Article: MAQSIP-RT: An HPC Benchmark
By: gallier2 (gallier2.delete@this.gmx.de), July 1, 2010 11:14 pm
Room: Moderated Discussions
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.
---------------------------
>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.
Topic | Posted By | Date |
---|---|---|
New article online: MAQSIP RT | David Kanter | 2010/06/21 10:57 AM |
Why no GCC? | Rohit | 2010/06/22 08:25 PM |
Why no GCC? | David Kanter | 2010/06/22 11:45 PM |
sun 's cc better than GCC? | Rohit | 2010/06/23 04:04 AM |
sun 's cc better than GCC? | anon | 2010/06/23 06:49 AM |
Where is the GCC optimization effort directed? | Mark Roulo | 2010/06/23 09:42 AM |
GCC is very ugly bad everywhere in 64 bits | Vincent Diepeveen | 2010/06/23 01:49 PM |
even for 64-bit arch? | anon | 2010/06/23 01:59 PM |
GCC is very ugly bad everywhere in 64 bits | ajensen | 2010/06/23 10:03 PM |
GCC is very ugly bad everywhere in 64 bits | Gabriele Svelto | 2010/06/24 01:33 AM |
GCC is very ugly bad everywhere in 64 bits | ajensen | 2010/06/24 04:32 AM |
GCC is very ugly bad everywhere in 64 bits | Gabriele Svelto | 2010/06/24 06:18 AM |
GCC is very ugly bad everywhere in 64 bits | ajensen | 2010/06/24 08:50 AM |
Why GCC is big and complicated (my guess) | Mark Roulo | 2010/06/24 11:17 AM |
Why GCC is big and complicated (my guess) | Gabriele Svelto | 2010/06/28 03:00 AM |
GCC is very ugly bad everywhere in 64 bits | Bernd Schmidt | 2010/06/24 04:46 AM |
GCC is very ugly bad everywhere in 64 bits | ajensen | 2010/06/24 08:43 AM |
GCC is very ugly bad everywhere in 64 bits | Vincent Diepeveen | 2010/06/26 01:12 PM |
GCC is very ugly bad everywhere in 64 bits | Rob Thorpe | 2010/06/24 06:47 AM |
GCC is very ugly bad everywhere in 64 bits | Anon | 2010/06/24 04:23 PM |
Where is the GCC optimization effort directed? | Gabriele Svelto | 2010/06/23 09:45 PM |
Where is the GCC optimization effort directed? | ? | 2010/06/24 12:48 AM |
Where is the GCC optimization effort directed? | Gabriele Svelto | 2010/06/24 01:29 AM |
Where is the GCC optimization effort directed? | ? | 2010/06/24 02:13 AM |
Where is the GCC optimization effort directed? | Andi Kleen | 2010/06/24 02:15 AM |
Where is the GCC optimization effort directed? | ? | 2010/06/24 03:08 AM |
Where is the GCC optimization effort directed? | Gabriele Svelto | 2010/06/24 02:54 AM |
Where is the GCC optimization effort directed? | ? | 2010/06/24 03:15 AM |
Where is the GCC optimization effort directed? | Gabriele Svelto | 2010/06/24 06:22 AM |
Where is the GCC optimization effort directed? | Rohit | 2010/06/24 02:04 AM |
Placebo effect | ? | 2010/06/24 05:37 AM |
Placebo effect | Rohit | 2010/06/24 07:45 AM |
Placebo effect | Vincent Diepeveen | 2010/06/26 01:50 PM |
Compile time | Mark Roulo | 2010/06/26 04:28 PM |
Compile time | Richard Cownie | 2010/06/27 03:44 AM |
Compile time | Mark Roulo | 2010/06/27 09:12 AM |
Compile time | Mark Roulo | 2010/06/27 09:21 AM |
Compile time | EduardoS | 2010/06/27 10:37 AM |
Compile time | Richard Cownie | 2010/06/27 03:07 PM |
Compile time & efficiency | ? | 2010/06/27 11:03 PM |
Compile time & efficiency | Mark Christiansen | 2010/06/28 05:08 AM |
Compile time & efficiency | Linus Torvalds | 2010/06/28 06:48 AM |
kernel programming language | John Simon | 2010/06/29 05:46 PM |
Compile time & efficiency | Richard Cownie | 2010/06/28 08:29 AM |
Compile time & efficiency | Linus Torvalds | 2010/06/28 10:17 AM |
Compile time & efficiency | Richard Cownie | 2010/06/28 01:16 PM |
Compile time & efficiency | Richard Cownie | 2010/06/28 05:23 PM |
Compile time & efficiency | Mark Roulo | 2010/06/29 07:31 AM |
Compile time & efficiency | Richard Cownie | 2010/06/29 10:48 AM |
Compile time & efficiency | rwessel | 2010/06/29 11:28 AM |
C is a crappy | dev | 2010/06/29 06:12 PM |
C is a crappy, but only when you push it out of it's niche | Rohit | 2010/06/30 01:11 AM |
C is a crappy | anon | 2010/06/30 01:17 AM |
C is a crappy | dev | 2010/06/30 06:59 AM |
C is a crappy | Max | 2010/07/01 03:30 AM |
C is a crappy | Michael S | 2010/07/01 06:00 AM |
C is a crappy | Konrad Schwarz | 2010/07/01 07:02 AM |
C is a crappy | Michael S | 2010/07/01 07:50 AM |
C isn't so crappy | anon | 2010/07/01 09:11 AM |
C isn't so crappy | Mikael Tillenius | 2010/07/01 10:39 AM |
C is a crappy | Konrad Schwarz | 2010/07/01 10:22 AM |
C is a crappy | Max | 2010/07/02 07:44 AM |
C is a crappy | rwessel | 2010/07/02 11:33 AM |
C is a crappy | anon | 2010/07/02 12:17 PM |
C is a crappy | Max | 2010/07/02 01:56 PM |
C is a crappy | Max | 2010/07/02 02:13 PM |
C is a crappy | rwessel | 2010/07/02 02:32 PM |
C is a crappy | Max | 2010/07/02 03:19 PM |
C is a crappy | Gabriele Svelto | 2010/07/05 04:25 AM |
C is a crappy | gallier2 | 2010/07/01 11:14 PM |
C is a crappy | Ian Ollmann | 2010/07/06 02:07 PM |
Portability | Max | 2010/07/06 02:37 PM |
C is a crappy | hobold | 2010/07/07 01:31 AM |
C is a crappy | Ian Ollmann | 2010/07/07 04:18 PM |
failure to standardize types | Carlie Coats | 2010/07/07 03:11 AM |
C is a crappy | Konrad Schwarz | 2010/07/07 07:34 AM |
C is a crappy | Ian Ollmann | 2010/07/07 04:29 PM |
C is a crappy NOT | Konrad Schwarz | 2010/07/07 11:29 PM |
C is a crappy | anon | 2010/07/01 09:40 PM |
C type safety | ? | 2010/07/02 12:10 AM |
C type safety | anon | 2010/07/02 10:02 PM |
C is a crappy | dev | 2010/07/03 03:51 PM |
C is a crappy | anon | 2010/07/03 06:02 PM |
C is a crappy | dev | 2010/07/05 06:27 AM |
C is a crappy | ? | 2010/07/05 08:05 AM |
C is a crappy | anonymous | 2010/07/07 07:32 AM |
C is a crappy | ? | 2010/07/07 09:48 PM |
C is a crappy | Anon | 2010/07/07 11:53 PM |
C is a crappy and a crappie is a fish | anonymous | 2010/07/03 06:24 PM |
Compile time & efficiency | Michael S | 2010/06/29 02:18 AM |
Compile time & efficiency | rwessel | 2010/06/29 11:20 AM |
Compile time & efficiency | someone | 2010/06/30 10:03 AM |
Compile time & efficiency | Jouni Osmala | 2010/07/02 04:29 AM |
Compile time & efficiency | Max | 2010/06/28 04:05 PM |
Compile time & efficiency | EduardoS | 2010/06/28 04:11 PM |
Compile time & efficiency | Michael S | 2010/06/29 02:33 AM |
Compile time | Foo_ | 2010/06/28 08:03 AM |
sun 's cc better than GCC? | Silent | 2010/06/23 05:19 PM |
sun 's cc better than GCC? | Foo_ | 2010/06/23 06:06 PM |
sun 's cc better than GCC? | Andi Kleen | 2010/06/24 01:49 AM |
sun 's versus gcc | Vincent Diepeveen | 2010/06/23 02:07 PM |
Why no GCC? | Carlie Coats | 2010/06/23 04:11 AM |