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

[Ioannis Vranos]

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

[Jack Klein]

On Mon, 19 Apr 2004 09:26:26 +0300, "Ioannis Vranos"
<iv*@guesswh.at.emails.ru> wrote in comp.lang.c++:

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

[snip]

This newsgroup is for discussing using the C++ language that exists
today. The (moderated) newsgroup for discussing possible future
additions or changes to the C++ language standard is comp.std.c++.
This post belongs there, not here.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Ioannis Vranos]

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:dv********************************@4ax.com...

On Mon, 19 Apr 2004 09:26:26 +0300, "Ioannis Vranos"
<iv*@guesswh.at.emails.ru> wrote in comp.lang.c++:

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

[snip]

This newsgroup is for discussing using the C++ language that exists
today. The (moderated) newsgroup for discussing possible future
additions or changes to the C++ language standard is comp.std.c++.
This post belongs there, not here.

I checked the clc FAQ and did not see any restriction for current standard
discussion.


Ioannis Vranos

[Ioannis Vranos]

"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote in message
news:c5***********@ulysses.noc.ntua.gr...

I checked the clc FAQ and did not see any restriction for current standard
discussion.

I meant: I checked the clc++ FAQ and did not see any restriction for
future-standard-features discussions.


Ioannis Vranos

[Ioannis Vranos]

"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote in message
news:c5***********@ulysses.noc.ntua.gr...

I meant: I checked the clc++ FAQ and did not see any restriction for
future-standard-features discussions.

And i had posted the same message to clc++m before i post it here. I posted
here too, because here there are more people and the flow of discussion is
faster.


Regards,

Ioannis Vranos

[Ioannis Vranos]

"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote in message
news:c5***********@ulysses.noc.ntua.gr...

And i had posted the same message to clc++m before i post it here. I

posted

#^*%&(%$$. I meant to say comp.std.c++.


Ioannis Vranos

[Michiel Salters]

"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote in message news:<c5***********@ulysses.noc.ntua.gr>...

I checked the clc++ FAQ and did not see any restriction for
future-standard-features discussions.

5.9 Only post to comp.lang.c++ if your question is about the C++ language _itself_.

Networking is not in the C++ language. 5.9 also points to the correct
group: comp.std.c++
"Discussion directly related to the evolving ANSI/ISO C++ standard"
i.e. what /may become/ the C++ language.
English is sometimes sloppy when compared to other languages,
especially when it comes to verbs and events in the future.

"Ultimately this means your question must be answerable by looking
into the C++ language definition as determined by the ISO/ANSI
C++ Standard document, and by planned extensions and adjustments."
(FAQ, 5.9)
does not cover your case. Networking is not planned, but it might
become planned depending on discussions in csc++ and WG21.
Regards,
Michiel Salters

[Dietmar Kuehl]

"Ioannis Vranos" <iv*@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:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

[Ioannis Vranos]

"Dietmar Kuehl" <di***********@yahoo.com> wrote in message
news:5b**************************@posting.google.c om...

At first I must tell that i have not enough information on what exactly is
going on with the committee, i based my questions mainly on rumors. If there
is a blog or something regarding C++0x please post some URL.

Your information on this issue is wrong. Although we are discussing how to
possibly deal with features not available everywhere,

I had heared of that.

there are no [new]
libraries for the standard on the way which are optional.
I did not know that.
In particular, no
networking library is currently under discussion.

My info then was erroneus.

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

So there is a proposal for exotic features.


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

Who cares for Java anyway. :-)

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.

Well this is not already the case. All serious compiler vendors strive for
C++98 conformance (even MS these days).
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?

I think that the best approach is somewhere in the middle. More library
facilities but not thousand of new facilities which not all will implement.
And Java API is made by only one company SUN, as with all frameworks and
APIs. Here we will expect many facilities from many. So it needs some
caution.
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.

I agree with that entirely.


Thanks for the clarifications!

Ioannis Vranos

[Pete Becker]

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

That is, of course, a possibility, but no decisions have yet been made
for C++0x. Your concerns are premature, to put it mildy. If you're so
concerned that we're totally blind, though, join the standards
committee, attend meetings, see what's actually happening, and if you
have something to contribute, do so.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Michiel Salters]

"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote in message news:<c6***********@ulysses.noc.ntua.gr>...

"Dietmar Kuehl" <di***********@yahoo.com> wrote in message
news:5b**************************@posting.google.c om...

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

So there is a proposal for exotic features.

#define exotic new

Seriously, we already have mechanisms to figure out in template code
whether some type T is an int, or a pointer. Asking whether
some type T is a union or an enum fits in with the list, but is in
fact not possible or rather complex. This is being generalized,
and a common interface is being proposed which can answer these kinds
of questions with a uniform syntax. That's not exotic. Providing
a single interface for a number of related functions is Good Software.

