Of course, the important stuff is there. People care about "static inline", member/array initializers, "long long", and "restrict". Nobody gives a damn about wchar_t unless they were duped into using it the first time around.
C1x
Thread local variables are handy and the _Atomic type qualifier might be useful too.
I'm all for standardizing (what are currently) compiler extensions to C - people probably won't abuse these features, it just avoids some platform specific code.
Out of the C99 add-ons I use only the long longs, Sepples comments, macros of variable arity, and variable-length arrays, and I don't feel like using an incomplete language just to have these.
Name:
Anonymous2010-08-29 11:04
C99, because why would I want to declare my variables at the start of every scope?
Though lately I've been using cl.exe so I was restricted to whatever standard of C that uses.
>>19 C99, because why would I want to declare my variables at the start of every scope?
So you can keep better track of the stack, instead of littering your code with random variables like some PHP skiddy.
>>27 i != 100;
I don't think you're even a programmer!
Name:
Anonymous2010-08-29 17:05
>>29
Your homework for tonight is to compile it and write a one page essay on how the not-equals operator has increased staff synergy and leveraged industry best practices at software startups using Java and VB.NET.
>>34 implying anyone on /prog/ still has an intact anus.
Name:
Anonymous2010-08-29 18:56
While we're on this topic, I kindly request the EXPERT C denizens of /prog/ to explain this bullshit[1]: (double (^)(int , long long))foo
``cast foo into block(int, long long) returning double''
>>41
Text input is text, and numbers are numbers. Anything more complex than that is sent to a library.
Name:
Anonymous2010-08-30 9:25
>>43
Then how does the library deal with dynamic input?
Name:
Anonymous2010-08-30 10:50
C#
Name:
Anonymous2010-08-30 13:06
>>45
crappy proprietary language with platform lock-in is crappy
Name:
Anonymous2010-08-30 13:26
C99. The features I use over C89 are mixed declarations (and for loop declarations), inline, restrict, sepples comments, incomplete structs, and variadic macros.
Name:
Anonymous2010-08-30 13:27
>>47
Oh also, I use -Wc++-compat so it can be compiled as sepples on a certain compiler that doesn't support C99... :(
The only defensible aspect of C99 is the restrict keyword. I don't agree that it should be the programmer's job to micromanage compilers like that (and I'm violently opposed to the inline keyword), but having compilers figure this out automatically is equivalent to solving the halting problem.
Anyone who uses Sepples comments should be shot, by the way.
Name:
Anonymous2010-08-30 15:21
The only defensible aspect of C99 is the restrict keyword.
What's wrong with designated initializers, compound literals, and exact-width integer types?
>>50 designated initializers
If you're going to initialise something, initialise all of it. If you can't, it shouldn't be a single entity.
compound literals
They're less readable than doing the same thing with named functions or macros, because they overlap with existing syntax. They provide no benefit, they just make bad code cheaper.
If you're going to initialise something, initialise all of it. If you can't, it shouldn't be a single entity.
So you're saying struct some_struct x;
x.a = &a;
x.b = NULL;
x.c = NULL;
x.d = NULL;
is better than struct some_struct x = { .a = &a };
?
They're less readable than doing the same thing with named functions or macros, because they overlap with existing syntax.
Sure, int a[] = { 1, 2, 3, 4, 5 };
/* 5 completely unrelated lines of code */
some_function(a);
is so much more readable than some_function((int [5]){ 1, 2, 3, 4, 5 });
POSIX already provided these.
Not everyone wants all of POSIX, and exact-width integer types are very useful.
>>55 So you're saying struct some_struct x; x.a = &a; x.b = NULL; x.c = NULL; x.d = NULL;
is better than struct some_struct x = { .a = &a };
?
No, I'm saying both are signs of profound incompetence, and providing syntactic sugar to do it is retarded.
Sure, int a[] = { 1, 2, 3, 4, 5 }; /* 5 completely unrelated lines of code */ some_function(a);
is so much more readable than some_function((int [5]){ 1, 2, 3, 4, 5 });
You're an idiot who can't read.
Not everyone wants all of POSIX, and exact-width integer types are very useful.
Every single platform provides them already. I said POSIX because that's what every sensible person uses anyway. Nobody gives a fuck about Windows users, and Windows users don't use C.
And embedded programmers are a red herring. You aren't one and don't know any.
>>62
And C99-style {.a = &a} breaks when someone changes the type of .a. What's your point? If you break things, things are going to break.
Really, they should break.
>>64-chan, structs aren't dictionaries. It's not reasonable to expect them to behave as dictionaries. If you want that kind of behavior, stick to high-level languages.
>>67
Has anyone ever told you that you are not a very good troll? They probably didn't want to hurt your feelings, but someone really should have said something. The next time you see your friends, tell them it's not cool to let you continue to make a fool out of yourself.
>>69
Do we really have to have this discussion again? The C preprocessor and the C language are two different things.
And the argument you're about to try to make that a lot of compilers remove C language comments in the preprocessor rather than in the compilation stage is missing the point entirely.
>>72
The argument I'm about to make is that you're an ignorant buffoon who don't know what you're talking about, and that the distinction that you are trying to make is one which neither compiler writers nor users care one iota about, leaving you quite alone.