Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Why learn C? (O'Reilly Radar)
Posted Jun 29, 2012 23:38 UTC (Fri) by HelloWorld (guest, #56129)
I don't know why I'm even responding to this, given that you're calling me a troll without any justification.
Anyway, the main problem with C is its declaration syntax. Let's take a declaration like
void (*signal(int, void(*)(int)))(int);
void signal(int, void*(int))*(int);
signal(int, *(int)void) *(int) void
Another problem with the C syntax is that in function parameter declarations, foo means the same as foo*, while everywhere else it doesn't. People keep confusing arrays and pointer due to this (though the implicit conversion from foo to foo* also promotes this).
I also find it ugly that while both :? and if/else exist, there is only a switch statement and not a switch expression.
Posted Jun 30, 2012 17:48 UTC (Sat) by tjc (subscriber, #137)
That's going to be hard to parse. The lexer is going to return a token with the value "signal", but the parser is going to be sitting at the top level without any context in which to evaluate it. If it's not a reserved word then it must be an identifier, but nothing else is known about it without peeking further ahead into the input stream.
Something like this would be more practical:
func signal(int, *(int)void) *(int)void
I personally don't mind that C (and C-like languages) anchor declarations with the type. It's still a left-to-right parse, with the single exception of the type. The "var|func ... <complete return type>" syntax is probably better, but I've been looking at "<type> ..." for so long that it seems natural to me. It also allows you to do things like this:
int i, j;
As far as the foo * vs. foo thing, that's not really a syntax problem, it's a semantic problem, given that arrays decay to a pointer to the first element in most (but not all; e.g. sizeof(foo)) cases. I agree that that could be changed, and it would be better in most cases. I usually write array parameters as foo *, just because that's what they really are inside the function.
I'm not aware of the difference between a switch statement and a switch expression, so I can't comment on that. I guess I better start "googling."
Posted Jul 1, 2012 11:15 UTC (Sun) by HelloWorld (guest, #56129)
The only problem I see with this syntax is that it's ambiguous: there's no way to know whether foo(bar)*baz; is a declaration or a statement without looking at the preceding declarations in order to find out whether bar and baz are variables or typedef-names. Alas, conventional C syntax has the same problem in declarations such as the above-mentioned foo *bar;.
It's also fairly easy to disambiguate it using a syntax such as
That would clash with the goto label syntax, as foo: bar; is valid C code. However, this is not a problem: bar; is a statement without effect, so there's no point in writing code like that, therefore a line like that should be parsed as a declaration.
Posted Jul 1, 2012 22:30 UTC (Sun) by tjc (subscriber, #137)
Posted Jul 1, 2012 22:49 UTC (Sun) by HelloWorld (guest, #56129)
Posted Jul 1, 2012 23:02 UTC (Sun) by tjc (subscriber, #137)
Posted Jul 1, 2012 23:20 UTC (Sun) by HelloWorld (guest, #56129)
Posted Jul 2, 2012 20:36 UTC (Mon) by tjc (subscriber, #137)
Posted Jul 2, 2012 21:23 UTC (Mon) by HelloWorld (guest, #56129)
Posted Jul 3, 2012 15:46 UTC (Tue) by tjc (subscriber, #137)
Posted Jul 1, 2012 22:59 UTC (Sun) by tjc (subscriber, #137)
I should have said, "I can't think of a situation in C where a statement that begins with a type specifier...."
Posted Jul 2, 2012 9:30 UTC (Mon) by nix (subscriber, #2304)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds