On Wed,  5 Jun 2002 15:23:56 GMT, Daniel Frey <daniel.frey@aixigo.de>
wrote:

>Francis Glassborow wrote:
>>
>> Well if you were to redesign a selection mechanism why not do it
>> properly and allow such things as
>> case X,Y,x,y :
>
>See my other post written 5 seconds before I read yours... :)
>
>> And if we are going to mess with this why not have a 'for' that is
>> applied to a comma separated list such as:
>> for(int i = {1,4,7,11}) do something
>
>Cool idea. And why not:
>
>  enum Foo { IS, THIS, A, GOOD, IDEA };
>
>  for( Foo f = Foo ) { ... }
>
>as a shortcut for
>
>  for( Foo f = { IS, THIS, A, GOOD, IDEA } ) { ... }
>
>It is far better to maintain if you just say "iterate all Foo's" with
>your code instead of "iterate *these* Foo's: A, B, C, ...".

Let me intervene here with a remark concerning the whole "C++0x wish
list" explosion on this group. These are just some thoughts I want to
discuss with all of you.

I like Francis' idea. It's simple and smart and would be IMHO a nice
addition to C++. Anyhow you can't implement with it something that
requires some code to be between a case label and the following one,
like in a Duff's device. Yes, we would still keep the old syntax of
course.

But I want to stress an important fact: the feasibility of such a
solution is a lucky circumstance. There are things in C++ that
probably can never be "perfected" as desired; that's because of the
strong, almost total, compatibility with C that Bjarne Stroustrup
decided to give to his new creature: when there were "conflicts"
between choosing the best (most readable, easy to maintain, etc.) form
and the C-compatible form he always, intentionally, chose the latter.
Therefore he injected into the language the result of *other* design
goals. What design goals?


The C language assumes the programmer *knows* what he is doing: the
compiler looks at it and obeys. Many of the criticisms that concern,
for instance, allowing 'if (a = b)' or to the syntax of declarations
address something that the C designer(s) were aware of. They simply
chose the most concise way. "We have to be careful" - they knew - "and
we'll be, what is important is that we have a useful tool". Usefulness
that probably had to be proved on the ground for the designers
themselves, BTW; see the article "The Development of the C Language"
at D. Ritchie's homepage where he says: "Writing the Unix kernel in C
had given us enough confidence in the language's usefulness and
efficiency that we began to recode the system's utilities and tools as
well." Moreover he states: "In spite of its difficulties, I believe
that the C's approach to declarations remains plausible, and am
comfortable with it" The word 'comfortable' here is the IMHO the key:
in one sense, he invented the language for himself! For instance (I'm
not joking) the following is extremely readable to me (now that I know
what it means, not when I didn't even read K&R).


   void copy (char * d, const char * s) {

       while (*d++ = *s++)
           ;
   }

at the point that I need a little effort to show a less stenographic
form when someone asks me how to make a copy of null-terminated
strings.


When we say, _now_, that x = x +1 can be translated exactly like ++x
it is because we can now afford compilers that weren't even imaginable
(yes, I mean 'implementable' but also 'conceivable') at those times
(see what the PDP-7 was). So, probably, if C was invented today the
auto-increment wouldn't have been introduced (if not for the fact that
the meaning of ++x ("increment x") is somewhat more natural than "take
x, increment its value and reassign that value to x", but the latter
is so "ingrained" in the mind of a programmer that he probably feels
more at home with it)

Programmers, like languages, are sons of their time.
_Now_ we ask things like "Is it correct to put all the #include at the
beginning of a file? Is it ok to put the const-qualifier at the
left?". Probably  (well I suppose, I was not even born when C was
invented! :)) in the times when C was created we would have smiled at
this. Be careful: I'm not saying these are stupid questions but this
is what we say _now_: we must recognize that these questions are
someway the result of our "culture" and use of the language.


The same "change" of mentality has happened, IMHO, with C++: if we
asked a few years ago while C++ doesn't have compile-time assertions
the answer would probably be: "Because it's easy to implement them!".
Think to the whole bag of gadgets of the Loki library we want to put
now into the language. Why no threads? - Because not all systems have
them. See what we says now.


In conclusions, it seems to me that times change, and (fortunately)
programmers too. Our aim is to improve what we have, but sometimes we
can't. Otherwise we have to throw away the old stuff, and re-create
everything from scratch (which would be, I think, another error).

This is my opinion; I hope others will share theirs.


    "If I give you a coin and you give one to me, at the end we
      will have one coin each; but if I give you an idea and you
     give one to me, at the end each one will have two ideas"
                                                      (unknown author)



Genny.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]