[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: GCC's statement expression extension
From:       Phil Edwards <pedwards () disaster ! jaj ! com>
Date:       2000-07-31 16:33:19
[Download RAW message or body]


Linus Torvalds <torvalds@transmeta.com>:
[beyond-the-standards argument]
> Now, that does NOT mean that every extension should be considered a good
> one. I'm not arguing anything like that. But I do think that your
> standpoint that "it is an extension so it must be bad" is narrow-minded
> and ultimately stupid. Extensions must be judged on _other_ criteria.

I'm all for extensions for languages, as long as their default mode is off.
But the "extension == bad" criterion isn't the one being applied here.
One of the other criteria of which you speak is "does it even make sense
to do this, and can we do it in a rational manner?"

Statement expressions mostly fail that criterion for C++.  Certainly it can
be argued that it makes sense to add S.E. to C++ (I would argue against it,
but at least both sides have an arguement).  I don't think it can be done
in a way that works well; the rules for C++ are a bit more complicated
than those of C.

And as others have pointed out, adding S.E. to C gains you something.
Adding them to C++ gains you nothing, but costs you something.  At least,
adding them /in their present form/.


> But I do understand the problem: if you want to make statement expressions
> illegal in C++ (which I have no real opinion of - it's a language I don't
> care for), you're screwing up one of the original advantages of C++: the
> backwards compatibility with a language I _do_ care about, and one that I
> want to see live on rather than die the horrid death of being forever
> entomed in the cobwebs of standardization.

Not a valid argument, sorry.  C++ has as one of its goals backwards
compatibility with C.  It's not required to be sideways compatible with
things added to C (like, say, some of the stuff added to C99) after the fact.

If glibc wants to be useable under two languages, then it has to restrain
itself to the common denominator.


> Could somebody explain why C++ has so many problems with statement
> expressions? Maybe there is some solution to this - something that might
> involve a form of statement expression-like behaviour that works on both C
> and C++?

A bunch of the "technical reasons why not" have been hashed out on the
list since your message.  As far as a middle ground... hmm.  I like the
idea of improving on S.E. so that they're acceptable to both languages.
The semantics for S.E. under C++ are still just going to be ass-nasty
however they work.  Maybe some variation on the C99 inline functions.

And I suspect that the glibc headers would still have to be rewritten,
because some people like to write portable code, and use "-ansi -pedantic"
to help test for GCC-isms.  The glibc implementation, of course, could be
written purely in extensions and it wouldn't bother anybody.


Phil

[prev in list] [next in list] [prev in thread] [next in thread]