22nd Century C

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.

Re: 22nd Century C

#5

Post by pqhwan » Sun, Sep 11, 2016, 3:13 AM UTC

em3rgent0rdr wrote: post #3

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

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.

Re: 22nd Century C

#6

Post by generic_user » Sun, Sep 11, 2016, 3:23 AM UTC

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.

Re: 22nd Century C

#7

Post by dikaiosune » Sun, Sep 11, 2016, 3:44 AM UTC

    fn main() {
        println!("hello, world");
    }

I kid, I kid. This looks cool!

Re: 22nd Century C

#8

Post by microcolonel » Sun, Sep 11, 2016, 4:08 AM UTC

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

Re: 22nd Century C

#9

Post by mieko » Sun, Sep 11, 2016, 4:13 AM UTC

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.

Re: 22nd Century C

#10

Post by noobermin » Sun, Sep 11, 2016, 4:17 AM UTC

generic_user wrote: post #6

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. It…

   int double_address foo; /* ? */

Or is it n steps away from ProducerObserverFactoryStragedy?