Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > C++ danger to break due to its weight, fragmentation danger - C++0x

Reply
Thread Tools

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

 
 
Ioannis Vranos
Guest
Posts: n/a
 
      04-19-2004
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

 
Reply With Quote
 
 
 
 
Jack Klein
Guest
Posts: n/a
 
      04-19-2004
On Mon, 19 Apr 2004 09:26:26 +0300, "Ioannis Vranos"
<(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Ioannis Vranos
Guest
Posts: n/a
 
      04-19-2004
"Jack Klein" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Mon, 19 Apr 2004 09:26:26 +0300, "Ioannis Vranos"
> <(E-Mail Removed)> 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

 
Reply With Quote
 
Ioannis Vranos
Guest
Posts: n/a
 
      04-19-2004
"Ioannis Vranos" <(E-Mail Removed)> wrote in message
news:c5vsuq$1nr0$(E-Mail Removed)...
>
> 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

 
Reply With Quote
 
Ioannis Vranos
Guest
Posts: n/a
 
      04-19-2004
"Ioannis Vranos" <(E-Mail Removed)> wrote in message
news:c5vtaf$1opc$(E-Mail Removed)...
>
> 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

 
Reply With Quote
 
Ioannis Vranos
Guest
Posts: n/a
 
      04-19-2004
"Ioannis Vranos" <(E-Mail Removed)> wrote in message
news:c5vu2b$1qum$(E-Mail Removed)...
>
> 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

 
Reply With Quote
 
Michiel Salters
Guest
Posts: n/a
 
      04-19-2004
"Ioannis Vranos" <(E-Mail Removed)> wrote in message news:<c5vtaf$1opc$(E-Mail Removed)>...
> 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
 
Reply With Quote
 
Dietmar Kuehl
Guest
Posts: n/a
 
      04-19-2004
"Ioannis Vranos" <(E-Mail Removed)> 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.
--
<(E-Mail Removed)> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting
 
Reply With Quote
 
Ioannis Vranos
Guest
Posts: n/a
 
      04-19-2004
"Dietmar Kuehl" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) 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

 
Reply With Quote
 
Pete Becker
Guest
Posts: n/a
 
      04-20-2004
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)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Its a bird, its a plane, its.. um, an Attribute based System? thunk Ruby 14 04-03-2010 10:08 AM
DANGER DANGER THIRD DAY CPU FAN FAILURE DANGER DANGER Skybuck Flying Windows 64bit 9 04-01-2010 10:33 PM
Its a bird, its a plane, its.. um, an Attribute based System? thunk Ruby 0 04-01-2010 10:25 PM
Its a bird, its a plane, no ummm, its a Ruide thunk Ruby 1 03-30-2010 11:10 AM
Danger Danger Will Robinson Vista SP1 Lloyd Sheen ASP .Net 2 03-19-2008 05:58 PM



Advertisments