Regards,
Michiel Salters

[Ioannis Vranos]

"Michiel Salters" <Mi*************@logicacmg.com> wrote in message
news:fc**************************@posting.google.c om...

So there is a proposal for exotic features.
#define exotic new

:-)
Seriously, we already have mechanisms to figure out in template code
whether some type T is an int, or a pointer. Asking whether
some type T is a union or an enum fits in with the list, but is in
fact not possible or rather complex. This is being generalized,
and a common interface is being proposed which can answer these kinds
of questions with a uniform syntax. That's not exotic. Providing
a single interface for a number of related functions is Good Software.

Yes that is nice and i agree with you. With the term "exotic" i meant
facilities like network connections on the standard library, which wouldn't
be possible to be defined using the core language since the core language
would lack the basic constructs to support this kind of stuff. Since there
is no network proposal, are there any proposals for other kinds of exotic
facilities?


Regards,

Ioannis Vranos

[Claudio Jolowicz]

On Tue, 20 Apr 2004, Ioannis Vranos wrote:

"Michiel Salters" <Mi*************@logicacmg.com> wrote in message
news:fc**************************@posting.google. com...

> So there is a proposal for exotic features.
#define exotic new

:-)

Seriously, we already have mechanisms to figure out in template code
whether some type T is an int, or a pointer. Asking whether
some type T is a union or an enum fits in with the list, but is in
fact not possible or rather complex. This is being generalized,
and a common interface is being proposed which can answer these kinds
of questions with a uniform syntax. That's not exotic. Providing
a single interface for a number of related functions is Good Software.

Yes that is nice and i agree with you. With the term "exotic" i meant
facilities like network connections on the standard library, which wouldn't
be possible to be defined using the core language since the core language
would lack the basic constructs to support this kind of stuff. Since there

Which "basic constructs"? For what "kind of stuff"? Many network
protocols are written in C and could no doubt be rewritten in
(idiomatic) Standard C++. This is also true, and even more so, of
programming interfaces provided to network protocols, e.g. sockets for
TCP connections. Your term "exotic" does not carry any meaning in this
context, and you are making things worse by explaining it with another
vague formulation. As far as I can judge, the problems relating to
specifying an interface for networking functions that could be
implemented on a wide range of platforms are due not to the allegedly
restricted capabilities of the core language, but to the (lack or
disparity of) networking support on those platforms.
is no network proposal, are there any proposals for other kinds of exotic
facilities?


Regards,

Ioannis Vranos

--
Claudio Jolowicz

Department of Computing
180 Queen's Gate
South Kensington campus
Imperial College
London SW7 2AZ

31 Humbolt Road
Fulham
London W6 8QH

mobile: [phone]
http://www.doc.ic.ac.uk/~cj603

[Ioannis Vranos]

"Claudio Jolowicz" <cj***@doc.ic.ac.uk> wrote in message
news:Pi*******************************@kiwi.doc.ic .ac.uk...

Which "basic constructs"? For what "kind of stuff"? Many network
protocols are written in C and could no doubt be rewritten in
(idiomatic) Standard C++. This is also true, and even more so, of
programming interfaces provided to network protocols, e.g. sockets for
TCP connections. Your term "exotic" does not carry any meaning in this
context, and you are making things worse by explaining it with another
vague formulation. As far as I can judge, the problems relating to
specifying an interface for networking functions that could be
implemented on a wide range of platforms are due not to the allegedly
restricted capabilities of the core language, but to the (lack or
disparity of) networking support on those platforms.

Can you establish a TCP/IP connection using only ISO C++? No. You will have
to use some system specific API. So if a library was provided having
networking facilities it would not be able to be written in ISO C++ the way
like std::basic_string can be written for example.


Ioannis Vranos

[Claudio Jolowicz]

On Wed, 21 Apr 2004, Ioannis Vranos wrote:

"Claudio Jolowicz" <cj***@doc.ic.ac.uk> wrote in message
news:Pi*******************************@kiwi.doc.i c.ac.uk...

Which "basic constructs"? For what "kind of stuff"? Many network
protocols are written in C and could no doubt be rewritten in
(idiomatic) Standard C++. This is also true, and even more so, of
programming interfaces provided to network protocols, e.g. sockets for
TCP connections. Your term "exotic" does not carry any meaning in this
context, and you are making things worse by explaining it with another
vague formulation. As far as I can judge, the problems relating to
specifying an interface for networking functions that could be
implemented on a wide range of platforms are due not to the allegedly
restricted capabilities of the core language, but to the (lack or
disparity of) networking support on those platforms.

Can you establish a TCP/IP connection using only ISO C++? No. You will have
to use some system specific API. So if a library was provided having
networking facilities it would not be able to be written in ISO C++ the way
like std::basic_string can be written for example.

How about std::cout? How would you implement that without using a
"system specific API"?

--
Claudio Jolowicz