4 ms·

I also think that the committee is out of touch. C99 was an awesome improvement on the language, and since then, it went downhill. We don't need the extra weird

I also think that the committee is out of touch. C99 was an awesome improvement on the language, and since then, it went downhill. We don't need the extra weird C11 syntax things, duplicating of existing libraries; we want tools that scope C better, or extensions that have been proven helpful and stable (one such example is the switch(x) { case A...B: } from gcc!). I want strict boundary checking, I want an array base type that can't be cast as a pointer. I want some sort of scoping mechanism (ie, blocks), I want a bit of standardisation of memory barrier and such. I want #pragma once FFS -- it was proven a good idea for 25 years. Basically there's tons of stuff that could help make the language better -- C99 did that; C99 is a masterpiece for example on how you can statically initialise extremely complex data into a single block, without having to use code. It's used all over the Linux kernel (amongst other thing; for example my own simavr is heavily based on that feature [0]). * Standardise the stupid bit order in bitfield declaration FFS. I've been wanting to use that feature for 30 years and I can't because they 'forgot' to make up their mind! * Coroutine standardisation would be awesome (stack swap primitives, with boundary checks etc).... * gcc 'sub functions' (or a derivative) would be awesome if improved to make them safe. * Reference counted allocator (basically, get libtalloc and roll it in [1]) There are so many things that could be improved, without diverging into weird stuff nobody needs (complex math anyone??!?!). * In fact I want SIMD. I don't need these complex types. [0]: https://github.com/buserror/simavr/blob/master/simavr/cores/sim_megax.h https://github.com/buserror/simavr/blob/master/simavr/cores/... [1]: https://talloc.samba.org/talloc/doc/html/index.html https://talloc.samba.org/talloc/doc/html/index.html

