On (22 Jul 97) Sunir Shah wrote to Darin Mcbride...
 SS> To: Darin Mcbride
 SS> Subject: Sunir ventures into C++
 DM> int bar::foo(void) const;
 DM> (since there is a "hidden" bar* parameter being passed in, in
 DM> this case it's being changed to bar* const)
 SS> Oh, right.. that would make sense. ;)
More accurately, it's being changed to `bar const *const' - `this' is
always of type `FOO *const', (I.e. you can't assign to `this' itself) by
in the case of a const member function, `this' points to a const object
as well, so you can't assign to members unless 1) you cast away the
cont, or 2) the member is mutable.
 SS> The difference is that Microsoft, Borland, Symantec, etc. can change
 SS> their implementation any time they want and force it into the draft
 SS> proposal because they have so many on-siders on the committee.  And
 SS> if they don't, the other compiler manufacturers will copy their new
 SS> fun features just to remain competitive.
Nonsense.  Nearly every major compiler vendor has at least one
representative on the committee.  If you think any single vendor, or
small group of vendors has ever, or will ever, "force" their own ideas
into the draft, you're basically nuts.  The rest of the committee
consists primarily of their competitors so if anything, they're likely
to reject sound ideas of they're suggested by one of the bigger vendors.
Just to give an example, MS representation came up with a proposal for
allowing overloading of the . operator in a reasonable fashion.  All the
best gurus of C++ admit that it's technicall sound and feasible.  But
it's NOT in the current draft of the standard, and NOT even being
considered for this round of standardization.  It's open to question
whether it'll ever be given serious consideration.
 SS> ANSI C is almost rock solid.  And the standard won't change in such a
 SS> way to break legacy code (i.e. stuff I wrote yesterday) whereas C++
 SS> might if it sells more shiny packages.
The C++ committee has a mandate to remain as compatible with C as
possible without breaking the language.  They've managed to retain
compatibility with the vast majority of C programs as long as they
include prototypes for functions and few things like that.  It's a bit
harder to say exactly how much old C++ code they might have broken.
Since there isn't a standard yet, it's easy to sit back and say that
anything that doesn't work never was C++, though that's not exactly
practical.  However, I've been writing C++ for a LONG time now, and I
can't remember rewriting much to work with newer compilers at all.
OTOH, I'm not stupid about things either.  When the committee says "This
is a brand new feature, and we're likely to change it somewhat before
it's finished." I generally avoid that feature, or at least use it only
in relatively simple ways that everybody agrees upon.  Some vendors seem
to feel obliged to implement every new feature, long before everybody
(or anybody) agrees upon even the final form of the feature.  Some users
seem to feel obliged to buy the compiler that claims the greatest
conformance with the latest standard, and to use absolutely the latest
features, even when they don't necessarily make sense.
Needless to say, these people who insist that life on the bleeding edge
is the best tend to pay a bit for it.
 SS> I'm actually just complaining because C++ is not even close to C any
 SS> more.  I was expecting something a little closer, but not at all...
 SS> I figure I could just consider C++ a new language and learn it
 SS> from scratch... that'd probably help me learn it faster/less
 SS> painfully.
It might.  C++ can be a lot like C if you want to use it that way.  It
can also be a fundamentally different language with a similar syntax if
you want to use it that way.
    Later,
    Jerry.
... The Universe is a figment of its own imagination.
--- PPoint 1.90
---------------