33 ms·
New C features in GCC 13
- jmclnx 3y agoI miss the simple days of just regular K&R and a decent lint. c was suppose to be a nice small simple language, but each standard adds more and more complexity.
- baq 3y agogcc -std=c89 still works
- ape4 3y agoOr you can chose to use the only the modern subset. eg only nullptr and never NULL.
- josephg 3y agoSure; but you’ll need to learn all those other features if you want to read other people’s code. I was adamantly against Javascript adding OO-style classes and public/private methods and stuff for that reason. More stuff in the language makes it strictly harder to learn. Even if I don’t want to use those language features myself, I will inevitably end up reading and debugging other people’s code which does use those features. So I still need to learn it all, even if I don’t ever see myself using that stuff.
- jvanderbot 3y agoWhat we need is a good old wave of deprecation. Re-simplify around a slightly more modern syntax.
- pmarin 3y agoMany people still write in a C89 dialect just fine. Most of the good stuff is written in it: sqlite, curl, STB libraries, zlib, OS kernels etc.
- jmclnx 3y agoYes, that is what I stick to also, and that is better for portability.
- sylware 3y agoC syntax is already too rich and complex. What it needs is not more but less and some fixing: Only sized primitive types (u8/s8...u64/s64, f32/f64); typedef, enum, switch, all but one loop keyword (loop{}) should go away; No more integer promotion, only compile-time/runtime explicit casts (except for literals, and maybe void * pointers); explicit compile-time constants; no anonymous code block; etc. That said, if risc-v is successful, many components will be written directly in assembly, and trash-abl code will be written in very high-level languages with risc-v assembly written interpreters (python/perl5/lua/javascript/ruby/php/haskell/tintin/milou).
- klodolph 3y agoThe variable-size int, unfortunately, made a lot of sense in the early days of C. On processors like the x86 and 68000, it made sense for int to be 16-bit, so you don't pay for the bits you don't need. On newer systems, it makes sense for int to be 32-bit, so you don't pay to throw away bits.
- sylware 3y agoThat's why it needs fixing. We are not in the early days anymore.
- mytailorisrich 3y agoA "nice small simple" thing implies that someone has the power to say "that's it, we're freezing it the way it is". Instead, usually there is pressure to add, change, 'improve', keep up with the Joneses.
- shrimp_emoji 3y agoNot enough, if you ask me. It's treated mostly like a museum language, like classical music, with some polishing and quality of life improvements (that came 50 years too late, like checked arithmetic).
- never_inline 3y agoI used to think like this. Then I had to use `thread_local` where it was so much more convenient and portable (and likely faster) than pthread_getspecific. I think it's good quality of life features get added and standardized. Even Linux kernel uses lot of GNU extensions. Computers are there to abstract stuff for us.
- userbinator 3y agoIMHO C should remain a language that is easy to write a compiler for (and there have been many examples of individuals doing it, some of which have appeared on HN in the past), i.e. one should be able to "bootstrap" from it.
- flohofwoe 3y agoOh come on, pure K&R-C is a pain to read and write even for old-school C enthusiasts, and C99 brought some really nice improvements (like compound literals and designated initialization) while not overloading the language with bells and whistles, it's mostly just logical extensions of existing syntax that should have worked to begin with. And C-isms like '= { 0 };' instead of '= { };' never really made a lot of sense.
- VyseofArcadia 3y agoI am starting to see value in fixing a language when you hit 1.0. No more language changes at that point. If you want to change something, it has to be in a library.
- stephc_int13 3y agoI have to disagree here. C++ is becoming more complex and bloated over time. C, on the other hand, is becoming more convenient with almost no bloat or confusing features. C is aging slowly but graciously, in my opinion.
- pajko 3y agoExcept C23 is going to have a lot of anti-features: https://queue.acm.org/detail.cfm?id=3588242 https://queue.acm.org/detail.cfm?id=3588242
- uecker 3y agoThe article is a boring rant with no substance. His main issue seems to be the realloc zero change which he claims breaks idiomatic code. But this is certainly not idiomatic code as it never worked correctly in portable C code, because different implementations did different things for decades with no willingness to change.
- frde 3y agoI don't write C / C++ so I'm not too aware of what's going on there, but wouldn't someone that wants those features just switch to C++? Is there any reason to change C at this point?
- hbossy 3y agoC and C++ are separate languages and lots of people don't like C++.
- frde 3y agoI guess my question is: If you want `auto`, why put it in C instead of using C++ with no other C++ specific feature besides auto? I get people don't like classes / templates / .. but there isn't any reason one has to use those.
- masklinn 3y ago> I guess my question is: If you want `auto`, why put it in C instead of using C++ with no other C++ specific feature besides auto? Because they're orthogonal, and making function bodies less verbose with no loss of expressivity is nice, without needing to significantly alter the language? Pretty much every C competitor has local type inference, and C actually needs more than most due to the `struct` namespace, typing `struct Foo` everywhere is annoying, and needing to typedef everything to avoid it is ugly. Also C++ is missing convenient C features, like not needing to cast `void*` pointers, and designated initialisers were only added in C++20.
- pmarin 3y agoType inference only make the code harder to read. You ended doing mental compiler work when you could just write the damm type. And the people who say "I Just hover the variable in my IDE" It doesn't work in a terminal with grep, you can't hoved a diff file and not even github do the hover thing. Combine that with the implicit type promotion rules of C. Have Fun.
- codr7 3y agoIs it just me, or is C turning into a C++ dialect?
- nicoburns 3y agoAll these new features, but still no arrays/strings that keep track of their length!
- becquerel 3y agoI think that if you want that, you're working with the wrong language.
- coldtea 3y agoOne could say that for any feature that a language got later on and everybody feels fine with it added. Go/Java and generics for example. C++ and auto or closures. Javascript and async/await ("just learn regular Javascript async patterns"). The thing is C could have had a string type that knows its length since day one, with known performance tradeoffs, and also allow for everybody to build their own type in the more rare cases where it's needed. And most of buffer overflow and string handling bugs would have been avoid, as most of the programs using them don't need the performance or special handling of C strings (or don't need them where the bugs occur, e.g. when reading some configuration file).
- pjmlp 3y agoIndeed, stuff like sds should have long been available as vocabulary types.
- throwaway894345 3y agoGo/Java is a weird one. I don't see many instances of generics in the wild. Honestly the biggest benefit I enjoy is that people who never intended to use Go in the first place are slightly less loud about Go's position on generics. Beyond that, it's a small quality of life improvement to only have to define min and max once for all of my integer types (incidentally, this is really only a problem in Go because it's so dang easy/convenient to create your own int types, whereas in Rust, Java, TypeScript etc it seems like everyone just uses the standard int types for everything).
- hgs3 3y ago
- apaprocki 3y agoSince GCC 13 made the first page, it’s worth pointing out that 13 marks *-solaris2.11.3 obsolete and the backend will be removed entirely in 14. In order to get it in 13, you need to build GCC with --enable-obsolete. It’s always hard to judge who may still use or need this, but just throwing it out there. edit: Sorry, didn't mean to say 11.4 was obsolete. If you know of 11.3 machines that still exist, upgrade them!
- torstenvl 3y agoThe end of an era. The SPARC ISA was a work of art.
- gpderetta 3y agoregister windows in particular stood the test of time!
- snvzz 3y agoMore like, they were bad at introduction, and remained bad to date. They rank high alongside delay slots, in harmful features.
- gpderetta 3y agoSorry, I forgot the /s
- torstenvl 3y agoCurious why you think both were bad designs in a time when memory access was slow, branch prediction was bad/non-existent, and pipelining was new? The constraints applicable in the late '80s aren't the constraints applicable now. Plus, this is a story about C, so I feel comfortable embracing the principle of explicit control flow. Delay slots just take that principle down to the branch prediction level.
- pavlov 3y agoSPARC is dead, long live RISC-V.
- duckqlz 3y agoEveryone is so angry in the comments about c adopting c++ traits. I do not see it that way. This is not the language standard this is just GCC. Clang and GCC have always had compiler specific features which could only be described as wizardry to a regular c user. GCC has always kept the c standard at arms length, clang is a bit better but using compiler specific features has always been reserved for mavericks. Conversely, C23 has some great additions, none that remind me of C++? [1]. I don't think the standards enthusiasts that hang out on #c in freenode would be happy to think this many people see c going in the direction of C++. [1] https://open-std.org/JTC1/SC22/WG14/www/docs/n3054.pdf https://open-std.org/JTC1/SC22/WG14/www/docs/n3054.pdf
- pmarin 3y agoI am not angry, just very sad but I guarantee you most people who love to program in C or do it for a living are not "standards enthusiasts".
- peterfirefly 3y agoI am very happy about #embed, auto, constexpr, static_assert, unreachable, and ditching of K&R function parameters. Aren't you?
- pmarin 3y agoauto, constexpr: Kill them with fire. unreachable. No when the optimizer compiler can f*#k up my code if you combine it with unintended undefined behaviur. I just use asser(0) in debug builds. Not kidding.
- dale_glass 3y agoWhat's wrong with constexpr?
- pmarin 3y agoIts a crippled form of code generator in an era where compile time execution is suported by many modern system languages. But I don't like any of them. I prefer to write my own code generators.
- plq 3y agoAll quite reasonable additions to the language, kudos to the GCC team. I'm /very/ sad to see the unprototyped functions to go though -- that was my favourite way to catch newbies off-guard! Oh well ... As for those who like to spend their Friday afternoon feeling sad about C++isms creeping into C: You are very late! You should have done that when GCC implemented ``__attribute__((cleanup))`` years^Wdecades ago. edit: https://gcc.gnu.org/legacy-ml/gcc/2003-05/msg00528.html https://gcc.gnu.org/legacy-ml/gcc/2003-05/msg00528.html
- hgs3 3y agoIt's unfortunate that a scope cleanup mechanism, like __attribute__((cleanup)), wasn't introduced. There was a proposal for one but it relied on lambda's which didn't make the cut for C23.
- yrro 3y agoNow if only they'd kill implicit function declarations too...
- flohofwoe 3y agoClang says it's already been killed in C99: https://www.godbolt.org/z/KaWzsc6qT https://www.godbolt.org/z/KaWzsc6qT ...in GCC it's still just a warning though.
- yrro 3y agoHuh I had no idea! Seems weird that it's not an error by default!
- linkdd 3y agoMeh, I compile with -Werror :)
- ekeane 3y agoThat is a 'warning as default error', so for at least Clang16, it is still disable-able. The Clang code owner is on a bit of a well-deserved war-path against these, so they are likely to be completely illegal in the next version or two.
- jwilk 3y ago> C++11 standardized a similar feature under the name decltype, so sadly we wound up with two names for a nearly identical feature. If you wonder why: https://open-std.org/JTC1/SC22/WG14/www/docs/n2927.htm#existing-decltype https://open-std.org/JTC1/SC22/WG14/www/docs/n2927.htm#exist...
- meinersbur 3y agoThank you, I looked specifically whether this was discussed here already and found your reference.
- loeg 3y agoMy follow-up question is: why does decltype((value)) return int& in C++?
- pjmlp 3y agoYou can find an explanation here, https://www.scs.stanford.edu/~dm/blog/decltype.html https://www.scs.stanford.edu/~dm/blog/decltype.html
- loeg 3y agoThere are a lot of words on that page and none really jump out at me as explaining why C++ chose to have decltype yield something different for decltype(value) and decltype((value)). But I was unable to read them all, so maybe it is buried somewhere in there.
- pjmlp 3y agoSorry, could not find a video. See decltype section.
- loeg 3y agoIt provides a series of rules for exactly when decltype() picks a reference or non-reference type, but as far as I can see, it does not explain why the language chose to sometimes return references in some scenarios, such as for '(value)' vs 'value'.
- tpoacher 3y ago> The auto feature is only enabled in C2X mode. In older modes, auto is a redundant storage class specifier which can only be used at block scope. Is it redundant? I'm no c expert, but I remember several very specific cases where auto is necessary, and not using it leads to problems. Nested functions being the big one I remember. The 'new' meaning for the 'auto' keyword doesn't seem compatible with this change. Won't these affect lots and lots of code that relies on nested function semantics?
- peterfirefly 3y agoNested functions are not C. It's a gcc extension but it is not used much. Many Debian/Red Hat packages that used it had it removed more than a decade ago because the implementation did things like stuffing code into the stack and executing it. When we began hardening our machines and disallowing that kind of behaviour, those packages either had to upgraded to not use that feature or be removed.
- uecker 3y agoMy software and Debian package uses nested functions. I use it because code quality improves a lot with nested functions. But yes, the executable stack is a problem. I had a patch for GCC to use function designators which would have removed this problem, but it was not accepted due to some backwards compatibility issues. I think a generic solution could be a new function pointer type.
- AdamH12113 3y agoNested functions are a GCC extension, not standard C. As far as I know, there's never been a reason to use the auto keyword in standard C.
- tpoacher 3y agoInteresting, I hadn't realised... So in standard c, all function prototypes and definitions must always appear at toplevel?
- yuuta 3y agoStill no #embed
- olodus 3y agoI am not that against most of these. However, I don't think I ever will be for using 'auto' in C. Good C is about being extremely clear about what you want to happen at every step. Type inference goes against that imo. If you complain about writing a few more characters I don't think C is the language you are looking for. And I try to not use the "then C is not for you" line very often - I promise.
- booleandilemma 3y agoI do wish there was a programming language that just never added new syntax, ever. They could call the language "Stone", and then we'd get to say "such and such program is written in Stone", "not written in Stone", etc. If they keep adding features to C, such as type inference, won't C just ultimately become as feature-laden as C++, albeit on a much longer timescale? What's the point of that?
- mananaysiempre 3y ago> [T]hey keep adding features to C, such as type inference [...]. The thing about typeof (and its close cousin auto) is that it exposes information that the compiler’s frontend has to know anyway for type checking. That’s why GCC has had typeof for many years, even back when it only spoke pure C. So while it’s a new feature, it doesn’t really have a lot of implications for the rest of the language.
- Keyframe 3y agohence -std=stone -pedantic
- tristan957 3y agoHare is planning on doing this for what it's worth.
- booleandilemma 3y agoHey, thanks for letting me know about this, I'll check it out
- WickedSmoke 3y agoThe most desired C++ feature I'd like to see is the automatic typedef'ing of structures. Does anyone know why such a fundamental thing hasn't been implemented yet?
- uecker 3y agoBecause it would break a lot of existing code.
- WickedSmoke 3y agoHow would using an existing structure definition where an undefined type is found break anything? Compilers already know what you want to do as it will print an error such as: "unknown type name ‘Vec’; use ‘struct’ keyword to refer to the type".
- uecker 3y agoSo you want Vec to refer to struct Vec but only if there is no other type Vec defined before or until one is defined later? That would work, but might be a bit confusing.
- TremendousJudge 3y agoThat's how it works for an object's attributes inside methods, since this is optional by default. I hate it but there's precedent.
- WickedSmoke 3y agoC++ has struct & typedef and things work quite naturally. It always seemed like an obvious thing to bring to C, but I'm not sure about the nuances of the rules governing this.
- uecker 3y agoC++ had this forever (I assume), but for C this would be a breaking change which we try very hard to avoid.
- astrange 3y agoMy dream is that someday C will have safe varargs functions that know how many arguments the caller passed in.