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


Author: ivr@guesswh.at.emails.ru ("Ioannis Vranos")
Date: Mon, 19 Apr 2004 16:07:54 +0000 (UTC)
Raw View
I would like to see your views on these.


C++98 is already a large language since it supports 4 paradigms and each one
is supported well, with optimal space and time efficiency. And this is
excellent.

>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).

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.


The existence of facilities not required to be implemented in a compliant
C++0x implementation, is by itself fragmentation. ISO C++0x code that
compiles in a C++0x compliant compiler will not compile in another, although
the computer system may have the functionality available (e.g. networking
again). So one may have C++0x networking code that compiles in a compiler,
and does not in another. Why would one write code using C++0x facilities
which is not guaranteed to compile everywhere, not even in the same platform
with a different compiler? The availability of such facilities should be
left to third party system-specific and framework APIs (e.g.  .NET, QT,
etc). Will a programmer write "ISO C++0x" network code not guaranteed to
compile in another ISO C++0x compliant compiler even in the same platform,
or will he use the APIs of his platform?

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).


The idea of library facilities not supported by language constructs
(=exotic), does not fit in a systems programming language, which must be
self-dependent. This means that either those facilities must not be part of
the library, or they are deemed very necessary and thus the fundamental
language constructs must be added to the core language. Since they are
exotic, we can conclude that they are not very necessary. The unneeded
language facilities add extra "weight" to the language.


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!


I am talking about possible dangers, so please be gentle with your critique.






Regards,

Ioannis Vranos

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]