10 ms·
C23: A Slightly Better C
- z_open 3y agoThe auto keyword seems like a strange addition given it's already a C keyword with a different meaning and this change won't help developers that much. It's more useful in C++.
- masklinn 3y agoIt's more useful in C++ with things like generic and voldemort types, but I still would not discount it in C as the lack of namespacing impacts type names, and it could limit convenience typedefs (those which exist only to avoid the `struct` and `enum` prefixes). It might also help transitioning to fixed integer types, which are rather verbose.
- kevin_thibedeau 3y agoC has generics as well. This permits the return type of generic functions to be preserved.
- jcranmer 3y agoThe only generic feature C has is the _Generic expression, which isn't a function, but closer to a switch(typeof(x)) expression.
- kevin_thibedeau 3y ago_Generic can be used to merge a collection of functions.
- CyberDildonics 3y agoThat's not the same as being able to write a data structure that takes any type.
- kevin_thibedeau 3y agoIt's still generic. You don't have to have feature parity with C++ to meet that bar.
- CyberDildonics 3y agoThat would be like calling function overloading generics.
- neutrono 3y agoIt should have been called _Overload or something similar, since it's not really a generic.
- rightbyte 3y agoHah. Voldemort types. The ones that can't be named (in practice becouse too long to fit on a line or remember)?
- gpderetta 3y agoAlso because they might be a) an undocumented implementation detail (the result of std::bind for example); b) utterly unutterable like the type of a lambda expression.
- masklinn 3y ago> The ones that can't be named (in practice becouse too long to fit on a line or remember)? Nah those are easy to name, just annoying, it's types which literally don't have an external / public name, like lambdas, or locally defined types.
- bheadmaster 3y agoIt's actually a struct that only has a name in the scope of the function which returns `auto`, and thus cannot be named outside of it. Like this: #include <iostream> auto createVoldemortType(int value) { struct Voldemort { int value; }; return Voldemort{value}; } int main() { auto voldemort = createVoldemortType(7); std::cout << voldemort.value << std::endl; // output: 7 }
- krater23 3y agoThis way to code is a good reason to make auto the same tabu as goto.
- trealira 3y agoI wonder how much this complicates parsing C++. Because of this, you can't discard/free struct and class definitions as soon as you leave the scope, like you can in C, because the definition can still escape the scope by being returned from a function with the "auto" keyword.
- 3y ago
- anthomtb 3y agoAre there any publicly-viewable C codebases that make use of pre-C23 auto? When I learned C (2003-ish) auto vs. register was at best a footnote that came up when discussing static. I agree that you don't need auto pointers in C the way you do in C++. C++ type names can get so cumbersome...much easier to let the compiler figure it out for you.
- andoaaaaz662 3y ago[dead]
- trealira 3y agoIt could help in generic macros, like this: #define SWAP(var1, var2) do { \ auto tmp = var1; \ var1 = var2; \ var2 = tmp; \ } while (0) Previously, you would have needed a third macro for the type, or you would have needed to do a byteswap to be generic.
- unwind 3y agoTrue, and now we also get typeof() so there is more than one way! const typeof(var1) tmp = var1;
- kstrauser 3y agoWhy’s that inside do/while?
- asplake 3y agoTo scope the temporaries?
- peterfirefly 3y agoNo, a block would be enough for that. It's to make ; handling natural when the macro is used.
- glouwbug 3y agoForces the use of a semicolon: SWAP(…);
- trealira 3y agoIf you simply put braces around it, you'd generate syntactically invalid code when you don't use braces for if-else statements. Consider this: if (e) SWAP(a, b); else something_else(); Currently, that expands to this, which is still valid code: if (e) do { // ...macro... } while(0); else something_else(); If it were just wrapped in braces, the code would be parsed like this: // One-armed if-statement if (e) { // ...macro... } // Empty statement ; // Another statement else something_else(); It's incorrect syntax to start a statement with else, so the compiler will say something like "Unexpected 'else' at line N."
- andoaaaaz662 3y agoDefinitely my least favorite of the new additions. The rest of them are good but I have a feeling auto and typeof on the left hand of an assignment are both going to be considered no-nos in real codebases. I think they obfuscate things unnecessarily. In C++ it's understandable because with templates you have a tendency to have massively complicated type names. Everything else looks great to me though.
- Conscat 3y agoIt standardizes existing common practice. Everyone already has `__auto_type` macros, but nearly nobody was using `auto` as a synonym for `int`.
- Karellen 3y ago> If you have GCC 23 or LLVM (Clang) 16 gcc 23? That doesn't sound right
- quincepie 3y agoprobably meant 13
- kevin_thibedeau 3y agoThe eighth line uses the static_assert keyword, which is a feature of C++11 C11 already had _Static_assert() and static_assert() in assert.h
- jwolfe 3y agoThat's already noted at the end: > The idea behind static_assert is great. You run a check that has no impact on the performance of the software, and may even help it. It is cheap and it can catch nasty bugs. It is not new to C, but adopting the C++ syntax is a good idea.
- Brian_K_White 3y agofta "It is not new to C, but adopting the C++ syntax is a good idea."
- zeckalpha 3y agoDid that work at compile time?
- jonathrg 3y agoWhat would it mean for _Static_assert to not work at compile time?
- hmry 3y agoThe keyword is new though
- lifthrasiir 3y agoMore accurately: C23 makes `static_assert` a keyword and remove `#define static_assert _Static_assert` in <assert.h>, so `#include <assert.h>` is no longer needed for `static_assert`. So the syntax was always supported since C11 but it's made more convenient to use.
- mgaunard 3y agoC++ is already a better C. So much so that new revisions of C are just backporting features at this point.
- z_open 3y agoC++ and C are no longer used for the same types of projects so C++ is not a better C.
- pjmlp 3y agoUntil C fixes its string and array story, C++ keeps being a better C.
- mgaunard 3y agoI think you must be from the 90s -- if so can you share your time machine? All kinds of major projects switched to C++ already, for example GCC. All the major new projects, for example LLVM, are also in C++ from the get-go. Even the Linux kernel is considering switching to C++ now.
- leosanchez 3y ago> Even the Linux kernel is considering switching to C++ now. Source?
- dzonga 3y agoquick qn ? for the tinkerers -- is there a language these days that nicely interfaces with c i.e able to use all c libraries through ffi. without loss of performance or extra fu. the language being small enough that all basics can be grasped in a day. the language being complete that it will remain the same in 10 years. while at the same time being memory safe. btw I don't think golang applies given the bad ffi story in go. --- edit btw:: yeah this implies the use of a GC. though it must not have massive pauses or stop the world GC.
- School-Cotton 3y agoZig
- andyjohnson0 3y agoI've heard good things about Zig. Interop with C libraries seems to be good, and there is some degree of memory safety (though not, as i understand it, anything like .net/Java).
- paulddraper 3y agoD [x] nicely interfaces with c [x] the language being small enough that all basics can be grasped in a day [x] the language being complete that it will remain the same in 10 years (the 1.0 release was 23 years ago) [x] while at the same time being memory safe.
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- liquid153 3y agoNo mention of typed enums and nullptr. Small things but makes dev experience better
- synergy20 3y agobased on https://en.cppreference.com/w/c/compiler_support/23 https://en.cppreference.com/w/c/compiler_support/23 even the newest clang does not support many of the c23 features. gcc13 is much better, only a very few c23 are yet to be supported. this is a long standing problem with clang/clang++: they're used in many linters and intellisense but they're lagging behind by a lot comparing to gcc.
- xxpor 3y ago>they're used in many linters and intellisense but they're lagging behind by a lot comparing to gcc. Pure speculation, but I wouldn't be surprised if these two were directly related to each other. Clang/LLVM is more modular, which makes it easy to write new things that integrate it (like a linter), but this can slow down adding new things that change the data model and external interfaces. GCC is the opposite: one big blob that makes it easier to add things since the surface area is lower.
- pjmlp 3y agoActually it is a mix of factors, companies enjoy their downstream forks without contributing to upstream thanks license. Almost all major compiler vendors have migrated to clang forks and if they contribute upstream, is on the backend side, for their platforms, not fronted changes. Big contributors like Apple and Google, deciding to refocus on their own languages, and current language support being good enough for their LLVM use cases.
- ronsor 3y agoPelles C for Windows actually supports all (perhaps missing one or two) C23 features, even `#embed`.
- slacka 3y agoAll of the features descried in the article are supported by clang except maybe for the constexpr keyword. By your own list, neither one supports all the features. Also, gcc only supports about 4 or 5 features more than gcc, and clang supports a few gcc doesn't. Hardly "much better".
- jakearmitage 3y agoWhy no std::string?
- layer8 3y agoMemory allocation, interoperability with existing libraries. Would require a huge new API and tricky design choices.
- flohofwoe 3y agoBecause std::string is pretty much the worst way how one would implement a string type. Sometimes it's better to not have a feature than to have a broken feature.
- jakearmitage 3y agoCould you point me to implementations that you believe are good? Much appreciated.
- AlectronikLabs 3y agoWhy don't they start to support units instead of these ugly header files to finally stop duplicating code? I see this might break stuff but you could implement it side by side with the preprocessor so old code would continue to work.
- selfmodruntime 3y agowhy not introduce an "import" keyword and keep the include keyword for old headers?
- Wevah 3y agoIf you mean #import, it already exists as a keyword (though the meaning is different between GCC/Clang and MSVC).
- Gibbon1 3y agoWalter Bright says he was able to implement modules in C with 10 lines of code. That probably works with C but it'd make C incompatible with C++. Most people think that's reason enough not to do it. I think breaking compatibility with C++ would be like cutting the ropes to a sinking ship to save your own.
- Sebb767 3y ago> That probably works with C but it'd make C incompatible with C++. C is not a subset of C++. The simplest example: > int new = 1; Perfectly valid C, but not valid C++. Now, modules would obviously be a bigger break than a few keyword incompatibilies, but at that point you'd also massively increase complexity and basically start creating C++ again, which is probably the actual reason it hasn't happened yet.
- Gibbon1 3y agoIf you listen to the C++ people it's obvious they think the incompatible changes are a terrible mistake. They can't undo them but they're adamant no other breaking changes be allowed. They don't want things to get worse for them. Meaning better for everyone else. And no modules wouldn't make C more like C++. It's just make C a bit saner and faster to compile. Because modules are complete and don't depend on code compiled before the import. Which means you can compile your modules exactly once and only once. Well written C code bases you could probably just change #include to #import and reap the benefits.
- malkia 3y agoI hoped for defer (e.g. "RAII" of sorts), is there any way?
- oconnor663 3y agoThere was an update on this just last week: https://github.com/ThePhD/future_cxx/issues/67#issuecomment-1891062821 https://github.com/ThePhD/future_cxx/issues/67#issuecomment-...
- joshkel 3y agoAccording to https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2391r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p23..., it's an "unadopted feature being explored." There's more information about the proposal at https://gustedt.wordpress.com/2022/01/15/a-defer-feature-using-lambda-expressions/ https://gustedt.wordpress.com/2022/01/15/a-defer-feature-usi...
- mike_hock 3y ago> typeof What was wrong with "decltype"? Seems utterly bizarre given that the rest is verbatim copypasta from C++, even the attribute syntax that sticks out like a sore thumb in C, and also given that auto and decl.. I mean, typeof, serve no useful purpose in C.
- edflsafoiewq 3y agohttps://www.open-std.org/jtc1/sc22/wg14/www/docs/n2927.htm#existing-decltype https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2927.htm#e...
- camel-cdr 3y agoIIRC behavior is has slightly different behavior, and most compilers already support typeof in c.
- hmry 3y agoBecause it has different behavior than decltype. (Isn't that why they decided to call it decltype in C++ in the first place? To show that it has different behavior than the GCC extension typeof?)
- flohofwoe 3y agoApart from having different behaviour than decltype, typeof is also a much better name IMHO (and GCC had typeof as language extension probably even before C++11 added decltype).
- Arch-TK 3y ago"slightly better" - nah, just as mediocre. Let me tell you, nobody stuck with C is going to bat an eyelid at this standard. They're going to continue using C89, or maybe C99 if they're lucky, for whatever reasons that justify it. People who casually write C don't really care for C23 since it fixes all the wrong things. Nobody really wanted C+ (i.e. something slightly closer to C++ than before) which is basically all this standard achieves.
- JackSlateur 3y agoHuh ? I use the cleanup attribute, for instance, which is a Real game changer Nobody wants that ? Everybody who knows it exist wants that.
- Arch-TK 3y agoThat's not a C23 feature. It's a non-portable compiler extension which has existed for a _long_ time.
- JackSlateur 3y agoHa ? Maybe I just woke up in 2023 and get confused :/ Thank you for the correction
- flohofwoe 3y agoI write a lot of C code (https://github.com/floooh/ https://github.com/floooh/) and I'm actually looking forward to some of the changes in C23 (depending on when MSVC will implement them, because most of the changes I'm looking forward to already exist as non-standard language extension in GCC and Clang, but not in MSVC).
- Arch-TK 3y agoGiven how long it took MSVC to attempt to support anything above the bare minimum C support for C++ interoperability. I wouldn't hold my breath.
- LAC-Tech 3y agoI remember back in the day everyone insisted C codebases had to be C89 so people could compile them in visual studio. EG the python interpreter. Is this still the case?
- pjmlp 3y agoVisual C now does C17, minus the C99 features that became optional in C11 like VLAs.
- keithnz 3y agoInteresting to see they are removing some of the quirkier things... - Remove Trigraphs. - Remove K&R function definitions/declarations (with no information about the function arguments)
- TwentyPosts 3y agoWait, no trigraphs anymore??? This is horrible, I loved using `and` and `not` and `or` in C boolean expressions and to pretend I'm writing Python code. It's fun!
- bombela 3y agoI find those keywords much more readable, and faster to type (qwerty). I also wish Rust had those instead of the weird symbols. Oh well, c'est la vie.
- pitaj 3y agoIn Rust you can just use the method call `expr.not()`
- pzmarzly 3y agoWhile it's true that in Rust most operators (eg. all arithmetic operators, as well as !, &, |, ^) are just syntax sugar over some trait methods that you could call directly, this is not the case for boolean "and" and "or": && and || have to be special due to their short-circuiting properties (in "false && b()" b never gets called, same in "true || b()").
- agapon 3y agoThose are not trigraphs, of course.
- TwentyPosts 3y agoReally? The Wikipedia article on trigraphs seems to disagree. Why do you think so?
- parenthesis 3y agockd_add(), ckd_sub() are ckd_mul() are what I'm looking forward to using.
- matheusmoreira 3y agoI'm told the C standards committee is actually just the C++ one. Explains a lot.
- flohofwoe 3y agoA small improvement in C23 - but probably my favourite - is that it finally allows writing: struct bla_t bla = {}; ...instead of struct bla_t bla = {0}; This was one of those pointless differences between C and C++ which caused a lot of grief when writing code in the common C/C++ subset. PS: also func() now actually is the same as func(void), and unnamed parameters are allowed.