Are multiple STL implementations necessary ?
Philip Brabbin
online STL documentation. It seems that their group (which I think
includes Alexander Stepanov) is still working on improving their
implementation. All credit to them, and I think that SGI's decision to
continue funding this work is very generous.
And given Boris Formichev's efforts to keep STLport in line with the
SGI developments, is their now any need for other third party
implementations ? After all, if a user spots a bug in the (quite
possibly out-of-date) implementation shipped with their favourite
compiler, the chances are that the vendor is not going to come up with
a quick fix. If the SGI (or STLport) implementation works for their
compiler, it is probably going to support STL better and be more
efficient, and reporting any problems on a newsgroup such as this (or
the STLport newsgroup) might well come up with something fairly quickly.
- Phil Brabbin
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Pete Becker
>
> And given Boris Formichev's efforts to keep STLport in line with the
> SGI developments, is their now any need for other third party
> implementations ? After all, if a user spots a bug in the (quite
> possibly out-of-date) implementation shipped with their favourite
> compiler, the chances are that the vendor is not going to come up with
> a quick fix. If the SGI (or STLport) implementation works for their
> compiler, it is probably going to support STL better and be more
> efficient, and reporting any problems on a newsgroup such as this (or
> the STLport newsgroup) might well come up with something fairly quickly.
>
Do you believe that the folks at SGI understand the quirks of Borland's
compiler as well as the folks at Borland do? If not, then it seems clear
that the folks at Borland are very likely to do a better job of getting
STL right and small and fast than the folks at SGI.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
Peter N Roth
Pete Becker <peteb...@acm.org> wrote in message
news:374CB96F...@acm.org...
> Do you believe that the folks at SGI understand the quirks of Borland's
> compiler as well as the folks at Borland do?
except that Borland ships the Rogue Wave STL, so maybe the question
should be phrased "...as well as the folks at RW do?"
--
Grace + Peace | Peter N Roth | Engineering Objects Int'l
Amazon.com associate | Inprise Tool & Component Builder
http://www.inconresearch.com/eoi
Bill Seymour
>
> Do you believe that the folks at SGI understand the quirks
> of Borland's compiler as well as the folks at Borland do?
> very likely to do a better job of getting STL right and
> small and fast than the folks at SGI.
>
Do you get the same answer if you replace "Borland" with
"Microsoft," "Sun," et al.?
IMO, the folk who know the STL, and who are willing to do
the work, are the ones most likely to get it right. If an
implementation can't compile a "well-formed" STL, then that
implementation is of inferior quality. (I know that's not
much help to programmers who, for non-technical reasons,
are stuck with poor implementations; but I'm afraid it's
the only real answer we have right now.)
--Bill Seymour
Philip Brabbin
Pete Becker <peteb...@acm.org> wrote:
> Philip Brabbin wrote:
> >
> > And given Boris Formichev's efforts to keep STLport in line with the
> > SGI developments, is their now any need for other third party
> > implementations ? After all, if a user spots a bug in the (quite
> > possibly out-of-date) implementation shipped with their favourite
> > compiler, the chances are that the vendor is not going to come up
with
> > a quick fix. If the SGI (or STLport) implementation works for their
> > compiler, it is probably going to support STL better and be more
> > efficient, and reporting any problems on a newsgroup such as this
(or
> > the STLport newsgroup) might well come up with something fairly
quickly.
> >
>
Borland's
> compiler as well as the folks at Borland do? If not, then it seems
clear
> that the folks at Borland are very likely to do a better job of
getting
> STL right and small and fast than the folks at SGI.
Firstly, you say "getting the STL right". By this I assume that you
mean both implementing the STL fully and completely as defined in the
C++ Standard, and also having a robust, relatively bug-free
implementation. This in itself is not a small task - do Borland
*really* have the time and resources, let alone the desire to do
this ? (I admit, I personally don't know the answer to this question
in the case of Borland, but I'm sure not all vendors will have all
three).
Secondly, you say "small and fast" (although there's often a tradeoff
between the two). As I understand it, the STL is implemented in plain
ANSI C++, and a lot of the optimisations rely on the template
specialisation mechanism. For example, using memcpy() in
specialisations of std::copy() in certain cases, and producing a
specialisation of container classes for pointers to avoid code bloat.
Choosing efficient algorithms/representations is also key in this
area. I'm not entirely sure I understand how you can exploit knowledge
of the "quirks of the Borland's compiler" to improve performance. The
hope is that most serious compilers will be mostly compiant with the
C++ Standard in the near future, in which case the SGI implementation,
with all its optimisations, should work just fine.
Even on the assumption that a vendor can squeeze a little extra out of
the implementation, is it really worth it ? Isn't this going back to
the old days when programmers had to aware of the quirks of each and
every system on which their code would be used ? Having multiple
implementations surely just introduces interface incompatibilties, non-
standard extensions, and more bugs ???
That's my view anyway. Please feel free to correct me if you think I'm
wrong.
- Phil Brabbin
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
valued customer
>
> Do you believe that the folks at SGI understand the quirks of Borland's
> compiler as well as the folks at Borland do? If not, then it seems clear
> that the folks at Borland are very likely to do a better job of getting
> STL right and small and fast than the folks at SGI.
>
>
Is Borland's compiler really so quirky that they must completely re-write
the library? I would think most optimizations would be in several key
areas (like memory allocation, streambuffers, umm.. and other stuff).
They could simply grab SGI's (or STLport) library, make their
optimizations for their own compiler in that library, and ship that with
their product. They would then have a library that is more thoroughly
tested (of course their optimizations will introduce problems, but less
than a complete re-write of STL would).
Note that I naively mixed the words standard library and STL. In the
least, Borland (or any other compiler) could use SGI's STL implementation
and supply their own string-s,stream-s, and whatever else to complete the
standard library.
f...@stlport.org
implementations - that ensures the progress.
That's my answer to the original question.
Pete, I think you missed the point a little - Philip asked about
third-party implementors, not compiler vendors. Sure that would
be great if the compiler guys would implement STL on instrintic level
with maximum of global and machine-dependant optimizations possible.
It does not seem to be the case now, though.
Why things go that slow ? Apparently compiler teams have other
priorities.
Since currently most compiler vendors do use third-party STL code (for
example, Borland uses Rogue Wave library, so that would be RW folks who
are supposed to fix user's problem, not Borland ones),
the turnaround cycle for bug fixes becomes longer, leave alone
additional optimizations.
To prove it, let's just watch how much STL code shipped with the latest
VC++ compiler differs from the one shipped with VC++ 4.2, years ago.
Consider also that SGI STL is around for 2.5 years, providing complete
working example on how things could be done better, in terms of
exception safety and important specializations that allow orders of
magnitude speedup (not possible with most kinds of compiler-specific
optimization).
If even that does not push compiler vendors (except Cygnus/FSF) to
improve their implementations, I seriosly doubt any user request will
make any move there, especially given the fact that the compiler
vendor in general has to request library vendor to do that.
Best regards,
-Boris.
In article <374CB96F...@acm.org>,
Pete Becker <peteb...@acm.org> wrote:
> Philip Brabbin wrote:
> >
> > And given Boris Formichev's efforts to keep STLport in line with the
> > SGI developments, is their now any need for other third party
> > implementations ? After all, if a user spots a bug in the (quite
> > possibly out-of-date) implementation shipped with their favourite
> > compiler, the chances are that the vendor is not going to come up
with
> > a quick fix. If the SGI (or STLport) implementation works for their
> > compiler, it is probably going to support STL better and be more
> > efficient, and reporting any problems on a newsgroup such as this
(or
> > the STLport newsgroup) might well come up with something fairly
quickly.
> >
>
> Do you believe that the folks at SGI understand the quirks of
Borland's
> compiler as well as the folks at Borland do? If not, then it seems
clear
> that the folks at Borland are very likely to do a better job of
getting
> STL right and small and fast than the folks at SGI.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Steve Clamage
>And given Boris Formichev's efforts to keep STLport in line with the
>SGI developments, is their now any need for other third party
>implementations ? After all, if a user spots a bug in the (quite
>possibly out-of-date) implementation shipped with their favourite
>compiler, the chances are that the vendor is not going to come up with
>a quick fix. If the SGI (or STLport) implementation works for their
>compiler, it is probably going to support STL better and be more
>efficient, and reporting any problems on a newsgroup such as this (or
>the STLport newsgroup) might well come up with something fairly quickly.
If you mean that all C++ implementations might as well adopt
STLport instead of shipping anything else, that might be a
possibility.
But your comments have implications far beyond that point.
The STL headers get baked into the C++ runtime library that is part
of any C++ implementation. Any change in any header is likely to
invalidate the runtime library. For example, there is a
co-dependency between iostream classes and the string class.
You can't just drop in a new string class and expect everything
else to work. There is also a co-dependency between the string
class and parts of the STL.
If, for example, you saw an update of STLport and dropped the new
headers into your C++ implementation, even one that was based
on STLport, there is no assurance that you could generate
working programs from the modified implementation. Parts of the
runtime library would have been compiled against the old version
of the headers, creating inconsistent notions of class layout
and functionality. (Inline functions get baked into code that
uses them, remember, so you could have multiple inconsistent
verions of functions.)
Unless you have the full source code for the entire C++ runtime
library and are prepared to regenerate it, you cannot make use
of new headers. You must still rely on the C++ implementer to
provide a consistent set of headers and runtime libraries.
But wait, there's more.
If you have application code that was compiled against an earlier
version of library headers, all that code will have to be
recompiled if any part of the application uses the new headers.
We can lay the blame for this situation on the heavy use of
inline functions and templates in C++, particularly in the
standard library. It means that much of a program is defined
by the standard C++ headers, with little of it confined to an
object-code standard library.
That in turn means you can't just replace the C++ runtime standard
library with a new version if any of the changes occur in any of
the headers. Similarly, you can't replace just the C++ standard
headers without recompiling the standard library and everything
else that used the headers.
--
Steve Clamage, stephen...@sun.com
Howard Hinnant
I have nothing but the highest respect for the engineers at SGI.
But I do not believe that they have a monopoly on the best implementation
of the standard C++ lib, nor the subset STL. I realize that by saying
this, I set myself up for some frightening abuse. After all, I'm saying
that someone else might do a part of STL better than Alex Stepanov
himself.
But this is what I truly believe is possible.
The original STL from HP was a very great thing. But it was not perfect.
SGI's implementation is very good. But it is not perfect. If we were to
declare that SGI's implementation (or anybody else's) was perfect, where
is the motivation for someone to come along and make a better version? If
you eliminate competition, you have eliminated a great deal of potential
future improvments.
Indeed, even the specifications for the standard C++ lib are still in flux
some what. The C++ committee still meets twice a year to discuss defect
reports in the standard. The great majority of these are minor type-o's
that won't effect any code anywere. But not all of them are. Has SGI (or
anyone else) already perfected a lib to meet these as yet unspecified
specifications?!
-Howard
Andrei Alexandrescu
monopolystic.
It assumes no one can produce a better STL than SGI, which sounds quite
strange.
I think there are a lot of things that one can add to the STL to make it
very liveable on a given platform. There are also additions to STL that
I would like seeing, but they lack in SGI STL. It's a pity that finding
companies that actually would pay you for doing such nifty things,
just to give away the results for nothing, is so hard. (How's that for a
lengthy statement? Proust would be proud.)
All credits to SGI... but there is more one can add to build a
world-class STL.
Andrei
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Ken Hagan
>And given Boris Formichev's efforts to keep STLport in line with the
>SGI developments, is their now any need for other third party
>implementations ?
Aside from my gut feeling that we shouldn't rely on a single implementation,
I can think of two reasons to have several versions of the STL parts of the
standard library.
Wierd environments will still require custom implementations. Having several
implementations targetting ordinary desktop platforms will stop alternative
ones becoming only a niche interest. The recent discussion of allocators in
this group (or was it comp.std.c++.moderated?) indicates that we are still
learning about these things.
The second reason is that someone might come up with a dramatically
different
implementation. As far as I know, all current implementations can match hand
written code for performance, but enjoy little re-use of code between
different
instantiations (mainly in the containers). I can imagine an implementation
which
re-uses almost all the code (even in algorithms), though with considerable
loss
in peformance. For some people this might be a desirable trade-off. We are
still
learning.
However, as the details are pinned down, we move to a "natural monopoly" and
ultimately there may only be room for two "conventional" implementations.
(Those would be the free one and whichever one MS ship.)
Stan Brown
>The STL headers get baked into the C++ runtime library that is part
>of any C++ implementation. Any change in any header is likely to
>invalidate the runtime library. For example, there is a
>co-dependency between iostream classes and the string class.
>You can't just drop in a new string class and expect everything
>else to work. There is also a co-dependency between the string
>class and parts of the STL.
So what you're saying, if I understand you correctly, is that NO ONE can
safely use STLPort unless it was supplied by their compiler vendor. And
even then, they can't safely use an update because that may be
incompatible with their run-time library.
Yet many people are using SGI STL, or STLPort, with their compilers and
the associated run-times. Are you saying they are wrong to do so?
--
There's no need to e-mail me a copy of a follow-up; but if you do,
please identify it as such.
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
http://www.mindspring.com/~brahms/
My reply address is correct as is. The courtesy of providing a correct
reply address is more important to me than time spent deleting spam.
James...@dresdner-bank.com
Bill Seymour <bs...@pobox.com> wrote:
> Pete Becker wrote:
> >
> > Do you believe that the folks at SGI understand the quirks
> > of Borland's compiler as well as the folks at Borland do?
> > If not, then it seems clear that the folks at Borland are
> > very likely to do a better job of getting STL right and
> > small and fast than the folks at SGI.
>
> "Microsoft," "Sun," et al.?
This seems so obvious that I don't know why it has to be said.
To begin with, I would expect that once compiler vendors are fully
conforming, and they can start worrying about performance again, they
will start adding special recognition of things like vector -- the
generic implementation can be expensive in the cases where you don't use
all of its features.
> IMO, the folk who know the STL, and who are willing to do
> the work, are the ones most likely to get it right.
Since STL is now a part of the standard, I would expect that "the folks
who know STL" would include all C++ programmers. And the money you pay
for your compiler is used, at least partially, to make people "willing
to do the work."
> If an
> implementation can't compile a "well-formed" STL, then that
> implementation is of inferior quality.
Note that as part of the implementation, the actual STL code doesn't
have to be "well-formed", in the classical sense. One could imagine an
implementation of vector which looked like this, for example:
template< class T >
class vector { __trigger_compiler_builtin_vector( T ) } ;
Such code is certainly undefined if you write it, but there is nothing
in the standard which says that the compiler vendor may not use
extensions in the implementation of the library. (In fact, there are
one or two small things, like offsetof or filebuf, which cannot be
written in standard C++, and require extensions.)
--
James Kanze mailto:
James...@dresdner-bank.com
Conseils en informatique orientée objet/
Beratung in objekt orientierter
Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49 (069) 63 19 86
27
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James...@dresdner-bank.com
no_...@nowhere.com (valued customer) wrote:
> In article <374CB96F...@acm.org>, peteb...@acm.org says...
> > Do you believe that the folks at SGI understand the quirks of
Borland's
> > compiler as well as the folks at Borland do? If not, then it seems
clear
> > that the folks at Borland are very likely to do a better job of
getting
> > STL right and small and fast than the folks at SGI.
> Is Borland's compiler really so quirky that they must completely
re-write
> the library? I would think most optimizations would be in several key
> areas (like memory allocation, streambuffers, umm.. and other stuff).
I suspect that the biggest optimizations will come because the compiler
itself knows the high level semantics of the library -- it no longer
sees some strange code manipulating pointers allocated through a class
with other strange code: it knows what the high level goal of the
pointers is. For example, I do not find it to exotic to think that
there may be compilers some day which, under certain circomstances,
allocate the memory for a vector on the stack, rather than on the heap.
I've already seen a C compiler in which memcpy was defined:
#define memcpy( d , s , l ) __builtin( 192 , d , s , l )
Given time, similar definitions for vector would not surprise me. And
believe me, they can result in a real spead up.
Philip Brabbin
Don't get me wrong, I'm neither trying to say that the SGI
implementation is perfect nor that there isn't anything which the C++
committee might want to add to the STL later on. But as you admit
yourself, it is very good and probably has something of a head start on
other available implementations.
Neither am I trying to say that monopoly is a good thing - but
realistically the alternative is to have a number of (possibly)
incomplete versions floating around with different bugs and different
extensions. Surely nobody thinks this is a good thing ?
So, here goes .... why doesn't the C++ committee adopt a standard
implementation, against which defect/bug reports could be raised, and
extensions proposed ? Maybe it's all just a question of funding ???????
Regards,
Phil Brabbin
Ken
>
> Dixitque cla...@eng.sun.com (Steve Clamage) in comp.lang.c++.moderated:
> >The STL headers get baked into the C++ runtime library that is part
> >of any C++ implementation. Any change in any header is likely to
> >invalidate the runtime library. For example, there is a
> >co-dependency between iostream classes and the string class.
> >You can't just drop in a new string class and expect everything
> >else to work. There is also a co-dependency between the string
> >class and parts of the STL.
>
> So what you're saying, if I understand you correctly, is that NO ONE can
> safely use STLPort unless it was supplied by their compiler vendor. And
> even then, they can't safely use an update because that may be
> incompatible with their run-time library.
No, I think he's saying that you can't just "drop in" a 3rd party
implementation and expect it to work. Because of tight coupling between
STL and those parts of the library that must be supplied by the compiler
vendor (eg. native I/O), you must be intimately familiar with the
vendor's library implementation and you will probably need to rebuild
the vendor's libraries. This assumes that the vendor has made the
library sources available.
OTOH, it only takes one developer to do this and publish the procedure
in order for the compiler vendor's customers to take advantage of the
3rd party STL.
--
Ken
mailto:sh...@well.com
http://www.sewingwitch.com/ken/
http://www.StopTheWarNow.com/
http://www.215Now.com/
Steve Clamage
>Dixitque cla...@eng.sun.com (Steve Clamage) in comp.lang.c++.moderated:
>>The STL headers get baked into the C++ runtime library that is part
>>of any C++ implementation. Any change in any header is likely to
>>invalidate the runtime library. For example, there is a
>>co-dependency between iostream classes and the string class.
>>You can't just drop in a new string class and expect everything
>>else to work. There is also a co-dependency between the string
>>class and parts of the STL.
>So what you're saying, if I understand you correctly, is that NO ONE can
>safely use STLPort unless it was supplied by their compiler vendor. And
>even then, they can't safely use an update because that may be
>incompatible with their run-time library.
>Yet many people are using SGI STL, or STLPort, with their compilers and
>the associated run-times. Are you saying they are wrong to do so?
If, as I believe is the case, STLport is configured as an
add-on library, there would not be a problem. I was talking
about the difficulty of replacing pieces of a run-time library
with different pieces.
The original posting seemed to say that if my compiler vendor
used, for example, STLport as a base and I found a new version
of STLport on the web site, I could just drop the revised into
my compiler's include directory, replacing the old versions,
and all would be well. I was objecting to that scenario.
--
Steve Clamage, stephen...@sun.com
Pete Becker
>
> Pete Becker <peteb...@acm.org> wrote in message
> news:374CB96F...@acm.org...
>
> > compiler as well as the folks at Borland do?
>
No, the question was phrased correctly. Borland doesn't simply stuff
whatever RW gives them into the package.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Pete Becker
> > that the folks at Borland are very likely to do a better job of getting
> > STL right and small and fast than the folks at SGI.
> >
> >
>
> Is Borland's compiler really so quirky that they must completely re-write
> the library?
I am not aware of any compiler that does not have several quirks that
must be dealt with by library writers. STL, in particular, makes some
rather aggressive use of templates, in ways that many compilers cannot
cope with.
Pete Becker
>
> Pete Becker wrote:
> >
> > Do you believe that the folks at SGI understand the quirks
> > of Borland's compiler as well as the folks at Borland do?
> > If not, then it seems clear that the folks at Borland are
> > very likely to do a better job of getting STL right and
> > small and fast than the folks at SGI.
> >
>
> "Microsoft," "Sun," et al.?
Yes.
>
> IMO, the folk who know the STL, and who are willing to do
> the work, are the ones most likely to get it right. If an
> implementation can't compile a "well-formed" STL, then that
> implementation is of inferior quality.
Since all the world is using implementations that you label "inferior
quality," it raises the question, inferior to what?
Dave Abrahams
> If even that does not push compiler vendors (except Cygnus/FSF) to
> improve their implementations, I seriosly doubt any user request will
> make any move there, especially given the fact that the compiler
> vendor in general has to request library vendor to do that.
As much as I love the STLPort, I have to be sure due credit is given to
Howard Hinnant at Metrowerks, who has continued to push his STL
implementation forward in several directions that have not yet been explored
by the SGI STL. In particular, he has reduced the memory footprint of
various containers (due to user demand!) and he has an ingenious deque
implementation that makes some interesting and useful efficiency tradeoffs.
Also they have standard-compliant exception-safety, just like STLPort ;)
-Dave
Dave Abrahams
bra...@mindspring.com (Stan Brown) wrote:
> So what you're saying, if I understand you correctly, is that NO ONE can
> safely use STLPort unless it was supplied by their compiler vendor. And
> even then, they can't safely use an update because that may be
> incompatible with their run-time library.
It's not unsafe if you know what you're doing. There are two viable
approaches with STLPort:
1. Compile new versions of your C++ standard library and runtime library,
and use those. Also, you need to make sure any other libraries you're using
have been compiled with the STLPort's definition of the standard components.
Technically, you're messing with your C++ implementation and your compiler
vendor would be right not to give you any assurances. For the most part,
though, these things have been checked out by STLPort implementors and
testers.
2. Use the STLPort in it's OWN_NAMESPACE mode, which puts all the components
in a separate namespace called STLPort. Then you just refer to
STLPort::vector instead of std::vector. This avoids any thorny issues
described above, but of course the compiler won't let you pass an
STLPort::vector to a 3rd party library which expects a std::vector.
Pete Becker
>
>
> Don't get me wrong, I'm neither trying to say that the SGI
> implementation is perfect nor that there isn't anything which the C++
> committee might want to add to the STL later on. But as you admit
> yourself, it is very good and probably has something of a head start on
> other available implementations.
Since engineering is based on knowledge and not guesses, the assertion
that SGI "probably has something of a head start" is useless, as well as
wrong.
>
> Neither am I trying to say that monopoly is a good thing - but
> realistically the alternative is to have a number of (possibly)
> incomplete versions floating around with different bugs and different
> extensions. Surely nobody thinks this is a good thing ?
It's quite preferable to having only one implementation that does not
conform to the standard. Competition drives improvement.
>
> So, here goes .... why doesn't the C++ committee adopt a standard
> implementation, against which defect/bug reports could be raised, and
> extensions proposed ? Maybe it's all just a question of funding ???????
Which implementation should the committee choose? What criteria should
we apply in choosing one? If it's number of users, Dinkumware wins. If
it's number of commercial compilers that ship with it, Rogue Wave wins.
If it's longest history, then perhaps SGI wins (although both Dinkumware
and Rogue Wave are based, at least in part, on the SGI code, so perhaps
they all have the same length of history). If it's conformance to the
standard, then you have to decide which compiler you're going to use to
judge conformance, because every implementation provides variants for
each compiler that it supports.
It's not just a question of funding, it's a question of practicality.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Tony
> >
> > And given Boris Formichev's efforts to keep STLport in line with the
> > SGI developments, is their now any need for other third party
> > possibly out-of-date) implementation shipped with their favourite
> > compiler, the chances are that the vendor is not going to come up with
> > a quick fix. If the SGI (or STLport) implementation works for their
> > compiler, it is probably going to support STL better and be more
> > efficient, and reporting any problems on a newsgroup such as this (or
> > the STLport newsgroup) might well come up with something fairly quickly.
> >
>
> compiler as well as the folks at Borland do? If not, then it seems clear
> that the folks at Borland are very likely to do a better job of getting
> STL right and small and fast than the folks at SGI.
I gave up on Borland's version of STL (actually by Rogue-Wave) for
STLPort and never looked back. It got rid of many headaches for me.
Tony
Tony
hinnant@_anti-spam_metrowerks.com says...
> <quoting no one in general, but replying to the general tone>
>
> I have nothing but the highest respect for the engineers at SGI.
>
> But I do not believe that they have a monopoly on the best implementation
> of the standard C++ lib, nor the subset STL. I realize that by saying
> this, I set myself up for some frightening abuse. After all, I'm saying
> that someone else might do a part of STL better than Alex Stepanov
> himself.
>
> But this is what I truly believe is possible.
>
> The original STL from HP was a very great thing. But it was not perfect.
> SGI's implementation is very good. But it is not perfect. If we were to
> declare that SGI's implementation (or anybody else's) was perfect, where
> is the motivation for someone to come along and make a better version? If
> you eliminate competition, you have eliminated a great deal of potential
> future improvments.
Well STLPort looks like the "best" one available today to me anyway. I
constantly hear others saying the same thing.
Dietmar Kuehl
valued customer (no_...@nowhere.com) wrote:
: Is Borland's compiler really so quirky that they must completely re-write
: the library? I would think most optimizations would be in several key
Actually, you can use platform dependent "quirks" to get faster
implementations, smaller object code size, better compile times, etc.
This can be substantial performance boosts. For example, the embedded
systems people really want small object code size. If you can fiddle
with compiler extensions to provide just this (while maintaining the
standard interface, of course) this is possible a much better
implementation than an implementation targetting at "normal" compilers.
In particular, performance trade-off can vary a lot: On embedded
systems, people are not willing to pay a substantial price in terms of
object code size or memory usage for better performance (of course,
there are also some limit there, too). On desktop systems, memory is
considered a cheap resource and executation time is considered critical
(well, at least somewhat...).
: They could simply grab SGI's (or STLport) library, make their
: optimizations for their own compiler in that library, and ship that with
: their product. They would then have a library that is more thoroughly
: tested (of course their optimizations will introduce problems, but less
: than a complete re-write of STL would).
Except that some optimizations use dramatically different approaches!
For example, I'm under the impression that SGI's implementation does
not yet optimize for small object code size. Doing so would really
change the library.
--
<mailto:dietma...@claas-solutions.de>
<http://www.informatik.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic
Dietmar Kuehl
Philip Brabbin (pabr...@hotmail.com) wrote:
: Don't get me wrong, I'm neither trying to say that the SGI
: implementation is perfect nor that there isn't anything which the C++
: committee might want to add to the STL later on. But as you admit
: yourself, it is very good and probably has something of a head start on
: other available implementations.
SGI's STL targets only one kind of platforms, although a very popular
one, namely computer where neither object code size nor memory usage
are critical, eg. desktop computers. There are other platforms which
ask for a very different implementation, eg. embedded systems. I doubt
that SGI's implementation has anything like a head start for these
platforms.
: Neither am I trying to say that monopoly is a good thing - but
: realistically the alternative is to have a number of (possibly)
: incomplete versions floating around with different bugs and different
: extensions. Surely nobody thinks this is a good thing ?
Most compiler vendors are obviously very interested in getting a fully
standard conforming implementation of the whole C++ standard (I know of
only one compiler vendor which apparently deliberately does not move
towards standard conformance...). Thus, I would expect that relatively
soon all compilers will be standard conforming both with respect to the
language and the library support (may be with the exception of the
template separation model; however, this "only" impacts how the user
code is organized, ie. in particular a compiler can ship a fully
conforming library). This is the reason for a standard in the first
place.
: So, here goes .... why doesn't the C++ committee adopt a standard
: implementation, against which defect/bug reports could be raised, and
: extensions proposed ? Maybe it's all just a question of funding ???????
It is definitely not a question of funding! I started to implement a
part of the standard library with the only goal to create the best
implementation of this part (with different measures for "best",
depending on certain requirements like available resources, need for
special support like multi threading support, debugging features,
etc). I'm still quite far away from this goal but I will continue to
work on this. For a free implementation. No funding required. If the
committee would have choosen any particular library for this part, I
wouldn't do it. And I'm quite sure that some of the ideas I have for
the implementation are quite useful and might have found their way
already into other implementations.
Dietmar Kuehl
Ken (sh...@well.com) wrote:
: OTOH, it only takes one developer to do this and publish the procedure
: in order for the compiler vendor's customers to take advantage of the
: 3rd party STL.
The standard does not allow you to replace any part of the standard
library. it happens to work with some of the current implementations
but mainly because both the compilers and the library are not
completed. For example, in the past the IOStream library didn't use any
of the STL classes or algorithms and most of the STL stuff was actually
inline code. Bot aspect might and probably will change. In this case,
you definitely have to replace the whole runtime library which might
actually be impossible: The compiler may depend (and more and more
compilers do depend) on the implementation of some classes like eg.
'exception' and 'bad_cast'. The compiler has to throw these classes.
... and nothing prohibits that these classes are implemented using some
compiler magic. Actually, even the statement '#include <vector>' (or
inclusion of any other standard header) might result in compiler magic
like just marking a set of declarations as seen.
Although I guess that it is possible to replace the runtime library for
most current compilers, I can imagine that this will not be true in a
few years.
Philip Brabbin
> > realistically the alternative is to have a number of (possibly)
> > incomplete versions floating around with different bugs and
different
> > extensions. Surely nobody thinks this is a good thing ?
>
> conform to the standard. Competition drives improvement.
I'm with you on the competition idea in principle, but you appear to be
stating that users are better off having to contend with several
implementations, each buggy and incomplete in its own way, than one
incomplete buggy version. Your logical astounds me! I guess we're
just looking at the problem from different perspectives.
- Phil Brabbin
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Dietmar Kuehl
: Pete Becker <peteb...@acm.org> wrote:
: > It's quite preferable to having only one implementation that does not
: > conform to the standard. Competition drives improvement.
: I'm with you on the competition idea in principle, but you appear to be
: stating that users are better off having to contend with several
: implementations, each buggy and incomplete in its own way, than one
: incomplete buggy version. Your logical astounds me! I guess we're
: just looking at the problem from different perspectives.
That is for certain: Pete Becker works for Dinkumware. This company
provided the library shipping eg. with MSVC++ and a bunch of other
compilers. That is, he takes the library writer perspective. However,
since most implementations of the C++ standard library are portable
across different systems (at least to a certain degree), it might be an
option when porting software not to use the one shipping with the
compiler by default but the one the code was developed with. Doing
this would remove the problem to have to cope with different library
bugs. ... but for now the problem of different compiler bugs remains.
So, why don't we all agree and use just one compiler?
Actually, the whole purpose of the standard is to allow porting between
different systems without any hassle. Currently, there is no conforming
C++ implementation (as far as I know; maybe this has changed within the
last weeks) and thus there are portability problems. This will
relatively soon change such that it is no problem to port code to
another implementation (well, I have some doubts that a certain
compiler vendor will ever provide a conforming implementation but this
is another issue...) as long as only standard features are used.
--
<mailto:dietma...@claas-solutions.de>
<http://www.informatik.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Pete Becker
>
> I gave up on Borland's version of STL (actually by Rogue-Wave) for
> STLPort and never looked back. It got rid of many headaches for me.
>
What headaches did you have, and in what way did STLPort get rid of
them? Or is this going to continue to be a fact-free discussion?
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Pete Becker
>
> Well STLPort looks like the "best" one available today to me anyway. I
> constantly hear others saying the same thing.
>
An unsupported statement like that is very difficult to respond to. What
things does STLPort do better than other implementations that you have
experience with, and what things does it not do as well? Which
implementations are you familiar with, and which implementations are
those others who are constantly saying the same thing familiar with?
What are your criteria for deciding which one is '"best"'? What are the
criteria of those others?
Pete Becker
>
>
> I'm with you on the competition idea in principle, but you appear to be
> stating that users are better off having to contend with several
> implementations, each buggy and incomplete in its own way, than one
> incomplete buggy version. Your logical astounds me! I guess we're
> just looking at the problem from different perspectives.
Users typically choose one library and stick with it for a while. They
only contend with multiple implementations serially, which ain't so bad.
Ryszard Kabatek
>
> Note that I naively mixed the words standard library and STL. In the
> least, Borland (or any other compiler) could use SGI's STL implementation
> and supply their own string-s,stream-s, and whatever else to complete the
> standard library.
This way goes Cygnus, gcc-2.95 will contain the SGI STL 3.2
http://egcs.cygnus.com/.
The Standard C++ Library v3,
http://sourceware.cygnus.com/libstdc++/
will contain the SGI STL too.
--
Ryszard Kabatek
Martin-Luther University Halle-Wittenberg, Department of Physical
Chemistry
Geusaer Str. 88, 06217 Merseburg, Germany
Tel. +49 3461 46 2487 (2466) Fax. +49 3461 46 2129
Pete Becker
>
> Philip Brabbin (pabr...@hotmail.com) wrote:
> : In article <3750350A...@acm.org>,
> : Pete Becker <peteb...@acm.org> wrote:
> : > It's quite preferable to having only one implementation that does not
> : > conform to the standard. Competition drives improvement.
>
> : stating that users are better off having to contend with several
> : implementations, each buggy and incomplete in its own way, than one
> : incomplete buggy version. Your logical astounds me! I guess we're
> : just looking at the problem from different perspectives.
>
> provided the library shipping eg. with MSVC++ and a bunch of other
> compilers. That is, he takes the library writer perspective.
Sigh. No, I have stated my personal perspective, based on what I
consider to be the best form of market for the future development of
C++.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Dietmar Kuehl
Pete Becker (peteb...@acm.org) wrote:
: Dietmar Kuehl wrote:
: > That is for certain: Pete Becker works for Dinkumware. This company
: > provided the library shipping eg. with MSVC++ and a bunch of other
: > compilers. That is, he takes the library writer perspective.
: Sigh. No, I have stated my personal perspective, based on what I
: consider to be the best form of market for the future development of
: C++.
I didn't and didn't want to express that you are stating Dinkumware's
perspective. However, you are quite obviously biased towards a
perspective which is normally not taken by users: For a user of a
library it is much more important that it stays stable and does not
introduce new bugs in different versions than that the specific
implementation is the "best" (for whatever measure is used to determine
the best library). With the current state of the C++ standard library,
it is quite likely that switching between two different implementations
will result in different behavior of programs for whatever reason. And,
althoug I'm pretty sure all library implementers do their best to be
standard conforming, this will continue in the future. Even if all
libraries are perfect and contain no bugs, some stuff in the standard
is not defined in such a way that there is only one interpretation of
what is correct (this is one kind of stuff we try to resolve in our
committee meetings; of course, you are aware of this but some readers
might not). Thus, porting code from one implementation to another will
remain a potential candidate for problems.
From a library write perspective, we are looking towards the "best"
implementation and towards competition which creates new ideas how to
implement specific parts (again, the quality may be measured in many
different way like code size, speed, robustness for request not covered
by the standard, support for debug features or multi-threading,
extensions, and so on). Although users will ask for certain features,
they will complain badly if we provide a "better" implementation but
change some detail, even if the standard does allow changing this
detail. The measure for "best" implementation you asked for in another
answer is proably "the implementation which behaves exactly like the
one used to implement the project": All other implementations, whether
they are more correct and the user relies on a bug as a feature, will
be inferior because the program stops to run "correctly".
Although I'm biased towards the library implementer's view I think I
can understand the user view since I'm also implementing stuff just
using the library. ... and even moving towards a conforming
implementation will be a problem because the implementation I have to
use does not always use the standard interfaces: For example,
'use_facet' takes three arguments instead of one! Of course, this is
only a workaround in the library for a problem with the compiler
(although IMO a bad one: It would be possible to use the standard
syntax even with this compiler at the cost of extra stuff to be done if
a user introduces a new facet; but which user really does?).
The goal of the user is to have just one implementation. The goal of
the library writer is to have multiple implementations with different
advantages. The standard is the compromise between these two.
--
<mailto:dietma...@claas-solutions.de>
<http://www.informatik.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Pete Becker
>
>
> The goal of the user is to have just one implementation.
Not if the user has any sense. Having only one implementation makes it
much less likely that there will be improvements made in that
implementation, which is what I said in the first place. Using only one
implementation makes good sense, provided that you're willing to change
implementations when one comes along that is significantly better than
the one you're using.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Tony
> Tony wrote:
> >
> > I gave up on Borland's version of STL (actually by Rogue-Wave) for
> > STLPort and never looked back. It got rid of many headaches for me.
> >
>
> What headaches did you have, and in what way did STLPort get rid of
> them? Or is this going to continue to be a fact-free discussion?
I think some of them are given at the STLPort site to which I refer you
to and were fixed by the STLPort. (I remember getting weird compiler
extension errors (closures etc) with the supplied libs). That was quite
awhile ago.
Tony
Tony
> Philip Brabbin wrote:
> > So, here goes .... why doesn't the C++ committee adopt a standard
> > implementation, against which defect/bug reports could be raised, and
> > extensions proposed ? Maybe it's all just a question of funding ???????
I raised the same question about "reference implementations" a few months
ago (in comp.std.c++ ?) as related to the entire language standard. The
thread may answer your questions as opposed to rehashing the issues (not
that that may not be good though).
(aside, perhaps related)
I think the thread ended when I asked if some interaction between
standards comittees and vendors exist that necessarily cause standards to
be complex. I pondered why a two-level standard, for instance, would be
better so that no small vendor would be locked out of developing a
compiler at the Level I (Lite) level while MegaCompiler Corp could
implement the Level II standard (all the bells, whistles and knobs). As
I recall, not many wanted to entertain the idea for some reason.
Tony
template containers and where they can be applied in my products with the
goal of reducing the usage of "advanced" C++ features like templates.
Why? Because I think simple is better and might want to trade any
benefits given by STL for a simpler compiler implementation.
Pete Becker
>
> In article <3751B894...@acm.org>, peteb...@acm.org says...
> > Tony wrote:
> > >
> > > I gave up on Borland's version of STL (actually by Rogue-Wave) for
> > > STLPort and never looked back. It got rid of many headaches for me.
> > >
> >
> > What headaches did you have, and in what way did STLPort get rid of
> > them? Or is this going to continue to be a fact-free discussion?
>
> I think some of them are given at the STLPort site to which I refer you
> to and were fixed by the STLPort. (I remember getting weird compiler
> extension errors (closures etc) with the supplied libs). That was quite
> awhile ago.
>
You made a public statement that Rogue Wave's implementaiton of STL gave
you headaches. I didn't ask for a marketing statement from a vendor. I
asked what problems you ran into and what STLPort did to get rid of
them. Since you have declined to provide this data, am I correct in
concluding that you cannot back up your claim?
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Steve Clamage
>I pondered why a two-level standard, for instance, would be
>better so that no small vendor would be locked out of developing a
>compiler at the Level I (Lite) level while MegaCompiler Corp could
>implement the Level II standard (all the bells, whistles and knobs). As
>I recall, not many wanted to entertain the idea for some reason.
At the very first meeting of the C++ the subject of a multi-level
standard was discussed. It was unanimously agreed that there
would be a single standard with no "levels of conformance".
Nobody ever raised the question again. I think it is a terrible
idea.
--
Steve Clamage, stephen...@sun.com
Tony
> Tony wrote:
> >
> > In article <3751B894...@acm.org>, peteb...@acm.org says...
> > > Tony wrote:
> > > >
> > > > I gave up on Borland's version of STL (actually by Rogue-Wave) for
> > > > STLPort and never looked back. It got rid of many headaches for me.
> > > >
> > >
> > > What headaches did you have, and in what way did STLPort get rid of
> > > them? Or is this going to continue to be a fact-free discussion?
> >
> > I think some of them are given at the STLPort site to which I refer you
> > to and were fixed by the STLPort. (I remember getting weird compiler
> > extension errors (closures etc) with the supplied libs). That was quite
> > awhile ago.
> >
>
> You made a public statement that Rogue Wave's implementaiton of STL gave
> you headaches.
It did. And ones I couldn't resolve. The swap to SGI STL made them go
away and I was able to continue on.
> I didn't ask for a marketing statement from a vendor.
??? I didn't make one.
> I
> asked what problems you ran into and what STLPort did to get rid of
> them.
And I said what I remembered. The link (?) errors disappeared when I
changed libs (I don't remember what they were but do know they were
relatively obscure). Don't ask me why, they just did. I'm not going to
try and use RW STL again and reproduce a detailed problem report for you
(else I'd want to get paid, but don't have time anyway). You see, some
of us just USE the lib and don't revolve around the intracies and details
like perhaps a lib vendor. So don't try and impose your science upon me.
Take the info and use it if you want, or not. It's not something I wish
to spend a lot of time on.
> Since you have declined to provide this data, am I correct in
> concluding that you cannot back up your claim?
I have no need to prove anything to you. I stand on my honesty that I
had problems (else I'd probably still be using the compiler supplied lib)
and that alone is valid information at some level, even if it's just .02.
Sorry if that makes you defensive. If you are calling me a liar, !@*X!
you.
Tony
Tony
says...
> To...@ask.me (Tony) writes:
>
> >I pondered why a two-level standard, for instance, would be
> >better so that no small vendor would be locked out of developing a
> >compiler at the Level I (Lite) level while MegaCompiler Corp could
> >implement the Level II standard (all the bells, whistles and knobs). As
> >I recall, not many wanted to entertain the idea for some reason.
>
> At the very first meeting of the C++ the subject of a multi-level
> standard was discussed.
But what was the rational for the levels?
> It was unanimously agreed that there
> would be a single standard with no "levels of conformance".
> Nobody ever raised the question again.
> I think it is a terrible idea.
Why?
{See my followup to Steve's post. -Herb}
Herb Sutter
>To...@ask.me (Tony) writes:
>>I pondered why a two-level standard, for instance, would be
>>better so that no small vendor would be locked out of developing a
>>compiler at the Level I (Lite) level while MegaCompiler Corp could
>>implement the Level II standard (all the bells, whistles and knobs). As
>>I recall, not many wanted to entertain the idea for some reason.
>
>At the very first meeting of the C++ the subject of a multi-level
>would be a single standard with no "levels of conformance".
>Nobody ever raised the question again. I think it is a terrible
>idea.
Let me offer a firsthand view after seeing both the C++ and SQL
committees in action: I couldn't agree more with Steve that the C++
committee thereby avoided an enormous pitfall. The SQL92 standard had
levels of conformance and, due in large part to that, there is today to
the best of my knowledge still no vendor with a complete implementation
of SQL92. That's right: As of 1999, the SQL92 standard has never been
fully implemented. Each vendor has generally implemented the Core level
features and a mix-and-match of higher levels as they saw fit. [Caveat:
The other major reason why SQL92 has never been fully implemented is
that it was too big; but don't discount levels as an equally major
factor, because levels created an excuse not to implement all of a big
standard.]
One of the major structural changes in SQL99 was to abandon the
"leveled/stratified" structure in favour of a "flower petal" structure
of a core foundation with multiple optional module; I fear, however,
that in practice the new model will still be almost as bad as the old.
Indeed, each of the last several meetings of ANSI H2 (database, SQL) has
included thoughtful discussion about whether the committee and the
standard will even continue to be relevant with/after SQL99.
I'm really glad that we've avoided levels of conformance in C++. What
use is a standard if there are many ways to conform to it? As Tanenbaum
said with irony: "The nice thing about standards is that there are so
many to choose from." It is refreshing that there is presently only one
C++, and this is likely to remain so because there is refreshingly loud
opposition at committee meetings whenever someone hints (even with the
purest of motives) at defining a "subset" of the standard.
Herb
---
Herb Sutter (mailto:hsu...@peerdirect.com)
PeerDirect Inc. 2695 North Sheridan Way, Suite 150
www.peerdirect.com Mississauga Ontario Canada L5K 2N6
Bill Seymour
> >
> > > I pondered why a two-level standard, for instance, would
> > > be better so that no small vendor would be locked out of
> > > developing a compiler at the Level I (Lite) level while
> > > MegaCompiler Corp could implement the Level II standard
> > > (all the bells, whistles and knobs).
> >
> >
> > It was unanimously agreed that there would be a single standard
> > with no "levels of conformance". Nobody ever raised the question
> > again.
> >
> > I think it is a terrible idea.
>
>
Well, it could be that it's a slippery slope that you don't want
to start down at all. Consider, for example, the current COBOL
standard which allows 23,328 combinations of required and optional
modules in conforming implementations. (See p. I-5 of ANSI X3.23-
1985, ISO 1989-1985.)
--Bill Seymour
Matt Austern
> I'm really glad that we've avoided levels of conformance in C++. What
> use is a standard if there are many ways to conform to it? As Tanenbaum
> said with irony: "The nice thing about standards is that there are so
> many to choose from." It is refreshing that there is presently only one
> C++, and this is likely to remain so because there is refreshingly loud
> opposition at committee meetings whenever someone hints (even with the
> purest of motives) at defining a "subset" of the standard.
To some extent, of course, we do have two levels of conformance in
C++. We've got "hosted" and "freestanding" implementations, the main
difference being that a freestanding implementation does not have to
include more than a tiny subset of the standard library. (See section
17.4.1.3, and section 1.4 paragraph 7.)
Tony
says...
> >>I pondered why a two-level standard, for instance, would be
> >>better so that no small vendor would be locked out of developing a
> >>compiler at the Level I (Lite) level while MegaCompiler Corp could
> >>I recall, not many wanted to entertain the idea for some reason.
> >
> >standard was discussed. It was unanimously agreed that there
> >would be a single standard with no "levels of conformance".
> >Nobody ever raised the question again. I think it is a terrible
> >idea.
>
> committees in action: I couldn't agree more with Steve that the C++
> committee thereby avoided an enormous pitfall.
> The SQL92 standard had
> levels of conformance and, due in large part to that, there is today to
> the best of my knowledge still no vendor with a complete implementation
> of SQL92. That's right: As of 1999, the SQL92 standard has never been
> fully implemented. Each vendor has generally implemented the Core level
> features and a mix-and-match of higher levels as they saw fit.
Sounds like a loophole (committee oversight/error) in the standards then.
There should of been a finite number of _well_defined_ levels of
conformance deliniated along the lines of the issues involved.
> I'm really glad that we've avoided levels of conformance in C++. What
> use is a standard if there are many ways to conform to it? As Tanenbaum
> said with irony: "The nice thing about standards is that there are so
> many to choose from."
As it stands, the need felt to subset C++ was great enough that we have
seen EC++ and perhaps even java (and MS is working on something too I
hear). Not to mention all the in-house and personal standards. Perhaps
the way to view the standard is the entire set of possibilities from
which one derives an appropriate subset of features. Maybe will actually
see that in a formal development methodology as one of the first steps
(expanding on a project coding standards document): "define C++ subset
via feature checkoff form". And perhaps see more compiler switches like
we see now for RTTI and exception handling. It's not necessarily a bad
thing giving the user the choice. The key would be to get feedback on
the selections though so that the subsets could form and solidify through
a more natural selection process. (I'm way out on a limb now huh? :) ).
> It is refreshing that there is presently only one
> C++, and this is likely to remain so because there is refreshingly loud
> opposition at committee meetings whenever someone hints (even with the
> purest of motives) at defining a "subset" of the standard.
Well that's perhaps good that there's room for vendors and groups to
value add via subsetting.
Tony
Tony
To me, C++ as it stands, feels like automotive engine control systems of
the late 70's, early 80's. Remember all those vacuum lines?! A lot of
clean up has occurred since then in engine compartments. Elegance
happens after initial invention after some level of
retraction/elimination/redesign/evolution occurs. Maybe C++ doesn't
really need all those vacuum lines either. (Not to even mention hot wire
anamometers!)
Tony
"Inside of C++ there's a great little language trying to come out"
- paraphrasing B. Stroustrup
Pete Becker
> > you headaches.
>
> It did. And ones I couldn't resolve. The swap to SGI STL made them go
> away and I was able to continue on.
I'm very happy for you, but your vague recollections of your personal
experiences are of absolutely no value to someone who is trying to make
a decision about libraries based on sound engineering.
>
> > I didn't ask for a marketing statement from a vendor.
>
> ??? I didn't make one.
No, you referred me to a home page that you said would answer all my
questions. It didn't, which is why I continued to ask.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Andrew Koenig
Tony <To...@ask.me> wrote:
> As it stands, the need felt to subset C++ was great enough that we have
> seen EC++ and perhaps even java (and MS is working on something too I
> hear).
Neither EC++ nor Java is a subset of C++.
--
Andrew Koenig
a...@research.att.com
http://www.research.att.com/info/ark
Steve Clamage
>In article <3758e756...@nntp.netcom.ca>, hsu...@peerdirect.com
>says...
>> On 3 Jun 1999 19:49:21 -0400, cla...@eng.sun.com (Steve Clamage) wrote:
>> >To...@ask.me (Tony) writes:
>> >>I pondered why a two-level standard, for instance, would be
>> >>better ...
>>
>> Let me offer a firsthand view after seeing both the C++ and SQL
>> committees in action: I couldn't agree more with Steve that the C++
>> committee thereby avoided an enormous pitfall.
>> The SQL92 standard had
>> levels of conformance and, due in large part to that, there is today to
>> the best of my knowledge still no vendor with a complete implementation
>> of SQL92. That's right: As of 1999, the SQL92 standard has never been
>> fully implemented. Each vendor has generally implemented the Core level
>> features and a mix-and-match of higher levels as they saw fit.
>Sounds like a loophole (committee oversight/error) in the standards then.
>There should of been a finite number of _well_defined_ levels of
>conformance deliniated along the lines of the issues involved.
I disagree, having firsthand experience with exactly that.
The pascal standard defined exactly two levels of conformance.
Since you couldn't depend on Level 1 features being available,
portable programs could use only Level 0 features. The issue
was futher muddied by Borland Pascal becoming a de facto standard
in the MSDOS world. BP did not implement all of Level 0, yet added
many extensions. In a sense, there were then four levels of pascal:
The two official levels, the common subset of Level 0 and BP, and
BP itself. It was not a happy situation for pascal programmers who
cared about more than one platform.
>> I'm really glad that we've avoided levels of conformance in C++. What
>> use is a standard if there are many ways to conform to it? As Tanenbaum
>> said with irony: "The nice thing about standards is that there are so
>> many to choose from."
>As it stands, the need felt to subset C++ was great enough that we have
>seen EC++ and perhaps even java (and MS is working on something too I
>hear).
Java is not a subset of C++. It is its own language. It has its
own design goals which differ subtantially from the design goals
of C++.
The desire to subset C++ is, in my experience, based primarily
on misunderstanding the language and its implementation.
EC++, for example, intends to be a subset created to eliminate
features that affect efficiency in embedded systems. It eliminates
namespaces, which have no impact on efficiency. It eliminates
exceptions, which have an impact in some systems but do not need
to. If you were intending to create an implementation without
exceptions, you could certainly choose instead an implementation
method that did not add overhead. (Some existing C++ systems
have no exception overhead if you do not use exceptions.)
When people talk about making C++ simpler by eliminating features,
which is what levels of conformance or subsetting do, you never
find any significant agreement about which features should be
eliminated. C++ has the features it does because each of them was
considered important for a broad range of programming.
The C++ Committee has a subgroup working on issues affecting
efficiency in general, including embedded system issues.
The result will be a report with recommendations to users and
implementers about how to accomdate efficiency with fully-
conforming implementations.
It is far better to have a single language standard and let
individuals choose which features they want to use. In our
programming odyssey, it avoids both the Scylla of combinatorial
explosion of subsets, and the Charybdis of least-common-denominator
implemenations.
--
Steve Clamage, stephen...@sun.com
Pete Becker
>
>
> The desire to subset C++ is, in my experience, based primarily
> on misunderstanding the language and its implementation.
>
> EC++, for example, intends to be a subset created to eliminate
> features that affect efficiency in embedded systems. It eliminates
> namespaces, which have no impact on efficiency. It eliminates
> exceptions, which have an impact in some systems but do not need
> to. If you were intending to create an implementation without
> exceptions, you could certainly choose instead an implementation
> method that did not add overhead. (Some existing C++ systems
> have no exception overhead if you do not use exceptions.)
>
EC++ has two goals, not just the one that Steve stated. Its goals are:
eliminating features that affect efficiency, and reducing the complexity
of the language. The latter is the reason that namespaces were
eliminated. As to exceptions, they're part of the standard library. In
particular, iostreams can throw exceptions under appropriate
circumstances. It's not at all easy to eliminate every trace of
exceptions when a user doesn't use them, without some sort of changes to
the compiler and library.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Steve Clamage
>Steve Clamage wrote:
>>
>> The desire to subset C++ is, in my experience, based primarily
>> on misunderstanding the language and its implementation.
>>
>> EC++, for example, intends to be a subset created to eliminate
>> features that affect efficiency in embedded systems. It eliminates
>> namespaces, which have no impact on efficiency. It eliminates
>> exceptions, which have an impact in some systems but do not need
>> to. If you were intending to create an implementation without
>> exceptions, you could certainly choose instead an implementation
>> method that did not add overhead. (Some existing C++ systems
>> have no exception overhead if you do not use exceptions.)
>>
>EC++ has two goals, not just the one that Steve stated. Its goals are:
>eliminating features that affect efficiency, and reducing the complexity
>of the language. The latter is the reason that namespaces were
>eliminated. As to exceptions, they're part of the standard library. In
>particular, iostreams can throw exceptions under appropriate
>circumstances. It's not at all easy to eliminate every trace of
>exceptions when a user doesn't use them, without some sort of changes to
>the compiler and library.
Fair enough, but an embedded system, as we usually understand
the term, is unlikely to want iostreams.
Any program can choose to avoid the other language features that
involve exceptions. If you use the "nothrow" versions of operator
new, or use malloc, or don't allocate dynamic objects, you won't
get memory allocation exceptions.
If you don't use dynamic_cast of references you won't get
bad_cast exceptions or generate any code to deal with them.
I also don't agree that eliminating namespaces reduces the
complexity of the language. You don't have to use namespaces
if you don't want them. For example, you can follow the inclusion
of standard headers with "using namespace std;", getting the
effect of no namespaces while using a standard implementation.
OTOH, if you want to avoid collisions in the global namespace,
C++ namespaces *reduce* the complexity of your programming!
You can leave the standard library in namespace std. You
can put your own code in its own project namespace. No
complicated naming conventions, no name collisions.
A major problem of subsets, as I see it, is trying to find
subsets that make sense. For example, what is an embedded
system? Consider a computer chip embedded in a wristwatch, the
ignition system of a car, a rice cooker, a microwave oven --
those systems will have little use for much of the standard
library, or indeed many of the "bigger" features of C++.
But what about a digital video camera, an interactive TV set-top
box, or a point-of-sale terminal? Those embedded systems could
certainly make use of those "bigger" C++ features.
--
Steve Clamage, stephen...@sun.com
Herb Sutter
>To...@ask.me (Tony) writes:
>>In article <3758e756...@nntp.netcom.ca>, hsu...@peerdirect.com
>>says...
>>> committees in action: I couldn't agree more with Steve that the C++
>>> committee thereby avoided an enormous pitfall.
>>> The SQL92 standard had
>>> levels of conformance and, due in large part to that, there is today to
>>> the best of my knowledge still no vendor with a complete implementation
>>> of SQL92. That's right: As of 1999, the SQL92 standard has never been
>>> fully implemented. Each vendor has generally implemented the Core level
>>> features and a mix-and-match of higher levels as they saw fit.
>>
>>Sounds like a loophole (committee oversight/error) in the standards then.
>>There should of been a finite number of _well_defined_ levels of
>>conformance deliniated along the lines of the issues involved.
Yes, that's the point: There were a small number of well defined levels.
The result was that vendors have implemented the Core level features
(the full lowest level) and a mix-and-match of higher levels as they saw
fit (usually never enough to fully conform to any higher level).
>I disagree, having firsthand experience with exactly that.
>The pascal standard defined exactly two levels of conformance.
>Since you couldn't depend on Level 1 features being available,
>portable programs could use only Level 0 features.
Bingo. Same issue with SQL. Steve's summary is very well crafted:
>It is far better to have a single language standard and let
>individuals choose which features they want to use. In our
>programming odyssey, it avoids both the Scylla of combinatorial
>explosion of subsets, and the Charybdis of least-common-denominator
>implemenations.
---
Herb Sutter (mailto:hsu...@peerdirect.com)
PeerDirect Inc. 2695 North Sheridan Way, Suite 150
www.peerdirect.com Mississauga Ontario Canada L5K 2N6
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Pete Becker
>
>
> I also don't agree that eliminating namespaces reduces the
> complexity of the language. You don't have to use namespaces
> if you don't want them. For example, you can follow the inclusion
> of standard headers with "using namespace std;", getting the
> effect of no namespaces while using a standard implementation.
But the compiler still has to know about them, and that makes it more
complicated.
>
> A major problem of subsets, as I see it, is trying to find
> subsets that make sense. For example, what is an embedded
> system? Consider a computer chip embedded in a wristwatch, the
> ignition system of a car, a rice cooker, a microwave oven --
> those systems will have little use for much of the standard
> library, or indeed many of the "bigger" features of C++.
> But what about a digital video camera, an interactive TV set-top
> box, or a point-of-sale terminal? Those embedded systems could
> certainly make use of those "bigger" C++ features.
Yes, but your'e quibbling over the name. The companies that developed
the EC++ standard deal mostly with various medium-sized consumer
products, and felt that for that segment what they produced was a
workable set of features. Nobody was attempting to produce a
specification that would be optimal for everything that could be labeled
"embedded."
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Tony
> > seen EC++ and perhaps even java (and MS is working on something too I
> > hear).
>
I didn't mean it that literally (although I though EC++ indeed was a
subset). Some alternative language products may have been unnecessary
with an "EZ C++" or "C++ Lite".
Tony
Tony
says...
> To...@ask.me (Tony) writes:
>
> >In article <3758e756...@nntp.netcom.ca>, hsu...@peerdirect.com
> >says...
> >> >To...@ask.me (Tony) writes:
> >> >>better ...
> >>
> >> committees in action: I couldn't agree more with Steve that the C++
> >> committee thereby avoided an enormous pitfall.
> >> The SQL92 standard had
> >> levels of conformance and, due in large part to that, there is today to
> >> the best of my knowledge still no vendor with a complete implementation
> >> of SQL92. That's right: As of 1999, the SQL92 standard has never been
> >> fully implemented. Each vendor has generally implemented the Core level
> >> features and a mix-and-match of higher levels as they saw fit.
>
> >Sounds like a loophole (committee oversight/error) in the standards then.
> >There should of been a finite number of _well_defined_ levels of
> >conformance deliniated along the lines of the issues involved.
>
> The pascal standard defined exactly two levels of conformance.
> Since you couldn't depend on Level 1 features being available,
> portable programs could use only Level 0 features.
Properly "handled", that scenario shouldn't be an issue. Borland and MS
would love to do the high end implementation and sell complexity, while
Joe's Compilers wouldn't. And the products fit different segments.
(This is getting hypothetical).
> >> I'm really glad that we've avoided levels of conformance in C++. What
> >> use is a standard if there are many ways to conform to it? As Tanenbaum
> >> said with irony: "The nice thing about standards is that there are so
> >> many to choose from."
>
> >As it stands, the need felt to subset C++ was great enough that we have
> >seen EC++ and perhaps even java (and MS is working on something too I
> >hear).
>
> Java is not a subset of C++. It is its own language. It has its
> own design goals which differ subtantially from the design goals
> of C++.
I know. But it's a competing language product.
> The desire to subset C++ is, in my experience, based primarily
> on misunderstanding the language and its implementation.
>
> EC++, for example, intends to be a subset created to eliminate
> features that affect efficiency in embedded systems.
I know.
> When people talk about making C++ simpler by eliminating features,
> which is what levels of conformance or subsetting do, you never
> find any significant agreement about which features should be
> eliminated.
Sounds like more discussion is necessary then. My concern was compiler
implementation difficulty (no Small-C++ compiler possible for sure right?
Only big-vendors can afford to implement?)
> The C++ Committee has a subgroup working on issues affecting
> efficiency in general, including embedded system issues.
> The result will be a report with recommendations to users and
> implementers about how to accomdate efficiency with fully-
> conforming implementations.
"Performance, performance, performance". What about "elegance" or
"simplicity" (usage and compiler implementation?
> It is far better to have a single language standard and let
> individuals choose which features they want to use.
What about "design for manufacture"?
Tony
> Tony wrote:
> >
> > In article <7j6j75$2l0$1...@engnews1.eng.sun.com>, cla...@eng.sun.com
> > says...
> > > To...@ask.me (Tony) writes:
> > >
> > > > I pondered why a two-level standard, for instance, would
> > > > developing a compiler at the Level I (Lite) level while
> > > > MegaCompiler Corp could implement the Level II standard
> > > > (all the bells, whistles and knobs).
> > >
> > >
> > > It was unanimously agreed that there would be a single standard
> > > with no "levels of conformance". Nobody ever raised the question
> > > again.
> > >
> > > I think it is a terrible idea.
> >
> >
>
> Well, it could be that it's a slippery slope that you don't want
> to start down at all. Consider, for example, the current COBOL
> standard which allows 23,328 combinations of required and optional
> modules in conforming implementations. (See p. I-5 of ANSI X3.23-
> 1985, ISO 1989-1985.)
Don't be an extremist. No one (at least I didn't) recommend subsets of
all permutations of the available C++ features. _My_ concern was that
the final standard endend up being a big vendor standard given the
complexity of implementation required (just a feeling).
Andrew Koenig
Tony <To...@ask.me> wrote:
> > Neither EC++ nor Java is a subset of C++.
> I didn't mean it that literally (although I though EC++ indeed was a
> subset).
That is a common misconception.
--
Andrew Koenig
a...@research.att.com
http://www.research.att.com/info/ark
Steve Clamage
>Steve Clamage wrote:
>>
>> I also don't agree that eliminating namespaces reduces the
>> complexity of the language. You don't have to use namespaces
>> if you don't want them. For example, you can follow the inclusion
>> of standard headers with "using namespace std;", getting the
>> effect of no namespaces while using a standard implementation.
>But the compiler still has to know about them, and that makes it more
>complicated.
True. I meant to say that I was speaking from the programmer's
perspective, not the compiler-writer's perspective.
But if you have a compiler that does not recognize namespaces,
you cannot write code using the standard library that will
compile with a standard compiler, or vice-versa.
>> A major problem of subsets, as I see it, is trying to find
>> subsets that make sense. For example, what is an embedded
>> system? Consider a computer chip embedded in a wristwatch, the
>> ignition system of a car, a rice cooker, a microwave oven --
>> those systems will have little use for much of the standard
>> library, or indeed many of the "bigger" features of C++.
>> But what about a digital video camera, an interactive TV set-top
>> box, or a point-of-sale terminal? Those embedded systems could
>> certainly make use of those "bigger" C++ features.
>Yes, but your'e quibbling over the name. The companies that developed
>the EC++ standard deal mostly with various medium-sized consumer
>products, and felt that for that segment what they produced was a
>workable set of features. Nobody was attempting to produce a
>specification that would be optimal for everything that could be labeled
>"embedded."
OK, so now you have a special language closely related to C++ with
a small number of compilers that compile it. Some standard C++ code
won't compile with these compilers, and some code that these
compilers accept won't be accepted by a standard-conforming compiler.
If you want to move your code to another system -- e.g., change the
CPU in the embedded system -- you must either find or fund another
EC++ compiler, or modify your code. If you still need to support
the previous EC++ system, you have two versions of all your code,
not just the system-specific parts.
Suppose instead you used a standard C++ compiler and wrote in the
subset of C++ that meets your needs. The parts of your code that
were not specific to the system would compile anywhere, and you
could import code from anywhere. If you want to change CPUs,
you pick another off-the-shelf compiler. If you discover that
parts of C++ you weren't using would better serve your needs,
you can just start using them.
These points, after all, are the reason for a single standard.
I can appreciate that when EC++ was first proposed, the standard
was not complete, the language definition was under development,
and different compilers implemented different versions and subsets
of C++. The idea of a stable subset no doubt was appealing.
But even then, you could write in the cfront 3.0 subset of C++
and your code would work with nearly all compilers. You could
avoid those parts of the language that were known to vary
among implementations.
I remain unconvinced that EC++ or similar approaches serve
any useful purpose.
--
Steve Clamage, stephen...@sun.com
Tony
> In article <MPG.11c51885c...@netnews.worldnet.att.net>,
> Tony <To...@ask.me> wrote:
>
> > > Neither EC++ nor Java is a subset of C++.
>
> > I didn't mean it that literally (although I though EC++ indeed was a
> > subset).
>
> That is a common misconception.
Why isn't it? What makes EC++ NOT a subset?
Tony
Tony
says...
> Yes, that's the point: There were a small number of well defined levels.
> The result was that vendors have implemented the Core level features
> (the full lowest level) and a mix-and-match of higher levels as they saw
> fit (usually never enough to fully conform to any higher level).
That's an infrastructure development problem.
{...exacerbated by the state of the standard, yes. :) -hps}
> >I disagree, having firsthand experience with exactly that.
> >The pascal standard defined exactly two levels of conformance.
> >Since you couldn't depend on Level 1 features being available,
> >portable programs could use only Level 0 features.
>
> Bingo. Same issue with SQL. Steve's summary is very well crafted:
>
> >It is far better to have a single language standard and let
> >individuals choose which features they want to use. In our
> >programming odyssey, it avoids both the Scylla of combinatorial
> >explosion of subsets, and the Charybdis of least-common-denominator
> >implemenations.
That's a case for all of the complexity all of the time though and also
ensures only big vendors get to participate in the market. Complexity is
being rewarded.
Phil McRevis
<MPG.11bf82ac4...@netnews.worldnet.att.net> thusly:
>Long term, if I have the time and resources, I'm going to look into non-
>template containers and where they can be applied in my products with the
>goal of reducing the usage of "advanced" C++ features like templates.
>Why? Because I think simple is better and might want to trade any
>benefits given by STL for a simpler compiler implementation.
There is a simple way to achieve this right now: use C.
--
http://www.xmission.com/~legalize Legalize Adulthood!
lega...@xmission.com
``Ain't it funny that they all fire the pistol, <URL: http://
at the wrong end of the race?''--PDBT www.eden.com/~thewho>
Valentin Bonnard
> In article <FD0wz...@research.att.com>, a...@research.att.com says...
> > In article <MPG.11c51885c...@netnews.worldnet.att.net>,
> > Tony <To...@ask.me> wrote:
> >
> > > > Neither EC++ nor Java is a subset of C++.
> >
> > > I didn't mean it that literally (although I though EC++ indeed was a
> > > subset).
> >
> > That is a common misconception.
>
> Why isn't it? What makes EC++ NOT a subset?
Hint: EC++ has no namespaces, and a standard library
Hint: ostream is a class in EC++, a typedef in C++
(in the correct namespace, of course)
--
Valentin Bonnard
Darin Adler
I don't know the full answer, but I have a guess. Here's an example:
int* p = new int;
In EC++, p can be 0. In C++, p can never be 0, because new is guaranteed to
throw an exception if it can't allocate the storage.
This shows a way that EC++ is different -- not a subset, but subtly
different.
It's possible that the EC++ designers thought they could subset standard C++
by removing exceptions and still retain "new", but I don't think that can be
done.
-- Darin
Valentin Bonnard
> As it stands, the need felt to subset C++ was great enough that
> we have seen EC++ and perhaps even java
There is much to be said about EC++, but I doubt
that moderators will let me do that.
It's simply ridiculous to view Java as an attempt
to subset C++ (Java has almost nothing to do with
C++, except for syntax).
> And perhaps see more compiler switches like
> we see now for RTTI and exception handling.
No, please, no more switches !
Compilers have way to many switches, and there is to
much code out there to remove them.
Ideally compilers would have a just an optimisation
switch, one for debuging, one for profiling and
that's it.
--
Valentin Bonnard
Pete Becker
>
> Pete Becker <peteb...@acm.org> writes:
>
> >Steve Clamage wrote:
> >>
> >> I also don't agree that eliminating namespaces reduces the
> >> complexity of the language. You don't have to use namespaces
> >> if you don't want them. For example, you can follow the inclusion
> >> of standard headers with "using namespace std;", getting the
> >> effect of no namespaces while using a standard implementation.
>
> >But the compiler still has to know about them, and that makes it more
> >complicated.
>
> True. I meant to say that I was speaking from the programmer's
> perspective, not the compiler-writer's perspective.
Once again making unwarranted assumptions about the audience that EC++
was intended for. But don't feel bad -- that's a common ailment. <g>
>
> >Yes, but your'e quibbling over the name. The companies that developed
> >the EC++ standard deal mostly with various medium-sized consumer
> >products, and felt that for that segment what they produced was a
> >workable set of features. Nobody was attempting to produce a
> >specification that would be optimal for everything that could be labeled
> >"embedded."
>
> OK, so now you have a special language closely related to C++ with
> a small number of compilers that compile it. Some standard C++ code
> won't compile with these compilers, and some code that these
> compilers accept won't be accepted by a standard-conforming compiler.
Yes, that's correct. Standard C++ code does not compile with many of the
compilers that are available for embedded systems today. EC++ is a small
change, if any, from what those compilers currently support. Adding full
C++ support would be much more expensive, and would provide no
discernable benefit.
> If you want to move your code to another system -- e.g., change the
> CPU in the embedded system -- you must either find or fund another
> EC++ compiler, or modify your code. If you still need to support
> the previous EC++ system, you have two versions of all your code,
> not just the system-specific parts.
Yup. And you still haven't had to pay the cost of adding features that
you don't intend to use.
>
> Suppose instead you used a standard C++ compiler and wrote in the
> subset of C++ that meets your needs. The parts of your code that
> were not specific to the system would compile anywhere, and you
> could import code from anywhere. If you want to change CPUs,
> you pick another off-the-shelf compiler. If you discover that
> parts of C++ you weren't using would better serve your needs,
> you can just start using them.
How many times does the average rice cooker change CPUs? My guess is
zero.
> I remain unconvinced that EC++ or similar approaches serve
> any useful purpose.
And the folks who developed EC++ continue to successfully write software
for their embedded systems, without having the world fall down around
them just because the folks who don't like EC++ proclaim that they're in
a state of sin.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Pete Becker
>
>
> Why isn't it? What makes EC++ NOT a subset?
>
The fact that you have to write three lines of otherwise unnecessary
code near the top of each source file if you want to be able to compile
EC++ code as standard C++:
#ifdef __cplusplus
using namespace std;
#endif
Of course, this can also be fixed by a simple change to the definition
of EC++, so simply allow 'using namespace std;', and ignore it.
Pete Becker
>
>
> But if you have a compiler that does not recognize namespaces,
> you cannot write code using the standard library that will
> compile with a standard compiler, or vice-versa.
Sure you can:
#ifdef __cplusplus
using namespace std;
#endif
--
Tony
says...
> To...@ask.me (Tony) spake the secret code
> <MPG.11bf82ac4...@netnews.worldnet.att.net> thusly:
>
> >Long term, if I have the time and resources, I'm going to look into non-
> >template containers and where they can be applied in my products with the
> >goal of reducing the usage of "advanced" C++ features like templates.
> >Why? Because I think simple is better and might want to trade any
> >benefits given by STL for a simpler compiler implementation.
>
> There is a simple way to achieve this right now: use C.
Well I'm not an extremist--I want most of the C++ features.
Tony
Tony
says...
> I remain unconvinced that EC++ or similar approaches serve
> any useful purpose.
How about preventing only big-vendor or high effort groups from being the
only ones who can build compilers?
Steve Clamage
>> >It is far better to have a single language standard and let
>> >individuals choose which features they want to use. In our
>> >programming odyssey, it avoids both the Scylla of combinatorial
>> >explosion of subsets, and the Charybdis of least-common-denominator
>> >implemenations.
>That's a case for all of the complexity all of the time though and also
>ensures only big vendors get to participate in the market. Complexity is
>being rewarded.
You keep making this completely false claim, but since no one
else has pointed out how wrong it is, I guess I have to.
Two tiny companies, fewer than 10 people each, created the C++
compiler front ends in use by many of the big vendors. The
exceptions are Microsoft, IBM, who grew their own compilers,
and HP who now uses the Taligent compiler. As far as I know,
the other major vendors bought their compilers and got
maintenance on them from TauMetric Corp (now defunct)
or Edison Design Group.
I stress the "front end" concept, because the remainder of the
compiler is target-specific, not language-specific, and is
typically shared by multiple compilers for the same target.
TauMetric supplied C++ compilers to Borland, Sun, and some
others whom I'm not allowed to mention.
You can visit EDG's web page to get a partial list of their
clients.
Most of the standard C++ libraries, including Microsoft's, come
from either Rogue Wave, which is not a giant company, or from
Dinkumware, which is a tiny company.
--
Steve Clamage, stephen...@sun.com
Christopher Eltschka
[...]
> Ideally compilers would have a just an optimisation
> switch, one for debuging, one for profiling and
> that's it.
I disagree: Useful switches are f.ex.
- switches to stop at various stages (esp. after preprocessing).
- the define switch
- warning switches
- the output name switch
Also, model switches can be useful: Should your compiler make use
of the new CPU's instructions if it would be a win, or should the
program run on older versions of the CPU as well?
Note that this is independant of the optimisation option itself
(which just tells the compiler how hard - if at all - it should
try to optimize. You can try to optimize very hard, but to still
avoid certain instructions).
Andrew Koenig
Tony <To...@ask.me> wrote:
> Why isn't it? What makes EC++ NOT a subset?
Here's a simple example. Suppose I want to execute
cout << "Hello, world" << endl;
I can do so in standard C++ by writing, for example:
#include <iostream>
int main()
{
using namespace std;
cout << "Hello, world" << endl;
}
However, this approach won't work in EC++ because EC++ doesn't support
namespaces. So how do I write this program in EC++ in such a way
as to be a standard C++ program as well? I don't think it's possible,
except by using the preprocessor to cause a C++ compiler to compile
one version and an EC++ compiler to compile another.
I'm sure someone will correct me if I'm mistaken.
--
Andrew Koenig
a...@research.att.com
http://www.research.att.com/info/ark
Herb Sutter
>> Suppose instead you used a standard C++ compiler and wrote in the
>> subset of C++ that meets your needs. The parts of your code that
>> were not specific to the system would compile anywhere, and you
>> could import code from anywhere. If you want to change CPUs,
>> you pick another off-the-shelf compiler. If you discover that
>> parts of C++ you weren't using would better serve your needs,
>> you can just start using them.
>
>How many times does the average rice cooker change CPUs? My guess is
>zero.
How many times does the average rice cooker software developer have
internal libraries that are reused when targeting other devices that
have other CPUs? My guess is lots.
>> I remain unconvinced that EC++ or similar approaches serve
>> any useful purpose.
>
>And the folks who developed EC++ continue to successfully write software
>for their embedded systems, without having the world fall down around
>them just because the folks who don't like EC++ proclaim that they're in
>a state of sin.
Unfair. No one says that developing a competing language and using it is
morally wrong. The concern is simply that multiple C++ dialects will
unarguably encourage divergence into multiple subcamps whereas today I'd
wager that 95%+ of all C++ programmers use a compiler which closely
approximates the one standard. Divergence into even two camps, with 60%
and 40% relative market share, is a bad thing.
The point that divergence is not in the best interests of the C++
language and the C++ community as a whole is, I feel, unassailable in
the lights of numerous counterexamples, notably Unix, X-based GUIs, and
SQL. Ask any developer who has to support multiple product versions to
support multiple Unix flavours, multiple X flavours, and multiple SQL
flavours whether they're really well served by "diversity." (I am in the
last (SQL) camp as a user, as a tools developer, and as a standards
committee member, and boy it ain't pretty.)
The same examples do, however, demonstrate that diversity due to
multiple standards or conformance levels is in the best interests of the
vendors. This is not intended to be a dig at anyone; it is merely an
observation, and I'm thinking primarily of database vendors as I write
this, and I know they themselves agree with me because they've told me
so. Indeed, in SQL we just added Yet Another Variant whereby a
conforming implementation of SQL/CLI (ODBC) is permitted to emit an
exception if the user tries to write a zero-length but non-null entry
into a VARCHAR field. Why? Because specifically Sybase's and Oracle's
products still don't distinguish between null and zero-length VARCHARs.
This is plainly a product bug that now has been blessed and enshrined in
the standard as an option, further encouraging SQL dialect divergence.
That divergence absolutely clearly and irrefutably is not a good thing
for users, but it just as clearly is a good thing for vendors.
Turn Steve's point around: Where would Unix and X and SQL be today if
there were indeed a single inclusive standard and everyone wrote in the
subset that suited their needs? Guaranteed portability, and almost
certainly no Windows. Indeed, Windows is a perfect counterexample of how
the market benefits by, and chooses, a single and inclusive standard
even if it's inferior, as long as developers can portably use subsets
thereof and run on most targeted (in this case, primarily desktop)
systems.
Please don't get me wrong... I absolutely understand that if an existing
standard, no matter how popular, has problems that makes it
fundamentally unsuitable for a certain class of users, it's not usable
as-is by those users. Fair enough. In this case, though, it still seems
that even for embedded systems developers the option of "use real
standard C++ but only the features you want" is often a realistic
option, even if "define a dialect" may have some additional advantages.
But do those advantages outweigh the advantages of being much more
easily portable and promoting a single standard -- avoiding divergence
and disintegration of portability as with Unix, X, and SQL -- even for
the developers who might benefit in some minor ways in the short term by
this solution over the "use only the standard features you want"
solution?
Herb
---
Herb Sutter (mailto:hsu...@peerdirect.com)
PeerDirect Inc. 2695 North Sheridan Way, Suite 150
www.peerdirect.com Mississauga Ontario Canada L5K 2N6
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Pete Becker
>
> Hint: ostream is a class in EC++, a typedef in C++
And what, exactly, does this distinction mean to users of either
language?
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
David J. Littleboy
Steve Clamage wrote in message <7jjip1$p7k$1...@engnews1.eng.sun.com>...
>
>Suppose instead you used a standard C++ compiler and wrote in the
>subset of C++ that meets your needs. The parts of your code that
>were not specific to the system would compile anywhere, and you
>could import code from anywhere. If you want to change CPUs,
>you pick another off-the-shelf compiler. If you discover that
>parts of C++ you weren't using would better serve your needs,
>you can just start using them.
Your assumption that off-the-shelf compilers would or could exist is wrong
for the segment of the microcontroller market I'm familiar with. Everyone
and his brother over here (in Japan) has their own proprietary-architecture
CPU with it's own bundled application development system. These folks are
currently supplying an assembler, an in-circuit emulator, and maybe a C
compiler. Some of the latter would like to provide more, but just don't have
the resources to deal with full C++. Even if they could purchase a front end
to their own code generators, they'd still be responsible for supporting the
full language, and see that as more than they are capable of (or willing to)
do. That reality (lack of resources) when it is a reality, and perception
(for management who underestimate their software staff) isn't going to
change, even with the stability of the standard and more implementations
around that are closer to the standard.
As I see it, EC++ would be a large plus for C++, simply in providing an
intermediate step for a large segment of the computer industry that is
otherwise simply not going to move to C++. Once a company (or especially a
programmer) has experience with EC++ both will be a lot closer to being able
to deal with full C++, and the programmer is going to be shouting loudly for
templates and the full library*. That's major progress towards wider
acceptance and adoption of C++, which I presume is of serious interest to
those most vociferously objecting to EC++.
David J. Littleboy
PS: Apologies in advance, but the opposition to EC++ really looks like a
classic case of shooting oneself in the foot.
*: Which brings up another point: programming staff that has no experience
with C++ asking for C++ is going to be a lot less persuasive to managers
than programming staff that has been using EC++. EC++ is exactly the right
thing to bootstrap this segment of the industry.
Phil McRevis
>> There is a simple way to achieve this right now: use C.
>
>Well I'm not an extremist--I want most of the C++ features.
Then your solution is simple: use the features you want to use and
don't use the rest. Simply because a feature is provided in C++
doesn't constitute a necessity to use it. Furthermore, your desire
for "C++ with less" can be had by simply imposing a little
self-discipline. You've decided that STL components bring too much
baggage? Then institute a clause in the coding standards at your shop
that "thou shalt not use STL". Similarly, for other features of C++
that you consider burdensome. Ultimately you can pare down all those
pesky extra features in C++ and get back to C with type checking.
--
http://www.xmission.com/~legalize Legalize Adulthood!
lega...@xmission.com
``Ain't it funny that they all fire the pistol, <URL: http://
at the wrong end of the race?''--PDBT www.eden.com/~thewho>
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Tony
says...
Someone's gotta keep 'em honest. Even with the above, the
number participants are few because of the complexity, I believe. It's
_hardly_ "completely false" that some degree of technological
inaccessibility exists.
Tony
Tony
> > Why isn't it? What makes EC++ NOT a subset?
>
>
> int* p = new int;
>
> In EC++, p can be 0. In C++, p can never be 0, because new is guaranteed to
> throw an exception if it can't allocate the storage.
>
> This shows a way that EC++ is different -- not a subset, but subtly
> different.
>
> It's possible that the EC++ designers thought they could subset standard C++
> by removing exceptions and still retain "new", but I don't think that can be
> done.
Hmmm. I have a compiler switch to turn off exceptions. Is my compiler
just out of date? (I don't use exceptions either, BTW).
Tony
> Tony wrote:
>
> > As it stands, the need felt to subset C++ was great enough that
> > we have seen EC++ and perhaps even java
>
> There is much to be said about EC++, but I doubt
> that moderators will let me do that.
>
> It's simply ridiculous to view Java as an attempt
> to subset C++ (Java has almost nothing to do with
> C++, except for syntax).
I wouldn't be surprised if it started that way. In either case, someone
thought an alternative was necessary, which doesn't bode well for C++.
> > And perhaps see more compiler switches like
> > we see now for RTTI and exception handling.
>
> No, please, no more switches !
>
> Compilers have way to many switches, and there is to
> much code out there to remove them.
Too many yes. But a few good ones would be nice.
> Ideally compilers would have a just an optimisation
> switch, one for debuging, one for profiling and
> that's it.
And one for C++ Lite. :)
Tony
>
>
> cout << "Hello, world" << endl;
>
> I can do so in standard C++ by writing, for example:
>
> #include <iostream>
>
> int main()
> {
> using namespace std;
> cout << "Hello, world" << endl;
> }
>
> However, this approach won't work in EC++ because EC++ doesn't support
> namespaces. So how do I write this program in EC++ in such a way
> as to be a standard C++ program as well? I don't think it's possible,
> except by using the preprocessor to cause a C++ compiler to compile
> one version and an EC++ compiler to compile another.
>
> I'm sure someone will correct me if I'm mistaken.
Hmmm. I guess C++ Lite is still in my future! (I need MI, so EC++ won't
work for me anyway.) :)
Pete Becker
>
> On 11 Jun 1999 08:47:48 -0400, Pete Becker <peteb...@acm.org> wrote:
> >> Suppose instead you used a standard C++ compiler and wrote in the
> >> subset of C++ that meets your needs. The parts of your code that
> >> were not specific to the system would compile anywhere, and you
> >> could import code from anywhere. If you want to change CPUs,
> >> you pick another off-the-shelf compiler. If you discover that
> >> parts of C++ you weren't using would better serve your needs,
> >> you can just start using them.
> >
> >How many times does the average rice cooker change CPUs? My guess is
> >zero.
>
> How many times does the average rice cooker software developer have
> internal libraries that are reused when targeting other devices that
> have other CPUs? My guess is lots.
Yup, you've picked a hole in a glib response to a non-issue.
>
> >> I remain unconvinced that EC++ or similar approaches serve
> >> any useful purpose.
> >
> >And the folks who developed EC++ continue to successfully write software
> >for their embedded systems, without having the world fall down around
> >them just because the folks who don't like EC++ proclaim that they're in
> >a state of sin.
>
> Unfair. No one says that developing a competing language and using it is
> morally wrong.
You obviously haven't been reading some of the attacks on EC++.
> The concern is simply that multiple C++ dialects will
> unarguably encourage divergence into multiple subcamps whereas today I'd
> wager that 95%+ of all C++ programmers use a compiler which closely
> approximates the one standard. Divergence into even two camps, with 60%
> and 40% relative market share, is a bad thing.
Guess what? It's much easier to write EC++ code that also compiles with
just about any standard C++ compiler on the market today than it is to
write standard C++ code that does the same.
>
> The point that divergence is not in the best interests of the C++
> language and the C++ community as a whole is, I feel, unassailable in
> the lights of numerous counterexamples, notably Unix, X-based GUIs, and
> SQL. Ask any developer who has to support multiple product versions to
> support multiple Unix flavours, multiple X flavours, and multiple SQL
> flavours whether they're really well served by "diversity." (I am in the
> last (SQL) camp as a user, as a tools developer, and as a standards
> committee member, and boy it ain't pretty.)
Ask any vendor who has to support multiple implementations of the C++
standard or the C standard what's involved. Portability as an absolute
is a myth. We do what we can to enhance portability, and we deal with
porting problems when they come up. Portability is only one of the many
goals in system development. Time to market and price are important,
too, and focusing exclusively on portability is a pretty good way to end
up bankrupt.
>
> The same examples do, however, demonstrate that diversity due to
> multiple standards or conformance levels is in the best interests of the
> vendors. This is not intended to be a dig at anyone; it is merely an
> observation, and I'm thinking primarily of database vendors as I write
> this, and I know they themselves agree with me because they've told me
> so. Indeed, in SQL we just added Yet Another Variant whereby a
> conforming implementation of SQL/CLI (ODBC) is permitted to emit an
> exception if the user tries to write a zero-length but non-null entry
> into a VARCHAR field. Why? Because specifically Sybase's and Oracle's
> products still don't distinguish between null and zero-length VARCHARs.
And the C standard permits malloc(0) to return a null pointer or a
non-null pointer. Yes, standards contain compromises, in the interest of
commercial viability.
> This is plainly a product bug that now has been blessed and enshrined in
> the standard as an option, further encouraging SQL dialect divergence.
> That divergence absolutely clearly and irrefutably is not a good thing
> for users, but it just as clearly is a good thing for vendors.
>
> Turn Steve's point around: Where would Unix and X and SQL be today if
> there were indeed a single inclusive standard and everyone wrote in the
> subset that suited their needs?
I have no idea.
> Guaranteed portability, and almost certainly no Windows.
"Guaranteed?" Nonsense. Guessing? Obviously.
> Indeed, Windows is a perfect counterexample of how
> the market benefits by, and chooses, a single and inclusive standard
> even if it's inferior, as long as developers can portably use subsets
> thereof and run on most targeted (in this case, primarily desktop)
> systems.
Surprise, Windows code isn't portable among Windows systems. There are
four widely used distinct versions of Windows, and each has its own
quirks. So the premise that Windows provides a single and inclusive
standard is false. The reason for the success of Windows is in large
part Microsoft's marketing skill.
>
> Please don't get me wrong... I absolutely understand that if an existing
> standard, no matter how popular, has problems that makes it
> fundamentally unsuitable for a certain class of users, it's not usable
> as-is by those users. Fair enough. In this case, though, it still seems
> that even for embedded systems developers the option of "use real
> standard C++ but only the features you want" is often a realistic
> option, even if "define a dialect" may have some additional advantages.
It's very nice of all the big iron folks have such wonderful advice for
those poor, deluded programmers who are stuck in the backwaters of
embedded systems. Gosh, for an investment of just a few hundred thousand
dollars, they can write code just like real programers.
> But do those advantages outweigh the advantages of being much more
> easily portable and promoting a single standard -- avoiding divergence
> and disintegration of portability as with Unix, X, and SQL -- even for
> the developers who might benefit in some minor ways in the short term by
> this solution over the "use only the standard features you want"
> solution?
Yup, you must be right: the folks who developed the EC++ standard were
shortsighted, ignorant, and self-indulgent. Why should we pay any
attention to what they think they need, when we understand their
problems so much better than they do?
Quite frankly, I'm sick of this condescending attitude toward the
developers of the EC++ specification. I'm not one of them, but I have
enough respect for the people who did it to be willing to try to look at
their problems from their perspective, and not insist that they be
theoretically pure in a world of practical consequences.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Pete Becker
>
>
> Indeed, Windows is a perfect counterexample of how
> the market benefits by, and chooses, a single and inclusive standard
> even if it's inferior, as long as developers can portably use subsets
> thereof and run on most targeted (in this case, primarily desktop)
> systems.
Actually, Windows is an example of exactly the same thing as EC++.
Windows NT Workstation is a subset of Windows NT Server. It uses less
disk space, requires less RAM, and costs less. And Windows CE, designed
for embedded systems, is configurable: device developers decide which OS
features they need, and build the OS accordingly, weighing size versus
features.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Andrew Koenig
David J. Littleboy <dav...@gol.com> wrote:
> As I see it, EC++ would be a large plus for C++, simply in providing an
> intermediate step for a large segment of the computer industry that is
> otherwise simply not going to move to C++.
I would be more inclined to agree with that statement if EC++ were indeed
an intermediate step -- that is, if EC++ were a subset of C++.
>From the literature I have seen, I think it is more accurate to say that
EC++ is being offered as an alternative to C++.
--
Andrew Koenig
a...@research.att.com
http://www.research.att.com/info/ark
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Valentin Bonnard
>
> Valentin Bonnard wrote:
>
> [...]
>
> > Ideally compilers would have a just an optimisation
> > switch, one for debuging, one for profiling and
> > that's it.
>
>
> - switches to stop at various stages (esp. after preprocessing).
Fine. These switches can't hurt.
> - the define switch
Usually used with ugly/unreadable conditional compilation
to work around limitations of the compiler/library.
> - warning switches
In an ideal world, the warning are actually errors,
because it's always clear if a code fragment does
what was intended or not. ;-)
And these warning/errors are always on, cause all
programs are perfect.
What is really awful is the mess of switches which
define another, subtly different, language (what the
previous poster proposed).
--
Valentin Bonnard
Dave Abrahams
wrote:
> And what, exactly, does this distinction mean to users of either
> language?
Though I'm not familiar with rules of EC++, I expect that the simplest
answer is that you can forward declare ostream in EC++:
class ostream;
-Dave
David J. Littleboy
>The concern is simply that multiple C++ dialects will
>unarguably encourage divergence into multiple subcamps whereas today I'd
>wager that 95%+ of all C++ programmers use a compiler which closely
>approximates the one standard.
Nobody's arguing for multiple dialects: people are arguing for one radically
limited alternative which provides the basic language improvements C++
offers over C without the rocket science. The whole point of EC++ was to do
this without "encouraging divergence".
There are several points apparent from where I sit (I translate
microcontroller manuals (Japanese to English)) that contradict your basic
assumptions. The first is that EC++ is aimed at a group that doesn't
have C++. The choice isn't between C++ and EC++, it's between C and EC++.
There are lots of places that just don't have the resources to do full C++.
You may not believe that, but a lot of folks who make proprietary
microcontrollers provide all the associated software. Even if they outsource
most of it, they are still responsible for making it work and supporting end
users. They don't feel that they can outsource that responsibility.
Another is that EC++ is such a radical subset that it can't
possibly function as a replacement for C++. The lack of templates is _good_
news. No one is going to think that EC++ is anything other than an interim
language for contexts in which full C++ isn't available. This is a
completely different phenomenon from the sort of divergence you are worried
about.
I'm not arguing that your concern is wrong (I can't even figure out which
version of Linux to look into), I'm arguing that it doesn't apply to EC++.
>The point that divergence is not in the best interests of the C++
>language and the C++ community as a whole is, I feel, unassailable in
>the lights of numerous counterexamples, notably Unix, X-based GUIs, and
>SQL.
> Ask any developer who has to support multiple product versions to
>support multiple Unix flavours, multiple X flavours, and multiple SQL
>flavours whether they're really well served by "diversity." (I am in the
>last (SQL) camp as a user, as a tools developer, and as a standards
>committee member, and boy it ain't pretty.)
Comparing EC++ (which tries to be a subset) and situations in which largely
equivalent products are competing just isn't valid. The C++ standard exists:
no one is talking about modifying it. The goal of the EC++ consortium was to
minimize divergence from the standard. If each and every one of their
members had tried to provide their own C++ subset, every one would be
different. Then you'd see some real divergence.
>Please don't get me wrong... I absolutely understand that if an existing
>standard, no matter how popular, has problems that makes it
>fundamentally unsuitable for a certain class of users, it's not usable
>as-is by those users. Fair enough. In this case, though, it still seems
>that even for embedded systems developers the option of "use real
>standard C++ but only the features you want" is often a realistic
>option, even if "define a dialect" may have some additional advantages.
Again, "use only the features you want" is simply not something a vendor of
a proprietary microcontroller plus development env system can say to their
users. Their product is a closed box, and they really are stuck with a "the
buck stops here" responsibility, which, if the language is full C++, they
just aren't prepared to take on.
And this doesn't even get into the problem that there aren't any C++
libraries that are small enough to actually fit in the memory available in
their products..
Put another way, it's the microcontroller plus development env system
vendor, not the end user, who would have to determine which features are not
provided. At which point, you really would have seriously divergent
dialects. And one point of EC++ was to avoid this divergence and to make
sure that the subsetting got done right.
>But do those advantages outweigh the advantages of being much more
>easily portable and promoting a single standard -- avoiding divergence
>and disintegration of portability as with Unix, X, and SQL -- even for
>the developers who might benefit in some minor ways in the short term by
>this solution over the "use only the standard features you want"
>solution?
Well, since the "use only the standard features you want" solution isn't an
option, and the EC++ community is making a point of avoiding the Unix and
SQL problems you mentioned (which are largely do to different _vendors_
doing the same thing differently), EC++ sure looks like the right idea...
Again, from where I sit, EC++ looks like a large plus for C++ as a whole. It
brings a large subset of the computer community into the C++ camp, giving
these folks a completely valid background that will make moving to full
C++ far easier when their resources allow it.
David J. Littleboy
Valentin Bonnard
> > Ideally compilers would have a just an optimisation
> > switch, one for debuging, one for profiling and
> > that's it.
>
> And one for C++ Lite. :)
My point is that switches which change the code generation
quality, or even the targeted processor, are fine, but every
switch which changes the language being compiled hurts.
--
Valentin Bonnard
David J. Littleboy
Andrew Koenig wrote in message ...
Once again appologies in advance. In the following I accuse Andrew Koenig of
quibbling, because I seriously think he is. The points he raises don't
address the needs of that segment of the computer community that thinks it
needs EC++.
>In article <h3i83.897$2b.1...@nnrp.gol.com>,
>David J. Littleboy <dav...@gol.com> wrote:
>
>> As I see it, EC++ would be a large plus for C++, simply in providing an
>> intermediate step for a large segment of the computer industry that is
>> otherwise simply not going to move to C++.
>
>I would be more inclined to agree with that statement if EC++ were indeed
>an intermediate step -- that is, if EC++ were a subset of C++.
As I understand it, EC++ fails to be a subset on one point; namely that the
standard library doesn't live in the std:: namespace. That strikes me as a
quibble because it means that EC++ programs fail to be C++ in that they are
missing one (identical in all cases) line of code.
>>From the literature I have seen, I think it is more accurate to say that
>EC++ is being offered as an alternative to C++.
>--
Our perceptions are vastly different here: I find it hard to believe that
EC++ would find much use outside of the areas it's specifically designed
for. It's an alternative in the sense that for some of the people providing
C on their hardware, EC++ would be a possibility whereas C++ wouldn't. If
you are worried about EC++ being seen as a replacement for C++, that would
strike me as seriously underestimating the last 15 years of work on C++.
Also, as I understand it, there are already C++ implementations for some
embedded systems so there is going to be competition amongst hardware
vendors to provide the full language.
David J. Littleboy
Pete Becker
>
> In article <3761AA49...@acm.org> , Pete Becker <peteb...@acm.org>
> wrote:
>
> > And what, exactly, does this distinction mean to users of either
> > language?
>
> Though I'm not familiar with rules of EC++, I expect that the simplest
> answer is that you can forward declare ostream in EC++:
>
> class ostream;
Ah, you're right.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Pete Becker
>
> In article <MPG.11c7c94c9...@netnews.worldnet.att.net>,
> Tony <To...@ask.me> wrote:
>
> > Why isn't it? What makes EC++ NOT a subset?
>
> Here's a simple example. Suppose I want to execute
>
> cout << "Hello, world" << endl;
>
> I can do so in standard C++ by writing, for example:
>
> #include <iostream>
>
> int main()
> {
> using namespace std;
> cout << "Hello, world" << endl;
> }
>
> However, this approach won't work in EC++ because EC++ doesn't support
> namespaces. So how do I write this program in EC++ in such a way
> as to be a standard C++ program as well? I don't think it's possible,
> except by using the preprocessor to cause a C++ compiler to compile
> one version and an EC++ compiler to compile another.
>
> I'm sure someone will correct me if I'm mistaken.
#include <iostream>
int main()
{
#ifdef __cplusplus
using namespace std;
#endif
cout << "Hello, world" << endl;
Pete Becker
>
> In article <h3i83.897$2b.1...@nnrp.gol.com>,
> David J. Littleboy <dav...@gol.com> wrote:
>
> > As I see it, EC++ would be a large plus for C++, simply in providing an
> > intermediate step for a large segment of the computer industry that is
> > otherwise simply not going to move to C++.
>
> I would be more inclined to agree with that statement if EC++ were indeed
> an intermediate step -- that is, if EC++ were a subset of C++.
Then you'd accept it if the EC++ spec added the requirement that every
translation unit in an EC++ program contain the following line, which
the compiler would ignore:
using namespace std;
Andrew Koenig
Pete Becker <peteb...@acm.org> wrote:
> Quite frankly, I'm sick of this condescending attitude toward the
> developers of the EC++ specification. I'm not one of them, but I have
> enough respect for the people who did it to be willing to try to look at
> their problems from their perspective, and not insist that they be
> theoretically pure in a world of practical consequences.
I have a good deal of sympathy for their perspective, but I do
not like it when they make factually incorrect claims
(such as the claim that EC++ is a subset of C++).
--
Andrew Koenig
a...@research.att.com
http://www.research.att.com/info/ark
Steve Clamage
>Someone's gotta keep 'em honest.
What does that mean?
>Even with the above, the
>number participants are few because of the complexity, I believe.
True enough. It often makes economic sense to buy a working
compiler instead of developing one from scratch. It wouldn't
make much sense to buy a lousy implementation, however.
Any vendor who cared about producing a quality product
would first verify that the purchased compiler worked well.
>It's
>_hardly_ "completely false" that some degree of technological
>inaccessibility exists.
C++ is now a complex language. Producing a good implementation
requires considerable knowledge, experience, and skill. Yet
several good independently-developed implementations exist.
Consider egcs, produced on an unpaid-volunteer basis. Others,
as I said, have been developed and are maintained by very
small companies. What is "completely false" is your claim
that C++ is outside the reach of any but large companies.
--
Steve Clamage, stephen...@sun.com
Steve Clamage
>In article <376042...@wanadoo.fr>, Bonn...@wanadoo.fr says...
>> Tony wrote:
>>
>> It's simply ridiculous to view Java as an attempt
>> to subset C++ (Java has almost nothing to do with
>> C++, except for syntax).
>I wouldn't be surprised if it started that way. In either case, someone
>thought an alternative was necessary, which doesn't bode well for C++.
C++ and Java have entirely different design and usage goals.
Java is an alternative to C++ in the same sense as any other
language where the application areas overlap.
Of course, Java is much more than just a programming language.
Unlike C++, it provides a standard environment and library
primitives suited to developing application programs. (Java
didn't start out that way, but it has evolved in that direction.)
Darin Adler
>>> What makes EC++ NOT a subset (of C++)?
My reply:
>> int* p = new int;
>>
>> In EC++, p can be 0. In C++, p can never be 0, because new is guaranteed to
>> throw an exception if it can't allocate the storage.
In article <MPG.11cb9aee3...@netnews.worldnet.att.net>,
To...@ask.me (Tony) wrote:
> I have a compiler switch to turn off exceptions. [...]
> (I don't use exceptions either, BTW).
It's possible to write standard code that doesn't use exceptions.
But you need to use "new (nothrow)" instead of "new".
I presume that you turn off you compiler's exception switch and use "new",
expecting it to return 0 on a failure rather than raising an exception. If
you do this, you're writing non-standard code that won't necessarily work on
other compilers that conform to the standard. Your code depends on the "no
exceptions" switch and requires this non-standard extension. There's no
guarantee that a conforming standard C++ compiler will have a way to turn
off exceptions, even though there's no requirement that you use exceptions
in your program.
If you instead use "new (nothrow)", you can write standard code that will
work with other conforming compilers, even ones that don't have a switch to
turn off exceptions.
Thus, if you use "new (nothrow)" you can program in a subset of standard C++
and choose not to use exceptions. If you use "new" and count on it not
throwing an exception, you're no longer using a subset of standard C++ and
instead using a non-standard variation.
This is one of the reasons that EC++ is not a subset of standard C++. In
EC++, I use "new" and expect it to return 0. Thus I can only compile my code
with a compiler that has a "no exceptions" mode, which is not required of a
standard C++ compiler.
> Is my compiler just out of date?
I can't see how having a non-standard feature would make a compiler "out of
date".
If I was writing a compiler with a "no exceptions" mode, I'd want it (at
least as an option) to refuse to compile a "new" without "nothrow" to help
in the process of writing standard-compliant non-exception code.
I can't tell from your response whether you don't understand this issue or
you just don't like the way the standard is written. The aim of my posting
is to clarify what the standard means, not disparage EC++ or promote the use
of exceptions.
-- Darin
Andrew Koenig
> >The concern is simply that multiple C++ dialects will
> >unarguably encourage divergence into multiple subcamps whereas today I'd
> >wager that 95%+ of all C++ programmers use a compiler which closely
> >approximates the one standard.
> Nobody's arguing for multiple dialects: people are arguing for one radically
> limited alternative which provides the basic language improvements C++
> offers over C without the rocket science. The whole point of EC++ was to do
> this without "encouraging divergence".
I would agree with you were it not for two uncomfortable facts:
1. In order to write EC++ programs, you pretty much have
to do things that aren't allowed in standard C++.
You can paper over these things by using the preprocessor,
but they're still there.
2. EC++ excludes a lot of improvements over C that I
consider fundamental, such as the container and algorithm
libraries. For example, I don't think that EC++ offers
any way to sort an array of strings, an operation that
I consider to be fundamental.
--
Andrew Koenig
a...@research.att.com
http://www.research.att.com/info/ark
Andrew Koenig
Pete Becker <peteb...@acm.org> wrote:
> > I would be more inclined to agree with that statement if EC++ were indeed
> > an intermediate step -- that is, if EC++ were a subset of C++.
> Then you'd accept it if the EC++ spec added the requirement that every
> translation unit in an EC++ program contain the following line, which
> the compiler would ignore:
> using namespace std;
Yes. Then I would no longer say that the claim was dishonest -- just sleazy.