bumblebritches5 8y ago
So you want C++, and need to leave that shit outta C. The only extensions I want from C2x is generic data (beyond void pointers) and type safe variadic functions. The rest you can build yourself, or use some other language. Edit: You HAVE SIMD without doing anything special, at least in Clang.
maxlybbert 8y ago
I can’t say much for most of your wish list, but I believe C11’s thread model/atomic operations include a standard memory barrier ( http://en.cppreference.com/w/c/atomic/atomic_thread_fence http://en.cppreference.com/w/c/atomic/atomic_thread_fence ).
pjmlp 8y ago
Looking at C2X list, I bet you aren't getting any of those wishes. http://www.open-std.org/jtc1/sc22/wg14/www/docs/PreBrno2018.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/PreBrno2018.... I am with you on strict boundary checking and array base types.
xtrapolate 8y ago
Honest question. You keep expecting all of these to be readily available for you in C (as part of the standard). Why don't you, instead, just a use a language/ecosystem which already offers all (or most) of these for you today? (ie. D/Go/Rust/Nim) > "* Reference counted allocator (basically, get libtalloc and roll it in [1])" Why and how should that be standardised exactly? Memory allocation is platform-dependent, hardware-dependent and generally case-specific. malloc() and free() are the lowest common denominators the standard can assume, anything beyond that is simply restrictive. If you need a "reference counted allocator", why not just find/implement one that simply suits your needs? > "* Coroutine standardisation would be awesome (stack swap primitives, with boundary checks etc)...." Again, what makes you think this can be standardised across the infinite span of platforms and compilation-targets, where C is often used? > "* In fact I want SIMD. I don't need these complex types." I'm not following your point. You're simply asking for a better abstraction for SIMD. Also, as I'm sure you're well aware, SIMD is not available everywhere. Wherever available, you have clear instruction-set APIs/ABIs you need to follow to make it work. What else is missing?
- buserror 8y ago
  I don't see your point. There's tons of stuff in C11 for example that is not applicable to a vast majority of where C is used. Even in C99 basic stuff as 'floating point' or 'malloc' is not available on many hardware, that doesn't stop having a standard way of using them /when applicable/. I know there are traps to fall into -- when I see people writing floating point code on an 8 bit AVR, I cringe, but well, 'it works'. As far as changing language, you just answered your own question by mentioning 4 of the myriad of them that aren't ported on as many platform as C, requires runtime of unknown quality, and also requires a body of developers that... doesn't exist. I've had a long enough time in the industry to have seen quite a few times a whole bunch of software done by someone who was following the fancy trendy language of the day, and required a complete rewrite in... C to be able to move on from it. Heck, I've done similarly as well, done 20+ years of C++, gradually trying to scope down the subset of what I was using to then realize I just might be better of with plain C -- and magic happened -- stuff still compile/work years after they were made... And anyone/everyone can just dive in and use the codebase.
enriquto 8y ago
> weird stuff nobody needs (complex math anyone??!?!). in my work (signal processing) I use complex math in C every day, and native language support for complex numbers is the single most important thing in my choice of C over other languages > I want an array base type that can't be cast as a pointer just out of curiosity? why would you like that? I mostly agree with the spirit of your comments (apart from neglecting the importance of complex math). I would add the following: * better stack support (e.g. a standard way know whether a VLA fits) * closures (being able to return a pointer to a local function)
- buserror 8y ago
  > in my work (signal processing) I use complex math in C every day, and native language support for complex numbers is the single most important thing in my choice of C over other languages Fair enough -- but I think you are in a fairly corner market -- personally I think I used complex math /twice/ over the last 30+ years... I used SIMD extensively tho, from Altivec onward! >> I want an array base type that can't be cast as a pointer > just out of curiosity? why would you like that? For bound checking. In C right now if you declare a char blob[4] and pass it as parameter to anything, it's passed down as a char * mostly -- and that function can clobber whatever it likes. An array type would propagate the size down so bound checking can be done at for the whole lifetime of the array. > * better stack support (e.g. a standard way know whether a VLA fits) Yes, anything involving stack requires serious dirty hacking -- even for basic things as 'what are my high/low water marks'. Basically your stack is just a problem waiting to explode in your face, especially on smaller devices. > * closures (being able to return a pointer to a local function) That's mostly what I meant by sub-functions -- I used them quite a bit, until I had to crossport to llvm (they refused to implement them). Apple "blocks" look pretty good, but I know there are a couple alternative implementations...
  - enriquto 8y ago
    > Fair enough -- but I think you are in a fairly corner market -- personally I think I used complex math /twice/ over the last 30+ years... I used SIMD extensively tho, from Altivec onward! One of the best ways to implement SIMD support for C would be to add native quaternion and octonion support to the language!

bumblebritches5 8y ago

So you want C++, and need to leave that shit outta C. The only extensions I want from C2x is generic data (beyond void pointers) and type safe variadic functions. The rest you can build yourself, or use some other language. Edit: You HAVE SIMD without doing anything special, at least in Clang.

maxlybbert 8y ago

I can’t say much for most of your wish list, but I believe C11’s thread model/atomic operations include a standard memory barrier ( http://en.cppreference.com/w/c/atomic/atomic_thread_fence http://en.cppreference.com/w/c/atomic/atomic_thread_fence ).

pjmlp 8y ago

Looking at C2X list, I bet you aren't getting any of those wishes. http://www.open-std.org/jtc1/sc22/wg14/www/docs/PreBrno2018.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/PreBrno2018.... I am with you on strict boundary checking and array base types.

xtrapolate 8y ago

Honest question. You keep expecting all of these to be readily available for you in C (as part of the standard). Why don't you, instead, just a use a language/ecosystem which already offers all (or most) of these for you today? (ie. D/Go/Rust/Nim) > "* Reference counted allocator (basically, get libtalloc and roll it in [1])" Why and how should that be standardised exactly? Memory allocation is platform-dependent, hardware-dependent and generally case-specific. malloc() and free() are the lowest common denominators the standard can assume, anything beyond that is simply restrictive. If you need a "reference counted allocator", why not just find/implement one that simply suits your needs? > "* Coroutine standardisation would be awesome (stack swap primitives, with boundary checks etc)...." Again, what makes you think this can be standardised across the infinite span of platforms and compilation-targets, where C is often used? > "* In fact I want SIMD. I don't need these complex types." I'm not following your point. You're simply asking for a better abstraction for SIMD. Also, as I'm sure you're well aware, SIMD is not available everywhere. Wherever available, you have clear instruction-set APIs/ABIs you need to follow to make it work. What else is missing?

buserror 8y ago
I don't see your point. There's tons of stuff in C11 for example that is not applicable to a vast majority of where C is used. Even in C99 basic stuff as 'floating point' or 'malloc' is not available on many hardware, that doesn't stop having a standard way of using them /when applicable/. I know there are traps to fall into -- when I see people writing floating point code on an 8 bit AVR, I cringe, but well, 'it works'. As far as changing language, you just answered your own question by mentioning 4 of the myriad of them that aren't ported on as many platform as C, requires runtime of unknown quality, and also requires a body of developers that... doesn't exist. I've had a long enough time in the industry to have seen quite a few times a whole bunch of software done by someone who was following the fancy trendy language of the day, and required a complete rewrite in... C to be able to move on from it. Heck, I've done similarly as well, done 20+ years of C++, gradually trying to scope down the subset of what I was using to then realize I just might be better of with plain C -- and magic happened -- stuff still compile/work years after they were made... And anyone/everyone can just dive in and use the codebase.

enriquto 8y ago

> weird stuff nobody needs (complex math anyone??!?!). in my work (signal processing) I use complex math in C every day, and native language support for complex numbers is the single most important thing in my choice of C over other languages > I want an array base type that can't be cast as a pointer just out of curiosity? why would you like that? I mostly agree with the spirit of your comments (apart from neglecting the importance of complex math). I would add the following: * better stack support (e.g. a standard way know whether a VLA fits) * closures (being able to return a pointer to a local function)

buserror 8y ago
> in my work (signal processing) I use complex math in C every day, and native language support for complex numbers is the single most important thing in my choice of C over other languages Fair enough -- but I think you are in a fairly corner market -- personally I think I used complex math /twice/ over the last 30+ years... I used SIMD extensively tho, from Altivec onward! >> I want an array base type that can't be cast as a pointer > just out of curiosity? why would you like that? For bound checking. In C right now if you declare a char blob[4] and pass it as parameter to anything, it's passed down as a char * mostly -- and that function can clobber whatever it likes. An array type would propagate the size down so bound checking can be done at for the whole lifetime of the array. > * better stack support (e.g. a standard way know whether a VLA fits) Yes, anything involving stack requires serious dirty hacking -- even for basic things as 'what are my high/low water marks'. Basically your stack is just a problem waiting to explode in your face, especially on smaller devices. > * closures (being able to return a pointer to a local function) That's mostly what I meant by sub-functions -- I used them quite a bit, until I had to crossport to llvm (they refused to implement them). Apple "blocks" look pretty good, but I know there are a couple alternative implementations...
- enriquto 8y ago
  > Fair enough -- but I think you are in a fairly corner market -- personally I think I used complex math /twice/ over the last 30+ years... I used SIMD extensively tho, from Altivec onward! One of the best ways to implement SIMD support for C would be to add native quaternion and octonion support to the language!