11 ms·

22nd Century C

130 points by Procedural 10y ago

TempleOSV409 10y ago
HolyC is from God.
em3rgent0rdr 10y ago
I don't get it. Could someone summarize/explain this.
- eudox 10y ago
  The included header file uses the macro system, among other things, to bring C99 up-to-date with more modern programming techniques, using what we've learnt in the past decades since C was conceived. In fairness however the short POD type names are purely cosmetic.
- pqhwan 10y ago
  I'm only guessing, but it looks like a C header file with a set of macros that produces neat-looking C code. Not sure what's the deal with the 22nd century thing.
  - coldtea 10y ago
    Probably an answer to the "21st century C", an O'Reilly book about how to write modern C.
  - PieterH 10y ago
    It's a clever joke and rather cynical deconstruction of our industry. The author suggests that in 100 years the C language will not only still exist and be widely used, it will have advanced almost nothing at all due to the industry's inability to solve real problems and instead focus on virtue signalling languages such as Clojure and Ruby. The author hammers home his point by demonstrating how a simple header file can at once render the code unreadable, while adding absolutely no value at all. I think he or she is specifically talking about Silicon Valley here, though of course since the joke is expressed in code, one can only guess. Seriously, I'd hope in 2100 we'd have pushed our systems languages beyond facile keyword redefinition. Maybe even towards concurrency and an actor model. Like I explored in my unfinished (sorry, shit happened) book "Scalable C". Or, Rust.
generic_user 10y ago
I'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. Its the one type of automatic memory management that you get for free and can't really screw up. The rest of the macro loops and so forth seem fairly standard. Its good to experiment and explore what you can do with the compiler and the preprocessor.
- noobermin 10y ago
  int double_address foo; /* ? */ Or is it n steps away from ProducerObserverFactoryStragedy?
  - mdadm 10y ago
    You know there'll be that one person who complains about it not supporting something nested like 20 pointers deep...
  - generic_user 10y ago
    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 Its nasty enough as it is without trying to name each pointer indirection.
dikaiosune 10y ago
fn main() { println!("hello, world"); } I kid, I kid. This looks cool!
microcolonel 10y ago
The "case" and "default" overrides seem kinda dicey.
- Tim61 10y ago
  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.
- jonathankoren 10y ago
  Yup. Congratulations kid. You broke fall-through, perhaps the biggest advantage of a switch over else-ifs.
- abecedarius 10y ago
  I defined the same macros but with different names, back when I still coded in C. I still think it's a good idea which tends to get reactions like "Ew! Wash your hands."
mieko 10y ago
I'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: "You know what, I'd like to make a decision as to the width of an integer every time I declare a function." "Just has to work" low level code was the norm during the 16-bit to 32-bit transition, so it was a fucking pain. Notice how smooth the 32-bit to 64-bit transition went? (and yes, it was smooth.) I credit that to high-level languages that don't care about this stuff, and people using better practices like generic word-sized ints and size_t's in lower level code. Keep that stuff on the borders of the application. I've noticed a decent-sized emphasis on type size in both Crystal and Swift, two not-entirely braindead newer languages. I don't get it, it's a big step backward.
- lake99 10y ago
  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.
  - mieko 10y ago
    > 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.
