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