Re: C++ danger to break due to its weight, fragmentation danger - C++0x

From: Dietmar Kuehl (dietmar_kuehl_at_yahoo.com)
Date: 04/19/04 

Date: 19 Apr 2004 04:06:13 -0700

"Ioannis Vranos" <ivr@guesswh.at.emails.ru> wrote:
> From the few things that i have read about C++0x, in addition to some C99...
> features (actually some other term comes in my mind for this instinctively,
> but it is another subject for discussion), there is library expansion with
> new facilities, some of them *not supported directly by language constructs*
> (= exotic) like networking. Also not all of the new features will be
> required by the standard to be implemented everywhere, since not all of this
> functionality will be available in all computer systems (e.g. networking
> again).

Your information on this issue is wrong. Although we are discussing how to
possibly deal with features not available everywhere, there are no [new]
libraries for the standard on the way which are optional. In particular, no
networking library is currently under discussion. There is, however, a
technical report on on standard C++ library extensions (lib-tr for short)
which provides some features which are unimplementable without non-standard
extensions to the C++ compiler. These features need not be implemented by
all compilers for the context of the lib-tr but this will probably change
if the components are added to the standard: none of these is inherently
unimplementable on some systems (it is always just accessing information
which is available anyway to the compiler but it would require compilers to
change).

As of now, nothing like networking or GUI is under discussion and I doubt
that any proposal for such a component would stand a reasonable chance.
This is not because it is unimplementable on some platforms but because the
variation between systems is too big to warrant standardization (yes, I
know: "Java has done it" - actually, it has not).

> This is a departure from the initial language ideals, that is to provide a
> common well-defined functionality subset of all existing computer systems
> out there with an integral language. Today, all C++98 language constructs
> are available to all C++98 compliant compilers.

This statement is also wrong: there are at least three different kinds of
compliant C++ implementations. The C++ standard explicitly mentions two of
them:

- A free standing implementation is one which only has a very rudimentary
  standard library. Essentially, only the language support library (eg.
  the memory allocation operators and the exception classes mentioned in
  the core language) is guaranteed to be supported there.
- A hosted implementation supports the whole library. However, there are
  two variations for a hosted implementation:
  - a good one where eg. the file operations indeed write some form of a
    file.
  - a "bad" one where eg. the file operations actually have no effect.

> The existence of facilities not required to be implemented in a compliant
> C++0x implementation, is by itself fragmentation.

Other standard also allow optional portions and this approach works
reasonable well for them. The issue for the customer becomes then to
select an implementation with the proper support. If there is a market for
the corresponding support, most vendors will implement it. Actually, this
is already the case: The separation model for template compilation (the
stuff associated witht the keyword "export") is only implemented by one
compiler (well, actually potentially a group of compilers: those based on
the EDG front-end). The other compiler vendors think that there is no
market which warrants implementation of this featurs - although it not an
optional one and any compiler not supporting it is not a C++ compiler: as
far as I know, there is currently only one existing standard conforming C++
compiler, namely the implementation of Comeau (see
<http://www.comeaucomputing.com>). Of course, it can be assumed that no
major software is entirely bug free but still no major C++ feature is
missing from Comeau's C++ compiler when used with the Dinkumware standard
library.

> Due to this, it is very possible that most compiler implementors will stick
> with the required stuff. This means that no longer we will have a coherent
> language, and this by definition (the standard itself).

This is already the case. Actually, implementers will stick to features
requested by the market: if nobody or only few users want a compiler
conforming to C++-0x, most C++ implementers will not implement it.

> The idea of numerous extensions to the library (i am talking about
> non-exotic stuff here) is nice, but adds much extra weight to the language.
> The result is that each implementor may choose to implement only what he
> considers as important from all this stuff, even to stick only with C++98
> library. This means extra fragmentation, and this time to the
> *required-by-the-standard* core. In this case, there is great danger the
> language to break by its weight. The new core of the library may become
> non-portable de facto, and this will mean the abortion of the most new part
> of C++0x. If this happens, C++ may become extinct!

This is funny: other claim that C++ will become extinct if we don't add
major libraries (like eg. Java's) to the language. Taking both prognoses
together, C++ will become extinct anyway. So why bother?

My personal expectation is that we will effectively bring the core language
in line with the C++/CLI binding currently standardized by ECMA and that
C++ will grow and prosper as *the* programming language used for implementing
applications on the dominant operating system or even operating systems (as
the CLR is not restricted to a particular platform). I'm not saying that I
like to follow the ECMA lead in this respect but I would guess that this is
the most reasonable path to pursue. 

--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

Relevant Pages

  • Re: "Criticism of the C programming language ??????"
    ... "that's not in the standard, ... rewrites of the compiler. ... PH> They got all the compiler vendors to agree to a common ... or graphics libraries or threading libraries, ...
    (comp.lang.c)
  • Re: "built-in" File I/O
    ... standard-defined libraries, then I have some trouble understanding what the ... Changed downthread to standard (either core or library). ... may be a touch less in the compiler, but if it's required in the ...
    (comp.lang.pl1)
  • Re: idea: on the issue of C and language extensions
    ... 1- Remove everything from the standard which can be provided by ... portable libraries and extend compiler "magic" to allow more and more ... struct B _Isa struct A; would declare that any struct B* could be ...
    (comp.std.c)
  • Re: Teaching new tricks to an old dog (C++ -->Ada)
    ... > the standard language. ... Or did they just implemented some 80% of the new features? ... there was a fully compiant C compiler available. ...
    (comp.lang.ada)
  • Re: Teaching new tricks to an old dog (C++ -->Ada)
    ... > the standard language. ... Or did they just implemented some 80% of the new features? ... there was a fully compiant C compiler available. ...
    (comp.lang.cpp)