Too little too late. Rust is already taking over, by the 22nd century C will be dead.
22nd Century C
11–20 of 106 posts
Re: 22nd Century C
#12I've spent two decades writing C and C++, but the last 8-9 years in really high-level languages (Ruby, Javascript, Python). From either end of the spectrum, I've never felt the need for such emphasis on fixed-sized numeric types. I've commonly needed access to fixed size numerics, like when sending texture formats to the GPU, defining struct layout in file formats and network protocols, but I have never once thought:…
Looks like you haven't worked on embedded systems. We need to be very careful with sizes of ints here. Not just because we run the risk of overflows, but also because when we create code that may have to be ported from one architecture to another, we want to minimize re-work.
> Notice how smooth the 32-bit to 64-bit transition went?
There are many reasons for that. For most PC work, a 32-bit int is more than large enough. Going to 64-bit should not have affected that at all. When you're working with embedded systems, you're often working at sizes that are the bare minimum that you can live with. You might also get to work on architectures where char, short, and int are all 32-bit wide. Assume something, and the communications protocol stops working. Moreover, the PC architecture itself supported coexistence of 32-bit and 64-bit executables.
Re: 22nd Century C
#13I'm not sure that 'address' is desirable. int adress adress adress foo; vs int * * * foo; Double pointers are extremely common and triple pointers show up now and then. Also '__attribute__ cleanup' as far as I know only works with automatic variables that live on the stack. Mucking about with code execution and automatic variables as the stack unwinds is not a style I would like to see in general purpose C coding. It…
int double_address foo; /* ? */ Or is it n steps away from ProducerObserverFactoryStragedy?
You know there'll be that one person who complains about it not supporting something nested like 20 pointers deep...
Re: 22nd Century C
#14I've spent two decades writing C and C++, but the last 8-9 years in really high-level languages (Ruby, Javascript, Python). From either end of the spectrum, I've never felt the need for such emphasis on fixed-sized numeric types. I've commonly needed access to fixed size numerics, like when sending texture formats to the GPU, defining struct layout in file formats and network protocols, but I have never once thought:…
Looks like you haven't worked on embedded systems. We need to be very careful with sizes of ints here. Not just because we run the risk of overflows, but also because when we create code that may have to be ported from one architecture to another, we want to minimize re-work. > Notice how smooth the 32-bit to 64-bit transition went? There are many reasons for that. For most PC work, a 32-bit int is more than large en…
> Looks like you haven't worked on embedded systems.
I've deleted a defensive technical response to point out that these dismissive assumptions (usually unjustified) are pretty prevalent on HN, and I don't think it promotes level-headed discussion. It reads like "Let me discredit a stranger's background that I don't know, and then argue my opposing view." It creates a defensive mindset off the bat.
Edit: I mean, your points are valid. We won't agree on them, but I don't like the assumption that we won't agree because I'm ignorant to them.
Re: 22nd Century C
#15Too little too late. Rust is already taking over, by the 22nd century C will be dead.
There will probably be C code running in 2100. That's only 84 years away. FORTRAN is now 60 years old and still going strong in scientific computing. (Partly because, in most other languages, multidimensional array support is worse.)
I suspect, though, that new successful languages will have automatic memory management, either GC/reference counting or Rust-type borrow checking. There's no reason for a new language with the lack of safety of C.
Re: 22nd Century C
#16Very cool! I wasn't aware of the cleanup attribute, can't wait to try it out:
The cleanup attribute runs a function when the variable goes out of scope. This attribute can only be applied to auto function scope variables; it may not be applied to parameters or variables with static storage duration. The function must take one parameter, a pointer to a type compatible with the variable. The return value of the function (if any) is ignored.
https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attribute...
Re: 22nd Century C
#17The "case" and "default" overrides seem kinda dicey.
Yeah, that is probably what bothers me the most about this. I write C code almost everyday. I can't remember the last time I forgot a "break", but I do use fallthrough when it simplifies the logic. It also breaks even the simple case of having multiple labels for the same code.
Also, the for-loop overrides are ugly and pointless, IMO.
Re: 22nd Century C
#18Too little too late. Rust is already taking over, by the 22nd century C will be dead.
There will probably be C code running in 2100. That's only 84 years away. FORTRAN is now 60 years old and still going strong in scientific computing. (Partly because, in most other languages, multidimensional array support is worse.) I suspect, though, that new successful languages will have automatic memory management, either GC/reference counting or Rust-type borrow checking. There's no reason for a new language wi…
[deleted]
Re: 22nd Century C
#19I'm not sure that 'address' is desirable. int adress adress adress foo; vs int * * * foo; Double pointers are extremely common and triple pointers show up now and then. Also '__attribute__ cleanup' as far as I know only works with automatic variables that live on the stack. Mucking about with code execution and automatic variables as the stack unwinds is not a style I would like to see in general purpose C coding. It…
int double_address foo; /* ? */ Or is it n steps away from ProducerObserverFactoryStragedy?
Actually, its not even an address its a pointer.
To get the address of an object you use the unary 'address of' operator '&'.
His macro was #define address *
The * is a pointer. You can declare a variable of type pointer to T with as many indirections as you want. int * * * * * * foo is fine. But you also use it to deference your object. bob = * foo;
You can't practically have a different name for each level of indirection to what ever the IS0 standard/Compiler limit is for * .
Also you end up with nasty indirections like this.
**(*((struct foo*)(*bob.x))).y
Re: 22nd Century C
#20You can write C in any language. You can also write any language in C.
The fact that it's possible does not imply that it's a good idea. Some of the macros here are in common use (e.g., countof, although often with other names); some will make experienced C developers say "what's this? Oh, you mean ; why did you use a weird macro?"; and some, like the redefinitions of case and default are actively hostile and are guaranteed to result in bugs when exposed to experienced C developers.
For more of the same, see "things to commit just before leaving your job": https://gist.github.com/aras-p/6224951