In article <CCxIHp.1qM@pmsr.philips.co.uk> david.binderman@pmsr.philips.co.uk (Dave Binderman) writes:
>
>I advocate a staged approach to language standardisation. Level 0
>is ARM chapters 1-13, Level 1 adds templates, Level 2 adds exceptions,
>and Level 3 is anything in the current ANSI spec, but not in the ARM.
>
>This way, we don't have to wait until 95 or 96 to get reliable compilers.

In my opinion, your solution really won't help.

Existing C++ compilers are often unreliable even when it comes to the
occasional things about which the ARM is perfectly clear and precise.

In other words, I can assure you that it will NOT be the case that all
existing C++ compilers will magically become totally reliable the day
after we have an approved international standard for C++.  That just
won't happen.

What is clearly needed is more testing (and better testing) by the
implementors (rather than by the end users) of C++ compilers.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <26546@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:
>
>
>david.binderman@pmsr.philips.co.uk (Dave Binderman @ Philips Medical Systems - Radiotherapy) writes
>
> > Part of the problem is the sheer complexity of C++, hence a 450 page
> > reference manual.
>
>Correction:
>
> The C++ reference manual as it appears in the ARM and in
> The C++ Programming Language (2nd Edition) is 157 pages.

Given that more than a few details were left out of those "reference manuals",
I think that it is safe to say that the number 157 is rather irrelevant in
any discussion of the size and complexity of the language.

A more relevant issue is how big the final international C++ standard
document will be.  Care to hazard a guess?  Will it be 600 pages?  800?
1000?  More?

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgCDJGpJ.AF@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>>I advocate a staged approach to language standardisation. Level 0
>>is ARM chapters 1-13, Level 1 adds templates, Level 2 adds exceptions,
>>and Level 3 is anything in the current ANSI spec, but not in the ARM.
>>
>>This way, we don't have to wait until 95 or 96 to get reliable compilers.
>
>In my opinion, your solution really won't help.
>
>Existing C++ compilers are often unreliable even when it comes to the
>occasional things about which the ARM is perfectly clear and precise.
>
>In other words, I can assure you that it will NOT be the case that all
>existing C++ compilers will magically become totally reliable the day
>after we have an approved international standard for C++.  That just
>won't happen.
>
>What is clearly needed is more testing (and better testing) by the
>implementors (rather than by the end users) of C++ compilers.

But they can become more competitive.  The vendors can advertise that
they meet the standard better than their competitors.  If bugs cause
them to fail to meet the standard, their competitors can point out
those bugs in their ads.  This will put more pressure on the vendors to
test their compilers more.  And, for example, it will put a lot of
pressure on Microsoft to support templates in their compilers, because
they will no longer be able to claim they meet the standard otherwise,
and their competitors will be able to claim they don't.

But with no standard at all, there is less competition and less
pressure to fix bugs and quirks, because there is no standard to fall
short of.

In article <ercCDK0M2.4vB@netcom.com> erc@netcom.com (Eric Smith) writes:
>In article <rfgCDJGpJ.AF@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>>In other words, I can assure you that it will NOT be the case that all
>>existing C++ compilers will magically become totally reliable the day
>>after we have an approved international standard for C++.  That just
>>won't happen.
>>
>>What is clearly needed is more testing (and better testing) by the
>>implementors (rather than by the end users) of C++ compilers.
>
>But they can become more competitive.  The vendors can advertise that
>they meet the standard better than their competitors.

Apparently, the current lack of an international C++ standard is NOT pre-
venting vendors from ALREADY claiming conformance to the "latest draft of
the evolving ANSI(tm) C++ standard".  (See the inside front cover of this
month's IEEE Software magazine for an example of one such claim.  We are
bound to see more and more such claims the longer we go without a standard.)

>But with no standard at all, there is less competition and less
>pressure to fix bugs and quirks, because there is no standard to fall
>short of.

Unfortunately, competition doesn't come from standards.  Competition comes
from companies offering products.  And for a number of different types of
machines, there simply is no competition.  You either buy a C++ compiler
from the system (hardware) vendor or else you code in some other language.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------