Michael S (already5chosen@yahoo.com) on 7/1/10 wrote:
---------------------------
>Max (max@a.com) on 7/1/10 wrote:
>---------------------------
>>I didn't really "get" C until I had written a medium size (10K line) program in
>>assembly. At the end I realized that C would have been a better choice...more productive/maintainable,
>>2x larger size code (acceptable), and no material performance difference except for a few critical bits.
>>
>>C is pretty uncontroversial these days. It's hard to even get an argument started
>>since everyone has made their peace with it.
>>
>>Max
>>
>
>There are few bits in 'C' syntax that have absolutely no justification except of
>backward compatibility with [hopefully] very small subset of existing code base.
>They are:
>1. Legality of functions without prototypes.

Agreed, but warnings do mitigate that problem

>2. Legality of strange syntax constructs like 5[x]

It's not strange at all and is a consequence of the pure simplicity (and elegance) of the C pointer concept. The a[b] is only a syntactic variation of *(a+b) and by consequence of the comuutativity property of addition absolutely equivalent to *(b+a) thus also to b[a] . It's imho elegant and pragmatic to not add more code in the compiler to disallow that.

>3. Inconsistency w.r.t. comma-delimited lists. In some contexts (struct/array initialization)
>comma as a terminator is allowed (at least by all compilers I use) while in some
>other contexts (function parameters lists, both in call and in prototype) it is
>not. Not a big deal for human coders, but unnecessary annoyance for code generators.

I don't where the behaviour of the supplemental comma in initializers comes from but it is quite practical when editing. Initializers can sometimes be really big, function parameters are rarely, so it's not an issue when coding manually.

>
>Another syntax ugliness which, if fixed, would break a bit more code, but not that
>much is a requirement to define variables at the beginning of the block. gcc dialect already has it fixed.

ANSI C99 also. This said, from my experience it's not a big deal, lone declarations of variables in the code happen not that often and are not really a good idea in the first place and when it is a good idea to have some more local variables in a narrower scope, it happens that one can put a {} block around without hassle (it's almost always within a loop or an if/else construct, and adding a {} in a switch/case doesn't harm readability). YMMV

>
>And finally the biggest unnecessary problem, which, unfortunately, if fixed, will
>break a lot of legacy code, in particular in mixed C/ASM environments - type-safe
>link. In my book, omission of type safe link alone is big enough reason to never
>use 'C' if C++ is supported by your environment.
>
Never had a problem with that but I can imagine how it can be a problem.