Mathnerd314 10y ago
Too little too late. Rust is already taking over, by the 22nd century C will be dead.
- Animats 10y ago
  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.
  - deleted 10y ago
    [deleted]
  - petre 10y ago
    Dlang is actually quite nice and mature, although nowhere nearly as hyped as Rust, Go or Swift. You get a GC with the option of deactivating it and doing the memory management yourself, pointers and casts if you need them (you usually don't), an auto type, fast compiling times, among many other cool things. https://dlang.org/overview.html https://dlang.org/overview.html
- kchoudhu 10y ago
  I don't know what the systems programming language of the 22nd century will look like, but I do know that it will be called C.
  - pjmlp 10y ago
    On UNIX yes, it will never change, C is married to UNIX and no alternative will ever change that. On other OSes, it really depends on how Apple, Google and Microsoft do their work of "our way or the highway" regarding pushing their safe alternatives.
    - 10y ago
alxmdev 10y ago
Very 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-Attributes.html https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attribute...
- jagger11 10y ago
  FYI - here's defer implementation for both gcc/clang - http://pastebin.com/EXZuRAdT http://pastebin.com/EXZuRAdT
cperciva 10y ago
You 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 <insert expansion here>; 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 https://gist.github.com/aras-p/6224951
dpc_pw 10y ago
That is very impressive. I really like the cleverness and cleanliness of these "hacks". Still... I wouldn't introduce it into existing/shared codebase due to risk of confusing everyone, and I will never start my own project in C again.
jdmoreira 10y ago
Maybe the author wanted this to be C99 compliant but a cool thing is that by using clang we even have lambdas. It's called blocks, the same as in Objective-C. http://clang.llvm.org/docs/BlockLanguageSpec.html http://clang.llvm.org/docs/BlockLanguageSpec.html I've been using them in all my new C code, since I'm stuck to clang anyway, and it's awesome.
transfire 10y ago
Still using header files in the 22nd century?
TickleSteve 10y ago
this is basically an updated version of iso646.h [https://en.wikipedia.org/wiki/C_alternative_tokens https://en.wikipedia.org/wiki/C_alternative_tokens] ...and no, they're not a good idea, its just a syntactic change. If you want a 'better-C', language-wise, Rust is pretty much best current hope, tho that wont mature for another decade or so.
- ci5er 10y ago
  Really? I haven't had a chance to dig into it and a quick google-based look-see didn't pop up immediately obvious results, but I would have thought that two areas where one would want to use C would include specific bit manipulation and explicit memory management. Both of those violate the high-level principles that I thought Rust was supposed to be about. So, either I was wrong (which happens more and more these days), or Rust has a work-around, or it's not a good fit for that last bastion of C use-cases. Thoughts?
  - steveklabnik 10y ago
    > specific bit manipulation Rust absolutely lets you work at the bit level, you can shift and mask just like in C. > explicit memory management It depends on what you mean by "explicit" here. Most Rust code has scope-based memory management, but you can also call malloc/free within an unsafe block.
    - ci5er 10y ago
      > but you can also call malloc/free within an unsafe block. Very cool. I was afraid I would be forced into an FFI type scenario (which Rust apparently has good support for anyway). Thanks!
      - steveklabnik 10y ago
        No problem. To elaborate on _this_ slightly, today in stable Rust you can call libc's malloc/free directly. There's also the Rust alloc::heap module, but it's not yet stable, and so is only available on nightly Rust https://doc.rust-lang.org/alloc/heap/index.html https://doc.rust-lang.org/alloc/heap/index.html
jagger11 10y ago
I wonder if this is in any way inspired by this - https://github.com/google/honggfuzz/blob/master/common.h https://github.com/google/honggfuzz/blob/master/common.h ? I use there defer for both gcc/clang, countof(arr) -> ARRAYSIZE(array) In any case, yeah, going through gcc/clang internals, and through C11 standards gives people some ways to speed-up and clena-up their implementations a bit.
catb0t 10y ago
It looks like just a cross between Go, DLang and maybe something else. Maybe I'll use it to troll my programming teacher.
approachingtraj 10y ago
This is so fucking stupid.
n_yuichi 10y ago
It reminds me of libCello http://libcello.org http://libcello.org

22nd Century C

130 points by Procedural 10y ago

TempleOSV409 10y ago

HolyC is from God.

em3rgent0rdr 10y ago

I don't get it. Could someone summarize/explain this.

eudox 10y ago
The included header file uses the macro system, among other things, to bring C99 up-to-date with more modern programming techniques, using what we've learnt in the past decades since C was conceived. In fairness however the short POD type names are purely cosmetic.
pqhwan 10y ago
I'm only guessing, but it looks like a C header file with a set of macros that produces neat-looking C code. Not sure what's the deal with the 22nd century thing.
- coldtea 10y ago
  Probably an answer to the "21st century C", an O'Reilly book about how to write modern C.
- PieterH 10y ago
  It's a clever joke and rather cynical deconstruction of our industry. The author suggests that in 100 years the C language will not only still exist and be widely used, it will have advanced almost nothing at all due to the industry's inability to solve real problems and instead focus on virtue signalling languages such as Clojure and Ruby. The author hammers home his point by demonstrating how a simple header file can at once render the code unreadable, while adding absolutely no value at all. I think he or she is specifically talking about Silicon Valley here, though of course since the joke is expressed in code, one can only guess. Seriously, I'd hope in 2100 we'd have pushed our systems languages beyond facile keyword redefinition. Maybe even towards concurrency and an actor model. Like I explored in my unfinished (sorry, shit happened) book "Scalable C". Or, Rust.

generic_user 10y ago

I'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. Its the one type of automatic memory management that you get for free and can't really screw up. The rest of the macro loops and so forth seem fairly standard. Its good to experiment and explore what you can do with the compiler and the preprocessor.

noobermin 10y ago
int double_address foo; /* ? */ Or is it n steps away from ProducerObserverFactoryStragedy?
- mdadm 10y ago
  You know there'll be that one person who complains about it not supporting something nested like 20 pointers deep...
- generic_user 10y ago
  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 Its nasty enough as it is without trying to name each pointer indirection.

dikaiosune 10y ago

fn main() { println!("hello, world"); } I kid, I kid. This looks cool!

microcolonel 10y ago

The "case" and "default" overrides seem kinda dicey.

Tim61 10y ago
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.
jonathankoren 10y ago
Yup. Congratulations kid. You broke fall-through, perhaps the biggest advantage of a switch over else-ifs.
abecedarius 10y ago
I defined the same macros but with different names, back when I still coded in C. I still think it's a good idea which tends to get reactions like "Ew! Wash your hands."

mieko 10y ago

I'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: "You know what, I'd like to make a decision as to the width of an integer every time I declare a function." "Just has to work" low level code was the norm during the 16-bit to 32-bit transition, so it was a fucking pain. Notice how smooth the 32-bit to 64-bit transition went? (and yes, it was smooth.) I credit that to high-level languages that don't care about this stuff, and people using better practices like generic word-sized ints and size_t's in lower level code. Keep that stuff on the borders of the application. I've noticed a decent-sized emphasis on type size in both Crystal and Swift, two not-entirely braindead newer languages. I don't get it, it's a big step backward.

lake99 10y ago
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.
- mieko 10y ago
  > 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.

Mathnerd314 10y ago

Too little too late. Rust is already taking over, by the 22nd century C will be dead.

Animats 10y ago
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.
- deleted 10y ago
  [deleted]
- petre 10y ago
  Dlang is actually quite nice and mature, although nowhere nearly as hyped as Rust, Go or Swift. You get a GC with the option of deactivating it and doing the memory management yourself, pointers and casts if you need them (you usually don't), an auto type, fast compiling times, among many other cool things. https://dlang.org/overview.html https://dlang.org/overview.html
kchoudhu 10y ago
I don't know what the systems programming language of the 22nd century will look like, but I do know that it will be called C.
- pjmlp 10y ago
  On UNIX yes, it will never change, C is married to UNIX and no alternative will ever change that. On other OSes, it really depends on how Apple, Google and Microsoft do their work of "our way or the highway" regarding pushing their safe alternatives.
  - 10y ago

alxmdev 10y ago

Very 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-Attributes.html https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attribute...

jagger11 10y ago
FYI - here's defer implementation for both gcc/clang - http://pastebin.com/EXZuRAdT http://pastebin.com/EXZuRAdT

cperciva 10y ago

You 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 <insert expansion here>; 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 https://gist.github.com/aras-p/6224951

dpc_pw 10y ago

That is very impressive. I really like the cleverness and cleanliness of these "hacks". Still... I wouldn't introduce it into existing/shared codebase due to risk of confusing everyone, and I will never start my own project in C again.

jdmoreira 10y ago

Maybe the author wanted this to be C99 compliant but a cool thing is that by using clang we even have lambdas. It's called blocks, the same as in Objective-C. http://clang.llvm.org/docs/BlockLanguageSpec.html http://clang.llvm.org/docs/BlockLanguageSpec.html I've been using them in all my new C code, since I'm stuck to clang anyway, and it's awesome.

transfire 10y ago

Still using header files in the 22nd century?

TickleSteve 10y ago

this is basically an updated version of iso646.h [https://en.wikipedia.org/wiki/C_alternative_tokens https://en.wikipedia.org/wiki/C_alternative_tokens] ...and no, they're not a good idea, its just a syntactic change. If you want a 'better-C', language-wise, Rust is pretty much best current hope, tho that wont mature for another decade or so.

ci5er 10y ago
Really? I haven't had a chance to dig into it and a quick google-based look-see didn't pop up immediately obvious results, but I would have thought that two areas where one would want to use C would include specific bit manipulation and explicit memory management. Both of those violate the high-level principles that I thought Rust was supposed to be about. So, either I was wrong (which happens more and more these days), or Rust has a work-around, or it's not a good fit for that last bastion of C use-cases. Thoughts?
- steveklabnik 10y ago
  > specific bit manipulation Rust absolutely lets you work at the bit level, you can shift and mask just like in C. > explicit memory management It depends on what you mean by "explicit" here. Most Rust code has scope-based memory management, but you can also call malloc/free within an unsafe block.
  - ci5er 10y ago
    > but you can also call malloc/free within an unsafe block. Very cool. I was afraid I would be forced into an FFI type scenario (which Rust apparently has good support for anyway). Thanks!
    - steveklabnik 10y ago
      No problem. To elaborate on _this_ slightly, today in stable Rust you can call libc's malloc/free directly. There's also the Rust alloc::heap module, but it's not yet stable, and so is only available on nightly Rust https://doc.rust-lang.org/alloc/heap/index.html https://doc.rust-lang.org/alloc/heap/index.html

jagger11 10y ago

I wonder if this is in any way inspired by this - https://github.com/google/honggfuzz/blob/master/common.h https://github.com/google/honggfuzz/blob/master/common.h ? I use there defer for both gcc/clang, countof(arr) -> ARRAYSIZE(array) In any case, yeah, going through gcc/clang internals, and through C11 standards gives people some ways to speed-up and clena-up their implementations a bit.

catb0t 10y ago

It looks like just a cross between Go, DLang and maybe something else. Maybe I'll use it to troll my programming teacher.

approachingtraj 10y ago

This is so fucking stupid.

n_yuichi 10y ago

It reminds me of libCello http://libcello.org http://libcello.org