Re: C++ standard
kanze wrote:
Walter Bright wrote:
The C++ standard committee can only control their C++ standard document.
They can't control anything else because they do not have any trademark
control over the term "C++". Anyone can produce a document claiming to
be a "C++ standard".
I think that ISO is trademarked; it is at least protected in
some way, and not just anyone can publish something called an
ISO standard.
But it stops there. If I repackage a K&R C compiler, and claim
that it complies with the ISO C++ standard, ISO isn't going to
take any action. With something that blatant, of course, I may
get into trouble because of various truth in advertising laws.
I think ISO could take legal action against someone claiming to have an
"ISO IEC 14882-1998 C++ compiler" that didn't support export. But not a
"C++ compiler".
And some countries may also have specific laws---a DIN standard
has a particular legal status in Germany, for example, and I
believe (although I'm far from sure) that it is illegal for you
to label a product X if there is a DIN standard for X, and you
are not conform. (If this is true, however, the law certainly
isn't enforced. The ISO C++ standard is also a DIN standard, so
technically, it would be illegal to label something a C++
compiler if it didn't support export.)
There is the possibility that if one sells a "C++ compiler" that is
actually a vacuum cleaner, one could be prosecuted for fraud. On the
other hand, the absence of any official C++ test suite means that nobody
can prove any C++ compiler to be standards compliant, and I suspect any
legal case against a non-conformant compiler would fall apart on that basis.
Doesn't Sun have some official validation suite for Java?
Since no one else has mentionned it, I will point out one
particular difference, and the consequences. Java rigorously
defines the size and formats of its basic types; C++ doesn't.
The result is that you do have to pay more attention in C++ if
you want to avoid implementation dependencies. Another result
is that an efficient implementation of Java is impossible on
some platforms. C++ tries to permit efficient implementations
on all reasonable hardware. If you have to target that 36 bit
1's complement machine that is still being sold, C++ has a
definite advantage:-).
PDP-10's became obsolete years before C++ appeared on the scene. I think
the C++ community would be well served by statements in the Standard
along the lines of "if it's a 32 bit CPU, then int shall be 32 bits,
etc." That would bless current existing practice into something that
could be relied upon.
That said, I believe the single biggest obstacle to C++ library
production is the lack of garbage collection. Every C++ shop seems to
evolve towards its own peculiar methodology to managing memory, meaning
that getting one 3rd party library to play well with another is a big
problem. And then, of course, there's simply the vast amount of effort
expended in any C++ library trying to manage memory. The Boehm
collector, while effective, cannot be relied upon by library vendors
because it isn't part of the standard, making it only useful for
"island" projects.
-Walter Bright
www.digitalmars.com C, C++, D programming language compilers
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]