>>>>> David Binderman <dcb@lovat.fmrco.com> writes:

>> When the rules change every few months, sometimes the repercussions
>> don't quite get propagated to the dark corners of the compiler.

> When the rules have been written down in black and white for four years,
> and we're still waiting for most vendors to implement the rules, then
> that makes C++ much less attractive to lots of customers.

> Leaving aside what the ANSI gruppe have done with C++ since 1990.

But you can't leave that aside.  What has been done since 1990 includes the
most recent printing of the ARM (May 1992).  If you want to leave aside
what has been done since 1990, you're leaving out a significant portion of
the ARM.

And in any case, a lot of the work the committee has been doing since the
last printing of the ARM is fixing rules in the ARM that just don't work.
Things like operator overloading; until the September 1994 Working Paper,
the presence of *any* user-defined operator+ would prevent an addition
involving an operand of class or enumerated type from matching the built-in
definitions.  Everyone agrees that this is wrong.

Jason

In article <1994Sep28.084346.14157@fmrco.uucp> dcb@lovat.fmrco.com
(David Binderman) writes:

|> I'm gradually coming round to the opinion that for large scale (>20
|> developers) programming, 80% of the benefit of C++ over ISO C is just being able
|> to have typesafe C and objects ( no inheritance, no templates, no EH).

I think that this is more a comment on the training of the current
bunch of C++ programmers, rather than a comment on C++ itself.

I personally find that a class without virtual functions is the
exception (except for the very low level things like linked lists,
safe arrays, string, etc.).  I'd guess that well over 95% of the
classes I write at the application level are polymorphic.

This does require attacting the problem from a different angle.  There
is no sense in using inheritance if your basic design is still
procedural.  OO is a new paradigm (to most people); to use it
effectivly means changing your way of thinking, just as using any
other new paradigm (say functional programming) does.  (I might add
that based on my experience, of the three common paradigms,
procedural, functional and object oriented, procedural is the least
powerful, but the most used.)
--
James Kanze      Tel.: (+33) 88 14 49 00     email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article 94Sep27152354@deneb.cygnus.com, jason@cygnus.com (Jason Merrill) writes:
>Assuming, of course, that the compiler is written in C++.  g++, for one,
>isn't.  Are there any others?

Yes.

>I think that the low quality of most available compilers is due primarily
>to the complexity and fluidity of the language.

Agreed.

I'm gradually coming round to the opinion that for large scale (>20
developers) programming, 80% of the benefit of C++ over ISO C is just being able
to have typesafe C and objects ( no inheritance, no templates, no EH).

I think the law of dimishing returns comes into play here.

>When the rules change
>every few months, sometimes the repercussions don't quite get propagated to
>the dark corners of the compiler.

When the rules have been written down in black and white for four years, and we're
still waiting for most vendors to implement the rules, then that makes
C++ much less attractive to lots of customers.

Leaving aside what the ANSI gruppe have done with C++ since 1990.


Regards

David C Binderman MSc BSc      +44 171 975 4723         dcb@lovat.fmrco.com
Academy Programming Ltd   the C++ on UNIX specialists      +44 129 354 4364

In article <1994Sep22.110602.27683@leeds.ac.uk> garyt@resumix.portal.com (Gary Thompson) writes:
|> So rather than rejecting these features just by their names and their
|> association with Lisp, I suggest you evaluate these issues carefully
|> and from a technical point of view; there have been several papers
|                                                      ^^^^^^^^^^^^^^^
|> describing the extensions--look them up and make specific criticism.
|> In fact, even among many people that opposed the inclusion of the
|> above features in the standard, many of them seem to agree that they
|> are fundamentally useful and important.  Standards committees rarely
|> make choices only based on technical merit.
|
|any references ???