https://gustedt.wordpress.com/2021/01/12/improve-type-generic-programming/https://gustedt.wordpress.com/2021/01/12/improve-type-generic-programming/ Skip to content Jens Gustedt's Blog Improve type generic programming This is a new paper that appeared today on the site of the C committee: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2638.pdf C already has a variaty of interfaces for type-generic programming, but lacks a systematic approach that provides type safety, strong ecapsulation and general usability. This paper is a summary paper for a series that provides improvements through * N2632. type inference for variable definitions (auto feature) and function return * N2633. function literals and value closures * N2634. type-generic lambdas (with auto parameters) * N2635. lvalue closures (pseudo-references for captures) The aim is to have a complete set of features that allows to easily specify and reuse type-generic code that can equally be used by applications or by library implementors. All this by remaining faithful to C's efficient approach of static types and automatic (stack) allocation of local variables, by avoiding superfluous indirections and object aliasing, and by forcing no changes to existing ABI. Share this: * Share * * Email * Print * * Facebook * Twitter * * Related [c3fbd]Author Jens GustedtPosted on January 12, 2021Categories C2x, core 4 thoughts on "Improve type generic programming" 1. [xUs8] Johny Shih (@twCyborg) says: January 25, 2021 at 20:34 Hi Jens, is there any chance C could have support of function members in custom types as maybe a syntactic sugar for member function pointers in the future? struct Point { int x, y; void reset(){ x = 0; y = 0; } } That would be a dream come true. Reply 2. [c3fb] Jens Gustedt says: January 26, 2021 at 08:19 From your question I assume that you mean for C to have classes, because your example supposes that behind the reset function there is a hidden object that gets initialized. Most certainly not. This has been discussed several times in the past, I think, and never made it into C. Classes are a whole can of worms, with implicit objects, this pointers, const qualification (or not) and a lot of indirections. This classic model of OO programming has clearly fallen out of fashion since already some time, and for C it is particularly inappropriate because we like to have things explicit as much as this is possible. What I'd hope could come some day (but far away) are modules, that is the possibility to group features together in a convenient way that allows to program them and refer to them easily. This not so difficult to achieve and can mostly be done with some textual replacement. For example shnell as I presented in this post https://gustedt.wordpress.com/2020/11/10/ c-source-to-source-compiler-enhancement-from-within/ has such a facility. Reply 3. [5300] zd7c says: February 17, 2021 at 15:10 Why introduce more and more language constructs from C++ that make the difficulty of implementing C approach that of implementing C++? And these are the kind of constructs that hide a significant cost to its users: code generation and thus ballooning code size. C's explicitness is a really good feature of the language. I hope this would be optional for, just like VLAs are optional since C11 (__STDC_NO_VLA__). (Side note: A while ago I've posted a long comment on the core specification v2 post. Was it removed/unapproved for some reason? I apologize if the tone was too critical.) Reply 1. [c3fb] Jens Gustedt says: February 17, 2021 at 15:28 I don't like this opposition that you imply in your question between C and C++, and I don't like the "more and more" either. This series of papers is just proposing a quite reduced and selected set of features that come from C++, yes, but could also be inspired from somewhere else. By no means this introduces C++'s complexity into C. Everybody has their own selection properties that they like in a particular programming language, nobody is forced to use features they don't like. As the paper states, C has already 8 different forms of type-generic programming, and the weirdness-level that these impose on our programmers is quite high. This series of papers tries to give them features at hand that allow for a more systematic approach. For the other post that you are refering to, I don't have a particular recollection. I am not at all oposed to approve posts that are critical to what I am doing, here, but indeed, I don't publish posts have a tone that hides the contents. Generally, when that happens I try to contact the author about that, if I happen to find an email address for them. Reply Leave a Reply Cancel reply Enter your comment here... [ ] Please log in using one of these methods to post your comment: * * * * Gravatar Email (required) (Address never made public) [ ] Name (required) [ ] Website [ ] WordPress.com Logo You are commenting using your WordPress.com account. ( Log Out / Change ) Google photo You are commenting using your Google account. ( Log Out / Change ) Twitter picture You are commenting using your Twitter account. ( Log Out / Change ) Facebook photo You are commenting using your Facebook account. ( Log Out / Change ) Cancel Connecting to %s [ ] Notify me of new comments via email. [ ] Notify me of new posts via email. [Post Comment] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] This site uses Akismet to reduce spam. Learn how your comment data is processed. Post navigation Previous Previous post: A defer mechanism for C [c3fbdd40] C as a language [gustedt-modernc-hi-band] Copyright (c) 2010-2019 Jens Gustedt, Strasbourg, France P99 macros for C99 emulation of C11 Categories * C++ (10) * C11 (43) + defects (11) + feature request (2) + library (9) * C17 (10) * C2x (7) * C99 (69) + integers (11) + language (31) + P99 (17) + preprocessor (12) + syntax (15) * compiler optimization (4) * core (3) * lock structures (8) * Modular C (5) * POSIX (13) + linux (2) * rants (5) * Uncategorized (1) Recent Posts * Improve type generic programming * A defer mechanism for C * C source-to-source compiler enhancement from within * An interview on Software Engineering Radio on Modern C * A Common C/C++ Core Specification rev 2 Top Posts & Pages * Improve type generic programming * A defer mechanism for C * Don't use casts * Modern C, Second Edition * Default arguments for C99 * Don't use NULL * cross-language interfaces between C and C++ * Detect empty macro arguments * C source-to-source compiler enhancement from within * C17 Search for: [ ] Search related * C99 * c threads * preprocessor Follow Blog via Email Enter your email address to follow this blog and receive notifications of new posts by email. Join 161 other followers Email Address: [ ] Follow Meta * Register * Log in * Entries feed * Comments feed * WordPress.com Archives * January 2021 * December 2020 * November 2020 * June 2020 * May 2020 * March 2020 * September 2019 * August 2018 * June 2018 * April 2018 * August 2017 * May 2017 * March 2017 * January 2017 * November 2016 * September 2016 * August 2016 * July 2016 * July 2015 * May 2015 * April 2015 * February 2015 * October 2014 * September 2014 * April 2014 * December 2013 * October 2013 * August 2013 * July 2013 * February 2013 * December 2012 * November 2012 * October 2012 * August 2012 * July 2012 * May 2012 * April 2012 * March 2012 * February 2012 * January 2012 * December 2011 * November 2011 * October 2011 * July 2011 * June 2011 * March 2011 * February 2011 * January 2011 * December 2010 * November 2010 * October 2010 * September 2010 * August 2010 * July 2010 * June 2010 RSS RSS Feed RSS - Posts RSS Feed RSS - Comments Jens Gustedt's Blog Create a free website or blog at WordPress.com. Send to Email Address [ ] Your Name [ ] Your Email Address [ ] [ ] loading [Send Email] Cancel Post was not sent - check your email addresses! Email check failed, please try again Sorry, your blog cannot share posts by email. [Close and accept] Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use. To find out more, including how to control cookies, see here: Cookie Policy [b]