Topic: problems with locale and its facets
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/08/01 Raw View
AllanW@my-dejanews.com wrote:
>
> In article <35BDE208.2781@wizard.net>,
> James Kuyper <kuyper@wizard.net> wrote:
...
> > portable. It's portability is limited to the range of implementations
> > that either don't define those symbols or define them with the same
> > meaning as the one you expect. In most cases, that subset is very large.
> > For practical purposes, it can easily be large enough to be useful. For
> > that matter, a program that can compile under exactly one implementation
> > of C can be useful, if that implementation is available for every
> > platform the program is needed on.
>
> I believe that you never stated the portion beginning "For practical
> purposes, ..." before. This gives your words a different tone, and
> at least a slightly different meaning.
I tend to take things like that for granted, which can make me
incomprehensible to people who don't. I run into that problem a lot.
Sorry - my fault.
...
> > Try not to read extra meanings into my statements. If the apparant
> > meaning is ridiculous, don't automatically assume that I'm that stupid -
> > try looking for simple errors on my part or yours that might have
> > resulted in miscommunication.
>
> I never thought you were stupid. But I have often seen rediculous
> ideas presented by very intelligent people; sometimes merely for
> effect (see the thread about the smallest compliant C++ compiler).
Talking about how useless the smallest compliant C++ compiler could be
is one way of criticizing the ridiculously inadequate conformance
requirements. A minimum value for each limit of 1 would be helpful. A
minimum that was high enough to allow a useful program would be great
improvement; the minima needn't be set so high as to prohibit
implementation on embedded processors.
> Other times, it's because I'm missing something fundamental, or
> because the poster did (see the thread "Dynamic cast of virtual
> function pointers" -- either Mr. Aberg is missing something or I
> am, possibly both.) However, it seems to me that by far the largest
I don't think his native language is English, and I think that has made
his messages less comprehensible.
Are there non-English C++ newsgroups out there? I'm suprised that I
haven't seen any references to any.
...
> In any case, I meant no offense, and I apologize if any was given.
No problem.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/07/30 Raw View
In article <35BDE208.2781@wizard.net>,
James Kuyper <kuyper@wizard.net> wrote:
> AllanW@my-dejanews.com wrote:
> >
> > In article <35BC7936.446B@wizard.net>,
> > James Kuyper <kuyper@wizard.net> wrote:
> > > AllanW@my-dejanews.com wrote:
> > > ...
> > > > Indeed, when I and others questioned the premise of that
> > > > argument, some of those "language lawyers" went to extremes,
> > > > stating categorically that we should *NEVER* check for *ANY*
> ^^^^^^^^^^^^^^^^^^^^
> > > > implementation-defined symbols.
> > >
> > > Who made that claim? I'm one of those "language lawyers", but I don't
> > > remember any of us making that suggestion; we only pointed out that
> > > doing so made the code not strictly conforming to the C++ standard.
> >
> > You did:
> > > Subject: Re: problems with locale and its facets
> > > From: James Kuyper <kuyper@wizard.net>
> > > Date: 1998/07/18
> > > Message-ID: <35AF6AD7.794B@wizard.net>
> > > Newsgroups: comp.std.c++
> > >
> > > AllanW@my-dejanews.com wrote:
> > > ...
> > > > But my point was that most non-trivial programs make use of at least
> > > > one non-portable feature of the current compiler/environment. This
> > > > does not stop a program from being portable if it makes use of
> > > > conditional compilation, so that it can use suitable non-portable
> > >
> > > If your code uses such symbols to conditionally compile one of two
> > > different implementation-specific pieces of code, there is always the
> > > possibility that a third choice will need to be added when porting to a
> > > new environment. That makes it non-portable.
> ^^^^^^^^^^^^
>
> Where did I say that you shouldn't do it? All I said was that it wasn't
> portable. It's portability is limited to the range of implementations
> that either don't define those symbols or define them with the same
> meaning as the one you expect. In most cases, that subset is very large.
> For practical purposes, it can easily be large enough to be useful. For
> that matter, a program that can compile under exactly one implementation
> of C can be useful, if that implementation is available for every
> platform the program is needed on.
I believe that you never stated the portion beginning "For practical
purposes, ..." before. This gives your words a different tone, and
at least a slightly different meaning.
After all, if you can't reliably detect and correct local
incompatibilities by detecting local implementation-defined symbols,
then you are left with only two choices:
* Code to the bare minimum core language plus the library functions
that operate in exactly the same manner on every single platform.
This excludes most user I/O, because of the vast differences
between batch, text, and GUI platforms.
* For each port to a new platform, MANUALLY EDIT some header file
to create your own implementation-defined symbol (be sure to NOT
start it with two underscores). Then the techniques above work
just fine. The catch is that this is error-prone, especially
when porting the weekly incremental version to a platform that
has been ported to 200 times before.
In reality, I have so far been able to rely on symbols created by
the compiler I'm using. I'm sure I could live with the second
alternative above if absolutely required to, but fortunately I've
never been required to yet.
> Try not to read extra meanings into my statements. If the apparant
> meaning is ridiculous, don't automatically assume that I'm that stupid -
> try looking for simple errors on my part or yours that might have
> resulted in miscommunication.
I never thought you were stupid. But I have often seen rediculous
ideas presented by very intelligent people; sometimes merely for
effect (see the thread about the smallest compliant C++ compiler).
Other times, it's because I'm missing something fundamental, or
because the poster did (see the thread "Dynamic cast of virtual
function pointers" -- either Mr. Aberg is missing something or I
am, possibly both.) However, it seems to me that by far the largest
cause of espousing rediculous ideas is a certain natural obstinance
by intelligent, educated people with strong opinions, which seems
to include most of us that post to this newsgroup.
In any case, I meant no offense, and I apologize if any was given.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/07/25 Raw View
In article <6p826q$d25$1@nnrp1.dejanews.com>,
kanze@my-dejanews.com wrote:
> In article <6p4o67$dod$1@nnrp1.dejanews.com>,
> saroj@bear.com wrote:
> > While the debate is going on about the executable size, we should not forget
> > the large-scale savings on the source code size and simpler logic (and
> > ultimately good performance for the above reasons)
> > the
> > standard library brings to a programmer.
> Woah. Large-scale savings on the source code size compared to what. I've
> rarely seen anything that increased source code size as much as the STL.
> Most, if not all, of the implementations of the STL are optimized for
> speed, not size.
>
> I think we should put this into perspective. When designing a library,
I'm almost certain that saroj@bear.com *did* have this in
perspective -- he(?) meant the size of the application source
code, not the size of the STL source code. That is, as a C++
user familiar with the STL, I can write programs less than
100 lines long that could easily have required 1,000 lines or
more in previous versions of C++ or other languages. Thus the
phrase "large-scale savings on the source code size and simpler
logic".
The STL is fairly complicated on the inside, but reasonably
simple on the outside. By following some simple rules, I can
make my programs smaller and more efficient at the same time.
Thus, the STL is a tool for both productivity and efficiency
(a rare combination).
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Daniel Parker" <danielp@nospam.com>
Date: 1998/07/25 Raw View
Fergus Henderson wrote in message <6p9ch8$iac$1@mulga.cs.mu.OZ.AU>...
>James Kuyper <kuyper@wizard.net> writes:
>Wouldn't it suffice to have a single header file called say
>`standard_hdrs.h' containing
>
> #ifdef __embedded_cplusplus
> #include <iostream.h>
> #else
> #include <iostream>
> using std;
> #endif
>
>and to #include this header file in each module?
>If you do that, and you stick to the subset of iostreams
>and other language and library features that are portable
>between the two dialects, wouldn't that be enough?
But why would anybody want to approach a problem like that these days? If
anyone wanted to write code using mostly the EC++ classes, to be on the safe
side, but to try out some standard library classes, they wouldn't be able to
do that; they wouldn't be able to incrementally move from EC++ to Standard
C++. If EC++ would add namespace support, and would move their own header
files off to some subdirectory, say embedded, it would make things a lot
cleaner without impacting anything that could possibly be of any concern to
an embedded system programmer. And while I can understand that it may be
difficult for a compiler vendor to implement templates correctly, it can't
possibly be difficult to implement namespaces correctly; that has to be
comparatively simple.
I would certainly hope that no standards body would give their blessing to
EC++ without insisting on namespace support and separation of EC++ header
files; to do so would seem to be a step backward, at no gain.
--
Regards,
Daniel Parker danielp@no_spam.anabasis.com.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/07/27 Raw View
AllanW@my-dejanews.com wrote:
...
> Indeed, when I and others questioned the premise of that
> argument, some of those "language lawyers" went to extremes,
> stating categorically that we should *NEVER* check for *ANY*
> implementation-defined symbols.
Who made that claim? I'm one of those "language lawyers", but I don't
remember any of us making that suggestion; we only pointed out that
doing so made the code not strictly conforming to the C++ standard.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/07/29 Raw View
AllanW@my-dejanews.com wrote:
>
> In article <35BC7936.446B@wizard.net>,
> James Kuyper <kuyper@wizard.net> wrote:
> > AllanW@my-dejanews.com wrote:
> > ...
> > > Indeed, when I and others questioned the premise of that
> > > argument, some of those "language lawyers" went to extremes,
> > > stating categorically that we should *NEVER* check for *ANY*
^^^^^^^^^^^^^^^^^^^^
> > > implementation-defined symbols.
> >
> > Who made that claim? I'm one of those "language lawyers", but I don't
> > remember any of us making that suggestion; we only pointed out that
> > doing so made the code not strictly conforming to the C++ standard.
>
> You did:
> > Subject: Re: problems with locale and its facets
> > From: James Kuyper <kuyper@wizard.net>
> > Date: 1998/07/18
> > Message-ID: <35AF6AD7.794B@wizard.net>
> > Newsgroups: comp.std.c++
> >
> > AllanW@my-dejanews.com wrote:
> > ...
> > > But my point was that most non-trivial programs make use of at least
> > > one non-portable feature of the current compiler/environment. This
> > > does not stop a program from being portable if it makes use of
> > > conditional compilation, so that it can use suitable non-portable
> >
> > If your code uses such symbols to conditionally compile one of two
> > different implementation-specific pieces of code, there is always the
> > possibility that a third choice will need to be added when porting to a
> > new environment. That makes it non-portable.
^^^^^^^^^^^^
Where did I say that you shouldn't do it? All I said was that it wasn't
portable. It's portability is limited to the range of implementations
that either don't define those symbols or define them with the same
meaning as the one you expect. In most cases, that subset is very large.
For practical purposes, it can easily be large enough to be useful. For
that matter, a program that can compile under exactly one implementation
of C can be useful, if that implementation is available for every
platform the program is needed on.
Try not to read extra meanings into my statements. If the apparant
meaning is ridiculous, don't automatically assume that I'm that stupid -
try looking for simple errors on my part or yours that might have
resulted in miscommunication.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: kanze@my-dejanews.com
Date: 1998/07/27 Raw View
In article <6paubt$qcd$1@nnrp1.dejanews.com>,
AllanW@my-dejanews.com wrote:
> In article <6p826q$d25$1@nnrp1.dejanews.com>,
> kanze@my-dejanews.com wrote:
>
> > In article <6p4o67$dod$1@nnrp1.dejanews.com>,
> > saroj@bear.com wrote:
>
> > > While the debate is going on about the executable size, we should not
forget
> > > the large-scale savings on the source code size and simpler logic (and
> > > ultimately good performance for the above reasons)
> > > the
> > > standard library brings to a programmer.
>
> > Woah. Large-scale savings on the source code size compared to what. I've
> > rarely seen anything that increased source code size as much as the STL.
> > Most, if not all, of the implementations of the STL are optimized for
> > speed, not size.
> >
> > I think we should put this into perspective. When designing a library,
>
> I'm almost certain that saroj@bear.com *did* have this in
> perspective -- he(?) meant the size of the application source
> code, not the size of the STL source code.
Woops. I hooked onto the first reference to executable size, and missed
the change in perspective.
> That is, as a C++
> user familiar with the STL, I can write programs less than
> 100 lines long that could easily have required 1,000 lines or
> more in previous versions of C++ or other languages. Thus the
> phrase "large-scale savings on the source code size and simpler
> logic".
Agreed. Of course, there are libraries which are even better in this
regard than the STL for typical uses -- you still pay a little for
the added flexibility of STL. But compared to doing it by hand...
> The STL is fairly complicated on the inside, but reasonably
> simple on the outside. By following some simple rules, I can
> make my programs smaller and more efficient at the same time.
> Thus, the STL is a tool for both productivity and efficiency
> (a rare combination).
I find that any use of STL increases the memory footprint (executable
size plus data memory) significantly. Which is not surprising, given
that the implementations I have access to were designed for machines
with large virtual memories, and were optimized for speed. And the
STL does make my programs shorter (in terms of lines of code) AND
faster.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/07/28 Raw View
In article <35BC7936.446B@wizard.net>,
James Kuyper <kuyper@wizard.net> wrote:
> AllanW@my-dejanews.com wrote:
> ...
> > Indeed, when I and others questioned the premise of that
> > argument, some of those "language lawyers" went to extremes,
> > stating categorically that we should *NEVER* check for *ANY*
> > implementation-defined symbols.
>
> Who made that claim? I'm one of those "language lawyers", but I don't
> remember any of us making that suggestion; we only pointed out that
> doing so made the code not strictly conforming to the C++ standard.
You did:
> Subject: Re: problems with locale and its facets
> From: James Kuyper <kuyper@wizard.net>
> Date: 1998/07/18
> Message-ID: <35AF6AD7.794B@wizard.net>
> Newsgroups: comp.std.c++
>
> AllanW@my-dejanews.com wrote:
> ...
> > But my point was that most non-trivial programs make use of at least
> > one non-portable feature of the current compiler/environment. This
> > does not stop a program from being portable if it makes use of
> > conditional compilation, so that it can use suitable non-portable
>
> If your code uses such symbols to conditionally compile one of two
> different implementation-specific pieces of code, there is always the
> possibility that a third choice will need to be added when porting to a
> new environment. That makes it non-portable.
...etc. The "discussion" continued from there.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/07/22 Raw View
In article <35B4D4C8.167E@wizard.net>,
James Kuyper <kuyper@wizard.net> wrote:
> I suspect that the __ecplusplus check will need to be done in almost
> every module of most programs. That doesn't count as well-isolated to
> me.
Generally I can keep my system-dependant sections in ONE header file,
say SYSDEPEND.H, and ONE source module, say SYSDEPEND.CPP
* Handle differences in almost-standard library functions
// Use Borland's strcmpi() instead of Microsoft's stricmp()
#define stricmp strcmpi
* Handle an almost-standard library function not present
bool strincmp(); // Defined in SYSDEPEND.CPP
Note we use library versions if possible, on the theory that it's
more optimized for the current environment than anything we can do.
* Handle syntax issues with macro replacements, if possible
#define std
* Handle syntax issues that aren't simple substitution
// Don't define if platform doesn't support member functions
#define MEMBER_TEMPLATES
In this case, source modules throughout the code will have to check
if MEMBER_FUNCTIONS is defined:
#ifdef MEMBER_TEMPLATES
typedef<class T>void SendTo(T *t) const { t->send(this); }
#else // MEMBER_TEMPLATES
void SendTo(Class1*t)const { t->send(this); }
void SendTo(Class2*t)const { t->send(this); }
void SendTo(Class3*t)const { t->send(this); }
void SendTo(Class4*t)const { t->send(this); }
void SendTo(Class5*t)const { t->send(this); }
#endif // MEMBER_TEMPLATES
You might view this as an exception to my claim that I isolate
system-dependant code in one header/source file. But I don't,
because the source module doesn't try to figure out what platform
it's running on. Once we've identified that *SOME* platforms
can't handle member templates, we write each of these sections
both ways. But only one section of code is responsible for
#defining MEMBER_TEMPLATES (or for not #defining it).
For a good example of this, see stl_config.h in SGI's implementation of
the Standard Template Library.
> > entire system. Tests and debugging should be constrained to changing
> > only the new section, until the program is certified on the new system
> > or until you can demonstrate that this is impossible. (This can happen
> > because some section of code which was NOT marked as non-portable,
> > turned out to be non-portable anyway. Hopefully this is rare, but it
> > does happen in the real world.)
>
> My experience is that it's quite common. Much of the code I've worked on
> has been touched at least once by programmers with less than 2 years of
> practical experience in C/C++, many of them ex-FORTRAN programmers. They
> just barely understand the language itself, never mind being aware of
> portability issues.
Then how do you *EVER* write portable programs? (Alright, in light of
what you say below: How does your company *EVER* write 'more nearly
portable' code?) Do you expect a computer language to protect itself
from misapplication? (Do you have a hammer that locks up if you aim it
at your thumb?)
A language should be as intuitive as possible, but at some level we need
to train our programmers before we set them loose. Where I work, a
programmer who has recently passed a C++ training course has a special
name: "Apprentice."
> > > Portable code is an ideal to be approached, not a practical goal to be
> > > achieved.
> >
> > Depends on what you call "portable," I suppose. I would say that the
> > technique above makes code "portable" because it can be compiled on
> > any identified platform with no extra work, and it can be compiled
> > on any other standard C++ platform with minimal extra work.
>
> There are degrees of portability, but in the absence of a modifying
> adjective, when I say "portable" I'm referring to code that can be
> translated by any conforming implementations of C++ with NO extra work.
> That is why I claim that portability is an ideal, not an achievable
> goal.
You might as well say that it's impossible to debug a program, and base
the claim on the fact that large programs inevitably have bugs. When you
claim that a program isn't portable because it doesn't stand up to some
arbitrary standard of perfection, you cease to communicate.
The legal standard for most laws (and let's face it, we're acting as
"language lawyers" here) is "reasonable." As in, would a (hypothetical)
"reasonable man" agree that the code compiled on this new platform.
> > > The way to approach portability is to avoid such code wherever
> > > possible, and to isolate such code in as few modules as possible.
> >
> > Aren't we saying the same thing, in different words?
>
> You call the result "portable", I would refer to it as "more nearly
> portable". There's a difference of attitude implicit in the different
> wording.
Whatever.
> > > What they did say was that the need to test for
> > > such symbols proves that EC++ is not a strict subset of C++. There is a
> > > strong relationship, it's just more complex than simple subsetting.
> >
> > Granted. Why is this important?
>
> Precision of meaning; if it isn't a subset, don't call it one. Use some
> kind of modifyier to at least hint at the true relationship. Plauger has
> already said that he is sorry he ever used the word.
Fine. Let's settle on super-subset, and move beyond the vocabulary.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/22 Raw View
In article <01bdb4c5$0abc1fe0$8a1ec2d0@porky>, "P.J. Plauger"
<pjp@dinkumware.com> writes
>Mike Davies <mike_davies@noco.demon.co.uk> wrote in article <xKtdmDA6k4s1EwLs@no
>co.demon.co.uk>...
>> New ? Templates have been in the Borland compiler (thats just the one I
>> know) since 1994.
>
>Yes, and that implementation a) was buggy and b) is now outdated.
There was no standard for C++ and therefore there were no bugs. Except
documentation ones ;-)
>
>P.J. Plauger
Regards,
--
Mike Davies
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/07/23 Raw View
AllanW@my-dejanews.com wrote:
...
> > > or until you can demonstrate that this is impossible. (This can happen
> > > because some section of code which was NOT marked as non-portable,
> > > turned out to be non-portable anyway. Hopefully this is rare, but it
> > > does happen in the real world.)
> >
> > My experience is that it's quite common. Much of the code I've worked on
> > has been touched at least once by programmers with less than 2 years of
> > practical experience in C/C++, many of them ex-FORTRAN programmers. They
> > just barely understand the language itself, never mind being aware of
> > portability issues.
>
> Then how do you *EVER* write portable programs? (Alright, in light of
> what you say below: How does your company *EVER* write 'more nearly
> portable' code?) ...
With difficulty :-) It's not as bad as it probably sounds. We use
inexperienced people mainly for maintence programming. That's why I said
"touched" rather than "written". We do have more experienced people
doing much of the original coding, and reviewing the work of less
experienced people.
> ... Do you expect a computer language to protect itself
> from misapplication? (Do you have a hammer that locks up if you aim it
> at your thumb?)
I don't expect a computer language to protect itself from
misapplication, but I'm quite pleased when my expectations are exceeded.
The extra compile time is usually negligible compared to the saved
debugging time.
The locking hammer is too expensive to implement, but I'd appreciate it
if it were cheap. Compiler improvements always look cheaper to us users
than they do to implementors.
...
> > There are degrees of portability, but in the absence of a modifying
> > adjective, when I say "portable" I'm referring to code that can be
> > translated by any conforming implementations of C++ with NO extra work.
> > That is why I claim that portability is an ideal, not an achievable
> > goal.
>
> You might as well say that it's impossible to debug a program, and base
I suppose I'm slightly inconsistent. I use "portable" to describe the
ideal case of 0-cost porting to arbitrary platforms. I use "debug" to
describe the practical case of removing some bugs, rather than the ideal
case of removing all of them. I don't trust anyone who claims they've
removed all the bugs. Such optimism is usually correlated with sloppy
programming habits.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Greg Colvin" <spam@me.not>
Date: 1998/07/23 Raw View
jkanze@otelo.ibmmail.com wrote in article
<6p5etn$d95$1@nnrp1.dejanews.com>...
> ...
> The largest area of incompatibility WAS that some compilers required you
> to include the implementation in the header file, whereas others didn't
> allow it. This one has largely disappeared; most compilers today will
> allow the implementation in the header file, even if some (e.g. CSet++)
> do a better job if it is separate.
But of course both kinds of compiler allowed you to put the implemention
in the header as inline functions.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/07/23 Raw View
Nathan Myers wrote:
>
>
> >> and demands to produce evidence of a
> >> library that doesn't exhibit such overhead.
> >
> >Well, not "demands", but insistence that engineering evaluations be
> >based on engineering and not on speculation. That seems like a
> >reasonable thing to ask for in a discussion about engineering.
>
> That's odd, I thought this was a standards newsgroup.
>
> Talk about bugs in already-finished implementations seems more
> appropriate in comp.lang.c++. Discussion of how to implement
> a standard-conforming library without overhead seems more
> appropriate here.
>
> If engineers were only allowed to discuss what was already finished,
> nothing new would ever be built. (There have been such societies.
> We call one apparent example the Dark Ages.) Certainly, new things
> are only built by people who are willing to "speculate".
Of course, I did not say that speculating is bad. What I said, and what
I continue to say, is that basing engineering evaluations on speculation
is not good engineering. Once you start speculating you are, by
definition, outside the realm of engineering.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: kanze@my-dejanews.com
Date: 1998/07/23 Raw View
In article <6p4o67$dod$1@nnrp1.dejanews.com>,
saroj@bear.com wrote:
> In article <01bdb4c5$0abc1fe0$8a1ec2d0@porky>,
> "P.J. Plauger" <pjp@dinkumware.com> wrote:
> > Mike Davies <mike_davies@noco.demon.co.uk> wrote in article
> <xKtdmDA6k4s1EwLs@noco.demon.co.uk>...
> > > New ? Templates have been in the Borland compiler (thats just the one I
> > > know) since 1994.
> >
> > Yes, and that implementation a) was buggy and b) is now outdated. Even
> > the much touted EDG front end still lacks template templates, and no two
> > implementations are alike in what they do support. I think that it's thus
fair
> > to characterize template technology as ``new.''
> >
>
> I have been using STL (first, HP STL and then SGI STL) with my Sun C++
> compiler since 1994 in production code. Even though, it does not have
> template defaults, template templates, member templates, etc., still you
> can do amazing things with templates. In fact, VC++ templates were not
> usable in large-scale programs until 5.0 version.
Which sort of supports what Plauger just said. Only the most recent version
of VC++ had usable template support.
> While the debate is going on about the executable size, we should not forget
> the large-scale savings on the source code size and simpler logic (and
> ultimately good performance for the above reasons)
> the
> standard library brings to a programmer.
Woah. Large-scale savings on the source code size compared to what. I've
rarely seen anything that increased source code size as much as the STL.
Most, if not all, of the implementations of the STL are optimized for
speed, not size.
I think we should put this into perspective. When designing a library,
there are a number of choices that you have to make--improving one aspect
has costs for another. I can think of at least three trade-offs that
occur: flexibility vs. simplicity of use, speed vs. safety, and speed
vs. size. Stepanov's documented design goals stress flexibility and
speed, so it is not surprising if the results are sometimes complicated
and dangerous to use, and take up more memory than other designs.
I presume that he made these choices for good reasons. They are certainly
correct for some people -- given today's machines, and what we do with
them, choosing speed rather than space is almost always right (except for
some small embedded processors). Given the actual competence of today's
programmers, on the other hand, I have my doubts concerning the choice
of speed vs. safety and flexibility vs. ease of use. (Wrapper classes
can actually add the ease of use without problems. I think that Rogue
Wave goes this way. Once the safety's gone, however, it's gone. Or at
least, I've not found a way of adding it back with a wrapper class.)
> I sincerely thank Stroustrup
> and Stepanov (and many more contributors) who have worked for more than
> a decade to bring default parameters, function overloading, templates,
> exceptions, constructor/destructor, classes and inheritance to a language
> that is close to C in performance (no debate please) and is a powerful
> and interesting language to program in.
Well, I'm certainly glad that some people are experimenting with what
future directions programming languages should take. I'm not really
totally happy with there being forced down my throat before they've
been thoroughly tested, but I have considerable trust in the people
writing C++ compilers today to come up with robust solutions. We've
come a long way since Zortech 1.2 or g++ 1.49.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: fjh@cs.mu.OZ.AU (Fergus Henderson)
Date: 1998/07/24 Raw View
James Kuyper <kuyper@wizard.net> writes:
>AllanW@my-dejanews.com wrote:
>>
>> By isolating the non-portable sections, we ensure that the port is easy.
>
>I suspect that the __ecplusplus check will need to be done in almost
>every module of most programs. That doesn't count as well-isolated to
>me.
Wouldn't it suffice to have a single header file called say
`standard_hdrs.h' containing
#ifdef __embedded_cplusplus
#include <iostream.h>
#else
#include <iostream>
using std;
#endif
and to #include this header file in each module?
If you do that, and you stick to the subset of iostreams
and other language and library features that are portable
between the two dialects, wouldn't that be enough?
Or are there some other difference(s) between EC++ and C++
that this wouldn't solve?
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/07/25 Raw View
In article <6p9ch8$iac$1@mulga.cs.mu.OZ.AU>,
fjh@cs.mu.OZ.AU (Fergus Henderson) wrote:
> James Kuyper <kuyper@wizard.net> writes:
>
> >AllanW@my-dejanews.com wrote:
> >>
> >> By isolating the non-portable sections, we ensure that the port is easy.
> >
> >I suspect that the __ecplusplus check will need to be done in almost
> >every module of most programs. That doesn't count as well-isolated to
> >me.
>
> Wouldn't it suffice to have a single header file called say
> `standard_hdrs.h' containing
>
> #ifdef __embedded_cplusplus
> #include <iostream.h>
> #else
> #include <iostream>
> using std;
> #endif
>
> and to #include this header file in each module?
> If you do that, and you stick to the subset of iostreams
> and other language and library features that are portable
> between the two dialects, wouldn't that be enough?
> Or are there some other difference(s) between EC++ and C++
> that this wouldn't solve?
I don't know EC++, but I'm given to believe that this:
#ifndef __embedded_cplusplus
using std;
#endif
or this:
#ifdef __embedded_cplusplus
#define std
#endif
would be enough. But that would put us back about 5-6 weeks,
when someone suggested exactly this second version (except
that they misspelled the preprocessor symbol). As I recall,
the widespread reaction was NOT a statement that this would
work, or that it would not because EC++ also has some other
specific difference. Instead, a "language lawyer" appeared
to argue that this would fail on any implementation that
happened to define __embedded_cplusplus for it's own purposes.
Indeed, when I and others questioned the premise of that
argument, some of those "language lawyers" went to extremes,
stating categorically that we should *NEVER* check for *ANY*
implementation-defined symbols.
Which is why I started teaching my computer class,
Portability 101: Portability Concepts
In this class, we will attempt to demonstrate simple
techniques that can mask minor differences between
pre-standard implementations of C++ and/or EC++.
However, before we've finished Chapter 1, we will
begin to nit-pick about the very meaning of terms such
as "portable," "embedded," "C++," "language,"
"language lawyer," "standard," "nit-pick,"
"techniques," and so on.
In the unlikely event that we have extra time, we will
begin a petty argument about what constitutes evidence
of intelligent life, especially as relates to Star
Trek's android named Data.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: dietmar.kuehl@claas-solutions.de
Date: 1998/07/22 Raw View
Hi,
In article <35B493F5.F9020840@acm.org>,
Pete Becker <petebecker@acm.org> wrote:
> That gives you the most important level of control: programs that don't
> use locales won't get any locale code. Those that do get everything.
I think the explanation I gave showed that I'm not making up things. Thus, I
hope you will believe me without asking me to reveal details of my
implementations (after all, I consider Dinkumware a competitor of me and
other library implementors are probably also watching). It is not at all
necessary to pull in all facets just because one facet is used. For example,
if IOStreams use locales, it is not necessary to pull in the monetary facets
(the trick how this is done is trivial; still, I'm not going to publish it
prior to my implementation).
> > Actually, it is not really necessary to fall back to
> > the full blown implementation immediately: There can still be finer control
> > depending on the replaced facets (yes, this can also be done at link time!).
>
> OK. Then the tradeoff you have to make is complexity in the library
> versus fine-grained control.
This is exactly my point: Yes, I have an increased complexity in my library to
make the life of a user easier. This is my damn job (well, I'm doing it in my
spare time but I'm doing it as if it were my job)! The implementation should
bother about complexity as much as possible. The use of the standard library
should be as easy as possible. After all, the user has to worry about other
complexities.
A naive approach to the implementation of the standard C++ library would
yield lots of overhead: for example, a large executable size in case of
IOStreams or mediocre performance for STL. Doing optimizations in the
library, invisible to the user, can do *LOT*. This makes the library
implementation more complex. ... but it can be done. In particular, different
implementations of the same library, without compromising standard
conformance, can be optimized for different aspects. This implies more work
for the library implementor. But we can't expect to be done at some time and
to wait for the money coming without further work :-)
> DLLs pose their own set of problems, because they're built
> independently of the application that uses them. The state of the art
> today is to put the entire runtime library into a single DLL, on the
> assumption that the code will be shared by multiple applications, so the
> space overhead really isn't that bad.
> At the other extreme, I suppose it would be possible to do something
> analogous to the technique used in static libraries, one function per
> DLL. You'd get the granularity, but at the cost of imposing a tremendous
> burden on the loader. Application startup would probably be very slow,
> because of the time needed to load each of the DLLs. And the disk space
> needed to store all those DLLs would be much greater than for a single
> DLL.
However, I doubt that it is really reasonable to optimize the executable size
for programs running under Windows anyway. Of course, it should not be
ignored but optimizing for executable size is only reasonable for
environments with very limited memory. Of course, smaller executables can
imply less paging even on systems with much memory such that it is not
completely irrelevant but not the major design goal. Instead, I would
consider speed the major goal. But you can choose what to optimize and you
can do it often to an extend where there is no or only very small runtime
overhead. ... of course, the implementation can still conform to the C++
standard. -- <mailto:dietmar.kuehl@claas-solutions.de> homepage:
<http://www.informatik.uni-konstanz.de/~kuehl>
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: tjsharrock@iee.org (Tim Sharrock)
Date: 1998/07/22 Raw View
On 21 Jul 1998 21:42:21 GMT, Mike Davies <mike_davies@noco.demon.co.uk>
wrote:
>In article <6p05im$d92$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
>writes
>>If the code was written five years ago, there's really very little
>>chance that it used templates.
>[...].
>I was using templates in code for industrial applications in late 1994,
>ie 31/2 years ago. I first started using them roughly a year before
>that. I hadn't realised that the post was referring so strictly to a 5
>year timescale, I don't know what reason you have for suggesting this ?
>
>I would expect templates to have crept into *most* C++ code from any era
>under the normal development process. They're just too generally useful.
They are indeed generally useful, but I have only just this week started
using "user-defined" templates in production code. We have used the
Rogue-Wave template collection classes for several years, and are now
switching to using the STL, but apart from one RW-like collection class
we have not attempted to use templates, precisely because of
cross-compiler portability issues.
There was a great deal of debate about even using templates when RW were
handling most of the portability issue for us - handling template
instantiation within our version control system gave us many headaches.
>>They existed, but in about the same
>>way namespaces do now; some compilers supported them, but you wouldn't
>>count on their being available in portable code.
>
>There was no standard for C++ in those days, people fell over themselves
>to buy compilers that supported templates. It was a major issue in
>reviews of compilers IIRC.
In our case, we might play with new compilers, but we would refrain from
using new features, typically for several years, until all our active
compilers could handle them. "Active compilers" might include not just
the current versions, but older versions required to support old
releases of our products on previous versions of the operating systems.
(In that last case we might use newer features for significant new
developments which would not be ported back to old releases, but that
requires a formal decision to do so.)
>My opinion is that cross-compiler portability is and always has been a
>minor issue for a large section of the market, particularly under MS
>Windows.
For another section of the market it is vital! We are not enjoying the
transition towards Standard C++, but it will be great when we can rely
on all of it... 2001?
Tim
--
Tim Sharrock (tjsharrock@iee.org)
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/07/22 Raw View
Pete Becker <petebecker@acm.org> wrote:
>Nathan Myers wrote:
>>
>> I don't recall reading any such requests. I _have_ seen repeated
>> assertions that it is impossible to implement the standard library
>> without prohibitive overhead,
>
>I don't recall reading any such assertions. I _have_ seen repeated
>assertions that it is harder than most people think to implement the
>standard library without prohibitive overhead.
Read the archives. The repeated assertions were that the standard
mandates overhead. If the standard mandates overhead, then it is
_impossible_ to implement a conforming library without overhead.
(Nobody ever said it would be _easy_ to produce a professional-quality
standard-compliant library.) If nobody had asserted (repeatedly)
that it was in fact impossible (i.e. that overhead was mandated),
most of this thread would not have happened.
>> and demands to produce evidence of a
>> library that doesn't exhibit such overhead.
>
>Well, not "demands", but insistence that engineering evaluations be
>based on engineering and not on speculation. That seems like a
>reasonable thing to ask for in a discussion about engineering.
That's odd, I thought this was a standards newsgroup.
Talk about bugs in already-finished implementations seems more
appropriate in comp.lang.c++. Discussion of how to implement
a standard-conforming library without overhead seems more
appropriate here.
If engineers were only allowed to discuss what was already finished,
nothing new would ever be built. (There have been such societies.
We call one apparent example the Dark Ages.) Certainly, new things
are only built by people who are willing to "speculate".
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: dietmar.kuehl@claas-solutions.de
Date: 1998/07/22 Raw View
Hi,
In article <01bdb4ad$7471d140$8a1ec2d0@porky>,
"P.J. Plauger" <pjp@dinkumware.com> wrote:
> dietmar.kuehl@claas-solutions.de wrote in article
<6ov12i$rb3$1@nnrp1.dejanews.com>...
> > I'm not going to give you my incomplete implemenation of IOStreams/locales
> > but I hope that telling you how things basically work are sufficient.
>
> Well, generalities are nice, but numbers are better. Didn't learn anything
> new from what you revealed.
I didn't claim that there is much to learn. You can get the whole
implementation including a documentation of why things are implemented the
way they are, when the implementation is released. The current state of the
implementation is simply not suitable for a release. My plan is to have it
ready prior to the next committee meeting. There we can discuss
implementation details and optimization potential if you are interested.
There is a solution
> > to this problem, too. ...but I hope that you understand that I don't reveal
> > all of my implementation.
>
> No, I don't understand. Not when you simultaneously make pious
> pronouncements like the following:
I guess you are not seeing me as competitor (after all, I'm just a single
person spending his spare time to implement something). However, I see you as
a competitor and thus I'm not willing to reveal details before making the
library available.
> : > David R Tribble <dtribble@technologist.com> wrote:
> : > >> It's been pretty well established that locale facet templates add
> : > >> code bloat when using iostreams. (Perhaps it's not templates that
> : >> are the problem, but an overly ambitious iostream specification?)
> :
> : What? Who established that? This is not at all true! There is no need at all
> : for code bloat when using iostreams which results from locales, unless
> : locales are explicitly used.
I described a solution how to tackle this problem if you don't use locales at
all. Thus, I already provided the details how to solve the problem. Avoiding
to pull in code for all facets even if some facets are used is not really
that much of a problem either (for example, it is trivial to avoid binding
code for the monetary facets into the executable).
> Microsoft ships the full source code of our library with VC++. Most of the
> code in question is in the headers. Anyone who studies it can see that we
> make a serious effort to keep the size of executables small -- without
> sacrificing performance. No secrets there.
This is true. Even better, you documented lots of your stuff in your books
about the C and C++ standard library. ... but you released it when it was
finished. There are no secrets in my code. Just it is not yet finished.
> This thread has seen repeated assertions to the effect that any inefficiencies
> in implementing the Standard C++ library are due to shortcomings of library
> and compiler implementations of ``immature'' (available) systems.
The major aspect in this thread was the claim that the definition of
IOStreams in the standard C++ library imply a dramatically increased
executable size compared eg. to the definition used in your book. In
particular, it was claimed that the standard definition of IOStreams is thus
unsuitable for embedded systems with low memory. This is definitely true for
all implementations I have seen so far. This does not imply to me that these
implementations are immature for the systems they are intended to be used on
(other aspects normally indicate that they are immature...). Normally,
optimizing for speed is much more important than even thinking about code
size when targetting decent machines. But this also does not imply that a
size overhead is necessary. Of course, if you use locales, there will be an
increased code size. If you don't need it, there is not necessarily such
impact. Using weak symbols is one approach to avoid pulling in facet code
which is not used. Another approach, requiring some user help, would be the
construction of two libraries, one including the facet code, one omitting
them: If a facet method is used, the linker will tell the user to use the
full blown version (normally with some unfriendly message like "undefined
symbol..."). There is no need for a clever compiler or linker here. And it is
still conforming: The standard says nothing about user actions necessary to
build an executable.
> Pete Becker
> and I have repeatedly asked for guidance on how to make our implementation
> better. It's nice to know that some compilers optimize away virtuals and some
> others support weak references -- both offer hope for the future. If there are
> still other techniques that can help, it would be nice to hear about them too.
If I were a customer of your library, I would probably tell you. But I'm not.
I'm implementing my own version of a part of the standard C++ library. To get
customers, I should have the best implementation available. This is hard when
giving away all the tricks. Once it is finished, you can get my
implementation, including a documentation of how things are done (for free; a
major reason to continue my implementation is to provide a free
implementation for Greg Comeau's compiler: the [current] GNU implementation
relies on certain gcc specific stuff and is thus unusable for his compiler).
However, I don't want to listen to myths which are simply not true in the
meantime.
--
<mailto:dietmar.kuehl@claas-solutions.de>
homepage: <http://www.informatik.uni-konstanz.de/~kuehl>
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: saroj@bear.com
Date: 1998/07/22 Raw View
In article <01bdb4c5$0abc1fe0$8a1ec2d0@porky>,
"P.J. Plauger" <pjp@dinkumware.com> wrote:
> Mike Davies <mike_davies@noco.demon.co.uk> wrote in article
<xKtdmDA6k4s1EwLs@noco.demon.co.uk>...
> > New ? Templates have been in the Borland compiler (thats just the one I
> > know) since 1994.
>
> Yes, and that implementation a) was buggy and b) is now outdated. Even
> the much touted EDG front end still lacks template templates, and no two
> implementations are alike in what they do support. I think that it's thus fair
> to characterize template technology as ``new.''
>
I have been using STL (first, HP STL and then SGI STL) with my Sun C++
compiler since 1994 in production code. Even though, it does not have
template defaults, template templates, member templates, etc., still you
can do amazing things with templates. In fact, VC++ templates were not
usable in large-scale programs until 5.0 version.
While the debate is going on about the executable size, we should not forget
the large-scale savings on the source code size and simpler logic (and
ultimately good performance for the above reasons)
the
standard library brings to a programmer. I sincerely thank Stroustrup
and Stepanov (and many more contributors) who have worked for more than
a decade to bring default parameters, function overloading, templates,
exceptions, constructor/destructor, classes and inheritance to a language
that is close to C in performance (no debate please) and is a powerful
and interesting language to program in.
Cheers,
Saroj Mahapatra
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/07/22 Raw View
In article <6p2sjo$bvf$1@shell7.ba.best.com>,
ncm@nospam.cantrip.org (Nathan Myers) wrote:
> P.J. Plauger<pjp@dinkumware.com> wrote:
> It takes time to implement a full standard-conforming library, and
> more time to optimize it for a small footprint. When it's ready,
> it will be available.
>
> >It's nice to
> >know that some compilers optimize away virtuals and some others
> >support weak references -- both offer hope for the future. If there
> >are still other techniques that can help, it would be nice to hear
> >about them too.
>
> I counsel patience.
Could you talk to my customers, and tell them that. We have to deliver
in November. (I don't know the exact situation here, but many times in
the past, there have been penalty clauses for late delivery. And of course,
if you are selling on the competative market, the penalty is that your
competiter gets the customers, not you.)
Of course, the answer here is to avoid the leading edge, so you don't
have the problem. For example, the measurements I posted show that
with VC++, using <iostream.h> results in a significantly smaller footprint
than using <iostream>. If the program footprint is an important point
for your product, you have an answer. (I'm willing to bet as well that
<iostream.h> is a more mature implementation, better tested and with
less bugs as well. Being on the leading edge is NOT always the correct
solution.)
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/07/22 Raw View
In article <6p2tbf$fqp$1@shell7.ba.best.com>,
ncm@nospam.cantrip.org (Nathan Myers) wrote:
> <jkanze@otelo.ibmmail.com> wrote:
> >... even today, it is extremely difficult to write a portable program that
> >uses templates. As late as Nov., 1997, the committee was rewording the
> >template chapter, because of problems.
>
> This vastly overstates the case. Four years ago there were wide
> variations in what different implementations would support, but
> very broad areas of agreement. All have converged since.
>
> The largest areas of incompatibility amounted to pure bugs, where
> a compiler would crash when presented with certain constructs.
> It has been years since that was a common occurrence on compilers
> that compete based on quality and service.
The largest area of incompatibility WAS that some compilers required you
to include the implementation in the header file, whereas others didn't
allow it. This one has largely disappeared; most compilers today will
allow the implementation in the header file, even if some (e.g. CSet++)
do a better job if it is separate.
The largest area of incompatibility today is just how much of the new
standard the compiler supports. Of course, if you limit yourself to
simple class templates, with no template members, no template templates,
no partial instantiations, etc., etc., you aren't too affected by this.
A second important area of incompatibility was, and as far as I know, still
is the context of instantiation. And this WAS being discussed up into
the Nov. meeting. (If I can believe the report presented at the AFNOR
meeting following this, the final standard introduces some subtle cases
of undefined behavior that weren't in any of the implementations I've
used.)
The problem with this particular incompatibility is that it doesn't normally
make a difference, so you don't pay attention to it. And when it makes a
difference, it doesn't normally cause a compiler error, but only introduces
a subtle change in the semantics of the program, so it is a bitch to
trace down.
> > ... A couple of years ago, it was anyone's guess
> >as to what the standard would require of templates.
>
> Again, this is an extreme interpretation. Many people have been
> writing templates in portable (and widely ported) production code
> for years. The then-unresolved areas in the standard (corresponding
> to still-unimplemented features in current compilers) were and are
> easily avoided.
I did say a couple of years ago. Practically, to conform to the standard,
all of my templates should be declared export. This is a radical change
with regards to current practice, and a couple of years ago, I'd never
heard of the term. I certainly wouldn't have guessed that the standard
would require it in order to implement separate compilation of templates.
(A couple of years ago, I wouldn't have even guessed that separate compilation
could be an issue.)
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/22 Raw View
David R Tribble <david.tribble@noSPAM.central.beasys.com> wrote in article <35B4F7BB.1509@noSPAM.central.beasys.com>...
> I realize it would be considered "nonconforming" to do so, or at
> least nonportable, but would it be reasonable for you to add #ifs
> for a special macro that I could set at compile time to disable the
> locale baggage when using <iostream>? Something like
> '_NO_IO_LOCALES' or '_DFL_IO_LOCALE'? This assumes, of course,
> that I know at compile time that I won't be needing any of the
> iostream locale stuff.
>
> I know this isn't a solution to the bigger general problem at hand,
> but it is certainly a practical solution. (Practically speaking,
> we enable quite a few compiler switches and macro definitions when
> we compile our code. One more special macro won't hurt us.)
>
> Of course, it might not be that simple. Is it?
Almost. As I have oft repeated in these pages, it takes careful thought
to determine how best to drive a cleavage plane through the Standard C++
library, to leave a maximally useful ``subset'' with no loose ends. That's
what the designers of EC++ did. I actually implemented their ideas by
reworking the full C++ library -- indeed with lots of #if logic. With a tad
more work, I could probably supply one set of headers that yields either
an EC++ or a full C++ library, depending on just one predefined macro.
You'd better be careful to link with the right binary library as well. In
practice, however, it's tidier to package two distinct libraries -- headers
plus corresponding binary library.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/22 Raw View
James Kuyper <kuyper@wizard.net> wrote in article <35B4D4C8.167E@wizard.net>...
> There are degrees of portability, but in the absence of a modifying
> adjective, when I say "portable" I'm referring to code that can be
> translated by any conforming implementations of C++ with NO extra work.
> That is why I claim that portability is an ideal, not an achievable
> goal.
``Portable'' is a statement about the *cost* of moving code between
implementations. It is never zero. It is usually colloquially approximated
as a boolean. So a person who says ``this code is portable'' usually
means ``this code is cheap enough to port that I'd rather port it than
rewrite it.'' We could shorten many semantic dances in these threads
if more of us accepted the fuzzy logic behind the definition of ``portable.''
> I'd like to point out that recent messages have suggested that
> __ecplusplus is not the correct symbol anyway. If true, this implies
> that even intense advocates of EC++ aren't always aware of the correct
> name of the macro; how can other people be expected to know of and avoid
> it?
It implies that the guy who first lobbed out the name doesn't use it every day
and didn't bother to look it up. What a quibble.
> > > What they did say was that the need to test for
> > > such symbols proves that EC++ is not a strict subset of C++. There is a
> > > strong relationship, it's just more complex than simple subsetting.
> >
> > Granted. Why is this important?
>
> Precision of meaning; if it isn't a subset, don't call it one. Use some
> kind of modifyier to at least hint at the true relationship. Plauger has
> already said that he is sorry he ever used the word.
Yeah. What I wish I'd said instead is:
``There clearly is a close relationship between EC++ and C++, so close that
the mathematical notion of a subset is a reasonable way of describing
it (given appropriate caveats where required by context), just as the
mathematical notion of a sphere is a reasonable way of describing the
shape of the earth (given appropriate caveats where required by context
- rotation imposes a slight flattening at the poles). In both cases,
the mathematical notion is a useful approximation of reality.''
This is a direct quote from a recent posting by Stroustrup, with EC++
written in place of C. As such, it is not strictly a subset of his words...
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/07/22 Raw View
In article <DvNBvDA$WNt1EwW1@noco.demon.co.uk>,
Mike Davies <mike_davies@noco.demon.co.uk> wrote:
> In article <6p05im$d92$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
> writes
> >In article <rPLLHCA++9r1EwhI@noco.demon.co.uk>,
> > Mike Davies <mike_davies@noco.demon.co.uk> wrote:
> >> In article <35AF2A6B.DDA4B716@acm.org>, Pete Becker <petebecker@acm.or=
> g>
> >> writes
> >> >Tell that to the maintenance programmer who works on C++ code written
> >> >five years ago. In many cases it's much easier to get it to compile w=
> ith
> >> >EC++ than with Standard C++.
> >>
> >> Unless it uses a template
> >
> >If the code was written five years ago, there's really very little
> >chance that it used templates. =20
>
> You are being careful to miss the point, I think. If code of around that
> era used templates, then there is *no* chance that it will compile under
> EC++.
And you're missing my point. Even today, shops concerned with a maximum
of portability ban templates, because they still don't work portabily.
In the places I've worked for, we gradually started introducing templates
about 1 1/2 or 2 years ago, not before.
As always, there is a trade-off involved; having written major applications
without templates, I do recognize their usefulness. I also recognize that
both their usefulness and their cost vary from one application to the
next -- in most of my work (although not currently), portability was
an important criteria.
> I was using templates in code for industrial applications in late 1994,
> ie 31/2 years ago. I first started using them roughly a year before
> that. I hadn't realised that the post was referring so strictly to a 5
> year timescale, I don't know what reason you have for suggesting this ?
Well, some of my code is eight years old, and still being used. At least
one application I know of is still being maintained and expanded with my
generic.h version of reference counted pointers and associative arrays,
despite the ban on templates having been lifted. (If it ain't broke,
don't fix it.)
> I would expect templates to have crept into *most* C++ code from any era
> under the normal development process. They're just too generally useful.
See above: if it ain't broke, don't fix it. Older applications do evolve,
and the ban on templates has been lifted in most (but not all) shops. But
most older applications will continue using the containers that worked;
no one wants to rewrite a complete application just to replace a generic.h
class with a template class. We prefer spending the time adding features.
> >They existed, but in about the same
> >way namespaces do now; some compilers supported them, but you wouldn't
> >count on their being available in portable code.
>
> There was no standard for C++ in those days, people fell over themselves
> to buy compilers that supported templates. It was a major issue in
> reviews of compilers IIRC.
It depends on the market. In the PC world, I think you're right, although
Microsoft was able to compete successfully for quite a while without
templates, even though Borland had them. The issue has never been simple.
> >For that matter, some serious portability guides say to avoid templates
> >even today, since no two compilers implement them in the same way. (I'v=
> e
> >found that with a few conditional includes, and by keeping them simple,
> >they can be made to work. But this is a very recent developement.)
>
> My opinion is that cross-compiler portability is and always has been a
> minor issue for a large section of the market, particularly under MS
> Windows.
Totally agreed. And I see absolutely no role for EC++ as a compiler for
Windows programs. Cross-compiler portability often is an issue on embedded
processors, since you want to be free to move up to a newer processor
in the next version.
For that matter, since I don't think I've made myself clear enough, I
don't really see a role for EC++ on processors that already have full
C++ compilers. Where I do see it playing a role, today, is as an upgrade
path for systems where the only language currently available is C.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/07/21 Raw View
Nathan Myers wrote:
>
> Pete Becker <petebecker@acm.org> wrote:
> >Nathan Myers wrote:
> >> All that has been established is that certain immature implementations
> >> add code bloat, under various usages.
> >
> >Apparently every implementation that anyone has been able to provide
> >data for in this discussion is immature, and only the ones that nobody
> >talks about can actually handle the standard C++ library adequately.
> >Wouldn't it be nice if those who view this as a solved problem would,
> >just this once, give us a hint as to where these marvelous, mature
> >implementations are hiding?
>
> Is this a troll?
>
> The standard has not been officially ratified yet. Of course all
> current implementations are immature. Certainly none are fully
> conforming (despite any inflated claims that may appear in advertising)
> even if you allow for workarounds for bugs in the standard. Any
> measurements taken today are necessarily of immature implementations.
Many of the 'new' features of the proposed standard have been fixed for
a very long time. The standard itself has been closed to significant
changes for a couple of months at least. Some of the bigger implementors
can afford to produce speculative versions of their product. I believe
that failed attempts to implement proposed changes by some of the
implementors who monitor the standardization process have been a
significant source of conversation on this newsgroup.
Implementations that come very close to conforming to the new standard
are already available; a fully conforming one shouldn't be long in
coming. Thus, the issue of whether any close-to-conformiing
implementation provides the suggested optimizations is entirely
appropriate.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ark@research.att.com (Andrew Koenig)
Date: 1998/07/21 Raw View
In article <35B292C1.C6A80B20@acm.org>,
Pete Becker <petebecker@acm.org> wrote:
> Andrew Koenig wrote:
> > In article <35B1DE32.5970A91A@acm.org>,
> > Pete Becker <petebecker@acm.org> wrote:
> > > However, if it were an international standard, adopted by the ISO C++
> > > committee, it would then be a proper subset with one trivial change to
> > > the C++ language definition.
> > As I said before, whether or not a change is trivial is a matter
> > of opinion, and differences of opinion in this matter can be profound.
> Context, please. The assertion wast that EC++ is not a proper subset
> because it relies on the identifier __embedded_cplusplus to indicate
> that the EC++ subset is in use. How would adopting this identifier
> result in profound changes?
I said nothing about profound changes. Read it again. I said that there
are profound differences of opinion about whether or not a change is trivial.
> > Moreover, the balloting for the C++ standard is closed. I don't know
> > the results of the vote, but if it is affirmative, the C++ language is
> > closed to changes, trivial or not, for at least five years.
> Yes. What's your point?
My point is that if you're suggesting that the C++ standard should be
changed to require a particular value for __embedded_cplusplus, it's too late.
> BTW, I read your earlier message in comp.lang.c before it disappeared.
> <g>
Umm... what message? I don't recall cancelling one, but I've been posting
a lot of stuff recently so I may have forgotten.
--
--Andrew Koenig
ark@research.att.com
http://www.research.att.com/info/ark
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/07/21 Raw View
In article <rPLLHCA++9r1EwhI@noco.demon.co.uk>,
Mike Davies <mike_davies@noco.demon.co.uk> wrote:
> In article <35AF2A6B.DDA4B716@acm.org>, Pete Becker <petebecker@acm.org>
> writes
> >Tell that to the maintenance programmer who works on C++ code written
> >five years ago. In many cases it's much easier to get it to compile with
> >EC++ than with Standard C++.
>
> Unless it uses a template
If the code was written five years ago, there's really very little
chance that it used templates. They existed, but in about the same
way namespaces do now; some compilers supported them, but you wouldn't
count on their being available in portable code.
For that matter, some serious portability guides say to avoid templates
even today, since no two compilers implement them in the same way. (I've
found that with a few conditional includes, and by keeping them simple,
they can be made to work. But this is a very recent developement.)
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/07/21 Raw View
In article <6oobas$16a$1@shell7.ba.best.com>,
ncm@nospam.cantrip.org (Nathan Myers) wrote:
> David R Tribble <dtribble@technologist.com> wrote:
> >
> >It's been pretty well established that locale facet templates add
> >code bloat when using iostreams.
>
> Is this a troll? It has not been "established", or even "pretty well
> established".
>
> All that has been established is that certain immature implementations
> add code bloat, under various usages. Repeating hearsay as fact does
> not improve the quality of the discussion.
Just a reminder that the "immature" implementations include all of those
based on the EDG front-end (which I'd heard was one of the best), EGCS
(leading-edge by some standards), VC++ and just about every other compiler
anyone here has cared to report about (Watcom being a potential exception).
I think if I were one of the implementors of any of these compilers, I'd
feel insulted.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/21 Raw View
In article <01bdb31f$89bd8920$8a1ec2d0@porky>, "P.J. Plauger"
<pjp@dinkumware.com> writes
>Mike Davies <mike_davies@noco.demon.co.uk> wrote in article <W+SlHHACzOs1EwNq@no
>co.demon.co.uk>...
>> I don't see the similarity at all. EC++ has been cut down from C++ for
>> the stated reason that C++ gives too large executables for some resource
>> constrained systems. The fact that templates do not contribute to code
>> bloat *at all* (in any reasonable implementation) is ignored by its
>> proponents.
>
>Excuse me, but I don't believe that's true. If you have the patience to wade
>back through this entire thread, you should find several occasions where the
>issue has been addressed. I will be as brief as possible in recapping.
>
>The folks who developed the EC++ specification had multiple goals in mind,
>not just avoiding language features that are likely to cause code bloat.
>Some features were omitted simply because they are too new. I know this
>annoys the more adventuresome enthusiasts of the new C++ Standard, but
>it is also sound engineering practice in many contexts. (James Kanze does
>the best job of explaining why.)
New ? Templates have been in the Borland compiler (thats just the one I
know) since 1994.
>Templates do not automatically cause code bloat, but they can contribute.
You agree with me that templates do not cause code bloat then ?
>I saw some increase in code size when I templatized iostreams, complex,
>and strings -- not because of the template technology per se but because
>of the restructuring needed to deal with arbitrary instead of known types in
>certain contexts.
You can always use specialisation to get rid of this.
> And, of course, we all know that injudicious use of
>templates -- specializing them for more types than are really needed -- can
>cause serious bloat.
As can intentionally writing dead code of any sort with the right (ie
wrong) compiler switches set.
...snip some stuff that made sense..
>P.J. Plauger
Regards,
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/07/21 Raw View
In article <01bdb183$a70cada0$8a1ec2d0@porky>,
"P.J. Plauger" <pjp@dinkumware.com> wrote:
> part of the C++ Standard. It's a trivial distinction to me, but them I'm a
> flaming pragmatist.
Wow, that's gotta hurt.
It must be convenient for outdoor barbeques, though.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/07/21 Raw View
dietmar.kuehl@claas-solutions.de wrote:
>
> One approach is the use of ELF weak symbols: The first implementation of the
> inserters and extractors of iostreams found in the library does not use
> facets to do the formatting. Of course, this can only be done, if the user
> cannot tell that facets are not used. The only way the user can tell that one
> of the standard facets is used, is to install one which overrides the
> standard behavior. This in turn means, the user has to call
> 'locale::global()' or 'ios_base::imbue()' (there are some other functions,
> too). Putting the implementations of these two functions into the same object
> file like the implementation of another set of inserters and extractors, this
> time using facets, guarantees that if the locale is replaced, the full blown
> implementation is used.
That gives you the most important level of control: programs that don't
use locales won't get any locale code. Those that do get everything.
That's a good start.
> Actually, it is not really necessary to fall back to
> the full blown implementation immediately: There can still be finer control
> depending on the replaced facets (yes, this can also be done at link time!).
OK. Then the tradeoff you have to make is complexity in the library
versus fine-grained control.
>
> Considering that Dinkumware's library is shipped with VC++ I think that there
> are some problems related to DLLs: The above approach assumes the typically
> UNIX approach to library construction. If DLLs or shared libraries are used,
> things become a little bit different.
DLLs pose their own set of problems, because they're built
independently of the application that uses them. The state of the art
today is to put the entire runtime library into a single DLL, on the
assumption that the code will be shared by multiple applications, so the
space overhead really isn't that bad.
At the other extreme, I suppose it would be possible to do something
analogous to the technique used in static libraries, one function per
DLL. You'd get the granularity, but at the cost of imposing a tremendous
burden on the loader. Application startup would probably be very slow,
because of the time needed to load each of the DLLs. And the disk space
needed to store all those DLLs would be much greater than for a single
DLL.
Thanks for the information.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/07/21 Raw View
Andrew Koenig wrote:
>
> In article <35B292C1.C6A80B20@acm.org>,
> Pete Becker <petebecker@acm.org> wrote:
>
> > > Moreover, the balloting for the C++ standard is closed. I don't know
> > > the results of the vote, but if it is affirmative, the C++ language is
> > > closed to changes, trivial or not, for at least five years.
>
> > Yes. What's your point?
>
> My point is that if you're suggesting that the C++ standard should be
> changed to require a particular value for __embedded_cplusplus, it's too late.
Since I've been involved in the C++ standardization effort for as long
as you have, and am well aware of the fact that the standard has just
been approved, can you think of an explanation for what I said that
doesn't assume that I'm stupid? <g>
>
> > BTW, I read your earlier message in comp.lang.c before it disappeared.
> > <g>
>
> Umm... what message? I don't recall cancelling one, but I've been posting
> a lot of stuff recently so I may have forgotten.
Looks like a newsreader glitch. Never mind.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Gabriel Dos_Reis <gdosreis@sophia.inria.fr>
Date: 1998/07/21 Raw View
jkanze@otelo.ibmmail.com writes:
>
> Just a reminder that the "immature" implementations include all of those
> based on the EDG front-end (which I'd heard was one of the best), EGCS
> (leading-edge by some standards), VC++ and just about every other compiler
> anyone here has cared to report about (Watcom being a potential exception).
> I think if I were one of the implementors of any of these compilers, I'd
> feel insulted.
That is an overstatement.
Nathan talked about *implementations*, not implementers. I can't
imagine that those implementations you report are mature
implementations of Standard C++.
--
Gabriel Dos Reis | Centre de Math=E9matiques et de
dosreis@cmla.ens-cachan.fr | Leurs Applications
Fax : (33) 01 47 40 21 69 | ENS de Cachan -- CNRS (URA 1611)
61, Avenue du Pdt Wilson, 94235 Cachan - Cedex
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: wkdugan@ix.netcom.com (Bill Dugan)
Date: 1998/07/21 Raw View
On 21 Jul 1998 00:49:58 GMT, ark@research.att.com (Andrew Koenig)
wrote:
>In article <35B292C1.C6A80B20@acm.org>,
>Pete Becker <petebecker@acm.org> wrote:
>
>> BTW, I read your earlier message in comp.lang.c before it disappeared.
>> <g>
>
>Umm... what message? I don't recall cancelling one, but I've been posting
>a lot of stuff recently so I may have forgotten.
There's a large-scale cancel war going on across much of Usenet. The
comp.* groups haven't been hit much yet, but it's possible you were
caught in the cross-fire. See the Cancel War thread in
news.admin.net-abuse.policy for details.
[ moderator's note: I'm allowing this as a possible answer to
the question. Please take further discusssion of cancellations
to another newsgroup. -sdc ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/07/21 Raw View
In article <35AF6AD7.794B@wizard.net>,
James Kuyper <kuyper@wizard.net> wrote:
> AllanW@my-dejanews.com wrote:
> ...
> > But my point was that most non-trivial programs make use of at least
> > one non-portable feature of the current compiler/environment. This
> > does not stop a program from being portable if it makes use of
> > conditional compilation, so that it can use suitable non-portable
>
> If your code uses such symbols to conditionally compile one of two
> different implementation-specific pieces of code, there is always the
> possibility that a third choice will need to be added when porting to a
> new environment.
Exactly.
> That makes it non-portable.
No! By isolating the non-portable sections, we ensure that the port is
easy. Find the source files that use conditional compilation (ideally
this is only one source file -- in most of my projects, it is called
SYSDEPEND.H), add a new section for the new target, and then build the
entire system. Tests and debugging should be constrained to changing
only the new section, until the program is certified on the new system
or until you can demonstrate that this is impossible. (This can happen
because some section of code which was NOT marked as non-portable,
turned out to be non-portable anyway. Hopefully this is rare, but it
does happen in the real world.)
> Portable code is an ideal to be approached, not a practical goal to be
> achieved.
Depends on what you call "portable," I suppose. I would say that the
technique above makes code "portable" because it can be compiled on
any identified platform with no extra work, and it can be compiled
on any other standard C++ platform with minimal extra work.
> The way to approach portability is to avoid such code wherever
> possible, and to isolate such code in as few modules as possible.
Aren't we saying the same thing, in different words?
> > features in various environments. This type of conditional
> > compilation is best accomplished by use of vendor-supplied
> > implementation-defined precompiler symbols, which by their very
> > nature cannot be legislated into the C++ standard. To suggest that
> > one should never use these symbols is ludicrous.
>
> No one suggested that.
Yes, someone DID suggest that. I don't want to spend time tracking
down the original quotation (look in Deja News if you're interested).
But someone said something amazingly similar to:
@ #include <iostream>
@ #ifdef __ecplusplus
@ # define std
@ #endif
@ int main(int, char*[])
@ {
@ std::cout << "Hello world!" << std::endl;
@ return 0;
@ }
@
@ This is not legal in C++ because a standard C++ compiler is
@ allowed to define the symbol __ecplusplus, even if it's not
@ an EC++ compiler.
Which is exactly what I was ranting about in the paragraph quoted
above. Again, just because a C++ compiler *CAN* define such a
symbol, doesn't mean that it *WILL* define it.
(As an extreme, consider a hypothetical compiler with a
preprocessor that considers any symbol beginning with two
underscores to be defined. You might convince me that this
compiler was standard C++. You wouldn't convince me that this
was A Good Thing.)
Many people have suggested that __ecplusplus might have a name
clash with some hypothetical C++ vendor that offered vendor-specific
"extensions" to C++ -- that is, __ecplusplus might stand for
"Extended C++". I'll grant that this is at least possible, and
that if it happened I wouldn't "blame" that vendor for not being
able to predict the future and the possible existence of EC++.
But, does anyone happen to know of a real vendor, on any platform
anywhere in the world that actually does this? Because:
(1) If not, then my point stands.
(2) If there are few (say, 1-2) such vendors, then the concept
almost works as-is. After all, we can at least assume that
some vendor who never defined __ecplusplus before, and is
not writing an EC++ compiler, will not define __ecplusplus
in the future -- at least, not if that vendor has access to
the internet and this newsgroup. So once we have
identified the vendors that have done it before (and may
need to keep doing it, for backwards compatibility for
their customers), we can use code like this:
#if defined(__ecplusplus) && !defined(__VENDOR1)
(3) If there are many (say, 3 or more), then the EC++ camp
(p.s. I am NOT one of them) will have to select a better
identifier, such as "__embedded_c_plus_plus_standard", but
the concept is still valid.
> What they did say was that the need to test for
> such symbols proves that EC++ is not a strict subset of C++. There is a
> strong relationship, it's just more complex than simple subsetting.
Granted. Why is this important?
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/21 Raw View
dietmar.kuehl@claas-solutions.de wrote in article <6ov12i$rb3$1@nnrp1.dejanews.com>...
> I'm not going to give you my incomplete implemenation of IOStreams/locales
> but I hope that telling you how things basically work are sufficient.
Well, generalities are nice, but numbers are better. Didn't learn anything
new from what you revealed.
> There is a solution
> to this problem, too. ...but I hope that you understand that I don't reveal
> all of my implementation.
No, I don't understand. Not when you simultaneously make pious
pronouncements like the following:
: > David R Tribble <dtribble@technologist.com> wrote:
: > >> It's been pretty well established that locale facet templates add
: > >> code bloat when using iostreams. (Perhaps it's not templates that
: >> are the problem, but an overly ambitious iostream specification?)
:
: What? Who established that? This is not at all true! There is no need at all
: for code bloat when using iostreams which results from locales, unless
: locales are explicitly used.
Microsoft ships the full source code of our library with VC++. Most of the
code in question is in the headers. Anyone who studies it can see that we
make a serious effort to keep the size of executables small -- without
sacrificing performance. No secrets there.
This thread has seen repeated assertions to the effect that any inefficiencies
in implementing the Standard C++ library are due to shortcomings of library
and compiler implementations of ``immature'' (available) systems. Pete Becker
and I have repeatedly asked for guidance on how to make our implementation
better. It's nice to know that some compilers optimize away virtuals and some
others support weak references -- both offer hope for the future. If there are
still other techniques that can help, it would be nice to hear about them too.
Inquiring minds want to know.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/07/21 Raw View
In article <xKtdmDA6k4s1EwLs@noco.demon.co.uk>,
Mike Davies <mike_davies@noco.demon.co.uk> wrote:
> New ? Templates have been in the Borland compiler (thats just the one I
> know) since 1994.
And even today, it is extremely difficult to write a portable program that
uses templates. As late as Nov., 1997, the committee was rewording the
template chapter, because of problems. Even today, I know of NO compiler
which implements templates as they are described in the standard.
Given this, should you simply ban templates? As usual, it is a trade-off;
having written and maintained code using generic.h, I can say that while
using templates involves a certain risk, and a certain amount of bother,
not using them, at least for simple containers, is VERY expensive. If a
failure in the program would result in the meltdown of a nuclear reactor,
or something similar, I suspect that I'd ban them, but for anything less,
the cost of not using them is simply too high.
None of which is really relevant to this thread. EC++ has been stable
for a couple of years now. A couple of years ago, it was anyone's guess
as to what the standard would require of templates. If EC++ were still
evolving, I would guess that they could now consider adding a simplified
form of templates: say only supporting class templates, and requiring a
typedef of the template at global scope to trigger instantiation. It is
now clear that the Borland model, and not the CFront model, has prevailed.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/21 Raw View
In article <6p05im$d92$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
writes
>In article <rPLLHCA++9r1EwhI@noco.demon.co.uk>,
> Mike Davies <mike_davies@noco.demon.co.uk> wrote:
>> In article <35AF2A6B.DDA4B716@acm.org>, Pete Becker <petebecker@acm.or=
g>
>> writes
>> >Tell that to the maintenance programmer who works on C++ code written
>> >five years ago. In many cases it's much easier to get it to compile w=
ith
>> >EC++ than with Standard C++.
>>
>> Unless it uses a template
>
>If the code was written five years ago, there's really very little
>chance that it used templates. =20
You are being careful to miss the point, I think. If code of around that
era used templates, then there is *no* chance that it will compile under
EC++.
I was using templates in code for industrial applications in late 1994,
ie 31/2 years ago. I first started using them roughly a year before
that. I hadn't realised that the post was referring so strictly to a 5
year timescale, I don't know what reason you have for suggesting this ?
I would expect templates to have crept into *most* C++ code from any era
under the normal development process. They're just too generally useful.
>They existed, but in about the same
>way namespaces do now; some compilers supported them, but you wouldn't
>count on their being available in portable code.
There was no standard for C++ in those days, people fell over themselves
to buy compilers that supported templates. It was a major issue in
reviews of compilers IIRC.
>For that matter, some serious portability guides say to avoid templates
>even today, since no two compilers implement them in the same way. (I'v=
e
>found that with a few conditional includes, and by keeping them simple,
>they can be made to work. But this is a very recent developement.)
My opinion is that cross-compiler portability is and always has been a
minor issue for a large section of the market, particularly under MS
Windows.
--
Mike Davies
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/07/21 Raw View
P.J. Plauger<pjp@dinkumware.com> wrote:
>This thread has seen repeated assertions to the effect that any
>inefficiencies in implementing the Standard C++ library are due to
>shortcomings of library and compiler implementations of ``immature''
>(available) systems. Pete Becker and I have repeatedly asked for
>guidance on how to make our implementation better.
I don't recall reading any such requests. I _have_ seen repeated
assertions that it is impossible to implement the standard library
without prohibitive overhead, and demands to produce evidence of a
library that doesn't exhibit such overhead.
It takes time to implement a full standard-conforming library, and
more time to optimize it for a small footprint. When it's ready,
it will be available.
>It's nice to
>know that some compilers optimize away virtuals and some others
>support weak references -- both offer hope for the future. If there
>are still other techniques that can help, it would be nice to hear
>about them too.
I counsel patience.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/07/22 Raw View
Nathan Myers wrote:
>
>
> I don't recall reading any such requests. I _have_ seen repeated
> assertions that it is impossible to implement the standard library
> without prohibitive overhead,
I don't recall reading any such assertions. I _have_ seen repeated
assertions that it is harder than most people think to implement the
standard library without prohibitive overhead.
> and demands to produce evidence of a
> library that doesn't exhibit such overhead.
Well, not "demands", but insistence that engineering evaluations be
based on engineering and not on speculation. That seems like a
reasonable thing to ask for in a discussion about engineering.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/22 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> wrote in article <xKtdmDA6k4s1EwLs@noco.demon.co.uk>...
> New ? Templates have been in the Borland compiler (thats just the one I
> know) since 1994.
Yes, and that implementation a) was buggy and b) is now outdated. Even
the much touted EDG front end still lacks template templates, and no two
implementations are alike in what they do support. I think that it's thus fair
to characterize template technology as ``new.''
> >Templates do not automatically cause code bloat, but they can contribute.
>
> You agree with me that templates do not cause code bloat then ?
I'd answer with a simple yes, if there were not a tedious parallel thread about
the difference between a subset and an almost subset.
> >I saw some increase in code size when I templatized iostreams, complex,
> >and strings -- not because of the template technology per se but because
> >of the restructuring needed to deal with arbitrary instead of known types in
> >certain contexts.
>
> You can always use specialisation to get rid of this.
Modulo combinatoric explosion, perhaps to some extent. But you can still
imbue an istream< char, char_traits<char> > with an arbitrary locale, and
the implementation has to be prepared for all sorts of changes in the behavior
of several facets. The structural problems remain.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/07/22 Raw View
AllanW@my-dejanews.com wrote:
>
> In article <35AF6AD7.794B@wizard.net>,
> James Kuyper <kuyper@wizard.net> wrote:
> > AllanW@my-dejanews.com wrote:
> > ...
> > > But my point was that most non-trivial programs make use of at least
> > > one non-portable feature of the current compiler/environment. This
> > > does not stop a program from being portable if it makes use of
> > > conditional compilation, so that it can use suitable non-portable
> >
> > If your code uses such symbols to conditionally compile one of two
> > different implementation-specific pieces of code, there is always the
> > possibility that a third choice will need to be added when porting to a
> > new environment.
>
> Exactly.
>
> > That makes it non-portable.
>
> No! By isolating the non-portable sections, we ensure that the port is
> easy. Find the source files that use conditional compilation (ideally
> this is only one source file -- in most of my projects, it is called
> SYSDEPEND.H), add a new section for the new target, and then build the
I suspect that the __ecplusplus check will need to be done in almost
every module of most programs. That doesn't count as well-isolated to
me.
> entire system. Tests and debugging should be constrained to changing
> only the new section, until the program is certified on the new system
> or until you can demonstrate that this is impossible. (This can happen
> because some section of code which was NOT marked as non-portable,
> turned out to be non-portable anyway. Hopefully this is rare, but it
> does happen in the real world.)
My experience is that it's quite common. Much of the code I've worked on
has been touched at least once by programmers with less than 2 years of
practical experience in C/C++, many of them ex-FORTRAN programmers. They
just barely understand the language itself, never mind being aware of
portability issues.
> > Portable code is an ideal to be approached, not a practical goal to be
> > achieved.
>
> Depends on what you call "portable," I suppose. I would say that the
> technique above makes code "portable" because it can be compiled on
> any identified platform with no extra work, and it can be compiled
> on any other standard C++ platform with minimal extra work.
There are degrees of portability, but in the absence of a modifying
adjective, when I say "portable" I'm referring to code that can be
translated by any conforming implementations of C++ with NO extra work.
That is why I claim that portability is an ideal, not an achievable
goal.
> > The way to approach portability is to avoid such code wherever
> > possible, and to isolate such code in as few modules as possible.
>
> Aren't we saying the same thing, in different words?
You call the result "portable", I would refer to it as "more nearly
portable". There's a difference of attitude implicit in the different
wording.
> > > features in various environments. This type of conditional
> > > compilation is best accomplished by use of vendor-supplied
> > > implementation-defined precompiler symbols, which by their very
> > > nature cannot be legislated into the C++ standard. To suggest that
> > > one should never use these symbols is ludicrous.
> >
> > No one suggested that.
>
> Yes, someone DID suggest that. I don't want to spend time tracking
> down the original quotation (look in Deja News if you're interested).
> But someone said something amazingly similar to:
>
> @ #include <iostream>
> @ #ifdef __ecplusplus
> @ # define std
> @ #endif
> @ int main(int, char*[])
> @ {
> @ std::cout << "Hello world!" << std::endl;
> @ return 0;
> @ }
> @
> @ This is not legal in C++ because a standard C++ compiler is
> @ allowed to define the symbol __ecplusplus, even if it's not
> @ an EC++ compiler.
>
> Which is exactly what I was ranting about in the paragraph quoted
> above. Again, just because a C++ compiler *CAN* define such a
> symbol, doesn't mean that it *WILL* define it.
He didn't say you couldn't do it; he just said you couldn't do it in
strictly conforming C++ (he might have used the word "illegal" as
shorthand for this statement). Strictly conforming code is extremely
rare in practice, but it is the proper subject for a standards
discussion.
> (As an extreme, consider a hypothetical compiler with a
> preprocessor that considers any symbol beginning with two
> underscores to be defined. You might convince me that this
> compiler was standard C++. You wouldn't convince me that this
> was A Good Thing.)
I'd like it. It shouldn't break any code I've written that wasn't
intended to be implementation-specific; if it did, that would be
something I'd want to know.
> Many people have suggested that __ecplusplus might have a name
> clash with some hypothetical C++ vendor that offered vendor-specific
> "extensions" to C++ -- that is, __ecplusplus might stand for
> "Extended C++". I'll grant that this is at least possible, and
> that if it happened I wouldn't "blame" that vendor for not being
> able to predict the future and the possible existence of EC++.
> But, does anyone happen to know of a real vendor, on any platform
> anywhere in the world that actually does this? Because:
> (1) If not, then my point stands.
I'd like to point out that recent messages have suggested that
__ecplusplus is not the correct symbol anyway. If true, this implies
that even intense advocates of EC++ aren't always aware of the correct
name of the macro; how can other people be expected to know of and avoid
it?
...
> > What they did say was that the need to test for
> > such symbols proves that EC++ is not a strict subset of C++. There is a
> > strong relationship, it's just more complex than simple subsetting.
>
> Granted. Why is this important?
Precision of meaning; if it isn't a subset, don't call it one. Use some
kind of modifyier to at least hint at the true relationship. Plauger has
already said that he is sorry he ever used the word.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/07/22 Raw View
<jkanze@otelo.ibmmail.com> wrote:
>... even today, it is extremely difficult to write a portable program that
>uses templates. As late as Nov., 1997, the committee was rewording the
>template chapter, because of problems.
This vastly overstates the case. Four years ago there were wide
variations in what different implementations would support, but
very broad areas of agreement. All have converged since.
The largest areas of incompatibility amounted to pure bugs, where
a compiler would crash when presented with certain constructs.
It has been years since that was a common occurrence on compilers
that compete based on quality and service.
> ... A couple of years ago, it was anyone's guess
>as to what the standard would require of templates.
Again, this is an extreme interpretation. Many people have been
writing templates in portable (and widely ported) production code
for years. The then-unresolved areas in the standard (corresponding
to still-unimplemented features in current compilers) were and are
easily avoided.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <david.tribble@noSPAM.central.beasys.com>
Date: 1998/07/22 Raw View
David R Tribble <dtribble@technologist.com> wrote:
> >> It's been pretty well established that locale facet templates add
> >> code bloat when using iostreams. (Perhaps it's not templates that
> >> are the problem, but an overly ambitious iostream specification?)
P.J. Plauger wrote:
> ...
> Microsoft ships the full source code of our library with VC++. Most of
> the code in question is in the headers. Anyone who studies it can see
> that we make a serious effort to keep the size of executables small --
> without sacrificing performance. No secrets there.
>
> This thread has seen repeated assertions to the effect that any
> inefficiencies in implementing the Standard C++ library are due to
> shortcomings of library and compiler implementations of ``immature''
> (available) systems. Pete Becker and I have repeatedly asked for
> guidance on how to make our implementation better. It's nice to know
> that some compilers optimize away virtuals and some others support
> weak references -- both offer hope for the future. If there are still
> other techniques that can help, it would be nice to hear about them
> too.
>
> Inquiring minds want to know.
I realize it would be considered "nonconforming" to do so, or at
least nonportable, but would it be reasonable for you to add #ifs
for a special macro that I could set at compile time to disable the
locale baggage when using <iostream>? Something like
'_NO_IO_LOCALES' or '_DFL_IO_LOCALE'? This assumes, of course,
that I know at compile time that I won't be needing any of the
iostream locale stuff.
I know this isn't a solution to the bigger general problem at hand,
but it is certainly a practical solution. (Practically speaking,
we enable quite a few compiler switches and macro definitions when
we compile our code. One more special macro won't hurt us.)
Of course, it might not be that simple. Is it?
FWIW, we currently don't use <iostream>, but do use a little of
<iostream.h>, for the simple reason that our code is ported to
several Unixes as well as Win32, and only a few of them come
close to full-blown standard <iostream> support. As I have
stated in another thread, we code in GCD-C++, which is a realistic
intersection of the capabilities of the currently available
C++ compilers and libraries we use. Eventually, GCD-C++ will
approach standard C++, but for the next year or two, it remains
a transitionary subset. (I envy those posters who only use one
compiler which is very close to std::C++.)
-- David R. Tribble, dtribble@technologist.com --
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/20 Raw View
In article <6oqtm3$21a$1@mulga.cs.mu.OZ.AU>, Fergus Henderson
<fjh@cs.mu.OZ.AU> writes
>Mike Davies <mike_davies@noco.demon.co.uk> writes:
>
>>In article <35AF2A6B.DDA4B716@acm.org>, Pete Becker <petebecker@acm.org>
>>writes
>>>Tell that to the maintenance programmer who works on C++ code written
>>>five years ago. In many cases it's much easier to get it to compile with
>>>EC++ than with Standard C++.
>>
>>Unless it uses a template
>
>My experience from about five years ago was that templates were
>basically unusable, at least with the implementations that were
>available to me at the time.
You don't say which compilers you were using, but I first came across
templates in Borlands compiler early in '94. I was using templates in
programs for industrial use around the end of that year.
As far as I recollect the templates didn't give me any problems of note.
>Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
Regards,
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: fjh@cs.mu.OZ.AU (Fergus Henderson)
Date: 1998/07/20 Raw View
ark@research.att.com (Andrew Koenig) writes:
>In article <35B1DE32.5970A91A@acm.org>,
>Pete Becker <petebecker@acm.org> wrote:
>
>> However, if it were an international standard, adopted by the ISO C++
>> committee, it would then be a proper subset with one trivial change to
>> the C++ language definition.
>
>As I said before, whether or not a change is trivial is a matter
>of opinion, and differences of opinion in this matter can be profound.
>
>Moreover, the balloting for the C++ standard is closed. I don't know
>the results of the vote, but if it is affirmative, the C++ language is
>closed to changes, trivial or not, for at least five years.
I don't think this is carved in stone. As far as I know it is quite possible,
under ISO rules, for the committee to issue an amendment without waiting
five years. Whether or not they will do so is another question, but
if the committee did decide to standardize EC++, and the committee wanted
to make some minor changes to C++ to make C++ and EC++ more compatible,
then I don't think they would have any difficulty in issuing an
amendment to the C++ standard to make whatever changes were needed.
The rules just say that (a) the committee must consider whether or not
to revise the standard *at least* (not at most) every five years
and (b) the committee can't issue more than two Amendments or Technical
Corigenda without issuing a new version of the standard.
For reference, see <ftp://ftp.iso.ch/pub/out/directives/en/dirp1.html>.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: dietmar.kuehl@claas-solutions.de
Date: 1998/07/20 Raw View
Hi,
In article <35AFEE0B.3FFF@noSPAM.central.beasys.com>,
dtribble@technologist.com wrote:
> David R Tribble <dtribble@technologist.com> wrote:
> >> It's been pretty well established that locale facet templates add
> >> code bloat when using iostreams. (Perhaps it's not templates that
> >> are the problem, but an overly ambitious iostream specification?)
What? Who established that? This is not at all true! There is no need at all
for code bloat when using iostreams which results from locales, unless
locales are explicitly used. My implementation of IOStreams/locales uses
different implementations depending on whether a user used one of the
functions locale::global()' or 'ios_base::imbue()'. Of course, this involves
some trickery at link time (ie. I use ELF weak symbols: the user of the
library wouldn't even note that something special is going on) but it
contradicts your claim that the mere existance of locales and the prescribed
use of facets in IOStreams imply code bloat. It is well established that some
people don't think about optimization potential but rather claim that things
are bad. A good implementation of the standard C++ library is not as straight
forward as some people want it to be! You can and you have to play tricks to
provide a small footprint, if this is the optimization goal. However, most of
the time this is not the primary optimization goal: normally, speed is the
major goal, small footprint is actually only a minor goal most of the time.
Fortunately, optimizing for a small footprint does not always contradict
optimizing for speed...
> Andrew Koenig wrote:
> > Surely that is not a justification for dropping templates outright?
>
> Uh, no. But it could be a justification for dropping the iostream
> library. Or at least the ambitious (baggage) parts.
If you think that IOStreams are too fat for you application, just don't use
them: If you don't use them, you are not paying for them. If you want them
and need an implementation optimized for a certain aspect, use an
implementation which is opitimized for that aspect rather than one which is
not. I know that most current implementations of IOStreams/locales are
optimized for one aspect only, namely their pure existance! I haven't seen an
implementation which is optimized for a small footprint yet (except the one
I'm working on but this doesn't count because it is not yet complete and not
yet released). However, instead of complaining about the "well established"
fact that IOStreams/locales imply code bloat, people should rather think
about how to avoid this...
-- <mailto:dietmar.kuehl@claas-solutions.de>
homepage: <http://www.informatik.uni-konstanz.de/~kuehl>
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/07/20 Raw View
Andrew Koenig wrote:
>
> In article <35B1DE32.5970A91A@acm.org>,
> Pete Becker <petebecker@acm.org> wrote:
>
> > However, if it were an international standard, adopted by the ISO C++
> > committee, it would then be a proper subset with one trivial change to
> > the C++ language definition.
>
> As I said before, whether or not a change is trivial is a matter
> of opinion, and differences of opinion in this matter can be profound.
Context, please. The assertion wast that EC++ is not a proper subset
because it relies on the identifier __embedded_cplusplus to indicate
that the EC++ subset is in use. How would adopting this identifier
result in profound changes?
>
> Moreover, the balloting for the C++ standard is closed. I don't know
> the results of the vote, but if it is affirmative, the C++ language is
> closed to changes, trivial or not, for at least five years.
Yes. What's your point?
BTW, I read your earlier message in comp.lang.c before it disappeared.
<g>
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: dietmar.kuehl@claas-solutions.de
Date: 1998/07/20 Raw View
Hi,
In article <35B0BE6D.660FA634@acm.org>,
Pete Becker <petebecker@acm.org> wrote:
> Wouldn't it be nice if those who view this as a solved problem would,
> just this once, give us a hint as to where these marvelous, mature
> implementations are hiding?
I'm not going to give you my incomplete implemenation of IOStreams/locales
but I hope that telling you how things basically work are sufficient. Since
I'm doing this implemenation in my spare time it simply takes a long time to
finish. I hope that I have it in a reasonable form at the next committee
meeting.
One approach is the use of ELF weak symbols: The first implementation of the
inserters and extractors of iostreams found in the library does not use
facets to do the formatting. Of course, this can only be done, if the user
cannot tell that facets are not used. The only way the user can tell that one
of the standard facets is used, is to install one which overrides the
standard behavior. This in turn means, the user has to call
'locale::global()' or 'ios_base::imbue()' (there are some other functions,
too). Putting the implementations of these two functions into the same object
file like the implementation of another set of inserters and extractors, this
time using facets, guarantees that if the locale is replaced, the full blown
implementation is used. Actually, it is not really necessary to fall back to
the full blown implementation immediately: There can still be finer control
depending on the replaced facets (yes, this can also be done at link time!).
Other approaches also exist. I like the weak symbol approach because it does
not compromise efficiency. Of course, this is only one part of it. Other
aspects also have to be taken into account when optimizing for a small
footprint. For example, just because the numeric category is used by
IOStreams, the monetary facets should not be pulled in. There is a solution
to this problem, too. ...but I hope that you understand that I don't reveal
all of my implementation.
Considering that Dinkumware's library is shipped with VC++ I think that there
are some problems related to DLLs: The above approach assumes the typically
UNIX approach to library construction. If DLLs or shared libraries are used,
things become a little bit different. I haven't played around with this but I
think in this case the DLL for the standard C++ library would have to be
split into several DLLs to get a smaller footprint (and a larger footprint
for the whole system if one program uses facets and the other does not). On
the other hand, compared to other object sizes, I don't think that it is
really a reasonable optimization goal to reduce the footprint of the DLL with
the standard C++ library... -- <mailto:dietmar.kuehl@claas-solutions.de>
homepage: <http://www.informatik.uni-konstanz.de/~kuehl>
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/07/20 Raw View
P.J. Plauger wrote:
[...]
> Templates do not automatically cause code bloat, but they can contribute.
> I saw some increase in code size when I templatized iostreams, complex,
> and strings -- not because of the template technology per se but because
> of the restructuring needed to deal with arbitrary instead of known types in
> certain contexts. And, of course, we all know that injudicious use of
> templates -- specializing them for more types than are really needed -- can
> cause serious bloat. But that is just one of many problems that occur when
> you place a powerful tool in naive hands. Library implementors need not and
> should not commit such sins.
How can specializing a template for a type cause code bloat, if that
code is never used? A template which is not *instantiated* should
IMHO not cause anything (except longer compile times and maybe
more memory usage during compilation).
Also, I can well imagine that you can remove much of the complexity
added by just providing the specialisations for the commonly used
types (f.ex. for strings it would be a specialisation of
basic_string<char>), and since in that specialisation you know
which types you are using, you can just program that without
using all the mechanism for general types as in the genmeral template.
For example, in basic_string<char>, you might be able to use things
like EOF directly instread of referring to char_traits<char>::eof(),
since as library vendor you *know* that it's the same, and no conforming
program can tell the difference (there's no way to determine if
char_traits<char>::eof() was instantiated). This way, you should be
able to avoid the overhead of char_traits<char>::eof() completely
*unless* the user accesses it directly (and if you tell him that
this is an overhead against using EOF, he'll be able to decide himself
if he wants that overhead). Of course, if the user decides to
use basic_string<some_weird_self_defined_character_type>, he will
get the overhead back - but then he is explicitly using the feature
which causes the bloat, so having bloat in that case should be OK.
I might be wrong (I never made space measurements), but simple
reasoning lets me conclude it should work this way.
[...]
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/07/20 Raw View
AllanW@my-dejanews.com wrote:
[...]
> Also, if you don't use any undefined symbols, you can't tell if
> plain chars are signed or not. Thus, if your program relies on
> char(127) being less than char(128), you will have to do a great
> deal of casting -- cast to unsigned char to do the test, and
> cast back to plain char for functions such as strcpy().
What about:
#if (1 >> (CHAR_BITS-1)) > CHAR_MAX
#define CHAR_IS_SIGNED
#else
#define CHAR_IS_UNSIGNED
#endif
However, if you want your program to work with signed *and* unsigned
chars, you'd better not rely on char(127)<char(128). Or you have to
use the casts anyway for signed chars and then there's no reason to
repeat the code minus casts for unsigned chars (the cast would come
out as a no-op anyway).
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <david.tribble@noSPAM.central.beasys.com>
Date: 1998/07/21 Raw View
[Be forewarned, this is mildly off-topic.]
>> -- David R. Tribble, dtribble@technologist.com --
>> -- C++, the PL/1 of the 90s.
Bjarne Stroustrup wrote:
> Many would consider that signature line name calling.
So sorry if I hurt your feelings, but, as I've explained in another
thread, I was merely comparing the alleged complexity of C++ in the
90s to the alleged complexity of PL/1 in the 60s. And you must
admit that C++, with all of its exception handling, multiple
inheritance, templates, STL, metaprogramming, and so forth, is a
complex language.
But don't get me wrong. My programming language of choice is C++,
and I enjoy C++ programming a great deal. I wouldn't be posting
here if I didn't care about the language. (FWIF, I liked PL/1
before Pascal and C became popular.)
(BTW, I was also the one who came up with the name "GCD-C++", which
you apparently liked.)
> I doubt we would have seen it except for the heat of the C++ vs
> EC++ debate.
I first used the phrase in a letter to CUJ last year.
-- David R. Tribble, dtribble@technologist.com --
-- GCD-C++ programmer.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/07/21 Raw View
Christopher Eltschka wrote:
...
> #if (1 >> (CHAR_BITS-1)) > CHAR_MAX
That can be done much simpler:
#if CHAR_MIN < 0
> #define CHAR_IS_SIGNED
> #else
> #define CHAR_IS_UNSIGNED
> #endif
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/07/21 Raw View
In article <EwAuMp.9K@research.att.com>,
ark@research.att.com (Andrew Koenig) wrote:
> I suspect that most embedded applications don't use any standard I/O
> facilities at all, in which case the whole question of I/O
> efficiency is moot.
All but the smallest embedded applications I've worked on have had a
serial interface for configuration and debugging. Although it's true
that often, we used our own conversion routines, a simplified form of
ostream (perhaps not supporting any of the formatting flags, for example)
could be very usefull.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <david.tribble@noSPAM.central.beasys.com>
Date: 1998/07/18 Raw View
ark@research.att.com (Andrew Koenig) wrote:
>>> ... we might begin by trying to understand what it is
>>> about namespaces and templates that would render EC++ impossibly
>>> fat.
David R Tribble <dtribble@technologist.com> wrote:
>> It's been pretty well established that locale facet templates add
>> code bloat when using iostreams. (Perhaps it's not templates that
>> are the problem, but an overly ambitious iostream specification?)
Andrew Koenig wrote:
> Surely that is not a justification for dropping templates outright?
Uh, no. But it could be a justification for dropping the iostream
library. Or at least the ambitious (baggage) parts.
Perhaps a subset of C++ (that maybe did indeed have some form of
templates, but perhaps not the full-blown templates of C++) that
did not have iostream capabilities would constitute a reasonable
EC++? Would EC++ with stdio be good enough for embedded programmers
(or programmers porting very old C++ code)?
-- David R. Tribble, dtribble@technologist.com --
-- C++, the PL/1 of the 90s.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/18 Raw View
In article <35AF2A6B.DDA4B716@acm.org>, Pete Becker <petebecker@acm.org>
writes
>Tell that to the maintenance programmer who works on C++ code written
>five years ago. In many cases it's much easier to get it to compile with
>EC++ than with Standard C++.
Unless it uses a template
--
Mike Davies
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/07/18 Raw View
Nathan Myers wrote:
>
> David R Tribble <dtribble@technologist.com> wrote:
> >
> >It's been pretty well established that locale facet templates add
> >code bloat when using iostreams.
>
> Is this a troll? It has not been "established", or even "pretty well
> established".
>
> All that has been established is that certain immature implementations
> add code bloat, under various usages.
Apparently every implementation that anyone has been able to provide
data for in this discussion is immature, and only the ones that nobody
talks about can actually handle the standard C++ library adequately.
Wouldn't it be nice if those who view this as a solved problem would,
just this once, give us a hint as to where these marvelous, mature
implementations are hiding?
> Repeating hearsay as fact does
> not improve the quality of the discussion.
Agreed. <g>
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/07/18 Raw View
Pete Becker <petebecker@acm.org> wrote:
>Nathan Myers wrote:
>> All that has been established is that certain immature implementations
>> add code bloat, under various usages.
>
>Apparently every implementation that anyone has been able to provide
>data for in this discussion is immature, and only the ones that nobody
>talks about can actually handle the standard C++ library adequately.
>Wouldn't it be nice if those who view this as a solved problem would,
>just this once, give us a hint as to where these marvelous, mature
>implementations are hiding?
Is this a troll?
The standard has not been officially ratified yet. Of course all
current implementations are immature. Certainly none are fully
conforming (despite any inflated claims that may appear in advertising)
even if you allow for workarounds for bugs in the standard. Any
measurements taken today are necessarily of immature implementations.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/18 Raw View
In article <35AEA751.3C93@noSPAM.central.beasys.com>, David R Tribble
<david.tribble@noSPAM.central.beasys.com> writes
...snip...
>This is off-topic, but the question about whether or not
>templates belong in EC++ is similar to the question of whether
>or not Java would be a more useful (but still manageable) language
>with something like templates.
I don't see the similarity at all. EC++ has been cut down from C++ for
the stated reason that C++ gives too large executables for some resource
constrained systems. The fact that templates do not contribute to code
bloat *at all* (in any reasonable implementation) is ignored by its
proponents.
> Many programmers feel that Java
>doesn't quite have the power or expressiveness of C++ because it's
>missing templates; on the other hand, others argue that C++ is too
>unwieldly because it has templates.
I cannot see for the life of me why you say that templates make C++
"unwieldy" ? If you don't like them don't use them.
>
>Perhaps we should contemplate languages that have "lightweight"
>or "in-between" templates, such as Eiffel, which provide the
>basics of template programming without going to extremes like C++
>(e.g., Eiffel doesn't allow specializations). Perhaps EC++ (and
>Java) could have *some* template capabilities without bloating the
>language and runtime library.
But template specialisation is one method of getting rid of code bloat!
...snip..
>It's been pretty well established that locale facet templates add
>code bloat when using iostreams. (Perhaps it's not templates that
>are the problem, but an overly ambitious iostream specification?)
It is certainly not the case that templates cause code bloat.
>There may be other sources of bloat, perhaps when using the STL?
No.
>I wouldn't think that namespaces add any code bloat, though.
Hooray for that at least
>-- David R. Tribble, dtribble@technologist.com --
--
Mike Davies
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: bs@research.att.com (Bjarne Stroustrup)
Date: 1998/07/18 Raw View
David R Tribble <david.tribble@noSPAM.central.beasys.com>
> Andrew Koenig wrote:
> > Surely that is not a justification for dropping templates outright?
>
> Uh, no. But it could be a justification for dropping the iostream
> library. Or at least the ambitious (baggage) parts.
Indeed - as I have mentioned repeatedly - if I was writing a system that
had serious time or memory constraints, and if I didn't need more than
a single locale, and if the iostreams implementation I had available
didn't meet my performance constraints I would certainly either
(1) avoid iostreams
(2) use a "lean/stripped" iostream implementation that conformed
to the standard except for not providing the features
I wasn't using anyway.
This, I consider simply common sense.
What I don't consider common sense is going from the obvious need to
avoid certain library features or language features in specific contexts
to creating a formally defined and supported dialects of C++.
We have an ISO C++ standard:
"Prefer the standard to the offbeat."
- Strunk & White
(for those who don't know, Strunk&White is a widely-accepted small book
of practical rules for writing good English)
> Perhaps a subset of C++ (that maybe did indeed have some form of
> templates, but perhaps not the full-blown templates of C++) that
> did not have iostream capabilities would constitute a reasonable
> EC++? Would EC++ with stdio be good enough for embedded programmers
> (or programmers porting very old C++ code)?
Why consider subsetting templates? That makes no sense. Templates
simplify programming, make important tasks safer, and impose no
overhead compared to hand-written code.
We have an ISO standard and we should stick to it except in very
special circumstances. It is very hard to select a subset of, say,
the standard C++ template facilities that (1) is significantly
smaller than the full set and (2) doesn't eliminate something
important (e.g. the ability to use the standard library).
A C++ dialect without templates or with restricted templates will
force people to either develop their own set of containers (in
competition with the standard one) or to write at an unnecessarily
low level of abstraction (e.g. arrays and/or ad hoc lists).
Very early on in the discussion of EC++, I pointed out that formally
defined dialects and organizations that support and/or promote
them take on a life of their own (both an intellectual life and a
commercial one). This is a fertile ground for confusion,
misunderstanding, strife, and language wars. One good reason to have
a standard and to stick to it is that it minimizes emotion in
language-technical debates by giving a standard base on which to base
arguments. Thus having a standard and sticking to it whereever
possible maximises the time we have to actually build systems.
> -- David R. Tribble, dtribble@technologist.com --
> -- C++, the PL/1 of the 90s.
Many would consider that signature line name calling. I doubt we would
have seen it except for the heat of the C++ vs EC++ debate.
- Bjarne
Bjarne Stroustrup (http://www.research.att.com/~bs)
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: fjh@cs.mu.OZ.AU (Fergus Henderson)
Date: 1998/07/18 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> writes:
>In article <35AF2A6B.DDA4B716@acm.org>, Pete Becker <petebecker@acm.org>
>writes
>>Tell that to the maintenance programmer who works on C++ code written
>>five years ago. In many cases it's much easier to get it to compile with
>>EC++ than with Standard C++.
>
>Unless it uses a template
My experience from about five years ago was that templates were
basically unusable, at least with the implementations that were
available to me at the time.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: loewis@informatik.hu-berlin.de (Martin v. Loewis)
Date: 1998/07/19 Raw View
"P.J. Plauger" <pjp@dinkumware.com> writes:
> Nothing prevented them. In fact, the inventors of EC++ didn't invent
> the identifier __ecplusplus. AFAIK, it was made up along the way
> in this thread, by was of example.
I believe I was using it first in this thread, so let me defend.
http://www.caravan.net/ec2plus/amendment2.html says:
>> 16.8 Predefined macro name
>> The name '__embedded_cplusplus' is defined when compiling a EC++
>> translation unit.
It seems that my memory was tricking me when I wrote my example, and
it is what people expect it to be.
IMHO, that doesn't change the fact that programs relying on it are not
compliant C++ programs, in a strict sense. This is probably not very
important to users of EC++. It is important for the question whether
EC++ should become an international standard, on the merits of being a
proper subset of standard C++ (which it is not).
Sorry,
Martin
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/07/19 Raw View
Nathan Myers wrote:
>
> Pete Becker <petebecker@acm.org> wrote:
> >Nathan Myers wrote:
> >> All that has been established is that certain immature implementations
> >> add code bloat, under various usages.
> >
> >Apparently every implementation that anyone has been able to provide
> >data for in this discussion is immature, and only the ones that nobody
> >talks about can actually handle the standard C++ library adequately.
> >Wouldn't it be nice if those who view this as a solved problem would,
> >just this once, give us a hint as to where these marvelous, mature
> >implementations are hiding?
>
> Is this a troll?
No, it's a request for clarification. That is, when you said "certain
immature implementations" you meant "all current implementations". Thank
you for the clarification.
>
> The standard has not been officially ratified yet. Of course all
> current implementations are immature. Certainly none are fully
> conforming (despite any inflated claims that may appear in advertising)
> even if you allow for workarounds for bugs in the standard. Any
> measurements taken today are necessarily of immature implementations.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/07/19 Raw View
Martin v. Loewis wrote:
>
> IMHO, that doesn't change the fact that programs relying on it are not
> compliant C++ programs, in a strict sense. This is probably not very
> important to users of EC++. It is important for the question whether
> EC++ should become an international standard, on the merits of being a
> proper subset of standard C++ (which it is not).
However, if it were an international standard, adopted by the ISO C++
committee, it would then be a proper subset with one trivial change to
the C++ language definition.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/19 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> wrote in article <W+SlHHACzOs1EwNq@noco.demon.co.uk>...
> I don't see the similarity at all. EC++ has been cut down from C++ for
> the stated reason that C++ gives too large executables for some resource
> constrained systems. The fact that templates do not contribute to code
> bloat *at all* (in any reasonable implementation) is ignored by its
> proponents.
Excuse me, but I don't believe that's true. If you have the patience to wade
back through this entire thread, you should find several occasions where the
issue has been addressed. I will be as brief as possible in recapping.
The folks who developed the EC++ specification had multiple goals in mind,
not just avoiding language features that are likely to cause code bloat.
Some features were omitted simply because they are too new. I know this
annoys the more adventuresome enthusiasts of the new C++ Standard, but
it is also sound engineering practice in many contexts. (James Kanze does
the best job of explaining why.)
Templates do not automatically cause code bloat, but they can contribute.
I saw some increase in code size when I templatized iostreams, complex,
and strings -- not because of the template technology per se but because
of the restructuring needed to deal with arbitrary instead of known types in
certain contexts. And, of course, we all know that injudicious use of
templates -- specializing them for more types than are really needed -- can
cause serious bloat. But that is just one of many problems that occur when
you place a powerful tool in naive hands. Library implementors need not and
should not commit such sins.
As a library vendor, I have no trouble partitioning EC++ into its language and
library components. The constraints imposed on the language are there, at
least in my opinion, primarily to deal with the wide variation that currently
exists in compilers. If you have access to a good compiler (such as the EDG
front end) and no desire for cross-platform portability of embedded code, then
I'm all for your using templates, namespaces, or any other ``weightless'' new
features that were excluded from EC++. Use the EC++ compiler switches as
a kind of lint, if you worry about dialect conformance at all.
But the library is a different matter. Given the ``immaturity'' of current compiler
and linker technology, I personally don't know how to supply a fully conforming
library that is anywhere near as lean as traditional C++ (and C) libraries. Like
it or not, that is the benchmark by which the Standard C++ library is being
judged, particularly in environments where code size is a premium. So my
company supplies an EC++ library, *in addition to* a fully conforming C++
library, as a leaner alternative. We also offer an intermediate version, which we
call the Abridged Library, that adds STL back into the EC++ library. The EC++
library itself makes no use of templates, but cohabits nicely with code that
does. It makes optional use of namespaces and/or exceptions. We offer all
these choices because customers demand them, not because we enjoy
proliferating dialects.
I respect the goals of the EC++ Technical Specification, even though I also
promote the use of templates in C++ programming. I respect the goals of
the C++ Standard, even though I also promote the use of pragmatic dialects.
Neither should be condemned, or embraced, for simplistic reasons.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ark@research.att.com (Andrew Koenig)
Date: 1998/07/19 Raw View
In article <35B1DE32.5970A91A@acm.org>,
Pete Becker <petebecker@acm.org> wrote:
> However, if it were an international standard, adopted by the ISO C++
> committee, it would then be a proper subset with one trivial change to
> the C++ language definition.
As I said before, whether or not a change is trivial is a matter
of opinion, and differences of opinion in this matter can be profound.
Moreover, the balloting for the C++ standard is closed. I don't know
the results of the vote, but if it is affirmative, the C++ language is
closed to changes, trivial or not, for at least five years.
--
--Andrew Koenig
ark@research.att.com
http://www.research.att.com/info/ark
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/07/15 Raw View
In article <35AB7FD7.794B@wizard.net>,
James Kuyper <kuyper@wizard.net> wrote:
> There's a key difference - I can write conforming C++ code that will
> work on any of those C++ implementations (subject to resource
> limitations) without referencing any reserved symbols.
Yes, but you might find yourself unneccesarily restricted.
A common technique is to provide a "system dependant" header file,
with defines that allow your program to use functions such as
strincmp() (Borland 3.x) or _strnicmp() (Microsoft 5.0). These
are non-standard functions that might not exist with any names at
all on some platforms, but if they do they are probably better
optimized for the local platform than you will be able to do.
You could, of course, supply a different "system dependant" header
file for each system. Whoever compiles your program would be
responsible for selecting the correct instance of this header file.
But it's much less burden on her if you supply one header file
with different sections for different compilers. You can detect
that you're on a Microsoft platform, for instance, with
#ifdef __MSC__VER
which is a reserved symbol. Although it's legal for any compiler
to define this symbol for it's own purposes, there's no actual
reason to do so except to deliberately prevent header files from
having portability sections such as this. (Such a compiler
probably wouldn't sell well.)
Also, if you don't use any undefined symbols, you can't tell if
plain chars are signed or not. Thus, if your program relies on
char(127) being less than char(128), you will have to do a great
deal of casting -- cast to unsigned char to do the test, and
cast back to plain char for functions such as strcpy().
> Also, I wouldn't
> be suprised to find an implementation that defines __ecplusplus to
> identify it's own unique extensions to C++.
I would be surprised.
I wouldn't claim that such a compiler was non-standard, because
yes, it certainly is entitled to define any symbols that it wants
to, so long as they start with two underscores. But I sure would
be surprised -- what would be the purpose of such symbol, if it
wasn't declaring conformance to EC++?
Seems an unlikely coincidence.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: anatoli@my-dejanews.com
Date: 1998/07/15 Raw View
In article <6ogstg$f8g$1@nnrp1.dejanews.com>,
AllanW@my-dejanews.com wrote: [snips]
[James Kuyper:]
> > Also, I wouldn't
> > be suprised to find an implementation that defines __ecplusplus to
> > identify it's own unique extensions to C++.
>
> I would be surprised.
>
> I wouldn't claim that such a compiler was non-standard, because
> yes, it certainly is entitled to define any symbols that it wants
> to, so long as they start with two underscores. But I sure would
> be surprised -- what would be the purpose of such symbol, if it
> wasn't declaring conformance to EC++?
>
> Seems an unlikely coincidence.
A couple of English words start with "e", besides "embedded".
One of them is "extended". If someday I'll invent an extension
to C++ and write a compiler (which will undoubtly be also a
full conforming implementation of STD C++:), I'll identify
it with the __ecplusplus preprocessing symbol.
Just for sheer fun of it <g>.
Probably the identifier "__ecplusplus" was a poor choice.
I wonder, what prevented inventors of EC++ from choosing
something more sensible, like __embedded_cplusplus?
--
Regards
Anatoli (anatoli at ptc dot com) opinions aren't
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/15 Raw View
Andrew Koenig <ark@research.att.com> wrote in article <Ew3913.8F0@research.att.com>...
> One reason that I am being prickly about this particular issue is
> that throughout the development of C++, I have been careful to
> say that although C++ is programmer-compatible with C, it is not
> exactly a superset of C. Indeed, Bjarne Stroustrup and I wrote an
> article for C++ Report, detailing the differences, called
>
> ``C++: As close as possible to C -- but no closer''
>
> In that article, we explained that while C++ was trying to avoid
> gratuitous incompatibilities with C, some incompatibilities were
> unavoidable without giving up some essential qualities of C++.
How about:
EC++: As fat as possible -- but no fatter.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/07/15 Raw View
In article <Ew38JE.82n@research.att.com>,
ark@research.att.com (Andrew Koenig) wrote:
> In article <35AA9065.53CB@noSPAM.central.beasys.com>,
> David R Tribble <dtribble@technologist.com> wrote:
>
> > > This program is not in the intersection of standard C++ and EC++,
> > > because it makes use of the identifier __ecplusplus, which is
> > > reserved for the implementation.
>
> > So is '__cplusplus', but it's present on every C++ compiler.
> > Perhaps '__ecplusplus' should be part of the EC++ standard, for
> > just this sort of coding situation you describe. (I can do the
> > same thing using a '-D' compiler option; you didn't place a
> > imitation on the compiler options I am allowed to use.)
>
> That wouldn't solve the problem, because a C++ compiler that is not
> also an EC++ compiler is nevertheless permitted by the C++ standard
> to define __ecplusplus.
It's also allowed to define __STDC__ to imply that it's a standard C
compiler. It's also allowed to define BOTH of __BORLANDC and __MSC_VER
to imply that it's BOTH the Borland C++ compiler and the Microsoft C++
compiler.
Take this argument far enough and it becomes ludicrous. You're
implying that such symbols never have value to anyone, which just isn't
true.
Any C++ compiler is permitted, by the C++ standard, to define
__ecplusplus. But none of them will, unless they also at least
claim to support EC++.
> > > Again, my question is whether it is possible to write a ``hello
> > > world'' program in such a way that every standard-conforming C++
> > > implementation is required to accept it (unless it has ludicrously
> > > small capacity limitations), and will also work in EC++.
>
> > That question is very similar to the question, "How is it possible
> > to write C++ code that will be accepted by both conforming and
> > not-quite-conforming compilers." Specifically, how do you write
> > C++ code that will compile on systems that support the 'std::'
> > namespace as well as on systems that don't? The only realistic
> > answer I can come up with is to use some sort of macro magic,
> > possibly by including a header file that sets those macros in a
> > system-dependent way.
>
> The genesis of my question was the claim that EC++ is a subset of C++.
> In order for that claim to be true, every EC++ must also be a
> C++ program, which does not appear to be the case.
[Snip]
These are good points. But let's recognize that there are (or will be)
EC++ compilers, and C++ compilers, and even some compilers that (try to)
do both depending on compiler settings. Furthermore, there will be some
programs that try to be both EC++ programs and C++ programs. If we
deliberately fight this (by defining __ecplusplus on C++ compilers that
are not also EC++ compilers), all we accomplish is to make writing those
dual-language programs harder than they otherwise would be (and that may
be hard enough without any special effort). And let's be realistic:
defining __ecplusplus on a C++ compiler probably isn't going to happen
by accident.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Valentin Bonnard <bonnardv@pratique.fr>
Date: 1998/07/15 Raw View
AllanW@my-dejanews.com wrote:
> Also, if you don't use any undefined symbols, you can't tell if
> plain chars are signed or not. Thus, if your program relies on
> char(127) being less than char(128), you will have to do a great
> deal of casting -- cast to unsigned char to do the test, and
> cast back to plain char for functions such as strcpy().
Simply wrong. Limits of integral (and fp) types are available
in C and C++.
--
Valentin Bonnard mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ark@research.att.com (Andrew Koenig)
Date: 1998/07/15 Raw View
In article <01bdaf8e$ada60f40$8a1ec2d0@porky>,
P.J. Plauger <pjp@dinkumware.com> wrote:
> How about:
> EC++: As fat as possible -- but no fatter.
How about it? Aside from the possibility that some readers might
interpret the proposed title as intending insult to C++, we might now
have the possibility of a reasoned discussion.
[ mod note: We moderators discussed the article before approving
it, and decided it was a humorous comment about EC++, coming
from one of its proponents. We hope that is what PJP had in mind,
and that readers would take it that way. A little humor in
this thread is needed, in my view. :-) -sdc ]
For example, we might begin by trying to understand what it is
about namespaces and templates that would render EC++ impossibly fat.
--
--Andrew Koenig
ark@research.att.com
http://www.research.att.com/info/ark
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/07/16 Raw View
AllanW@my-dejanews.com wrote:
>
> In article <35AB7FD7.794B@wizard.net>,
> James Kuyper <kuyper@wizard.net> wrote:
> > There's a key difference - I can write conforming C++ code that will
> > work on any of those C++ implementations (subject to resource
> > limitations) without referencing any reserved symbols.
> Yes, but you might find yourself unneccesarily restricted.
>
> A common technique is to provide a "system dependant" header file,
> with defines that allow your program to use functions such as
> strincmp() (Borland 3.x) or _strnicmp() (Microsoft 5.0). These
> are non-standard functions that might not exist with any names at
> all on some platforms, but if they do they are probably better
> optimized for the local platform than you will be able to do.
>
> You could, of course, supply a different "system dependant" header
> file for each system. Whoever compiles your program would be
> responsible for selecting the correct instance of this header file.
> But it's much less burden on her if you supply one header file
> with different sections for different compilers. You can detect
> that you're on a Microsoft platform, for instance, with
> #ifdef __MSC__VER
> which is a reserved symbol. Although it's legal for any compiler
> to define this symbol for it's own purposes, there's no actual
> reason to do so except to deliberately prevent header files from
> having portability sections such as this. (Such a compiler
> probably wouldn't sell well.)
There are other possible reasons for #defining a macro with the same
name and conflicting meaning. Try simple ignorance of the fact that
someone else is already using that macro name. The simpler your method
of choosing names for implementation-specific macros, the greater the
likelihood of collision.
The key point is that if EC++ were a strict subset of C++, every
strictly conforming EC++ program would be a strictly conforming C++
program, and strictly conforming C++ programs can't use symbols in the
reserved namespace. The relationship between EC++ and C++ is more
complicated than simple subsetting.
> Also, if you don't use any undefined symbols, you can't tell if
> plain chars are signed or not. Thus, if your program relies on
Nonsense; just #include <limits.h> and #if based upon the value of
CHAR_MIN. If plain char is signed, CHAR_MIN will be negative; if it is
unsigned then CHAR_MIN will be 0. See section 5.2.4.2.1.
> char(127) being less than char(128), you will have to do a great
> deal of casting -- cast to unsigned char to do the test, and
> cast back to plain char for functions such as strcpy().
>
> > Also, I wouldn't
> > be suprised to find an implementation that defines __ecplusplus to
> > identify it's own unique extensions to C++.
>
> I would be surprised.
>
> I wouldn't claim that such a compiler was non-standard, because
> yes, it certainly is entitled to define any symbols that it wants
> to, so long as they start with two underscores. But I sure would
> be surprised -- what would be the purpose of such symbol, if it
> wasn't declaring conformance to EC++?
How about #defining it for the purpose of indicating the implementation
of "Extensions to C PLUS PLUS"? Obviously, such a name would only have
been chosen by someone who was unaware of the existence of alternate
meanings for __ecplusplus. Well, guess what: a lot of C++
implementations were designed before EC++ was ever proposed. Even the
ones designed after EC++ were proposed were not necessarily designed by
people aware of the details of EC++.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jbuck@best.com (Joe Buck)
Date: 1998/07/16 Raw View
Andrew Koenig <ark@research.att.com> wrote:
> The genesis of my question was the claim that EC++ is a subset of C++.
> In order for that claim to be true, every EC++ must also be a
> C++ program, which does not appear to be the case.
You are correct in a formal sense, but I don't believe that you are
correct in a useful sense. C is not a subset of C++, for the same
reason. However, in terms of concepts implemented, EC++ appears to
be a subset of C++ in the same sense that C is. That is, making the
C/EC++ program into a C++ program involves only very localized adjustments that can be done in an almost mechanical way.
>There is the related question of how it is possible to write useful
>EC++ programs that (a) will compile on most existing C++ implementations,
>or (b) will be guaranteed to compile on every standard C++ compiler.
In practice (and programmers live in a practical world, not the formal
world of language lawyers), in the absence of actual malice on the
part of compiler vendors, __ecplusplus will do the trick.
--
-- Joe Buck
work: jbuck@synopsys.com, otherwise jbuck@welsh-buck.org or jbuck@best.com
http://www.welsh-buck.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Darron Shaffer <darron.shaffer@beasys.com>
Date: 1998/07/16 Raw View
AllanW@my-dejanews.com writes:
> In article <35AB7FD7.794B@wizard.net>,
> James Kuyper <kuyper@wizard.net> wrote:
> > There's a key difference - I can write conforming C++ code that will
> > work on any of those C++ implementations (subject to resource
> > limitations) without referencing any reserved symbols.
> Yes, but you might find yourself unneccesarily restricted.
>
> A common technique is to provide a "system dependant" header file,
> with defines that allow your program to use functions such as
> strincmp() (Borland 3.x) or _strnicmp() (Microsoft 5.0). These
> are non-standard functions that might not exist with any names at
> all on some platforms, but if they do they are probably better
> optimized for the local platform than you will be able to do.
>
> You could, of course, supply a different "system dependant" header
> file for each system. Whoever compiles your program would be
> responsible for selecting the correct instance of this header file.
> But it's much less burden on her if you supply one header file
> with different sections for different compilers.
In my experience, long term maintainence is easier with one "system
dependant" header per platform. It's much easier to handle new
systems, for instance. When porting to HPUX 11.0 you copy the HPUX
10.20 header and make the appropriate changes. Do you know which
symbols are defined differently between 10.20 and 11.0?
> Also, if you don't use any undefined symbols, you can't tell if
> plain chars are signed or not. Thus, if your program relies on
> char(127) being less than char(128), you will have to do a great
> deal of casting -- cast to unsigned char to do the test, and
> cast back to plain char for functions such as strcpy().
>
Not true. Early in our build system we compile a (nearly conforming,
and very portable) program. When this program is run, it writes a new
header file that has things like "#define CHAR_IS_SIGNED 1" in it.
No need to reference system-specific symbols.
> > Also, I wouldn't
> > be suprised to find an implementation that defines __ecplusplus to
> > identify it's own unique extensions to C++.
>
> I would be surprised.
>
I agree, simply because (in the case of this symbol) most C++ compiler
writers should be aware of EC++.
--
__ __ _
_ ) ___ _\ Enterprise Middleware Solutions Darron J. Shaffer
__) __ \ BEA Systems Inc. Sr. Software Engineer
17101 Preston Rd darron.shaffer@beasys.com
LB# 115, Ste 260 Voice: (972) 738-6137
Dallas, TX 75248 Fax: (972) 738-6111
http://www.beasys.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/07/16 Raw View
AllanW@my-dejanews.com wrote:
> Any C++ compiler is permitted, by the C++ standard, to define
> __ecplusplus. But none of them will, unless they also at least
> claim to support EC++.
You're assuming that they had already heard about EC++ when they
designed their implementation of C++, and that they knew enough about it
to realize that __ecplusplus would be a bad thing to give an alternate
definition to, and that they had no reason to define a similar name of
their own. Given that 'e' is a perfectly logical abbreviation for
'extended', I think that it's quite possible that an implementation
already exists that violates all three assumptions. I certainly wouldn't
risk the portability of my code on the assumption that there wasn't.
However, I would guess that the EC++ community is less concerned with
portabilty than I am.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ark@research.att.com (Andrew Koenig)
Date: 1998/07/16 Raw View
In article <6oitp3$f36$1@nnrp1.dejanews.com>, <AllanW@my-dejanews.com> wrote:
> > That wouldn't solve the problem, because a C++ compiler that is not
> > also an EC++ compiler is nevertheless permitted by the C++ standard
> > to define __ecplusplus.
> It's also allowed to define __STDC__ to imply that it's a standard C
> compiler. It's also allowed to define BOTH of __BORLANDC and __MSC_VER
> to imply that it's BOTH the Borland C++ compiler and the Microsoft C++
> compiler.
> Take this argument far enough and it becomes ludicrous.
> implying that such symbols never have value to anyone, which just isn't
> true.
Fair enough -- so let me bring forward the point that is lurking behind
this particular legalistic argument:
If the only way to write the ``Hello, world'' program so that it will work
both in C++ and EC++ is to use the preprocessor to test which compiler
you're using, then the languages are pretty far apart.
--
--Andrew Koenig
ark@research.att.com
http://www.research.att.com/info/ark
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/07/16 Raw View
Andrew Koenig wrote:
>
> In article <01bdaf8e$ada60f40$8a1ec2d0@porky>,
> P.J. Plauger <pjp@dinkumware.com> wrote:
>
> > How about:
>
> > EC++: As fat as possible -- but no fatter.
>
> How about it? Aside from the possibility that some readers might
> interpret the proposed title as intending insult to C++, we might now
> have the possibility of a reasoned discussion.
>
> [ mod note: We moderators discussed the article before approving
> it, and decided it was a humorous comment about EC++, coming
> from one of its proponents. We hope that is what PJP had in mind,
> and that readers would take it that way. A little humor in
> this thread is needed, in my view. :-) -sdc ]
>
> For example, we might begin by trying to understand what it is
> about namespaces and templates that would render EC++ impossibly fat.
There's a problem with wording the question that way. It implies that
one side of debate is wrong - the one that claims that EC++ would not be
rendered impossibly fat by those additions. I'm not taking sides on the
issue. I'm just pointing out that such a question is not likely to
improve the level the discussion has dropped to.
Has any active participant changed their minds on any relevant issue in
the last week, or even in the last month? Has anyone even changed the
nature of their arguments significantly? Is there any point in
continuing this discussion? Is there a newsgroup specifically for EC++
that this discussion could be moved to? Quite frankly, I'm tired of it.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/07/16 Raw View
In article <01bdaf8e$ada60f40$8a1ec2d0@porky>,
"P.J. Plauger" <pjp@dinkumware.com> wrote:
> Andrew Koenig <ark@research.att.com> wrote in article
<Ew3913.8F0@research.att.com>...
> > One reason that I am being prickly about this particular issue is
> > that throughout the development of C++, I have been careful to
> > say that although C++ is programmer-compatible with C, it is not
> > exactly a superset of C. Indeed, Bjarne Stroustrup and I wrote an
> > article for C++ Report, detailing the differences, called
> >
> > ``C++: As close as possible to C -- but no closer''
> >
> > In that article, we explained that while C++ was trying to avoid
> > gratuitous incompatibilities with C, some incompatibilities were
> > unavoidable without giving up some essential qualities of C++.
>
> How about:
>
> EC++: As fat as possible -- but no fatter.
And taking that a step further, would you state:
EC++ is trying to avoid gratuitous compatibilities with C++, but
some compatibilities are unavoidable without giving up the
essential qualities of EC++???
[evil grin 8-]
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/07/16 Raw View
Andrew Koenig wrote:
>
> Fair enough -- so let me bring forward the point that is lurking behind
> this particular legalistic argument:
>
> If the only way to write the ``Hello, world'' program so that it will work
> both in C++ and EC++ is to use the preprocessor to test which compiler
> you're using, then the languages are pretty far apart.
In a theoretical sense, perhaps. In a practical sense there is much less
conditionalization needed to write a program that satisfies the EC++
specification and that also compiles as full C++ than is contained in
many C++ programs that are widely used and maintained today. Of course,
standardizing EC++ would eliminate this trivial obstacle.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/07/16 Raw View
In article <35ACF58E.1D1C@pratique.fr>,
bonnardv@pratique.fr wrote:
> AllanW@my-dejanews.com wrote:
>
> > Also, if you don't use any undefined symbols, you can't tell if
> > plain chars are signed or not. Thus, if your program relies on
> > char(127) being less than char(128), you will have to do a great
> > deal of casting -- cast to unsigned char to do the test, and
> > cast back to plain char for functions such as strcpy().
>
> Simply wrong. Limits of integral (and fp) types are available
> in C and C++.
Yes, you're right. I wasn't thinking when I wrote that paragraph.
But my point was that most non-trivial programs make use of at least
one non-portable feature of the current compiler/environment. This
does not stop a program from being portable if it makes use of
conditional compilation, so that it can use suitable non-portable
features in various environments. This type of conditional
compilation is best accomplished by use of vendor-supplied
implementation-defined precompiler symbols, which by their very
nature cannot be legislated into the C++ standard. To suggest that
one should never use these symbols is ludicrous.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <david.tribble@noSPAM.central.beasys.com>
Date: 1998/07/17 Raw View
Andrew Koenig <ark@research.att.com> wrote:
>> ... Indeed, Bjarne Stroustrup and I wrote an
>> article for C++ Report, detailing the differences, called
>> ``C++: As close as possible to C -- but no closer''
P.J. Plauger wrote:
> How about:
> EC++: As fat as possible -- but no fatter.
That is exactly it in a nutshell. ;-)
This is off-topic, but the question about whether or not
templates belong in EC++ is similar to the question of whether
or not Java would be a more useful (but still manageable) language
with something like templates. Many programmers feel that Java
doesn't quite have the power or expressiveness of C++ because it's
missing templates; on the other hand, others argue that C++ is too
unwieldly because it has templates.
Perhaps we should contemplate languages that have "lightweight"
or "in-between" templates, such as Eiffel, which provide the
basics of template programming without going to extremes like C++
(e.g., Eiffel doesn't allow specializations). Perhaps EC++ (and
Java) could have *some* template capabilities without bloating the
language and runtime library. Then our discussions about whether
EC++ constitutes a (proper) subset of C++ might be more fruitful.
ark@research.att.com (Andrew Koenig) wrote:
>> ... we might begin by trying to understand what it is
>> about namespaces and templates that would render EC++ impossibly
>> fat.
It's been pretty well established that locale facet templates add
code bloat when using iostreams. (Perhaps it's not templates that
are the problem, but an overly ambitious iostream specification?)
There may be other sources of bloat, perhaps when using the STL?
I wouldn't think that namespaces add any code bloat, though.
-- David R. Tribble, dtribble@technologist.com --
-- C++, the PL/1 of the 90s.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: saroj@bear.com
Date: 1998/07/17 Raw View
In article <35AE1771.41C6@wizard.net>,
James Kuyper <kuyper@wizard.net> wrote:
> Andrew Koenig wrote:
> >
> > In article <01bdaf8e$ada60f40$8a1ec2d0@porky>,
> > P.J. Plauger <pjp@dinkumware.com> wrote:
> >
> > > How about:
> >
> > > EC++: As fat as possible -- but no fatter.
> >
> > How about it? Aside from the possibility that some readers might
> > interpret the proposed title as intending insult to C++, we might now
> > have the possibility of a reasoned discussion.
> >
> > [ mod note: We moderators discussed the article before approving
> > it, and decided it was a humorous comment about EC++, coming
> > from one of its proponents. We hope that is what PJP had in mind,
> > and that readers would take it that way. A little humor in
> > this thread is needed, in my view. :-) -sdc ]
> >
> > For example, we might begin by trying to understand what it is
> > about namespaces and templates that would render EC++ impossibly fat.
>
> There's a problem with wording the question that way. It implies that
> one side of debate is wrong - the one that claims that EC++ would not be
> rendered impossibly fat by those additions. I'm not taking sides on the
> issue. I'm just pointing out that such a question is not likely to
> improve the level the discussion has dropped to.
>
> Has any active participant changed their minds on any relevant issue in
> the last week, or even in the last month? Has anyone even changed the
> nature of their arguments significantly? Is there any point in
> continuing this discussion? Is there a newsgroup specifically for EC++
> that this discussion could be moved to? Quite frankly, I'm tired of it.
Me too. I think EC++ proponents will go ahead and implement it anyway
with no changes. So I do not understand why they are wasting everybody's
time here. We should discuss C++ here and not EC++.
Cheers,
Saroj Mahapatra
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: saroj@bear.com
Date: 1998/07/17 Raw View
In article <Ew6x1y.DxI@research.att.com>,
ark@research.att.com (Andrew Koenig) wrote:
> In article <6oj6ne$f8l$1@shell17.ba.best.com>, Joe Buck <jbuck@best.com>
wrote:
> > Andrew Koenig <ark@research.att.com> wrote:
>
> > > The genesis of my question was the claim that EC++ is a subset of C++.
> > > In order for that claim to be true, every EC++ must also be a
> > > C++ program, which does not appear to be the case.
>
> > You are correct in a formal sense, but I don't believe that you are
> > correct in a useful sense. C is not a subset of C++, for the same
> > reason. However, in terms of concepts implemented, EC++ appears to
> > be a subset of C++ in the same sense that C is. That is, making the
> > C/EC++ program into a C++ program involves only very localized adjustments
that can be done in an almost mechanical way.
>
> I disagree. For example, I can write
>
> #include <stdio.h>
>
> int main()
> {
> printf("Hello, world!\n");
> return 0;
> }
>
> and I have a strictly conforming C program that is also guaranteed to
> work on every conforming C++ implementation. This is a useful program
> that is in the intersection of C and C++, and there are many such programs.
>
> But so far, no one has shown me how to write a corresponding program in
> the intersection of C++ and EC++ that uses the C++ I/O library. I can
> write such a program that uses the C library, of course -- I just did --
> but every solution to the problem that I have seen that uses the C++
> library either includes a test to see whether it's being compiled on
> an EC++ compiler or relies on a vendor extension to C++.
>
> I believe that if I want to write standard C++ programs that are also
> EC++ programs, I have to restrict myself to the C library. That's a
> pretty severe restriction.
Without templates, exceptions
and STL, EC++ is basically a superset of C (rather
than subset of C++). As I said before, most modern C++ programs are
written using templates and exceptions.
Cheers,
Saroj Mahapatra
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/07/17 Raw View
Andrew Koenig wrote:
>
> In article <35AE3D9F.CF34DC31@acm.org>,
> Pete Becker <petebecker@acm.org> wrote:
>
> > In a theoretical sense, perhaps. In a practical sense there is much less
> > conditionalization needed to write a program that satisfies the EC++
> > specification and that also compiles as full C++ than is contained in
> > many C++ programs that are widely used and maintained today. Of course,
> > standardizing EC++ would eliminate this trivial obstacle.
>
> The question of whether the obstacle is trivial is the basis
> for a profound difference of opinion.
>
> For example, in order to write a program that satisfies the EC++
> specification and also compiles as full C++, one must either abandon
> the C++ I/O library or take advantage of vendor extensions that are not
> part of the C++ standard. I consider neither of these alternatives trivial.
Tell that to the maintenance programmer who works on C++ code written
five years ago. In many cases it's much easier to get it to compile with
EC++ than with Standard C++.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ark@research.att.com (Andrew Koenig)
Date: 1998/07/17 Raw View
In article <6ong1a$hfh$1@nnrp1.dejanews.com>, <saroj@bear.com> wrote:
> Me too. I think EC++ proponents will go ahead and implement it anyway
> with no changes. So I do not understand why they are wasting everybody's
> time here. We should discuss C++ here and not EC++.
I think it is entirely legitimate to discuss what strategies, tools,
etc., are useful for writing C++ programs that are intended to run
in embedded environments. I also think that for such discussions to
be useful, it is important to be clear about the nature of the problems,
and of the solutions.
--
--Andrew Koenig
ark@research.att.com
http://www.research.att.com/info/ark
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ark@research.att.com (Andrew Koenig)
Date: 1998/07/17 Raw View
In article <35AEA751.3C93@noSPAM.central.beasys.com>,
David R Tribble <dtribble@technologist.com> wrote:
> ark@research.att.com (Andrew Koenig) wrote:
> >> ... we might begin by trying to understand what it is
> >> about namespaces and templates that would render EC++ impossibly
> >> fat.
> It's been pretty well established that locale facet templates add
> code bloat when using iostreams. (Perhaps it's not templates that
> are the problem, but an overly ambitious iostream specification?)
Surely that is not a justification for dropping templates outright?
--
--Andrew Koenig
ark@research.att.com
http://www.research.att.com/info/ark
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ark@research.att.com (Andrew Koenig)
Date: 1998/07/17 Raw View
In article <35AF2A6B.DDA4B716@acm.org>,
Pete Becker <petebecker@acm.org> wrote:
> > For example, in order to write a program that satisfies the EC++
> > specification and also compiles as full C++, one must either abandon
> > the C++ I/O library or take advantage of vendor extensions that are not
> > part of the C++ standard. I consider neither of these alternatives trivial.
> Tell that to the maintenance programmer who works on C++ code written
> five years ago. In many cases it's much easier to get it to compile with
> EC++ than with Standard C++.
It is hard to understand how this statement could be true if EC++
is a subset of Standard C++, because then any program that would
compile under EC++ would also compile under Standard C++.
--
--Andrew Koenig
ark@research.att.com
http://www.research.att.com/info/ark
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: herbs@cntc.com (Herb Sutter)
Date: 1998/07/17 Raw View
saroj@bear.com wrote:
>Me too. I think EC++ proponents will go ahead and implement it anyway
>with no changes. So I do not understand why they are wasting everybody's
>time here. We should discuss C++ here and not EC++.
This is comp.std.c++, and the C++ standards committee has been asked to
take up the question of real/perceived size and performance issues. The
committee has responded with a positive and willing spirit, and is in the
process of putting together a proposal for a new working group to tackle
such questions. Whether or not the final result ends up having anything to
do with EC++, it was the EC++ people who initiated the "asking," and I for
one am happy that they were kind enough to not just present real/perceived
problems but also to propose specific solutions. I wish all comments were
of that form.
So, although I understand your sentiment, IMO this is on-topic. (Besides,
there may be less else to talk about for the next five years than there
was for the previous eight. :-) )
Herb
---
Herb Sutter (mailto:herbs@cntc.com)
Current Network Technologies Corp 2695 North Sheridan Way, Suite 150
www.cntc.com www.peerdirect.com Mississauga Ontario Canada L5K 2N6
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/18 Raw View
anatoli@my-dejanews.com wrote in article <6ohs3l$s8v$1@nnrp1.dejanews.com>...
> Probably the identifier "__ecplusplus" was a poor choice.
> I wonder, what prevented inventors of EC++ from choosing
> something more sensible, like __embedded_cplusplus?
Nothing prevented them. In fact, the inventors of EC++ didn't invent
the identifier __ecplusplus. AFAIK, it was made up along the way
in this thread, by was of example.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/18 Raw View
Andrew Koenig <ark@research.att.com> wrote in article <Ew7F4t.B4@research.att.com>...
> For example, in order to write a program that satisfies the EC++
> specification and also compiles as full C++, one must either abandon
> the C++ I/O library or take advantage of vendor extensions that are not
> part of the C++ standard. I consider neither of these alternatives trivial.
Uh, are we talking about the same library? The vast majority of more-or-less
real C++ programs I've seen that use iostreams would compile as EC++
*unchanged*. No need to abandon anything here. True, they write to an
object of class ostream (cout) instead of an object of template class
basic_ostream< char, char_traits<char> > typedefed as ostream. I suppose
you could say they thus take advantage of vendor extensions that are not
part of the C++ Standard. It's a trivial distinction to me, but them I'm a
flaming pragmatist.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/07/18 Raw View
AllanW@my-dejanews.com wrote:
...
> But my point was that most non-trivial programs make use of at least
> one non-portable feature of the current compiler/environment. This
> does not stop a program from being portable if it makes use of
> conditional compilation, so that it can use suitable non-portable
If your code uses such symbols to conditionally compile one of two
different implementation-specific pieces of code, there is always the
possibility that a third choice will need to be added when porting to a
new environment. That makes it non-portable.
Portable code is an ideal to be approached, not a practical goal to be
achieved. The way to approach portability is to avoid such code wherever
possible, and to isolate such code in as few modules as possible.
> features in various environments. This type of conditional
> compilation is best accomplished by use of vendor-supplied
> implementation-defined precompiler symbols, which by their very
> nature cannot be legislated into the C++ standard. To suggest that
> one should never use these symbols is ludicrous.
No one suggested that. What they did say was that the need to test for
such symbols proves that EC++ is not a strict subset of C++. There is a
strong relationship, it's just more complex than simple subsetting.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/18 Raw View
James Kuyper <kuyper@wizard.net> wrote in article <35AE1771.41C6@wizard.net>...
> Has any active participant changed their minds on any relevant issue in
> the last week, or even in the last month? Has anyone even changed the
> nature of their arguments significantly? Is there any point in
> continuing this discussion? Is there a newsgroup specifically for EC++
> that this discussion could be moved to? Quite frankly, I'm tired of it.
Your comments are well taken. Obviously, a handful of outspoken people on
both sides of this debate have stuck to their positions rather tenaciously. As
one of the tenacious pro-EC++ types, I have to respect the tenacity of the
antis. But it is not a mark of failure if this debate has won no converts from the
hard core on either side.
I waded into this discussion initially to dispel the considerable misinformation
being passed around about EC++. In saying this, I do not mean to suggest
that any of the misinformation was intentional. As we have seen, there are
any number of subtle issues surrounding the ``problems with locale and its
facets,'' as well as several related technical issues. There are equally subtle
issues surrounding the degree to which EC++ can or might be recognized as
a ``standard'', be it an ISO Technical Report, a de facto industry standard, or
a popular collection of compilation options. For my part, the discussions
have been a rip roaring success, if only because many more people have
been exposed to the technical and political considerations that motivated the
Embedded C++ Technical Committee to take the path it chose.
Along the way, I developed another motivation. As a vendor of libraries -- both
EC++ and fully standard-conforming C++ (not to mention C, C9X, Java, etc.) --
my company is determined to produce the best products possible, and to
keep improving them. Pete Becker and I have repeatedly asked for guidance,
in this forum, for ways to solve optimization problems that we have found to
be largely intractable. The open discussion of linker techniques has been very
helpful, even if it shows that some of the most promising mechanisms are not
yet widely available. It also educates many programmers -- our potential
customers in the end -- as to what is reasonable with today's technology and
what we all can hope for in the future.
I thank all the people who contributed to this discussion so far. I've learned a
lot, even as I've tried to educate others. I sympathize with Mr. Kuyper's
weariness, however, and would be content to see this discussion wind down.
And I'm sorry I ever used the word ``subset.''
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/07/18 Raw View
David R Tribble <dtribble@technologist.com> wrote:
>
>It's been pretty well established that locale facet templates add
>code bloat when using iostreams.
Is this a troll? It has not been "established", or even "pretty well
established".
All that has been established is that certain immature implementations
add code bloat, under various usages. Repeating hearsay as fact does
not improve the quality of the discussion.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/07/18 Raw View
Andrew Koenig wrote:
>
>
> It is hard to understand how this statement could be true if EC++
> is a subset of Standard C++, because then any program that would
> compile under EC++ would also compile under Standard C++.
No, the point is that EC++ is a historical subset. <g>
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/18 Raw View
>Me too. I think EC++ proponents will go ahead and implement it anyway
>with no changes. So I do not understand why they are wasting everybody's
>time here. We should discuss C++ here and not EC++.
That's a a bit pessimistic. Arguing your point of view *can* change
peoples opinion
>Cheers,
>Saroj Mahapatra
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <david.tribble@noSPAM.central.beasys.com>
Date: 1998/07/13 Raw View
Andrew Koenig wrote:
>>> So how do you write this program in the intersection of standard
>>> C++ and EC++?
David R Tribble <dtribble@technologist.com> wrote:
>> How about:
>> #include <iostream>
>>
>> #ifdef __ecplusplus
>> #define std
>> #endif
>>
>> int main()
>> {
>> std::cout << "Hello, world"\n";
>> return 0;
>> }
Andrew Koenig wrote:
> This program is not in the intersection of standard C++ and EC++,
> because it makes use of the identifier __ecplusplus, which is
> reserved for the implementation.
So is '__cplusplus', but it's present on every C++ compiler.
Perhaps '__ecplusplus' should be part of the EC++ standard, for
just this sort of coding situation you describe. (I can do the
same thing using a '-D' compiler option; you didn't place a
imitation on the compiler options I am allowed to use.)
> Again, my question is whether it is possible to write a ``hello
> world'' program in such a way that every standard-conforming C++
> implementation is required to accept it (unless it has ludicrously
> small capacity limitations), and will also work in EC++.
That question is very similar to the question, "How is it possible
to write C++ code that will be accepted by both conforming and
not-quite-conforming compilers." Specifically, how do you write
C++ code that will compile on systems that support the 'std::'
namespace as well as on systems that don't? The only realistic
answer I can come up with is to use some sort of macro magic,
possibly by including a header file that sets those macros in a
system-dependent way.
They are both tricky, but important, questions to answer.
-- David R. Tribble, dtribble@technologist.com --
-- C++, the PL/1 of the 90s.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/07/14 Raw View
> > > So how do you write this program in the intersection of standard C++
> > > and EC++?
> In article <35A29634.17A5@noSPAM.central.beasys.com>,
> David R Tribble <dtribble@technologist.com> wrote:
> > How about:
> > #include <iostream>
> >
> > #ifdef __ecplusplus
> > #define std
> > #endif
> >
> > int main()
> > {
> > std::cout << "Hello, world"\n";
> > return 0;
> > }
In article <EvvtII.BwL@research.att.com>,
ark@research.att.com (Andrew Koenig) wrote:
> This program is not in the intersection of standard C++ and EC++,
> because it makes use of the identifier __ecplusplus, which is
> reserved for the implementation.
Well, that's not really fair, is it?
I would buy this argument as a good reason not to include
#define __ecplusplus
in my own program. After all, even if that symbol wasn't currently
used by my implementation, it could be used in the future.
But compiler vendors routinely define __something symbols which,
among other things, help to identify the current compile environment.
Microsoft has one to show that it's Microsoft, and others for the
memory models. Same for Borland, and probably all the others.
Compilers may have settings to turn this off, just as they may have
settings to explicitly define others. But show me a compiler that
doesn't define ANY of these symbols unless it's told to explicitly?
That would be madness. Program authors that try to target a large
number of platforms would either have to give special instructions
("be sure to use /Define:BrandName") or just ignore that compiler
altogether.
The __ecplusplus identifier falls into this category. In fact,
despite the fact that it isn't in the spec, I would have certain
expectations for any compiler that defines it, and so would you.
Just as the Microsoft symbols allow me to use the Microsoft extended
library or work around it's shortcomings, the _ecplusplus identifier
allows me to use the EC++ features or work around it's shortcomings.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ark@research.att.com (Andrew Koenig)
Date: 1998/07/14 Raw View
In article <6oe921$jvg$1@nnrp1.dejanews.com>, <AllanW@my-dejanews.com> wrote:
> In article <EvvtII.BwL@research.att.com>,
> ark@research.att.com (Andrew Koenig) wrote:
> > This program is not in the intersection of standard C++ and EC++,
> > because it makes use of the identifier __ecplusplus, which is
> > reserved for the implementation.
> Well, that's not really fair, is it?
Yes, it is fair, because it is relevant to the claim that EC++ is a subset
of standard C++. If the original claim had been that EC++ is similar
enough to a subset of most implementations of standard C++ that it is
possible to write useful programs that will work in both environments,
I would not have quibbled -- but the claim has been made on several
occasions that ``EC++ is a subset of standard C++'' without further
qualification. It is that specific claim that I wish to refute.
One reason that I am being prickly about this particular issue is
that throughout the development of C++, I have been careful to
say that although C++ is programmer-compatible with C, it is not
exactly a superset of C. Indeed, Bjarne Stroustrup and I wrote an
article for C++ Report, detailing the differences, called
``C++: As close as possible to C -- but no closer''
In that article, we explained that while C++ was trying to avoid
gratuitous incompatibilities with C, some incompatibilities were
unavoidable without giving up some essential qualities of C++.
Similarly, I believe that the proponents of EC++ should not be claiming
that EC++ is a subset of C++ unless that claim is literally true.
Rather, they should say what incompatibilities there are, and
why those incompatibilities are necessary to the purpose of EC++.
Then it might be possible to have a useful discussion of design issues.
--
--Andrew Koenig
ark@research.att.com
http://www.research.att.com/info/ark
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/07/14 Raw View
AllanW@my-dejanews.com wrote:
>
> > > > So how do you write this program in the intersection of standard C++
> > > > and EC++?
>
> > In article <35A29634.17A5@noSPAM.central.beasys.com>,
> > David R Tribble <dtribble@technologist.com> wrote:
> > > How about:
> > > #include <iostream>
> > >
> > > #ifdef __ecplusplus
> > > #define std
> > > #endif
> > >
> > > int main()
> > > {
> > > std::cout << "Hello, world"\n";
> > > return 0;
> > > }
>
> In article <EvvtII.BwL@research.att.com>,
> ark@research.att.com (Andrew Koenig) wrote:
> > This program is not in the intersection of standard C++ and EC++,
> > because it makes use of the identifier __ecplusplus, which is
> > reserved for the implementation.
>
> Well, that's not really fair, is it?
>
> I would buy this argument as a good reason not to include
> #define __ecplusplus
> in my own program. After all, even if that symbol wasn't currently
> used by my implementation, it could be used in the future.
>
> But compiler vendors routinely define __something symbols which,
> among other things, help to identify the current compile environment.
> Microsoft has one to show that it's Microsoft, and others for the
> memory models. Same for Borland, and probably all the others.
> Compilers may have settings to turn this off, just as they may have
> settings to explicitly define others. But show me a compiler that
> doesn't define ANY of these symbols unless it's told to explicitly?
> That would be madness. Program authors that try to target a large
> number of platforms would either have to give special instructions
> ("be sure to use /Define:BrandName") or just ignore that compiler
> altogether.
>
> The __ecplusplus identifier falls into this category. In fact,
> despite the fact that it isn't in the spec, I would have certain
> expectations for any compiler that defines it, and so would you.
> Just as the Microsoft symbols allow me to use the Microsoft extended
> library or work around it's shortcomings, the _ecplusplus identifier
> allows me to use the EC++ features or work around it's shortcomings.
There's a key difference - I can write conforming C++ code that will
work on any of those C++ implementations (subject to resource
limitations) without referencing any reserved symbols. Also, I wouldn't
be suprised to find an implementation that defines __ecplusplus to
identify it's own unique extensions to C++.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/08 Raw View
In article <01bda6a1$314b3600$8a1ec2d0@porky>, "P.J. Plauger"
<pjp@dinkumware.com> writes
...snip...
>> What is the part of the iceberg that I missed? Let us set aside the
>> iostream argument for a moment.
>
>Uh, you just set the iceberg aside.
I suppose I'm risking fate by saying this, but iostreams are probably
not a big issue for embedded SW projects, especially the small data
space ones which are typically very control, not IO oriented
...snip...
>P.J. Plauger
Regards,
--
Mike Davies
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <david.tribble@noSPAM.central.beasys.com>
Date: 1998/07/08 Raw View
Andrew Koenig wrote:
> Now let's return to your example:
> #include <iostream>
>
> int main()
> {
> cout << "Hello, world!\n";
> return 0;
> }
>
> Legal though this example may be in EC++, it is *not* legal in
> standard C++ because the header <iostream> puts its names in namespace
> std. ...
> Suppose, though, that you wanted to write this trivial program in a
> way that was well formed in both standard C++ and EC++. How would you
> do that? None of the techniques I've suggested so far would work, ...
> So how do you write this program in the intersection of standard C++
> and EC++?
How about:
#include <iostream>
#ifdef __ecplusplus
#define std
#endif
int main()
{
std::cout << "Hello, world"\n";
return 0;
}
As much as it is despised by some, sometimes a little preprocessor
magic is just the thing. (Just ask Plauger.)
> Summary: You've convinced me that the lack of templates might well be
> capable of being implemented as a true subset. On the other hand,
> you've also convinced me that the lack of namespaces is a much more
> profound incompatibility than I had realized previously.
Yes, and the slow move to full support for namespaces will be a
pain in the wrists over the next 12-24 months. But, we are
constantly reminded, the end results will be well worth it, right?
-- David R. Tribble, dtribble@technologist.com --
-- I program in GCD-C++, a subset of C++.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/08 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> wrote in article <dpvmOLAgK7o1Ewcx@noco.demon.co.uk>...
> I suppose I'm risking fate by saying this, but iostreams are probably
> not a big issue for embedded SW projects, especially the small data
> space ones which are typically very control, not IO oriented
Mostly, you're right. But practically every attempt I've seen at delivering
an embedded C library without I/O has been criticized by customers for
omitting sprintf. Even if the code just scribbles on a plasma panel, or
ships the occasional status message through a UART, it's sure nice not
to have to reinvent formatted output. Similarly, attempts at omitting iostreams
from small C++ libraries often elicit howls if strstream (and now sstream)
go out with the bathwater. So the set of programs that do ``I/O'' is probably
larger than you think.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Valentin Bonnard <bonnardv@pratique.fr>
Date: 1998/07/03 Raw View
David R Tribble wrote:
>
> P.J. Plauger <pjp@dinkumware.com> wrote:
> >> My company, Dinkumware, Ltd., promptly wrote the library subset
> >> required by that spec, and several compiler vendors provided compiler
> >> switches for testing conformance with the language subset promoted by
> >> that spec.
>
> Andrew Koenig wrote:
> > In the interest of accuracy, I would like to point out that the EC++
> > library is not a subset of the C++ library.
>
> That implies that the EC++ library contains something that the C++
> library doesn't. What would that be? How is it not a subset?
The only such things that _I_ know of are float_complex,
double_complex, longdouble_complex.
--
Valentin Bonnard mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/04 Raw View
Valentin Bonnard <bonnardv@pratique.fr> wrote in article <359D10B4.2F1CF0FB@pratique.fr>...
> David R Tribble wrote:
> >
> > P.J. Plauger <pjp@dinkumware.com> wrote:
> > >> My company, Dinkumware, Ltd., promptly wrote the library subset
> > >> required by that spec, and several compiler vendors provided compiler
> > >> switches for testing conformance with the language subset promoted by
> > >> that spec.
> >
> > Andrew Koenig wrote:
> > > In the interest of accuracy, I would like to point out that the EC++
> > > library is not a subset of the C++ library.
> >
> > That implies that the EC++ library contains something that the C++
> > library doesn't. What would that be? How is it not a subset?
>
> The only such things that _I_ know of are float_complex,
> double_complex, longdouble_complex.
And there isn't even a longdouble_complex. I think (though I can't speak for
Andy) that he keeps saying this because EC++ doesn't support namespaces.
So strictly speaking, EC++ is not a proper subset of full C++. (Nor is any C++
implementation on the market today, but what the heck.) OTOH, you can
make an arbitrary EC++ program compile as full C++ by including the
following code at the beginning of every translation unit, either directly or
via an include file:
#ifdef _NOT_ECPP_
namespace std {}
using namespace std;
#define float_complex complex<float>
#define double_complex complex<double>
#endif
Just define the macro _NOT_ECPP_ when you compile and it adapts.
If you think this patch disqualifies EC++ as a subset of full C++, then
you're far more finicky than I am.
Of course I'd hate to advocate the use of macros and #ifdefs to deal with
dialect differences among C++ implementations, but I hear there's precedent
for it...
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Daniel Parker" <danielp@nospam.com>
Date: 1998/07/05 Raw View
Andrew Koenig wrote in message ...
>I think I get it. You're saying that although the EC++ library is
>implemented in a way that differs from the C++ standard, users can't
>tell because EC++ doesn't have any of the language facilities that
>would be necessary to be able to tell.
>
>Summary: You've convinced me that the lack of templates might well be
>capable of being implemented as a true subset. On the other hand,
>you've also convinced me that the lack of namespaces is a much more
profound
>incompatibility than I had realized previously.
Wouldn't it be highly desirable to put standard like classes that are
implemented differently from the standard in their own namespace, and do
something with the header file names as well, possibly putting them under a
subdirectory? How else could an implementation of EC++ move closer to the
standard in the future without breaking everything?
--
Regards,
Daniel Parker danielp@no_spam.anabasis.com.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ark@research.att.com (Andrew Koenig)
Date: 1998/07/05 Raw View
In article <6nohos$i02$1@news.interlog.com>,
Daniel Parker <danielp@nospam.com> wrote:
> Wouldn't it be highly desirable to put standard like classes that are
> implemented differently from the standard in their own namespace, and do
> something with the header file names as well, possibly putting them under a
> subdirectory? How else could an implementation of EC++ move closer to the
> standard in the future without breaking everything?
This is hard to do if you're working in a language that doesn't support namespaces.
--
--Andrew Koenig
ark@research.att.com
http://www.research.att.com/info/ark
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Daniel Parker" <danielp@nospam.com>
Date: 1998/07/06 Raw View
Andrew Koenig wrote in message ...
>In article <6nohos$i02$1@news.interlog.com>,
>Daniel Parker <danielp@nospam.com> wrote:
>
>> Wouldn't it be highly desirable to put standard like classes that are
>> implemented differently from the standard in their own namespace, and do
>> something with the header file names as well,
>
>This is hard to do if you're working in a language that doesn't support
namespaces.
Yeah, I guess, let me try again. Wouldn't it be possible for everyone to
agree that it would be an excellent thing that a reduced version of C++
intended for embedded systems development at a minimum support namespaces,
and that any classes that departed in any way from the standard go into that
namespace? I think that if the advocates for a reduced version of C++ were
to lend there support to that position, they would find less people who were
dead against and more people who didn't care.
--
Regards,
Daniel Parker danielp@no_spam.anabasis.com.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "David J. Littleboy" <davidjl@gol.com>
Date: 1998/07/06 Raw View
Andrew Koenig wrote in message ...
>Now let's return to your example:
[snip]
>Legal though this example may be in EC++, it is *not* legal in standard C++
>because the header <iostream> puts its names in namespace std. So, to be
>legal in standard C++, you must write
>
[snip]
> std::cout << "Hello, world"\n";
[snip]
>Alternatively, you could insert
>
> using std::cout;
>
>or
>
> using namespace std;
>
>in an appropriate place.
>
>Suppose, though, that you wanted to write this trivial program in a way
>that was well formed in both standard C++ and EC++. How would you do that?
>None of the techniques I've suggested so far would work, because they rely
>on namespaces. And although changing <iostream> to <iostream.h> would be
>likely to work on most standard C++ implementations, the standard itself
>does not offer <iostream.h>, which means that any program that uses it
>is relying on an extension. So how do you write this program in the
intersection
>of standard C++ and EC++?
Two ways come to mind: EC++ could define "using namespace std;" to be a nop
that is required after all (relevant) headers have been loaded, or could
similarly require the use of an #ifndef __EC++__ using namespace std; #endif
(Or whatever the correct sytax is.) The former is far preferable, since it
avoids the preprocessor and doesn't imply a restriction on the use of that
symbol by every C++ implementation ever.
David J. Littleboy <davidjl@gol.nonspam.com>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/06 Raw View
Andrew Koenig <ark@research.att.com> wrote in article <EvMJsv.H53@research.att.com>...
> I think I get it. You're saying that although the EC++ library is
> implemented in a way that differs from the C++ standard, users can't
> tell because EC++ doesn't have any of the language facilities that
> would be necessary to be able to tell. So, for example, although standard
> C++ says that the type `string' is a synonym for the type `basic_string<char>',
> and EC++ cannot provide that equivalence because it has no templates,
> there's no way for a user to use the type `basic_string<char>' directly
> anyway, so users can't tell.
Nicely put.
> I will have to think about whether I can come up with a user-detectable
> example that behaves differently with and without templates.
That might be of academic interest, but the fact that you have to think about it
speaks worlds. It tells me that people can write to the EC++ subset with a
high probability that their code can be recompiled as full C++ without surprises.
(See namespace caveat below.)
> However, there
> is one major difference in the template area, and that is the strategy
> that one would use to implement the library. If you take the view that
> the language should make it possible to implement the standard library
> (aside from restrictions on names of identifiers and access to the operating-
> system primitives needed to do so), then it is certainly true that an
> implementation of the EC++ library cannot be a subset of the implementation
> of the C++ standard library, because a standard-library implementation has
> no choice but to use templates.
The *implementation* does not itself have to be a proper subset in order for it
to *provide* a subset of the capabilities of full C++. In fact, I get a lot of mileage
out of code patterns such as:
#if _IS_EMBEDDED
class filebuf : public streambuf {
#else
template<class _E, class _Tr>
class basic_filebuf : public basic_streambuf<_E, _Tr> {
#endif
The bulk of the code is identical between EC++ and the full C++ libraries.
But that's my problem, not the programmer's.
> Now let's return to your example:
>
> #include <iostream>
>
> int main()
> {
> cout << "Hello, world!\n";
> return 0;
> }
>
> Legal though this example may be in EC++, it is *not* legal in standard C++
> because the header <iostream> puts its names in namespace std.
It may not be valid Standard C++, but implementations exist that accept it
(besides EC++, that is).
> So, to be
> legal in standard C++, you must write
>
> #include <iostream>
>
> int main()
> {
> std::cout << "Hello, world"\n";
> return 0;
> }
>
> Alternatively, you could insert
>
> using std::cout;
>
> or
>
> using namespace std;
>
> in an appropriate place.
Or you could use one or more of the techniques I outlined in an earlier
posting. Or you could simply impose upon your compiler vendor to add
a compile option to deal with the missing namespace decorations, if the
option doesn't already exist (see below).
> Suppose, though, that you wanted to write this trivial program in a way
> that was well formed in both standard C++ and EC++. How would you do that?
> None of the techniques I've suggested so far would work, because they rely
> on namespaces. And although changing <iostream> to <iostream.h> would be
> likely to work on most standard C++ implementations, the standard itself
> does not offer <iostream.h>, which means that any program that uses it
> is relying on an extension. So how do you write this program in the intersection
> of standard C++ and EC++?
For that matter, what do you do with the five gazillion lines of C++ code written
before namespaces were added to Standard C++. Everything you say above
applies. I suppose you can argue that we should know better now. Any new
code we write should make proper use of namespaces and be done with it.
Yeah, well, there are still lots of compilers out there with no support for
namespaces. And as has been observed in a separate thread, *not a single
compiler available today* fully conforms to the standard in its handling of
namespaces in the library. So as a practical matter:
-- compilers have to deal with programs written with no consideration for
namespaces
-- some programmers have to write code that can work, with no compiler
assistance, with a host of variations of library namespaces
These are obviously transient phenomena. So too was the move from
``K&R style'' C code. Programmers have known since April 1983 that
they would have to change their coding practice and rewrite existing code
to conform to the emerging C Standard. Yet it is still a common compiler
option to tolerate K&R C, fifteen years later...
If this is the worst dialect difference between EC++ and Standard C++,
seems to me it's lost in the noise of backward compatibility issues.
> Summary: You've convinced me that the lack of templates might well be
> capable of being implemented as a true subset. On the other hand,
> you've also convinced me that the lack of namespaces is a much more profound
> incompatibility than I had realized previously.
That's what I kept saying from 1993 through 1997. But it's a dangerous thing
to say now. Want to tell all those companies with a huge investment in
existing C++ code that it's profoundly incompatible with Standard C++?
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/07/06 Raw View
Andrew Koenig wrote:
>
> In article <359E27D9.28BB31D8@acm.org>,
> Pete Becker <petebecker@acm.org> wrote:
> > Andrew Koenig wrote:
>
> > > Well, that's true, but I don't consider [namespaces] the most important issue.
>
> > > The main thing is that EC++ doesn't support templates [unless it has changed
> > > since the last time I checked], which means that any library classes that
> > > are based on templates must either be different from standard C++ or absent.
>
> > That is simply not true. The library classes that are defined in terms
> > of instantiations of templates can be implemented as classes directly:
>
> > #include <iostream>
>
> > int main()
> > {
> > cout << "Hello, world!\n";
> > return 0;
> > }
>
> > That's perfectly legal in EC++, and it's perfectly legal in standard C++
> > (ignoring namespaces).
>
> I think I get it. You're saying that although the EC++ library is
> implemented in a way that differs from the C++ standard, users can't
> tell because EC++ doesn't have any of the language facilities that
> would be necessary to be able to tell. So, for example, although standard
> C++ says that the type `string' is a synonym for the type `basic_string<char>',
> and EC++ cannot provide that equivalence because it has no templates,
> there's no way for a user to use the type `basic_string<char>' directly
> anyway, so users can't tell.
>
> It's analogous to the difference in the result type of prefix++ between C++
> and C. In C, ++x is always an rvalue. In C++, if x has built-in type, ++x
> is an lvalue if x is an lvalue. So that's a difference between C++ and C,
> and it might be possible to claim it's an incompatibility. However, there is
> no way to write a C program that can detect the incompatibility, so it
> doesn't matter.
>
> I will have to think about whether I can come up with a user-detectable
> example that behaves differently with and without templates. However, there
> is one major difference in the template area, and that is the strategy
> that one would use to implement the library. If you take the view that
> the language should make it possible to implement the standard library
> (aside from restrictions on names of identifiers and access to the operating-
> system primitives needed to do so), then it is certainly true that an
> implementation of the EC++ library cannot be a subset of the implementation
> of the C++ standard library, because a standard-library implementation has
> no choice but to use templates.
>
> Now let's return to your example:
>
> #include <iostream>
>
> int main()
> {
> cout << "Hello, world!\n";
> return 0;
> }
>
> Legal though this example may be in EC++, it is *not* legal in standard C++
> because the header <iostream> puts its names in namespace std. So, to be
> legal in standard C++, you must write
>
> #include <iostream>
>
> int main()
> {
> std::cout << "Hello, world"\n";
> return 0;
> }
>
> Alternatively, you could insert
>
> using std::cout;
>
> or
>
> using namespace std;
>
> in an appropriate place.
>
> Suppose, though, that you wanted to write this trivial program in a way
> that was well formed in both standard C++ and EC++. How would you do that?
> None of the techniques I've suggested so far would work, because they rely
> on namespaces. And although changing <iostream> to <iostream.h> would be
> likely to work on most standard C++ implementations, the standard itself
> does not offer <iostream.h>, which means that any program that uses it
> is relying on an extension. So how do you write this program in the intersection
> of standard C++ and EC++?
A solution would be to allow the statement
using namespace std;
to be used, but ignored by the EC++ compiler. This is what current
g++ does, and it works well enough to have std conforming programs
compiling on g++.
>
> Summary: You've convinced me that the lack of templates might well be
> capable of being implemented as a true subset. On the other hand,
> you've also convinced me that the lack of namespaces is a much more profound
> incompatibility than I had realized previously.
But one that can be solved with the g++ trick. (It would of course
still be possible to write non-C++-conforming EC++-programs; however
each EC++ program could be written to compile with EC++ as well as
C++, with the one possible exception of float_fomplex and
double_complex. However, I can imagine that it would also be
possible to accept and ignore the statements
typedef complex<double> double_complex;
and
typedef complex<float> float_complex;
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/06 Raw View
In article <01bda6a6$7f99a6c0$8a1ec2d0@porky>, "P.J. Plauger"
<pjp@dinkumware.com> writes
>Mike Davies <mike_davies@noco.demon.co.uk> wrote in article <XaGUSJA+Aom1EwfH@no
>co.demon.co.uk>...
>> >Again you miss the point. (It's an easy one to miss.) It's not the number of
>> >locales supplied by the vendor that adds to the complexity. Rather, it's the
>> >*extensibility offered to the programmer* that you can't hide from as an
>> >implementor. Offer just one prepackaged locale and you conform. Deny the
>> >programmer the right to add or change facets and you don't conform. Once
>> >you don't conform, you may as well not conform in style.
>>
>> Um.. I don't agree with you here, you can conform and provide the
>> customer with low-cost (memory space costs I mean) extensions as I
>> believe you already do. The problem with EC++ as a non-conforming
>> "standard" is that it cuts out lots of other stuff that doesn't have
>> (perhaps implementation dependent) costs too.
>
>Sigh, here's that semantic dance again.
I don't understand why this is a "semantic dance" (or even what you mean
by this).
> I think you're insisting that any
>nonstandard version must always accompany one that is capable of
>conforming to the standard.
Yup, if supplied as part of a compiler suite.
>A library certainly doesn't conform with the kind
>of ``low-cost extensions'' we've discussed here. If that kind of packaging is
>indeed what you want, I can tell you that some vendors do offer EC++
>as an add-on to a reasonably full implementation, others do not. It's a
>marketing choice for our customers, as far as I'm concerned.
The point is that if a cut down compiler is supplied as well as a cut
down library then the end-user is denied the chance to use C++. The
subset that is EC++ lacks facilities that any customer will need sooner
rather than later.
>
>The problem I have with your definition of ``costs'' is that it is not the same
>as those of our immediate customers (compiler vendors) and their customers
>(programmers of embedded systems). There ain't no such thing as a free
>lunch.
I don't know about a free lunch, but I am an embedded systems
programmer, and I know that if a language feature has many uses along
with no costs then that is a good thing.
...snips throughout...
>P.J. Plauger
Regards,
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/07 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> wrote in article <uCdakDAo7Qo1EwJb@noco.demon.co.uk>...
> >> Um.. I don't agree with you here, you can conform and provide the
> >> customer with low-cost (memory space costs I mean) extensions as I
> >> believe you already do. The problem with EC++ as a non-conforming
> >> "standard" is that it cuts out lots of other stuff that doesn't have
> >> (perhaps implementation dependent) costs too.
> >
> >Sigh, here's that semantic dance again.
>
> I don't understand why this is a "semantic dance" (or even what you mean
> by this).
Sorry to be so obscurely self referential. In an earlier posting, I made the
point that each compiler switch setting was essentially a different
implementation. ``Conforming with extensions'' is an oxymoron if applied
to a single implementation, particularly if the ``extensions'' omit parts of
the language or library to achieve greater efficiencies. ``Conforming with
extensions'' might make sense if you're describing a set of implementations
packaged together and selected among by compiler switches. You have
reaffirmed that this is what you meant.
> >The problem I have with your definition of ``costs'' is that it is not the same
> >as those of our immediate customers (compiler vendors) and their customers
> >(programmers of embedded systems). There ain't no such thing as a free
> >lunch.
>
> I don't know about a free lunch, but I am an embedded systems
> programmer, and I know that if a language feature has many uses along
> with no costs then that is a good thing.
And I reiterate my belief that what appears to have ``no costs'' to you can
have very real costs to implementors, and hence to other customers
overtly and you covertly. You don't see the cost until a bug in an ``unused''
language feature reaches over and bites you. James Kanze has made this
point much better than I can, on more than one occasion.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: loewis@informatik.hu-berlin.de (Martin v. Loewis)
Date: 1998/07/07 Raw View
ark@research.att.com (Andrew Koenig) writes:
> I will have to think about whether I can come up with a user-detectable
> example that behaves differently with and without templates.
I believe that the following code is valid EC++, but invalid standard
C++:
#include <iostream>
#ifndef __ecplusplus
using std::istream;
using std::ostream;
#endif
void f(class ostream& x)
{
x<<"Hallo\n";
}
void istream();
The problem here is not really the templates, but that in standard
C++, several things are typedefs and not classes.
Regards,
Martin
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/07/02 Raw View
In article <6ne5qd$kfc$1@shell7.ba.best.com>,
ncm@nospam.cantrip.org (Nathan Myers) wrote:
>
> <jkanze@otelo.ibmmail.com> wrote:
> >Many years ago, I did some measures on sort routines. The point where
> >quick sort becomes typically better than shell sort was around 100000
> >elements.
>
> Using what ratio of compare:swap time? Without such a
> specification the crossover point is meaningless.
The measurements were made of execution time. Since I was comparing
and swapping integers, I imagine that the times were about equal.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/02 Raw View
In article <359AC0CC.7CF02CA2@acm.org>, Pete Becker <petebecker@acm.org>
writes
>Mike Davies wrote:
>>
>>
>> This is true, but the practical code overhead for including exceptions
>> is about 5-10 % (in my experience). Given that almost every embedded
>> project I have worked on has had an entry in the requirement spec
>> insisting upon a minimum of 50% spare code space for future development
>> then this doesn't look so bad.
>>
>
>On the contrary: if you're at the 50% limit you can't afford to add
>5-10%. The fact that the extra memory is supposed to be there doesn't
>mean you can use it. If you do you're violating the system's
>requirements.
>
The point I was making is that if contractual/managerial requirements
can double the memory supplied as part of an embedded system then 5-10%
extra for engineering reasons doesn't seem so bad.
And don't forget that this is only required if you wish to *use*
rtti/exceptions, otherwise just switch them out.
--
Mike Davies
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/02 Raw View
In article <3598D65D.C2211A92@acm.org>, Pete Becker <petebecker@acm.org>
writes
>I don't know why the EC++ detractors keep insisting that it is the only
>subset appropriate for discussion.
Its the only subset that's been widely aired AFAIK.
> Nobody who supports EC++ has made
>such a claim. The C++ standards committee is not bound by the definition
>of EC++. The committee has been asked to produce a subset suitable for
>use in embedded systems. The starting point is EC++.
A better starting point IMO would be C++, together with a proposal for
splitting the standard library into orthogonal parts.
> Discussions of how
>to define a good subset are perfectly appropriate, and welcomed by
>anyone with an open mind.
>
It seems to me that superset is a more useful concept than subset.
--
Mike Davies
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/03 Raw View
In article <6ne5qd$kfc$1@shell7.ba.best.com>, Nathan Myers
<ncm@nospam.cantrip.org> writes
>
>Try to run any version of iostreams on a machine with a few dozen bytes
>of memory. The concept is silly to contemplate. When your memory is
>so little you won't consider any library that is also useful on bigger
>machines.
>
I think that library use on extremely resource constrained systems *is*
likely to be limited as you suggest. However there is no reason AFAIK
why any library should not be used if it fits the bill.
You will consider anything that will do the job in the end : library
vendors for this market have to work to earn their crust. Part of the
way they can do that is provide librarys which can have parts left out
as required.
The concept of overloading operators ">>" and "<<" to provide I/O is no
sillier on a PIC than on a mainframe IMO.
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/03 Raw View
In article <01bda3c9$f9e48920$8a1ec2d0@porky>, "P.J. Plauger"
<pjp@dinkumware.com> writes
>saroj@bear.com wrote in article <6n8cb4$a7f$1@nnrp1.dejanews.com>...
>> In article <3596ACC0.A226AA6A@acm.org>,
>> I have always heard how big the cout << "hello world" program is.
>> Can you say that iostream template is the cause of this? Definitely not.
>
>I assume this is a rhetorical question, since you answered it for all of us.
>Too bad you're wrong. Templatized iostreams are at least part of the
>problem, if not all of it.
No, as has been discussed here, the Watcom V11.0 compiler has an option
that can eliminate the overhead associated with locale facets in the
iostreams. All of the problem lies at the door of compiler
implementations.
>
>Not necessarily. You seem to take for granted that the templatized code
>is essentially the same as the non-templatized code, which is far from
>the case.
"Templatise" with a pointer to void then as you do with a structure in
the equivalent C program. Ugly though IMO.
>> It has been repeated in this
>> group that a compiler can remove the unused virtuals.
>
>One or two evidently can. Most don't.
You are a compiler vendor, it's in your hands :-)
>> Even if your
>> compiler does not do this, a library vendor can tell its customers that
>> because of such and such constraints our iostream library supports only
>> one locale or does not support locale stuff.
>
>Yup. That's called a nonconforming subset. Do you want to design a
>coherent one and call it, say, EC++?
EC++ is *not* a coherent subset of C++. No feature of C++ can be removed
without inconveniencing somebody. If you have to have an expedient for
efficiency reasons then supply *extra* features, don't reduce the
standard.
>True. Once you consider such a wide range of subsets, you give up on
>any possibility of writing code that's portable across different compiler
>implementations. A clearly identified, efficient subset offers more promise.
But you don't then have portability from full (or anything *like* full)
C++. One of the key advantages of using a general purpose language for
applications (eg embedded systems) for which it was not specifically
designed is to have a wide choice of cross-compilers, application
specific librarys etc etc. If you cannot use any of these features
because your compiler is for EC++, not C++ then you might just as well
have stayed with C. *Most* of the justification for C++ (indeed OO in
general) is to be able to re-use code. EC++ doesn't give you that
facility to any greater extent than C IMO.
>> So just for <iostream>, do you really
>> need a EC++ label for your product?
>
>No. You also need it for string and complex, as I mentioned above. And
>you need it to ensure that you have a library that can survive the elimination
>of RTTI, multiple inheritance, exceptions, etc. The label itself provides some
>assurance of coherence and portability, as I also mentioned above.
It would be better to spend the time on compiler design. Vendors can
supply librarys specifically for embedded systems then in the knowledge
that they will at least compile under any C++ compiler. It is the
library vendors business to supply one that worls well in a particular
domain.
I haven't heard anybody suggest that the C++ standard should include a
database library suitable for supporting an enterprise wide database,
why should the Standard library support deeply embedded systems ?
If you sell into a specific market area you make your living by
supplying stuff that isn't in the standards.
>
>> Ultimately, a vendor will succeed
>> by making the customer (programmers') life easy by supplying the
>> whole library (within the resource constraints) and not by claiming
>> compliance with an standard like EC++.
>
>Now wait. What's ``a whole library (within the resource constraints)''?
>Is that a subset in disguise or not?
No, a superset.
>
>> Please do not underestimate the
>> intelligence of your customers - they will see through it.
>
>Yeah. Particularly when you tell `em you're giving them just a full
>implementation of C++, at whatever cost, for their own good.
Plus the ability to customise it to suit their specific application
>
>P.J. Plauger
Regards,
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/03 Raw View
In article <WaIm1.630$0T2.17384997@mothra.gol.ad.jp>, "David J.
Littleboy" <davidjl@gol.com> writes
>Mike Davies wrote in message ...
>
>>This isn't intended as a libel upon *anybody*, but I have seen posts in
>>this thread whose tenor was very sympathetic to EC++, and which claimed
>>that the high entry costs of writing a fully standard conforming C++
>>compiler were the main reason for the creation of EC++.
>
>It seems that you have misunderstood my remarks about
>microcontroller manufacturers and applied them to C++ compiler vendors,
>which was _never_ my intention.
OK, maybe I have misunderstood you then, this has been because I don't
*ever* come across compilers written by microcontroller manufacturers
these days. That is not to say they don't exist of course, and I can
only offer them the same advice I would offer a mfr of PLDs who wrote
their own VHDL compiler :
Why are you writing software ? Stop being silly and farm the work out
for Gods sake !
> Maybe I overstated my case and a better
>statement would be "the simplicity of EC++ provides some added niceties =
for
>manpower and financial resource limited microcontroller manufacturers." =
I
>was _never_ referring to compiler vendors only to microcontroller hardwa=
re
>development groups (who provide
>development envs for their products). Also, I was trying to explain that=
the
>"cost of entry" for such a group includes the long term cost of supporti=
ng
>their customers who try to develop applications for those microcontrolle=
rs.
>
>One reason you may have misunderstood my comments is that I'm largely
>referring to Japanese electronics companies with fab lines and
>in-house designed microcontrollers. I don't know anything about developm=
ent
>on Intel, IBM, and Motorola microcontrollers,
All done nowadays (at Intel anyway, IBM may be different, they're a
sotfware house aren't they ? <g>) by third party suppliers in a *very*
competitive market.
> but I've translated a lot of
>manuals for microcontrollers from companies most people associate with
>stereos and home appliances. (There are even Japanese steel companies an=
d
>shipbuilders who have diversified into semiconductors, but I don't know =
if
>they make microcontrollers.)
If they make their main living selling hardware not software then why
don't they club together and fund an 8-bit optimised instruction
scheduler for the EGCS compiler ?
This would be cheaper than writing even a C compiler from scratch, would
give full C++ support from day one, would transfer the maintainance
costs into the public realm, would benefit from the ongoing work
provided by the EGCS people and lastly the difference in price could go
to the FSF to help support the free software initiative. Hooray=B2 IMO.
...snip...
>As a relative newcomer to C++, I'm impressed by the depth, scope, and
>difficulty of the language.=20
You don't have too learn it all at once, I've been using it for 5 years
and I still get the occasional brainout from it :-)
>It is clear to me that C++ is a much more
>difficult language to support than C was. So I have _lots_ of sympathy
>for managers who are faced with supporting such a language.
Those managers will be glad in the end of the resources the language
provides to the programmers who use it.
>
>David J. Littleboy <davidjl@gol.nonspam.com>
Regards,
--=20
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: wkdugan@ix.netcom.com (Bill Dugan)
Date: 1998/07/03 Raw View
On 01 Jul 98 16:34:23 GMT, jkanze@otelo.ibmmail.com wrote:
>In article <3599ae14.5018932@nntp.ix.netcom.com>,
> wkdugan@ix.netcom.com (Bill Dugan) wrote:
>
>> >They may not know the actual ammount of memory, but they do know the
>> >maximum. If the processor has 16 address bits, you really don't have
>> >to worry about what happens with more than 64K elements. And of course,
>> >a lot of processors have even less.
>>
>> 64K is already past the point where
>>
>> >>>a linear search will _always_ be faster than a tree based lookup.
>
>Many years ago, I did some measures on sort routines. The point where
>quick sort becomes typically better than shell sort was around 100000
>elements.
It's not clear that's the same point where a tree-based lookup would
become faster than a linear search.
>> Many of the classical algorithms were developed in the days when most
>> machines had no more than 64K, because linear search wasn't always
>> faster on such machines.
>
>You have to go back very far to find a time when mainframes had only
>64K. Well before the invention of quicksort, for example.
That's not the way I remember it, but it's been long enough that my
recollection may be faulty. In any case, there were still a lot of
smaller machines in use when quicksort was invented. Minicomputers
with 64K (or less) addressing were in use quite a while afterward.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/03 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> wrote in article <WfQEzQAnH9m1Ewv0@noco.demon.co.uk>...
> > Templatized iostreams are at least part of the
> >problem, if not all of it.
>
> No, as has been discussed here, the Watcom V11.0 compiler has an option
> that can eliminate the overhead associated with locale facets in the
> iostreams. All of the problem lies at the door of compiler
> implementations.
I propose the addition of the keyword dwim. (There's prior art for it.) Use it
anywhere in your code and the resultant program will do what you mean,
not what you say. Can't buy a compiler like that tomorrow? ``All of the problem
lies at the door of compiler implementations.''
You cite one optimization that ameliorates one part of a large and diffuse
problem, then observe that one compiler vendor provides it as an option.
(Why an option, by the way, if it's such an obvious good idea?) A solution
exists. The remainder of the proof is left as an exercise for the implementors.
> >Not necessarily. You seem to take for granted that the templatized code
> >is essentially the same as the non-templatized code, which is far from
> >the case.
>
> "Templatise" with a pointer to void then as you do with a structure in
> the equivalent C program. Ugly though IMO.
Even then you still introduce structural changes that lead to more expensive
code. It ain't that simple, I keep saying.
> >> It has been repeated in this
> >> group that a compiler can remove the unused virtuals.
> >
> >One or two evidently can. Most don't.
>
> You are a compiler vendor, it's in your hands :-)
Actually, we're not. We're a library vendor. We contract with compiler vendors to
make our libraries work as well as possible with their existing C++ compilers and
C libraries, as a rule. For them, getting a standard-conforming C++ library is just
one small nuisancy detail in getting the next box-full of goodies out the door. Do
you think the code-generator folks, or the linker people, or the (probably separate)
C compiler group are going to down tools and hustle out a whole new set of
optimizations just to get this one small component to work better? How did it
come to pass (they ask) that a standard nine years in the making should
suddenly *require* optimizations not needed in the past, and still not come
close to past performance?
Sure it's in our hands, if ``our'' includes several distinct groups working in tandem.
And we all have our hands full.
> >Yup. That's called a nonconforming subset. Do you want to design a
> >coherent one and call it, say, EC++?
>
> EC++ is *not* a coherent subset of C++. No feature of C++ can be removed
> without inconveniencing somebody.
Hmm, that's not my definition of ``coherence.'' But it does highlight a
fundamental philosophical difference between us.
> If you have to have an expedient for
> efficiency reasons then supply *extra* features, don't reduce the
> standard.
I'm not reducing the standard. I'm supplying a subset that's more practically
realizable given the technology of today, and the near- to medium-term
future at least. I didn't design the subset, but I respect the goals of the
designers.
> >True. Once you consider such a wide range of subsets, you give up on
> >any possibility of writing code that's portable across different compiler
> >implementations. A clearly identified, efficient subset offers more promise.
>
> But you don't then have portability from full (or anything *like* full)
> C++.
Quite right. There's a price associated with any compromise, even full C++.
> One of the key advantages of using a general purpose language for
> applications (eg embedded systems) for which it was not specifically
> designed is to have a wide choice of cross-compilers, application
> specific librarys etc etc. If you cannot use any of these features
> because your compiler is for EC++, not C++ then you might just as well
> have stayed with C. *Most* of the justification for C++ (indeed OO in
> general) is to be able to re-use code. EC++ doesn't give you that
> facility to any greater extent than C IMO.
Another philosophical difference. I have detected a few advantages to using
EC++ over C. So have others.
> >> So just for <iostream>, do you really
> >> need a EC++ label for your product?
> >
> >No. You also need it for string and complex, as I mentioned above. And
> >you need it to ensure that you have a library that can survive the elimination
> >of RTTI, multiple inheritance, exceptions, etc. The label itself provides some
> >assurance of coherence and portability, as I also mentioned above.
>
> It would be better to spend the time on compiler design.
But why is it either/or? Some people do spend time on compiler design.
The programmers in my company spend time on library design. Some of
that time goes to improving full C++, some goes to implementing subsets.
Why can't we all just get along?
> Vendors can
> supply librarys specifically for embedded systems then in the knowledge
> that they will at least compile under any C++ compiler.
Done that.
> It is the
> library vendors business to supply one that worls well in a particular
> domain.
Done that.
> I haven't heard anybody suggest that the C++ standard should include a
> database library suitable for supporting an enterprise wide database,
> why should the Standard library support deeply embedded systems ?
Indeed, the C++ committee seems to have decided that it should not.
I proposed several changes to the library, along the way, that would
improve the lot of embedded programmers. Those proposals that were
accepted were invariably undone at the next meeting. I got the message.
Nobody's asking for a library of interrupt handlers or device drivers. We
just want some wiggle room to ensure that C++ *can* be used effectively
in programming embedded systems. C demonstrably meets that
requirement. People pay lip service to the goal of having C++ do the
same. We're discussing here the ways that C++, and the library in
particular, has fallen short of that stated goal.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <david.tribble@noSPAM.central.beasys.com>
Date: 1998/07/03 Raw View
P.J. Plauger <pjp@dinkumware.com> wrote:
>> My company, Dinkumware, Ltd., promptly wrote the library subset
>> required by that spec, and several compiler vendors provided compiler
>> switches for testing conformance with the language subset promoted by
>> that spec.
Andrew Koenig wrote:
> In the interest of accuracy, I would like to point out that the EC++
> library is not a subset of the C++ library.
That implies that the EC++ library contains something that the C++
library doesn't. What would that be? How is it not a subset?
-- David R. Tribble, dtribble@technologist.com --
-- C++, the PL/1 of the 90s.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/03 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> wrote in article <OPbCHWAKe9m1EwNt@noco.demon.co.uk>...
If they make their main living selling hardware not software then why
don't they club together and fund an 8-bit optimised instruction
scheduler for the EGCS compiler ?
This would be cheaper than writing even a C compiler from scratch, would
give full C++ support from day one, would transfer the maintainance
costs into the public realm, would benefit from the ongoing work
provided by the EGCS people and lastly the difference in price could go
to the FSF to help support the free software initiative. Hooray IMO.
Hmm. I just recently downloaded EGCS and looked it over. Best I can
tell, the library it supplied is a *subset* of what we call the Dinkum
Abridged Library. This is essentially the EC++ library with STL layered
atop it. Take away SGI's STLPort and what's left could qualify as a
wannabe EC++ library.
Not sure what you mean by ``full C++ support from day one''...
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/07/03 Raw View
Mike Davies wrote:
>
>
> No, as has been discussed here, the Watcom V11.0 compiler has an option
> that can eliminate the overhead associated with locale facets in the
> iostreams. All of the problem lies at the door of compiler
> implementations.
No, as has been said here, the Watcom V11.0 compiler has an option that
some people think might be able to eliminate the overhead associated
with locale facets in iostreams. Nobody here has said that they tested
it.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/03 Raw View
saroj@bear.com wrote in article <6neq6i$ci$1@nnrp1.dejanews.com>...
> > Offer just one prepackaged locale and you conform. Deny the
> > programmer the right to add or change facets and you don't conform. Once
> > you don't conform, you may as well not conform in style.
> >
>
> Nonsense. Just because you may have to deviate from the standard
> in locale and iostream (even that may not be necessary), that does
> not mean you will ignore very very important parts of the C++
> language - templates, exceptions, namespaces, rtti (to lesser
> extent). A modern program written without these features should not
> even pretend to be C++ (may be another language).
An interesting opinion. A language with those very characteristics pretended
to be C++ for many years. It was the language in effect when many of its
users and suppliers decided to standardize it.
> PJ, take a mid size program; (re)write it using the full C++.
> After that rewrite using a C++ subset - 1st option: full C++
> minus locales; 2nd option: no template (STL), no exceptions,
> no namespace (did somebody say EC++?). See which is harder? It
> is not an argument against locales. All I am saying is that the
> programmer will be writing to a totally different language without
> features like templates, exceptions, but it may be easier to
> encapsulate the I/O part in a different module (old iostream vs.
> iostream).
I agree with everything you say here, particularly the need to make
quite distinct libraries if you want to avoid the overheads introduced
into the iostreams library in the process of standardization.
> > Recompile a typical C++ library with exceptions disabled and see what
> > happens. (Safety tip: hide behind the sofa.)
> >
> I said, that the library will be designed with that in mind -
> it will either throw an exception or call a user handler.
Exactly. Vendors have to do the advance work or you can't experiment
with options. You want vendors to give you a Chinese menu of features
that you can disable in arbitrary combinations. You will scream bloody
murder if you trip across a combination that doesn't work. And you will
still complain if your idea of the most efficient subset isn't as efficient
as you imagined. We try to do the work that has the biggest payoff. So
we focus on those combinations that we think will be most useful. One
such combination of features is called EC++.
> Ignoring templates (low cost and
> better than many alternatives) and namespace (zero cost), now I
> am talking about exceptions and rtti. Turning rtti on/off is a single
> compiler switch. Do you have a better idea than calling user level
> handler or throwing an exception in the library depending on a switch?
> Is that a great deal of work (beside the normal library work)?
What the heck is ``normal library work''? To me, it's making a product
that sells. If it's too big, slow, or buggy, it won't sell. Providing no
subsets makes for a library that's too big and slow for an important
market segment (to us). Providing too many subsets makes for a
library that's likely to be too buggy. Picking a coherent subset or two
is the safe middle ground.
> What is the part of the iceberg that I missed? Let us set aside the
> iostream argument for a moment.
Uh, you just set the iceberg aside.
> Can EC++ do better than the solution
> I proposed :
> -lstdcpp_rtti -l[exception_handler|user_handler]
> -lstdcpp_no_rtti -l[exception_handler|user_handler] and the
> compiler automatically selecting the library for you? If yes, please
> tell us how?
>
> Once you agree to these things, now we have locale and iostreams.
Turning off the potentially expensive language features is part of the
solution, as has often been observed in this thread. Preparing the library
to work without those features is a necessary accompaniment. You
don't get it for free. But then you still have ``problems with locale and
its facets,'' to name the major example that has driven this thread, plus a
host of minor examples from other parts of the library. What do you omit,
and why? What do you keep, and why? Those decisions are critical to
obtaining the *coherence* I keep harping on. Then you have to drive a
cleavage plane through the code for the full library so that the identified
subset actually works, and takes advantage of the permitted omissions.
If you don't do this partitioning, you get only a fraction of the savings
that are possible. And it ain't easy, I can attest.
> If
> inspite of all the optimizations, it is not possible to fit the
> library within an embedded system, now you, together with other people
> (many from this newsgroup will also participate) can sitdown together
> and solve the real problems faced by the implementors or even suggest
> a embedded iostream library. EC++ is a totally different story.
Uh, but what if EC++ makes it possible to fit the library within an
embedded system? Remember, embedded systems cover an enormous
range of sizes. Any improvement in code size will open up more
candidate applications. I kinda thought that EC++ *was* solving ``the
real problems faced by the implementors'' in its own way. Other ways
also exist, to be sure, such as improving compilers, linkers, and full
C++ libraries. Nobody had advocated stopping such work because
EC++ exists -- I've been known to do a bit of work along those lines
myself.
> > > And I always
> thought you
> > > are a great programmer.
> >
> > Thanks, I think.
>
> Yes, you are very talented. You can contribute your expertise and also
> work with other experts here to improve C++ implementation techniques
> and decide on the engineering compromises needed for embedded systems
> in a democratic and open process.
What the hell do you think I've been doing for the past eighteen years? I've
devoted hundreds of hours per year, year in and year out, to doing just that,
for Posix, C, and C++, to name just the major standards to which I've
contributed. And I've done it all on my own nickel, near as no matter.
The democratic and open process that led to the C++ Standard has
apparently left some needs unmet, particularly for programmers of embedded
systems. I'm trying to meet those needs, in my own way, *as well as* advancing
the cause of the C++ Standard. It ain't either/or.
> This is also a plea to everybody. Please let us stop this thread and
> instead discuss the implementation techniques and typical embedded
> system configurations and what can be be the right compromises.
Seems to me we have been, along with the polemics pro and con EC++.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/03 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> wrote in article <XaGUSJA+Aom1EwfH@noco.demon.co.uk>...
> >Again you miss the point. (It's an easy one to miss.) It's not the number of
> >locales supplied by the vendor that adds to the complexity. Rather, it's the
> >*extensibility offered to the programmer* that you can't hide from as an
> >implementor. Offer just one prepackaged locale and you conform. Deny the
> >programmer the right to add or change facets and you don't conform. Once
> >you don't conform, you may as well not conform in style.
>
> Um.. I don't agree with you here, you can conform and provide the
> customer with low-cost (memory space costs I mean) extensions as I
> believe you already do. The problem with EC++ as a non-conforming
> "standard" is that it cuts out lots of other stuff that doesn't have
> (perhaps implementation dependent) costs too.
Sigh, here's that semantic dance again. I think you're insisting that any
nonstandard version must always accompany one that is capable of
conforming to the standard. A library certainly doesn't conform with the kind
of ``low-cost extensions'' we've discussed here. If that kind of packaging is
indeed what you want, I can tell you that some vendors do offer EC++
as an add-on to a reasonably full implementation, others do not. It's a
marketing choice for our customers, as far as I'm concerned.
The problem I have with your definition of ``costs'' is that it is not the same
as those of our immediate customers (compiler vendors) and their customers
(programmers of embedded systems). There ain't no such thing as a free
lunch.
> The solution of providing other libraries as well as a C++Standard
> conforming one seems to me to be a good interim measure while compiler
> technology catches up with the standard.
Thanks for that much, at least. It's a significant part of our business.
> >And on the ability of the compiler and library to indulge their whims.
> >Recompile a typical C++ library with exceptions disabled and see what
> >happens. (Safety tip: hide behind the sofa.)
>
> That doesn't happen with your extensions does it ? ;-)
No. That was part of the work we put into them. But feel free to try the
same thing with other libraries. Fun to watch.
> >You've described Dinkumware's library offerings to a tee, thanks.
>
> It sounds like a good solution to me.
>
> If compiler implementation techniques that can eradicate costs from
> features of the full C++ language become widespread (as they will if
> they are publicised) then those features will obviously find their way
> into all of the libraries supplied by a vendor.
>
> Someone trying to shoehorn a piece of code into a small ROM may be glad
> of an expedient regardless of its purity.
> However this does not amount to an argument for EC++ as a *standard*.
I personally don't want EC++ to become an ISO standard. Never have.
> This is because it is overwhelmingly inadequate for *all* embedded
> programmers needs, and as a standard is likely to hold back the
> development of full-featured C++ compiler implementations for embedded
> use.
Some embedded systems programmers have failed to notice that it is
overwhelmingly inadequate. Matter of opinion, I guess, since it is hard to
demonstrate. It is also a matter of opinion, and unprovable, that the
existence of EC++ as a standard (in any form) will hold back the
development of full C++. Dinkumware is certainly doing its part to
promote and improve full C++ as well as EC++.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/07/01 Raw View
Nathan Myers wrote:
>
> Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
> >Ok, let's make a next try: Define EC++ as full C++ compiler with
> >the option to turn costly features off, and a std library with
> >certain standardized extensions to avoid common overhead.
>
> Sorry, you don't get to define EC++. EC++ has been defined already
> by a self-selected consortium, and it stinks. If you want to define
> something else, give it a different name so we know what you're
> talking about.
>
Author: Pete Becker <petebecker@acm.org>
Date: 1998/07/01 Raw View
Nathan Myers wrote:
>
> Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
> >Ok, let's make a next try: Define EC++ as full C++ compiler with
> >the option to turn costly features off, and a std library with
> >certain standardized extensions to avoid common overhead.
>
> Sorry, you don't get to define EC++. EC++ has been defined already
> by a self-selected consortium, and it stinks. If you want to define
> something else, give it a different name so we know what you're
> talking about.
I don't know why the EC++ detractors keep insisting that it is the only
subset appropriate for discussion. Nobody who supports EC++ has made
such a claim. The C++ standards committee is not bound by the definition
of EC++. The committee has been asked to produce a subset suitable for
use in embedded systems. The starting point is EC++. Discussions of how
to define a good subset are perfectly appropriate, and welcomed by
anyone with an open mind.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/07/01 Raw View
P.J. Plauger<pjp@dinkumware.com> wrote:
>Nathan Myers <ncm@nospam.cantrip.org> wrote:
>> P.J. wrote:
>> >The committee at first shied away from templatizing iostreams,
>> >string, and complex, because of the known inefficiencies introduced
>> >when you generalize all of these classes.
>>
>> That was not why the committee initially shied away from templatizing
>> iostreams.
>
> I was there at the time. You weren't.
This is a false statement.
>> -- The template char_traits<> adds no overhead at runtime.
>
> I disagree.
The repeated pattern is:
PJ: "The standard mandates overhead."
NM: "False, the standard does not mandate overhead."
PJ: "Many current implementations impose overhead when
implementing standard features."
The fact is, the standard does not mandate overhead. Naive and
immature implementations impose overhead. To say that the standard
itself mandates overhead is to claim that nobody will ever have an
efficient conforming implementation, with obvious corollaries:
-- you had better forget about standard-conforming libraries
if you need efficiency.
-- anybody who claims to offer an efficient conforming library
is a liar.
I reject these corollaries as well.
> It doesn't help to be told flatly
> that overheads don't exist when I've seen them with my own eyes.
PJ has seen overheads imposed by particular compilers and his
particular library, not by the standard.
> The bottom line is still that the Standard C++ library *can* be made
> dramatically smaller by judicious subsetting.
False. Certain implementations can be made smaller by subsetting,
The Standard C++ library itself is an interface definition, and can
be implemented as efficiently as you care to do.
Nobody objects to a company selling libraries that resemble Standard
C++. However, I will continue to call attention to false statements,
despite how useful such statements might be to one's market strategy.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/07/01 Raw View
In article <3599ae14.5018932@nntp.ix.netcom.com>,
wkdugan@ix.netcom.com (Bill Dugan) wrote:
> >They may not know the actual ammount of memory, but they do know the
> >maximum. If the processor has 16 address bits, you really don't have
> >to worry about what happens with more than 64K elements. And of course,
> >a lot of processors have even less.
>
> 64K is already past the point where
>
> >>>a linear search will _always_ be faster than a tree based lookup.
Many years ago, I did some measures on sort routines. The point where
quick sort becomes typically better than shell sort was around 100000
elements.
> Many of the classical algorithms were developed in the days when most
> machines had no more than 64K, because linear search wasn't always
> faster on such machines.
You have to go back very far to find a time when mainframes had only
64K. Well before the invention of quicksort, for example.
> If you go all the way down to machines which support only a few dozen
> or a few hundred bytes of memory, the statement might be true.
> However, I'm not familiar with any such which also have C++ or EC++
> libraries for which
I would expect such machines to be able to support EC++. I agree that
C++ would be asking a lot.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientee objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/01 Raw View
saroj@bear.com wrote in article <6natcs$t83$1@nnrp1.dejanews.com>...
> In article <01bda3c9$f9e48920$8a1ec2d0@porky>,
> > Not necessarily. You seem to take for granted that the templatized code
> > is essentially the same as the non-templatized code, which is far from
> > the case.
>
> On my Sun compiler, it is the same. The instantiated functions are put into
> separate files in a repository and compiled like normal code (automatically
> by the compiler). If VC++ compiler is not smart about instantiating only the
> needed functions and having identical code size for the instantiated
> functions, then expect it to improve soon or complain to the vendor.
You miss my point. To templatize the iostreams classes, they had to be
restructured, sometimes dramatically. Many of the restructurings led to
expressions and statements that cannot be made to collapse back to the
simpler forms of yore for type char. You pay for generality. It's not about
how smart your template processor may be -- but one that doesn't optimize
aggressively costs you even more, to be sure.
> > -- class locale
> >
> > -- various locale facets
> >
> As I said, if your target system is lacking in resources, then you can
> support only one locale or, you can say that the minimum resources
> needed to use this library is so and so.
> You do not need another standard for marketing your library.
Again you miss the point. (It's an easy one to miss.) It's not the number of
locales supplied by the vendor that adds to the complexity. Rather, it's the
*extensibility offered to the programmer* that you can't hide from as an
implementor. Offer just one prepackaged locale and you conform. Deny the
programmer the right to add or change facets and you don't conform. Once
you don't conform, you may as well not conform in style.
> > -- nested class sentry
> >
> A nested class is only lexical scoping. It can not add any overhead
> compared to an identical function (ipfx or others).
It ain't the class but what you're obliged to do with it.
> > Yup. That's called a nonconforming subset. Do you want to design a
> > coherent one and call it, say, EC++? Or do you want to just call it Fred?
> > Either way, *you're no longer implementing full C++ because you can't
> > afford the overheads*. Call it what you will.
>
> The difference is that in the first case, the customer makes the decision
> (case by case) depending on the availability of resource or portability
> needs, what to use and what not to.
And on the ability of the compiler and library to indulge their whims.
Recompile a typical C++ library with exceptions disabled and see what
happens. (Safety tip: hide behind the sofa.)
> In the second case, a group of vendors
> band together and decide what is easy for them and arbitrarily (just opposite
> of coherent) decide to standardise a subset and call it EC++ for marketing.
> Then it becomes a tool in the hands of an incompetent manager - just stick to
> the limits (arbitrarily) defined by EC++.
Where did that come from? I know from personal experience that the decisions
were *not* made arbitrarily, nor to make life easy for the vendors. Who are you
to libel people you don't even know?
> A coherent subset will have
> namespace, templates, exception and rtti (with switch to disable at the
> customer's option - not yours). All exception throwing functions in a library
> can call a function (much like a new_handler) to decide whether to throw or
> not. It will also provide a library with rtti and one without.
You've described Dinkumware's library offerings to a tee, thanks. The only
way we can ensure that customers make coherent subsets is to plan ahead
for them. Believe me, that takes a lot of work, both in the initial design and
in increased cost of product maintenance. *One* coherent subset we offer
matches the EC++ subset. Programmers who choose to use it know they
have a greater chance of moving code to another implementation that
promises the same subset -- but they don't have to.
> This is no different from vendors shipping single threaded and multi threaded
> libraries for years. In fact, it is a lot easier than multithreading issues,
> you simply compile your library with/without rtti and throw exceptions/call
> user_handler. Probably, it is even simpler than writing a shared library vs.
> archive in MS platforms, where you either litter your code with import/export
> statements or write a tool using Perl or something to create a DEF file.
> It is more comparable to creating a UNIX shared library (a single switch).
Nice of you to speculate. I've done the work. I assure you that you've only
seen the tip of the iceberg.
> And I always thought you
> are a great programmer.
Thanks, I think.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/07/01 Raw View
Pete Becker <petebecker@acm.org> wrote:
>The committee has been asked to produce a subset suitable for
>use in embedded systems. The starting point is EC++. Discussions of how
>to define a good subset are perfectly appropriate, and welcomed by
>anyone with an open mind.
The committee has "been asked" to produce a subset, but has not
resolved to produce a subset. Anyone with an open mind will not
simply assume that a subset is what the committee will work on.
The mailing list created for the purpose is a "performance issues"
list, which is in my opinion (and the committee's, apparently) a
more appropriate mode for addressing embedded-system programmers'
problems than talk about "defining subsets".
Incidentally, there is a a parallel list, for the same purpose,
open to anyone. Any insights that arise on that list will be
sure to be seen by committee participants. I've attached a copy
of the announcement below.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
Announcement:
------------
We've set up a public mailing list for open discussion of the issues
related to the use of C++ for embedded systems. Topics might include:
the problems people have encountered in writing programs on systems
with a limited memory footprint; current implementations of the
language that carry unexpected cost (like exception handling
or RTTI) in the emitted code; reentrancy and thread safety; or
real-time response for C++ programs. The discussion will be fairly
open.
To join the list, write to
c++-embedded-request at cygnus.com
The general address for the list is
c++-embedded at cygnus.com
[Replace "at" with "@"; you know the drill.]
An archive of the list is maintained on the Web at the URL
http://www.cygnus.com/ml/c++-embedded/
If you have any questions, or encounter problems joining the list,
please drop me a note.
Thanks!
Brendan Kehoe
Cygnus Solutions
brendan at cygnus.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/01 Raw View
Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote in article <3599ED5D.54E0D834@physik.tu-muenchen.de>...
> From the previous discussion, I got the conclusion that EC++ is not yet
> defined, but was in the process of being defined. And in this case it
> makes sense to suggest a definition.
> If it already *is* defined, I don't see any point in discussing it now
> - it's simply a fact and the past cannot be changed.
> .....
> Is it really a ready descripion and not just a draft?
> .....
> My impression was the following:
> There's a need for better support with embedded-system programming,
> and there's a group trying to standardize the necessary changes, and
> the standard that is planned will be called EC++. There's also a draft
> which is not at all satisfying, but since it's just a draft, it can
> still be changed - f.ex. to add a sentence that EC++ compilers must
> support full C++ as well.
>
> If that impression was wrong, I'm sorry that my comments didn't
> fit.
Your comments are extremely apt in this wandering discussion. Here's a brief
history that may help clarify. In September 1996, a consortium of Japanese
companies published the Embedded C++ Technical Specification. See:
http://www.caravan.net/ec2plus
My company, Dinkumware, Ltd., promptly wrote the library subset required
by that spec, and several compiler vendors provided compiler switches for
testing conformance with the language subset promoted by that spec. A
number of companies have been shipping EC++ compilers for the past year
or so, some including our library.
Faced with a steady stream of requests for changes, the Embedded C++
Technical Committee (the consortium) proposed to the C++ standards
committee (WG21 plus ANSI J16) that they ``take over'' this specification.
They essentially proposed that WG21 use the current spec as a starting
point to produce a Technical Report -- a document that does *not* have
the force of a formal standard. At the last WG21/J16 meeting in March,
the committee, by straw vote, expressed strong support for forming a
subcommittee to deal with the needs of embedded systems, *and other
performance issues*. But they took no formal votes.
So the current situation is that a spec for EC++ exists. The EC++
Technical Committee has stopped entertaining changes to it. WG21 has
taken no formal action, and probably won't until the next meeting in October.
Sentiment exists for producing a technical report on performance issues,
which may or may not elaborate on the EC++ spec. I know of no proposals
for making a formal standard subset of C++.
Hope this helps.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/01 Raw View
Martin v. Loewis <loewis@informatik.hu-berlin.de> wrote in article <p6qpvfqucdi.fsf@pandora.fb-inf2>...
> "P.J. Plauger" <pjp@dinkumware.com> writes:
> > So far, I haven't figured out how to avoid executable code in the initializers
> > for the iostreams objects.
>
> It certainly depends on your compiler technology. If your system
> supports weak references (such as GNU/ELF), you could use the
> following approach:
>
> ...::Init()
> {
> __init_cin();
> __init_cout();
> ...
> }
>
> void __init_cin() __attribute__((weak)){}
> ...
>
> Then, the object file containing the cin definition would also define
> __init_cin, which would override the empty implementation. So in
> effect, you call the real initialization only if the object you want
> to initialize is also linked.
Looks like a nice trick, if it's available in enough compilers. All weak
references are, of course, nonstandard extensions. That stigma alone
never deters a determined implementor from taking advantage of them,
but it does lessen the odds that a library can be structured to make
use of them in a sufficiently wide range of cases. For my part, I've never
seen a weak reference that you can implicitly stub out with an alternate
function to call, as you do here. Pete Becker says he hasn't seen this
flavor either. Maybe you can do much the same with function pointers
that default to null... Have to research those possibilities some more.
Thanks for the suggestion.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ark@research.att.com (Andrew Koenig)
Date: 1998/07/01 Raw View
In article <01bda4f8$f2e23e80$8a1ec2d0@porky>,
P.J. Plauger <pjp@dinkumware.com> wrote:
> My company, Dinkumware, Ltd., promptly wrote the library subset required
> by that spec, and several compiler vendors provided compiler switches for
> testing conformance with the language subset promoted by that spec.
In the interest of accuracy, I would like to point out that the EC++ library
is not a subset of the C++ library.
--
--Andrew Koenig
ark@research.att.com
http://www.research.att.com/info/ark
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/01 Raw View
In article <35981CA7.78D7548E@acm.org>, Pete Becker <petebecker@acm.org>
writes
>saroj@bear.com wrote:
>>
>> Now you have only the locale argument. It has been repeated in this
>> group that a compiler can remove the unused virtuals. Even if your
>> compiler does not do this, a library vendor can tell its customers that
>> because of such and such constraints our iostream library supports only
>> one locale or does not support locale stuff.
>
>Yes, that's one of the things that EC++ does.
If it was only that one thing then I think fewer people would be
complaining here though, but it's not =:-(
Other things EC++ does : remove templates (costless), remove namespaces
(costless), remove exceptions (low cost and crucially required if
safety-critical code is to be written), etc, etc
...snip...
>> So just for <iostream>, do you really
>> need a EC++ label for your product? Ultimately, a vendor will succeed
>> by making the customer (programmers') life easy by supplying the
>> whole library (within the resource constraints) and not by claiming
>> compliance with an standard like EC++.
>
>Ultimately, probably.
In the interim the compiler should do the best they can and provide
specific additional libraries where their market segment demands.
>By the time your current project must to be
>finished? Unlikely.
We are stuck with what is available on our current projects anyway. The
issue here is whether the sub-standard (in both senses) EC++ is given a
credence it doesn't deserve, and that allows it get in the way of
efficient full featured C++ implementations.
> Until it happens, standard C++ is simply too big for
>many embedded systems.
Simply nonsense.
--
Mike Davies
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/01 Raw View
In article <359858B9.E5874A3F@acm.org>, Pete Becker <petebecker@acm.org>
writes
>Mike Davies wrote:
>>
>> In article <3596ACC0.A226AA6A@acm.org>, Pete Becker <petebecker@acm.org>
>> writes
>> >
>> >How big an executable did it produce for "Hello, world" using cout? Does
>> >the library include locale facets?
>>
>> Executables using their iostreams library came in at down to around 8k.
>> I don't believe that the version of the library I used has locale facets
>> though.
>
>In other words, they got that size by using the EC++ library spec. <g>
>
I am in the unfortunate position of not having a copy of the Watcom V
11.0 compiler available. I *think* they added locale facets, while
simultaneously implementing optimisations to alleviate the increaes in
code size. Without versions 10.6 and versions 11.0 side by side I can't
test the code size changes for the iostreams implementations. Maybe
somebody else can try this and post some results ?
(The Watcom compiler is excellent IMO, though not the closest to the
standard so far as I've been able to tell).
--
Mike Davies
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/01 Raw View
In article <01bda4ff$e8eb6a80$8a1ec2d0@porky>, "P.J. Plauger"
<pjp@dinkumware.com> writes
...snip...
>> > -- class locale
>> >
>> > -- various locale facets
>> >
>> As I said, if your target system is lacking in resources, then you can
>> support only one locale or, you can say that the minimum resources
>> needed to use this library is so and so.
>> You do not need another standard for marketing your library.
>
>Again you miss the point. (It's an easy one to miss.) It's not the number of
>locales supplied by the vendor that adds to the complexity. Rather, it's the
>*extensibility offered to the programmer* that you can't hide from as an
>implementor. Offer just one prepackaged locale and you conform. Deny the
>programmer the right to add or change facets and you don't conform. Once
>you don't conform, you may as well not conform in style.
Um.. I don't agree with you here, you can conform and provide the
customer with low-cost (memory space costs I mean) extensions as I
believe you already do. The problem with EC++ as a non-conforming
"standard" is that it cuts out lots of other stuff that doesn't have
(perhaps implementation dependent) costs too.
The solution of providing other libraries as well as a C++Standard
conforming one seems to me to be a good interim measure while compiler
technology catches up with the standard.
...snip...
>> > Yup. That's called a nonconforming subset. Do you want to design a
>> > coherent one and call it, say, EC++? Or do you want to just call it Fred?
>> > Either way, *you're no longer implementing full C++ because you can't
>> > afford the overheads*. Call it what you will.
>>
>> The difference is that in the first case, the customer makes the decision
>> (case by case) depending on the availability of resource or portability
>> needs, what to use and what not to.
>
>And on the ability of the compiler and library to indulge their whims.
>Recompile a typical C++ library with exceptions disabled and see what
>happens. (Safety tip: hide behind the sofa.)
That doesn't happen with your extensions does it ? ;-)
>
>> In the second case, a
>group of vendors
>> band together and decide what is easy for them and arbitrarily (just opposite
>> of coherent) decide to standardise a subset and call it EC++ for marketing.
>> Then it becomes a tool in the hands of an incompetent manager - just stick to
>> the limits (arbitrarily) defined by EC++.
>
>Where did that come from? I know from personal experience that the decisions
>were *not* made arbitrarily, nor to make life easy for the vendors. Who are you
>to libel people you don't even know?
This isn't intended as a libel upon *anybody*, but I have seen posts in
this thread whose tenor was very sympathetic to EC++, and which claimed
that the high entry costs of writing a fully standard conforming C++
compiler were the main reason for the creation of EC++.
>> A coherent subset
>will have
>> namespace, templates, exception and rtti (with switch to disable at the
>> customer's option - not yours). All exception throwing functions in a library
>> can call a function (much like a new_handler) to decide whether to throw or
>> not. It will also provide a library with rtti and one without.
>
>You've described Dinkumware's library offerings to a tee, thanks.
It sounds like a good solution to me.
If compiler implementation techniques that can eradicate costs from
features of the full C++ language become widespread (as they will if
they are publicised) then those features will obviously find their way
into all of the libraries supplied by a vendor.
Someone trying to shoehorn a piece of code into a small ROM may be glad
of an expedient regardless of its purity.
However this does not amount to an argument for EC++ as a *standard*.
This is because it is overwhelmingly inadequate for *all* embedded
programmers needs, and as a standard is likely to hold back the
development of full-featured C++ compiler implementations for embedded
use.
The solution you describe above does the opposite IMO, I think it will
lead to full C++ implementations without overheads becoming available
(reasonably) soon, while giving programmers the best compromise pending
other solutions.
--
Mike Davies
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/01 Raw View
In article <6ndime$8fk$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
writes
>In article <3599ae14.5018932@nntp.ix.netcom.com>,
> wkdugan@ix.netcom.com (Bill Dugan) wrote:
...snip...
>> If you go all the way down to machines which support only a few dozen
>> or a few hundred bytes of memory, the statement might be true.
>> However, I'm not familiar with any such which also have C++ or EC++
>> libraries for which
>
>I would expect such machines to be able to support EC++. I agree that
>C++ would be asking a lot.
I've just been working on an assembler project where the machine had 36
bytes of data space and I found some things hard to do that would have
been easy in full C++ (but not EC++).
It is fair to say though that I would not have used iostreams in this
project :-)
--
Mike Davies
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/07/01 Raw View
<jkanze@otelo.ibmmail.com> wrote:
>Many years ago, I did some measures on sort routines. The point where
>quick sort becomes typically better than shell sort was around 100000
>elements.
Using what ratio of compare:swap time? Without such a
specification the crossover point is meaningless.
>> If you go all the way down to machines which support only a few dozen
>> or a few hundred bytes of memory, the statement might be true.
>> However, I'm not familiar with any such which also have C++ or EC++
>> libraries for which
>
>I would expect such machines to be able to support EC++. I agree that
>C++ would be asking a lot.
Try to run any version of iostreams on a machine with a few dozen bytes
of memory. The concept is silly to contemplate. When your memory is
so little you won't consider any library that is also useful on bigger
machines.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/02 Raw View
In article <6n8iu9$iak$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
writes
>In article <9BruECAHojl1Ewy0@noco.demon.co.uk>,
> Mike Davies <mike_davies@noco.demon.co.uk> wrote:
>
>> I have use Watcoms' container classes in embedded applications, and my
>> perceptions of the code (eg in the debugger) were that it was no bigger
>> than any other method of obtaining that functionality would have been.
>> My understanding (I no longer have access to the Watcom compiler to
>> check) is that the STL has been implemented *more* efficiently than
>> this. I would use the STL on an 8-bit micro like a shot, if it were
>> available and if the application required the functionality. I don't
>> suppose I am a better programmer than the person who wrote the STL
>> anyway, so why should my own implementation of the functions be more
>> efficient ?
>
>I've never seen the Watcoms' container classes to compare, but I seriously
>doubt that any of the current STL implementations would run on an 8-bit
>micro. It has nothing to do with the relative competence of the programmer,
>and everything to do with his goals; the goals of the current implementations
>are all to favor speed over space, for example, and they do tend to be
>memory hogs.
>
>In practice, things like requiring amortised constant time for vector::
>push_back will tend to require extra memory.
No, this doesn't help your argument. If you need the functionality of
the STL then you are likely to find that it is the best solution, tight
memory space or not.
I do not say that a vector<T> is the best solution for *every* array-
like container that you may need, but I do say that if you are
implementing continer classes then the STL is the place to look first.
If you try the STL solution and it *really* won't fit (and don't forget
to look up a few optimisation switches first) then this has likely only
cost you a day to find out. If you spend 3 weeks implementing your own
version of b-trees and find the STL implementation is actually smaller
(which I would expect given its quality) then you will look pretty
silly. This goes for 8-bit versions of the STL too, as you will find out
when one becomes available. Sigh.
>James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
Regards
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/07/02 Raw View
Nathan Myers wrote:
>
> P.J. Plauger<pjp@dinkumware.com> wrote:
> >Nathan Myers <ncm@nospam.cantrip.org> wrote:
> >> P.J. wrote:
> >> >The committee at first shied away from templatizing iostreams,
> >> >string, and complex, because of the known inefficiencies introduced
> >> >when you generalize all of these classes.
> >>
> >> That was not why the committee initially shied away from templatizing
> >> iostreams.
> >
> > I was there at the time. You weren't.
>
> This is a false statement.
>
Believe it or not, there actually was a standardization committee before
Nathan started attending. Those of us who were there did discuss library
design questions, and we did so in a reasonably intelligent manner, even
though we didn't have Nathan's help.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: saroj@bear.com
Date: 1998/07/02 Raw View
In article <01bda4ff$e8eb6a80$8a1ec2d0@porky>,
"P.J. Plauger" <pjp@dinkumware.com> wrote:
>
> saroj@bear.com wrote in article <6natcs$t83$1@nnrp1.dejanews.com>...
> > In article <01bda3c9$f9e48920$8a1ec2d0@porky>,
> > As I said, if your target system is lacking in resources, then you can
> > support only one locale or, you can say that the minimum resources
> > needed to use this library is so and so.
> > You do not need another standard for marketing your library.
>
[snipped]
> Offer just one prepackaged locale and you conform. Deny the
> programmer the right to add or change facets and you don't conform. Once
> you don't conform, you may as well not conform in style.
>
Nonsense. Just because you may have to deviate from the standard
in locale and iostream (even that may not be necessary), that does
not mean you will ignore very very important parts of the C++
language - templates, exceptions, namespaces, rtti (to lesser
extent). A modern program written without these features should not
even pretend to be C++ (may be another language). Recently, I posted
a CORBA nameservice implementation using STL and exceptions in
corbadev mailiglist. It implemented the service in half the
number of lines compared to the the best performing(overall) CORBA
implementation - thanks to STL. Now, I am implementing a make program
portable to Unix and Windows and the source code size for identical
functionality as GNU make or BSD make is dramatically smaller. Again
thanks to STL and exceptions.
PJ, take a mid size program; (re)write it using the full C++.
After that rewrite using a C++ subset - 1st option: full C++
minus locales; 2nd option: no template (STL), no exceptions,
no namespace (did somebody say EC++?). See which is harder? It
is not an argument against locales. All I am saying is that the
programmer will be writing to a totally different language without
features like templates, exceptions, but it may be easier to
encapsulate the I/O part in a different module (old iostream vs.
iostream).
> Recompile a typical C++ library with exceptions disabled and see what
> happens. (Safety tip: hide behind the sofa.)
>
I said, that the library will be designed with that in mind -
it will either throw an exception or call a user handler.
> > A coherent subset
will have
> > namespace, templates, exception and rtti (with switch to disable at the
> > customer's option - not yours). All exception throwing functions in a
library
> > can call a function (much like a new_handler) to decide whether to throw or
> > not. It will also provide a library with rtti and one without.
>
[snipped]
> Nice of you to speculate. I've done the work. I assure you that you've only
> seen the tip of the iceberg.
Ignoring templates (low cost and
better than many alternatives) and namespace (zero cost), now I
am talking about exceptions and rtti. Turning rtti on/off is a single
compiler switch. Do you have a better idea than calling user level
handler or throwing an exception in the library depending on a switch?
Is that a great deal of work (beside the normal library work)?
What is the part of the iceberg that I missed? Let us set aside the
iostream argument for a moment. Can EC++ do better than the solution
I proposed :
-lstdcpp_rtti -l[exception_handler|user_handler]
-lstdcpp_no_rtti -l[exception_handler|user_handler] and the
compiler automatically selecting the library for you? If yes, please
tell us how?
Once you agree to these things, now we have locale and iostreams. If
inspite of all the optimizations, it is not possible to fit the
library within an embedded system, now you, together with other people
(many from this newsgroup will also participate) can sitdown together
and solve the real problems faced by the implementors or even suggest
a embedded iostream library. EC++ is a totally different story.
>
> > And I always
thought you
> > are a great programmer.
>
> Thanks, I think.
>
Yes, you are very talented. You can contribute your expertise and also
work with other experts here to improve C++ implementation techniques
and decide on the engineering compromises needed for embedded systems
in a democratic and open process.
This is also a plea to everybody. Please let us stop this thread and
instead discuss the implementation techniques and typical embedded
system configurations and what can be be the right compromises.
Cheers,
Saroj Mahapatra
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "David J. Littleboy" <davidjl@gol.com>
Date: 1998/07/02 Raw View
Mike Davies wrote in message ...
>This isn't intended as a libel upon *anybody*, but I have seen posts in
>this thread whose tenor was very sympathetic to EC++, and which claimed
>that the high entry costs of writing a fully standard conforming C++
>compiler were the main reason for the creation of EC++.
It seems that you have misunderstood my remarks about
microcontroller manufacturers and applied them to C++ compiler vendors,
which was _never_ my intention. Maybe I overstated my case and a better
statement would be "the simplicity of EC++ provides some added niceties for
manpower and financial resource limited microcontroller manufacturers." I
was _never_ referring to compiler vendors only to microcontroller hardware
development groups (who provide
development envs for their products). Also, I was trying to explain that the
"cost of entry" for such a group includes the long term cost of supporting
their customers who try to develop applications for those microcontrollers.
One reason you may have misunderstood my comments is that I'm largely
referring to Japanese electronics companies with fab lines and
in-house designed microcontrollers. I don't know anything about development
on Intel, IBM, and Motorola microcontrollers, but I've translated a lot of
manuals for microcontrollers from companies most people associate with
stereos and home appliances. (There are even Japanese steel companies and
shipbuilders who have diversified into semiconductors, but I don't know if
they make microcontrollers.)
Interestingly, the EC++ committee is far heavier on the "usual players" than
the smaller folks who I end up working for. Still, EC++ seems to speak to
the needs of a group that I have personal experience with. I suspect that
your experience in embedded development is very different from what happens
at my customers' customers.
As a relative newcomer to C++, I'm impressed by the depth, scope, and
difficulty of the language. It is clear to me that C++ is a much more
difficult language to support than C was. So I have _lots_ of sympathy
for managers who are faced with supporting such a language.
David J. Littleboy <davidjl@gol.nonspam.com>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/07/02 Raw View
Mike Davies wrote:
>
>
> This is true, but the practical code overhead for including exceptions
> is about 5-10 % (in my experience). Given that almost every embedded
> project I have worked on has had an entry in the requirement spec
> insisting upon a minimum of 50% spare code space for future development
> then this doesn't look so bad.
>
On the contrary: if you're at the 50% limit you can't afford to add
5-10%. The fact that the extra memory is supposed to be there doesn't
mean you can use it. If you do you're violating the system's
requirements.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: tony@ns.cook.ml.org (Tony Cook)
Date: 1998/07/02 Raw View
Mike Davies (mike_davies@noco.demon.co.uk) wrote:
: I am in the unfortunate position of not having a copy of the Watcom V
: 11.0 compiler available. I *think* they added locale facets, while
: simultaneously implementing optimisations to alleviate the increaes in
: code size. Without versions 10.6 and versions 11.0 side by side I can't
: test the code size changes for the iostreams implementations. Maybe
: somebody else can try this and post some results ?
: (The Watcom compiler is excellent IMO, though not the closest to the
: standard so far as I've been able to tell).
Unfortunately Watcom 11.0 doesn't implement the standard library: it
may have the virtual function removal option, but it doesn't have all
of the language support required for the standard library. The main
lack is in template support - no new template syntax, no typename, no
default template parameters, basically ARM level template support (it
has namespaces, bool, mutable, explicit, exceptions, RTTI, new style
casts all as language features with minimum library support). The std
namespace is not used.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/07/02 Raw View
saroj@bear.com wrote:
>
> "P.J. Plauger" <pjp@dinkumware.com> wrote:
>
> > Recompile a typical C++ library with exceptions disabled and see what
> > happens. (Safety tip: hide behind the sofa.)
> >
> I said, that the library will be designed with that in mind -
> it will either throw an exception or call a user handler.
What is the signature of that user handler? What does the library
require it to do? Or, more generally, what should a progammer who uses
such a library do in order to insure maximal code portability?
The issue is not whether various library vendors can dream up ad hoc
solutions to particular problems. The problem is deciding what library
users can expect and rely on. If every library vendor provides a
different workaround when exceptions are disabled it will be a disaster
for programmers who want to write portable code.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/29 Raw View
saroj@bear.com wrote:
>
> Now you have only the locale argument. It has been repeated in this
> group that a compiler can remove the unused virtuals. Even if your
> compiler does not do this, a library vendor can tell its customers that
> because of such and such constraints our iostream library supports only
> one locale or does not support locale stuff.
Yes, that's one of the things that EC++ does.
> There are even systems,
> where you can not use stdio.h.
If you're talking C here, those are standalone systems, not hosted
systems. Most of the rules don't apply when you're on a standalone
system, and you pay the price in not being able to easily port code from
other systems.
> So just for <iostream>, do you really
> need a EC++ label for your product? Ultimately, a vendor will succeed
> by making the customer (programmers') life easy by supplying the
> whole library (within the resource constraints) and not by claiming
> compliance with an standard like EC++.
Ultimately, probably. By the time your current project must to be
finished? Unlikely. Until it happens, standard C++ is simply too big for
many embedded systems.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1998/06/29 Raw View
In article <3595a40b.4991047@nntp.ix.netcom.com>,
wkdugan@ix.netcom.com says...
[ ... ]
> How many implementors actually make such guarantees? How could they?
> Neither the compiler nor the library implementor know how much memory
> is available on the machine where the program will run, so they don't
> know what the largest possible collection will be.
There are quite a few machines where the basic architecture can only
address 64K of memory. If a machine can only address 64K of memory, I
have a hard time seeing how it could support collections greater than
65536 elements. Furthermore, in many cases the address space is
divided up -- one section will always be ROM, leaving an even smaller
portion in which you could store a collection.
> If the possible targets include machines with so little memory that a
> linear search will always be optimal, it's not practical to carry around
> the machinery to make that decision at run time, and the programmer is
> the only one who might have enough information to make it earlier.
I was speaking mostly (if not entirely) of machines small enough that
there's no need for a decision at run-time; the basic architecture of
the machine would allow the decision to be made ahead of time.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Ross Smith" <ross.s@ihug.co.nz>
Date: 1998/06/30 Raw View
Jerry Coffin wrote ...
>
>Well, technically, you don't even need to get into defining
>"approximately" -- the standard says things like "N Log N", but
>doesn't define the base of the logarithm. By choosing the appropriate
>base for the logarithm, you can more or less pick arbitrary numbers
>and make them fit...
I'm afraid not. Logs to different bases differ only by a constant
factor. In terms if big-O notation, which ignores constant factors, any
expression involving "log N" represents the same complexity regardless
of what the base of logs is.
--
Ross Smith ................................... mailto:ross.s@ihug.co.nz
.............. The Internet Group, Auckland, New Zealand ..............
"Remember when we told you there was no future? Well, this is it."
-- Blank Reg
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/06/30 Raw View
saroj@bear.com wrote in article <6n8cb4$a7f$1@nnrp1.dejanews.com>...
> In article <3596ACC0.A226AA6A@acm.org>,
> I have always heard how big the cout << "hello world" program is.
> Can you say that iostream template is the cause of this? Definitely not.
I assume this is a rhetorical question, since you answered it for all of us.
Too bad you're wrong. Templatized iostreams are at least part of the
problem, if not all of it.
> If at all, it can only reduce the code size, because the standard
> requires that if some non-inline template members are not used,
> then they should not be instantiated.
And if some non-inline non-template members are not used, then
linkers don't include them. A wash here.
> So even without the linker support,
> your code size is smaller.
Not necessarily. You seem to take for granted that the templatized code
is essentially the same as the non-templatized code, which is far from
the case. The committee at first shied away from templatizing iostreams,
string, and complex, because of the known inefficiencies introduced when
you generalize all of these classes. To make templates out of these
creatures, the committee added:
-- template class char_traits
-- template class istreambuf_iterator
-- class locale
-- various locale facets
-- nested class sentry
All of these things add mass not present in traditional iostreams, *even
if you optimize away unused virtuals*.
> Now you have only the locale argument.
Well, no. I still have several others.
> It has been repeated in this
> group that a compiler can remove the unused virtuals.
One or two evidently can. Most don't.
> Even if your
> compiler does not do this, a library vendor can tell its customers that
> because of such and such constraints our iostream library supports only
> one locale or does not support locale stuff.
Yup. That's called a nonconforming subset. Do you want to design a
coherent one and call it, say, EC++? Or do you want to just call it Fred?
Either way, *you're no longer implementing full C++ because you can't
afford the overheads*. Call it what you will.
> There are even systems,
> where you can not use stdio.h.
True. Once you consider such a wide range of subsets, you give up on
any possibility of writing code that's portable across different compiler
implementations. A clearly identified, efficient subset offers more promise.
> So just for <iostream>, do you really
> need a EC++ label for your product?
No. You also need it for string and complex, as I mentioned above. And
you need it to ensure that you have a library that can survive the elimination
of RTTI, multiple inheritance, exceptions, etc. The label itself provides some
assurance of coherence and portability, as I also mentioned above.
> Ultimately, a vendor will succeed
> by making the customer (programmers') life easy by supplying the
> whole library (within the resource constraints) and not by claiming
> compliance with an standard like EC++.
Now wait. What's ``a whole library (within the resource constraints)''?
Is that a subset in disguise or not?
> Please do not underestimate the
> intelligence of your customers - they will see through it.
Yeah. Particularly when you tell `em you're giving them just a full
implementation of C++, at whatever cost, for their own good.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/30 Raw View
Mike Davies wrote:
>
>
> My point was that the existance a compiler that can produce a zero
> overhead implementation of a feature of C++ reduces the strength of the
> argument for the EC++ subset of C++ on the basis of the putative
> efficiency gain, since it is possible to obtain this gain without having
> the cut down version of the language.
I have asked a couple times, and ask again: has anyone compiled "Hello,
world" with one of these compilers that allegedly produces zero
overhead? Using, of course, the full C++ library, including locales. How
big is it?
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/30 Raw View
Mike Davies wrote:
>
> In article <3596ACC0.A226AA6A@acm.org>, Pete Becker <petebecker@acm.org>
> writes
> >
> >How big an executable did it produce for "Hello, world" using cout? Does
> >the library include locale facets?
>
> Executables using their iostreams library came in at down to around 8k.
> I don't believe that the version of the library I used has locale facets
> though.
In other words, they got that size by using the EC++ library spec. <g>
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/30 Raw View
Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
>Ok, let's make a next try: Define EC++ as full C++ compiler with
>the option to turn costly features off, and a std library with
>certain standardized extensions to avoid common overhead.
Sorry, you don't get to define EC++. EC++ has been defined already
by a self-selected consortium, and it stinks. If you want to define
something else, give it a different name so we know what you're
talking about.
>> The standard doesn't say that you're not allowed to help your compiler
>> optimize your program. In fact, specifying various compiler flags
>> for various purposes (optimization, debugging, profiling, test coverage)
>> is familiar to us all.
>
>Then why are people so obviously against this idea, if it is
>connected with the name "EC++"?
Why? Because that's not what EC++ is. EC++ is described by a
(readily-obtained) document. What that document describes sounds
nothing like what you say you want.
If you are arguing for better compiler support for embedded-system
programmers, then we are in total agreement. If you are arguing
for EC++, then we are in total disagreement.
>... if you want to avoid exception overhead, you must either use a
>non-portable extension, program your own string class or not use
>strings at all. Better would be a standardized way to do it.
>Standardizing a way needs, of course, a standard.
>
>This standard could be the EC++ standard, since in embedded programming
>the memory overhead is important.
"This standard" could *not* be the EC++ standard, because EC++ is
already defined as something very, very different.
>> A good compiler for embedded-system programmers would be one which
>> implements language features efficiently, not one that does them
>> badly (if at all) and with a switch to turn them off. It's a shame
>> that vendors of the latter have absconded with the "EC++" label, so
>> that anyone who makes the former must invent a different name.
>
>And a good library for embedded programmers would be ...
... a set of extensions to the standard, not an incompatible subset
defined primarily for the convenience of certain compiler vendors.
The former has no name yet, but the latter is (definitively) EC++.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/30 Raw View
David J. Littleboy<davidjl@gol.com> wrote:
>... STL seems to force one into a "value semantics" approach, which
>seems to me to be potentially problematic in memory constrained situations
>(although one can, of course, use STL to contain pointers, but that seems to
>defeat the whole point of STL.)
STL works fine with pointers. I don't know why you suggest it "defeats
the point". It also works fine with intrusive containers.
>Remember, the people who are interested in EC++ aren't Intel, IBM,
>Motorola, and Hitachi. They are XXX, YYY, and ZZZ, and Fujiyama Denki,
>and a couple of steel companies that diversified into semiconductors.
>The folks at gnu don't have time to port to every microcontroller around.
The folks at GNU (properly, FSF) have time for little more than
maintaining the copyright registry. The folks at Cygnus, who do
the bulk of gcc ports, have as much time as you are willing to buy.
A substantial part of their business, in fact, is in porting gcc
to "every microcontroller around", particularly including (as it
happens) those produced by Japanese companies large and small.
>... I've been fairly careful (some of the time)
>to qualify my comments with "certain segments of the embedded area",
>meaning the companies that can't expect RMS and/or Microsoft to do their
>homework for them.
Again, RMS has little to do with this. It is manifestly the case that
makers of microcontrollers *do* purchase the attention of compiler
vendors.
>The anti-EC++ crowd here would like people to design their own subset.
I don't know where you ever got such an idea. _Every_ program uses
some subset of the language. Does this mean every program represents
its programmer's "design of his own subset"? Of course not.
Designing non-standard language subsets is a fool's game.
>There wouldn't be such a brouhaha over the size of the standard library
>if it weren't for EC++.
This is obviously false.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/30 Raw View
P.J. Plauger<pjp@dinkumware.com> wrote:
>The committee at first shied away from templatizing iostreams,
>string, and complex, because of the known inefficiencies introduced when
>you generalize all of these classes.
That was not why the committee initially shied away from templatizing
iostreams. The effort to specify all the changes was recognized
(correctly) as large. The necessity for the change was substantially
due to requirements by the Japanese delegation, which was (reasonably)
concerned about support for their language.
I don't recall hearing anybody mention expecting inefficiencies, "known"
or otherwise. In fact, it was fully expected among the people I worked
with that the templatization would *not* add inefficiencies to the "char"
case, and in a well-implemented library it should not.
> To make templates out of these creatures, the committee added:
>-- template class char_traits
>-- template class istreambuf_iterator
>-- class locale
>-- various locale facets
>-- nested class sentry
>All of these things add mass not present in traditional iostreams, *even
>if you optimize away unused virtuals*.
-- The template char_traits<> adds no overhead at runtime.
-- The template istreambuf_iterator need add no overhead at runtime for
the common case.
-- Nested class sentry" is just an inline class wrapper for the existing
ipfx() and opfx() functions, and adds no overhead.
-- The class locale and facets need add no overhead if they are not used.
PJ's presentation above conflates facilities that only affect the
compiler at compile-time with others that involve code that executes
at runtime. While "mass" is left undefined, it is treated as equivalent
to "runtime overhead", which is clearly false for most of examples
quoted, and questionable for the rest.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/06/30 Raw View
Nathan Myers <ncm@nospam.cantrip.org> wrote in article <6na54v$qa0$1@shell7.ba.best.com>...
> P.J. Plauger<pjp@dinkumware.com> wrote:
> >The committee at first shied away from templatizing iostreams,
> >string, and complex, because of the known inefficiencies introduced when
> >you generalize all of these classes.
>
> That was not why the committee initially shied away from templatizing
> iostreams.
I was there at the time. You weren't.
> I don't recall hearing anybody mention expecting inefficiencies, "known"
> or otherwise. In fact, it was fully expected among the people I worked
> with that the templatization would *not* add inefficiencies to the "char"
> case, and in a well-implemented library it should not.
We ate lunch at different tables.
> -- The template char_traits<> adds no overhead at runtime.
I disagree.
> -- The template istreambuf_iterator need add no overhead at runtime for
> the common case.
I disagree.
> -- Nested class sentry" is just an inline class wrapper for the existing
> ipfx() and opfx() functions, and adds no overhead.
I disagree.
> -- The class locale and facets need add no overhead if they are not used.
I disagree. It is also essentially impossible not to use them.
> PJ's presentation above conflates facilities that only affect the
> compiler at compile-time with others that involve code that executes
> at runtime. While "mass" is left undefined, it is treated as equivalent
> to "runtime overhead", which is clearly false for most of examples
> quoted, and questionable for the rest.
I did indeed use mass to mean runtime overhead.
I have been writing libraries for a third of a century. I have been writing C
libraries since 1975. I have written a C++ library that has matched every
draft of the C++ Standard since March 1993 (over a dozen of 'em). I have
written the only commercial EC++ library and tracked it through three
drafts of the C++ Standard. In short, I speak from experience. I do not,
however, pretend to know everything.
I began this (sub)thread in response to a request for detailed reasons
why the Standard C++ library might benefit from subsetting. I did so
asking for guidance where I didn't know how to perform optimizations
that others insist are state of the art. It doesn't help to be told flatly
that overheads don't exist when I've seen them with my own eyes.
None of the ones listed above are large in their own right. I don't even
try to eliminate some of them from EC++. They are nevertheless
present and their cumulative effect on the size of the Standard C++
library is very real.
The bottom line is still that the Standard C++ library *can* be made
dramatically smaller by judicious subsetting. Clever optimizations
alone, while they certainly help, are not enough. Show me more
optimizations that we can apply and Dinkumware will apply them
to our product line. We'll even report whether they materially help.
But we will also continue to offer efficient subsets to our customers
as long as those subsets meet a real need.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/06/30 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> wrote in article <JfrDDKAHe9l1EwVg@noco.demon.co.uk>...
> My point was that the existance a compiler that can produce a zero
> overhead implementation of a feature of C++ reduces the strength of the
> argument for the EC++ subset of C++ on the basis of the putative
> efficiency gain, since it is possible to obtain this gain without having
> the cut down version of the language.
Agreed -- to the extent that better optimizations can close the gap, the
need for EC++ is weakened. My point was that the widespread absence
of an optimization today creates a gap that may well take years to close.
I also observe yet again that we're not merely a few optimizations away
from closing the gap. I'm personally not yet convinced, as an implementor,
that we can ever close the performance gap between full C++ and the
EC++ subset by optimizations alone. I think we'll always have to turn off
(conditionally omit) library support for certain features, such as locales.
> If a compiler vendor is deciding between investing in a cut-down version
> of their library or an improvement in the quality of their compiler then
> they now know what the competition can do. They are able to make the
> decision that is IMO most in the interests of their customers and
> improve their compiler implementation.
Agreed again -- to the extent that an optimization helps all users, it is a
better investment of implementor energies than making a subset. But what
if optimization is not enough?
> >We give the programmer the choice of coherent libraries -- EC++, abridged
> >(EC++ plus STL), and full C++ -- all configurable for use with or without
> >exceptions in the language. We also give the compiler vendor a gazillion
> >other options to tailor the libraries to any limitations of the compiler or
> >underlying C library. The programmer can judge which of these libraries,
> >and which compatible compiler options, give an acceptable cost for a
> >given job. It ain't a Chinese menu, but it does offer quite a range of
> >entrees.
>
> Sounds good to me, do you do free home deliverys ? :-)
Well, yes, via the internet.
> OK. One further argument against EC++ :
>
> Any realistic implementation of C++ / C with classes would contain EC++
> anyway, so why the need for the standard ?
Any realistic implementation contains the *functionality* of EC++. But you
get the *efficiencies* of EC++ only by structuring the subset library very
carefully:
a) eliminating expensive library features that are less important in an
embedded environment (such as locales)
b) eliminating library dependency on language features that can be
expensive in their own right (such as exceptions)
You design to a common specification (standard is an emotionally charged
term) to ensure that the library has a coherent set of tradeoffs, and that it
will look very much the same across cooperating vendors.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/06/30 Raw View
In article <b$HHLBA1O9l1EwU2@noco.demon.co.uk>,
Mike Davies <mike_davies@noco.demon.co.uk> wrote:
>
> In article <6n8g2i$eo3$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
> writes
>
> ...snip...
>
> >They may not know the actual ammount of memory, but they do know the
> >maximum. If the processor has 16 address bits, you really don't have
> >to worry about what happens with more than 64K elements. And of course,
> >a lot of processors have even less.
>
> External page registers excepted of course.
Not really. Without some very special logic, you can't have objects
(vectors, etc.) spanning several pages. So the problem of an object
containing more than 64K elements doesn't occur.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientee objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: saroj@bear.com
Date: 1998/07/01 Raw View
In article <01bda3c9$f9e48920$8a1ec2d0@porky>,
"P.J. Plauger" <pjp@dinkumware.com> wrote:
>
> saroj@bear.com wrote in article <6n8cb4$a7f$1@nnrp1.dejanews.com>...
[snipped]
> > So even without the linker support,
> > your code size is smaller.
>
> Not necessarily. You seem to take for granted that the templatized code
> is essentially the same as the non-templatized code, which is far from
> the case.
On my Sun compiler, it is the same. The instantiated functions are put into
separate files in a repository and compiled like normal code (automatically
by the compiler). If VC++ compiler is not smart about instantiating only the
needed functions and having identical code size for the instantiated
functions, then expect it to improve soon or complain to the vendor.
> The committee at first shied away from templatizing iostreams,
> string, and complex, because of the known inefficiencies introduced when
> you generalize all of these classes. To make templates out of these
> creatures, the committee added:
>
> -- template class char_traits
>
Again, on my Sun compiler, inline template functions do not even appear
in the template repository. Absolutely no difference from calling strlen
or memcmp directly (in generated code). char_traits<char> has only inline
stuff.
> -- template class istreambuf_iterator
See above.
>
> -- class locale
>
> -- various locale facets
>
As I said, if your target system is lacking in resources, then you can
support only one locale or, you can say that the minimum resources
needed to use this library is so and so.
You do not need another standard for marketing your library.
> -- nested class sentry
>
A nested class is only lexical scoping. It can not add any overhead
compared to an identical function (ipfx or others).
[snipped]
>
> > It has been repeated in this
> > group that a compiler can remove the unused virtuals.
>
> One or two evidently can. Most don't.
>
If the customers find the compiler inadequate, they will throw it out
of the market place. They can evidently make better decisions on how
to reward (or punish) the vendors.
> > Even if your
> > compiler does not do this, a library vendor can tell its customers that
> > because of such and such constraints our iostream library supports only
> > one locale or does not support locale stuff.
>
> Yup. That's called a nonconforming subset. Do you want to design a
> coherent one and call it, say, EC++? Or do you want to just call it Fred?
> Either way, *you're no longer implementing full C++ because you can't
> afford the overheads*. Call it what you will.
>
The difference is that in the first case, the customer makes the decision
(case by case) depending on the availability of resource or portability
needs, what to use and what not to. In the second case, a group of vendors
band together and decide what is easy for them and arbitrarily (just opposite
of coherent) decide to standardise a subset and call it EC++ for marketing.
Then it becomes a tool in the hands of an incompetent manager - just stick to
the limits (arbitrarily) defined by EC++. A coherent subset will have
namespace, templates, exception and rtti (with switch to disable at the
customer's option - not yours). All exception throwing functions in a library
can call a function (much like a new_handler) to decide whether to throw or
not. It will also provide a library with rtti and one without.
Now, the link order will be something like
-lstdcpp_rtti -l[except_handler|null_except_handler]
-lstdcpp_no_rtti -l[except_handler|null_except_handler]
This is no different from vendors shipping single threaded and multi threaded
libraries for years. In fact, it is a lot easier than multithreading issues,
you simply compile your library with/without rtti and throw exceptions/call
user_handler. Probably, it is even simpler than writing a shared library vs.
archive in MS platforms, where you either litter your code with import/export
statements or write a tool using Perl or something to create a DEF file.
It is more comparable to creating a UNIX shared library (a single switch).
Even the compiler can automatically link in the right library
(much like -mt pulls in the reentrant libraries and the thread library)
automatically. When you say one size does not fit all, I agree with you
and a good programmer will do exactly like this. And I always thought you
are a great programmer.
> A clearly identified, efficient subset offers more promise.
Sure. See above, all the examples I presented above are subsets. It is well
identified, coherent, efficient and the programmer makes the decisions.
Cheers,
Saroj Mahapatra
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <david.tribble@noSPAM.central.beasys.com>
Date: 1998/07/01 Raw View
P.J. Plauger wrote:
> ...
> In fact, a dirty little secret among us standards
> hacks is that many customers *never* run their compilers in strict
> conformance mode. That mode is a device supplied by the compiler
> vendors so they can promise conformance with a straight face, but
> remarkably few people are the purists we'd like them to be about
> using it.
Indeed, if you turn on "ANSI compliant mode" for MS-VC++ (5.0),
it effectively disables all of the Win32 API functions. Other
Unix compilers do similar things, effectively disabling the POSIX
O/S library calls. They will still compile "conforming" code, but
it's effectively useless for programs that actually want to interact
with the O/S. Which is usually the case for most programs, right?
> We need to be very careful about what we mean when we use the
> terms subset, optimizations, compiler switches, and conformance
> all in the same breath.
Yes. If you write a "conforming" program that doesn't use
templates, for instance, you should be able to compile it (and
run it!) with a compiler that supports standard C++ minus
templates. That would be a pretty clear definition of "subset".
If the standard library internally uses some template features,
though, the linker portion of the implementation can't be said
to be a proper subset. And the same is true if your code
compiles into an object module that yanks in template features.
On the other hand, if the compiler, linker, and library can
operate AS IF templates really do not exist, then that would
be a convincing argument for calling them a "subset" implementation.
-- David R. Tribble, dtribble@technologist.com --
-- C++, the PL/1 of the 90s.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: wkdugan@ix.netcom.com (Bill Dugan)
Date: 1998/07/01 Raw View
On 29 Jun 1998 16:56:53 GMT, jkanze@otelo.ibmmail.com wrote:
>In article <3595a40b.4991047@nntp.ix.netcom.com>,
> wkdugan@ix.netcom.com (Bill Dugan) wrote:
>>
>> On 27 Jun 98 11:37:09 GMT, jcoffin@taeus.com (Jerry Coffin) wrote:
snip
>> >Why? The implementor has already done exhaustive testing and proven
>> >that for the largest possible collection on this machine, that a
>> >linear search will _always_ be faster than a tree based lookup.
>>
>> How many implementors actually make such guarantees? How could they?
>> Neither the compiler nor the library implementor know how much memory
>> is available on the machine where the program will run, so they don't
>> know what the largest possible collection will be.
>
>They may not know the actual ammount of memory, but they do know the
>maximum. If the processor has 16 address bits, you really don't have
>to worry about what happens with more than 64K elements. And of course,
>a lot of processors have even less.
64K is already past the point where
>>>a linear search will _always_ be faster than a tree based lookup.
Many of the classical algorithms were developed in the days when most
machines had no more than 64K, because linear search wasn't always
faster on such machines.
If you go all the way down to machines which support only a few dozen
or a few hundred bytes of memory, the statement might be true.
However, I'm not familiar with any such which also have C++ or EC++
libraries for which
>>>The implementor has already done exhaustive testing
etc.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: loewis@informatik.hu-berlin.de (Martin v. Loewis)
Date: 1998/07/01 Raw View
"P.J. Plauger" <pjp@dinkumware.com> writes:
> I agree -- almost. I just don't know how to ensure that they are defined, and
> initialized, before they are referenced in a static constructor; but to generate
> no additional references to them unless someone else references them first.
The requirements aren't that strict, are they? A static constructor
can't rely on cout, etc, unless it knows that a basic_ios::Init has
been constructed before ([lib.iostream.objects]/2).
So the problem is really in the implementation of basic_ios::Init,
which needs to initialize everything that is used.
> So far, I haven't figured out how to avoid executable code in the initializers
> for the iostreams objects.
It certainly depends on your compiler technology. If your system
supports weak references (such as GNU/ELF), you could use the
following approach:
...::Init()
{
__init_cin();
__init_cout();
...
}
void __init_cin() __attribute__((weak)){}
...
Then, the object file containing the cin definition would also define
__init_cin, which would override the empty implementation. So in
effect, you call the real initialization only if the object you want
to initialize is also linked.
Regards,
Martin
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/01 Raw View
In article <35975D31.2AA0FE1A@physik.tu-muenchen.de>, Christopher
Eltschka <celtschk@physik.tu-muenchen.de> writes
...snip..
>> But this assumes that horrendous overhead for support of exceptions is
>> the norm. Exception support need not add any more overhead than the
>> apparatus to check return results, and in mature compilers it won't.
>
>The point is that error handling code is written by you, and
>therefore you can decide for each case if it is needed (simple
>example, if your program contains sqrt(M_PI), you'll never even
>think about checking if sqrt succeeded). However, exception code
>is produced by the compiler, who in general will not be able to do
>as detailed analysis as you'll do. So it'll put that code in
>where *you* wouldn't do that. While this can be done in a way that
>doesn't affect execution speed at all (since the error never happens,
>only normal path matters), it will affect code size.
>
This is true, but the practical code overhead for including exceptions
is about 5-10 % (in my experience). Given that almost every embedded
project I have worked on has had an entry in the requirement spec
insisting upon a minimum of 50% spare code space for future development
then this doesn't look so bad.
Of course if you're down to your last 3 bytes of ROM then you may like
to leave exceptions switched out on this project :-)
...snip...
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/28 Raw View
In article <6mrnj2$a0f$1@shell7.ba.best.com>, Nathan Myers
<ncm@nospam.cantrip.org> writes
>Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
>>
>>Well, maybe the best definition for a good EC++ standard would be:
>>A *full* C++ implementation which *additionally* has the option to
>>turn certain costy features (like EH and RTTI) off, and has the EC++
>>standard library in addition to the C++ standard library. This would
>>satisfy all people, I think.
>
>No, that's just another expedient. What would satisfy is efficient
>compilers and libraries that don't impose overhead for unused features.
>There are plenty of excuses for not providing that, but to standardize
>such excuses is madness.
>
>"You must bring your homework, *unless* the dog ate it."
>
It is of course *crucial* not to *standardise* any expedient. Otherwise
it is too likely (IMO) that the defined subset will hang around forever,
to the disadvantage of the embedded programmer.
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/28 Raw View
In article <35924B9D.EEFC43F3@acm.org>, Pete Becker <petebecker@acm.org>
writes
>Nathan Myers wrote:
>>
>>
>> No, that's just another expedient. What would satisfy is efficient
>> compilers and libraries that don't impose overhead for unused features.
>> There are plenty of excuses for not providing that, but to standardize
>> such excuses is madness.
>
>It would be wonderful if we all lived in Lake Wobegon, where all the men
>are strong, all the women are good looking, all the children are above
>average, and all the C++ compilers and libraries don't impose overhead
>for unused features. Most of us don't live there, though. Insisting that
>everyone should live in that fantasy world is madness.
EC++ standardisation is a trade-off between portability and code
generation costs.
If a team of embedded programmers are designing a project to be portable
from scratch then they only have to look at the compilers they actually
intend to use, and write code for the common subset of the full C++
language that siuts the specific application/compiler implementations at
hand. This will to be a bigger subset of C++ than EC++ in any practical
case, any this will have the ensuing benefits for them.
It is rare for code to unexpectedly have to be ported from one CPU to
another in the deeply embedded world, though obviously it does happen .
In this case the costs of implementing the SW changes have to be weighed
together with the other (eg hardware) costs to be meaningful, together
with the initial costs involved in writing the code which can be much
reduced by, for example, the use of templates, exceptions, namespaces
etc,etc.
Having a fuller implementation of the language for the new target cpu
will reduce the costs in the areas that these features can be used, and
this will offset to some extend any additional work required re-writing
parts of the code that relied upon language features not provided by the
new target compiler. If this is some way down the line from the initial
code generation then hopefully the new target compiler will be a better,
fuller implementation of the full C++ spec in any case :-)
There is nothing to stop people writing code for a language subset, if
that is what suits their requirements. It is a bad idea IMO to have a
language subset as a *standard* though as it will have the effect of
promulgating bad SW design. This is because you need the full standard
C++ to do OO design. You do not necessarily need it for every project /
source code file, but you need it in the end for something.
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/28 Raw View
In article <35926585.700E5FC4@physik.tu-muenchen.de>, Christopher
Eltschka <celtschk@physik.tu-muenchen.de> writes
...snip...
>What makes exceptions different from most other features is that
>it affects the global program. *Any* code must be compiled with
>exceptions "in mind", even if it contains no exception specific
>code. Only if you can see the whole program at once, you can
>decide if it uses exceptions.
This is very common for embedded programs, of course, which are often
small enough to allow the whole library to be compiled and linked at the
same time as the application. Assuming the source code is available to
the programmer.
>And exceptions can't come in free,
>since they provide functionality. There are implementations with
>no overhead at no-throw path, but all the information *must* be
>there for the case someone throws.
>
>However, even if there once exists a no-overhead-for-unused-features
>compiler, you'll still need an EC++ library to "unuse" those
>features *without* abandoning useful parts of the library that
>just happen to use those features per std definition, but could
>be defined not using them with little or no efford.
Well, no, you could supply a more modular library with your compiler as
Wind River do.
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1998/06/28 Raw View
ncm@nospam.cantrip.org (Nathan Myers) writes:
|> David R Tribble <david.tribble@noSPAM.central.beasys.com> wrote:
|> >
|> >C++, the PL/1 of the 90s.
|>
|> There were no free, portable PL/1 compilers.
|> There are at least two free, portable full C++ compilers.
Which is, I think, irrelevant to his point.
More relevant would be the fact that all of the features in C++ are
useful to some significant group of programmers -- even the ones which
aren't immediately useful to me. I'm not sure that this was the case of
PL/1.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/28 Raw View
In article <%7ak1.474$0T2.11587818@mothra.gol.ad.jp>, "David J.
Littleboy" <davidjl@gol.com> writes
...snip...
>My axe to grind is cost of entry. My (translation) customers look pretty
>stressed just providing C, so I'm sympathetic to the idea of keeping it
>simple.
What is to stop them banding together to implement a scheduler for the
egcs compiler that is optimised for 8-bit microcontrollers with seperate
instruction/data area architectures ?
It seems to me that this would be a cheaper alternative to standardising
a language subset, and then providing seperate implementations. It would
also have the advantage that ongoing work for egcs would automatically
enhance the support for a particular microcontroller.
Hitachi have followed the gnu/egcs route and this been very much in
their interests IMO.
IBM have had no problems putting their HAIFA scheduler into the public
domain, why shouldn't a group of micro / compiler vendors do the same ?
If the objective is to help reduce their cost of entry, as you suggest,
then this seems to me to be a way forward
...snip...
>David J. Littleboy <davidjl@gol.nonspam.com>
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1998/06/28 Raw View
Valentin Bonnard <bonnardv@pratique.fr> writes:
|> <jkanze@otelo.ibmmail.com> writes:
|>
|> > Exceptions also introduce unexpected program flow in your program.
|>
|> Exceptions introduce syntax-free program flow in your program,
|> granted.
|>
|> Now is it a problem ? If you want to understand a function w/o
|> getting lost in the error handling, it is actually an advantage.
|> If you want to prove the correctness of error handling code,
|> you are arguing that it's a problem. (Correct me if I am wrong.)
Sort of. Although IMHO, most of the error handling is, or should be, an
intrinsic part of the function, not something "added on". So there is
no such thing as understanding a function without understanding its
error handling, or more correctly, its clean-up in the case of error
propagation. (Strictly speaking, error handling takes place in the
final catch block; anything before is error propagation.)
But I think my statement above is more a case of simply changing the
accent, rather than contradicting what you say. And I'm gradually
coming to the opinion that you can write robust code with exceptions;
after all, at another level, data base programmers have been doing it
for years (where exception == system crash, which also modifies program
flow -- rather brutally, in fact). But I've yet to see the problem
treated in a rigorous mathematical fashion.
|> Perhaps what is needed are 'reading levels' ? You read the code
|> at the no exceptions level, the what appens if xxx level, the
|> prove everything level... (you could _perhaps_ model a reading
|> level as an abstraction function (don't know, just an idea from
|> the top of my head [1]))
|>
|> At a simple reading level, you want to keep things simple. At
|> a finer level, you want to know more details.
|>
|> Example: a math function. First you want to prove that the
|> function computes the correct number in IR (or IN, IQ...)
|> Then, at a finer level you want to check the approximation
|> made by float/double/long double.
|>
|> What do you think about that ?
Interesting, but I'm not sure. For example, the techniques (and proofs)
used in numerical analysis ARE radically different from those used in
"pure" mathematics. Sometimes, this approach might work, but what
happens if, when checking at the finer level, the check fails? You may
be forced to use a different algorithm; more importantly, the algorithm
you finally do use may fail at the higher level (but you can prove that
the error due to the failure is less than the desired precision).
|> [1] the idea of the relation between abstract interpretation
|> and reading levels may be completly silly, it's late, I am
|> not sure...
I don't think it's silly, and it is probably worth pursuing. At least
with regards to exceptions.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/29 Raw View
P.J. Plauger<pjp@dinkumware.com> wrote:
>saroj@bear.com wrote in article <6mtmdl$4ag$1@nnrp1.dejanews.com>...
>>
>> In the worst case, the programmer can have
>> -features=no%wchar
>> to disable wchar stuff.
>
>I can't see how this differs materially from supplying a subset
>library, which just happens to be called EC++.
"Supplying" a subset (or several subsets!) is one thing.
_Standardizing_ a single subset is obviously something else.
In fact, PJ has already identified inadequacies in the EC++ subset
(e.g. no containers) and supplies an alternative (his product).
>In either case, the
>implementation no longer accepts all conforming programs.
This is a false statement.
A full implementation that supports optimization switches
does still accept all conforming programs.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/29 Raw View
Mike Davies wrote:
>
> There is nothing to stop a compiler vendor from supplying several
> versions of the library, Borland (and others) have done this in the past
> for rtti, exceptions etc.
Borland C++ never shipped libraries built with exceptions or rtti
disabled. There was some conditional code to make such builds possible,
but it was rarely tested. The cost of shipping multiple libraries is, of
course, the cost of the additional testing: every library you add means
running the library test suite one more time on each build. When you
start building with various combinations of possible command line
switches you quickly get into a combinatorial explosion, and testing
becomes prohibitive.
> Wind River supply a completely modular library. This is not very up to
> date, but it shows another way forward.
Exceptions and rtti aren't modules, however. You can't just decide not
to link them in.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/29 Raw View
Mike Davies wrote:
>
> >Yup. Six STL headers. My point is that STL is not a viable programming
> >style in the memory constrained subset of the embedded area.
>
> You support your point with the incorrect statement that the STL was
> responsible for your 200k program bloat.
> Given that your statement is incorrect, how do you now support your
> assertion that the STL is "not a viable programming style in the memory
> constrained subset of the embedded arena" ?
Note that many people use "STL" to mean "Standard Library".
> I have use Watcoms' container classes in embedded applications, and my
> perceptions of the code (eg in the debugger) were that it was no bigger
> than any other method of obtaining that functionality would have been.
> My understanding (I no longer have access to the Watcom compiler to
> check) is that the STL has been implemented *more* efficiently than
> this. I would use the STL on an 8-bit micro like a shot, if it were
> available and if the application required the functionality. I don't
> suppose I am a better programmer than the person who wrote the STL
> anyway, so why should my own implementation of the functions be more
> efficient ?
How big an executable did it produce for "Hello, world" using cout? Does
the library include locale facets?
> I am genuinely interested in how you got a 200k program out of 20 lines.
> Even coding for Win32 using the Borland V4.52 static library doesn't do
> anything like that, and you are buying huge functionality with that
> library.
Borland 4.52 uses classic iostreams. No templates, no locales. No valid
comparison.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/06/29 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> wrote in article <e2SWZEAgKkl1EwET@noco.demon.co.uk>...
> >Despite what has been said in this thread about what compiler vendors
> >could or should do about unused virtuals, nearly all compilers in use today
> >do not eliminate them.
>
> But some do, which is an existance proof that it is possible to improve
> other compilers to do the same optimisations.
Existence proofs are fine for mathematicians, less fine for practicing
engineers with deadlines. They tell us what we can aspire to, not what
we can count on today.
> It seems to me that the provision of an extra library in addition to the
> standard one is wholly to the advantage of your customers.
> Borland supplies the source code to their libraries (or they used to
> anyway), this allowed customers to compile the libraries with or without
> rtti, exceptions etc etc to create the the right tradeoff for the
> application at hand.
> This is another possible method for allowing the customer to determine
> what is acceptable/necessary for his individual circumstances.
Fine, but there's far more to tailoring a library than compiling it with
different options. Many combinations simply cause nutty behavior.
And that, I keep repeating, is why a well thought out subset becomes
particularly important. Library implementors like us need to work to a
*coherent* set of options, so our customers aren't reduced to random
experiments.
> What I don't think your argument supports is the requirement for a
> language "subset", EC++. If compiler technology is lagging so that
> conforming libraries have an unacceptable cost then by all means provide
> your cuctomers with a solution (maybe based upon the methods above) for
> this problem, but there is no requirement for a new standard that I can
> see.
As above.
> It still seems to me still to be better to provide switches to disallow
> those features of C++ that a given compiler cannot implement
> efficiently, this gives the *customer* the choice as to which features
> to use. Surely you cannot disagree with the principle that the
> application writer is a better person to judge what is an acceptable
> cost for a given feature than the compiler vendor ?
We give the programmer the choice of coherent libraries -- EC++, abridged
(EC++ plus STL), and full C++ -- all configurable for use with or without
exceptions in the language. We also give the compiler vendor a gazillion
other options to tailor the libraries to any limitations of the compiler or
underlying C library. The programmer can judge which of these libraries,
and which compatible compiler options, give an acceptable cost for a
given job. It ain't a Chinese menu, but it does offer quite a range of
entrees.
> It is far better IMO to allow customers to keep appplying the pressure
> upon their compiler vendor for the parts of C++ that they need to be
> efficiently implemented. That way you will have a market led rise in the
> standard of C++ compiler implementations. I do not see that portability
> should be exempt from this selection pressure as opposed to being
> determined in advance by the fiat of a language sub-standard.
Why is this an either/or situation? I keep hearing expressed the fear that
a pragmatic subset of C++ made available today will somehow dissipate
the market pressure for fuly conforming C++. I haven't seen the least
hint of such an effect. The market is just too big and diverse to characterize
in such monolithic terms. As library vendors, we feel powerful pressures to
keep improving all our library products, even the ones that already fully
conform to their respective standards.
Relax, and let the embedded programmers have a little fun along the way.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/06/29 Raw View
In article <3595a40b.4991047@nntp.ix.netcom.com>,
wkdugan@ix.netcom.com (Bill Dugan) wrote:
>
> On 27 Jun 98 11:37:09 GMT, jcoffin@taeus.com (Jerry Coffin) wrote:
>
> >In article <6mtjpa$k1$1@nnrp1.dejanews.com>, saroj@bear.com says...
> >
> >[ ... ]
> >
> >> I disagree! Whether to use linear search or not, should not be done
> >> by the implementor of map, but should be decided by the programmer.
> >
> >Why? The implementor has already done exhaustive testing and proven
> >that for the largest possible collection on this machine, that a
> >linear search will _always_ be faster than a tree based lookup.
>
> How many implementors actually make such guarantees? How could they?
> Neither the compiler nor the library implementor know how much memory
> is available on the machine where the program will run, so they don't
> know what the largest possible collection will be.
They may not know the actual ammount of memory, but they do know the
maximum. If the processor has 16 address bits, you really don't have
to worry about what happens with more than 64K elements. And of course,
a lot of processors have even less.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientee objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: saroj@bear.com
Date: 1998/06/29 Raw View
In article <3596ACC0.A226AA6A@acm.org>,
Pete Becker <petebecker@acm.org> wrote:
>
[snipped]
>
> How big an executable did it produce for "Hello, world" using cout? Does
> the library include locale facets?
>
> > I am genuinely interested in how you got a 200k program out of 20 lines.
> > Even coding for Win32 using the Borland V4.52 static library doesn't do
> > anything like that, and you are buying huge functionality with that
> > library.
>
> Borland 4.52 uses classic iostreams. No templates, no locales. No valid
> comparison.
I have always heard how big the cout << "hello world" program is.
Can you say that iostream template is the cause of this? Definitely not.
If at all, it can only reduce the code size, because the standard
requires that if some non-inline template members are not used,
then they should not be instantiated. So even without the linker support,
your code size is smaller.
Now you have only the locale argument. It has been repeated in this
group that a compiler can remove the unused virtuals. Even if your
compiler does not do this, a library vendor can tell its customers that
because of such and such constraints our iostream library supports only
one locale or does not support locale stuff. There are even systems,
where you can not use stdio.h. So just for <iostream>, do you really
need a EC++ label for your product? Ultimately, a vendor will succeed
by making the customer (programmers') life easy by supplying the
whole library (within the resource constraints) and not by claiming
compliance with an standard like EC++. Please do not underestimate the
intelligence of your customers - they will see through it.
Cheers,
Saroj Mahapatra
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/06/29 Raw View
In article <9BruECAHojl1Ewy0@noco.demon.co.uk>,
Mike Davies <mike_davies@noco.demon.co.uk> wrote:
> I have use Watcoms' container classes in embedded applications, and my
> perceptions of the code (eg in the debugger) were that it was no bigger
> than any other method of obtaining that functionality would have been.
> My understanding (I no longer have access to the Watcom compiler to
> check) is that the STL has been implemented *more* efficiently than
> this. I would use the STL on an 8-bit micro like a shot, if it were
> available and if the application required the functionality. I don't
> suppose I am a better programmer than the person who wrote the STL
> anyway, so why should my own implementation of the functions be more
> efficient ?
I've never seen the Watcoms' container classes to compare, but I seriously
doubt that any of the current STL implementations would run on an 8-bit
micro. It has nothing to do with the relative competence of the programmer,
and everything to do with his goals; the goals of the current implementations
are all to favor speed over space, for example, and they do tend to be
memory hogs.
In practice, things like requiring amortised constant time for vector::
push_back will tend to require extra memory.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientee objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/29 Raw View
In article <6n8g2i$eo3$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
writes
...snip...
>They may not know the actual ammount of memory, but they do know the
>maximum. If the processor has 16 address bits, you really don't have
>to worry about what happens with more than 64K elements. And of course,
>a lot of processors have even less.
External page registers excepted of course.
--
Mike Davies
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/29 Raw View
In article <3596AB7E.C3B5A707@acm.org>, Pete Becker <petebecker@acm.org>
writes
>Mike Davies wrote:
>>
>> There is nothing to stop a compiler vendor from supplying several
>> versions of the library, Borland (and others) have done this in the past
>> for rtti, exceptions etc.
>
>Borland C++ never shipped libraries built with exceptions or rtti
>disabled. There was some conditional code to make such builds possible,
>but it was rarely tested.
I tested it :-)
It worked ok for me.
>
>> Wind River supply a completely modular library. This is not very up to
>> date, but it shows another way forward.
>
>Exceptions and rtti aren't modules, however. You can't just decide not
>to link them in.
No, but the point I was making is that libraries can be compiled and
shipped without them, you may need to restrict the functionality also.
The point being that there is no need for a language subset, you can
supply both versions of the library and let the customer choose. If the
base code for the different libraries is the same then this goes some
way to alleviate the testing requirement.
--
Mike Davies
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "David J. Littleboy" <davidjl@gol.com>
Date: 1998/06/29 Raw View
Mike Davies wrote in message <9BruECAHojl1Ewy0@noco.demon.co.uk>...
>Given that your statement is incorrect, how do you now support your
>assertion that the STL is "not a viable programming style in the memory
>constrained subset of the embedded arena" ?
Lets put it this way: a programming technique that implies multiple
instantiations of the same code for different types may be seen as
questionable in a memory constrained area. Similarly, a programming
technique that implies the instantiation of unknown amounts of code
may be seen as questionable in a memory constrained area.
>I have use Watcoms' container classes in embedded applications, and my
>perceptions of the code (eg in the debugger) were that it was no bigger
>than any other method of obtaining that functionality would have been.
There are lost of ways to skin a cat, and your "no bigger than any other
method of obtaining that functionality would have been" really means "I
can't see a better method just now". For example, the standard library does
not
support invasive containers, and those are sometimes the right idea.
Furthermore, STL seems to force one into a "value semantics" approach, which
seems to me to be potentially problematic in memory constrained situations
(although one can, of course, use STL to contain pointers, but that seems to
defeat the whole point of STL.)
>>>EC++ would
>>>>allow programmers in that world to start using a subset of C++ in the
>>>>very near future.
>>>
>>>They can do that now by using C++. The difference is that they get to
>>>choose the subset instead of having it foisted upon them by a compiler
>>>vendor who is having difficulty doing for profit something that the
>>>egcs group is doing very well for free.
>>
>>No, they can't. First someone's got to implement it for them.
>
>They already have. Lots of C++ compilers have switches to dis-allow rtti
>and exceptions while the compiler implementations are being improved.
Sorry, I should have said "port the code generator". None of those compilers
produce code for any of the microprocessors of concern to the EC++ folks.
And whether those switches actually work or not is problematic.
Remember, the people who are interested in EC++ aren't Intel, IBM,
Motorola, and Hitachi. They are XXX, YYY, and ZZZ, and Fujiyama Denki, and a
couple of steel companies that diversified into semiconductors. The folks at
gnu don't have time to port to every microcontroller around.
>>This is a point I wish you'd listen to more carefully. There are a
>>large number of microcontroller manufacturers who do not have the
>>manpower and financial resources to implement and support full C++.
>>These are groups that are struggling just to support C. And these are
>>the groups that are asking for a minimal C++ subset. My best guess is
>>that there are more groups in this position (i.e. more proprietary
>>architecture microcontrollers) than there are C++ implementations in
>>the world. These groups just don't have the deep pockets of Sun, MS,
>>Intel.
>>In other words, EC++ is not being foisted on anyone by compiler
>>vendors.
>
>This is also incorrect. Intel haven't sold compilers for (eg
>their 8051,90196, etc etc) microcontrollers for *years and years*.
>They only sell the 80x86 compiler as an add-on to the Microsoft
>development suite.
>
>*Most* microcontroller mfrs don't sell compilers any more. They rely on
>third parties like Keil et al to write compilers.
Your "most" and my "most" are different. We're talking about completely
different groups. I'd be surprised if Intel, Motorola, and IBM had any
interest whatsoever in EC++. I've been
fairly careful (some of the time) to qualify my comments with "certain
segments of the embedded area", meaning the companies that can't expect rms
and/or Microsoft to do their homework for them.
>So EC++ *is* being promoted primarily by compiler vendors. Whether this
>is "foisting" EC++ on anybody depends upon your point of view of course.
No, it's being proposed by a consortium of mostly Japanese microcontroller
manufacturers. It only looks that way because they aren't here and the only
people to represent their opinions happen to be compiler vendors (and one
freelance translator).
>>Furthermore, any microcontroller group that can
>>afford to support full C++ is going to have a large advantage, as soon
>>as compiler technology appears, anyway, and can be expected to do so.
>
>Not if all the other vendors have the phrase "fully (E)C++ standard
>compliant" to hide behind.
The idea that anyone would mistake EC++ for C++ strikes me as pretty
unlikely. The alternative of not having an EC++ standard would be much
worse. The anti-EC++ crowd here would like people to design their own
subset. At which point people offering a subset would be advertising "an
efficient subset of C++". This would be a major disaster for the customer,
since he would never know what he was getting.
The advantage of EC++ being a public standard would be that one would
know exactly what one was getting.
[snip]
>>EC++ is a _major_ improvement over C
>
>No, EC++ is basically C with classes. This was developed into C++ as it
>stands today at the request of the users themselves, who had found it
>not to be sufficient!
Well, we're into opinion land here, but it seems to me that the whole
motivation for C++ existed long before locale facets. We've been
having too much fun over the last 8 years or so and forgotten how important
getting classes and type safety down right was.
>(Source is one of Stroustrups books, they are not to hand at the moment
>and I cannot remember which)
Yeah, but he's one of the people who's been having most of that too much
fun.
>>, and for a lot of embedded
>>programmers, opposition to EC++ means denying them _any_ form of C++
>>whatsoever.
>
>No, opposition to EC++ is denying compiler vendors the chance to make
>minimal changes to their C compilers then stop with an unsatisfactory
>language subset.
First of all, your statement as it stands is just plain wrong. None of the
major players is basing EC++ on a C compiler. Furthermore, EC++ will never
be more than a niche product, so (I expect that) the only people who will be
providing EC++ products will be C++ vendors. Besides, the microcontroller
manufacturers interested in EC++ are also interested in at least leaving
open the possibility of moving to C++, so an EC++-only product would find
zero customers.
Second, work on EC++ directly leads to improvements in C++. There wouldn't
be such a brouhaha over the size of the standard library if it weren't for
EC++.
Third, an "unsatisfactory language subset" is exactly the right idea. It
provides easy entry to C++ with enough features left out so that there's
lots of incentive to move on. If EC++ were 90% of full C++, then it could
really turn into the drag on the community Bjarne worries about, but as
it is (without templates and STL), that's inconceivable.
David J. Littleboy <davidjl@gol.com>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/06/29 Raw View
Nathan Myers wrote:
>
> Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
> >Nathan Myers wrote:
> >>
> >> What would satisfy is efficient
> >> compilers and libraries that don't impose overhead for unused features.
> >> There are plenty of excuses for not providing that, but to standardize
> >> such excuses is madness.
> >
> >But you can't do a standard string class that doesn't throw exceptions.
>
> You can do a conforming string class that doesn't necessarily throw
> exceptions. In particular, it can call a function instead of throwing
> an exception, and the compiler can link different definitions of
> this function according to a compiler flag.
>
A good idea. However, this extra mechanism would have to be
standardized as well to be widely useful.
Ok, let's make a next try: Define EC++ as full C++ compiler with
the option to turn costy features off, and a std library with
certain standardized extensions to avoid common overhead.
Those extensions could be
- callbacks for thowing functions, as you proposed above
- extra member functions to containers to reduce their size
consumption (f. ex. a vector::shrink() member which allows
to reduce the memory occupied by a vector to be reduced
to the memory actually needed)
Another possible part for an EC++ standard could be additional
requirements on std implementations (f.ex an upper limit for
average unused memory consumption for vectors). I can imagine
that such additional requirements could encourage embedded
programmers to make use of the std libraries.
> But this assumes that horrendous overhead for support of exceptions is
> the norm. Exception support need not add any more overhead than the
> apparatus to check return results, and in mature compilers it won't.
The point is that error handling code is written by you, and
therefore you can decide for each case if it is needed (simple
example, if your program contains sqrt(M_PI), you'll never even
think about checking if sqrt succeeded). However, exception code
is produced by the compiler, who in general will not be able to do
as detailed analysis as you'll do. So it'll put that code in
where *you* wouldn't do that. While this can be done in a way that
doesn't affect execution speed at all (since the error never happens,
only normal path matters), it will affect code size.
>
> >Also note that it doesn't help to check values for validity when
> >calling string functions - the throws of string will be compiled
> >in anyway (and you won't give the compiler the burden to proof that
> >all parameters to string functions will be legal at runtime, do you?)
>
> If you have asked not to get exceptions, the burden of proof is on you,
> not on the compiler. The "throws of string" will be function calls
> to a (presumably) user-defined handler.
Well, I just said that an EC++ standard could demand a way to ask
for not throwing exceptions. If you don't have a way to ask for it,
the compiler would have to derive that from your code. Of course
this wouldn't free you from proving the code - but it would in
addition require the compiler to re-do the proof to avoid the
(memory) overhead of exception handling code which will never be
executed anyway.
>
> >And then there's the question if it's possible to avoid any overhead
> >for features not used, if there's no switch to turn them off.
>
> The standard doesn't say that you're not allowed to help your compiler
> optimize your program. In fact, specifying various compiler flags
> for various purposes (optimization, debugging, profiling, test coverage)
> is familiar to us all.
>
Then why are people so obviously against this idea, if it is
connected with the name "EC++"?
> >What makes exceptions different from most other features is that
> >it affects the global program. ... There are implementations with
> >no overhead at no-throw path, but all the information *must* be
> >there for the case someone throws.
>
> The linker can throw away the information if the program contains no
> throws, or even if you have asserted (via a linker switch) that it
> does no throws.
The first option requires a way to make the program throw-free.
Since the stdlib does contain throws, this is not possible without
adding something to the stdlib -> EC++ standard library.
The second option is the flag option (if it's a flag to the compiler
or the linker doesn't matter - usually you give both to the
compiler driver).
Together, they make exactly what I described as possible solution
for a satisfying EC++ standard: A *full* C++ compiler with
*additional* compiler flags to turn off expensive features
(esp. exception handling) and an EC++ library. The only
difference is that I thought of an additional library, but
now you pointed out that an extension of the std library would
be sufficient.
>
> >However, even if there once exists a no-overhead-for-unused-features
> >compiler, you'll still need an EC++ library to "unuse" those
> >features *without* abandoning useful parts of the library that
> >just happen to use those features per std definition, but could
> >be defined not using them with little or no efford.
>
> In that case it's not an EC++ library at all. It's just a compile-
> and-link option (one among many, I hope).
It *is* an EC++ library, since to avoid exceptions, you have at
least to extend the stdlib, since by default it throws exceptions.
I can imagine that one might build a compiler that recognices
the use of those special features so that the extra flags are not
required any more, but I would not like to use a compiler which
*changed* the behaviour of the library with compiler flags (other
than by linking in another library).
>
> We haven't standardized optimizer choices on compilers before now,
> why should we start now? Especially, why should we accept a standard
> for what amounts to a definition of inefficient language features when
> these features are inefficient only on immature compilers?
There's no feature that comes with no overhead if used. Therefore
if you don't want to have a specific overhead one required step to
get that is not to use the feature. So far so good. However, the
C++ standard library classes use features which are not always
necessary to provide the functionality. The string exceptions
are an example. While you can provide ways to avoid those in
implementations, there's no way to avoid them in a standard way,
except by not using strings. This is bad, because that means if
you want to avoid exception overhead, you must either use a
non-portable extension, program your own string class or not use
strings at all. Better would be a standardized way to do it.
Standardizing a way needs, of course, a standard. This standard
could be the EC++ standard, since in embedded programming the
memory overhead is important.
Stated another way: The problem isn't just the overhead you get for
features you don't use, but the overhead for features you don't
need, but are forced to use when using the library.
The string exceptions are an example; the locale problem which
started the thread is another (although that is solvable by
compiler behaviour).
>
> A good compiler for embedded-system programmers would be one which
> implements language features efficiently, not one that does them
> badly (if at all) and with a switch to turn them off. It's a shame
> that vendors of the latter have absconded with the "EC++" label, so
> that anyone who makes the former must invent a different name.
And a good library for embedded programmers would be one that lets
you use the advantages of specific parts of the std library without
forcing you to use features you don't want to use, and which are not
needed to get the key functionality of the part used. The C++ standard
library is not that library (except for the STL part, which is quite
perfect in this respect).
Remember: You always have to pay for the features you use, even
if you don't need them.
Maybe we need yet another paradigma: You should not only not have to pay
for what you don't use. You should also not have to use what you don't
need.
[...]
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/06/29 Raw View
Nathan Myers <ncm@nospam.cantrip.org> wrote in article <6n683n$3ch$1@shell7.ba.best.com>...
> >I can't see how this differs materially from supplying a subset
> >library, which just happens to be called EC++.
>
> "Supplying" a subset (or several subsets!) is one thing.
> _Standardizing_ a single subset is obviously something else.
>
> In fact, PJ has already identified inadequacies in the EC++ subset
> (e.g. no containers) and supplies an alternative (his product).
Hmm, that argument cuts several ways. The fact that we supply
several different libraries could be taken as proof that the Standard
C++ library is inadequate. But I don't look at it that way. I see that
``one size fits all'' is not a viable approach to implementing C++
today. If that can be fixed by improving compiler/linker technology,
over the next several years, that's fine with me. Meanwhile, no
single subset, or full set, is likely to be adequate for all needs.
That in no way diminishes the importance of *specifying* what a
subset, or full set, should consist of. People who want to achieve
some level of portability across implementations have a greater
chance than if they simply choose among a continuum of options.
> >In either case, the
> >implementation no longer accepts all conforming programs.
>
> This is a false statement.
> A full implementation that supports optimization switches
> does still accept all conforming programs.
Please don't yank the statement out of context. At least some of
the optimizations suggested in the post I was responding to require
a relaxing of strict conformance to the C++ Standard. When you run
a compiler with exceptions turned off, for example, you're supplying
a non-conforming subset implementation. It's not the same as, say,
enabling the use of hash tables for switch statements. Each
combination of compiler switches is de facto a different
implementation, as Larry Rosler so aptly observed in the early days
of C standardization.
Whether the entire package can be configured to fully conform is
an orthogonal matter. In fact, a dirty little secret among us standards
hacks is that many customers *never* run their compilers in strict
conformance mode. That mode is a device supplied by the compiler
vendors so they can promise conformance with a straight face, but
remarkably few people are the purists we'd like them to be about
using it.
We need to be very careful about what we mean when we use the
terms subset, optimizations, compiler switches, and conformance
all in the same breath.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/06/29 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> wrote in article <xGidVMAjnkl1Ewj2@noco.demon.co.uk>...
> Why cannot the linker do some form of reference counting before it
> decides to instanciate code in the initialisers for the iostreams
> objects ? Can't you use a weak reference in the iostream's initialiser ?
> Or am I missing the point here ?
That's certainly the kind of machinery you need to solve this particular
problem. Maybe one day it will become commonplace. Right now,
however, I don't know of a mechanism that can eliminate the need to
define four single-byte and four wide-character stream objects every
time a C++ program includes <iostream>. The problem has been
with us for many years, but it was not considered a big problem until:
a) iostreams classes got a lot heftier with machinery mandated by
the C++ Standard
b) wide iostreams classes got stuck in the same header as the
traditional ones
c) iostreams objects got tied into locale objects, which themselves
drag in lots of facet code
When a library has time to evolve over a period of years, it achieves
a kind of equilibrium with the language proper and with the compiler
technology. Traditional libraries are rife with pragmatic compromises.
Equally, compilers and linkers have adopted numerous optimizations,
over the years, to meet the demonstrated needs of library writers. I
emphasize, however, that both compromises and optimizations occur
*over the years*.
What we have been experiencing with the C++ Standard is a kind of
forced growth of both language and library innovation, without the usual
annealing of experience to temper the final design. In this hothouse
atmosphere, specifications have way outpaced the technology. It is
easy to say that implementors are lazy, or vendors are trying to lock
customers into nonstandard dialects. That may even be true of some
players in this diverse marketplace. I just don't happen to know any
such. But it is unmistakably true that C++, as a total marketplace, is
*not* in the kind of equilibrium we usually see right after a just
completed standard.
Some of us are offering clearly defined subsets of Standard C++ as
a way to deal with the current stresses. Maybe the need for such
subsets will evaporate in a few years, maybe not. Equilibrium has a
way of defining itself.
> >As always, I will enjoy being educated.
>
> Probably not by me, though :-)
On the contrary. I learn the most from people whose views differ from
mine.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/06/29 Raw View
Jerry Coffin wrote:
>
> In article <6mtjpa$k1$1@nnrp1.dejanews.com>, saroj@bear.com says...
>
> [ ... ]
>
> > I disagree! Whether to use linear search or not, should not be done
> > by the implementor of map, but should be decided by the programmer.
>
> Why? The implementor has already done exhaustive testing and proven
> that for the largest possible collection on this machine, that a
> linear search will _always_ be faster than a tree based lookup.
>
Even for classes which need two minutes to compare?
(Yes, I know, nobody will ever write a class which need two minutes
to compare - but then, nobody will ever need more than 640 KByte,
right? ;-))
> > The implementor should provide vector (contiguous), linked list,
> > a balanced-tree map, a hash map. The programmer should decide when
> > to use which container.
>
> WHY? I'll repeat: for this machine, the implementor has already
> proven that all of these will _always_ give inferior performance.
Show me the implementor who can prove this. Note that he doesn't
know which classes you'll want to sort.
>
> > Again hammer and nail syndrome. Hash table is not the universal solution.
> > map makes stronger guarantees than the hash_map : a map stores its
> > elements in the sorted order.
>
> It's not hammer and nail syndrome AT ALL. It's simply an observation
> that for the VAST majority of what I've seen done on a regular basis,
> hashing based containers are more efficient.
It's simply an observation that for the VAST majority of what I've
seen done on a regular basis, hammers are the best tool for the job ;-)
[...]
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/29 Raw View
In article <3596ACC0.A226AA6A@acm.org>, Pete Becker <petebecker@acm.org>
writes
>Mike Davies wrote:
>>
>> >Yup. Six STL headers. My point is that STL is not a viable programming
>> >style in the memory constrained subset of the embedded area.
>>
>> You support your point with the incorrect statement that the STL was
>> responsible for your 200k program bloat.
>> Given that your statement is incorrect, how do you now support your
>> assertion that the STL is "not a viable programming style in the memory
>> constrained subset of the embedded arena" ?
>
>Note that many people use "STL" to mean "Standard Library".
No.
>> I have use Watcoms' container classes in embedded applications, and my
>> perceptions of the code (eg in the debugger) were that it was no bigger
>> than any other method of obtaining that functionality would have been.
>> My understanding (I no longer have access to the Watcom compiler to
>> check) is that the STL has been implemented *more* efficiently than
>> this. I would use the STL on an 8-bit micro like a shot, if it were
>> available and if the application required the functionality. I don't
>> suppose I am a better programmer than the person who wrote the STL
>> anyway, so why should my own implementation of the functions be more
>> efficient ?
>
>How big an executable did it produce for "Hello, world" using cout? Does
>the library include locale facets?
Executables using their iostreams library came in at down to around 8k.
I don't believe that the version of the library I used has locale facets
though.
>
>> I am genuinely interested in how you got a 200k program out of 20 lines.
>> Even coding for Win32 using the Borland V4.52 static library doesn't do
>> anything like that, and you are buying huge functionality with that
>> library.
>
>Borland 4.52 uses classic iostreams. No templates, no locales. No valid
>comparison.
My point was that you got a 200k executable by linking against the MFC,
not by using the STL :-)
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/29 Raw View
In article <01bda2fd$47f05400$8a1ec2d0@porky>, "P.J. Plauger"
<pjp@dinkumware.com> writes
>Mike Davies <mike_davies@noco.demon.co.uk> wrote in article <e2SWZEAgKkl1EwET@no
>co.demon.co.uk>...
>> >Despite what has been said in this thread about what compiler vendors
>> >could or should do about unused virtuals, nearly all compilers in use today
>> >do not eliminate them.
>>
>> But some do, which is an existance proof that it is possible to improve
>> other compilers to do the same optimisations.
>
>Existence proofs are fine for mathematicians, less fine for practicing
>engineers with deadlines. They tell us what we can aspire to, not what
>we can count on today.
My point was that the existance a compiler that can produce a zero
overhead implementation of a feature of C++ reduces the strength of the
argument for the EC++ subset of C++ on the basis of the putative
efficiency gain, since it is possible to obtain this gain without having
the cut down version of the language.
If a compiler vendor is deciding between investing in a cut-down version
of their library or an improvement in the quality of their compiler then
they now know what the competition can do. They are able to make the
decision that is IMO most in the interests of their customers and
improve their compiler implementation.
...snip...
>> It still seems to me still to be better to provide switches to disallow
>> those features of C++ that a given compiler cannot implement
>> efficiently, this gives the *customer* the choice as to which features
>> to use. Surely you cannot disagree with the principle that the
>> application writer is a better person to judge what is an acceptable
>> cost for a given feature than the compiler vendor ?
>
>We give the programmer the choice of coherent libraries -- EC++, abridged
>(EC++ plus STL), and full C++ -- all configurable for use with or without
>exceptions in the language. We also give the compiler vendor a gazillion
>other options to tailor the libraries to any limitations of the compiler or
>underlying C library. The programmer can judge which of these libraries,
>and which compatible compiler options, give an acceptable cost for a
>given job. It ain't a Chinese menu, but it does offer quite a range of
>entrees.
Sounds good to me, do you do free home deliverys ? :-)
...snip..
>Relax, and let the embedded programmers have a little fun along the way.
OK. One further argument against EC++ :
Any realistic implementation of C++ / C with classes would contain EC++
anyway, so why the need for the standard ?
>
>P.J. Plauger
..snipetty-snip... :-)
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1998/06/29 Raw View
In article <m3wwa24kef.fsf@gabi-soft.fr>, kanze@gabi-soft.fr says...
[ ... ]
> Given the very weak wording concerning the complexity requirements in
> the standard, I think a shell sort would be a legal implementation on
> such a small machine. After all, n^1.2 is approximately n log n for a
> sufficiently loose definition of approximately. At any rate,
> realistically, I can't imagine anyone complaining the the performance
> was too good:-).
Well, technically, you don't even need to get into defining
"approximately" -- the standard says things like "N Log N", but
doesn't define the base of the logarithm. By choosing the appropriate
base for the logarithm, you can more or less pick arbitrary numbers
and make them fit...
--
Later,
Jerry.
The Universe is a figment of its own imagination.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/06/27 Raw View
Jerry Coffin wrote:
>
> In article <35918C0D.1CFB@wizard.net>, kuyper@wizard.net says...
...
> > I'm not worried about implementors faking compliance by such
> > methods. I'm worried about implementors taking short cuts by using a
> > simpler but slower algorithm than the one that was used as a basis for
> > setting the required operation counts. In every case, those operation
> > counts were based upon someone being aware of a feasible implementation
> > that met those requirements.
>
> Why are you "worried" about this? Just picking an obvious instance,
> have you seen lots of C standard libraries that used, say, a bubble
> sort to implement their qsort() function?
I'm worried because most of the code I've ever seen written by other
people contains shortcuts that could produce problems if used in
contexts that the programmer hadn't bothered to think about,
particularly if it was produced on a tight budget or short deadlines.
There are very competent, careful programmers out there, and companies
that allow/require them to take the time to do things right, but both
are rare. One thing I like about my current job is that my supervisor is
willing to let me take that time, even when we're on a tight schedule.
I'm not aware of any really bad implementations of qsort(), but I
wouldn't be surprised by one either. I have heard that virtually every
implementation of rand() is inadequately random for serious work, even
in cases where the limited range of rand() would otherwise be
acceptable.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/06/27 Raw View
saroj@bear.com wrote in article <6mtmdl$4ag$1@nnrp1.dejanews.com>...
> > So far, I haven't figured out how to avoid executable code in the initializers
> > for the iostreams objects.
> >
> > As always, I will enjoy being educated.
>
> In the worst case, the programmer can have
>
> -features=no%wchar
>
> to disable wchar stuff.
I can't see how this differs materially from supplying a subset library, which
just happens to be called EC++. In either case, the implementation no longer
accepts all conforming programs.
> In the best case, I expect the compiler and library vendor to do the
> required research and make sure that the initialization code is put in
> different object file (much like template repository), use the vendor
> specific initialization pragma (to make sure those objects are
> initialized (if linked with the program at all)), and not link the
> initialization code at all if not needed.
I am now doing the required research(!) I am asking the community of C++
experts to tell me how to do something that I confess I don't know how to
do. (Nor have I seen any competitors succeed so far, FWIW.) I don't know
how to ``not link the initialization code at all if not needed'' in this particular
case. ``Use pragmas'' is great advice -- if I can find a compiler person at
each of my customer sites onto whom I can foist a problem that was never
a problem in the past decade-plus of C++ history.
The C++ committee chose not to codify existing practice in many areas of
the Standard C++ library. As Al Stevens so aptly put it, on a different topic,
we are now alpha testing inventions made in the guise of standardization.
And the Standard can no longer change if we determine that small changes
can make a big difference in functionality or performance.
> Floating point stuff is
> also platform specific. Does that mean you will not implement any
> floating point routines for a library?
A fascinating non sequitur. In point of fact, the C Standard mandates
enough about floating-point arithmetic that I have managed to keep the
bulk of my math library in portable C. The part that can't be made portable
was well understood *while the C Standard was being developed.* So we
knew how to keep the issues localized, and we tweaked the library headers
to improve the localization as we went along. Not the same case at all.
> To do otherwise, will be like Microsoft saying if you want to use
> std::list<Person>, just define operator<, operator= in struct Person,
> because it is too difficult for us to determine what template stuff
> are needed and what are not.
Microsoft didn't say that, AFAIK. They made an early stab at checking
templates, while the draft C++ Standard was continually changing. When
it became clear how the job should be done better, they complied. Why
do you ascribe a pejorative motive to them that is not in evidence?
> I have heard complains in this thread that if you want to just output an
> integer, you do not need many things. I know it and I, as a programmer,
> can decide whether I want to use streams (which provides a lot of
> control of formatting, local etc) or just use K&R program itoa for
> simple output.
Right. Good guideline. We each form a mental model of the complexity
we buy with each language or library feature we make use of. The issue
here is that the C++ Standard has changed the real-world model in
surprising ways, without ensuring the technology can deliver on expectations
formed in simpler times. So maybe the technology will eventually catch up.
(If you standardize it, they will come.) I'm doing all I know how to do to help.
But meanwhile, the best way I know to keep customers happy is to supply
a subset that *can* meet those expectations.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1998/06/27 Raw View
In article <35914948.59E2@wizard.net>, kuyper@wizard.net says...
> Jerry Coffin wrote:
> ...
> > may be faster overall than ones that make fewer comparisons. Imagine
> > the overhead involved in doing, say, a heapsort on 10 items. Compare
> > that to using an insertion or selection sort on the same 10 items.
> > The latter will make more comparisons than allowed, but will be
> > finished before the heap-creation phase of the heap-sort is finished.
>
> That depends entirely upon the amount of time the comparisons take. For
> sufficiently slow comparisons, the ONLY thing that matters is how many
> of them you make (that's the definition of "sufficiently slow" in this
> context). You can't write a templated standard container and have it
> simultaneously optimized for all types of objects.
This assumes that comparison is consistently so much slower than
swapping that that the latter can and should be completely ignored. I
don't have _extensive_ studies about huge bodies of C++ source code,
but it's not my experience that this is a reasonable or correct
assumption. (I.e. "sufficiently" slow comparisons don't seem to be
the rule...)
Second, while I agree that it's not possible to write containers that
are simultaneously optimized for ALL possible types of objects, I do
believe it's entirely possible to specify the containers and
algorithms so they would be much closer to optimum for a much wider
variety of objects.
> The specifications
> that restrict the number of comparisons implicitly imply that
> comparisons are the main operations that constrain the speed. If that's
> not true for a given class of contained objects, you might need to use a
> non-Standard container class.
The question is: should that be the case? The answer (IMO) is NO,
absolutely not!
--
Later,
Jerry.
The Universe is a figment of its own imagination.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1998/06/27 Raw View
In article <6mtjpa$k1$1@nnrp1.dejanews.com>, saroj@bear.com says...
[ ... ]
> I disagree! Whether to use linear search or not, should not be done
> by the implementor of map, but should be decided by the programmer.
Why? The implementor has already done exhaustive testing and proven
that for the largest possible collection on this machine, that a
linear search will _always_ be faster than a tree based lookup.
> The implementor should provide vector (contiguous), linked list,
> a balanced-tree map, a hash map. The programmer should decide when
> to use which container.
WHY? I'll repeat: for this machine, the implementor has already
proven that all of these will _always_ give inferior performance.
> Again hammer and nail syndrome. Hash table is not the universal solution.
> map makes stronger guarantees than the hash_map : a map stores its
> elements in the sorted order.
It's not hammer and nail syndrome AT ALL. It's simply an observation
that for the VAST majority of what I've seen done on a regular basis,
hashing based containers are more efficient.
> You need a sorted container (be it map
> or a sorted vector or list) for efficient implementation of set_union,
> set_intersection and several other algorithms. If you think carefully,
> you will see need for different containers in different situations.
> I advise reading Knuth Vol. 3 about the tradeoffs he mentions about
> balanced tree vs. array, but the writing is equally applicable to other
> containers.
I've read it. I've also been watching programming and what gets done
in programming for the 20+ years since I first read it.
That observation has lead me to one conclusion: doing things like
intersections and unions of sets isn't anywhere close to as common as
simple key-based lookup. Optimizing the rare case at the expense of
the common case is NOT a good policy.
> It is useful to specify the computational complexity in STL. One sort
> method is not always the best, but the standard provides one with specified
> worst case behavior. In most situations, you can just use the standard
> library sort, and rest of the times, use your own sort (heap/selection/
> shell/...).
The programmer rarely if ever has access to the information necessary
to make an intelligent and informed decision about what's going to
work best in a given situation. The implementation does. You rarely
if ever have access to the information necessary to decide whether the
sorting algorithms in the library will be optimal or not. Again, the
implementation does.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1998/06/27 Raw View
In article <6mrq6n$mv3$1@shell7.ba.best.com>, ncm@nospam.cantrip.org
says...
[ ... ]
> Generally, if you have special knowledge about the type that is
> being sorted, you can specialize std::sort() for that type and apply
> any algorithm you want. Thus, std::sort() is usable as-is for almost
> all purposes by almost all people, which wouldn't be the case without
> performance requirements, and it's hand-tunable for cases where those
> requirements might be a problem. So, what's the problem?
The problem is that YOU, the coder, rarely know when you should do the
hand-tuning, at least in portable code.
The implementor knows more about the machine than you do. Based on
that extra knowledge, the implementor can make more intelligent
decisions about what sorting algorithm to you than you can.
This does not apply only to sorting: as I've already mentioned, it
applies equally to things like memory allocation as well. YOU rarely
know the exact expense of allocating, say, an extra megabyte of memory
on a particular machine. Since it varies WIDELY with the
implementation (and often even with the exact amount of physical
memory in the machine) there's NO portable way to find out or make a
reasonable decision.
OTOH, the implementation CAN know about such things. It doesn't HAVE
to be portable, so it can use specific knowledge of this machine,
including all sorts of non-portable data about the processor, the
amount of physical memory, etc., to make a MUCH better informed
decision than you can.
In short, you've assumed that special knowledge of the TYPE is what's
important here. I don't think that's correct at all -- nearly all
that matters about the type is whether it's cheaper to compare or swap
elements, which (surprise, surprise) the implementation can determine,
and, once again, you can't in a portable fashion.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1998/06/27 Raw View
In article <35926225.570393770@news.motu.com>, abrahams@motu.com
says...
[ ... ]
> C'mon, Jerry, you know better than that! You can't "simply specify
> that map<> would do keyed lookup". If it's going to do hashing, you
> put requirements on the contained type which are different from what
> you get if it's going to use a tree.
Yes, I realize there's a bit more to it than that. However, we're not
talking about rocket science here: people have been doing hashing
based containers for years, so we're certainly not talking about
inventing new science or anything like that.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/27 Raw View
Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
>Nathan Myers wrote:
>>
>> What would satisfy is efficient
>> compilers and libraries that don't impose overhead for unused features.
>> There are plenty of excuses for not providing that, but to standardize
>> such excuses is madness.
>
>But you can't do a standard string class that doesn't throw exceptions.
You can do a conforming string class that doesn't necessarily throw
exceptions. In particular, it can call a function instead of throwing
an exception, and the compiler can link different definitions of
this function according to a compiler flag.
But this assumes that horrendous overhead for support of exceptions is
the norm. Exception support need not add any more overhead than the
apparatus to check return results, and in mature compilers it won't.
>Also note that it doesn't help to check values for validity when
>calling string functions - the throws of string will be compiled
>in anyway (and you won't give the compiler the burden to proof that
>all parameters to string functions will be legal at runtime, do you?)
If you have asked not to get exceptions, the burden of proof is on you,
not on the compiler. The "throws of string" will be function calls
to a (presumably) user-defined handler.
>And then there's the question if it's possible to avoid any overhead
>for features not used, if there's no switch to turn them off.
The standard doesn't say that you're not allowed to help your compiler
optimize your program. In fact, specifying various compiler flags
for various purposes (optimization, debugging, profiling, test coverage)
is familiar to us all.
>What makes exceptions different from most other features is that
>it affects the global program. ... There are implementations with
>no overhead at no-throw path, but all the information *must* be
>there for the case someone throws.
The linker can throw away the information if the program contains no
throws, or even if you have asserted (via a linker switch) that it
does no throws.
>However, even if there once exists a no-overhead-for-unused-features
>compiler, you'll still need an EC++ library to "unuse" those
>features *without* abandoning useful parts of the library that
>just happen to use those features per std definition, but could
>be defined not using them with little or no efford.
In that case it's not an EC++ library at all. It's just a compile-
and-link option (one among many, I hope).
We haven't standardized optimizer choices on compilers before now,
why should we start now? Especially, why should we accept a standard
for what amounts to a definition of inefficient language features when
these features are inefficient only on immature compilers?
A good compiler for embedded-system programmers would be one which
implements language features efficiently, not one that does them
badly (if at all) and with a switch to turn them off. It's a shame
that vendors of the latter have absconded with the "EC++" label, so
that anyone who makes the former must invent a different name.
I hereby propose the title "EEC++", "Efficient Embedded C++",
reserved for implementations of the full language suitable for
use by embedded-system programmers without need to "turn off"
key core-language features.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1998/06/28 Raw View
ncm@nospam.cantrip.org (Nathan Myers) writes:
|> Generally, if you have special knowledge about the type that is
|> being sorted, you can specialize std::sort() for that type and apply
|> any algorithm you want. Thus, std::sort() is usable as-is for almost
|> all purposes by almost all people, which wouldn't be the case without
|> performance requirements,
Just a nit, but the standard doesn't set any performance requirements
for addition; I find addition quite usable anyway:-).
It's a nit, because I think Nathan is basically right, even if he
slightly overstated his case. The performance requirements of sort tell
us more or less what to expect in a quality implementation; as such, the
are very useful. They don't, of course, guarantee a quality
implementation, and they could easily be met by using bubble sort, and
adding extra loops when there are few elements in the list.
|> and it's hand-tunable for cases where those
|> requirements might be a problem. So, what's the problem?
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/28 Raw View
Jerry Coffin<jcoffin@taeus.com> wrote:
>In article <35914948.59E2@wizard.net>, kuyper@wizard.net says...
>
>> The specifications
>> that restrict the number of comparisons implicitly imply that
>> comparisons are the main operations that constrain the speed. If that's
>> not true for a given class of contained objects, you might need to use a
>> non-Standard container class.
... or specialize the standard container class for your object type.
>The question is: should that be the case? The answer (IMO) is NO,
>absolutely not!
Jerry, are you proposing an alternative? If not, what *are* you doing?
Either the standard specifies performance requirements for components,
based on assumptions about what operations are costly, or it omits the
requirements or the components. (I don't get the impression that you
feel the performance requirements are insufficiently detailed.) I don't
see any other alternatives.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1998/06/28 Raw View
ncm@nospam.cantrip.org (Nathan Myers) writes:
|> In early (and who knows, maybe current?) Microsoft C libraries,
|> qsort() had a worst-case linear _space_ requirement. (Of course
|> there's never any excuse for this.) But it conformed.
Question: wouldn't the same basic implementation conform to sort in the
C++ library? The only performance requirements I can find concern the
number of comparisons, not space.
I really think that Jerry Coffin's point is more that on small machines
(say 64KBytes maximum memory), the cut-off point where the average
performance of a quick sort is superior to the guaranteed performance of
e.g. a well written shell sort is likely to be higher than the number of
objects that can possibly fit in memory. It's been a long time ago, but
I once did a series of benchmarks, and if memory serves me right, on a
Sun3, the shell sort beat quick sort for anything less than about 100000
objects.
Given the very weak wording concerning the complexity requirements in
the standard, I think a shell sort would be a legal implementation on
such a small machine. After all, n^1.2 is approximately n log n for a
sufficiently loose definition of approximately. At any rate,
realistically, I can't imagine anyone complaining the the performance
was too good:-).
|> Many other
|> implementations were as bad, so common coding standards (e.g. at
|> Mentor Graphics in the late '80's) specified that qsort() must
|> not be used. Without complexity requirements in the Standard C++
|> Library, similar restrictions would have been reasonable.
Sorry, but in this case, I think it is the availability of free
implementations of a reasonable quality, which serves as an incentive
for commercial implementations to do better, and as a fall-back when
they don't, which makes such restrictions no longer necessary. (But for
application critical parts, I still insist on wrapping any standard
components in a wrapper with a narrow interface. The narrow interface
may allow optimizations which the standard interface doesn't, just in
case.) The standard complexity requirements allow me to have certain
expectations, but they really don't give a guarantee.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1998/06/28 Raw View
ncm@nospam.cantrip.org (Nathan Myers) writes:
|> Pete Becker <petebecker@acm.org> wrote:
|> >Nathan Myers wrote:
|> >> What would satisfy is efficient
|> >> compilers and libraries that don't impose overhead for unused features.
|> >
|> > It would be wonderful if ...
|> > all the C++ compilers and libraries don't impose overhead
|> > for unused features. ... Insisting that
|> > everyone should live in that fantasy world is madness.
|>
|> People get what they settle for.
Or more often, people settle for what they can get. If my customer has
to deliver code before the end of the year, an optimization which will
only be available next year won't help him.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/28 Raw View
Jerry Coffin<jcoffin@taeus.com> wrote:
> ncm@nospam.cantrip.org says...
>
>> Generally, if you have special knowledge about the type that is
>> being sorted, you can specialize std::sort() for that type and apply
>> any algorithm you want. Thus, std::sort() is usable as-is for almost
>> all purposes by almost all people, which wouldn't be the case without
>> performance requirements, and it's hand-tunable for cases where those
>> requirements might be a problem. So, what's the problem?
>
>The problem is that YOU, the coder, rarely know when you should do the
>hand-tuning, at least in portable code.
>
>The implementor knows more about the machine than you do. Based on
>that extra knowledge, the implementor can make more intelligent
>decisions about what sorting algorithm to you than you can.
It appears that Jerry has had very different experiences with
compiler implementers than I have.
>...
>In short, you've assumed that special knowledge of the TYPE is what's
>important here. I don't think that's correct at all -- nearly all
>that matters about the type is whether it's cheaper to compare or swap
>elements, which (surprise, surprise) the implementation can determine,
>and, once again, you can't in a portable fashion.
I don't see how an implementation can determine, in general,
the relative cost of my operator<() and my swap(). On the other
hand, I certainly can, typically with good portability.
Certainly there are other considerations than these. Jerry mentions
memory management overhead, which is a major headache precisely
because the performance costs are unpredictable and unspecified.
Portable performance tuning is a hard problem. Ideally we would
describe the characteristics of our types to a wise and optimal
implementation, and it would make our tradeoffs for us. We have
no language for such a description, and implementations tend to be
neither so wise nor so optimal (for our intended use) as we would
like.
Instead, we get implementation components which conform to some
guarantees, and we reason based on those requirements and what
we know, and are better off than without those guarantees. If
we need to do better, we break portability and measure the target
implementation.
Perhaps a future language will come with better (more precise,
more complete) guarantees, or better ways for us to describe our
tradeoffs so that it can choose better for us. I look forward
to using such a language. In the meantime, C++ offers better
performance tuning opportunities than any other language I know of.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: wkdugan@ix.netcom.com (Bill Dugan)
Date: 1998/06/28 Raw View
On 27 Jun 98 11:37:09 GMT, jcoffin@taeus.com (Jerry Coffin) wrote:
>In article <6mtjpa$k1$1@nnrp1.dejanews.com>, saroj@bear.com says...
>
>[ ... ]
>
>> I disagree! Whether to use linear search or not, should not be done
>> by the implementor of map, but should be decided by the programmer.
>
>Why? The implementor has already done exhaustive testing and proven
>that for the largest possible collection on this machine, that a
>linear search will _always_ be faster than a tree based lookup.
How many implementors actually make such guarantees? How could they?
Neither the compiler nor the library implementor know how much memory
is available on the machine where the program will run, so they don't
know what the largest possible collection will be. If the possible
targets include machines with so little memory that a linear search
will always be optimal, it's not practical to carry around the
machinery to make that decision at run time, and the programmer is the
only one who might have enough information to make it earlier.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/28 Raw View
In article <01bd9f8a$d1befd60$8a1ec2d0@porky>, "P.J. Plauger"
<pjp@dinkumware.com> writes
>
>DJL> Because (as has been said before) the C++ standard defines the language in
>DJL> such a way that it forces code bloat (at least in the library) that can't
>DJL> be prevented by just by "turning off" the parts you don't need.
>
>Could you supply a proof for this statement, please?
>
>#include <iostream>
>int main()
> {std::cout << "hello world" << endl;
> return 0; }
>
>Including <iostream> doesn't just declare cout, it declares cin, cerr, clog,
>wcin,
>wcout, wcerr, and wclog. Each of these objects can be used within a static
>constructor, so it has to be assuredly initialized in any translation unit that
>includes <iostream>. Perhaps there are techniques unique to each compiler
>and linker that can avoid dragging in code for each of these objects unless it
>is actually referenced, but I don't know about them. I certainly don't know any
>techniques that are likely to be at all portable. Isn't it nice to know that
>you've
>got three objects of class basic_ostream<wchar_t> at your beck and call in
>*every* program that includes <iostream>?
>
>Every one of these eight stream objects is ``imbued'' with a locale object.
>The default locale object contains references to 28 different facets, about
>half of which are only used for manipulating wide characters. Every facet
>has a fistful of virtual member functions (as do the different flavors of
>template class basic_streambuf associated with the eight stream objects).
>I think there are roughly 150 such protected virtuals. Maybe half a dozen
>of these are arguably needed if you insert or extract integers. Essentially
>none are needed for the toy program above. They nevertheless include
>the ability to read and write dates and monetary amounts using wide
>characters.
>
>Despite what has been said in this thread about what compiler vendors
>could or should do about unused virtuals, nearly all compilers in use today
>do not eliminate them.
But some do, which is an existance proof that it is possible to improve
other compilers to do the same optimisations.
>And even after eliminating all unused virtuals, the
>locale/facet machinery still drags in an extraordinary amount of cruft.
>EC++ omits wide streams, as well as the ability to switch from the default
>locale. That's how the library gets much of its savings. (We still compare
>favorably to older iostreams libraries as well, however, so that's not the
>whole story.)
>
>N.B. I do not consider this recitation a ``proof'' that the Standard C++ library
>specification forces code bloat. I simply observe that I haven't been able to
>avoid much of the bloat -- other than by providing an EC++ library -- and still
>work within the constraints of customers and their commercial compilers.
>Nor have any of our competitors, AFAIK. In fact, they usually do much worse.
>As we learn new techniques, Pete Becker and I keep making our products
>better. Meanwhile, the best we can do for our customers is offer a library
>that subsets the requirements of the C++ Standard fo avoid the bloat.
It seems to me that the provision of an extra library in addition to the
standard one is wholly to the advantage of your customers.
Borland supplies the source code to their libraries (or they used to
anyway), this allowed customers to compile the libraries with or without
rtti, exceptions etc etc to create the the right tradeoff for the
application at hand.
This is another possible method for allowing the customer to determine
what is acceptable/necessary for his individual circumstances.
What I don't think your argument supports is the requirement for a
language "subset", EC++. If compiler technology is lagging so that
conforming libraries have an unacceptable cost then by all means provide
your cuctomers with a solution (maybe based upon the methods above) for
this problem, but there is no requirement for a new standard that I can
see.
It still seems to me still to be better to provide switches to disallow
those features of C++ that a given compiler cannot implement
efficiently, this gives the *customer* the choice as to which features
to use. Surely you cannot disagree with the principle that the
application writer is a better person to judge what is an acceptable
cost for a given feature than the compiler vendor ?
It is far better IMO to allow customers to keep appplying the pressure
upon their compiler vendor for the parts of C++ that they need to be
efficiently implemented. That way you will have a market led rise in the
standard of C++ compiler implementations. I do not see that portability
should be exempt from this selection pressure as opposed to being
determined in advance by the fiat of a language sub-standard.
Cordially,
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/28 Raw View
In article <knii1.322$0T2.7405177@mothra.gol.ad.jp>, "David J.
Littleboy" <davidjl@gol.com> writes
>Mike Davies wrote in message ...
>>In article <JQih1.285$0T2.4990046@mothra.gol.ad.jp>, "David J.
>>Littleboy" <davidjl@gol.com> writes
>
>>I would be astonished if anybody in the low end embedded world
>>compiled a 20 line program in C++ and found it gave a 200k binary :-)
>>The way that happens is when compile against a (massive in your case)
>>library.
>
>Yup. Six STL headers. My point is that STL is not a viable programming
>style in the memory constrained subset of the embedded area.
You support your point with the incorrect statement that the STL was
responsible for your 200k program bloat.
Given that your statement is incorrect, how do you now support your
assertion that the STL is "not a viable programming style in the memory
constrained subset of the embedded arena" ?
I have use Watcoms' container classes in embedded applications, and my
perceptions of the code (eg in the debugger) were that it was no bigger
than any other method of obtaining that functionality would have been.
My understanding (I no longer have access to the Watcom compiler to
check) is that the STL has been implemented *more* efficiently than
this. I would use the STL on an 8-bit micro like a shot, if it were
available and if the application required the functionality. I don't
suppose I am a better programmer than the person who wrote the STL
anyway, so why should my own implementation of the functions be more
efficient ?
There are embedded systems that could not use printf() for that matter.
It has not been argued that there should be a standard subset of C that
omits these functions (which can also have an overhead if badly
implemented). Why should the fact that there are embedded systems that
cannot make use of every feature of C++ be taken as an argument for a
standard subset of C++ ?
>>You do not yourself make the fallacious inference that this is
>>*overhead*, as opposed to *cost* but somebody else might if I don't
>>point it out, so : that 200k has bought you something, if you write a
>>20k line program against the same library the cost looks better, I
>>bet.
>
>Yup. Like I said. STL is wonderful. My 6 headers got me strings, sort,
>cin and cout, vectors, set, and file streams. I paid 200k. Worth every
>byte of it and easily afforded since I'm running on a 160 MB machine.
I could show you a 3 line asssembler statement would generate 4Gbytes of
code ! This does not imply that assembler cannot be used in memory
constrained systems :-).
I am now going to make a prediction, I suppose I may get egg on my face
here, but I don't think so :
If you zip up your 20 line source program code, tell me which (standard,
remember) headers you are using and include the makefiles etc then I'll
have a go at compiling a shrunk version of the executable for you.
It would also be useful to include test harnesses if these are available
and a description of the function of the program.
I am genuinely interested in how you got a 200k program out of 20 lines.
Even coding for Win32 using the Borland V4.52 static library doesn't do
anything like that, and you are buying huge functionality with that
library.
The prediction of course is : You won't. Because you can't. Because your
statement is incorrect.
...snip...
>>EC++ would
>>>allow programmers in that world to start using a subset of C++ in the
>>>very near future.
>>
>>They can do that now by using C++. The difference is that they get to
>>choose the subset instead of having it foisted upon them by a compiler
>>vendor who is having difficulty doing for profit something that the
>>egcs group is doing very well for free.
>
>No, they can't. First someone's got to implement it for them.
They already have. Lots of C++ compilers have switches to dis-allow rtti
and exceptions while the compiler implementations are being improved.
I understand that the gnu tools have been retargetted to the Motorola
'HC11 family of 8-bit CPUs, I don't know how good the generated code is,
but why shouldn't these compiler vendors club together to implement an
8-bit optimised instruction scheduler for that compiler ?
>This is a point I wish you'd listen to more carefully. There are a
>large number of microcontroller manufacturers who do not have the
>manpower and financial resources to implement and support full C++.
>These are groups that are struggling just to support C. And these are
>the groups that are asking for a minimal C++ subset. My best guess is
>that there are more groups in this position (i.e. more proprietary
>architecture microcontrollers) than there are C++ implementations in
>the world. These groups just don't have the deep pockets of Sun, MS,
>Intel.
>In other words, EC++ is not being foisted on anyone by compiler
>vendors.
This is also incorrect. Intel haven't sold compilers for (eg
their 8051,90196, etc etc) microcontrollers for *years and years*.
They only sell the 80x86 compiler as an add-on to the Microsoft
development suite.
*Most* microcontroller mfrs don't sell compilers any more. They rely on
third parties like Keil et al to write compilers.
So EC++ *is* being promoted primarily by compiler vendors. Whether this
is "foisting" EC++ on anybody depends upon your point of view of course.
>The compiler vendors who are offering EC++ products are ones who
>primarily provide a C++ product.
Which makes it easy for them to implement the options/pragmas
*temporarily* needed to reduce the code size while they improve their
products. Particularly if they're already in place.
>Furthermore, any microcontroller group that can
>afford to support full C++ is going to have a large advantage, as soon
>as compiler technology appears, anyway, and can be expected to do so.
Not if all the other vendors have the phrase "fully (E)C++ standard
compliant" to hide behind. There have already been postings in this
thread where the important distinction between EC++ and C++ has not been
made clear where it should have been.
>It very much looks to me that at least some of the objection to EC++ is
>by people who don't want to admit that C++ has turned into a language
>that is large and complex enough to be seriously expensive to
>implement.
Your statement above said above that C++ has already been implemented,
by the same compiler vendors who are arguing for an EC++ language
standard, so I don't follow your argument.
>And the truth (of the current state of compiler technology) is that the
>advanced" features involve overheads and costs that aren't acceptable
>in (some sections of) the embedded area.
Unacceptable For the implementer, or for the user ?
If the user cannot use certain features for a particular compiler then
the user needs to be able to switch them out or to investigate other
compiler vendors products to see if they've been better implemented.
It is not my job as an embedded programmer to make it easy for compiler
vendors to avoid making the improvements to their products.
My job is to express my requirements unambiguously. The job of compiler
vendors is get on with the implementation of compilers that meet my
requirements.
>Insisting on full C++ forces a large number of microcontroller vendors
>to support a large number of language features that (at the current
>state of C++ compiler technology) either result in larger code or
>involve programming styles that aren't appropriate.
The programmer should be the judge of the appropriate programming style,
based upon the application and the tools at hand.
They will know what features of C++ they can afford to use if the
*compiler* vendor is honest and open about the costs of each feature.
That way if a memory constrained application *can* make use of a C++
feature that happens to be implemented well in a particular compiler
they can do so and reap the benefits.
...snip...
>If I were writing for a system with 64k of ROM, I would not have been
>able to use STL, and would have had to implement my program
>differently.
You might find that to get the same functionality by the same deadline
implementing it yourself would be bigger, not smaller, than using the
STL
>Reading in an ASCII text file and sorting the words could be
>implemented in a few k.
>It would be harder and take a lot more than 20 lines. The point is that
>since STL implies a programming style inappropropriate for memory
>limited situations,
This assertion is simply wrong.
>the cost of implementing and supporting STL are far in excess of
>the value it would provide _in the particular context of concern_.
No, your assertion requires that the STL be inefficient. It is not. Few
programmers could write code as good as library code in typical SW
timescales. The STL is a good example of facilities that should be made
available to memory constrained embedded developers.
...snip...
>EC++ is a _major_ improvement over C
No, EC++ is basically C with classes. This was developed into C++ as it
stands today at the request of the users themselves, who had found it
not to be sufficient!
(Source is one of Stroustrups books, they are not to hand at the moment
and I cannot remember which)
>, and for a lot of embedded
>programmers, opposition to EC++ means denying them _any_ form of C++
>whatsoever.
No, opposition to EC++ is denying compiler vendors the chance to make
minimal changes to their C compilers then stop with an unsatisfactory
language subset.
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/28 Raw View
In article <0RPj1.462$0T2.10740840@mothra.gol.ad.jp>, "David J.
Littleboy" <davidjl@gol.com> writes
>Jim Barry wrote in message
><898604025.3958.0.nnrp-01.9e98e8f6@news.demon.co.uk>...
>
>>Sure. It's fine for people to not use a language feature because it
>>costs too much or they just don't need it. When I don't need it, I
>>turn off RTTI to get my executable size down a bit, and I just don't
>>see why that sort of thing requires a new language definition.
>
>Because (as has been said before) the C++ standard defines the language in
>such a way that it forces code bloat (at least in the library) that can't be
>prevented by just by "turning off" the parts you don't need. At a minimum,
>you have to have a library that exactly matches the things you turn off.
No, this is incorrect, it is not the language standard, but the current
implementations of compilers (and not all of them, as has been reported
in this thread).
There is nothing to stop a compiler vendor from supplying several
versions of the library, Borland (and others) have done this in the past
for rtti, exceptions etc.
Wind River supply a completely modular library. This is not very up to
date, but it shows another way forward.
...snip...
>Whom EC++ really is for the benefit of is embedded hardware vendors who are
>put off at the current memory requirements of C++. It also happens that most
>of these hardware vendors are not convinced that the advanced features of
>the full language speak to their needs, and thus they aren't justified in
>supporting them from a cost/benefit standpoint.
I cannot think of a single mocrocontroller vendor who currently writes
their compilers in-house. All the currently available compilers I know
of for embedded use are written by independent compiler vendors.
Given that this is the case, how do you justify your statement that it
is embedded hardware vendors who have an interest in promoting EC++, not
compiler vendors ?
...snip...
>The programmers who might be using EC++ are programmers who's employer has
>decided to use a particular embedded microcontroller made by some hardware
>vendor. These machines largely have a unique instruction set and a large set
>of very random "peripheral functions" (A/D and D/A converters, timers,
>serial I/O controllers, LCD drivers) on the chip itself. That hardware
>vendor provides a software development environment, simply because no one
>else is going to. Right now, that's either assembler or C. When EC++
>replaces the assembler or C in these contexts, it would very much be to the
>benefit of the programmers.
I am an embedded programmer who has used existing (ie pre-standard) C++
compilers to write code for embedded systems. My experience has been the
opposite to the prospect that you depict. I have found that adding
classes to C makes very little difference to the support of OO
techniques. No sooner do you start to use OO techniques than you run
into the requirements for templates et al. It would be very soon after
purchasing an EC++ compiler that that the inadequacies of that language
subset became apparent to the programmer.
>By the way, EC++ is pretty draconian about slashing out C++ features, and I
>think it is this that causes a lot of the objections. However, I see that as
>good news. It means that there will be strong motivations to move to full
>C++ as soon as memory constraints allow. By dropping the cost of entry it
>increases that size of the C++ community, and by _not_ being "almost C++" it
>will be less likely to be mistaken for anything other than an interim
>measure.
And now I have heard everything. We are being asked to agree upon a
standard supported by the fact that it does *not* meet its users
requirements ! The deficiencies of the EC++ language subset are being
promoted as its advantages!
IMO the argument for EC++ is plainly bankrupt.
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/28 Raw View
In article <01bd9fcc$1ab29d60$8a1ec2d0@porky>, "P.J. Plauger"
<pjp@dinkumware.com> writes
>Martin v. Loewis <loewis@informatik.hu-berlin.de> wrote in article
><p6qbtri7gsx.fsf@pandora.fb-inf2>...
>> "P.J. Plauger" <pjp@dinkumware.com> writes:
>> > Including <iostream> doesn't just declare cout, it declares cin, cerr,
>> > clog, wcin, wcout, wcerr, and wclog. Each of these objects can be used
>> > within a static constructor, so it has to be assuredly initialized in
>> > any translation unit that includes <iostream>.
>>
>> How so? <iostream> is only required to declare these objects, not to
>> define them (27.3). If the object is declared but not used, it does
>> not need to be defined (3.2). If the object is not defined, it is
>> certainly not initialized.
>>
>> So I can't see why the wide-character support code must be linked to
>> the program given above.
>
>I agree -- almost. I just don't know how to ensure that they are defined, and
>initialized, before they are referenced in a static constructor; but to generate
>no additional references to them unless someone else references them first.
>So far, I haven't figured out how to avoid executable code in the initializers
>for the iostreams objects.
As a consumer of compilers, not a producer of them, I am speaking
entirely out of turn here so please forgive me if what I say doesn't
make any sense :-)
Why cannot the linker do some form of reference counting before it
decides to instanciate code in the initialisers for the iostreams
objects ? Can't you use a weak reference in the iostream's initialiser ?
Or am I missing the point here ?
>As always, I will enjoy being educated.
Probably not by me, though :-)
Regards,
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/25 Raw View
Pete Becker <petebecker@acm.org> wrote:
>Nathan Myers wrote:
>> What would satisfy is efficient
>> compilers and libraries that don't impose overhead for unused features.
>
> It would be wonderful if ...
> all the C++ compilers and libraries don't impose overhead
> for unused features. ... Insisting that
> everyone should live in that fantasy world is madness.
People get what they settle for.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1998/06/25 Raw View
In article <35918C0D.1CFB@wizard.net>, kuyper@wizard.net says...
[ ... ]
> Saying it doesn't make it so. There is a big difference between no
> information and little information. The small amount of information the
> standard does provide is very nearly the only information that could
> have portable meaning.
You're right: saying it doesn't make it so. However, I notice that
nobody's attempted to refute the examples I've given where the
information given is actively misleading. Information that may be
actively misleading I suppose can be said to have some meaning, but it
certainly doesn't have any portable _use_.
> If you don't care about portability, and do care
> about optimization, then you look at other implementation specific
> measures such as the actual amount of time taken. Portable code should
> not be optimized for a particular machine; it should be optimized only
> in the algorithmic sense, and that is what the standard's operation
> count requirements allows.
The whole problem is that it DOESN'T allow one to make sensible
decisions. We're left with the worst of both worlds: the programmer
HAS to decide what to do, but is deprived of the information necessary
to do so. The implementation HAS the information necessary to make
sensible decisions, but is deprived of the ability to do so.
> > Why? If the implementor is writing a map<> class for a machine that
> > supports only 128 bytes of RAM (they DO exist, and remember that much
> > of the discussion centers around suitability to just such systems) and
> > a relatively small amount of ROM, a linear search might be perfectly
> > reasonable.
>
> I'm unlikely to be porting code to and from such a machine. Any code I
> wrote for such a machine would be heavily optimized for that particular
> machine. I referred specifically to portable code.
However, of the major ideas of the standard is to allow portability to
nearly as wide a range of machines as possible. One with 128 bytes of
RAM might be a bit beyond what the anybody would try to program in C++
and I guess I don't expect to do so either.
At the extreme, you've got machines that you nearly have to program in
assembly language. Next, you've got a class of machines that could
sensibly run portable code if the complexity requirements in the
standard didn't exist. Then you've got still larger machines that can
typically meet the complexity requirements of the standard, but little
more. Finally, you've got really high-end machines that could do even
better, but are being handicapped by the requirements of the standard.
The first group doesn't concern us much. However, the second and
fourth are served well by removing the requirements from the standard.
When we do this, it causes no harm to the second group.
> Hashing belongs in the library; so do binary trees. Hashing, in order to
> be usable in a standard library, needs to have lots of adjustable
> parameters and options to be customized for different applications.
To put it simply, I don't buy this at all. Just for example, the map-
like classes in Smalltalk have been based on hashing for years. I
don't recall them having anything in the way of parameters and options
to adjust them for different applications, but they generally work
very nicely indeed. Virtually everybody doing a C++ library seems to
consider adding hashing based maps a necessity, while nobody doing
Smalltalk libraries seems to find any reason to add tree based maps at
all.
> And how many copies of this implementation do you think could be sold
> using such a method? That would be horrendously inefficient! I'm willing
> to let market pressures weed out such cases; I'm not going to worry
> about them.
I believe I already stated that it would be market pressure rather
than decree of standard that weeded out the inefficient cases. The
problem is that to provide really high efficiency right now, the
vendor has to do so with non-standard extensions and/or a library that
doesn't meet the complexity requirements of the standard.
> I'm not worried about implementors faking compliance by such
> methods. I'm worried about implementors taking short cuts by using a
> simpler but slower algorithm than the one that was used as a basis for
> setting the required operation counts. In every case, those operation
> counts were based upon someone being aware of a feasible implementation
> that met those requirements.
Why are you "worried" about this? Just picking an obvious instance,
have you seen lots of C standard libraries that used, say, a bubble
sort to implement their qsort() function?
The fact is, implementations of at least this part of the standard are
being given away with virtually no strings attached at all. The free
implementation from SGI (to name an obvious example) is good enough to
prevent most people from turning out really lousy versions of this
part of the library -- therefore, if somebody chose, for example, to
use a Shell-Metzner sort instead of one with O(N logN) complexity, it
seems apparent to me that they just about HAD to make a conscious
decision to do so. The rule against doing so in the standard
basically says that the implementor is too stupid to be able to make
an intelligent, informed decision, so (s)he must be prevented from
making any decision at all.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: mtobler@no-spam-ibm.net (Michael J. Tobler)
Date: 1998/06/25 Raw View
In article <35924B9D.EEFC43F3@acm.org>, petebecker@acm.org said...
[snip]
> It would be wonderful if we all lived in Lake Wobegon, where all the men
> are strong, all the women are good looking, all the children are above
> average, and all the C++ compilers and libraries don't impose overhead
> for unused features. Most of us don't live there, though. Insisting that
> everyone should live in that fantasy world is madness.
I seem to remember that the Topspeed products were very good at this. I
had, in my arsenal, the C, C++, and Modula-2 packages plugged into their
environment. The linker was very good at removing unwanted "stuff".
Topspeed usually won top honors for speed of compile/link, and speed/size
of the executable it produced. You could also do inter-language
development very easily. Too bad their marketing was in a slump.
--
<<<<<<<<<< Blue Skies >>>>>>>>>>>
< Michael J. Tobler >
< mtobler@no-spam-ibm.net >
< remove "no-spam-" when replying >
<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: saroj@bear.com
Date: 1998/06/25 Raw View
In article <MPG.ffaf3b99d1111b7989b46@news.rmi.net>,
jcoffin@taeus.com (Jerry Coffin) wrote:
>
> In article <358FC442.41C6@wizard.net>, kuyper@wizard.net says...
>
> [ ... ]
>
> > The implementor can provide any non-standard trade-offs they want, as
> > extensions to the standard. What the complexity requirements do is
> > provide programmers with a way of knowing something about what the
> > trade-offs will be for a design choice relating to the STL, something
> > that will remain true no matter where the code is ported to.
>
> As I've repeatedly pointed out, this simply isn't true -- in most
> cases the requirements tell you nothing, but give you a false sense of
> security.
>
> > There is no
> > way I would be willing to use a map<> class for portable code if I
> > thought that implementors were free to use a linear search for every
> > access; I'd roll my own binary-tree implementation, and ignore the
> > standard.
>
> Why? If the implementor is writing a map<> class for a machine that
> supports only 128 bytes of RAM (they DO exist, and remember that much
> of the discussion centers around suitability to just such systems) and
> a relatively small amount of ROM, a linear search might be perfectly
> reasonable.
>
I disagree! Whether to use linear search or not, should not be done
by the implementor of map, but should be decided by the programmer.
The implementor should provide vector (contiguous), linked list,
a balanced-tree map, a hash map. The programmer should decide when
to use which container.
> The fact is, the marketplace (NOT the requirements of the standard)
> are going to determine the efficiency of libraries that people use.
> If you simply specified that map<> would do keyed lookup and left it
> at that, chances are that 99% of the implementations would use hash
> tables, providing FAR better access speed than the present version.
>
Again hammer and nail syndrome. Hash table is not the universal solution.
map makes stronger guarantees than the hash_map : a map stores its
elements in the sorted order. You need a sorted container (be it map
or a sorted vector or list) for efficient implementation of set_union,
set_intersection and several other algorithms. If you think carefully,
you will see need for different containers in different situations.
I advise reading Knuth Vol. 3 about the tradeoffs he mentions about
balanced tree vs. array, but the writing is equally applicable to other
containers.
> > False - you cannot decrease the computational complexity by adding
> > operations. By definition, computational complexity is measured in the
> > limit of arbitrarily large N.
>
> By definition, conformance with the standard is measured on real
> implementations on real machines, where arbitrarily large N is simply
> impossible. An implementor who chooses to do so, can find the largest
> collection possible on a real machine, and make operations on even the
> smallest collections take as long as those on the largest one possible
> on the implementation, providing constant time for ALL operations.
>
> Ultimately, this doesn't affect conformance with the standard, since
> it's mostly defined in terms of number of elementary operations rather
> than time taken. However, for practical purposes, the number of
> operations involved is interesting ONLY to the extent that it
> indicates the amount of time the algorithm will take.
>
It is useful to specify the computational complexity in STL. One sort
method is not always the best, but the standard provides one with specified
worst case behavior. In most situations, you can just use the standard
library sort, and rest of the times, use your own sort (heap/selection/
shell/...).
- Saroj Mahapatra
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: saroj@bear.com
Date: 1998/06/25 Raw View
In article <01bd9fcc$1ab29d60$8a1ec2d0@porky>,
"P.J. Plauger" <pjp@dinkumware.com> wrote:
>
> Martin v. Loewis <loewis@informatik.hu-berlin.de> wrote in article
<p6qbtri7gsx.fsf@pandora.fb-inf2>...
> > "P.J. Plauger" <pjp@dinkumware.com> writes:
> > > Including <iostream> doesn't just declare cout, it declares cin, cerr,
clog, wcin,
> > > wcout, wcerr, and wclog. Each of these objects can be used within a static
> > > constructor, so it has to be assuredly initialized in any translation unit
that
> > > includes <iostream>.
> >
> > How so? <iostream> is only required to declare these objects, not to
> > define them (27.3). If the object is declared but not used, it does
> > not need to be defined (3.2). If the object is not defined, it is
> > certainly not initialized.
> >
> > So I can't see why the wide-character support code must be linked to
> > the program given above.
>
> I agree -- almost. I just don't know how to ensure that they are defined, and
> initialized, before they are referenced in a static constructor; but to
generate
> no additional references to them unless someone else references them first.
> So far, I haven't figured out how to avoid executable code in the initializers
> for the iostreams objects.
>
> As always, I will enjoy being educated.
>
In the worst case, the programmer can have
-features=no%wchar
to disable wchar stuff.
In the best case, I expect the compiler and library vendor to do the
required research and make sure that the initialization code is put in
different object file (much like template repository), use the vendor
specific initialization pragma (to make sure those objects are
initialized (if linked with the program at all)), and not link the
initialization code at all if not needed. Floating point stuff is
also platform specific. Does that mean you will not implement any
floating point routines for a library?
To do otherwise, will be like Microsoft saying if you want to use
std::list<Person>, just define operator<, operator= in struct Person,
because it is too difficult for us to determine what template stuff
are needed and what are not.
I have heard complains in this thread that if you want to just output an
integer, you do not need many things. I know it and I, as a programmer,
can decide whether I want to use streams (which provides a lot of
control of formatting, local etc) or just use K&R program itoa for
simple output.
Cheers,
Saroj Mahapatra
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/26 Raw View
Michael J. Tobler wrote:
>
> In article <35924B9D.EEFC43F3@acm.org>, petebecker@acm.org said...
> [snip]
> > It would be wonderful if we all lived in Lake Wobegon, where all the men
> > are strong, all the women are good looking, all the children are above
> > average, and all the C++ compilers and libraries don't impose overhead
> > for unused features. Most of us don't live there, though. Insisting that
> > everyone should live in that fantasy world is madness.
>
> I seem to remember that the Topspeed products were very good at this. I
> had, in my arsenal, the C, C++, and Modula-2 packages plugged into their
> environment. The linker was very good at removing unwanted "stuff".
> Topspeed usually won top honors for speed of compile/link, and speed/size
> of the executable it produced. You could also do inter-language
> development very easily. Too bad their marketing was in a slump.
Yes, they did fairly well at that in the early days. That's not today,
however.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Valentin Bonnard <bonnardv@pratique.fr>
Date: 1998/06/23 Raw View
<jkanze@otelo.ibmmail.com> writes:
> Exceptions also introduce unexpected program flow in your program.
Exceptions introduce syntax-free program flow in your program,
granted.
Now is it a problem ? If you want to understand a function w/o
getting lost in the error handling, it is actually an advantage.
If you want to prove the correctness of error handling code,
you are arguing that it's a problem. (Correct me if I am wrong.)
Perhaps what is needed are 'reading levels' ? You read the code
at the no exceptions level, the what appens if xxx level, the
prove everything level... (you could _perhaps_ model a reading
level as an abstraction function (don't know, just an idea from
the top of my head [1]))
At a simple reading level, you want to keep things simple. At
a finer level, you want to know more details.
Example: a math function. First you want to prove that the
function computes the correct number in IR (or IN, IQ...)
Then, at a finer level you want to check the approximation
made by float/double/long double.
What do you think about that ?
[1] the idea of the relation between abstract interpretation
and reading levels may be completly silly, it's late, I am
not sure...
--
Valentin Bonnard mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <david.tribble@noSPAM.central.beasys.com>
Date: 1998/06/23 Raw View
David J. Littleboy wrote:
> It very much looks to me that at least some of the objection to EC++
> is by people who don't want to admit that C++ has turned into a
> language that is large and complex enough to be seriously expensive to
> implement. And the truth (of the current state of compiler technology)
> is that the "advanced" features involve overheads and costs that
> aren't acceptable in (some sections of) the embedded area.
C++, the PL/1 of the 90s.
(But at least PL/1 had formal subsets that compiler vendors were
allowed to support.)
-- David R. Tribble, david.tribble@central.beasys.com --
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <david.tribble@noSPAM.central.beasys.com>
Date: 1998/06/24 Raw View
James Kuyper <kuyper@wizard.net> writes:
>> With the originally stated definition, I doubt that GCD-C++ is a
>> large enough language to be useful.
Really? That's a shame, because that's what we have today. That
was my original point, by the way: that the compilers we use today
define the subset of C++ I call GCD-C++. Perhaps the millions of
lines of C++ code running today aren't written in a really useful
language?
James Kuyper:
>> In particular, it cannot contain
>> <iostreams>, because that isn't supported by the older versions of
>> C++, and it can't contain <iostreams.h> because that isn't supported
>> by the draft ISO C++ standard.
J. Kanze wrote:
> But it still could use stdio.h.
Indeed. The project I work on has 600,000 lines of C++ code in
some 1,800 source files, and we seem to manage I/O just fine (using
both stdio and iostreams as appropriate).
-- David R. Tribble, david.tribble@central.beasys.com --
C++, the PL/1 of the 90s.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Gabriel Dos Reis <dosreis@DPTMaths.ens-cachan.fr>
Date: 1998/06/24 Raw View
>>>>> =ABDJL=BB, David J Littleboy <davidjl@gol.com> wrote:
DJL> Because (as has been said before) the C++ standard defines the langu=
age in
DJL> such a way that it forces code bloat (at least in the library) that =
can't be
DJL> prevented by just by "turning off" the parts you don't need.
=09
Could you supply a proof for this statement, please?
-- Gabriel
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/24 Raw View
David J. Littleboy<davidjl@gol.com> wrote:
>
>Because (as has been said before) the C++ standard defines the language in
>such a way that it forces code bloat (at least in the library) that can't be
>prevented by just by "turning off" the parts you don't need.
This "has been said before", but not demonstrated.
It doesn't matter how many times it's said, it's still false.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: fjh@cs.mu.OZ.AU (Fergus Henderson)
Date: 1998/06/24 Raw View
Christopher Eltschka <celtschk@physik.tu-muenchen.de> writes:
>Fergus Henderson wrote:
>>
>> Matt Austern <austern@sgi.com> writes:
>>
>> >(And yes, it's true that set<> doesn't use hash tables. The
>> >requirements forbid it: set has guaranteed logarithmic worst-case
>> >complexity, and hash tables can't guarantee anything better than
>> >linear worst-case complexity.
>>
>> ... unless you use a hash table whose nodes are some kind of balanced
>> binary tree structure, e.g. red-black trees. Then you get linear
>> average-case and logarithmic worst-case. Of course the constant factors
>> may be worse.
>
>Ahem... you say that average-case is worse than worst-case? :-)
Sorry, I meant constant time average case. I should also have added that
this is assuming the hash function is sufficiently well distributed.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Jim Barry" <jim.barry@bigfoot.com>
Date: 1998/06/24 Raw View
David J. Littleboy wrote in message
<0RPj1.462$0T2.10740840@mothra.gol.ad.jp>...
>
>Because (as has been said before) the C++ standard defines the language in
>such a way that it forces code bloat (at least in the library) that can't be
>prevented by just by "turning off" the parts you don't need. At a minimum,
>you have to have a library that exactly matches the things you turn off.
What is to stop a full C++ implementation from doing that?
>The only vendors who sell an EC++ package are vendors who's main product is
>a full C++ compiler and/or library. No one in the compiler or library market
>makes only EC++ products.
So if all the vendors already have a full C++ compiler, then (assuming
that 'expensive' language features can be disabled) what is the
purpose of EC++?
>EC++ is being designed
>for environments where C++ is currently unavailable. As such, it will very
>rarely replace C++. It will be replacing assembler or C, and as such will be
>welcomed.
Indeed. But...
>EC++ is pretty draconian about slashing out C++ features, and I
>think it is this that causes a lot of the objections.
Yes. EC++ claims to be all about reducing overheads, then throws out
zero-overhead features like templates and namespaces.
- Jim
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/06/24 Raw View
Jim Barry wrote:
>
> J. Kanze wrote in message ...
> >
> >The C++ exception mechanism is a mechanism for reporting errors. Or
> are
> >you claiming that it helps detect them, or handle them, as well.
>
> Yes, I am claiming that exceptions help enormously with error
> handling. Maybe we are at cross-purposes here; by errors, I mean stuff
> like i/o failures, and I am talking about the capability of recovering
> cleanly from such failures. Perhaps you mean programming errors.
>
> >Obviously. So perhaps "unexpected" wasn't the right word. Although
> >there is certainly nothing in the code for a function call that
> >indicates that we might suddenly go to the end of the function,
> without
> >executing the following code.
>
> That is what exception-specifications are for. A function makes a
> contract by publishing in its declaration a list of exceptions that it
> might throw, directly or indirectly. A function which calls that
> function is required either to handle those exceptions or let them
> "pass through" by listing them in its own exception-specification. Use
> of the "resource acquisition is initialisation" technique (CPL3,
> 14.4)prevents leakage.
>
Unfortunately, strict specification checking fails for templates,
since there's no way to "propagate" exception specifications.
For example, the following code:
template<class T> T min(T const& t1, T const& t2) throw (what???)
{
return t1<t2? t1 : t2;
}
The exceptions which may leave the template clearly depend on T.
More exactly, they are the union of the exceptions which may be
thrown by T::operator< and the copy constructor of T.
However, it can get more complicated, if the function handles
certain kind of exceptions which might be thrown by T, but
lets others through, and maybe in addition throws some exceptions
on its own.
To handle all that, you'd have to have a way to say "This template
may throw whatever the operations xy on T throw, except the exceptions
a,b,c and d, and in addition it may throw f and g."
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/24 Raw View
David R Tribble <david.tribble@noSPAM.central.beasys.com> wrote:
>
>C++, the PL/1 of the 90s.
There were no free, portable PL/1 compilers.
There are at least two free, portable full C++ compilers.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/06/24 Raw View
David J. Littleboy wrote:
>
> Jim Barry wrote in message
> <898604025.3958.0.nnrp-01.9e98e8f6@news.demon.co.uk>...
>
> >Sure. It's fine for people to not use a language feature because it
> >costs too much or they just don't need it. When I don't need it, I
> >turn off RTTI to get my executable size down a bit, and I just don't
> >see why that sort of thing requires a new language definition.
>
> Because (as has been said before) the C++ standard defines the language in
> such a way that it forces code bloat (at least in the library) that can't be
> prevented by just by "turning off" the parts you don't need. At a minimum,
> you have to have a library that exactly matches the things you turn off.
>
Well, maybe the best definition for a good EC++ standard would be:
A *full* C++ implementation which *additionally* has the option to
turn certain costy features (like EH and RTTI) off, and has the EC++
standard library in addition to the C++ standard library. This would
satisfy all people, I think.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/06/24 Raw View
Gabriel Dos Reis <dosreis@DPTMaths.ens-cachan.fr> wrote in article <v8v90mnw3fe.fsf@piano.dptmaths.ens-cachan.fr>...
>>>>> DJL , David J Littleboy <davidjl@gol.com> wrote:
DJL> Because (as has been said before) the C++ standard defines the language in
DJL> such a way that it forces code bloat (at least in the library) that can't be
DJL> prevented by just by "turning off" the parts you don't need.
Could you supply a proof for this statement, please?
#include <iostream>
int main()
{std::cout << "hello world" << endl;
return 0; }
Including <iostream> doesn't just declare cout, it declares cin, cerr, clog, wcin,
wcout, wcerr, and wclog. Each of these objects can be used within a static
constructor, so it has to be assuredly initialized in any translation unit that
includes <iostream>. Perhaps there are techniques unique to each compiler
and linker that can avoid dragging in code for each of these objects unless it
is actually referenced, but I don't know about them. I certainly don't know any
techniques that are likely to be at all portable. Isn't it nice to know that you've
got three objects of class basic_ostream<wchar_t> at your beck and call in
*every* program that includes <iostream>?
Every one of these eight stream objects is ``imbued'' with a locale object.
The default locale object contains references to 28 different facets, about
half of which are only used for manipulating wide characters. Every facet
has a fistful of virtual member functions (as do the different flavors of
template class basic_streambuf associated with the eight stream objects).
I think there are roughly 150 such protected virtuals. Maybe half a dozen
of these are arguably needed if you insert or extract integers. Essentially
none are needed for the toy program above. They nevertheless include
the ability to read and write dates and monetary amounts using wide
characters.
Despite what has been said in this thread about what compiler vendors
could or should do about unused virtuals, nearly all compilers in use today
do not eliminate them. And even after eliminating all unused virtuals, the
locale/facet machinery still drags in an extraordinary amount of cruft.
EC++ omits wide streams, as well as the ability to switch from the default
locale. That's how the library gets much of its savings. (We still compare
favorably to older iostreams libraries as well, however, so that's not the
whole story.)
N.B. I do not consider this recitation a ``proof'' that the Standard C++ library
specification forces code bloat. I simply observe that I haven't been able to
avoid much of the bloat -- other than by providing an EC++ library -- and still
work within the constraints of customers and their commercial compilers.
Nor have any of our competitors, AFAIK. In fact, they usually do much worse.
As we learn new techniques, Pete Becker and I keep making our products
better. Meanwhile, the best we can do for our customers is offer a library
that subsets the requirements of the C++ Standard fo avoid the bloat.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "David J. Littleboy" <davidjl@gol.com>
Date: 1998/06/24 Raw View
Jim Barry wrote in message
<898685899.10880.0.nnrp-03.9e98e8f6@news.demon.co.uk>...
>David J. Littleboy wrote in message
>>The only vendors who sell an EC++ package are vendors who's main product
is
>>a full C++ compiler and/or library. No one in the compiler or library
market
>>makes only EC++ products.
>
>So if all the vendors already have a full C++ compiler, then (assuming
>that 'expensive' language features can be disabled) what is the
>purpose of EC++?
Two. First, if what I've read here is correct, that assumption is wrong (at
least) for current compiler technology, so something is needed, at least in
the short term. Second, C++ is seen as being large, complex, difficult (and
thus expensive) to implement and support, and full of features that are not
relevent to memory limited embedded applications. Ignoring the question of
which of those fears are justified and which aren't, it seems obvious that a
low cost-of-entry version of C++ would allow a lot of resource limited mfgrs
of memory limited microcontrollers to provide (very good) OO programming to
their customers' programmers.
>>EC++ is being designed
>>for environments where C++ is currently unavailable. As such, it will very
>>rarely replace C++. It will be replacing assembler or C, and as such will
be
>>welcomed.
>
>Indeed. But...
>
>>EC++ is pretty draconian about slashing out C++ features, and I
>>think it is this that causes a lot of the objections.
>
>Yes. EC++ claims to be all about reducing overheads, then throws out
>zero-overhead features like templates and namespaces.
My axe to grind is cost of entry. My (translation) customers look pretty
stressed just providing C, so I'm sympathetic to the idea of keeping it
simple. Besides, the more stuff *not* included, the greater the incentive to
move on to full C++. A lot of people like the idea that EC++ should add
features as the technology develops for making them practical in the
embedded world. However, it seems to me that fixing it at the pre-template
level and waiting for full C++ compiler technology improves would be far
better, from the incentive standpoint, as well as keeping it clear that EC++
really is only for extremely memory constrained applications that are so
special-purpose that there just aren't any relevant third party libraries.
David J. Littleboy <davidjl@gol.nonspam.com>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/06/24 Raw View
Jim Barry <jim.barry@bigfoot.com> wrote in article <898685899.10880.0.nnrp-03.9e98e8f6@news.demon.co.uk>...
> David J. Littleboy wrote in message
> <0RPj1.462$0T2.10740840@mothra.gol.ad.jp>...
> >
> >Because (as has been said before) the C++ standard defines the language in
> >such a way that it forces code bloat (at least in the library) that can't be
> >prevented by just by "turning off" the parts you don't need. At a minimum,
> >you have to have a library that exactly matches the things you turn off.
>
> What is to stop a full C++ implementation from doing that?
Speaking on behalf of a library vendor has a full implementation of the C++ library,
as well as a commercial EC++ library ... In a sense, that's exactly what we've done.
Turning off a particular set of parts, such as locales and facets, yields significant
improvements in code size for a broad class of programs. We also provide the
*option* of turning off exception handling in the library, which has a dramatic
effect on code size for an even broader class of programs. We call our slimmest
version an EC++ library because it meets the requirements of that spec.
> So if all the vendors already have a full C++ compiler, then (assuming
> that 'expensive' language features can be disabled) what is the
> purpose of EC++?
The vendors currently shipping EC++ have fairly full C++ compilers, AFAIK,
but that will not always be true. We have at least two customers for the EC++
library so far who do not. The purpose of the EC++ spec is to define a common
subset that programmers can depend upon from multiple vendors. Programmers
who care about such portability will stay within the spec, and use the checking
features now in many compilers to ensure that they do so. Other programmers
will use the EC++ library for its efficiency along with whatever added language
features they consider desirable. They will even use STL if their compilers
have adequate template support -- it's one of our most popular add-ons.
> >EC++ is being designed
> >for environments where C++ is currently unavailable. As such, it will very
> >rarely replace C++. It will be replacing assembler or C, and as such will be
> >welcomed.
>
> Indeed. But...
>
> >EC++ is pretty draconian about slashing out C++ features, and I
> >think it is this that causes a lot of the objections.
>
> Yes. EC++ claims to be all about reducing overheads, then throws out
> zero-overhead features like templates and namespaces.
No, it doesn't. Reducing overheads is an important goal of EC++, particularly
in the library, but it is not the only goal. Having a practical common subset,
given today's compiler technology, is an orthogonal goal that is also important
in certain contexts.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1998/06/24 Raw View
In article <6mmdk8$1re$1@shell7.ba.best.com>, ncm@nospam.cantrip.org
says...
[ ... ]
> A system that used a different algorithm for small ranges (or even
> for small subranges of larger, partitioned, ranges) to get better
> performance would be entirely conforming. What is specified is the
> maximum number of operations; if for small N the same effect could
> be achieved by a more-efficient algorithm, the spec doesn't quibble.
Yes it DOES! First of all, the standard specifies the maximum number
of comparisons rather than total operations. Second, with very small
collections, even algorithms that make more comparisons than allowed
may be faster overall than ones that make fewer comparisons. Imagine
the overhead involved in doing, say, a heapsort on 10 items. Compare
that to using an insertion or selection sort on the same 10 items.
The latter will make more comparisons than allowed, but will be
finished before the heap-creation phase of the heap-sort is finished.
> Of course it is very common for quicksort implementations to use
> this two-stage process, using a different sort for ranges of four
> elements or fewer. The break-even point depends on how expensive
> a comparison and a swap are, and unfortunately the STL has no way
> to measure these. Still, for small-enough N even that doesn't matter.
It's very common, but the standard will NOT allow it in some cases --
even if the overall effect is higher speed, if it increases the number
of comparisons, the result is a non-conforming implementation.
> The current SGI STL (3.1 -- get it if you haven't yet) uses a
> threshold of N = 16.
Yup. Are you sure it conforms? I haven't looked -- if it uses an
insertion sort for small N, it may still conform. If it uses a
selection sort instead (which may be faster when swapping objects is
non-trivial) it almost certainly WON'T conform to the requirements
anymore.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/06/24 Raw View
In article <898604025.3958.0.nnrp-01.9e98e8f6@news.demon.co.uk>,
"Jim Barry" <jim.barry@bigfoot.com> wrote:
>
> J. Kanze wrote in message ...
> >
> >The C++ exception mechanism is a mechanism for reporting errors. Or
> are
> >you claiming that it helps detect them, or handle them, as well.
>
> Yes, I am claiming that exceptions help enormously with error
> handling. Maybe we are at cross-purposes here; by errors, I mean stuff
> like i/o failures, and I am talking about the capability of recovering
> cleanly from such failures. Perhaps you mean programming errors.
I mean any serious error. I don't see where exceptions can help either
in detection or handling. I don't even see where they claim to.
Read very carefully what I have said, and then explain in what way
exceptions can help in handling (not propagating) the error.
> >Obviously. So perhaps "unexpected" wasn't the right word. Although
> >there is certainly nothing in the code for a function call that
> >indicates that we might suddenly go to the end of the function,
> without
> >executing the following code.
>
> That is what exception-specifications are for. A function makes a
> contract by publishing in its declaration a list of exceptions that it
> might throw, directly or indirectly. A function which calls that
> function is required either to handle those exceptions or let them
> "pass through" by listing them in its own exception-specification.
I agree. But the standard doesn't allow the compiler to verify this;
throwing an exception which isn't listed in the exception specification
has defined semantics according to the standard. A compiler is required
to generate code, even if I do it, and execute the defined semantics.
> Use
> of the "resource acquisition is initialisation" technique (CPL3,
> 14.4)prevents leakage.
It helps in certain situations, but it is certainly not a panacea. In
many, if not most, cases, you need some sort of concept of transactions,
with a complete roll-back.
> >A C++ compiler is not allowed (by the language) to check exception
> >specifications. (Of course, it could generate a warning.)
>
> I don't understand. If the compiler cannot check
> exception-specifications then what are they for? To quote Stroustrup
> CPL3, 14.6.1: "Importantly, exception-specifications are not required
> to be checked exactly across compilation-unit boundaries. Naturally,
> an implementation can check."
FDIS, 15.4/10: "An implementation shall not reject an expression merely
because when executed it throws or might throw an exception that the
containing function does not allow."
> >Since Bjarne has admitted that using a subset is sometimes
> appropriate,
> >I would caracterize our disagreement as one concerning the level at
> >which this subset should be defined. I also recognize the arguments
> he
> >presented as very legitimate concerns, which should be taken into
> >account -- they are very strong arguments against standardization at
> the
> >ISO level. I find them less determining when it is a question of a
> >definition by an association of vendors in a very particular, very
> >limited market subsegment.
>
> Sure. It's fine for people to not use a language feature because it
> costs too much or they just don't need it. When I don't need it, I
> turn off RTTI to get my executable size down a bit, and I just don't
> see why that sort of thing requires a new language definition. It
> seems to me that EC++ is for the benefit of compiler writers who
> (understandably) want to avoid implementing the trickier parts of the
> language, but still be able to put a sticker on the box saying
> "standard-conforming". It's certainly not for the benefit of
> programmers, and I don't think it should be touted as such.
If I have to write programs for a specific environment, it is definitly to
my benefit to know what features are likely to be present and work, and
which ones aren't. If I am only concerned with one compiler, then I
work to a description written by that compiler vendor (or determined
by experimentation, if the vendor is too lazy to provide the description).
If I have to write for several processors, then having a common specification
as to what I can expect is an advantage -- first, because I don't have to
determine it myself through trial and error, and second, because I also
have a specific engagement from the vendor that it will be available and
reasonable to use.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1998/06/24 Raw View
In article <6mmejl$6lu$1@shell7.ba.best.com>, ncm@nospam.cantrip.org
says...
[ computation complexity guarantees on standard algorithms... ]
> >I guess in theory this was done to guarantee that all programs would
> >be efficient. ...
>
> No, that's not it at all.
>
> It was done to permit programs to have predictable, and therefore
> analyzable and optimizable, performance.
Unfortunately, it doesn't do that. For a given collection, the
computation complexity doesn't necessarily tell you anything. If your
collections are always (or at least typically) very large, it starts
to mean something, but otherwise, it can end up meaningless and
useless to the programmer, while preventing the implementor from
making sound decisions based on their superior knowledge of their
environment. It's my experience that many (if not most) collections
are too small for the computational complexity to be a meaningful
indicator of the speed of an operation.
> If you don't know how expensive an operation is, you can't make
> tradeoffs.
The problem is that knowing the computational complexity does NOT let
you know about how expensive an operation is, especially with the
typical (fairly small) collection.
> Even if the standard library operation hasn't the complexity you want
> for a particular use, at least you know what it is, and you know to
> substitute a different algorithm for the (rare) case where the
> standard heuristic is wrong.
The problems here are too numerous to go into detail on each one, so
I'll give only one extremely obvious example, based on the collection
classes.
Adding items to a vector is required by the standard to have amortized
constant computational complexity. Most real computers either have a
large virtual memory, or have quite limited physical memory.
In a system with virtual memory, you end up allocating memory, most
of which gets written out to the page-file before use, then read back
in as it's used. The pages are of constant size, so we end up with
linear speed in actually expanding the array, even though the number
of calls to the memory allocation routine is amortized constant. The
promise in the standard ends up misleading and useless.
However, that's quite benign compared to the problems that arise in a
situation with only physical memory: in this case, you typically can't
afford to waste 25% of each vector, so even though the promise in the
standard would be followed, nobody is likely to even attempt
supporting it.
With maps and multimaps, we get an example of simply ignoring real-
world requirements: virtually everything that uses associative lookups
(e.g the compilers, assemblers, linkers, etc., we all use on a regular
basis) are virtually always implemented using hashing for their symbol
tables. Unfortunately, we can't use hashing to implement a map or
multimap...
> Without specs you have to use your own algorithms anywhere
> performance matters, because you don't know *what* the library might do.
I disagree -- right now, if performance matters, you have to use a
profiler to determine whether the standard implementation is
satisfactory or not. If there was no guarantee in the standard, you'd
have to do exactly the same thing. The guarantees in the standard
make NO difference whatsoever.
[ ... ]
> Without complexity requirements in the Standard C++
> Library, similar restrictions would have been reasonable.
Similar restrictions are presently reasonable. Worse yet, the
requirements in the standard give people a false sense of security, so
they don't realize that the restrictions are reasonable.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1998/06/24 Raw View
In article <358FC442.41C6@wizard.net>, kuyper@wizard.net says...
[ ... ]
> The implementor can provide any non-standard trade-offs they want, as
> extensions to the standard. What the complexity requirements do is
> provide programmers with a way of knowing something about what the
> trade-offs will be for a design choice relating to the STL, something
> that will remain true no matter where the code is ported to.
As I've repeatedly pointed out, this simply isn't true -- in most
cases the requirements tell you nothing, but give you a false sense of
security.
> There is no
> way I would be willing to use a map<> class for portable code if I
> thought that implementors were free to use a linear search for every
> access; I'd roll my own binary-tree implementation, and ignore the
> standard.
Why? If the implementor is writing a map<> class for a machine that
supports only 128 bytes of RAM (they DO exist, and remember that much
of the discussion centers around suitability to just such systems) and
a relatively small amount of ROM, a linear search might be perfectly
reasonable.
The fact is, the marketplace (NOT the requirements of the standard)
are going to determine the efficiency of libraries that people use.
If you simply specified that map<> would do keyed lookup and left it
at that, chances are that 99% of the implementations would use hash
tables, providing FAR better access speed than the present version.
> False - you cannot decrease the computational complexity by adding
> operations. By definition, computational complexity is measured in the
> limit of arbitrarily large N.
By definition, conformance with the standard is measured on real
implementations on real machines, where arbitrarily large N is simply
impossible. An implementor who chooses to do so, can find the largest
collection possible on a real machine, and make operations on even the
smallest collections take as long as those on the largest one possible
on the implementation, providing constant time for ALL operations.
Ultimately, this doesn't affect conformance with the standard, since
it's mostly defined in terms of number of elementary operations rather
than time taken. However, for practical purposes, the number of
operations involved is interesting ONLY to the extent that it
indicates the amount of time the algorithm will take.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: loewis@informatik.hu-berlin.de (Martin v. Loewis)
Date: 1998/06/24 Raw View
"P.J. Plauger" <pjp@dinkumware.com> writes:
> Could you supply a proof for this statement, please?
>
> #include <iostream>
> int main()
> {std::cout << "hello world" << endl;
> return 0; }
>
> Including <iostream> doesn't just declare cout, it declares cin, cerr, clog, wcin,
> wcout, wcerr, and wclog. Each of these objects can be used within a static
> constructor, so it has to be assuredly initialized in any translation unit that
> includes <iostream>.
How so? <iostream> is only required to declare these objects, not to
define them (27.3). If the object is declared but not used, it does
not need to be defined (3.2). If the object is not defined, it is
certainly not initialized.
So I can't see why the wide-character support code must be linked to
the program given above.
Martin
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/24 Raw View
Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
>
>Well, maybe the best definition for a good EC++ standard would be:
>A *full* C++ implementation which *additionally* has the option to
>turn certain costy features (like EH and RTTI) off, and has the EC++
>standard library in addition to the C++ standard library. This would
>satisfy all people, I think.
No, that's just another expedient. What would satisfy is efficient
compilers and libraries that don't impose overhead for unused features.
There are plenty of excuses for not providing that, but to standardize
such excuses is madness.
"You must bring your homework, *unless* the dog ate it."
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Matt Austern <austern@sgi.com>
Date: 1998/06/24 Raw View
jcoffin@taeus.com (Jerry Coffin) writes:
> The fact is, the marketplace (NOT the requirements of the standard)
> are going to determine the efficiency of libraries that people use.
> If you simply specified that map<> would do keyed lookup and left it
> at that, chances are that 99% of the implementations would use hash
> tables, providing FAR better access speed than the present version.
But different performance characteristics---not uniformly better. The
tradeoffs are completely different. As a library implementor I don't
know which data structure is appropriate for users' programs, so I
provide both. The standard ought to include both as well; I expect
that hash tables will make it into a future revision.
Similarly, the STL provides five different sorting algorithms. (Five
that I can think of off the top of my head, anyway. Maybe I've
forgotten one or two.) Again this is reasonable: there is no
uniformly best sorting algorithm, and users ought to be able to choose
the one that's appropriate for their applications. The standard has
to say something about the differences between these sorting
algorithms, and that means it has to say something about their
different performance characteristics.
It may very well be true that the STL doesn't have enough sorting
algorithms. Most STL implementations do include an internal insertion
sort algorithm, and it might be a good idea to expose insertion sort
as part of the public interface. Similarly, there may well be some
cases where selection sort, radix sort, or shell sort are better
choices than any of the existing STL algorithms.
But adding more algorithms means specifying each one's performance
characteristics---otherwise, users will have no rational basis for
choosing between them.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/24 Raw View
P.J. Plauger<pjp@dinkumware.com> wrote:
>Including <iostream> doesn't just declare cout, it declares cin, cerr,
>clog, wcin, wcout, wcerr, and wclog.
>...
>Perhaps there are techniques
>unique to [the implementation] that can avoid dragging in code for each
>of these objects unless it is actually referenced,
Precisely. This is the job of the implementation.
>Every one of these eight stream objects is ``imbued'' with a locale object.
This is false. The standard does not require anything to be "imbued"
unless a user program does so.
>... even after eliminating all unused virtuals, the
>locale/facet machinery still drags in an extraordinary amount of cruft.
The language standard doesn't require any implementation to "drag in"
anything that's not used. If your vendor's implementation does so
anyhow, that's an optimization opportunity, for them or for their
competitors. Optimization can be as convenient (entirely automatic,
or via compiler switches) or as clumsy (substituting various library
subsets by hand) as users will tolerate.
It seems some users will tolerate (even cherish!) *anything*.
I suppose those users make good customers.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/24 Raw View
Jerry Coffin<jcoffin@taeus.com> wrote:
>With maps and multimaps, we get an example of simply ignoring real-
>world requirements: virtually everything that uses associative lookups
>(e.g the compilers, assemblers, linkers, etc., we all use on a regular
>basis) are virtually always implemented using hashing for their symbol
>tables. Unfortunately, we can't use hashing to implement a map or
>multimap...
Certainly you can. Just don't call it std::map; or if you do,
specialize it for the types you're using.
>> Without complexity requirements in the Standard C++
>> Library, similar restrictions [entirely forbidding use]
>> would have been reasonable.
>
>Similar restrictions are presently reasonable. Worse yet, the
>requirements in the standard give people a false sense of security,
>so they don't realize that the restrictions are reasonable.
"Similar restrictions" means: don't use Standard Library containers
or algorithms. Jerry, what are you saying?
- The Standard Library's containers and algorithms are unusable
*because* they have complexity requirements?
- The Standard Library's containers and algorithms are unusable
with or without complexity requirements?
If you're not going to use them, what does it matter how they're
defined? Should they not have been provided at all?
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/06/25 Raw View
Jerry Coffin wrote:
>
> In article <358FC442.41C6@wizard.net>, kuyper@wizard.net says...
>
> [ ... ]
>
> > The implementor can provide any non-standard trade-offs they want, as
> > extensions to the standard. What the complexity requirements do is
> > provide programmers with a way of knowing something about what the
> > trade-offs will be for a design choice relating to the STL, something
> > that will remain true no matter where the code is ported to.
>
> As I've repeatedly pointed out, this simply isn't true -- in most
> cases the requirements tell you nothing, but give you a false sense of
> security.
Saying it doesn't make it so. There is a big difference between no
information and little information. The small amount of information the
standard does provide is very nearly the only information that could
have portable meaning. If you don't care about portability, and do care
about optimization, then you look at other implementation specific
measures such as the actual amount of time taken. Portable code should
not be optimized for a particular machine; it should be optimized only
in the algorithmic sense, and that is what the standard's operation
count requirements allows.
> > There is no
> > way I would be willing to use a map<> class for portable code if I
> > thought that implementors were free to use a linear search for every
> > access; I'd roll my own binary-tree implementation, and ignore the
> > standard.
>
> Why? If the implementor is writing a map<> class for a machine that
> supports only 128 bytes of RAM (they DO exist, and remember that much
> of the discussion centers around suitability to just such systems) and
> a relatively small amount of ROM, a linear search might be perfectly
> reasonable.
I'm unlikely to be porting code to and from such a machine. Any code I
wrote for such a machine would be heavily optimized for that particular
machine. I referred specifically to portable code.
> The fact is, the marketplace (NOT the requirements of the standard)
> are going to determine the efficiency of libraries that people use.
> If you simply specified that map<> would do keyed lookup and left it
> at that, chances are that 99% of the implementations would use hash
> tables, providing FAR better access speed than the present version.
Hashing belongs in the library; so do binary trees. Hashing, in order to
be usable in a standard library, needs to have lots of adjustable
parameters and options to be customized for different applications.
There is less need for that with binary trees. I suspect that's the main
reason why a form for map<> was agreed upon in time, and whay a form for
hash_map<> wasn't. I wouldn't mind seeing a hash_map<> in the next
standard, and I expect to see one provided as an extension in virtually
any commercial implementation of the new standard.
> > False - you cannot decrease the computational complexity by adding
> > operations. By definition, computational complexity is measured in the
> > limit of arbitrarily large N.
>
> By definition, conformance with the standard is measured on real
> implementations on real machines, where arbitrarily large N is simply
> impossible. An implementor who chooses to do so, can find the largest
> collection possible on a real machine, and make operations on even the
> smallest collections take as long as those on the largest one possible
> on the implementation, providing constant time for ALL operations.
And how many copies of this implementation do you think could be sold
using such a method? That would be horrendously inefficient! I'm willing
to let market pressures weed out such cases; I'm not going to worry
about them. I'm not worried about implementors faking compliance by such
methods. I'm worried about implementors taking short cuts by using a
simpler but slower algorithm than the one that was used as a basis for
setting the required operation counts. In every case, those operation
counts were based upon someone being aware of a feasible implementation
that met those requirements.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/06/25 Raw View
Martin v. Loewis <loewis@informatik.hu-berlin.de> wrote in article <p6qbtri7gsx.fsf@pandora.fb-inf2>...
> "P.J. Plauger" <pjp@dinkumware.com> writes:
> > Including <iostream> doesn't just declare cout, it declares cin, cerr, clog, wcin,
> > wcout, wcerr, and wclog. Each of these objects can be used within a static
> > constructor, so it has to be assuredly initialized in any translation unit that
> > includes <iostream>.
>
> How so? <iostream> is only required to declare these objects, not to
> define them (27.3). If the object is declared but not used, it does
> not need to be defined (3.2). If the object is not defined, it is
> certainly not initialized.
>
> So I can't see why the wide-character support code must be linked to
> the program given above.
I agree -- almost. I just don't know how to ensure that they are defined, and
initialized, before they are referenced in a static constructor; but to generate
no additional references to them unless someone else references them first.
So far, I haven't figured out how to avoid executable code in the initializers
for the iostreams objects.
As always, I will enjoy being educated.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/25 Raw View
Jerry Coffin<jcoffin@taeus.com> wrote:
>Nathan Myers writes:
>> Of course it is very common for quicksort implementations to use
>> this two-stage process, using a different sort for ranges of four
>> elements or fewer. The break-even point depends on how expensive
>> a comparison and a swap are, and unfortunately the STL has no way
>> to measure these. Still, for small-enough N even that doesn't matter.
>> The current SGI STL (3.1 -- get it if you haven't yet) uses a
>> threshold of N = 16.
>
>Yup. Are you sure it conforms? I haven't looked -- if it uses an
>insertion sort for small N, it may still conform. If it uses a
>selection sort instead (which may be faster when swapping objects is
>non-trivial) it almost certainly WON'T conform to the requirements
>anymore.
It's easy to look (I did), and quite educational, on several fronts.
I recommend it.
Generally, if you have special knowledge about the type that is
being sorted, you can specialize std::sort() for that type and apply
any algorithm you want. Thus, std::sort() is usable as-is for almost
all purposes by almost all people, which wouldn't be the case without
performance requirements, and it's hand-tunable for cases where those
requirements might be a problem. So, what's the problem?
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/06/25 Raw View
Jerry Coffin wrote:
...
> may be faster overall than ones that make fewer comparisons. Imagine
> the overhead involved in doing, say, a heapsort on 10 items. Compare
> that to using an insertion or selection sort on the same 10 items.
> The latter will make more comparisons than allowed, but will be
> finished before the heap-creation phase of the heap-sort is finished.
That depends entirely upon the amount of time the comparisons take. For
sufficiently slow comparisons, the ONLY thing that matters is how many
of them you make (that's the definition of "sufficiently slow" in this
context). You can't write a templated standard container and have it
simultaneously optimized for all types of objects. The specifications
that restrict the number of comparisons implicitly imply that
comparisons are the main operations that constrain the speed. If that's
not true for a given class of contained objects, you might need to use a
non-Standard container class.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Gabriel Dos Reis <dosreis@DPTMaths.ens-cachan.fr>
Date: 1998/06/25 Raw View
>>>>> =ABPJP=BB, P J Plauger <pjp@dinkumware.com> wrote:
PJP> #include <iostream>
PJP> int main()
PJP> {std::cout << "hello world" << endl;
PJP> return 0; }
PJP> Including <iostream> doesn't just declare cout, it declares cin, cer=
r, clog, wcin,
PJP> wcout, wcerr, and wclog.=20
[...]
Well, you said these objects got *declared*. Fine. Is there a
paragraph in the standard which forces a linker not to optimize away
unused objects ?
-- Gabriel
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/25 Raw View
Nathan Myers wrote:
>
>
> No, that's just another expedient. What would satisfy is efficient
> compilers and libraries that don't impose overhead for unused features.
> There are plenty of excuses for not providing that, but to standardize
> such excuses is madness.
It would be wonderful if we all lived in Lake Wobegon, where all the men
are strong, all the women are good looking, all the children are above
average, and all the C++ compilers and libraries don't impose overhead
for unused features. Most of us don't live there, though. Insisting that
everyone should live in that fantasy world is madness.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: abrahams@motu.com (David Abrahams)
Date: 1998/06/25 Raw View
On 24 Jun 1998 19:56:06 GMT, jcoffin@taeus.com (Jerry Coffin) wrote:
>The fact is, the marketplace (NOT the requirements of the standard)
>are going to determine the efficiency of libraries that people use.
>If you simply specified that map<> would do keyed lookup and left it
>at that, chances are that 99% of the implementations would use hash
>tables, providing FAR better access speed than the present version.
C'mon, Jerry, you know better than that! You can't "simply specify
that map<> would do keyed lookup". If it's going to do hashing, you
put requirements on the contained type which are different from what
you get if it's going to use a tree.
-Dave
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Jim Barry" <jim.barry@bigfoot.com>
Date: 1998/06/25 Raw View
jkanze@otelo.ibmmail.com wrote in message
<6mrcso$qo3$1@nnrp1.dejanews.com>...
>
>I mean any serious error. I don't see where exceptions can help either
>in detection or handling. I don't even see where they claim to.
>
>Read very carefully what I have said, and then explain in what way
>exceptions can help in handling (not propagating) the error.
Stroustrup explains it in chapter 14 of CPL3 much better that I can
here.
>FDIS, 15.4/10: "An implementation shall not reject an expression merely
>because when executed it throws or might throw an exception that the
>containing function does not allow."
Yes. Presumably, an implementation can issue a warning though. Having
re-read section 15.4 [except.spec], it does seem to me that
exception-specifications are are little more than formalised
documentation, and are almost completely useless. Sigh.
- Jim
--
Jim Barry, Thermoteknix Systems Ltd., Cambridge, UK.
http://www.thermoteknix.co.uk Queen's Award for Export 1998
Antispam address courtesy of http://www.bigfoot.com
Or e-mail direct: jim at thermoteknix dot co dot uk
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/06/25 Raw View
Nathan Myers wrote:
>
> Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
> >
> >Well, maybe the best definition for a good EC++ standard would be:
> >A *full* C++ implementation which *additionally* has the option to
> >turn certain costy features (like EH and RTTI) off, and has the EC++
> >standard library in addition to the C++ standard library. This would
> >satisfy all people, I think.
>
> No, that's just another expedient. What would satisfy is efficient
> compilers and libraries that don't impose overhead for unused features.
> There are plenty of excuses for not providing that, but to standardize
> such excuses is madness.
But you can't do a standard string class that doesn't throw exceptions.
So if you decide that having exceptions is too expensive for your app,
you cannot use std::string (note that this even holds for compilers
which don't produce one byte or one cycle overhead if your program
doesn't contain a throw or catch - the string code *does* contain
throw).
Now what options do you have?
1. Use C strings - ugly
2. Write your own string class - works, but unfortunate, since there's
an almost satisfying string class already there.
3. Have an EC++ string class, which doesn't throw (the std::string class
throws too often anyway, IMHO).
Also note that it doesn't help to check values for validity when
calling string functions - the throws of string will be compiled
in anyway (and you won't give the compiler the burden to proof that
all parameters to string functions will be legal at runtime, do you?)
And then there's the question if it's possible to avoid any overhead
for features not used, if there's no switch to turn them off. At
least for exceptions, I think it will be very hard at minimum.
Note that when compiling one module, you generally cannot know
if another module will throw through it - except if there's a
special flag you can give to the compiler to tell it so - this
flag is effectively the "disable exceptions" flag. So why not name
it as such.
What makes exceptions different from most other features is that
it affects the global program. *Any* code must be compiled with
exceptions "in mind", even if it contains no exception specific
code. Only if you can see the whole program at once, you can
decide if it uses exceptions. And exceptions can't come in free,
since they provide functionality. There are implementations with
no overhead at no-throw path, but all the information *must* be
there for the case someone throws.
However, even if there once exists a no-overhead-for-unused-features
compiler, you'll still need an EC++ library to "unuse" those
features *without* abandoning useful parts of the library that
just happen to use those features per std definition, but could
be defined not using them with little or no efford.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1998/06/22 Raw View
James Kuyper <kuyper@wizard.net> writes:
|> With the originally stated definition, I doubt that GCD-C++ is a large
|> enough language to be useful. In particular, it cannot contain
|> <iostreams>, because that isn't supported by the older versions of C++,
|> and it can't contain <iostreams.h> because that isn't supported by the
|> draft ISO C++ standard.
But it still could use stdio.h.
|> ISO C++ will be very different from previous
|> practice, far more so than was the case with the first C standard. That
|> may have been a wise decision, but there are going to be a lot of costs
|> to that decision. This is one of them.
This may surprise some people, but my impression is that globally, ISO
C++ will be more upward compatible with previous C++'s that ISO C was
with most existing C compilers at the time. Not formally, since of
course, iostream is formally completely different. But practically.
(An awful lot of C programs were broken by changes in the preprocessor,
or the signed/unsigned promotion. In theory, the ISO C preprocessor was
upward compatible from the one described in K&R1, and whether promotion
was value preserving or signedness preserving wasn't defined. But the
Reiser preprocessor was very wide spread, and broke with ISO C, and of
course, an awful lot of programs depended on the promotion semantics of
the Johnson pcc.)
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/06/23 Raw View
In article <MPG.ff7a6f6589733c989b2f@news.rmi.net>,
jcoffin@taeus.com (Jerry Coffin) wrote:
>
> In article <fxtwwabesy2.fsf@isolde.mti.sgi.com>, austern@sgi.com
> says...
> > If you care more about average speed
> > than worst-case, then you should use a different data structure. But
> > that's not an argument for using a library that's smaller than the
> > standard C++ library: it's an argument for using a library that's
> > larger, one that provides both the standard container set<> and, as an
> > extension, the non-standard container hash_set<>.)
>
> Or, perhaps, it's an argument for the library having been defined a
> bit differently in the first place -- I've yet to be convinced that
> placing requirements on computational complexity really accomplished
> anything useful. For the most part, it simply made it impossible for
> the implementor to make trade-offs appropriate to the environment
> they're supporting.
>
> I guess in theory this was done to guarantee that all programs would
> be efficient. In reality, it doesn't go far enough to guarantee such
> a thing, and I can't think of a way of rewriting the specification so
> it would either. If a library chooses to use an algorithm with
> particularly poor computational complexity, it can still comply with
> the standard by wasting the proper lengths of times when told to work
> on small collections. Obviously this isn't an attractive option...
You're looking in the wrong end of the telescope. The guarantee was made for
the STL user.
Consider the following code snippet, which operates on some container x:
for (x::iterator i=x.begin(); i!=x.end(); ++i)
if (i == std::find_if( /* ... */ ))
std::cout << "Element " << (i-x.begin())
<< " matches" << std::endl;
The condition in the for loop uses member function x.end(), which has
(I believe) constant complexity. That is very reasonable.
The condition in the if() statement uses function find_if, which has linear
complexity. That is not at all reasonable.
I have seen programmers use dozens of variables with temporary values, in
order to pull from loops some calculations that are very close to free
(i.e. if j==i+1). A very minor sin, certainly, but less than optimal.
Meanwhile, some other programmers fail to pull calculations that are
very expensive indeed (such as calling strlen() on an input string or
getting today's date in a text string). This is a more serious problem
because performance can bog down.
In each case, to explain to them what's wrong with the code, you have to
have an inkling of how long the function takes to execute. It isn't
practical to say, for instance, that find_if takes 1.5 milliseconds, or
even 1.5 milliseconds per data element -- it depends on far too many
factors. But at least by providing complexity guarantees, we can get a
general understanding for what type of work we're asking for.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1998/06/23 Raw View
Oleg Zabluda <zabluda@math.psu.edu> writes:
|> David J. Littleboy <davidjl@gol.com> wrote:
|> : My point is that STL is not a viable programming style
|> : in the memory constrained subset of the embedded area.
|>
|> Nonsense. STL has no inherent overhead compared to hand-written
|> code with identical functionality. Neither in memory size nor in
|> speed. If anything, it'll produce smaller and faster code
|> then an ec++-programmer-who-allegedly-can't-learn-c++ can whip
|> out.
I'm not sure about the "inherent overhead", but the one implementation
of STL whose memory usage I did measure (the old HP one) was a real
memory hog.
More generally, I suspect that the amortized constant time requirement
for growing the vector will require some excess memory usage.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1998/06/23 Raw View
"Jim Barry" <jim.barry@bigfoot.com> writes:
|> jkanze@otelo.ibmmail.com wrote in message
|> <6m6i4q$7k1$1@nnrp1.dejanews.com>...
|> >Neither is simple. Handling errors is difficult, period. Exceptions
|> >make reporting errors simpler -- they do not have any effect on
|> detecting
|> >them nor on handling them.
|>
|> That's not my understanding of exceptions at all. Exception handling
|> is not simply for reporting errors.
The C++ exception mechanism is a mechanism for reporting errors. Or are
you claiming that it helps detect them, or handle them, as well.
|> >Exceptions also introduce unexpected program flow in your program.
|>
|> No they don't. If an exception is thrown I expect program flow to move
|> to the appropriate catch block and for the stack to be unwound.
Obviously. So perhaps "unexpected" wasn't the right word. Although
there is certainly nothing in the code for a function call that
indicates that we might suddenly go to the end of the function, without
executing the following code.
|> The
|> issue of unhandled exceptions is addressed by exception-specifications
|> and, in the context of embedded systems, I would expect the compiler
|> to aggressively check such specifications.
A C++ compiler is not allowed (by the language) to check exception
specifications. (Of course, it could generate a warning.)
|> >At the level of "depends on your application": applications where a
|> >programming error is simply not acceptable, regardless of price, use
|> >somewhat elaborate methods of program proof.
|>
|> I am somewhat sceptical about formal methods of 'proof'. I don't see
|> how it can ever be possible to prove 100% that code does exactly what
|> the programmer intended.
You can't of course. To start with, you can't generally specify exactly
"what the programmer intended" (which might not be what the program
should do anyway). Formal proof is only one arm to be used against
program errors. In my experience, some sort of "proof" is a moderately
effective arm, but I would not consider it by any means "sufficient".
In life critical applications, of course, you use every arm available.
(More generally, I find "formal" proofs only slightly more efficient
than informal ones. And far more expensive. I thus only use them in
life critical applications. On the other hand, I find informal proofs
considerably more effective than testing in preventing errors.)
|> C++ provides a wealth of language features
|> precisely so that programmers can write code that is more expressive
|> of the problem domain, which also implies code that stands a better
|> chance of doing what it is intended to.
Maybe. But how can you know it?
More generally, added features which aren't immediately useful to you
have a definite cost in the complexity of the language. Because C++ has
features for everyone, it almost certainly has some that aren't
particularly useful to you. For most people, this cost is offset by the
advantage of having one single language used by many people (which
simplifies finding people who know it, if nothing else).
|> >This means that *anything* that does not have single entrance/single
|> exit
|> >is too expensive, by definition, for the application.
|>
|> I think that single-exit is just the kind of old-fashioned paradigm
|> that C++ is trying to get away from.
With regards to functions, I only see two paradigms: procedural and
functional. I don't think that C++ is functional (where even looping
constructs are forbidden).
|> >I don't think the argument is really whether a subset is useful or
|> not.
|> >It is whether that subset should be standardized, or perhaps more
|> correctly,
|> >to what degree that subset should be standardized. On this,
|> reasonable
|> >people may differ, and there is no absolute answer.
|>
|> I am entirely in agreement with Bjarne Stroustrup's postings on this
|> thread, so I am against formally defined subsets. Even if I did not
|> consider EC++ to be flawed, I would still think it unnecessary,
|> divisive (just look at the heated arguments on this thread), and
|> ultimately harmful to C++.
In practice, you MUST have use formally defined subset. The question is
more at what level the formal definition is specified. If I understood
Bjarne's posting correctly (not necessarily certain -- I've been known
to misunderstand people, even when they are perfectly clear), he is
against a formal definition of the subset at anything other than the
project (or maybe the corporate) level. While I would be against such a
formal definition at the ISO level, I do think that there is room in the
middle.
Since Bjarne has admitted that using a subset is sometimes appropriate,
I would caracterize our disagreement as one concerning the level at
which this subset should be defined. I also recognize the arguments he
presented as very legitimate concerns, which should be taken into
account -- they are very strong arguments against standardization at the
ISO level. I find them less determining when it is a question of a
definition by an association of vendors in a very particular, very
limited market subsegment.
(I think the difference is worth insisting upon. If Sun and Microsoft
were saying that their next releases would be EC++, for Solaris and NT,
I'd be up in arms against EC++ even more than its current opponents.
For the moment, however, I don't consider this a real risk.)
It's worth considering that you are always programming to a subset.
What the compiler supports without errors. Most of the time, this
subset is neither formally defined (you discover it because you code
doesn't work), nor have you the slightest influence in its specification
(the compiler implementor defines it, generally unintentionally). Given
this, I find it difficult to get worked up about a formally defined
subset.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/06/23 Raw View
Jason Merrill wrote:
>
> >>>>> Pete Becker <petebecker@acm.org> writes:
>
> > Jason Merrill wrote:
> >>
> >> No, but they can be eliminated with existing options to existing
> >> compilers. What overhead does g++ -fno-rtti -fno-exceptions have that an
> >> EC++ compiler would necessarily not?
> >>
> >> In fact, Cygnus ships an EC++ product which consists of g++ with an option
> >> that disables namespaces, MI, mutable, templates, RTTI, and exceptions. I
> >> don't see the point; the above command would produce exactly the same code.
> >> The EC++ option just adds diagnostics.
>
> > No, EC++ also adds a library built with code size in mind. That's why
> > Cygnus has been unable to match the significant size reductions that,
> > for example, the Green Hills compiler gives with EC++. With a suitable
> > library, g++ does much better.
>
> Agreed.
>
> >> So just considering the language itself, what does EC++ buy users that a
> >> couple of well-placed compiler options won't?
>
> > Users don't use "the language itself", they use the language plus
> > libraries.
>
> Of course. But my point is this: why does EC++ specify a language subset
> when all the gains are from changes to the library?
Because one of the things that makes the library better is optimizations
that are possible only because it needn't support all the features of
C++? Just a guess; I've no direct knowledge of either library.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/23 Raw View
Jason Merrill wrote:
>
> >>>>> Pete Becker <petebecker@acm.org> writes:
>
> > Jason Merrill wrote:
> >>
> >> Of course. But my point is this: why does EC++ specify a language subset
> >> when all the gains are from changes to the library?
>
> > Because not all the gains are from changes to the library. Exceptions
> > are the most obvious example.
>
> Aargh! That's what I was just talking about!
>
> As I said in my previous message in this thread, with existing compilers
> you can turn exceptions and RTTI off with flags if you don't want to pay
> for those features. So why prevent people that want to make that tradeoff
> from using them?
>
> My point is, using an EC++ compiler with the EC++ library is essentially
> equivalent to using a C++ compiler with the EC++ library, specifying the
> options to turn off exceptions and RTTI. Do you dispute this?
Can you please say what you're trying to say, rather than trying to get
me to say it? I'm completely confused about what you're point is.
Obviously, since the EC++ library is designed to be used in a system
without exceptions and RTTI, when you use it you should not use
exceptions and RTTI. Who do you think is trying to prevent anyone from
doing something?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/06/23 Raw View
Jason Merrill <jason@cygnus.com> wrote in article <u9ogvl91cq.fsf@yorick.cygnus.com>...
> My point is, using an EC++ compiler with the EC++ library is essentially
> equivalent to using a C++ compiler with the EC++ library, specifying the
> options to turn off exceptions and RTTI. Do you dispute this?
We *celebrate* it. People who have access to a full C++ compiler -- with
options to turn certain language features on and off -- need just the EC++
library to gain the advantages of EC++. We even favor adding STL back
into the library, for most of the reasons oft repeated in this thread.
But we also sympathize with those vendors who have less that complete
C++ compilers -- and their customers for years to come. Describing a
*language* subset likely to be portable across many embedded development
environments can be salutary.
Language subsetting is an issue orthogonal to library subsetting. Too bad
the two are inevitably confused in the kind of rambling discussion that
a newsgroup can't help but encourage.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1998/06/23 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> writes:
|> In article <6m8biu$1pj$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
|> writes
|> >In article <fFJmlGAcLXh1Ew3r@noco.demon.co.uk>,
|> > Mike Davies <mike_davies@noco.demon.co.uk> wrote:
|> >
|> > [...]
|> >> Has he asked his programmers ? Do they have any OO design skills ?
|> >> Because if so they will reply that they will need all of C++ at some
|> >> point in time.
|> >
|> >I rather take ombrage at this. It has nothing to do with EC++, but
|> >I feel sure that in the applications I'm currently working on, there
|> >are large parts of C++ which I'll never need.
|>
|> Please list them, I notice you say something rather different below
Where did I say anything different? I have no real use for namespaces,
no use whatsoever for any of the advanced template features, only
limited use for exceptions (due to requirements in the CORBA
interface). I personally get by very well without STL, and on my
current projects don't need the template features of iostream.
This doesn't mean that others may not need them (as I explicitly said),
nor even that I will never need them -- I can see a definite utility in
the templated iostream and the new locale, for example. And export is
almost essential if templates are to be used for anything other than
basic libraries. (But this isn't really an extension, but a return to
the original template implementation.)
|> > And I don't consider
|> >my OO design skills to be 0. How on earth did we manage to write
|> >programs before? For that matter, how do I manage now, since most
|> >of the compilers I use don't support the full language yet?
|>
|> I haven't use a C++ compiler since I don't know when that didn't offer a
|> *much* fuller implementation than EC++, and I have severely missed
|> features present in the new standard. If you stay with programming
|> practices close to normal C ones then you won't miss them to the same
|> extent.
Well, I've used compilers which implemented a lot less -- partially
unintentionally:-). Most of my recent work, however, has been on larger
systems (between 250 and 1000KLOC), running on larger UNIX systems.
Obviously, for such systems, the trade-offs will be different than for
those targetted by EC++.
|> >Of course, I'm sure that the poster didn't really mean "need" -- strictly
|> >speaking, all anyone needs is a language which is Turing complete.
|>
|> Read on its own this is a fatuous remark.
Which is why I didn't say it on its own -- it was part of a larger
paragraph which, I think, narrowed it signification considerably.
|> >The choice beyond that is always motivated by the trade-offs: how much
|> >does this feature cost (and they all cost something, if only in added
|> >language complexity) vs. how much does it save.
|>
|> If you don't need the features of C++ to support your style of
|> programming then I am surprised to hear you say you are doing OO design.
|> In any case the language is only as complex as the subset that you
|> choose to use.
Be surprised. My main selling point as a consultant is my strong OO
capabilities. Of course, I'm not a "purist"; an OO purist would oppose
any templates, for example:-).
|> >The trade-off's I'm seeing on the projects I'm currently working on (which
|> >are NOT the type of systems targetted by EC++) is that we really don't need
|> >anything that wasn't in CFront 3.0, except maybe exceptions. On my previous
|> >project (which had higher reliability constraints), we didn't even need
|> >exceptions, but we DID need some form of separate compilation of templates --
|> >what has been standardized with export. Namespaces would be nice.
|>
|> So condensing your remarks above : "
|>
|> ___start___
|>
|> >there
|> >are large parts of C++ which I'll never need
|> ...
|> >we
|> ...
|> >don't need
|> >anything that wasn't in CFront 3.0, except
|> ...
|> >exceptions
|> ...
|> >we
|> ...
|> >need some form of
|> ...
|> > templates
|> ...
|> >Namespaces would be nice.
|>
|> ___end___
|>
|> You are going to get all this stuff (that you need and don't need at the
|> same time) from EC++ ?
Why don't you read what I say before trying to answer? You said that no
one who knew anything about OO could need anything less than the full
C++ standardized by the committee. All I did was point out that your
point of view did not correspond to that of any of the OO experts I
know. None of which has anything to do with EC++. I was just pointing
out that even on a large machine (not the target for EC++), many
features weren't always necessary, even if (or maybe especially) if you
program in a strong OO manner.
All of the features adopted by the committee were adopted for a good
reason. Neither I, nor Pete Becker, nor Plaugher, have said anything to
the contrary. This does NOT mean that all of the features are
appropriate for all all programs -- I would be very suspicious of any
one program that did use all of the features.
|> > But
|> >the new template features, or STL, are simply excess baggage -- something
|> >that we have to pay for, but won't use.
|> >
|> No, templates and STL come without overhead, no baggage, just don't use
|> it 'till you need it.
I didn't think my mastery of colloquial English was that bad. I was
under the impression that "excess baggage" was a general expression for
anything for which you had no use. (And of course, NOTHING in a compler
is free -- the development costs are still repercuted in the purchase
price, even if I don't use the feature.)
|> >Obviously, I'm not suggesting that any of these features be removed from
|> >the standard -- I know people who really do need them.
|>
|> If you are arguing for EC++ that is *exactly* what you are arguing for.
I've very explicitly said that I would oppose EC++ becoming an ISO
standard. All the more so I would oppose it replacing C++ as the only
ISO C++ standard.
|> ...snip...
|>
|> >
|> >Back to EC++: apparently, there are some people who find that in its
|> >current state, and the current state of technology, the complete standard
|> >does not represent an acceptable trade-off for them.
|>
|> The people most vociferous in this point of view are compiler vendors so
|> far as I can tell. Why should a programmer object to zero-overhead
|> features in a language when they can just avoid using them ?
Because in the end, he has to pay for them.
|> > Whether you or I
|> >agree will not change their feeling about this.
|>
|> I hope that arguing my point of view can change peoples opinion.
Then you must do two things: 1) get your technical facts straight, and
2) argue against what the others are saying, rather than just inventing
things to argue against.
(NOTE: I do not say this concerning all of the opponents to EC++. I
found Bjarne Stroustrup's posting very good, for example, with some
really pertinant points. In fact, even some of the more emotional
postings have also contained valid points, once you got beyond the
heat.)
|> ...snip...
|>
|> >When you only have 16KB to work in, third party libraries are generally
|> >not a problem.
|>
|> Generally true. Of course namespaces are vital when it is false. Sadly
|> you don't get to choose which is the case :-(
You do and you don't. You can always refuse to use libraries which
don't systematically use prefixes. Or you may be in a context where you
cannot make this choice. Of course, if the library vendor doesn't use
prefixes, what makes you expect it to use namespaces. (The worst
library I've seen in this regard -- luckily, I didn't have to use it --
was full of macros in the global namespace. So namespaces don't help.)
|> > In fact, although I currently work in a 4GB address
|> >space, with a large number of third party libraries, I manage to get
|> >by without namespaces very well. Namespaces may be an elegant solution,
|> >but I've yet to see the problem.
|>
|> You had best sort out a solution now then, before it suddenly appears
|> in your critical path.
Agreed. But namespaces don't really help that much. They make it
(slightly) easier for conciencious librarys to do a good job. But the
problem is, in both cases, the sloppily written libraries, where
namespaces don't help.
|> >I presume you mean programmer efficiency, which is, of course, where
|> >templates really shine. (I can write programs that run faster using
|> >generic.h than I can with templates. I certainly cannot write them
|> >anywhere near as fast, however.)
|>
|> And execution efficiency.
If execution efficiency is really critical (it rarely is), then nothing
beats expressedly written hand coded code. About the only place I've
seen where templates improve speed efficiency is in certain numeric
applications, where the hand coded alternative to expression templates
is just too complex to be considered.
On the other hand, as I say, templates are a lot simpler than generic.h
for the programmer.
|> ...snip...
|>
|> >> multiple inheritance - abstract interfaces
|> >
|> >This is certainly what I'd miss most in EC++. Still, the smaller the
|> >system, the less inheritance (multiple or otherwise) is important.
|> >
|>
|> I see the importance of *multiple* inheritance as being mainly due to
|> the ease with which abstract interfaces can be maintained. This is a
|> programmer effort issue, not invalidated by small code size. Think of
|> the case where an embedded box may need to support many different
|> attachments, but ony one of them will be fitted to any given box.
In which case, no inheritance is needed. Just define a single class,
and link in the appropriate library.
|> ...snip...
|>
|> >>
|> >> unable to use the safety features of exceptions to write safety critical
|> >> code,
|> >
|> >I mentioned this is passing, but more as a counter argument because people
|> >were claiming that you couldn't write robust code without certain features,
|> >where in fact, you can't write really robust code with them.
|>
|> No, it is the other way around. We'll just have to agree to differ, I
|> think :-)
With the difference that I carefully explained why I don't think you can
use exceptions with safety-critical code. (Again, I stress that this is
totally orthogonal to EC++, which also addresses the numerous non
safety-critical embedded applications. And this is not meant to raise
the argument about exceptions in more general code, where I am gradually
becoming convinced that they are not worse than the alternatives.)
|> ...snip...
|>
|> >> > However, I'd bet that the EC++
|> >> >standard goes over a lot better with programmers at companies that are
|> >> >currently purchasing said manager's microcontrollers, since they might have
|> >> >a bit more sympathy for said managers difficulties and they might prefer to
|> >> >see a limited feature set implemented well.
|> >>
|> >> No, not really, it isn't the managers who write the code is it ?
|> >
|> >No, they pay for the programmers, they pay for the tools, and in the
|> >end, they take the risks. Don't underrate the importance of managers,
|> >nor the criteria they use for their decisions.
|>
|> I think you've misunderstood the issue here. I was being asked to feel
|> sorry for the microcontroller vendor (as a proxy for the compiler
|> vendor). If *he* felt sorry for *me* then he'd relent and write me a
|> full featured zero-overhread C++ compiler. Which I see as being his job.
The world being the way it is, you can be sure that if he wrote a full
featured zero-overhead C++ compiler (supposing such a thing possible),
he'd make you pay for it. Because the way the world works, making a
profit is his job, and selling things below cost is not a particularly
good way of doing this.
|> ...snip...
|>
|> >> It may be the case that if you talk to programmers who have not got very
|> >> much OO design experience they do not see the need for some features of
|> >> C++.
|> >
|> >I'm not sure how to answer this one. My first reaction was that I consider
|> >myself an experienced OO designer, and I don't see the need for many of
|> >the features. But if I think about it, I do see the need for them. Just
|> >not in most application domains. And not in embedded processors.
|>
|> But embedded SW is the most likely to need the efficiency advantages of
|> C++ over EC++.
What efficiency advantages?
|> >> If you explained to them the the efficiency advantages of C++ I bet
|> >> you'd get a different response - I give some examples :
|> >>
|> >> virtual functions implemented via a jump table vs switch cases,
|> >
|> >See above. On small systems, you generally don't need virtual functions.
|>
|> It ain't the size of the system, its the style of the code. Jump tables
|> execute in constant time, switches (in the compilers whose output I've
|> seen) in linear time wrt the number of case statements.
And embedded systems don't typically need either -- if there is only one
instance of an interface, resolve the polymorphism at link time.
|> >(On life critical systems, you probably won't allow them.)
|>
|> What ? Why ? Jump tables are more dangerous than a sequence of
|> conditional jumps ? I don't think so.
Precise analysis of program flow is excedingly important for program
proof. Indirect calls, whether hand written (through a pointer to a
function) or generated by the compiler (as a virtual function call) are
generally banned in safety-critical applications.
|> >> templates that can save pointer indirection or function call overhreads,
|> >
|> >??? I don't get this. Can save ... compared to what? Hand written
|> >specialized code? Certainly not.
|>
|> I though they can take reference parameters without needing temporarys,
|> am I wrong here ?
The reference wasn't to temporaries. Simply a general observation that
something written specifical for the tast at hand cannot be less
efficient than generic code, and can often be more efficient.
|> ...snip...
|>
|> >> exception handling that handles *every* error returned by *every*
|> >> function at exactly the place where it is convenient for about a 5% code
|> >> space cost,
|> >
|> >Which implementation? All of the exception implementations I've seen
|> >have been very gourmand in code space (or introduced unacceptable run-time
|> >overhead, plus additional requirements in stack space).
|>
|> Watcom C/C++ V10.6 and Borland C++ V4.5 are both good examples, and both
|> used in embedded systems programming.
I'm not familiar with either personally, but I have heard explinations
of the Borland solution, and it involved significant time overhead (as
well as some additional stack overhead). Of course, my information here
might be out of date, and it might also be that this overhead is due to
some sort of compatibility issue with Windows (VC++ certainly has
significant run-time overhead), and that a compiler switch offers an
alternative.
What I can say is that in all of the discussions I have heard concerning
the implemention of exceptions, the proposed implementations involve
significant space overhead. Perhaps you (or anyone else) could explain
the technique used, so that other vendors could take advantage of it.
(I'm sure that the people at Sun would be interested, since they are the
ones that I remember having explained the almost zero run-time overhead
solution. Which was presented as a space/time trade off: more space for
less time.)
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/06/23 Raw View
Andrew Koenig <ark@research.att.com> wrote in article <Eut1us.G52@research.att.com>...
> In article <358A4753.E470AED1@acm.org>,
> Pete Becker <petebecker@acm.org> wrote:
>
> > Yes, there are compilers shipping today that support the EC++ subset.
>
> EC++ is not a subset of C++.
In the same sense, no C++ compiler available today implements a subset
of C++ -- seven months after the final draft was frozen and nine years after
standardization began, despite the active involvement of many implementors
throughout. (This statement is factually accurate, but it doesn't provide a
useful perspective for making technical judgements about the C++ Standard,
at least not in my opinion.)
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/06/23 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> wrote in article <i5Up6VAkyri1EwLk@noco.demon.co.uk>...
> In article <3589ABD2.422782FC@acm.org>, Pete Becker <petebecker@acm.org>
> writes
> >> I would be astonished if anybody in the low end embedded world compiled
> >> a 20 line program in C++ and found it gave a 200k binary :-)
> >> The way that happens is when compile against a (massive in your case)
> >> library.
> >
> >Have you tried "Hello, world" with the full library?
>
> *Which* version of the full library ?
One that conforms to the FDIS, or some recent draft, including support for
``locale and its facets'' (note subject line for this thread). The *best* version
you can get commercially today, in terms of iostreams code size at least,
is the one that comes with VC++ V5.0. I consider it embarrassingly large,
particularly compared to a typical cfront-style iostreams library. Other
implementations have been know to generate much larger executables,
as Pete Becker reports:
> > Two first attempts
> >at implementating the library that I'm familiar with produced
> >executables of over 1 Meg for hello world. With some work that can be
> >gotten down to 200k. With some rather heroic (and fragile) efforts it
> >can be reduced to about 60k.
>
> I have never argued that it is impossible to produce a large library in
> C++.
Natch. The issue under discussion, however, is how hard it is to *avoid*
producing a large library that conforms to the FDIS.
> I have used C++ for years, and although I know that the careless use of
> libraries can give you unnecessarily large programs, I also know that
> including only the minimum required headers gives C++ programs of
> comperable size to C programs for similar functionality.
That has long been true for C++ libraries. But the FDIS does *not* codify
existing practice. It plows new turf with a large and ambitious library design
that was voted into the draft C++ Standard before much of it was implemented.
We implementors are now in the debugging stage with that design -- after
the FDIS is frozen. The C++ Standard proper cannot benefit from much of
that experience for at least another five years. In particular, it is very difficult
to avoid some surprisingly large overheads foisted on even the simplest of
C++ programs -- not without deviating from the C++ Standard in small ways.
That's where subsetting comes in.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/23 Raw View
Jerry Coffin<jcoffin@taeus.com> wrote:
>
>IMO, this is another example of the specification of computational
>complexity being overly constraining without serving a useful purpose.
>On a system where it's known that data sets will always be relatively
>small (e.g. because the system doesn't address a lot of memory) it
>might be perfectly reasonable to implement sort() using a Shell-
>Metzner sort. Unfortunately, this doesn't meet the official
>computational complexity requirements, even though on relatively small
>collections it's often faster than most of the others, along with
>typically using less memory.
A system that used a different algorithm for small ranges (or even
for small subranges of larger, partitioned, ranges) to get better
performance would be entirely conforming. What is specified is the
maximum number of operations; if for small N the same effect could
be achieved by a more-efficient algorithm, the spec doesn't quibble.
Of course it is very common for quicksort implementations to use
this two-stage process, using a different sort for ranges of four
elements or fewer. The break-even point depends on how expensive
a comparison and a swap are, and unfortunately the STL has no way
to measure these. Still, for small-enough N even that doesn't matter.
The current SGI STL (3.1 -- get it if you haven't yet) uses a
threshold of N = 16.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/23 Raw View
Jerry Coffin<jcoffin@taeus.com> wrote:
> .... I've yet to be convinced that
>placing requirements on computational complexity really accomplished
>anything useful. For the most part, it simply made it impossible for
>the implementor to make trade-offs appropriate to the environment
>they're supporting.
>
>I guess in theory this was done to guarantee that all programs would
>be efficient. ...
No, that's not it at all.
It was done to permit programs to have predictable, and therefore
analyzable and optimizable, performance. If you don't know how
expensive an operation is, you can't make tradeoffs. Even if the
standard library operation hasn't the complexity you want for a
particular use, at least you know what it is, and you know to
substitute a different algorithm for the (rare) case where the
standard heuristic is wrong. Without specs you have to use your
own algorithms anywhere performance matters, because you don't
know *what* the library might do.
In early (and who knows, maybe current?) Microsoft C libraries,
qsort() had a worst-case linear _space_ requirement. (Of course
there's never any excuse for this.) But it conformed. Many other
implementations were as bad, so common coding standards (e.g. at
Mentor Graphics in the late '80's) specified that qsort() must
not be used. Without complexity requirements in the Standard C++
Library, similar restrictions would have been reasonable.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Jim Barry" <jim.barry@bigfoot.com>
Date: 1998/06/23 Raw View
J. Kanze wrote in message ...
>
>The C++ exception mechanism is a mechanism for reporting errors. Or
are
>you claiming that it helps detect them, or handle them, as well.
Yes, I am claiming that exceptions help enormously with error
handling. Maybe we are at cross-purposes here; by errors, I mean stuff
like i/o failures, and I am talking about the capability of recovering
cleanly from such failures. Perhaps you mean programming errors.
>Obviously. So perhaps "unexpected" wasn't the right word. Although
>there is certainly nothing in the code for a function call that
>indicates that we might suddenly go to the end of the function,
without
>executing the following code.
That is what exception-specifications are for. A function makes a
contract by publishing in its declaration a list of exceptions that it
might throw, directly or indirectly. A function which calls that
function is required either to handle those exceptions or let them
"pass through" by listing them in its own exception-specification. Use
of the "resource acquisition is initialisation" technique (CPL3,
14.4)prevents leakage.
>A C++ compiler is not allowed (by the language) to check exception
>specifications. (Of course, it could generate a warning.)
I don't understand. If the compiler cannot check
exception-specifications then what are they for? To quote Stroustrup
CPL3, 14.6.1: "Importantly, exception-specifications are not required
to be checked exactly across compilation-unit boundaries. Naturally,
an implementation can check."
>Since Bjarne has admitted that using a subset is sometimes
appropriate,
>I would caracterize our disagreement as one concerning the level at
>which this subset should be defined. I also recognize the arguments
he
>presented as very legitimate concerns, which should be taken into
>account -- they are very strong arguments against standardization at
the
>ISO level. I find them less determining when it is a question of a
>definition by an association of vendors in a very particular, very
>limited market subsegment.
Sure. It's fine for people to not use a language feature because it
costs too much or they just don't need it. When I don't need it, I
turn off RTTI to get my executable size down a bit, and I just don't
see why that sort of thing requires a new language definition. It
seems to me that EC++ is for the benefit of compiler writers who
(understandably) want to avoid implementing the trickier parts of the
language, but still be able to put a sticker on the box saying
"standard-conforming". It's certainly not for the benefit of
programmers, and I don't think it should be touted as such.
- Jim
--
Jim Barry, Thermoteknix Systems Ltd., Cambridge, UK.
http://www.thermoteknix.co.uk Queen's Award for Export 1998
Antispam address courtesy of http://www.bigfoot.com
Or e-mail direct: jim at thermoteknix dot co dot uk
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/06/23 Raw View
Jerry Coffin wrote:
...
> bit differently in the first place -- I've yet to be convinced that
> placing requirements on computational complexity really accomplished
> anything useful. For the most part, it simply made it impossible for
> the implementor to make trade-offs appropriate to the environment
> they're supporting.
The implementor can provide any non-standard trade-offs they want, as
extensions to the standard. What the complexity requirements do is
provide programmers with a way of knowing something about what the
trade-offs will be for a design choice relating to the STL, something
that will remain true no matter where the code is ported to.
> I guess in theory this was done to guarantee that all programs would
> be efficient. In reality, it doesn't go far enough to guarantee such
Not quite; it was done to guarantee that the developer know something
about the efficiency consequences of STL design decisions. There is no
way I would be willing to use a map<> class for portable code if I
thought that implementors were free to use a linear search for every
access; I'd roll my own binary-tree implementation, and ignore the
standard.
> a thing, and I can't think of a way of rewriting the specification so
> it would either. If a library chooses to use an algorithm with
> particularly poor computational complexity, it can still comply with
> the standard by wasting the proper lengths of times when told to work
> on small collections. Obviously this isn't an attractive option...
False - you cannot decrease the computational complexity by adding
operations. By definition, computational complexity is measured in the
limit of arbitrarily large N. If the operations you add have a
complexity in themselves which is less than that of the original
algorithm, they become neglible by comparison for large N, leaving the
original complexity unchanged. If they have a higher complexity, they
will dominate for large N, increasing the complexity.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "David J. Littleboy" <davidjl@gol.com>
Date: 1998/06/23 Raw View
Jim Barry wrote in message
<898604025.3958.0.nnrp-01.9e98e8f6@news.demon.co.uk>...
>Sure. It's fine for people to not use a language feature because it
>costs too much or they just don't need it. When I don't need it, I
>turn off RTTI to get my executable size down a bit, and I just don't
>see why that sort of thing requires a new language definition.
Because (as has been said before) the C++ standard defines the language in
such a way that it forces code bloat (at least in the library) that can't be
prevented by just by "turning off" the parts you don't need. At a minimum,
you have to have a library that exactly matches the things you turn off.
> It
>seems to me that EC++ is for the benefit of compiler writers who
>(understandably) want to avoid implementing the trickier parts of the
>language, but still be able to put a sticker on the box saying
>"standard-conforming".
This has been re-repeated and re-refuted so many times it's getting silly.
The only vendors who sell an EC++ package are vendors who's main product is
a full C++ compiler and/or library. No one in the compiler or library market
makes only EC++ products. I suppose you could say EC++ is "for the benefit
of" full C++ compiler/library vendors who would like to increase their
market.
Whom EC++ really is for the benefit of is embedded hardware vendors who are
put off at the current memory requirements of C++. It also happens that most
of these hardware vendors are not convinced that the advanced features of
the full language speak to their needs, and thus they aren't justified in
supporting them from a cost/benefit standpoint.
>It's certainly not for the benefit of
>programmers, and I don't think it should be touted as such.
I think this is the most incorrect of your comments. EC++ is being designed
for environments where C++ is currently unavailable. As such, it will very
rarely replace C++. It will be replacing assembler or C, and as such will be
welcomed.
The programmers who might be using EC++ are programmers who's employer has
decided to use a particular embedded microcontroller made by some hardware
vendor. These machines largely have a unique instruction set and a large set
of very random "peripheral functions" (A/D and D/A converters, timers,
serial I/O controllers, LCD drivers) on the chip itself. That hardware
vendor provides a software development environment, simply because no one
else is going to. Right now, that's either assembler or C. When EC++
replaces the assembler or C in these contexts, it would very much be to the
benefit of the programmers.
By the way, EC++ is pretty draconian about slashing out C++ features, and I
think it is this that causes a lot of the objections. However, I see that as
good news. It means that there will be strong motivations to move to full
C++ as soon as memory constraints allow. By dropping the cost of entry it
increases that size of the C++ community, and by _not_ being "almost C++" it
will be less likely to be mistaken for anything other than an interim
measure.
David J. Littleboy <davidjl@gol.nonspam.com>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Oleg Zabluda <zabluda@math.psu.edu>
Date: 1998/06/21 Raw View
David J. Littleboy <davidjl@gol.com> wrote:
: Oleg Zabluda wrote in message <6mf3lh$kn6@marianna.psu.edu>...
: >David J. Littleboy <davidjl@gol.com> wrote:
: >: My point is that STL is not a viable programming style
: >: in the memory constrained subset of the embedded area.
: >
: >Nonsense. STL has no inherent overhead compared to hand-written
: >code with identical functionality. Neither in memory size nor in
: >speed.
: Huh?
: Speed: Every book I've seen says "code with the standard library and then
: fix it if it's too slow."
STL coming from your compiler vendor, is a universal general purpose
library. Because it is not tailored to everyone's specific needs, it
can't be sufficiently fast for everyone. The advice holds for every
other library on existance as well.
: STL forces you to use its algorithms and data
: structures.
Not true. The genius of Stepanov is exactly in the fact that he
realized that you can separate data structures and algorithms,
without any performance penalty. Later, the committee realized
that you can separate storage from the containers as well,
again with no performance hit.
Doing so enables you to use you own data structures and/or
algorithms within or without STL.
: STL's quicksort is usually OK, except that it's O(n^2) for
: almost sorted data.
So write and use your own sort. BTW, in SGI STL ithe worst case
is not O(n^2) anymore, I think.
: <set> (last time I checked) isn't implemented with hash
: tables.
Because hash tables have horrible worst-case complexity and
writing hash functions is impossible for general-purpose
library. You can get hash_set from third parties, like SGI
for example, or write your own.
: Value semantics in containers isn't always the right thing.
: (Allocating large numbers of small objects is gross on the system I run on
: (and has at least one word of overhead per object in principle) and some
: sort of memory pooling is often required. I suppose I might be able to
: figure out how to interface Scott Meyer's approach into the STL, but that's
: beyond this ex-BCPL programmer at this point in time.) The list goes on. It
: looks to me that STL may be the right answer 99% of the time, but the
: majority of time critical stuff falls in that last 1%.
Note words "with identical functionality" in my original post.
Surely, if STL is inappropriate for whatever reasons for your
needs, using it instead of hand-written code might indeed
decrease your performance. This doesn't imply what you've written
however: -- "My point is that STL is not a viable programming style
in the memory constrained subset of the embedded area."
SGI STL happened to optimize for speed. Typical modern compilers
are also concerned with speed more then with memory. However
there is nothing inherent in STL which creates code
with larger memory footprint then hand-written code with identical
functionality.
[...]
: I guess the other way of looking at this that I'm the programs I'm writing
: are not large enough to amortize the cost of including the STL headers and
: instantiating the first data type used.
I think it has more to do with immaturity of current optimizers
and insufficient choice of STL implementations.
Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Jason Merrill <jason@cygnus.com>
Date: 1998/06/21 Raw View
>>>>> David J Littleboy <davidjl@gol.com> writes:
> Speed: Every book I've seen says "code with the standard library and then
> fix it if it's too slow." STL forces you to use its algorithms and data
> structures.
Nonsense. It's a framework; write your own algorithms and data structures
if you don't like the standard ones.
> STL's quicksort is usually OK, except that it's O(n^2) for almost sorted
> data.
The SGI implementation isn't, because it uses introsort.
> <set> (last time I checked) isn't implemented with hash tables.
The SGI implementation includes hash_set.
Jason
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/21 Raw View
Jason Merrill wrote:
>
> Of course. But my point is this: why does EC++ specify a language subset
> when all the gains are from changes to the library?
Because not all the gains are from changes to the library. Exceptions
are the most obvious example. The simple tests that the Novel folks did
involved existing source code that could be compiled without
modification both ways. Library size tends to dominate in that context.
We clearly need better benchmarks in order to be able to talk about
size issues more realistically. The Novel work was a start, but it's not
very rigorous.
-- Pete
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Matt Austern <austern@sgi.com>
Date: 1998/06/21 Raw View
"David J. Littleboy" <davidjl@gol.com> writes:
> Speed: Every book I've seen says "code with the standard library and then
> fix it if it's too slow." STL forces you to use its algorithms and data
> structures. STL's quicksort is usually OK, except that it's O(n^2) for
> almost sorted data. <set> (last time I checked) isn't implemented with hash
> tables.
The standard allows sort() to be implemented in such a way that its
complexity is worst-case quadratic. However, (1) Some implementations
have versions of sort that have guaranteed O(N log(N)) worst-case
complexity (SGI has had such an implementation for more than a year;
it uses introsort instead of quicksort), and I expect that all library
vendors will have improved versions of sort() before long; and (2) I'm
not aware of any library vendors that provide a sort() with worst-case
behavior for already-sorted sequences. Every implementation I'm aware
of uses median-of-three quicksort, which has worst case behavior for
rather complicated and rare input sequences.
(And yes, it's true that set<> doesn't use hash tables. The
requirements forbid it: set has guaranteed logarithmic worst-case
complexity, and hash tables can't guarantee anything better than
linear worst-case complexity. If you care more about average speed
than worst-case, then you should use a different data structure. But
that's not an argument for using a library that's smaller than the
standard C++ library: it's an argument for using a library that's
larger, one that provides both the standard container set<> and, as an
extension, the non-standard container hash_set<>.)
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: hinnant@_anti-spam_lightlink.com (Howard Hinnant)
Date: 1998/06/21 Raw View
In article <UMMi1.358$0T2.8497629@mothra.gol.ad.jp>, "David J. Littleboy"
<davidjl@gol.com> wrote:
>STL's quicksort is usually OK, except that it's O(n^2) for
> almost sorted data.
You need a better sort if that's the case. Go CodeWarrior! Um... yeah,
I'm biased. But I can promise you that CodeWarrior's sort (which is a
quick sort) does not display 0(n^2) behavior with sorted (or reverse
sorted) data.
-Howard
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "David J. Littleboy" <davidjl@gol.com>
Date: 1998/06/21 Raw View
David J. Littleboy wrote in message ...
>Code size: I'd never written a 200KB non-GUI program in 30 minutes before I
>had the STL to help. (I will admit that if I had cannibalized by existing
>code I have lying around for those things, it would have taken a couple of
>hours, but it wouldn't have been even 50KB.)
Oleg has probably already pointed this out by now, but my code size is
largely not STL but the standard library, with over 100K of that (actually
227KB) being thanks to <fstream>, *NOT* STL. And yes, adding in all the
other STL headers adds zero to the size until you use them. And STL code
bloat isn't all that bad. Instantiating a single deque costs 1KB.
Oh well, guess my other points will get ignored. Sigh.
David J. Littleboy <davidjl@gol.nonspam.com>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: fjh@cs.mu.OZ.AU (Fergus Henderson)
Date: 1998/06/22 Raw View
Matt Austern <austern@sgi.com> writes:
>(And yes, it's true that set<> doesn't use hash tables. The
>requirements forbid it: set has guaranteed logarithmic worst-case
>complexity, and hash tables can't guarantee anything better than
>linear worst-case complexity.
... unless you use a hash table whose nodes are some kind of balanced
binary tree structure, e.g. red-black trees. Then you get linear
average-case and logarithmic worst-case. Of course the constant factors
may be worse.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "David J. Littleboy" <davidjl@gol.com>
Date: 1998/06/22 Raw View
Oleg Zabluda wrote in message <6mh13h$u3@marianna.psu.edu>...
>STL coming from your compiler vendor, is a universal general purpose
>library. Because it is not tailored to everyone's specific needs, it
>can't be sufficiently fast for everyone.
OK. But a "universal general purpose library" probably looks like
overkill to the EC++ community, and the cost of supporting something that
might not be used in the speed and memory constrained corner of
the embedded world is off-putting.
>: STL forces you to use its algorithms and data
>: structures.
>
>Not true. The genius of Stepanov is exactly in the fact that he
>realized that you can separate data structures and algorithms,
>without any performance penalty. Later, the committee realized
>that you can separate storage from the containers as well,
>again with no performance hit.
>
>Doing so enables you to use you own data structures and/or
>algorithms within or without STL.
Hmm. The reason for my diatribe was that in the stuff I've been doing lately
the STL pointed to (or seemed to to me) a particular way of doing things
(groveling over cin or an ifstream to create STL strings that are then
stuffed into a vector or set.), which resulted in acceptable size
and performance on a 160MB 333MHz machine, but wouldn't on a lot of embedded
microcontrollers. On the other hand, a much lower level C-like approach
resulted in better performance with smaller run-time data requirements.
>Note words "with identical functionality" in my original post.
But there's never "identical functionality". The reason using <string> might
be the wrong idea is that a different approach to solving the problem would
use different functionality. If I wrote my own string class, I'd be right
where I started. The only way to beat STL is to play a different game.
Stated crudely, ad hoc kludges let you take short cuts. If your problem is
itself "completely general" and requires a "completely general" solution,
STL is the right idea. But real data in real problems has structure, and
symmetries, and properties that allow you to do things like find a good
hashing algorithm or the right sorting algorithm.
If you expect your programmers to be doing their homework and busting their
butts to find the shortcuts and the right algorithms from day one of every
project, then the expected utility of "universal general purpose libraries"
is reduced. The model "code at the highest level of generality first, then
optimize if needed" seems inappropriate since the a priori assumption is
that there isn't enough memory and cycles.
>Surely, if STL is inappropriate for whatever reasons for your
>needs, using it instead of hand-written code might indeed
>decrease your performance. This doesn't imply what you've written
>however: -- "My point is that STL is not a viable programming style
>in the memory constrained subset of the embedded area."
Well, if the phrase "not a viable style" is too strong, how about, "there
are cases where (current implementations of) STL can't be used due to memory
constraints, and those cases are common in (even if completely restricted
to) a certain segment of the embedded programming world."
Anyway, the point I'm trying to make is not so much that STL has "excessive"
overhead, but that the added value of STL in the EC++ context isn't seen as
being worth the costs. That's an economic/engineering decision, and one that
looks reasonable to me, given that development and support costs are likely
to be nontrivial.
>SGI STL happened to optimize for speed. Typical modern compilers
>are also concerned with speed more then with memory.
That's the problem: memory is ridiculously cheap, but any increase in speed
is greatly appreciated just about everywhere. Except that it's memory that's
in short supply in the EC++ world. Unless there's an EC++ standard, there
will be little motivation for the vendors to try to reduce library and code
sizes. (My turn to play the "vendor paranoia" card<g>.)
David J. Littleboy <davidjl@gol.nonspam.com>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1998/06/22 Raw View
In article <hinnant-2006981906110001@port28.lightlink.com>,
hinnant@_anti-spam_lightlink.com says...
[ ... ]
> You need a better sort if that's the case. Go CodeWarrior! Um... yeah,
> I'm biased. But I can promise you that CodeWarrior's sort (which is a
> quick sort) does not display 0(n^2) behavior with sorted (or reverse
> sorted) data.
In reality, I've yet to see any implementation of the standard library
that uses a method with such execrable performance on nearly sorted
data. For anything that uses a QuickSort, there _will_ be a worst
case input order that closely approaches O(N^2) performance, but the
usual is to use something like median of three partition selection,
which makes the worst-case input order fairly complex.
If a library was really excited about worst case performance, it could
implement sort() with any number of other algorithms, Heap Sort and
Merge Sort being a couple of the best known.
IMO, this is another example of the specification of computational
complexity being overly constraining without serving a useful purpose.
On a system where it's known that data sets will always be relatively
small (e.g. because the system doesn't address a lot of memory) it
might be perfectly reasonable to implement sort() using a Shell-
Metzner sort. Unfortunately, this doesn't meet the official
computational complexity requirements, even though on relatively small
collections it's often faster than most of the others, along with
typically using less memory.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1998/06/22 Raw View
In article <fxtwwabesy2.fsf@isolde.mti.sgi.com>, austern@sgi.com
says...
[ ... ]
> (And yes, it's true that set<> doesn't use hash tables. The
> requirements forbid it: set has guaranteed logarithmic worst-case
> complexity, and hash tables can't guarantee anything better than
> linear worst-case complexity.
As I believe I've posted here at least once before, this isn't
entirely true: if you use a balanced tree to handle hash collisions,
you get logarithmic wort-case performance on insertions, lookups and
deletions. Unfortunately, this still leaves iterating through the
collection in order, and I don't know of an easy way to address that.
> If you care more about average speed
> than worst-case, then you should use a different data structure. But
> that's not an argument for using a library that's smaller than the
> standard C++ library: it's an argument for using a library that's
> larger, one that provides both the standard container set<> and, as an
> extension, the non-standard container hash_set<>.)
Or, perhaps, it's an argument for the library having been defined a
bit differently in the first place -- I've yet to be convinced that
placing requirements on computational complexity really accomplished
anything useful. For the most part, it simply made it impossible for
the implementor to make trade-offs appropriate to the environment
they're supporting.
I guess in theory this was done to guarantee that all programs would
be efficient. In reality, it doesn't go far enough to guarantee such
a thing, and I can't think of a way of rewriting the specification so
it would either. If a library chooses to use an algorithm with
particularly poor computational complexity, it can still comply with
the standard by wasting the proper lengths of times when told to work
on small collections. Obviously this isn't an attractive option...
--
Later,
Jerry.
The Universe is a figment of its own imagination.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/06/22 Raw View
Fergus Henderson wrote:
>
> Matt Austern <austern@sgi.com> writes:
>
> >(And yes, it's true that set<> doesn't use hash tables. The
> >requirements forbid it: set has guaranteed logarithmic worst-case
> >complexity, and hash tables can't guarantee anything better than
> >linear worst-case complexity.
>
> ... unless you use a hash table whose nodes are some kind of balanced
> binary tree structure, e.g. red-black trees. Then you get linear
> average-case and logarithmic worst-case. Of course the constant factors
> may be worse.
Ahem... you say that average-case is worse than worst-case? :-)
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Jason Merrill <jason@cygnus.com>
Date: 1998/06/22 Raw View
>>>>> Pete Becker <petebecker@acm.org> writes:
> Jason Merrill wrote:
>>
>> Of course. But my point is this: why does EC++ specify a language subset
>> when all the gains are from changes to the library?
> Because not all the gains are from changes to the library. Exceptions
> are the most obvious example.
Aargh! That's what I was just talking about!
As I said in my previous message in this thread, with existing compilers
you can turn exceptions and RTTI off with flags if you don't want to pay
for those features. So why prevent people that want to make that tradeoff
from using them?
My point is, using an EC++ compiler with the EC++ library is essentially
equivalent to using a C++ compiler with the EC++ library, specifying the
options to turn off exceptions and RTTI. Do you dispute this?
Jason
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/19 Raw View
Wil Evers wrote:
>
>
> This makes we wonder what exactly triggers all this bloat. Is it just the
> locale stuff, or is it primarily caused by compilers instatantiating whole
> template classes instead of just the members functions that are actually
> used?
Good point. I had forgotten that the 1 Meg that I saw was with a
compiler that instantiated all template members. The 200k is with a
compiler that only instantiates members that are used, but even then it
takes work to get it there.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/20 Raw View
In article <35892700.446B@wizard.net>, James Kuyper <kuyper@wizard.net>
writes
>> (Indeed, our "GCD-C++ language standard" is an internal document
>> entitled "Portable C++ Coding Guidelines", a list of do's and don't's,
>> which is updated periodically as our compilers get better. Eventually,
>> this document will contain no restrictions on the language, but will
>> only discuss portability issues between systems.)
>
>Based upon the originally given description, that GCD-C++ can only
>contain features that are supported by all C++ versions, it can only
>shrink with time. You've apparantly modified the definition, by
>restricting it to the latest version of each compiler; with that
>modified definition, GCD-C++ is capable of expanding.
>
>With the originally stated definition, I doubt that GCD-C++ is a large
>enough language to be useful.
I think that the key point about GCD-C++ is that every company will have
its own version based upon the C++ compilers that it needs to use, and
the language features it can afford in its applications.
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/20 Raw View
In article <358A4895.48287A44@acm.org>, Pete Becker <petebecker@acm.org>
writes
>Jason Merrill wrote:
>
...snip...
>>
>> No, but they can be eliminated with existing options to existing
>> compilers. What overhead does g++ -fno-rtti -fno-exceptions have that an
>> EC++ compiler would necessarily not?
>>
>> In fact, Cygnus ships an EC++ product which consists of g++ with an option
>> that disables namespaces, MI, mutable, templates, RTTI, and exceptions. I
>> don't see the point; the above command would produce exactly the same code.
>> The EC++ option just adds diagnostics.
>
>No, EC++ also adds a library built with code size in mind. That's why
>Cygnus has been unable to match the significant size reductions that,
>for example, the Green Hills compiler gives with EC++. With a suitable
>library, g++ does much better.
Well it would always be possible to follow the lead of Wind River and
supply your library as a collection of modules and use #defines to
include the parts you want. I increased the size of a VxWorks image from
400k to 550k just by adding 2 defines. I shall shrink the code to a
more reasonable size when I know exactly which options I need.
>
>>
>> My understanding is that the Green Hills EC++ product is the same sort of
>> thing, with the EDG frontend. Certainly EDG also has --no_exceptions and
>> --no_rtti options.
>
>Green Hills ships the EDG front end plus an EC++ library. You can't take
>leave out one part of a design and expect it to work as specified.
But it *is* possible to write the EC++ library under the --no_exceptions
and --no_rtti options regime and supply it along with the full C++
library. Then if a customer says that the code it coming out too big you
can suggest using these options together with the smaller library. I
think a fully modular library would be better, but this would be easier
to implement.
>
>>
>> So just considering the language itself, what does EC++ buy users that a
>> couple of well-placed compiler options won't?
>
>Users don't use "the language itself", they use the language plus
>libraries.
Exactly, so supply several versions of the library and let the customer
choose.
I just don't want a situation where the market-competitive onus to
improve the full-featured C++ language is nullified by accepting an
inadequate subset as the embedded programmers ghetto.
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Oleg Zabluda <zabluda@math.psu.edu>
Date: 1998/06/20 Raw View
David J. Littleboy <davidjl@gol.com> wrote:
: My point is that STL is not a viable programming style
: in the memory constrained subset of the embedded area.
Nonsense. STL has no inherent overhead compared to hand-written
code with identical functionality. Neither in memory size nor in
speed. If anything, it'll produce smaller and faster code
then an ec++-programmer-who-allegedly-can't-learn-c++ can whip
out.
Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/20 Raw View
In article <3589AC08.A535DF96@acm.org>, Pete Becker <petebecker@acm.org>
writes
>Mike Davies wrote:
>>
>> C. I speak from personal experience of Watcom C/C++ V10.6 on QNX
>
>Does Watcom support locale objects?
I don't believe so at V10.6.
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/20 Raw View
In article <3589ABD2.422782FC@acm.org>, Pete Becker <petebecker@acm.org>
writes
>Mike Davies wrote:
>>
>>
>> I would be astonished if anybody in the low end embedded world compiled
>> a 20 line program in C++ and found it gave a 200k binary :-)
>> The way that happens is when compile against a (massive in your case)
>> library.
>
>Have you tried "Hello, world" with the full library?
*Which* version of the full library ?
> Two first attempts
>at implementating the library that I'm familiar with produced
>executables of over 1 Meg for hello world. With some work that can be
>gotten down to 200k. With some rather heroic (and fragile) efforts it
>can be reduced to about 60k.
I have never argued that it is impossible to produce a large library in
C++.
>
>> I intend to help that prediction come about by arguing against EC++
>> wherever I can :-)
>
>Fine, but base your arguments on facts, not on guesses.
I have used C++ for years, and although I know that the careless use of
libraries can give you unnecessarily large programs, I also know that
including only the minimum required headers gives C++ programs of
comperable size to C programs for similar functionality.
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Jason Merrill <jason@cygnus.com>
Date: 1998/06/20 Raw View
>>>>> Pete Becker <petebecker@acm.org> writes:
> Jason Merrill wrote:
>>
>> No, but they can be eliminated with existing options to existing
>> compilers. What overhead does g++ -fno-rtti -fno-exceptions have that an
>> EC++ compiler would necessarily not?
>>
>> In fact, Cygnus ships an EC++ product which consists of g++ with an option
>> that disables namespaces, MI, mutable, templates, RTTI, and exceptions. I
>> don't see the point; the above command would produce exactly the same code.
>> The EC++ option just adds diagnostics.
> No, EC++ also adds a library built with code size in mind. That's why
> Cygnus has been unable to match the significant size reductions that,
> for example, the Green Hills compiler gives with EC++. With a suitable
> library, g++ does much better.
Agreed.
>> So just considering the language itself, what does EC++ buy users that a
>> couple of well-placed compiler options won't?
> Users don't use "the language itself", they use the language plus
> libraries.
Of course. But my point is this: why does EC++ specify a language subset
when all the gains are from changes to the library?
Jason
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/20 Raw View
Mike Davies wrote:
>
> In article <358A4895.48287A44@acm.org>, Pete Becker <petebecker@acm.org>
> writes
> >Jason Merrill wrote:
> >
> ...snip...
>
>
> Well it would always be possible to follow the lead of Wind River and
> supply your library as a collection of modules and use #defines to
> include the parts you want. I increased the size of a VxWorks image
from
> 400k to 550k just by adding 2 defines. I shall shrink the code to a
> more reasonable size when I know exactly which options I need.
It's not that simple. The choice isn't "do I want this capability in the
library or don't I." The choice is "which version of formatted io do I
want to use," "do I want exceptions", etc. I can't imagine having to
specify the interactions of half a dozen such choices in the standard
library.
> >
> >>
> >> My understanding is that the Green Hills EC++ product is the same sort of
> >> thing, with the EDG frontend. Certainly EDG also has --no_exceptions and
> >> --no_rtti options.
> >
> >Green Hills ships the EDG front end plus an EC++ library. You can't take
> >leave out one part of a design and expect it to work as specified.
>
> But it *is* possible to write the EC++ library under the --no_exceptions
> and --no_rtti options regime and supply it along with the full C++
> library. Then if a customer says that the code it coming out too big you
> can suggest using these options together with the smaller library. I
> think a fully modular library would be better, but this would be easier
> to implement.
Which means shipping a dozen different libraries in order to support
some combination of the various options that users might want to select.
That's very expensive, probably prohibitive for most vendors. It's also
very confusing for users. Instead of having, say, two standard libraries
now there are a dozen.
>
> I just don't want a situation where the market-competitive onus to
> improve the full-featured C++ language is nullified by accepting an
> inadequate subset as the embedded programmers ghetto.
Nor do I. But nobody has proposed such a thing.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "David J. Littleboy" <davidjl@gol.com>
Date: 1998/06/20 Raw View
Oleg Zabluda wrote in message <6mf3lh$kn6@marianna.psu.edu>...
>David J. Littleboy <davidjl@gol.com> wrote:
>: My point is that STL is not a viable programming style
>: in the memory constrained subset of the embedded area.
>
>Nonsense. STL has no inherent overhead compared to hand-written
>code with identical functionality. Neither in memory size nor in
>speed.
Huh?
Speed: Every book I've seen says "code with the standard library and then
fix it if it's too slow." STL forces you to use its algorithms and data
structures. STL's quicksort is usually OK, except that it's O(n^2) for
almost sorted data. <set> (last time I checked) isn't implemented with hash
tables. Value semantics in containers isn't always the right thing.
(Allocating large numbers of small objects is gross on the system I run on
(and has at least one word of overhead per object in principle) and some
sort of memory pooling is often required. I suppose I might be able to
figure out how to interface Scott Meyer's approach into the STL, but that's
beyond this ex-BCPL programmer at this point in time.) The list goes on. It
looks to me that STL may be the right answer 99% of the time, but the
majority of time critical stuff falls in that last 1%.
Code size: I'd never written a 200KB non-GUI program in 30 minutes before I
had the STL to help. (I will admit that if I had cannibalized by existing
code I have lying around for those things, it would have taken a couple of
hours, but it wouldn't have been even 50KB.)
At least my (limited) experience is that STL is much easier to code with,
but that any time I code by hand it's going to be faster and smaller than
what I would have gotten with the STL.
I guess the other way of looking at this that I'm the programs I'm writing
are not large enough to amortize the cost of including the STL headers and
instantiating the first data type used. Unfortunately, I think that's true
of a lot of the embedded systems that will be the purview of EC++
David J. Littleboy <davidjl@gol.nonspam.com>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/18 Raw View
In article <6m8biu$1pj$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
writes
>In article <fFJmlGAcLXh1Ew3r@noco.demon.co.uk>,
> Mike Davies <mike_davies@noco.demon.co.uk> wrote:
>
> [...]
>> Has he asked his programmers ? Do they have any OO design skills ?
>> Because if so they will reply that they will need all of C++ at some
>> point in time.
>
>I rather take ombrage at this. It has nothing to do with EC++, but
>I feel sure that in the applications I'm currently working on, there
>are large parts of C++ which I'll never need.
Please list them, I notice you say something rather different below
> And I don't consider
>my OO design skills to be 0. How on earth did we manage to write
>programs before? For that matter, how do I manage now, since most
>of the compilers I use don't support the full language yet?
I haven't use a C++ compiler since I don't know when that didn't offer a
*much* fuller implementation than EC++, and I have severely missed
features present in the new standard. If you stay with programming
practices close to normal C ones then you won't miss them to the same
extent.
>
>Of course, I'm sure that the poster didn't really mean "need" -- strictly
>speaking, all anyone needs is a language which is Turing complete.
Read on its own this is a fatuous remark.
>The choice beyond that is always motivated by the trade-offs: how much
>does this feature cost (and they all cost something, if only in added
>language complexity) vs. how much does it save.
If you don't need the features of C++ to support your style of
programming then I am surprised to hear you say you are doing OO design.
In any case the language is only as complex as the subset that you
choose to use.
>
>The trade-off's I'm seeing on the projects I'm currently working on (which
>are NOT the type of systems targetted by EC++) is that we really don't need
>anything that wasn't in CFront 3.0, except maybe exceptions. On my previous
>project (which had higher reliability constraints), we didn't even need
>exceptions, but we DID need some form of separate compilation of templates --
>what has been standardized with export. Namespaces would be nice.
So condensing your remarks above : "
___start___
>there
>are large parts of C++ which I'll never need
...
>we
...
>don't need
>anything that wasn't in CFront 3.0, except
...
>exceptions
...
>we
...
>need some form of
...
> templates
...
>Namespaces would be nice.
___end___
You are going to get all this stuff (that you need and don't need at the
same time) from EC++ ?
> But
>the new template features, or STL, are simply excess baggage -- something
>that we have to pay for, but won't use.
>
No, templates and STL come without overhead, no baggage, just don't use
it 'till you need it.
>Obviously, I'm not suggesting that any of these features be removed from
>the standard -- I know people who really do need them.
If you are arguing for EC++ that is *exactly* what you are arguing for.
...snip...
>
>Back to EC++: apparently, there are some people who find that in its
>current state, and the current state of technology, the complete standard
>does not represent an acceptable trade-off for them.
The people most vociferous in this point of view are compiler vendors so
far as I can tell. Why should a programmer object to zero-overhead
features in a language when they can just avoid using them ?
> Whether you or I
>agree will not change their feeling about this.
I hope that arguing my point of view can change peoples opinion.
...snip...
>When you only have 16KB to work in, third party libraries are generally
>not a problem.
Generally true. Of course namespaces are vital when it is false. Sadly
you don't get to choose which is the case :-(
> In fact, although I currently work in a 4GB address
>space, with a large number of third party libraries, I manage to get
>by without namespaces very well. Namespaces may be an elegant solution,
>but I've yet to see the problem.
You had best sort out a solution now then, before it suddenly appears
in your critical path.
>I presume you mean programmer efficiency, which is, of course, where
>templates really shine. (I can write programs that run faster using
>generic.h than I can with templates. I certainly cannot write them
>anywhere near as fast, however.)
And execution efficiency.
...snip...
>> multiple inheritance - abstract interfaces
>
>This is certainly what I'd miss most in EC++. Still, the smaller the
>system, the less inheritance (multiple or otherwise) is important.
>
I see the importance of *multiple* inheritance as being mainly due to
the ease with which abstract interfaces can be maintained. This is a
programmer effort issue, not invalidated by small code size. Think of
the case where an embedded box may need to support many different
attachments, but ony one of them will be fitted to any given box.
...snip...
>>
>> unable to use the safety features of exceptions to write safety critical
>> code,
>
>I mentioned this is passing, but more as a counter argument because people
>were claiming that you couldn't write robust code without certain features,
>where in fact, you can't write really robust code with them.
No, it is the other way around. We'll just have to agree to differ, I
think :-)
...snip...
>> > However, I'd bet that the EC++
>> >standard goes over a lot better with programmers at companies that are
>> >currently purchasing said manager's microcontrollers, since they might have
>> >a bit more sympathy for said managers difficulties and they might prefer to
>> >see a limited feature set implemented well.
>>
>> No, not really, it isn't the managers who write the code is it ?
>
>No, they pay for the programmers, they pay for the tools, and in the
>end, they take the risks. Don't underrate the importance of managers,
>nor the criteria they use for their decisions.
I think you've misunderstood the issue here. I was being asked to feel
sorry for the microcontroller vendor (as a proxy for the compiler
vendor). If *he* felt sorry for *me* then he'd relent and write me a
full featured zero-overhread C++ compiler. Which I see as being his job.
...snip...
>> It may be the case that if you talk to programmers who have not got very
>> much OO design experience they do not see the need for some features of
>> C++.
>
>I'm not sure how to answer this one. My first reaction was that I consider
>myself an experienced OO designer, and I don't see the need for many of
>the features. But if I think about it, I do see the need for them. Just
>not in most application domains. And not in embedded processors.
But embedded SW is the most likely to need the efficiency advantages of
C++ over EC++.
>
>> If you explained to them the the efficiency advantages of C++ I bet
>> you'd get a different response - I give some examples :
>>
>> virtual functions implemented via a jump table vs switch cases,
>
>See above. On small systems, you generally don't need virtual functions.
It ain't the size of the system, its the style of the code. Jump tables
execute in constant time, switches (in the compilers whose output I've
seen) in linear time wrt the number of case statements.
>(On life critical systems, you probably won't allow them.)
What ? Why ? Jump tables are more dangerous than a sequence of
conditional jumps ? I don't think so.
>
>> templates that can save pointer indirection or function call overhreads,
>
>??? I don't get this. Can save ... compared to what? Hand written
>specialized code? Certainly not.
I though they can take reference parameters without needing temporarys,
am I wrong here ?
...snip...
>> exception handling that handles *every* error returned by *every*
>> function at exactly the place where it is convenient for about a 5% code
>> space cost,
>
>Which implementation? All of the exception implementations I've seen
>have been very gourmand in code space (or introduced unacceptable run-time
>overhead, plus additional requirements in stack space).
Watcom C/C++ V10.6 and Borland C++ V4.5 are both good examples, and both
used in embedded systems programming.
...snip...
>James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
--
Mike Davies
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/18 Raw View
In article <JQih1.285$0T2.4990046@mothra.gol.ad.jp>, "David J.
Littleboy" <davidjl@gol.com> writes
...snip...
>Any feature left out makes EC++ a worse language than C++. There is no
>question that EC++ is a worse language than C++. The only issue is that for
>some people, the added value of the features being cut is outweighed by the
>costs of implementing and support. Templates and STL are wonderful. But the
>20-line program I wrote last night compiled into a 200K binary, compiler
>options set for minimize code size.
I would be astonished if anybody in the low end embedded world compiled
a 20 line program in C++ and found it gave a 200k binary :-)
The way that happens is when compile against a (massive in your case)
library.
You do not yourself make the fallacious inference that this is
*overhead*, as opposed to *cost* but somebody else might if I don't
point it out, so : that 200k has bought you something, if you write a
20k line program against the same library the cost looks better, I bet.
The STL of course is implemented wholly in header files (at least the
version I looked at was, that may have changed). There is not much cost
there (& no overhead at all).
>That sort of thing is not viable in the
>low end of the embedded world.
No indeed. I think your result above is a long way from the typical
experience of embedded C++ programmers :-)
When I was recently compiling Watcom C++ 10.6 programs in an embedded
application, complete stand-alone programs were coming out at between 5k
and 100k in size. The 100k programs were full-featured GUI applications,
the smaller ones were command line utilities. In no case did I make a
special effort to reduce the code size.
>
>Maybe EC++ should have namespaces. But that's a technical argument for a
>language you and I are never going to be using.
I intend to help that prediction come about by arguing against EC++
wherever I can :-)
...snip...
>But
>when was the last time anyone even dreamed about using a commercial library
>product in the code used to run a vending machine?
When the last person who knew about a suitable commercial library (eg
the STL) programmed a vending machine, I guess. Or did you mean
commercial in the sense of having a non-zero price tag :-)
I dreamed of using C++ (templates and inline virtual functions, if you
must know the details) the other week when I was writing code for a PIC
(36 bytes of data-space in total !)
>There's a large world out
>there that needs the OO stuff that C++ provides, but can't afford (the code
>size, implementation, and support costs of) full C++.
They should use just the parts of C++ that they need, then. They will
then find, as if by a miracle, that the costs become affordable.
>
>>Embedded programming is
>>enough of a ghetto as it is.
>
>That's why they need a path to full C++. Asking individual groups to
>research their own subset of C++ is neither nice nor reasonable.
No it is vital to their interests that *they* be able to *choose* the
parts of C++ that they need and can afford to use.
If they don't need a feature of C++ then there is no *overhead* if they
don't use it. There is only a cost for the features that are used.
Embedded programmers are a various bunch, and they, least of all
programmers can afford a lowest common denominator language subset. If
you don't believe me look at the language *extensions* provided by
various flavours of embedded C compilers !
> EC++ would
>allow programmers in that world to start using a subset of C++ in the very
>near future.
They can do that now by using C++. The difference is that they get to
choose the subset instead of having it foisted upon them by a compiler
vendor who is having difficulty doing for profit something that the egcs
group is doing very well for free.
>This would significantly increase the amount of C++ expertise
I wondered aloud in a post to this thread that didn't make it through,
how long it would take for the "E" in EC++ to cease to be pronounced.
...snip...
>I'm not asking you to use EC++. I'm asking you to allow people who don't
>have 200k extra lying around not to have to implement templates and support
>STL.
There is no overhead in the STL, nor in templates. You know very well
that the STL was not responsible for your 200k program bloat.
Your statement, as written, looks almost as if it was intended to
mislead. I assume that it was not, so please explain what you mean.
..snip..
>To a large extent, that's exactly what EC++ is. It's just that there are a
>lot of advantages to defining what the zeroth level subset is so that the
>majority of players can get to work.
No, I don't agree. And particularly not with such a *bad* subset that
excludes things like exceptions, templates, namespaces. These will all
be important at some point in time to any embedded programmer,
especially those most resource constrained.
> Later, everyone who can switch, will
>switch since there are such obvious advantages to C++.
Why *switch* at all ? Is an *extra* language change in the interests of
embedded programmers ?
No, my advice to embedded programmers starting in C++ is the same as I
received : use the parts you need and understand. Read and learn more as
you find you need it. That way the costs will always seem reasonable to
you compared to the benefits you are receiving.
--
Mike Davies
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Christian Millour <chris161@club-internet.fr>
Date: 1998/06/18 Raw View
David R Tribble wrote:
> sed 's/std:://g' foo.c >xfoo.c # The hack
unsafe. 's/\<std\>:://g' should be somewhat better. You might also
keep the ::.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Jason Merrill <jason@cygnus.com>
Date: 1998/06/19 Raw View
>>>>> Pete Becker <petebecker@acm.org> writes:
> Bjarne Stroustrup wrote:
>> > Note that all the supporters of EC++ state that they aim to support the
>> > full international standard eventually.
> Yes: "aim", not "expect". It has not been convincingly demonstrated that
> the overheads that EC++ eliminates can be eliminated by improved
> compilers.
No, but they can be eliminated with existing options to existing
compilers. What overhead does g++ -fno-rtti -fno-exceptions have that an
EC++ compiler would necessarily not?
In fact, Cygnus ships an EC++ product which consists of g++ with an option
that disables namespaces, MI, mutable, templates, RTTI, and exceptions. I
don't see the point; the above command would produce exactly the same code.
The EC++ option just adds diagnostics.
My understanding is that the Green Hills EC++ product is the same sort of
thing, with the EDG frontend. Certainly EDG also has --no_exceptions and
--no_rtti options.
So just considering the language itself, what does EC++ buy users that a
couple of well-placed compiler options won't?
Jason
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/06/19 Raw View
David R Tribble wrote:
>
> I, David R Tribble wrote:
> >> Theoretical arguments aside, there are those of us who develop real
> >> code designed to run on several real platforms. We are thus forced to
> >> use a "least common denominator" language; call it "LCD-C++". Some...
>
> [That should be "greatest common denominator" language, or "GCD-C++".]
>
> >> ...
> >> Is GCD-C++ the same as EC++? I don't know. But I really only care
> >> that GCD-C++, the language I must program with, is not the same as
> >> ISO C++.
>
> James Kuyper wrote:
> > More importantly, GCD-C++ will be incompatible with ISO C++ (I can't
> > give details, I have no copy of the GCD-C++ standard :-). Therefore, any
> > code written in it will slowly become less and less portable as more and
> > more vendors start providing ISO C++.
>
> No, since GCD-C++ is a proper subset of the C++ standard (specifically,
> the subset that is supported TODAY), it should be, and probably is,
> fully compatible with full-blown ISO C++. One of the goals for us is
> for GCD-C++ to be a truly proper subset of ISO C++, for the simple
> reason that we don't want to have to rewrite our code in the future in
> order to correct incompatibilities with ISO C++. As far as we can tell,
> our code will compile okay on a fully compliant ISO C++ compiler in the
> future.
>
> Bear in mind that GCD-C++ is not a language definition of what you CAN
> use so much as it is a list of features you CANNOT use. (Things like
> nested classes, complicated templates, exception handling, std::, etc.)
> GCD-C++ is designed to omit the features of ISO C++ we simply don't have
> universally available to us yet.
>
> Thus the language covered by GCD-C++ is an evolving subset. Every
> time we get a new release of a compiler for one of our operating
> systems,
> we see if it supports more of the full C++ language, so that we can
> remove some restrictions from our GCD-C++ subset. For example, once all
> our compilers support nested classes correctly, we will remove the
> restriction on using nested classes from GCD-C++, or in other words, we
> will add nested classes to GCD-C++. Eventually, we hope, GCD-C++ will
> be identical to ISO C++. But we don't expect that to happen for at
> least another 12 to 24 months.
>
> (Indeed, our "GCD-C++ language standard" is an internal document
> entitled "Portable C++ Coding Guidelines", a list of do's and don't's,
> which is updated periodically as our compilers get better. Eventually,
> this document will contain no restrictions on the language, but will
> only discuss portability issues between systems.)
Based upon the originally given description, that GCD-C++ can only
contain features that are supported by all C++ versions, it can only
shrink with time. You've apparantly modified the definition, by
restricting it to the latest version of each compiler; with that
modified definition, GCD-C++ is capable of expanding.
With the originally stated definition, I doubt that GCD-C++ is a large
enough language to be useful. In particular, it cannot contain
<iostreams>, because that isn't supported by the older versions of C++,
and it can't contain <iostreams.h> because that isn't supported by the
draft ISO C++ standard. ISO C++ will be very different from previous
practice, far more so than was the case with the first C standard. That
may have been a wise decision, but there are going to be a lot of costs
to that decision. This is one of them.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Hankel O'Fung" <hkfung@ust.hk>
Date: 1998/06/19 Raw View
Dear all,
Daniel Parker wrote:
> Now, if a programmer were using a Standard C++ compiler, with RTTI disabled,
> and he writes a program using the subset of the language found in EC++,
> except he doesn't use streams, is there a reason to suppose that the
> resulting executable would be bigger than the executable EC++ would produce?
Being an inexperienced programmer, I am not qualified to attend the
debate in this thread. However, in light of Parker's question above, I
think no fair judgement could be made without enough and accurate
information regarding the following:
1) Compilers. Is there any compiler tailor-made to EC++ going to be
shipped? If yes, why does such a compiler perform better than any C++
compiler in optimization of code size/speed? If not, are current
compilers not aggresive enough? Are compiler vendors more concentrated
in catching up the standard or marketing rather than improving the
compilers' performances? (Well, I haven't any implications here. I just
state the questions.)
2) Programmers and education. There is a blind spot in the debate,
namely, most people here are working in the states or in Europe.
Undoubtedly, the US is a knowledge center. However, does anybody know
about the situation in Japan or Asia? (Well, I don't know.) Is there a
good environment for programmers to exchange their knowledge or to
learn the best practices? If you are not a racist, you should agree
that an "average programmer" in Japan and an average American
programmer should be equally intelligent. But there is still a chance
for the Japanese to feel difficult to learn those new C++ features, or
to migrate from C to the large language C++ because the C++ population
in Japan may be small. Some ladies or gentlemen here may learn C++ by
themselves without difficulties, but I strongly believe that an average
C++ programmer needs mentors and advices in the course of learning. And
don't forget that the Japanese are not good at English. An average
Japanese programmer may have great difficulty to communicate with a
guru in the West. Perhaps someone who know the situation well could
give us some comments.
3) Coverage. Is the EC++ committee pushing a worldwide standard? If
what she needs is only a standard for the Japanese microcontrollers, I
see no reason why the use of EC++ would be harmful to the C++
community. Somehow I have the impression (not necessarily true, of
course) that the Japaneses are seeking help (instead of trying to
conquer the C++ community by the "stripped down" / "crippled" version
of C++) but find that people are blaming them for the problems they
have.
Regards,
Hankel
--
IEEM Dept, HKUST, Clear Water Bay, Kowloon, Hong Kong
voice (852) 2358 7103 fax (852) 2358 0062
http://home.ust.hk/~hkfung
The biggest difference between the so called good commanders and
bad commanders lies in that the former killed millions of enemy
soliders, while the latter killed millions of his own.
- Yang Wenli
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/19 Raw View
In article <6m6i4q$7k1$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
writes
>> >: >In this case, you are simply wrong. In hi-rel code, exceptions are
>> >: >generally banned, because proving exception safety is too difficult.
>> >
>> >: No, I don't agree. It is completely trivial to make C++ code exception
>> >: safe : compile all modules with exceptions enabled and use the exception
>> >: enabled version of the library. Then wrap the contents of main() in a
>> >: try...catch block.
>> >
>> >What James Kanze probably meant is that it is difficult to ensure
>> >that all relevant cleanup was being made, not that it is difficult
>> >to ensure that an exception does not escape from main().
>>
>> That ain't what he said.
>
>That's exactly what I said. What do you think "exception safety"
>means?
You are not making the distinction between exception safety (trivial in
C++ , hard in other languages like C for example) with resource
(de)allocation (hard in any language, but provided better for in C++
than in for example C)
...snip...
> Handling errors is difficult, period. Exceptions
>make reporting errors simpler -- they do not have any effect on detecting
>them nor on handling them.
Not so. Exceptions make handling errors easier than using error codes.
This is because you only have to write the code to handle the error at
two points : the point where you detect the errror, and the point where
you deal with it.
If you use function return codes then every function has to supply code
to handle all the error codes (either pass the error code up the chain
or deal with the error) that can be returned by *any* function beneath
it.
In any case the fact that reporting errors is easier in C++ is a
convincing reason for choosing the language on its own. I'm sure we're
in agreement that SW reliability will improve if programmers become more
punctilious about dealing with errors.
>
>Exceptions also introduce unexpected program flow in your program. What
>the effect of this is depends on many things, but it is never positive.
You do not make the distinction between unexpected program flow and
implicit program flow.
The implicit program flow produced by exceptions *is* advantageous IMO
because it allows the main function performed by the piece of software
to be performed without distracting the programmer/maintainer with a
pile if inessential detail.
The detail is inessential using exceptions because as I say above you
only need to write the exception producer & exception handler, not all
the reporting code in between.
>Whether the negative effect fo the unexpected program flow outweighs the
>positive effect of the simpler error reporting depends on your application,
>your style, and probably partially just on personal taste.
I think that entangling essential application code in strings of error
handling if/then or switch statements is more than a question of
personal taste, I think it is a question of good programming practice.
>At the level of "depends on your application": applications where a
>programming error is simply not acceptable, regardless of price, use
>somewhat elaborate methods of program proof. Most of the generally known
>methods require single entrance/single exit. (As has been pointed out
>to me, there have been papers concerning program proofs in other contexts,
>but the work is little known, and the techniques are not generally used.)
>This means that *anything* that does not have single entrance/single exit
>is too expensive, by definition, for the application.
C++ exception handling *is* single exit. The stack is unwound as if all
the functions between the detection of the error and it's handler had
wrapped the rest of theircode in an "if (no_error)" statement. This is
in general how you will pass back an error code that you are not going
to to handle in a given function anyway !
>
>Note that in general, anything that results in program flow that is not
>immediately apparent is also out. Also, rigorous program proof is very
>expensive, with the cost rizing exponentially with the size of the program,
>so such programs are very small.
Reduce the amount of written code further then, by using the exception
handling features of C++ to eliminate the (potentially error prone) hand
production of error reporting code :-)
...snip...
>I don't think the argument is really whether a subset is useful or not.
>It is whether that subset should be standardized, or perhaps more correctly,
>to what degree that subset should be standardized. On this, reasonable
>people may differ, and there is no absolute answer. I find that just
>"standardizing" for myself is not sufficient, but I don't think that
>EC++ should become anything like an ISO standard, either. The current
>status of EC++ is, however, within the range I would consider acceptable.
>That's all.
The point that I make is that there is no need for EC++ at all. Also it
has features missing from it that I am trying to show are vital for
embedded programmers. In particular exception are IMO important for
people designing safety-critical systems.
regards,
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/19 Raw View
Mike Davies wrote:
>
>
> I would be astonished if anybody in the low end embedded world compiled
> a 20 line program in C++ and found it gave a 200k binary :-)
> The way that happens is when compile against a (massive in your case)
> library.
Have you tried "Hello, world" with the full library? Two first attempts
at implementating the library that I'm familiar with produced
executables of over 1 Meg for hello world. With some work that can be
gotten down to 200k. With some rather heroic (and fragile) efforts it
can be reduced to about 60k.
> I intend to help that prediction come about by arguing against EC++
> wherever I can :-)
Fine, but base your arguments on facts, not on guesses.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/19 Raw View
Mike Davies wrote:
>
> C. I speak from personal experience of Watcom C/C++ V10.6 on QNX
Does Watcom support locale objects?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "David J. Littleboy" <davidjl@gol.com>
Date: 1998/06/19 Raw View
Mike Davies wrote in message ...
>In article <JQih1.285$0T2.4990046@mothra.gol.ad.jp>, "David J.
>Littleboy" <davidjl@gol.com> writes
>>The only issue is that for
>>some people, the added value of the features being cut is outweighed by
the
>>costs of implementing and support. Templates and STL are wonderful. But
the
>>20-line program I wrote last night compiled into a 200K binary, compiler
>>options set for minimize code size.
>I would be astonished if anybody in the low end embedded world compiled
>a 20 line program in C++ and found it gave a 200k binary :-)
>The way that happens is when compile against a (massive in your case)
>library.
Yup. Six STL headers. My point is that STL is not a viable programming style
in the memory constrained subset of the embedded area.
>You do not yourself make the fallacious inference that this is
>*overhead*, as opposed to *cost* but somebody else might if I don't
>point it out, so : that 200k has bought you something, if you write a
>20k line program against the same library the cost looks better, I bet.
Yup. Like I said. STL is wonderful. My 6 headers got me strings, sort, cin
and cout, vectors, set, and file streams. I paid 200k. Worth every byte of
it and easily afforded since I'm running on a 160 MB machine.
By the way, the added costs would be very reasonable if I wrote another 20k
lines _using only the types I've already used_. But what happens when I say
set<ObjType1>, and then set<OBjType2>, and then ...? Each time I get a new
increment of code for the new type.
>The STL of course is implemented wholly in header files (at least the
>version I looked at was, that may have changed). There is not much cost
>there (& no overhead at all).
Unless you use it. And there are very nasty costs if you have to support it.
>> EC++ would
>>allow programmers in that world to start using a subset of C++ in the very
>>near future.
>
>They can do that now by using C++. The difference is that they get to
>choose the subset instead of having it foisted upon them by a compiler
>vendor who is having difficulty doing for profit something that the egcs
>group is doing very well for free.
No, they can't. First someone's got to implement it for them.
This is a point I wish you'd listen to more carefully. There are a large
number of microcontroller manufacturers who do not have the manpower and
financial resources to implement and support full C++. These are groups that
are struggling just to support C. And these are the groups that are asking
for a minimal C++ subset. My best guess is that there are more groups in
this position (i.e. more proprietary architecture microcontrollers) than
there are C++ implementations in the world. These groups just don't have the
deep pockets of Sun, MS, Intel.
In other words, EC++ is not being foisted on anyone by compiler vendors.
The compiler vendors who are offering EC++ products are ones who primarily
provide a C++ product. Furthermore, any microcontroller group that can
afford to support full C++ is going to have a large advantage, as soon as
compiler technology appears, anyway, and can be expected to do so.
It very much looks to me that at least some of the objection to EC++ is by
people who don't want to admit that C++ has turned into a language that is
large and complex enough to be seriously expensive to implement. And the
truth (of the current state of compiler technology) is that the "advanced"
features involve overheads and costs that aren't acceptable in (some
sections of) the embedded area.
Insisting on full C++ forces a large number of microcontroller vendors to
support a large number of language features that (at the current state of
C++ compiler technology) either result in larger code or involve programming
styles that aren't appropriate. Given this reality, switching to full C++
isn't going to happen.
>>I'm not asking you to use EC++. I'm asking you to allow people who don't
>>have 200k extra lying around not to have to implement templates and
support
>>STL.
>
>There is no overhead in the STL, nor in templates. You know very well
>that the STL was not responsible for your 200k program bloat.
>Your statement, as written, looks almost as if it was intended to
>mislead. I assume that it was not, so please explain what you mean.
If I were writing for a system with 64k of ROM, I would not have been able
to use STL, and would have had to implement my program differently. Reading
in an ASCII text file and sorting the words could be implemented in a few k.
It would be harder and take a lot more than 20 lines. The point is that
since STL implies a programming style inappropropriate for memory limited
situations, the cost of implementing and supporting STL are far in excess of
the value it would provide _in the particular context of concern_.
>> Later, everyone who can switch, will
>>switch since there are such obvious advantages to C++.
>
>Why *switch* at all ? Is an *extra* language change in the interests of
>embedded programmers ?
It is if it means lowering the cost of creating an implementation in the
first place. EC++ is a _major_ improvement over C, and for a lot of embedded
programmers, opposition to EC++ means denying them _any_ form of C++
whatsoever.
David J. Littleboy <davidjl@gol.nonspam.com>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Wil Evers" <WEvers@nospamPCL-Software.nl>
Date: 1998/06/19 Raw View
Pete Becker <petebecker@acm.org> wrote in article
<3589ABD2.422782FC@acm.org>...
> Have you tried "Hello, world" with the full library? Two first attempts
> at implementating the library that I'm familiar with produced
> executables of over 1 Meg for hello world. With some work that can be
> gotten down to 200k. With some rather heroic (and fragile) efforts it
> can be reduced to about 60k.
This makes we wonder what exactly triggers all this bloat. Is it just the
locale stuff, or is it primarily caused by compilers instatantiating whole
template classes instead of just the members functions that are actually
used?
- Wil
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/19 Raw View
Hankel O'Fung wrote:
>
>
> 1) Compilers. Is there any compiler tailor-made to EC++ going to be
> shipped? If yes, why does such a compiler perform better than any C++
> compiler in optimization of code size/speed?
Yes, there are compilers shipping today that support the EC++ subset.
The somewhat sketchy benchmarks that are available today indicate that
using the EC++ language subset with an EC++ library produces significant
(over 50%) size reductions.
>
> 3) Coverage. Is the EC++ committee pushing a worldwide standard? If
> what she needs is only a standard for the Japanese microcontrollers, I
> see no reason why the use of EC++ would be harmful to the C++
> community. Somehow I have the impression (not necessarily true, of
> course) that the Japaneses are seeking help (instead of trying to
> conquer the C++ community by the "stripped down" / "crippled" version
> of C++) but find that people are blaming them for the problems they
> have.
Well said.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/19 Raw View
Jason Merrill wrote:
>
> >>>>> Pete Becker <petebecker@acm.org> writes:
>
> > Bjarne Stroustrup wrote:
>
> >> > Note that all the supporters of EC++ state that they aim to
support the
> >> > full international standard eventually.
>
> > Yes: "aim", not "expect". It has not been convincingly demonstrated that
> > the overheads that EC++ eliminates can be eliminated by improved
> > compilers.
>
> No, but they can be eliminated with existing options to existing
> compilers. What overhead does g++ -fno-rtti -fno-exceptions have that an
> EC++ compiler would necessarily not?
>
> In fact, Cygnus ships an EC++ product which consists of g++ with an option
> that disables namespaces, MI, mutable, templates, RTTI, and exceptions. I
> don't see the point; the above command would produce exactly the same code.
> The EC++ option just adds diagnostics.
No, EC++ also adds a library built with code size in mind. That's why
Cygnus has been unable to match the significant size reductions that,
for example, the Green Hills compiler gives with EC++. With a suitable
library, g++ does much better.
>
> My understanding is that the Green Hills EC++ product is the same sort of
> thing, with the EDG frontend. Certainly EDG also has --no_exceptions and
> --no_rtti options.
Green Hills ships the EDG front end plus an EC++ library. You can't take
leave out one part of a design and expect it to work as specified.
>
> So just considering the language itself, what does EC++ buy users that a
> couple of well-placed compiler options won't?
Users don't use "the language itself", they use the language plus
libraries.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Matt Seitz" <mseitz@meridian-data.com>
Date: 1998/06/18 Raw View
Pete Becker wrote in message ...
>Bjarne Stroustrup wrote
[...]
>The language experts who created C++, if they are honest, may even be a bit
>apologetic about the extreme difficulty in compiling C++ to produce
>efficient, small code.
[...]
>It has not been convincingly demonstrated that
>the overheads that EC++ eliminates can be eliminated by improved
>compilers.
I've read lots of claims from both sides about whether Standard C++ produces
larger code than EC++. I would like to see some data to either support or
refute these claims. How big is the code generated by a Standard C++
compiler vs. an EC++ compiler?
>This objection can, of course, be eliminated by adding multiple
>inheritance and templates.
It sounds like there is some general agreement that multiple inheritance and
templates could be put back into EC++ without increasing code size or
decreasing efficiency. Perhaps if they did so, there would be less
objection to EC++.
>This, of course, is irrelevant if your objection truly encompasses all
>subsets. Since you state it here, I assume that what you are really
>saying is that you are supportive of a coherent, logically designed
>subset.
Of course, if one believes that any subset is bad, the defects of a
particular subset are in some ways moot. But just because one points out
the defects of a subset does not mean one would support a different subset.
>> > In "The History of C++" article for ACM HOPL2 and in "The Design of
>> > Evolution of C++," I deemed the failure of shipping a good standard
library
>> > with C++ release 1.0 or even release 2.0 my greatest mistake. I still
>> > think that it was. EC++ repeats this mistake and thus condemns EC++
>> > programmers to reinvent the wheel or suffer the problems of multiple
>> > incompatible (and often commercial) foundation libraries that the C++
>> > population at large is still trying to recover from.
>
>Which argues strongly for adopting a formal subset.
Portability is a strong argument for a standard. In this case, it is an
argument that can cut either for or against EC++.
For: EC++ will make code portable among various embedded environments.
Against: EC++ will make code unportable between EC++ environments and
Standard C++ environments
The key question seems to be "Is portability among EC++ compilers worth
breaking portability between embedded and non-embedded environments?"
>The subset itself is
>already there: several compiler vendors ship products that support EC++.
>The Standard can help solve this problem, or it can continue to be part
>of the problem.
This presupposes the Standard is the problem. I have yet to be convinced of
that.
>Perhaps I was mistaken in assuring the EC++ Technical Committee and the
>Japanese national body last February that their needs would get a fair
>hearing in the ISO/ANSI standards committee.
In what way has the ISO comittee treated the EC++ Technical Committee
unfairly?
>A significant problem with a formally defined "standard" is that it
>develops its own culture and will eventually develop in a direction
>different from the needs of its users. The members of this culture will
>inevitably develop a rationale for their standard being superior to all
>alternatives. This leads to efforts diverted from the needs of users and to
>distracting debates.
There is always a danger that the people who make standards will become
isolated from users, and will produce standards that do not help users. My
impression is that Dr. Stroustrup and the ISO comittee have been very
sensitive to this. Time and again, they discuss the need for standards to
be based on real world experience. I think they are open to suggestions, if
those suggestions can be backed by both theoretical arguments and real world
data.
> I'm getting a very uncomfortable feeling from this thread that there's
>a growing attitude that EC++ is being supported by a group of lazy,
>technically inept outsiders.
It would be very easy for this argument to degrade into "EC++ supporters are
lazy and incompetent" versus "EC++ opponents are ignorant and elitist."
Let's try to avoid impugning characters on both sides.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/18 Raw View
Matt Seitz<mseitz@meridian-data.com> wrote:
>I've read lots of claims from both sides about whether Standard C++ produces
>larger code than EC++. I would like to see some data to either support or
>refute these claims. How big is the code generated by a Standard C++
>compiler vs. an EC++ compiler?
Unfortunately, numbers are likely generate more confusion than
enlightenment at this point. There are many different compilers
of both stripes, and an infinitude of programs that might be
compiled with them. It's easy to cook the numbers to support
any position. What matters is (1) how big *your* program is
when built with the compilers available for *your* target machines,
and (2) what can be done if it's too big.
Everybody agrees that many current compilers produce code that
may be "too big". Some people say fully-conforming compilers
are obliged by the standard to produce code that is too big, and
others disagree. Numbers about current compilers for C++ and
its variants would reveal little about this issue.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/18 Raw View
Matt Seitz wrote:
>
> >It has not been convincingly demonstrated that
> >the overheads that EC++ eliminates can be eliminated by improved
> >compilers.
>
> I've read lots of claims from both sides about whether Standard C++ produces
> larger code than EC++. I would like to see some data to either support or
> refute these claims. How big is the code generated by a Standard C++
> compiler vs. an EC++ compiler?
I have not seen anyone object to EC++ on the basis that it does not
deliver the size savings that it promises. Can you cite messages from
that size about whether Standard C++ produces larger code?
There was a study done by Japan Novel Corporation (not related to the
networking company) that showd that for the handful of applications that
they downloaded from the net the size savings ranged from 50% to 90%.
(yes, savings: one application compiled with EC++ was 10% of the size of
the same application compiled with full C++) That was using the Green
Hills compiler, which uses the EDG front end and the Dinkumware
libraries.
>
> >This objection can, of course, be eliminated by adding multiple
> >inheritance and templates.
>
> It sounds like there is some general agreement that multiple inheritance and
> templates could be put back into EC++ without increasing code size or
> decreasing efficiency. Perhaps if they did so, there would be less
> objection to EC++.
The EC++ standard was written three years ago. The C++ committee has
been asked to consider it as a basis for a solution. It would be silly
to rewrite it independently while the C++ committee is considering it.
It has never been presented on a take it or leave it basis. Don't be
misled by this red herring.
>
> The key question seems to be "Is portability among EC++ compilers worth
> breaking portability between embedded and non-embedded environments?"
You cannot realistically expect to use C++ for systems with tight memory
contraints. That doesn't sound portable to me.
>
> >Perhaps I was mistaken in assuring the EC++ Technical Committee and the
> >Japanese national body last February that their needs would get a fair
> >hearing in the ISO/ANSI standards committee.
>
> In what way has the ISO comittee treated the EC++ Technical Committee
> unfairly?
Just read the messages from various members of the committee attacking
EC++ before the formal discussion has actually begun.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/18 Raw View
In article <358906A5.E36AEE1A@acm.org>, Pete Becker <petebecker@acm.org>
writes
...snip...
>> The key question seems to be "Is portability among EC++ compilers worth
>> breaking portability between embedded and non-embedded environments?"
My vote is no.
>
>You cannot realistically expect to use C++ for systems with tight memory
>contraints. That doesn't sound portable to me.
This is not true. It is possible to use C++ in such a way that you get
*no* noticable code or data size increase over the same code written in
C. I speak from personal experience of Watcom C/C++ V10.6 on QNX
...snip...
--
Mike Davies
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Jim Barry" <jim.barry@bigfoot.com>
Date: 1998/06/15 Raw View
Oleg Zabluda wrote in message <6lu9fb$hn3@marianna.psu.edu>...
>
>What James Kanze probably meant is that it is difficult to ensure
>that all relevant cleanup was being made, not that it is difficult
>to ensure that an exception does not escape from main().
I appreciate that there are well-developed techniques for 'proving'
the correctness of traditional code, but I think the job would be
rather more easily done using exceptions and object-managed resource
aquisition.
>As an example, consider a program which runs indefinitely. It
>should clarify the point for you.
I would have thought that proper use of exception handling would make
achieving this goal considerably more likely.
- Jim
--
Jim Barry, Thermoteknix Systems Ltd., Cambridge, UK.
http://www.thermoteknix.co.uk Queen's Award for Export 1998
Antispam address courtesy of http://www.bigfoot.com
Or e-mail direct: jim at thermoteknix dot co dot uk
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/15 Raw View
In article <6lu9fb$hn3@marianna.psu.edu>, Oleg Zabluda
<zabluda@math.psu.edu> writes
>Mike Davies <mike_davies@noco.demon.co.uk> wrote:
>: In article <6lj95e$bt6$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
>: writes
>
>[...]
>
>: >In this case, you are simply wrong. In hi-rel code, exceptions are
>: >generally banned, because proving exception safety is too difficult.
>
>: No, I don't agree. It is completely trivial to make C++ code exception
>: safe : compile all modules with exceptions enabled and use the exception
>: enabled version of the library. Then wrap the contents of main() in a
>: try...catch block.
>
>What James Kanze probably meant is that it is difficult to ensure
>that all relevant cleanup was being made, not that it is difficult
>to ensure that an exception does not escape from main().
That ain't what he said.
>
>As an example, consider a program which runs indefinitely. It
>should clarify the point for you.
No, it is *still* better to use exceptions than to pass the return value
back up the calling chain, whether the program runs forever or not.
Let me explain where I am coming from :
This is a thread relating to the purported advantages of EC++ over C++.
Mr Kanze provided a specious (IMO) argument that implied that exceptions
were not acceptable in safety critical applications.
My reasons for thinking that his argument is specious are twofold :
1.
Exceptions are *easier* to recover from than the case where a called
program returns an error. Easier ? Yes - the code is easier to write
(hence more likely to get written / be maintained) than passing *every*
possible eror status back up through the calling chain to where it can
be handled which is the alternative to using exceptions.
Also, as I pointed out, it is possible to write code using exceptions
where it is impossible to have a *silently* ignored return of an error
from a function.
People writing safety critical code should *love* this feature of C++ as
it makes a whole class of errors manifest at debug time.
2.
If there is a feature of C++ that is *genuinely* unacceptable for a
given application (and for a good compiler there should be no *overhead*
- as opposed to *cost* - for any feature of C++) then the best solution
is not to use it (ie switch it out with a pragma) not to cripple the
language for every embedded application programmer.
The subset of C++ needed by embedded programmers is the whole language
IMO, but not every project / source file will need every feature.
>
>Oleg.
Regards,
--
Mike Davies
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/15 Raw View
In article <6lag1.36$0T2.2558654@mothra.gol.ad.jp>, "David J. Littleboy"
<davidjl@gol.com> writes
>>
>>Having no experience in embedded system programming whatsoever, I had
>always
>>imagined embedded systems programmers to be highly skilled individuals. I
>>was quite surprised to read in the EC++ document that they are actually
>>quite stupid; the basic argument is that Standard C++ is too difficult for
>>embedded systems programmers. The document states "the ultimate goal of
>>Embedded C++ is to provide embedded systems programmers with a subset of
>C++
>>that is easy for the average C programmer to understand and use"
>
>The reason for this is that the EC++ standard is written from the standpoint
>of a manager of a hardware development group that either has an in-group
>C-based development environment team or else subcontracts out the
>development of their development environment.
Said manager had better read my comments below. Namespaces and templates
in particular.
>Said manager's company may
>have lots of C++ expertise, but it's not in his group (nor at the
>subcontractor). There happens to be a dearth of unemployed C++ gurus just
>now, so if he wants to provide some sort of object-oriented support (and he
>does), he's got to do it with the manpower he's got. That leaves him
>terrified at the prospect of implementing and supporting C++.
>
>(Remember, the Annotated C Standard is a mere 200 pages, whereas Bjarne's
>book is 900, and it took Bjarne _five_ printings to get most of the
>(incredibly numerous) errors out. C++ looks to said manager to be a large,
>difficult language. (And who knows which errors got fixed in the Japanese
>translation, if there is one.)
>
>His clientelle (for his hardware) is not the space shuttle. It's cell
>phones, vending machines, test and measurement equipment, audio equipment,
>electric guitar effects boxes. All applications in which object oriented
>support would be more than helpful. But full 1999 vintage C++ looks to our
>manager friend like overkill.
Has he asked his programmers ? Do they have any OO design skills ?
Because if so they will reply that they will need all of C++ at some
point in time.
>
>The result is that he's interested in the 1985 or so version of C++.
>
>[snip]
>
>> the main theme is to keep things simple for the
>>programmer. The document doesn't say that namespaces are too difficult for
>>programmers; only that "the size of [embedded] application programs cannot
>>be very large...under such conditions, names seldom, if ever, come into
>>conflict" and so namespaces aren't needed.
>
>Maybe because he's more concerned with (not<g>) implementing and supporting
>namespaces. (The document does, by the way, argue that they are not
>necessary in the scale of embedded systems that EC++ targets.)
I hope somebody has explained to him the alternative to namespaces ?
He has been made aware, has he , that if he ever buys an object code
library which has name clashes with his own existing code then one or
the other will need re-writing ? And he's *certain* that this is not
*ever* going to be an issue ? And if its just a few name clashes he
knows up front (before he knows what the library is) that he can afford
the inefficiency of function wrappers for those functions in the library
that have name clashes ? Hmm ? He's a brave man to turn down the
namespaces I think, especially since his programmers dont need to use
them (to any meaningful extent) if they dont want to.
And if its a source code library what's he going to do if *it* uses
namespaces ?
There are ually good arguments for
templates - efficiency
multiple inheritance - abstract interfaces
exceptions - reliability (see elsewhere in this thread)
, etc, etc as well of course.
Especially if you *do* want to use a source library that relys upon any
of these features.
I hope that I am not going to see the response that libraries used by
embedded programmers will be written in EC++. Embedded programming is
enough of a ghetto as it is, look at the number of people switching to
the x86 family so as to make use of mass-market tools.
I am an embedded programmer, and it was a joy to first come across
container classes. Tempered immediately by the fact that I had to write
compiler dependant code to use them. Now you are promoting a language
subset that doesn't allow the use of the standard implementation of the
STL :-(
>
>>One suspects that whatever comittee came up with this document was lacking
>>in representation from embedded systems programmers; I doubt if they would
>>have been quite this condescending to themselves. They are actually
>>probably quite good.
>
>It certainly was lacking in representation from the sort of embedded systems
>programmers you'll find on this list<g>.
I have just written some code for a PIC micro in assembler, 36 bytes of
data space in total and I *still* missed C++ style templates and inline
virtual functions.
We have heard at various points on this thread that "the people who need
EC++" are :
too stupid to learn C++,
too resource constrained to use the features of C++ that make it more
efficient than C,
unable to use the safety features of exceptions to write safety critical
code,
certain that their manager will never prefer to buy a library rather
than pay them to write it,
too thoughtless to write abstract interfaces to their hardware or too
lazy to maintain internal documented code interfaces.
not needing templated container classes like linked lists etc etc
I think you've been very *selective* in your choice of embedded
programmers, but I don't think you have made a *good* selection.
> However, I'd bet that the EC++
>standard goes over a lot better with programmers at companies that are
>currently purchasing said manager's microcontrollers, since they might have
>a bit more sympathy for said managers difficulties and they might prefer to
>see a limited feature set implemented well.
>
No, not really, it isn't the managers who write the code is it ?
We embedded programmers will need *all* of C++ sooner rather than later,
most particularly templates and exceptions on efficiency and reliability
grounds
What we want is for compiler vendors to write full featured C++
compilers that have pragmas to switch out the bits that show an
*overhead* until the compilers have been enhanced to the point that
they're not needed. It can't be that hard can it ? Why don't you just
retarget EGCS, it would be better than EC++.
It may be the case that if you talk to programmers who have not got very
much OO design experience they do not see the need for some features of
C++.
If you explained to them the the efficiency advantages of C++ I bet
you'd get a different response - I give some examples :
virtual functions implemented via a jump table vs switch cases,
templates that can save pointer indirection or function call overhreads,
exception handling that handles *every* error returned by *every*
function at exactly the place where it is convenient for about a 5% code
space cost,
namespaces that allow you to use bought in librarys without getting a
name clash (one single use of this feature could pay for a complete team
to be trained in C++ !)
etc, etc
>David J. Littleboy <davidjl@gol.nonspam.com>
>
Cordially,
--
Mike Davies
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/06/17 Raw View
In article <897930812.7022.0.nnrp-11.9e98e8f6@news.demon.co.uk>,
"Jim Barry" <jim.barry@bigfoot.com> wrote:
>
> Oleg Zabluda wrote in message <6lu9fb$hn3@marianna.psu.edu>...
> >
> >What James Kanze probably meant is that it is difficult to ensure
> >that all relevant cleanup was being made, not that it is difficult
> >to ensure that an exception does not escape from main().
>
> I appreciate that there are well-developed techniques for 'proving'
> the correctness of traditional code, but I think the job would be
> rather more easily done using exceptions and object-managed resource
> aquisition.
Curiously enough (in light of my recent statement), I suspect that you
are right. The problem is that while I suspect that techniques exist
to prove programs in the light of exceptions, and that these techniques
are likely simpler than those currently used, I've yet to see an article
which presents them to a wide professional community for review and
criticism.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/06/17 Raw View
In article <6m3v2k$okf@engnews1.Eng.Sun.COM>,
Mike Davies <mike_davies@noco.demon.co.uk> wrote:
>
> In article <6lu9fb$hn3@marianna.psu.edu>, Oleg Zabluda
> <zabluda@math.psu.edu> writes
> >Mike Davies <mike_davies@noco.demon.co.uk> wrote:
> >: In article <6lj95e$bt6$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
> >: writes
> >
> >[...]
> >
> >: >In this case, you are simply wrong. In hi-rel code, exceptions are
> >: >generally banned, because proving exception safety is too difficult.
> >
> >: No, I don't agree. It is completely trivial to make C++ code exception
> >: safe : compile all modules with exceptions enabled and use the exception
> >: enabled version of the library. Then wrap the contents of main() in a
> >: try...catch block.
> >
> >What James Kanze probably meant is that it is difficult to ensure
> >that all relevant cleanup was being made, not that it is difficult
> >to ensure that an exception does not escape from main().
>
> That ain't what he said.
That's exactly what I said. What do you think "exception safety"
means? Try reading any of the series of articles that appeared in
C++ Reports some time back, or look up the expression on DejaNews.
> >
> >As an example, consider a program which runs indefinitely. It
> >should clarify the point for you.
>
> No, it is *still* better to use exceptions than to pass the return value
> back up the calling chain, whether the program runs forever or not.
>
> Let me explain where I am coming from :
>
> This is a thread relating to the purported advantages of EC++ over C++.
> Mr Kanze provided a specious (IMO) argument that implied that exceptions
> were not acceptable in safety critical applications.
> My reasons for thinking that his argument is specious are twofold :
>
> 1.
> Exceptions are *easier* to recover from than the case where a called
> program returns an error. Easier ? Yes - the code is easier to write
> (hence more likely to get written / be maintained) than passing *every*
> possible eror status back up through the calling chain to where it can
> be handled which is the alternative to using exceptions.
Neither is simple. Handling errors is difficult, period. Exceptions
make reporting errors simpler -- they do not have any effect on detecting
them nor on handling them.
Exceptions also introduce unexpected program flow in your program. What
the effect of this is depends on many things, but it is never positive.
Whether the negative effect fo the unexpected program flow outweighs the
positive effect of the simpler error reporting depends on your application,
your style, and probably partially just on personal taste.
At the level of "depends on your application": applications where a
programming error is simply not acceptable, regardless of price, use
somewhat elaborate methods of program proof. Most of the generally known
methods require single entrance/single exit. (As has been pointed out
to me, there have been papers concerning program proofs in other contexts,
but the work is little known, and the techniques are not generally used.)
This means that *anything* that does not have single entrance/single exit
is too expensive, by definition, for the application.
Note that in general, anything that results in program flow that is not
immediately apparent is also out. Also, rigorous program proof is very
expensive, with the cost rizing exponentially with the size of the program,
so such programs are very small. (This is just to put what I am saying
in context. I do not want to start a general pro/contra discussion of
exceptions with this.)
> Also, as I pointed out, it is possible to write code using exceptions
> where it is impossible to have a *silently* ignored return of an error
> from a function.
> People writing safety critical code should *love* this feature of C++ as
> it makes a whole class of errors manifest at debug time.
People writing safety critical code don't have a "debug" time. The
code works straight out of the compiler. People writing safety critical
code use extensive code reviews, etc. to ensure this. Testing is a
necessary step to validate the previous procedure, not to debug.
And of course, even in non safety critical code, the "return value" is
generally a class type, whose destructor asserts that the value has been
read. Or at least it is in any large scale application where reasonable
quality is important.
> 2.
> If there is a feature of C++ that is *genuinely* unacceptable for a
> given application (and for a good compiler there should be no *overhead*
> - as opposed to *cost* - for any feature of C++) then the best solution
> is not to use it (ie switch it out with a pragma) not to cripple the
> language for every embedded application programmer.
I don't what to restart an argument which has apparently calmed down. I
suspect that the real reason why exceptions are not in EC++ is their
space overhead, and not the safety issue. I just mentioned in as a
side issue.
> The subset of C++ needed by embedded programmers is the whole language
> IMO, but not every project / source file will need every feature.
For what definition of needed. The subset of C++ that is absolutely
needed is very small -- probably smaller than C (since even C is Turning
complete). The question is not whether a given feature is needed (it
isn't), but whether it pays for itself -- i.e.: whether its cost is higher
than its advantages. On a machine like a Sparc, with enough other people
using the compiler to amortise the development costs, it is probable that
most features have an effective cost to me of 0; even a small benefit
makes the feature a win. On an embedded system, on which no, or maybe
only one or two users can use a feature, the development cost of the
feature must be born by someone; the feature then becomes very expensive.
I don't think the argument is really whether a subset is useful or not.
It is whether that subset should be standardized, or perhaps more correctly,
to what degree that subset should be standardized. On this, reasonable
people may differ, and there is no absolute answer. I find that just
"standardizing" for myself is not sufficient, but I don't think that
EC++ should become anything like an ISO standard, either. The current
status of EC++ is, however, within the range I would consider acceptable.
That's all.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/17 Raw View
David J. Littleboy wrote:
>
> Any feature left out makes EC++ a worse language than C++. There is no
> question that EC++ is a worse language than C++.
Replace "worse" with "less powerful" and I agree.
> The only issue is that for
> some people, the added value of the features being cut is outweighed by the
> costs of implementing and support.
More generally: if C++ produces an executable that's too big for your
target platform and EC++ produces one that fits, EC++ is far better than
C++ for your purposes.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/17 Raw View
Pete Becker <petebecker@acm.org> wrote:
>
>More generally: if C++ produces an executable that's too big for your
>target platform and EC++ produces one that fits, EC++ is far better than
>C++ for your purposes.
C++ and EC++ don't produce executables. Only compilers produce
executables. A compiler that produces executables that "fit" is
better than one that doesn't, for that application. C++ and EC++
compilers could be in either role.
For an apropos example, if your program uses libraries that contain
many virtual functions, then a real C++ compiler that strips unused
functions may well be the one that "fits", where an EC++ compiler
might not.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Jim Barry" <jim.barry@bigfoot.com>
Date: 1998/06/17 Raw View
jkanze@otelo.ibmmail.com wrote in message
<6m6i4q$7k1$1@nnrp1.dejanews.com>...
>Neither is simple. Handling errors is difficult, period. Exceptions
>make reporting errors simpler -- they do not have any effect on
detecting
>them nor on handling them.
That's not my understanding of exceptions at all. Exception handling
is not simply for reporting errors.
>Exceptions also introduce unexpected program flow in your program.
No they don't. If an exception is thrown I expect program flow to move
to the appropriate catch block and for the stack to be unwound. The
issue of unhandled exceptions is addressed by exception-specifications
and, in the context of embedded systems, I would expect the compiler
to aggressively check such specifications.
>At the level of "depends on your application": applications where a
>programming error is simply not acceptable, regardless of price, use
>somewhat elaborate methods of program proof.
I am somewhat sceptical about formal methods of 'proof'. I don't see
how it can ever be possible to prove 100% that code does exactly what
the programmer intended. C++ provides a wealth of language features
precisely so that programmers can write code that is more expressive
of the problem domain, which also implies code that stands a better
chance of doing what it is intended to.
>This means that *anything* that does not have single entrance/single
exit
>is too expensive, by definition, for the application.
I think that single-exit is just the kind of old-fashioned paradigm
that C++ is trying to get away from.
>I don't think the argument is really whether a subset is useful or
not.
>It is whether that subset should be standardized, or perhaps more
correctly,
>to what degree that subset should be standardized. On this,
reasonable
>people may differ, and there is no absolute answer.
I am entirely in agreement with Bjarne Stroustrup's postings on this
thread, so I am against formally defined subsets. Even if I did not
consider EC++ to be flawed, I would still think it unnecessary,
divisive (just look at the heated arguments on this thread), and
ultimately harmful to C++.
- Jim
--
Jim Barry, Thermoteknix Systems Ltd., Cambridge, UK.
http://www.thermoteknix.co.uk Queen's Award for Export 1998
Antispam address courtesy of http://www.bigfoot.com
Or e-mail direct: jim at thermoteknix dot co dot uk
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/06/17 Raw View
In article <fFJmlGAcLXh1Ew3r@noco.demon.co.uk>,
Mike Davies <mike_davies@noco.demon.co.uk> wrote:
[...]
> Has he asked his programmers ? Do they have any OO design skills ?
> Because if so they will reply that they will need all of C++ at some
> point in time.
I rather take ombrage at this. It has nothing to do with EC++, but
I feel sure that in the applications I'm currently working on, there
are large parts of C++ which I'll never need. And I don't consider
my OO design skills to be 0. How on earth did we manage to write
programs before? For that matter, how do I manage now, since most
of the compilers I use don't support the full language yet?
Of course, I'm sure that the poster didn't really mean "need" -- strictly
speaking, all anyone needs is a language which is Turing complete.
The choice beyond that is always motivated by the trade-offs: how much
does this feature cost (and they all cost something, if only in added
language complexity) vs. how much does it save.
The trade-off's I'm seeing on the projects I'm currently working on (which
are NOT the type of systems targetted by EC++) is that we really don't need
anything that wasn't in CFront 3.0, except maybe exceptions. On my previous
project (which had higher reliability constraints), we didn't even need
exceptions, but we DID need some form of separate compilation of templates --
what has been standardized with export. Namespaces would be nice. But
the new template features, or STL, are simply excess baggage -- something
that we have to pay for, but won't use.
Obviously, I'm not suggesting that any of these features be removed from
the standard -- I know people who really do need them. And I have already
"paid" for them, whether I like it or not, in a three year (more or less)
delay of the standard -- a stable standard was something I really did
need over the last five years. So am I saying that the standards committee
made a mistake adding these things to the standard, rather than just
standardizing the existing? Not really -- the most I can say is that
certain decisions didn't correspond to MY trade-offs; they certainly
corresponded to the trade-offs of some others, and I suspect that there
are even people who think that the standard didn't go far enough in
innovating.
Back to EC++: apparently, there are some people who find that in its
current state, and the current state of technology, the complete standard
does not represent an acceptable trade-off for them. Whether you or I
agree will not change their feeling about this. (And having worked in
the field, I understand the feeling.) Given this, their alternatives
are to stick with C, or to define a subset of C++ that is a valid trade-off
for them.
> >The result is that he's interested in the 1985 or so version of C++.
> >
> >[snip]
> >
> >> the main theme is to keep things simple for the
> >>programmer. The document doesn't say that namespaces are too difficult for
> >>programmers; only that "the size of [embedded] application programs cannot
> >>be very large...under such conditions, names seldom, if ever, come into
> >>conflict" and so namespaces aren't needed.
> >
> >Maybe because he's more concerned with (not<g>) implementing and supporting
> >namespaces. (The document does, by the way, argue that they are not
> >necessary in the scale of embedded systems that EC++ targets.)
>
> I hope somebody has explained to him the alternative to namespaces ?
>
> He has been made aware, has he , that if he ever buys an object code
> library which has name clashes with his own existing code then one or
> the other will need re-writing ?
When you only have 16KB to work in, third party libraries are generally
not a problem. In fact, although I currently work in a 4GB address
space, with a large number of third party libraries, I manage to get
by without namespaces very well. Namespaces may be an elegant solution,
but I've yet to see the problem.
> And he's *certain* that this is not
> *ever* going to be an issue ? And if its just a few name clashes he
> knows up front (before he knows what the library is) that he can afford
> the inefficiency of function wrappers for those functions in the library
> that have name clashes ? Hmm ? He's a brave man to turn down the
> namespaces I think, especially since his programmers dont need to use
> them (to any meaningful extent) if they dont want to.
>
> And if its a source code library what's he going to do if *it* uses
> namespaces ?
>
> There are ually good arguments for
>
> templates - efficiency
I presume you mean programmer efficiency, which is, of course, where
templates really shine. (I can write programs that run faster using
generic.h than I can with templates. I certainly cannot write them
anywhere near as fast, however.)
I'm not sure what the current position of the EC++ group is with regards
to templates. When I last read their rationale, some time ago, the
rationale given for templates was that they were not yet stable in the
standard -- I'm not sure that this rationale wouldn't partially hold
today; while the standard text is frozen, there isn't a single compiler
I know of which implements it, or even comes close.
I do think that some sort of "automatic code generating facility" is
necessary. The C/C++ preprocessor is one, but is too weak. Programs
like lex and yacc are another, but far to specialized. Templates are
somewhere in the middle; whether they are at the right place, again,
depends on your trade-offs. As they are standard, however, I would
expect that once people learn how to implement them (particularly
with export), EC++ will adopt them, or at least a minimal subset.
> multiple inheritance - abstract interfaces
This is certainly what I'd miss most in EC++. Still, the smaller the
system, the less inheritance (multiple or otherwise) is important.
> exceptions - reliability (see elsewhere in this thread)
>
> , etc, etc as well of course.
>
> Especially if you *do* want to use a source library that relys upon any
> of these features.
>
> I hope that I am not going to see the response that libraries used by
> embedded programmers will be written in EC++. Embedded programming is
> enough of a ghetto as it is, look at the number of people switching to
> the x86 family so as to make use of mass-market tools.
>
> I am an embedded programmer, and it was a joy to first come across
> container classes. Tempered immediately by the fact that I had to write
> compiler dependant code to use them. Now you are promoting a language
> subset that doesn't allow the use of the standard implementation of the
> STL :-(
Well, I was using container classes long before I had STL, or even templates.
Managing the instantiation of generic.h classes was a pain in a large
system, although with a few clever shell scripts and some tricky makefile's,
it can be automated. It would hardly be a problem for systems which
fit in 16K, however.
> >>One suspects that whatever comittee came up with this document was lacking
> >>in representation from embedded systems programmers; I doubt if they would
> >>have been quite this condescending to themselves. They are actually
> >>probably quite good.
> >
> >It certainly was lacking in representation from the sort of embedded systems
> >programmers you'll find on this list<g>.
>
> I have just written some code for a PIC micro in assembler, 36 bytes of
> data space in total and I *still* missed C++ style templates and inline
> virtual functions.
>
> We have heard at various points on this thread that "the people who need
> EC++" are :
>
> too stupid to learn C++,
I don't think I would say "too stupid". Perhaps, however, with other
priorities -- C++ is a complex language, and it does take time (i.e.
resources) to learn it.
> too resource constrained to use the features of C++ that make it more
> efficient than C,
>
> unable to use the safety features of exceptions to write safety critical
> code,
I mentioned this is passing, but more as a counter argument because people
were claiming that you couldn't write robust code without certain features,
where in fact, you can't write really robust code with them. I do not
think that the motivation of EC++ was ever safety -- after all, many
embedded processors are not safety critical, and you could always use
a subset of EC++ for the ones that were.
> certain that their manager will never prefer to buy a library rather
> than pay them to write it,
>
> too thoughtless to write abstract interfaces to their hardware or too
> lazy to maintain internal documented code interfaces.
An abstract interface does not necessarily mean virtual functions. The
resolution of the polymorphism can occur at compile time (templates),
link time (separate libraries for a common set of headers -- how I generally
handle more portability issues, for example), or run-time (virtual functions).
Run-time is by far the most flexible solution, and should (IMHO) be
preferred whenever possible. But if the small size of an application
means that you will only ever have a single instance of an implementation
of a given abstract interface, then all three methods do the trick
equally well.
> not needing templated container classes like linked lists etc etc
>
> I think you've been very *selective* in your choice of embedded
> programmers, but I don't think you have made a *good* selection.
They have been selective, I believe -- they are not targetting the world.
Whether it is a good selection is, in a certain sense, not for you (or
I) to judge -- it is their trade-off, not ours.
> > However, I'd bet that the EC++
> >standard goes over a lot better with programmers at companies that are
> >currently purchasing said manager's microcontrollers, since they might have
> >a bit more sympathy for said managers difficulties and they might prefer to
> >see a limited feature set implemented well.
>
> No, not really, it isn't the managers who write the code is it ?
No, they pay for the programmers, they pay for the tools, and in the
end, they take the risks. Don't underrate the importance of managers,
nor the criteria they use for their decisions.
> We embedded programmers will need *all* of C++ sooner rather than later,
> most particularly templates and exceptions on efficiency and reliability
> grounds
> What we want is for compiler vendors to write full featured C++
> compilers that have pragmas to switch out the bits that show an
> *overhead* until the compilers have been enhanced to the point that
> they're not needed. It can't be that hard can it ? Why don't you just
> retarget EGCS, it would be better than EC++.
How much does Cygnus charge for a retargetting. To a machine that doesn't
have 32/64 bit ints, or maybe isn't byte addressable, or... Given the
current state of technology, you'd have to turn off exception handling,
and if memory is tight, you can't use the SGI implementation of the standard
library (which was designed intentionally with the premise that all space/
time trade-offs favor time). So you end up paying a lot of money to get
a compiler which isn't very stable, mainly because it supports a lot of
features you can't use. (I don't mean to criticize the people at Cygnus
here -- I think they do an excellent job. But the global targets and
goals of egcs are NOT appropriate for most of the embedded market.)
> It may be the case that if you talk to programmers who have not got very
> much OO design experience they do not see the need for some features of
> C++.
I'm not sure how to answer this one. My first reaction was that I consider
myself an experienced OO designer, and I don't see the need for many of
the features. But if I think about it, I do see the need for them. Just
not in most application domains. And not in embedded processors.
> If you explained to them the the efficiency advantages of C++ I bet
> you'd get a different response - I give some examples :
>
> virtual functions implemented via a jump table vs switch cases,
See above. On small systems, you generally don't need virtual functions.
(On life critical systems, you probably won't allow them.)
> templates that can save pointer indirection or function call overhreads,
??? I don't get this. Can save ... compared to what? Hand written
specialized code? Certainly not. Code generated by a macro preprocessor?
Even there, I suspect that I can do better with the macro preprocessor.
(The one exception is perhaps expression templates. And as far as I can
see, these really only have application in numerical analysis, when working
on large matrices and vectors.)
What templates save is programmer time. When they work.
> exception handling that handles *every* error returned by *every*
> function at exactly the place where it is convenient for about a 5% code
> space cost,
Which implementation? All of the exception implementations I've seen
have been very gourmand in code space (or introduced unacceptable run-time
overhead, plus additional requirements in stack space).
> namespaces that allow you to use bought in librarys without getting a
> name clash (one single use of this feature could pay for a complete team
> to be trained in C++ !)
It's curious, but I've been using bought in libraries for years, and I've
never had a name clash (except with a header in X, and the nameclash there
involved a macro, so namespaces wouldn't have solved the problem). As I
said above, namespaces are an elegant solution to an inexistant problem.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/17 Raw View
Bjarne Stroustrup wrote:
> >
> > However, this does not imply that a vendor or a group of vendors have to
> > go and define their own sub-language with its own name and support
> > organization.
> > They can do what others have done: grow to meet the standard as fast as
> > is reasonable for their needs (different companies have different needs
> > and approximate the standard in different ways). If they are honest, they
> > may even be a bit apologetic about the missing features.
The language experts who created C++, if they are honest, may even be a bit
apologetic about the extreme difficulty in compiling C++ to produce
efficient, small code.
> > Note that all the supporters of EC++ state that they aim to support the
> > full international standard eventually.
Yes: "aim", not "expect". It has not been convincingly demonstrated that
the overheads that EC++ eliminates can be eliminated by improved
compilers. The only guaranteed solutions today are adding more memory,
which increases the cost of a product, and reducing functionality. Can
these overheads be reduced by improved compiler technology? Maybe. When
will this happen? It's anybody's guess. C++ will probably still be in
wide use when this occurs, but there's no guarantee of that. What should
developers of memory-constrained devices do in the meantime?
> > As I have said in every posting on this topic: I don't mind subsets -
> > everybody use subsets to suit their needs - I mind formally defined
> > subsets (and ``almost subsets'').
> >
> > In another posting you used the wonderful term GCD-C++ as the obvious
> > language to write in. That's the obvious right idea from the perspective
> > of a user wanting to maximize portability. One way stating my objection
> > to EC++ as a formally defined and supported subset of C++ is that it is
> > a good chance to become an excuse for not doing better and an obstacle
> > to GCD-C++'s convergence to Standard C++. Note that by excluding multiple
> > inheritance EC++ fails to reach the 1989 state of the art and by excluding
> > templates and exceptions, it doesn't even come close to the ARM.
This objection can, of course, be eliminated by adding multiple
inheritance and templates. Exceptions impose unavoidable space overhead.
> > I see EC++ as an "almost subset" defined by historical accident rather
> > than logical determination of needs.
This, of course, is irrelevant if your objection truly encompasses all
subsets. Since you state it here, I assume that what you are really
saying is that you are supportive of a coherent, logically designed
subset.
> > I don't think that there is a useful
> > logically delimited subset of Standard C++ that can serve everybody
> > reasonably well (that's one reason we converged on the standard) or even
> > one that can serve all of the embedded systems community reasonably well.
> > The closest we can come it the zero-overhead subset of C++ that is defined
> > as the subset that can be implemented without a byte or a cycle's run-time
> > overhead - and the zero-subset C++ subset has templates as an obvious and
> > essential component. Only templates can deliver zero-overhead containers
> > and algorithms.
Yup.
> > In "The History of C++" article for ACM HOPL2 and in "The Design of
> > Evolution of C++," I deemed the failure of shipping a good standard library
> > with C++ release 1.0 or even release 2.0 my greatest mistake. I still
> > think that it was. EC++ repeats this mistake and thus condemns EC++
> > programmers to reinvent the wheel or suffer the problems of multiple
> > incompatible (and often commercial) foundation libraries that the C++
> > population at large is still trying to recover from.
Which argues strongly for adopting a formal subset. The subset itself is
already there: several compiler vendors ship products that support EC++.
The Standard can help solve this problem, or it can continue to be part
of the problem.
> > There is no good
> > reason for that, templates are in the zero-overhead subset of C++ and
> > the STL is part of the standard library and several high-quality,
> > high-performance implementations are available. I could claim to have
> > had a good excuse for my mistake back in 1985 and possibly even in 1989;
> > I don't think such an excuse exists today.
Perhaps I was mistaken in assuring the EC++ Technical Committee and the
Japanese national body last February that their needs would get a fair
hearing in the ISO/ANSI standards committee. I could claim to have had a
good excuse for my mistake back in 1991 and possibly even in 1995; I don't
think such an excuse exists today.
> > A significant problem with a formally defined "near subset" is that it
> > develops its own culture and will eventually develop in a direction
> > different from the language of which it is ostensibly a "near subset."
> > The members of this culture will inevitably develop a rationale for
> > their subset being superior to all alternatives. This leads to effort
> > diverted from the standard and to distracting debates.
A significant problem with a formally defined "standard" is that it
develops its own culture and will eventually develop in a direction
different from the needs of its users. The members of this culture will
inevitably develop a rationale for their standard being superior to all
alternatives. This leads to efforts diverted from the needs of users and to
distracting debates.
I'm getting a very uncomfortable feeling from this thread that there's
a growing attitude that EC++ is being supported by a group of lazy,
technically inept outsiders. Bjarne, please don't contribute to this
misconception. You know better.
(Note to all readers: I apologize for the disrespectful tone of some of my
comments above. Apparently the rules of discussion in this forum prohibit
direct, factually-based challenges but permit innuendo and half truths. I
have edited my original message to comply with the rules.)
-- Pete
Dinkumware, Ltd.
"Genuine Software"
[Moderator's note:
Pete Becker has apparently misunderstood our moderation policy.
"Direct, factually-based challenges" are fine, so long
as they do not include wording that is unnecessarily
inflammatory and that would add more heat than light.
Half truths are generally fine too, in fact complete
falsehoods are fine! The moderators take no responsibility
for the veracity of postings: readers should judge the
truthfulness (or otherwise) of articles for themselves.
As for innuendo (which my Concise Oxford defines as
"oblique hint, allusive remark (usually depreciative)"),
that is a rather subjective concept which by its very nature
is difficult for moderators to even identify.
As always, a convincing rebuttal is the best remedy.
-moderator (fjh).]
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Daniel Parker" <danielp@nospam.com>
Date: 1998/06/17 Raw View
Pete Becker wrote in message <3586F7D5.9A4DF81A@acm.org>...
>David J. Littleboy wrote:
>>
>> Any feature left out makes EC++ a worse language than C++. There is no
>> question that EC++ is a worse language than C++.
>
>Replace "worse" with "less powerful" and I agree.
>
>> The only issue is that for
>> some people, the added value of the features being cut is outweighed by the
>> costs of implementing and support.
>
>More generally: if C++ produces an executable that's too big for your
>target platform and EC++ produces one that fits, EC++ is far better than
>C++ for your purposes.
You would concede, though, that the motivation for EC++ as expressed in the
rationale document is primarily to simplify the language for "average C
programmers" and only secondarily to make a smaller, faster executable?
Now, if a programmer were using a Standard C++ compiler, with RTTI disabled,
and he writes a program using the subset of the language found in EC++,
except he doesn't use streams, is there a reason to suppose that the
resulting executable would be bigger than the executable EC++ would produce?
--
Regards,
Daniel Parker danielp@no_spam.anabasis.com.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <david.tribble@noSPAM.central.beasys.com>
Date: 1998/06/17 Raw View
I, David R Tribble wrote:
>> Theoretical arguments aside, there are those of us who develop real
>> code designed to run on several real platforms. We are thus forced to
>> use a "least common denominator" language; call it "LCD-C++". Some...
[That should be "greatest common denominator" language, or "GCD-C++".]
>> ...
>> Is GCD-C++ the same as EC++? I don't know. But I really only care
>> that GCD-C++, the language I must program with, is not the same as
>> ISO C++.
James Kuyper wrote:
> More importantly, GCD-C++ will be incompatible with ISO C++ (I can't
> give details, I have no copy of the GCD-C++ standard :-). Therefore, any
> code written in it will slowly become less and less portable as more and
> more vendors start providing ISO C++.
No, since GCD-C++ is a proper subset of the C++ standard (specifically,
the subset that is supported TODAY), it should be, and probably is,
fully compatible with full-blown ISO C++. One of the goals for us is
for GCD-C++ to be a truly proper subset of ISO C++, for the simple
reason that we don't want to have to rewrite our code in the future in
order to correct incompatibilities with ISO C++. As far as we can tell,
our code will compile okay on a fully compliant ISO C++ compiler in the
future.
Bear in mind that GCD-C++ is not a language definition of what you CAN
use so much as it is a list of features you CANNOT use. (Things like
nested classes, complicated templates, exception handling, std::, etc.)
GCD-C++ is designed to omit the features of ISO C++ we simply don't have
universally available to us yet.
Thus the language covered by GCD-C++ is an evolving subset. Every
time we get a new release of a compiler for one of our operating
systems,
we see if it supports more of the full C++ language, so that we can
remove some restrictions from our GCD-C++ subset. For example, once all
our compilers support nested classes correctly, we will remove the
restriction on using nested classes from GCD-C++, or in other words, we
will add nested classes to GCD-C++. Eventually, we hope, GCD-C++ will
be identical to ISO C++. But we don't expect that to happen for at
least another 12 to 24 months.
(Indeed, our "GCD-C++ language standard" is an internal document
entitled "Portable C++ Coding Guidelines", a list of do's and don't's,
which is updated periodically as our compilers get better. Eventually,
this document will contain no restrictions on the language, but will
only discuss portability issues between systems.)
-- David R. Tribble, david.tribble@central.beasys.com --
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Oleg Zabluda <zabluda@math.psu.edu>
Date: 1998/06/14 Raw View
David J. Littleboy <davidjl@gol.com> wrote:
: (Remember, the Annotated C Standard is a mere 200 pages, whereas Bjarne's
: book is 900, and it took Bjarne _five_ printings to get most of the
: (incredibly numerous) errors out.
Raw number of errors means nothing. A meanigful measure would be
the density of errors (a number of errrors divided by the amount
of material covered) weighted by the obscureness of the error.
This measure doesn't strike me as too high in the original printings
of C++PL3.
Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Oleg Zabluda <zabluda@math.psu.edu>
Date: 1998/06/14 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> wrote:
: In article <6lj95e$bt6$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
: writes
[...]
: >In this case, you are simply wrong. In hi-rel code, exceptions are
: >generally banned, because proving exception safety is too difficult.
: No, I don't agree. It is completely trivial to make C++ code exception
: safe : compile all modules with exceptions enabled and use the exception
: enabled version of the library. Then wrap the contents of main() in a
: try...catch block.
What James Kanze probably meant is that it is difficult to ensure
that all relevant cleanup was being made, not that it is difficult
to ensure that an exception does not escape from main().
As an example, consider a program which runs indefinitely. It
should clarify the point for you.
Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Oleg Zabluda <zabluda@math.psu.edu>
Date: 1998/06/14 Raw View
Daniel Parker <danielp@nospam.com> wrote:
: Oleg Zabluda wrote in message <6lklio$do@marianna.psu.edu>...
: >Jay Zipnick <no_junk_mail@best.com> wrote:
: >
: >: But you can read it and decide for yourself:
: >: <http://www.caravan.net/ec2plus/rationale.html>
: >
: >Thanks. I've read the rationale and all of it, minus some minor
: >details, makes no sense whatsoever.
: >
: Having no experience in embedded system programming whatsoever, I had always
: imagined embedded systems programmers to be highly skilled individuals. I
: was quite surprised to read in the EC++ document that they are actually
: quite stupid; the basic argument is that Standard C++ is too difficult for
: embedded systems programmers.
[...]
: There is surprizingly little discussion of efficiency issues either in terms
: of code size or performance, with the one or two exceptions being the
: predominate theme of this newsgroup thread.
That's right. It strikes me how different the "rationale" was
from the discussions in this thread. For example, I disagree
with almost everything P.J.Plauger says on the subject,
but at least he makes sense. Like I've said, the Rationale makes
no sense. Just like you've said, the overriding theme is
"We must do EC++ because an average C programmer is unable to learn
C++ and/or to use compiler options, like -fno-exceptions or -fno-rtti".
Incidently, my own experience so far, indicates that an average C
programmer is unable to learn plain C either. So what?
Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/06/15 Raw View
Matthias Neeracher wrote:
>
> David R Tribble <david.tribble@noSPAM.central.beasys.com> writes:
> > Be careful when using '-Dstd=', since it wipes out all types, tags,
> > variables, functions, members, and labels named 'std'.
> [...]
> > Perhaps this is a slightly better solution:
> >
> > # makefile
> > foo.o: foo.c
> > rm -f foo.o xfoo.[co]
> > sed 's/std:://g' foo.c >xfoo.c # The hack
>
> Wouldn't:
>
> sed 's/std::/::/g'
>
> Be safer?
Somewhat. However, either way would damage any code that contained a
class whose name ended in 'std'. You've got to be more careful with
universal search and replace operations.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/06/15 Raw View
David R Tribble wrote:
...
> Theoretical arguments aside, there are those of us who develop real
> code designed to run on several real platforms. We are thus forced to
> use a "least common denominator" language; call it "LCD-C++". Some
...
> Is LCD-C++ the same as EC++? I don't know. But I really only care
> that LCD-C++, the language I must program with, is not the same as
> ISO C++.
More importantly, LCD-C++ will be incompatible with ISO C++ (I can't
give details, I have no copy of the LCD-C++ standard :-). Therefore, any
code written in it will slowly become less and less portable as more and
more vendors start providing ISO C++.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/06/09 Raw View
In article <6lcura$bh6$1@godzilla.gol.com>,
"David J. Littleboy" <davidjl@gol.com> wrote:
> Anyway, my intuition, based on (a limited view of) the current state of
> microcontroller development environments in Japan, is that full C++ just
> isn't reasonable. So it's either stick with C, push forward with EC++, or
> do something different. If C++ subsetting is not acceptable, do you have
> suggestions for an alternative?
I have two other suggestions.
First, the people who have this problem might consider the previous version
of the ANSI/ISO C++ spec. (Was that 1992? I forget now.) This may have all
of the features that EC++ seems to need, with few or none of the features
that EC++ wants to avoid for now.
If that isn't acceptable (and somehow I doubt that either party will swallow
that), then sure, go ahead with another spec. But perhaps emotions would run
a little cooler if we stopped calling it a C++ subset, and started calling it
a superset of C. The superset's additional features would be modelled after
similar features in C++, but there would be no other connection between the
two.
Surely, with C/CFront/C++1992/C++1997/Java already in circulation, nobody
could object to Yet Another Language Spec in the series. The people that
feel that a C++ subset would slow down vendor efforts to implement
high-quality "real" C++ should see this as no more of a threat than Fortran
or Java. And the people who see this as an important standardization effort
to solve real-world problems, should see this as a method to accomplish just
that.
"A rose, by any other name..." (Shakespeare?)
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: tony@ns.cook.ml.org (Tony Cook)
Date: 1998/06/09 Raw View
James Kuyper (kuyper@wizard.net) wrote:
: Tony Cook wrote:
: > Someone did respond. In message <35640E53.C9A@aks.com> Eyal Ben-David
: > mentioned that Watcom C/C++ supports this feature (in version 11.0).
: His statement was pretty weak - it started with "AFAIK". I posted a
: simple test program earlier in this thread; does it compile to the same
: size both ways under Watcom C/C++?
I missed your code, but I did run a simple test of my own. Without
the vfremoval options the .exe size is 39936, and with the options it
is 38400. The program is as follows:
// vfrem2.h
class Base
{
public:
virtual void f1() = 0;
virtual void f2() = 0;
};
class Derived : public Base
{
public:
void f1();
void f2();
};
extern void g(Base *b);
// vfrem1.cpp
#include <iostream.h>
#include "vfrem2.h"
int main()
{
Derived d;
g(&d);
return 0;
}
// vfrem2.cpp
#include <iostream.h>
#include "vfrem2.h"
void Derived::f1()
{
cout << "Derived::f1" << endl;
}
void Derived::f2()
{
cout << "Derived::f2" << endl;
}
void g(Base *b)
{
b->f1();
}
The compilation options used were:
wcl386 -zmf -bt=nt -l=nt vfrem1.cpp vfrem2.cpp -fm
and:
wcl386 -zmf -bt=nt -l=nt vfrem1.cpp vfrem2.cpp -fm -zv /"op vfremoval"
The tests were done with v11.0a of Watcom C/C++
[Note: I'm a member of TeamPS, and help support the compiler so I
might have some bias, but pjp sells a EC++ implementation, so I guess
we're even.]
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/06/09 Raw View
In article <6lhjkt$313@engnews1.Eng.Sun.COM>,
Mike Davies <mike_davies@noco.demon.co.uk> wrote:
>
> In article <c=GB%a=_%p=Pi_Group%l=EAGLE-980608141826Z-
> 1224@eagle.pigroup.co.uk>, Martin Bonner <martin.bonner@pigroup.co.uk>
> writes
>
> >A lot of embedded work is safety critical, and the constraints imposed
> >on safety critical work are truely astonishing the first time round.
> >For example, new and delete are completely out of the question.
> >Pointers are quite often unacceptable.
>
> It is not correct to say that new and delete are "completely out of the
> question" for safety critical code. There are features in C++ that allow
> you to have deterministic dynamic de/allocation. Of course you have to
> do the work.
These features are also in EC++. However, the effort of proving the
deterministic characteristics of the allocation are often superior to
the effort necessary to not use new and delete.
> >EC++ is a smaller language than C++. It is thus easier to implement it
> >correctly, and it is also easier to show it has been implemented
> >correctly. This is crucial - one of the main arguments for C rather
> >than ADA in safety critical work is that although the language per se is
> >less type-safe, the compiler is more likely to translate the source
> >correctly.
>
> One of the main arguments for using a feature provided as part of a
> language rather than implementing it yourself is that the resulting code
> is more likely to be correct.
I guess it depends. My experience in embedded systems with C++ is that
compiler errors outnumber errors in my code by a ration of 2 to 1. (This
was with earlier compilers -- I doubt I find this the case with any of
the compilers I now use.)
One of the main reasons for the high number of compiler errors was that
the language was continuously evolving, so each compiler update, while
correcting some errors, introduced others.
> Are you saying for instance that a language
> without exception handling can be used to write more rugged code in a
> given timescale than one with that facility ? I disagree.
In this case, you are simply wrong. In hi-rel code, exceptions are
generally banned, because proving exception safety is too difficult.
There are sometimes exceptions: the Ariane 5 software, for example:-).
And no, I'm not claiming that exceptions were the cause of the software
failure, nor that it is impossible to write error free code in the
presence of exceptions. But the techniques to prove that the code is
error free are less widely known, and less studied, than those for
code without exceptions.
> Its is all very well saying that a compiler for a complicated language
> is likely to have more defects than a compiler for a simple one. This
> is likely true, the problem is that application code will contain *far*
> more defects than either of the compilers (it simply isn't thrashed to
> the same extent for one thing).
See above. This hasn't been my experience in the past (when I worked on
such systems). In general, I doubt that it is the case for hi-rel
systems -- for such systems, the code is extensively verified and tested,
much more than a compiler typically is. And having thousands of people
throwing random code at a compiler is NOT thorough testing.
> The reductio ad absurdem for your argument would have us all coding in
> forth (language translator sizes down to 8k). Are you seriously
> suggesting this would result in applications with fewer errors ?
Well, I know some people who claim this:-). In fact, there is some
compromise, and the break-even point evolves in time. IMHO, today,
for really life critical systems, even EC++ is too complicated.
> No. We need *all of* the complexity of C++ (though not necessarily all
> in one file or even program). We need it for this reason :
>
> We must have OO programming practices and backward compatibility with C
> to be able to write rugged code within tight time constraints. Anything
> removed from C++ will conflict with one or the other of these
> requirements.
You may need all of those things; I currently need only full support for
OO (including garbage collection:-(). In my embedded systems, however,
typically, only limited support for OO was important (encapsulation and
objects are often important, polymorphism much less), and backward
compatibility with C was of no importance. The time critical sections
were often written in assembler, as well, at least in the past. (Today,
I think that writing C-level C++ would do the trick.) As for "rugged",
it's a compromise -- almost by definition, anything related to C will
not be rugged.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/06/09 Raw View
AllanW@my-dejanews.com wrote in article
<6lhgic$rdt$1@nnrp1.dejanews.com>...
> In article <6lcura$bh6$1@godzilla.gol.com>,
> "David J. Littleboy" <davidjl@gol.com> wrote:
> First, the people who have this problem might consider the previous
version
> of the ANSI/ISO C++ spec. (Was that 1992? I forget now.) This may have
all
> of the features that EC++ seems to need, with few or none of the features
> that EC++ wants to avoid for now.
Having implemented that spec, and written a book about it, I should be all
for this approach. Certainly the functionality of ``pre-templatized'' C++
(circa March 1994 to be more precise) is very close to that of EC++. I even
began my EC++ library development with this earlier library -- and gave
it up after a day and a half.
The fact is, the C++ Standards committee really did make a number of
improvements and clarifications to the draft C++ Standard between March
1994 and November 1998. I gripe more than most about the complexification
that also occurred, but I also happily acknowledge the work of many fine
people to make a better specification. EC++ is better off being a subset of
the final C++ Standard than trying to roll back the clock to a nominally
simpler era.
> If that isn't acceptable (and somehow I doubt that either party will swallow
> that), then sure, go ahead with another spec. But perhaps emotions would
> run a little cooler if we stopped calling it a C++ subset, and started
> calling it a superset of C. The superset's additional features would
> be modelled after similar features in C++, but there would be no other
connection between the two.
We can call it Fred, for all I care. Arguing about whether EC++ is or
should be a subset of C++ is, to me, a quibble. I need fewer ifdefs
to make code portable between EC++ and full C++ than I do between any
two compilers, or compiler versions, I can think of offhand.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: no_junk_mail@best.com (Jay Zipnick)
Date: 1998/06/09 Raw View
Reading the recent posts, does bring up a number of concerns about EC++:
1) Subset:
I don't know if this is what Andrew Koenig alluded to, but it seems that I
cannot just take code from this "subset", and simply compile it with a C++
compiler. Example:
EC++ code: s = sqrt(d); // EC++ has no namespaces
C++ code: s = std::sqrt(d);
If someone gives me EC++ code, it is not guaranteed to compile on my C++
compiler without modification. This reminds me of the times I needed to
modify old K&R style C function definitions for my stricter ANSI C/C++
compiler. Who wants to do that again? There may be other/better examples
than the std namespace, but you get the point -- it's not a true subset of
C++ if I need to modify it to compile for C++.
2) Templates:
I have an efficient FixedPoint class that was written for fast low-level
device control and embedded systems applications. This class uses
templates with nontype template parameters to specify the number of
integer and fractional bits. It would be unuseable with EC++. Templates
are just too useful. I am surprised that there are intelligent people
suggesting disabling them for "a good cause".
Part of the "rationale" against templates from the Embedded C++ Technical
Committee is "if used carelessly, templates might cause unexpected code
explosion". In the right hands any language feature can be misused. That
is not a sufficient argument to not be included. Arguments such as this
are simply nonsequiturs. The rest of the rationale seemed equally weak.
But you can read it and decide for yourself:
<http://www.caravan.net/ec2plus/rationale.html>
BTW, I have programmed 8085 systems with 256 bytes of RAM, 6502 systems
with 1K RAM, 6800 and Z80 systems with a whopping 32K RAM..., so I
understand the other side of these arguments for squeezing every ounce of
speed or byte of memory. I just don't agree with the current EC++ "subset"
direction. Instead of letting a standard declare parts of a langauge and
library as "non-essential" or not required for a class of applications,
let the customer have a full implementation (or at least as rich as a
vendor can provide) and let the customer decide what s/he needs to use. If
there are performance or size limitations, let the customer decide how it
is best to optimize. It could very well be the best approach to optimize a
specific embedded application may require features not available in EC++.
- Jay Zipnick
--
(Change username from "no_junk_mail" to "jayz" to reply)
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/06/09 Raw View
Tony Cook <tony@ns.cook.ml.org> wrote in article
<6lhs92$gdi$1@ns.cook.ml.org>...
> James Kuyper (kuyper@wizard.net) wrote:
> : Tony Cook wrote:
> : > Someone did respond. In message <35640E53.C9A@aks.com> Eyal Ben-David
> : > mentioned that Watcom C/C++ supports this feature (in version 11.0).
> .....
> : His statement was pretty weak - it started with "AFAIK". I posted a
> : simple test program earlier in this thread; does it compile to the same
> : size both ways under Watcom C/C++?
>
> I missed your code, but I did run a simple test of my own. Without
> the vfremoval options the .exe size is 39936, and with the options it
> is 38400. The program is as follows:
> .....
> [Note: I'm a member of TeamPS, and help support the compiler so I
> might have some bias, but pjp sells a EC++ implementation, so I guess
> we're even.]
I have no bias whatsoever about the truth. I simply missed the posting
that Watcom has this optimization, before I made my statement. I am
in fact delighted to hear that commercial compilers are now available
that optimize away unused virtuals. I hope to see even more of them
soon.
I must also reiterate, however, that this optimization deals with only
part of the ``problems with locale and its facets.'' I actually avoid
loading most unused virtuals by other ruses, and I still can't get
simple executables that link with the full C++ library down to the same
size as those that link with the EC++ library. I continue to work on
the problem, and I welcome any help I can get from the compiler and its
tool chain.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/10 Raw View
In article <6l7v5o$557$1@godzilla.gol.com>, "David J. Littleboy"
<davidjl@gol.com> writes
... snip ...
>> 2. The language subset EC++ represents is a poor match not only for
>> real user requirements, but also for the real overheads one
>> encounters with current compilers. For example, EC++ lacks
>> templates even though in typical implementations templates
>> impose no overhead and (indeed) are a key tool for user-level
>> optimization. EC++ has no support for namespaces, despite
>> that these cannot cause any overhead even in the most naive
>> implementation.
>
>From where I sit, it looks as though you don't understand the "real user
>requirements" of the EC++ community; you are arbitrarily applying your
>requirements, and they don't address the problems.
>
I am a user of C++ in hard real time embedded systems. Allow me to tell
you my requirements :
I *need* templates and use them all the time. They are a total boon IMO,
if you're moderately careful they are easy enough to use.
I *need* exception handling and can afford the small amount of function
size increase it engenders for those files/processes that support it (if
a given piece of code *couldn't* afford it then I would *need* a
#pragma/compiler switch to disable it).
I *need* multiple inheritance to help me divorce interfaces from
implementations.
I *need* virtual functions for efficiency reasons.
I have been lucky enough to have not (so far) ever *needed* namespaces,
but when I do the alternatives will be truly horrible.
I *need* C compatibility to allow me to re-use existing code.
I have used all these facilities (except namespaces) in the real world
in motor control (and other) hard real time embedded applications. I
know that the project would have been harder to implement / taken longer
without them. Exception handling is especially important to me.
The CPU used had hardware memory protection which helped uncover many
defects during development - sing Yo! for that too :-)
Thank god we're living in 1998 not 1968, I say.
There is a much better solution for the embedded compiler vendor to
follow than to create a cut down version of C++ :
They simply have to implement as much of C++ as they can do within their
individual time and implementation efficiency constraints and then
*publish* their current status.
Think of what this would do to empower the user ! S/he could, for
instance, judge a microcontroller makers' seriousness about supporting
their products by the quality of the information they released about
their compiler. The compilers that had the closest support for the full
C++ standard would obviously be the ones targeted at CPUs that had the
brightest futures.
Similarly for the independant compiler vendors, these would be competing
in an open market to release better and better, closer and closer
conforming, more and more efficient fully compliant C++ compilers !
It does of course give users an easier time at the expense of compiler
vendors . Still never mind, eh :-)
There would be no chance in this scenario for compiler vendors to band
together and settle for what is IMO a 3rd rate, unsatisfactory solution
like EC++ . For if they did then wouldn't the other guy try to steal a
jump by implementing another feature of C++ behind their backs ? And
wouldn't that mean that they'd have to follow suit to stay competitive ?
Would that be in the users interests, *and* the compiler vendors ? Hey ?
:-)
A problem with an expedient like a language subset is that it is likely
IMO to result in the compiler products leveling down instead of up.
By which I mean that If a salesman can answer :
"Of course we have a fully standard compliant EC++ compiler available
for our products, Sir!"
then they are less likely to pull out all the stops releasing a fully
standard compliant C++ compiler. Notice the difference that all-
important (and oh-so-subtle) initial "E" has.
>The majority of the members on the EC++ committee are Japanese
>microcontroller manufacturers. As a technical translator (J->E) who has
>translated a lot of data sheets and manuals related to Japanese
>microcontrollers and their development environments, it sounds to me as
>though you have no idea of the difficulties the Japanese have in providing
>software for their products. Given their limited manpower resources,
>implementing (or even dealing with) all of C++ is simply not an option, at
>least for the relatively smaller players. Yet even a subset of C++ would
>make life much easier for developers. (I.e., full C++ is just too hard for
>the struggling sub-sub-sub-contractors where the work is actually done.)
>
>In other words, there is a real problem, and the people who have this
>problem are working to create a workaround. I don't see anything wrong with
>that. Especially since they are doing it in a reasonably open and public
>manner.
You appear to me to be saying that the reason for EC++ to exist is to
reduce the investment that certain embedded compiler vendors will have
to make in their products !
This is surely an unwarrantable slur on those fine fellows ! I am
certain that they (you don't give the company names, and I won't invent
any here) would have chosen to follow the approach I describe above
instead, as it is so obviously more in interests of their customers.
I am surprised that your assertion made it past the moderator given the
parliamentary standards of language understandably being levelled upon
this thread !!
... snip ...
>David J. Littleboy <davidjl@gol.nonspam.com>
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/06/10 Raw View
Jay Zipnick <no_junk_mail@best.com> wrote in article
<no_junk_mail-0906980056000001@c420522-a.snvl1.sfba.home.com>...
> Reading the recent posts, does bring up a number of concerns about EC++:
>
> 1) Subset:
> .....
> I don't know if this is what Andrew Koenig alluded to, but it seems that
I
> cannot just take code from this "subset", and simply compile it with a
C++
> compiler. Example:
>
> EC++ code: s = sqrt(d); // EC++ has no namespaces
> C++ code: s = std::sqrt(d);
Or you could add ``using namespace std;'' in one place. You could even
protect it with an ifdef if your goal was to write code in the largest
common subset. The point is, you can be officious about employing
the term ``subset'' in its mathematically purest sense, or you can
notice that pragmatically the Hamming distance between EC++ and
full C++ is even less than the distance between Standard C and
Standard C++. Take your pick.
> 2) Templates:
>
> I have an efficient FixedPoint class that was written for fast low-level
> device control and embedded systems applications. This class uses
> templates with nontype template parameters to specify the number of
> integer and fractional bits. It would be unuseable with EC++. Templates
> are just too useful. I am surprised that there are intelligent people
> suggesting disabling them for "a good cause".
So would I. I haven't heard anybody suggesting that we do. You can use
lint and heed many of its warnings. That doesn't mean that lint is
outlawing
the use of certain constructs -- it's simply warning you about potential
portability or maintenance issues. The C Standard provides for an embedded
subset that eliminates the requirement for most library headers. It doesn't
*outlaw* those headers, it merely sets minimum requirements for an
embedded implementation.
I like templates. I'm all for 'em. The EC++ library happens not to use any
templates, for maximum portability across implementations. Whether or
not that makes for a smaller library, I won't speculate here. It certainly
doesn't make for a larger one, as far as I can tell.
> Instead of letting a standard declare parts of a langauge and
> library as "non-essential" or not required for a class of applications,
> let the customer have a full implementation (or at least as rich as a
> vendor can provide) and let the customer decide what s/he needs to use.
If
> there are performance or size limitations, let the customer decide how it
> is best to optimize. It could very well be the best approach to optimize
a
> specific embedded application may require features not available in EC++.
That's generally a good guideline. Where it breaks down is in the library
specification. Sometimes you can't just say, ``I'm only interested in the
part of the iceberg that's above water.'' Sometimes you have to redesign
the iceberg.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <david.tribble@noSPAM.central.beasys.com>
Date: 1998/06/10 Raw View
"David J. Littleboy" <davidjl@gol.com> wrote:
>> First, the people who have this problem might consider the previous
>> version of the ANSI/ISO C++ spec. (Was that 1992? I forget now.)
>> This may have all of the features that EC++ seems to need, with few
>> or none of the features that EC++ wants to avoid for now.
>> ...
>> If that isn't acceptable (and somehow I doubt that either party will swallow
>> that), then sure, go ahead with another spec. But perhaps emotions would
>> run a little cooler if we stopped calling it a C++ subset, and started
>> calling it a superset of C. The superset's additional features would
>> be modelled after similar features in C++, but there would be no other
>> connection between the two.
P.J. Plauger wrote:
> We can call it Fred, for all I care. Arguing about whether EC++ is or
> should be a subset of C++ is, to me, a quibble. I need fewer ifdefs
> to make code portable between EC++ and full C++ than I do between any
> two compilers, or compiler versions, I can think of offhand.
Theoretical arguments aside, there are those of us who develop real
code designed to run on several real platforms. We are thus forced to
use a "least common denominator" language; call it "LCD-C++". Some
compilers don't support templates fully, some don't support
'new(nothrow)',
some don't support exceptions (at all), some have problems with shared
libraries, some choke on nested classes, some don't support namespaces,
some don't interface well to other languages (which we require), and on
and on. We determine what it is that they can't handle, and yank it
out of our development language. Thus LCD-C++ is a "supported" subset
of ISO C++.
(For those interested, these are the primary platforms we port to:
HP-UX 10.20
DEC Unix 4.0b
Sun Solaris 2.5
IBM AIX 4.2
MS Windows NT 4.0
These are not trivial platforms. And there are more platforms on the
way in the near future. And whatever version we use to build our
executables, we must require our customers to use also.)
Yes, it would be nice to use full-featured C++. But for the next 12
to 24 months, we can't. Not until the compiler vendors catch up.
All of them. (Remember, the standard isn't even approved yet.) And
even after they do, there will still be compiler bugs that prevent us
from using *some* advanced features. So we're stuck with LCD-C++, which
will slowly become less crippled, but which will always be less than
100% ISO C++.
We experienced the same problem several years back, when the vendors
were
trying to catch up to ISO C. That language was standardized by 1990,
but our compilers didn't catch up until 1994. Well, here we are in
1998, repeating history all over again.
Is LCD-C++ the same as EC++? I don't know. But I really only care
that LCD-C++, the language I must program with, is not the same as
ISO C++.
-- David R. Tribble, david.tribble@noSPAM.central.beasys.com --
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/10 Raw View
Mike Davies wrote:
>
>
> I am a user of C++ in hard real time embedded systems. Allow me to tell
> you my requirements :
>
> I *need* templates and use them all the time. They are a total boon IMO,
> if you're moderately careful they are easy enough to use.
>
> I *need* exception handling and can afford the small amount of function
> size increase it engenders for those files/processes that support it (if
> a given piece of code *couldn't* afford it then I would *need* a
> #pragma/compiler switch to disable it).
>
> I *need* multiple inheritance to help me divorce interfaces from
> implementations.
>
> I *need* virtual functions for efficiency reasons.
>
> I have been lucky enough to have not (so far) ever *needed* namespaces,
> but when I do the alternatives will be truly horrible.
>
> I *need* C compatibility to allow me to re-use existing code.
>
Then you should certainly *use* full C++.
> Vecdors simply have to implement as much of C++ as they can do within their
> individual time and implementation efficiency constraints and then
> *publish* their current status.
Maybe. But pity the poor programmer who works on several projects in
succession for different targets with different language subsets. Talk
about whiplash...
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/06/10 Raw View
In article <01bd93f0$ac7dc680$8a1ec2d0@porky>,
"P.J. Plauger" <pjp@dinkumware.com> wrote:
>
> Jay Zipnick <no_junk_mail@best.com> wrote in article
> <no_junk_mail-0906980056000001@c420522-a.snvl1.sfba.home.com>...
> > Reading the recent posts, does bring up a number of concerns about EC++:
> >
> > 1) Subset:
> > .....
> > I don't know if this is what Andrew Koenig alluded to, but it seems that
> I
> > cannot just take code from this "subset", and simply compile it with a
> C++
> > compiler. Example:
> >
> > EC++ code: s = sqrt(d); // EC++ has no namespaces
> > C++ code: s = std::sqrt(d);
>
> Or you could add ``using namespace std;'' in one place.
It would seem to me that invoking the EC++ compiler with -Dstd= would
be an even simpler solution. Of course, if you forget an std::, the
EC++ compiler won't pick it up, but it will fail when compiled with
a complete C++ compiler.
Just curious, but can anyone give an example where a program written
to EC++ spec's, but using std:: (and the -Dstd= flag to compile the EC++)
would not compile under complete C++. Or worse (and probably more likely)
where it would compile, but with different semantics?
> > 2) Templates:
> >
> > I have an efficient FixedPoint class that was written for fast low-level
> > device control and embedded systems applications. This class uses
> > templates with nontype template parameters to specify the number of
> > integer and fractional bits. It would be unuseable with EC++. Templates
> > are just too useful. I am surprised that there are intelligent people
> > suggesting disabling them for "a good cause".
>
> So would I. I haven't heard anybody suggesting that we do. You can use
> lint and heed many of its warnings. That doesn't mean that lint is
> outlawing
> the use of certain constructs -- it's simply warning you about potential
> portability or maintenance issues. The C Standard provides for an embedded
> subset that eliminates the requirement for most library headers. It doesn't
> *outlaw* those headers, it merely sets minimum requirements for an
> embedded implementation.
>
> I like templates. I'm all for 'em. The EC++ library happens not to use any
> templates, for maximum portability across implementations. Whether or
> not that makes for a smaller library, I won't speculate here. It certainly
> doesn't make for a larger one, as far as I can tell.
Funny, the more I use templates, the less I like them. They seem to be
ideal for introducing subtle bugs in working code. Changing the order
of declarations in a C++ program can always cause changes in the semantics,
because it affects what variables are visible at a given point. With
templates, however, the changes are "invisible", because the point of
instantiation (which determines the semantics of the instantiated template)
is not physically manifested in the program; for that matter, the
context of instantiation is not terribly clear anyway (to me, anyway).
About the best thing one can say about templates is that they are nowhere
near as bad as the currently available alternatives (the C++ preprocessor,
in particular, although using generic.h macros is significantly more
robust than templates).
Of course, this problem tends to manifest itself only in the largest
systems, not in the type of systems EC++ targets.
> > Instead of letting a standard declare parts of a langauge and
> > library as "non-essential" or not required for a class of applications,
> > let the customer have a full implementation (or at least as rich as a
> > vendor can provide) and let the customer decide what s/he needs to use.
> If
> > there are performance or size limitations, let the customer decide how it
> > is best to optimize. It could very well be the best approach to optimize
> a
> > specific embedded application may require features not available in EC++.
>
> That's generally a good guideline. Where it breaks down is in the library
> specification. Sometimes you can't just say, ``I'm only interested in the
> part of the iceberg that's above water.'' Sometimes you have to redesign
> the iceberg.
It also breaks down as soon as one considers code reuse, which implies
portability. (This is, of course, why it breaks down in the library
specification. But the library specification is not the only thing
affected.) The code reuse issue is, in fact, the only reason to back
EC++ -- if you don't care about code reuse, just see what works for
your compiler, and be done with it.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Matt Austern <austern@sgi.com>
Date: 1998/06/10 Raw View
David R Tribble <david.tribble@noSPAM.central.beasys.com> writes:
> Is LCD-C++ the same as EC++? I don't know. But I really only care
> that LCD-C++, the language I must program with, is not the same as
> ISO C++.
It isn't. I think it's safe to assume that LCD-C++ is the C++ of the
ARM, with a few minor changes and additions. That means LCD-C++ has
exceptions and that it has some limited support for templates. As I
understand it, though, the proposed EC++ subset doesn't have even a
limited form of templates.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/10 Raw View
In article <6lj95e$bt6$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
writes
>>
>> It is not correct to say that new and delete are "completely out of the
>> question" for safety critical code. There are features in C++ that allow
>> you to have deterministic dynamic de/allocation. Of course you have to
>> do the work.
>
>These features are also in EC++. However, the effort of proving the
>deterministic characteristics of the allocation are often superior to
>the effort necessary to not use new and delete.
I agree of course that you should use whichever technique is best suited
to the task at hand. You said however that new and delete are
"completely out of the question" for safety critical systems and were
using this to support your argument that embedded systems will not miss
certain features of C++, or am I mistaken ?
>>
>> One of the main arguments for using a feature provided as part of a
>> language rather than implementing it yourself is that the resulting code
>> is more likely to be correct.
>
>I guess it depends. My experience in embedded systems with C++ is that
>compiler errors outnumber errors in my code by a ration of 2 to 1. (This
>was with earlier compilers -- I doubt I find this the case with any of
>the compilers I now use.)
I don't know which C++ compilers you have used but I am astonished to
hear this. I have used the Borland and Watcom compilers and although
there has not been a spec for the language 'till now I could number the
bugs I've run into in either of these compilers on the fingers of one
hand. I only wish that were true of my code :-) (during the development
process anyway). The situation with libraries may be slightly worse
though.
>
>One of the main reasons for the high number of compiler errors was that
>the language was continuously evolving, so each compiler update, while
>correcting some errors, introduced others.
>
>> Are you saying for instance that a language
>> without exception handling can be used to write more rugged code in a
>> given timescale than one with that facility ? I disagree.
>
>In this case, you are simply wrong. In hi-rel code, exceptions are
>generally banned, because proving exception safety is too difficult.
No, I don't agree. It is completely trivial to make C++ code exception
safe : compile all modules with exceptions enabled and use the exception
enabled version of the library. Then wrap the contents of main() in a
try...catch block.
Of course you then have the problem of what to do when you do catch an
error, but this is an easier problem than the problem of finding a
function that returns an error code that the calling code just
*silently* ignores. I know which bug I'd find easier to uncover if I was
a SW Test Engineer :-)
...snip...
>
>> Its is all very well saying that a compiler for a complicated language
>> is likely to have more defects than a compiler for a simple one. This
>> is likely true, the problem is that application code will contain *far*
>> more defects than either of the compilers (it simply isn't thrashed to
>> the same extent for one thing).
>
>See above. This hasn't been my experience in the past (when I worked on
>such systems). In general, I doubt that it is the case for hi-rel
>systems -- for such systems, the code is extensively verified and tested,
>much more than a compiler typically is. And having thousands of people
>throwing random code at a compiler is NOT thorough testing.
It's fair to say that one reason C++ hasn't been used in (eg) Aerospace
applications is the lack of a standard against which to test it. I don't
think that this is a reason in itself to cut the standard for C++ down
when we have one.
It is still the case that an application relying on a correctly
implemented language feature will have a better chance of being bug-free
than one where the programmer has had to implement the feature
themselves. Otherwise surely the only language choice for safety
critical systems would be assembler ? :-)
>
>> The reductio ad absurdem for your argument would have us all coding in
>> forth (language translator sizes down to 8k). Are you seriously
>> suggesting this would result in applications with fewer errors ?
>
>Well, I know some people who claim this:-).
I don't.
...snip...
>> No. We need *all of* the complexity of C++ (though not necessarily all
>> in one file or even program). We need it for this reason :
...snip...
>You may need all of those things; I currently need only full support for
>OO (including garbage collection:-().
Garbage collection is not directly related to OO design, but much closer
to dynamic allocation in general. It is ironic to hear somebody who is
arguing for EC++ on (inter-alia) efficiency reasons rueing the omission
of garbage collection from C++ when this was done precisely because it
is hard to implement without adding an overhead to the language. If you
think new and delete are out of the question for safety critical systems
then wait till you see your system stop dead while it carries the trash
out !
>In my embedded systems, however,
>typically, only limited support for OO was important (encapsulation and
>objects are often important, polymorphism much less), and backward
>compatibility with C was of no importance. The time critical sections
>were often written in assembler, as well, at least in the past. (Today,
>I think that writing C-level C++ would do the trick.)
Templates and inline virtual functions allow code to be written that is
simultaneously high level and more efficient than is convenient to write
in modular assambler language.
I gave an example of this in comp.arch.embedded recently which you could
probably still find on dejanews if you are interested.
I repeat that there is no feature of C++ that will not be missed if it
is removed from the language.
People have tried to say in this thread that resource constrained
embedded systems programmers will not miss various features.
I would say that we are exactly the people who will miss templates,
exceptions, multiple inheritance etc.
More so than resource rich systems where it is ok to use a feature that
inefficiently implemented (perhaps because written at the application
level, perhaps because it hasn't had the time spent on it that is needed
to make it efficient).
>
>--
>James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
Regards,
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Oleg Zabluda <zabluda@math.psu.edu>
Date: 1998/06/11 Raw View
Jay Zipnick <no_junk_mail@best.com> wrote:
: Part of the "rationale" against templates from the Embedded C++ Technical
: Committee is "if used carelessly, templates might cause unexpected code
: explosion". In the right hands any language feature can be misused. That
: is not a sufficient argument to not be included. Arguments such as this
: are simply nonsequiturs. The rest of the rationale seemed equally weak.
: But you can read it and decide for yourself:
: <http://www.caravan.net/ec2plus/rationale.html>
Thanks. I've read the rationale and all of it, minus some minor
details, makes no sense whatsoever.
Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1998/06/11 Raw View
Matt Austern <austern@sgi.com> writes:
|> David R Tribble <david.tribble@noSPAM.central.beasys.com> writes:
|>
|> > Is LCD-C++ the same as EC++? I don't know. But I really only care
|> > that LCD-C++, the language I must program with, is not the same as
|> > ISO C++.
|>
|> It isn't. I think it's safe to assume that LCD-C++ is the C++ of the
|> ARM, with a few minor changes and additions. That means LCD-C++ has
|> exceptions and that it has some limited support for templates. As I
|> understand it, though, the proposed EC++ subset doesn't have even a
|> limited form of templates.
I think it depends on what your application domain is, and what your
portability requirements are. If your application results in a couple
of 100KBytes of code, or uses some form of windowing, or perhaps
persistent data on disk, you may be right, although even today, if you
want to use templates, you need a lot of #ifdef's to handle the
portability issues. If your applications are designed to fit into less
than 16KBytes, I rather think that EC++ is very close to LCD-C++, and
that this will probably be the case for some time yet.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <david.tribble@noSPAM.central.beasys.com>
Date: 1998/06/12 Raw View
jkanze@otelo.ibmmail.com wrote:
> It would seem to me that invoking the EC++ compiler with -Dstd= would
> be an even simpler solution. Of course, if you forget an std::, the
> EC++ compiler won't pick it up, but it will fail when compiled with
> a complete C++ compiler.
>
> Just curious, but can anyone give an example where a program written
> to EC++ spec's, but using std:: (and the -Dstd= flag to compile the
> EC++) would not compile under complete C++. Or worse (and probably
> more likely) where it would compile, but with different semantics?
Be careful when using '-Dstd=', since it wipes out all types, tags,
variables, functions, members, and labels named 'std'.
I won't dwell on this because I think it's trivial, but here's an
ezample:
int main(int argc, char **argv)
{
int std;
std = (argc > 1);
return (std);
}
But I see what you're saying, and I agree.
Perhaps this is a slightly better solution:
# makefile
foo.o: foo.c
rm -f foo.o xfoo.[co]
sed 's/std:://g' foo.c >xfoo.c # The hack
$(CXX) $(CXXFLAGS) -c xfoo.c
mv -f xfoo.o foo.o
rm -f xfoo.c
-- David R. Tribble, david.tribble@central.beasys.com --
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Daniel Parker" <danielp@nospam.com>
Date: 1998/06/12 Raw View
Oleg Zabluda wrote in message <6lklio$do@marianna.psu.edu>...
>Jay Zipnick <no_junk_mail@best.com> wrote:
>
>: But you can read it and decide for yourself:
>: <http://www.caravan.net/ec2plus/rationale.html>
>
>Thanks. I've read the rationale and all of it, minus some minor
>details, makes no sense whatsoever.
>
Having no experience in embedded system programming whatsoever, I had always
imagined embedded systems programmers to be highly skilled individuals. I
was quite surprised to read in the EC++ document that they are actually
quite stupid; the basic argument is that Standard C++ is too difficult for
embedded systems programmers. The document states "the ultimate goal of
Embedded C++ is to provide embedded systems programmers with a subset of C++
that is easy for the average C programmer to understand and use" and it is
necessary to "remove complex features and specifications." Whether it's a
mutable keyword that "might bewilder the average embedded systems
programmer" or templates which would require the programmer "[having] to
invest a great deal of time to learn them well," or the fact that "it is
difficult even for an expert programmer to design a class hierarchy using
multiple inheritance", the main theme is to keep things simple for the
programmer. The document doesn't say that namespaces are too difficult for
programmers; only that "the size of [embedded] application programs cannot
be very large...under such conditions, names seldom, if ever, come into
conflict" and so namespaces aren't needed.
There is surprizingly little discussion of efficiency issues either in terms
of code size or performance, with the one or two exceptions being the
predominate theme of this newsgroup thread. But one or two substantative
issues are surely not sufficient to justify a new language subset, with its
new keywords, like float_complex and double_complex.
One suspects that whatever comittee came up with this document was lacking
in representation from embedded systems programmers; I doubt if they would
have been quite this condescending to themselves. They are actually
probably quite good.
--
Regards,
Daniel Parker danielp@no_spam.anabasis.com.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/12 Raw View
Mike Davies wrote:
>
>
> It is completely trivial to make C++ code exception
> safe : compile all modules with exceptions enabled and use the exception
> enabled version of the library. Then wrap the contents of main() in a
> try...catch block.
> Of course you then have the problem of what to do when you do catch an
> error, but this is an easier problem than the problem of finding a
> function that returns an error code that the calling code just
> *silently* ignores. I know which bug I'd find easier to uncover if I was
> a SW Test Engineer :-)
Exception safety is more complicated than this. For example:
void f()
{
lock_mutex();
do_processing();
unlock_mutex();
}
If do_processing throws an exception the mutex won't get unlocked.
Catching the exception in main doesn't help, because you don't know what
resources have to be released.
The answer here, as is often the case, is to use an object to lock and
unlock the mutex. If an exception is thrown the object's destructor will
be invoked, which will unlock the mutex.
-- Pete
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Matthias Neeracher <neeri@iis.ee.ethz.ch>
Date: 1998/06/12 Raw View
David R Tribble <david.tribble@noSPAM.central.beasys.com> writes:
> Be careful when using '-Dstd=', since it wipes out all types, tags,
> variables, functions, members, and labels named 'std'.
[...]
> Perhaps this is a slightly better solution:
>
> # makefile
> foo.o: foo.c
> rm -f foo.o xfoo.[co]
> sed 's/std:://g' foo.c >xfoo.c # The hack
Wouldn't:
sed 's/std::/::/g'
Be safer?
Matthias
--
Matthias Neeracher <neeri@iis.ee.ethz.ch> http://www.iis.ee.ethz.ch/~neeri
"Paranotions, which designate constructs, may now contain metanotions and
``hypernotions'' have been introduced in order to designate protonotions"
-- A. van Wijngaarden et al., _ALGOL 68 Revised Report_
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "David J. Littleboy" <davidjl@gol.com>
Date: 1998/06/12 Raw View
Daniel Parker wrote in message <6lpvbr$mu4$1@news.interlog.com>...
>Oleg Zabluda wrote in message <6lklio$do@marianna.psu.edu>...
>>Jay Zipnick <no_junk_mail@best.com> wrote:
>>
>>: But you can read it and decide for yourself:
>>: <http://www.caravan.net/ec2plus/rationale.html>
>>
>>Thanks. I've read the rationale and all of it, minus some minor
>>details, makes no sense whatsoever.
>>
>Having no experience in embedded system programming whatsoever, I had
always
>imagined embedded systems programmers to be highly skilled individuals. I
>was quite surprised to read in the EC++ document that they are actually
>quite stupid; the basic argument is that Standard C++ is too difficult for
>embedded systems programmers. The document states "the ultimate goal of
>Embedded C++ is to provide embedded systems programmers with a subset of
C++
>that is easy for the average C programmer to understand and use"
The reason for this is that the EC++ standard is written from the standpoint
of a manager of a hardware development group that either has an in-group
C-based development environment team or else subcontracts out the
development of their development environment. Said manager's company may
have lots of C++ expertise, but it's not in his group (nor at the
subcontractor). There happens to be a dearth of unemployed C++ gurus just
now, so if he wants to provide some sort of object-oriented support (and he
does), he's got to do it with the manpower he's got. That leaves him
terrified at the prospect of implementing and supporting C++.
(Remember, the Annotated C Standard is a mere 200 pages, whereas Bjarne's
book is 900, and it took Bjarne _five_ printings to get most of the
(incredibly numerous) errors out. C++ looks to said manager to be a large,
difficult language. (And who knows which errors got fixed in the Japanese
translation, if there is one.)
His clientelle (for his hardware) is not the space shuttle. It's cell
phones, vending machines, test and measurement equipment, audio equipment,
electric guitar effects boxes. All applications in which object oriented
support would be more than helpful. But full 1999 vintage C++ looks to our
manager friend like overkill.
The result is that he's interested in the 1985 or so version of C++.
[snip]
> the main theme is to keep things simple for the
>programmer. The document doesn't say that namespaces are too difficult for
>programmers; only that "the size of [embedded] application programs cannot
>be very large...under such conditions, names seldom, if ever, come into
>conflict" and so namespaces aren't needed.
Maybe because he's more concerned with (not<g>) implementing and supporting
namespaces. (The document does, by the way, argue that they are not
necessary in the scale of embedded systems that EC++ targets.)
>One suspects that whatever comittee came up with this document was lacking
>in representation from embedded systems programmers; I doubt if they would
>have been quite this condescending to themselves. They are actually
>probably quite good.
It certainly was lacking in representation from the sort of embedded systems
programmers you'll find on this list<g>. However, I'd bet that the EC++
standard goes over a lot better with programmers at companies that are
currently purchasing said manager's microcontrollers, since they might have
a bit more sympathy for said managers difficulties and they might prefer to
see a limited feature set implemented well.
David J. Littleboy <davidjl@gol.nonspam.com>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Matt Seitz" <mseitz@meridian-data.com>
Date: 1998/06/06 Raw View
Bjarne Stroustrup wrote in message ...
>I am convinced that in the long run most successful systems will
>evolve to the point where they need a large fraction of the facilities
>offered by Standard C++ and I would hate to see that evolution
>cribbled by arbitrary restrictions of a library or language subset.
>This is a major reason why I oppose formally defined subsets of C++.
Perhaps the way to avoid crippling the evolution to Standard C++ is for EC++
to not be a set of restrictions on a compiler, but rather a minimum standard
for compilers and libraries.
Think of it this way. Today, the target audience for EC++ is using C. They
want to use C++, but right now compiler vendors can't support the whole
standard. So as a first step they create a standard called EC++, which
represents a minimum set of features that a compiler must support today.
This allows users to write programs that they know will be compatible with
any EC++ compiler and library. Over time, the EC++ bar can be raised higher
and higher, adding Standard C++ features, until EC++ and Standard C++ are
one and the same.
For example, instead of saying that an EC++ compiler must not support
templates, the specification could simply be that an EC++ compiler is not
required to support templates. Next year, the EC++ Consortium could decree
that EC++ compilers must now support templates.
Would that approach solve the problems of EC++?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/06 Raw View
In article <01bd8e33$5bb1d7e0$8a1ec2d0@porky>, "P.J. Plauger"
<pjp@dinkumware.com> writes
You have been careful to avoid my main point so I'll repeat it here :
I need to be able to choose the features of C++ that I use on a per
project (or preferably per source file) basis. There are *no*
significant features of C++ that I will not someday *need*. That is why
they are in the language in the first place.
>There has been some discussion of EC++ *as a language dialect* that
>intentionally omits features that are not widely implemented. Ironically,
>the most widely used front end for EC++ compilers is the full-featured
>front end from EDG. Other companies that now advertise EC++
>*language* support -- Metrowerks and Cygnus -- do so by adding
>compiler switches to reasonably complete C++ compilers. So the
>reality is that the EC++ *language* is used to turn off compiler features,
>such as exception handling, where the overhead might be an insupportable
>burden.
You are telling me that if I buy an EC++ compiler from these vendors it
comes with a full-featured C++ as standard ?
...snip...
>Whether it's #pragmas, compiler switches, or #ifdefs, we're talking about
>the age-old practice of applying pragmatic extensions to a
>standard-conforming compiler and library, to meet the more stringent
>performance needs of a community of developers. This ain't rocket science,
>and it ain't a rebellion against the C++ Standard.
True for #pragmas and compiler switches, false for standard subsets of
the language - see my first point above.
>
>Embedded C++ differs from past practice in one significant respect --
>it has been developed by a consortium of (mostly Japanese) vendors as
>a voluntary industry standard for embedded systems development.
>Many
>of us would welcome even a de facto standard for: name mangling, DLLs,
>IDEs, GUIs, <your API here>.
DLLs, IDEs and GUIs are only peripherally relevant to the C++ standard,
name mangling has been dealt with here before.
>Why not one for high-performance C++?
Because in principle the whole of C++ can be made to be high-
performance. If you define a high-performance subset of C++ then you
remove the incentive of compiler vendors to fix the shortcomings of
their products. My experience is that they need no such incentives :-)
>
>> I speak as a consumer of programming languages, not a producer.
>
>Quite rightly. And I speak as a producer who has no business unless
>enough consumers are happy.
... "applying pragmatic extensions to a standard-conforming compiler and
library, to meet the more stringent performance needs of a community of
developers" ...
extending a language by removing language features !!!
You speak as a salesman surely :-)
>
>P.J. Plauger
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/06/06 Raw View
Matt Seitz <mseitz@meridian-data.com> wrote in article
<35787bec.0@newsread.exodus.net>...
> Perhaps the way to avoid crippling the evolution to Standard C++ is for
EC++
> to not be a set of restrictions on a compiler, but rather a minimum
standard
> for compilers and libraries.
That's how I've always thought of it. A typical EC++ compiler can
warn if you exceed the minimum subset -- much like using lint to
ensure maximum portability among implementations. But essentially
all compilers can and do let you use whatever language features you
choose.
BTW, ``crippling'' is a perjorative term oft repeated in this discussion.
I know of no evidence that anybody involved with EC++ is motivated
to cripple the evolution to Standard C++, or that such an outcome is
likely regardless of motivations (or that you could measure the effect
in any event). Have a red herring.
[ mod note: Emotions in this thread have run high. The
moderators have started to reject posts that contain perjorative
language, applying stricter standards to this thread than we
have for others. We hope not to let through any more articles
that imply that others have evil intentions. -sdc ]
> Think of it this way. Today, the target audience for EC++ is using C.
They
> want to use C++, but right now compiler vendors can't support the whole
> standard. So as a first step they create a standard called EC++, which
> represents a minimum set of features that a compiler must support today.
> This allows users to write programs that they know will be compatible
with
> any EC++ compiler and library. Over time, the EC++ bar can be raised
higher
> and higher, adding Standard C++ features, until EC++ and Standard C++ are
> one and the same.
>
> For example, instead of saying that an EC++ compiler must not support
> templates, the specification could simply be that an EC++ compiler is not
> required to support templates. Next year, the EC++ Consortium could
decree
> that EC++ compilers must now support templates.
>
> Would that approach solve the problems of EC++?
Nicely expressed, but I think it addresses only half the story. One reason
for promoting EC++ is indeed to cut some slack for vendors with incomplete
implementations. Still another is for those of us with complete front ends
or
libraries who can't deliver small enough code size and still adhere to the
full C++ Standard. You can blame tool-chain technology or call us lazy, but
that doesn't alter the simple fact that we can make many more embedded
systems developers happy by subsetting the current spec right now today.
The ``problems of EC++'' are, to me, the problems of standardizing an
ambitious spec for C++ before it was adequately field tested. I too expect
that EC++ and C++ will converge as we all gain experience over the coming
years.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/06/06 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> wrote in article
<jLCJWAAA2Zd1EwQ9@noco.demon.co.uk>...
> In article <01bd8e33$5bb1d7e0$8a1ec2d0@porky>, "P.J. Plauger"
> <pjp@dinkumware.com> writes
>
> You have been careful to avoid my main point so I'll repeat it here :
Please don't ascribe such motivations to me. I genuinely tried
to address the issues you raised. If I missed a point, well,
that's the stuff of dialogs.
> You are telling me that if I buy an EC++ compiler from these vendors it
> comes with a full-featured C++ as standard ?
Typically, yes. Some of our customers ship only the EC++ subset
library, but the translators are generally as full featured as they can
supply.
> >Why not one for high-performance C++?
>
> Because in principle the whole of C++ can be made to be high-
> performance. If you define a high-performance subset of C++ then you
> remove the incentive of compiler vendors to fix the shortcomings of
> their products. My experience is that they need no such incentives :-)
Uh, yeah. I don't see the harm in removing an unneeded incentive.
But in any event, I disagree. I wrote and sold compilers for a decade.
I now work with many compiler vendors. I can assure you that Topic
A at all times is ``What do the customers want THIS MONTH?''
Topic B is ``How will we ever find the resources to keep up with the
competition?'' Some customers want a high-performance subset of
C++ now. Some want full Standard C++ compliance asap. Some
customers want both of these things at once. Sigh.
> >Quite rightly. And I speak as a producer who has no business unless
> >enough consumers are happy.
>
> ... "applying pragmatic extensions to a standard-conforming compiler and
> library, to meet the more stringent performance needs of a community of
> developers" ...
>
> extending a language by removing language features !!!
No. Extending an *implementation* by optionally disabling expensive
language features. Read the words.
> You speak as a salesman surely :-)
I surely do. I have products to sell. One is a fully compliant Standard C++
Library, another is an efficient subset called the EC++ Library, and still
another is the EC++ Library with STL. I also speak about technical issues
as a competent techie, so I'm not *just* a salesman, surely.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "David J. Littleboy" <davidjl@gol.com>
Date: 1998/06/08 Raw View
Bjarne Stroustrup wrote in message ...
[snip]
>However, first I will check that there really is a performance problem
>and next I will report what I consider unnecessary overheads to my
>implementation provider and look for alternative vendors. The
>optimizations that has been mentioned in this and similar threads
>can be done without my intervention and I would naturally prefer that
>they be.
Listening to the people who object to EC++ leaves me with the impression
that they are not considering the problems and difficulties faced by
microcontroller manufactures.
The main problem is that the microcontroller manufacturer *IS* the vendor.
They can't "report unnecessary overheads to the implementation provider and
look for alternative vendors." They have to provide a development
environment that works at the point a given chip is released as a product.
Furthermore, when a customer has a problem developing an end-product
application, the microcontroller manufacturer must provide support or lose
the customer. Even if they purchase (Dinkumware, gnu whatever) and port,
they still have to provide in-house support and expertise. Add to this the
reality that there is a limited amount of C++ expertise in the world, these
companies face a very difficult situation.
>I am convinced that in the long run most successful systems will
>evolve to the point where they need a large fraction of the facilities
>offered by Standard C++ and I would hate to see that evolution
>cribbled by arbitrary restrictions of a library or language subset.
>This is a major reason why I oppose formally defined subsets of C++.
That may be true in the very long run, but in the near term there is a
gaping hole between C and C++, and for the foreseeable future, there will
be many applications that could benefit from a subset of C++, even a
subset without templates.
Anyway, my intuition, based on (a limited view of) the current state of
microcontroller development environments in Japan, is that full C++ just
isn't reasonable. So it's either stick with C, push forward with EC++, or
do something different. If C++ subsetting is not acceptable, do you have
suggestions for an alternative?
David J. Littleboy <davidjl@gol.nonspam.com>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Ross Smith" <ross.s@ihug.co.nz>
Date: 1998/06/08 Raw View
David J. Littleboy wrote in message <6lcura$bh6$1@godzilla.gol.com>...
>
>The main problem is that the microcontroller manufacturer *IS* the
vendor.
>They can't "report unnecessary overheads to the implementation provider
and
>look for alternative vendors." They have to provide a development
>environment that works at the point a given chip is released as a
product.
If alternative vendors are a non-issue, why do they need any kind of
standard? The purpose of a standard is cross-vendor compatibility. If
the microcontroller vendor is providing their own C++ development
environment, then surely they can just provide whatever subset of full
C++ they find convenient, without needing any committee's blessing.
--
Ross Smith ................................... mailto:ross.s@ihug.co.nz
.............. The Internet Group, Auckland, New Zealand ..............
"Remember when we told you there was no future? Well, this is it."
-- Blank Reg
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ark@research.att.com (Andrew Koenig)
Date: 1998/06/08 Raw View
In article <6lcura$bh6$1@godzilla.gol.com>,
David J. Littleboy <davidjl@gol.com> wrote:
> That may be true in the very long run, but in the near term there is a
> gaping hole between C and C++, and for the foreseeable future, there will
> be many applications that could benefit from a subset of C++, even a
> subset without templates.
One problem is that EC++ is not a subset of C++.
--
--Andrew Koenig
ark@research.att.com
http://www.research.att.com/info/ark
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Martin Bonner <martin.bonner@pigroup.co.uk>
Date: 1998/06/08 Raw View
In article <jLCJWAAA2Zd1EwQ9@noco.demon.co.uk> "Mike Davies"
<mike_davies@noco.demon.co.uk> writes:
>
> You have been careful to avoid my main point so I'll repeat it here :
>
> I need to be able to choose the features of C++ that I use on a per
> project (or preferably per source file) basis. There are *no*
> significant features of C++ that I will not someday *need*. That is why
> they are in the language in the first place.
[snip]
> In article <01bd8e33$5bb1d7e0$8a1ec2d0@porky>, "P.J. Plauger"
> <pjp@dinkumware.com> writes
>
> >
> >> I speak as a consumer of programming languages, not a producer.
> >
> >Quite rightly. And I speak as a producer who has no business unless
> >enough consumers are happy.
>
> ... "applying pragmatic extensions to a standard-conforming compiler and
> library, to meet the more stringent performance needs of a community of
> developers" ...
>
> extending a language by removing language features !!!
>
> You speak as a salesman surely :-)
A lot of embedded work is safety critical, and the constraints imposed
on safety critical work are truely astonishing the first time round.
For example, new and delete are completely out of the question.
Pointers are quite often unacceptable.
EC++ is a smaller language than C++. It is thus easier to implement it
correctly, and it is also easier to show it has been implemented
correctly. This is crucial - one of the main arguments for C rather
than ADA in safety critical work is that although the language per se is
less type-safe, the compiler is more likely to translate the source
correctly.
--
Martin Bonner, Pi Technology Ltd
Milton Hall, Church Lane, Milton, Cambridge, CB4 6AB
Tel: +44 (0)1223 203894
Fax: +44 (0)1223 203999
martin.bonner@pigroup.co.uk
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/08 Raw View
Andrew Koenig wrote:
>
>
> One problem is that EC++ is not a subset of C++.
Sigh. Yet another unhelpful argument. I assume that Andy is referring
to the absence of namespaces, which means that the standard C++ library
can't be in namespace std. This "problem" is trivial to work around in
the spec, so that every legal EC++ program will also be a legal C++
program*. A more ambitious fix would, of course, be to add namespaces.
If Andy has some other problem in mind it would be much more helpful if
he would state what that problem is, so that it can be discussed
meaningfully.
-- Pete
*the simplest answer I've been able to come up with is to require the
compiler to recognize and ignore "using namespace std;".
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/08 Raw View
In article <c=GB%a=_%p=Pi_Group%l=EAGLE-980608141826Z-
1224@eagle.pigroup.co.uk>, Martin Bonner <martin.bonner@pigroup.co.uk>
writes
>A lot of embedded work is safety critical, and the constraints imposed
>on safety critical work are truely astonishing the first time round.
>For example, new and delete are completely out of the question.
>Pointers are quite often unacceptable.
It is not correct to say that new and delete are "completely out of the
question" for safety critical code. There are features in C++ that allow
you to have deterministic dynamic de/allocation. Of course you have to
do the work.
>EC++ is a smaller language than C++. It is thus easier to implement it
>correctly, and it is also easier to show it has been implemented
>correctly. This is crucial - one of the main arguments for C rather
>than ADA in safety critical work is that although the language per se is
>less type-safe, the compiler is more likely to translate the source
>correctly.
One of the main arguments for using a feature provided as part of a
language rather than implementing it yourself is that the resulting code
is more likely to be corect. Are you saying for instance that a language
without exception handling can be used to write more rugged code in a
given timescale than one with that facility ? I disagree.
Its is all very well saying that a compiler for a complicated language
is likely to have more defects than a compiler for a simple one. This
is likely true, the problem is that application code will contain *far*
more defects than either of the compilers (it simply isn't thrashed to
the same extent for one thing).
The reductio ad absurdem for your argument would have us all coding in
forth (language translator sizes down to 8k). Are you seriously
suggesting this would result in applications with fewer errors ?
No. We need *all of* the complexity of C++ (though not necessarily all
in one file or even program). We need it for this reason :
We must have OO programming practices and backward compatibility with C
to be able to write rugged code within tight time constraints. Anything
removed from C++ will conflict with one or the other of these
requirements.
--
Mike Davies
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1998/05/30 Raw View
ncm@nospam.cantrip.org (Nathan Myers) writes:
[Quoting Bjarne...]
|> What could a group do to make C++ more effective for the
|> embedded systems community? Document efficiencies and
|> inefficiencies in generated code. Popularize implementation
|> techniques and programming techniques that are efficient in
|> time and space. Lobby for compiler options to turn off
|> features that don't meet the zero-overhead principle and
|> for efficient implementations of the standard library and,
|> where necessary, subsets [note plural] thereof. ...
|> Does this require a formal specification of yet another
|> C/C++ dialect? I doubt it, and every dialect does some harm
|> by fragmenting the community... Nor do I see the embedded
|> systems C++ community as a monolith whose needs can be
|> completely served by a single subset language and almost-
|> subset standard library. ... Only the ability of
|> individual organizations to pick suitable proper subsets
|> of ISO C++ will provide sufficient flexibility and
|> portability of code. ...
I must say that I don't see any contradiction between this and the EC++
movement; in fact, IMHO, the last sentence more or less implies the
existance of suitable proper subsets, EC++ is one of these.
Might I add that this whole thing is getting a little out of hand. Like
many programmers of my generation, one of the most influencial texts on
my programming was Kernighan and Plauger's "Programming Tools". I also
have great admiration for the work Nathan has done in the standard's
committee ; following a short discussion in the French newsgroup, I
actually tried to trace back the sources, and realized just how original
and important it is. I think that the C++ community at large owns them
both a great debt, and it pains me to see them bickering about something
that is, in fact, not that important. In the end, if the customers want
EC++, it will take place, even if Plauger where not there behind it.
And if they don't it will disappear. I come from an ebedded programming
background, and I find that the EC++ has some value, even if it isn't
directly relevant to the programming I'm doing now. I can understand
Nathan's arguments, however, even if I don't agree with the, and I don't
think less of him because we happen to disagree on this one point (or
our opinions about certain compilers, which also depends on the position
from which we are coming).
I'm not going to say any more concerning this, or the compilers, because
I get the impression that the discussion has already descended to a
level where we are not listening to the technical arguments the other
side is presenting; I'm probably as much to blame as others, but I think
it would be a good moment to simply drop the topics until the emotion
has died down.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/05/31 Raw View
P.J. Plauger<pjp@plauger.com> wrote:
> ... given current compiler technology, I can't see how to come close
>to matching the efficiencies of the EC++ library by optimizing the
>full C++ library -- not for years to come, in fact.
Most of the appeal of the EC++ crippled library is based on the
lack of one minor pre-linker optimization. This optimization
(as has been demonstrated) takes just a few days' work to implement.
Only a misled customer would ask a vendor for a crippled library
in place of that optimization, not least because a crippled library
helps avoid bloat from that one library but does not help with any
other libraries.
P.J. Plauger<pjp@plauger.com> wrote this, too:
>It is the *specification* mandated by the FDIS that causes the
>library to bloat, far more than the putative shortcomings of
>current compiler technology.
Now, *this* is profoundly untrue. (Furthermore, P.J. knows it
is untrue even as he writes it.) The FDIS does not require any
compiler to link in any function whose name isn't mentioned in a
program. Period. A vendor who pointed to the FDIS as the cause
of its bloat would be profoundly dishonest. (A good answer would
be: "We don't have that optimization yet because we've been busy
with other things. How important is it to you?" Do ask.)
The design of the entire Standard C++ Library (not just locale) was
optimized for mature compilers. Where mature compilers are not yet
available, engineers rely on temporary expedients. Different
expedients are appropriate for different circumstances. To enshrine
one such expedient as a rattletrap Standard would be profoundly
foolish. (ISO/ANSI will not be so foolish.)
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/05/31 Raw View
Nathan Myers <ncm@nospam.cantrip.org> wrote in article
<6kq9mb$ieh$1@shell7.ba.best.com>...
> P.J. Plauger<pjp@plauger.com> wrote:
> > ... given current compiler technology, I can't see how to come close
> >to matching the efficiencies of the EC++ library by optimizing the
> >full C++ library -- not for years to come, in fact.
>
> Most of the appeal of the EC++ crippled library is based on the
> lack of one minor pre-linker optimization. This optimization
> (as has been demonstrated) takes just a few days' work to implement.
Amusing. It has been well known since C++ was born that unused
virtual member functions get dragged in by the vtable. Compiler vendors
have had over a decade (since C++ became at all popular) to do
something about it. Why haven't they? I can think of at least two reasons,
neither of which is nefarious:
a) It isn't quite as easy as it sounds. As I recall, the recent discussion
ran down after a few comments of the form, ``Oh yes, I forgot that part.''
And *nobody* responded to Pete Becker's repeated request for the
name of one single commercial product that has this ``minor pre-linker
optimization.'' So we have no data on how much it will really help when
it finally comes along.
b) Until recently, the optimization wasn't all that important. Most good
programmers know to minimize the use of virtuals, certainly in code
that gets used a lot. It was not until Standard C++ came along that
we found ourselves with a library that is awash with unused virtuals.
Every stream object, including cin and cout, stores a locale object.
The default locale object stores references to 28 (count 'em) facets.
Each facet has several virtual member functions, for a grand total of
well over 100 functions, by my quick count. A typical program uses
maybe ten of these.
Now we *really* need to optimize away unused virtuals. We also need
to optimize away unused facets, which is a whole 'nother matter. But
even if we do, all the superstructure that goes with locales and facets
still adds to code bloat. Class istream can no longer just read and convert
an integer. It must call a facet member function, which in turn calls a
protected virtual (on the off chance that a sophisticated user will derive
from the facet, override the virtual, concoct a new locale object, and
imbue that object into the stream). It must also construct two iterators
to serve as glue between the facet and the underlying stream buffer.
And so on and so on.
Understand, this is powerful machinery, based on a clever design.
But it does violence to an oft-neglected design goal of C++ that you
only pay for what you use. That's what I mean when I say that the
cost is intrinsic to the specification, not just a limitation of current
compiler technology.
> Only a misled customer would ask a vendor for a crippled library
> in place of that optimization, not least because a crippled library
> helps avoid bloat from that one library but does not help with any
> other libraries.
Hmm. I have heard Stroustrup, on several occasions now, say that
he favors a version of the library that supports only one locale, and
streams only of type char, as a way to avoid the obvious inefficiencies
of the full C++ library. THIS IS THE ESSENCE OF THE EC++
LIBRARY DESIGN. I couldn't possibly characterize him as a misled
customer.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/06/01 Raw View
Nathan Myers <ncm@nospam.cantrip.org> wrote in article
<6kq9mb$ieh$1@shell7.ba.best.com>...
> P.J. Plauger<pjp@plauger.com> wrote:
> Now, *this* is profoundly untrue. (Furthermore, P.J. knows it
> is untrue even as he writes it.)
Watch it.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ mod note:
First, I must apologize for approving the post quoted above.
The newsgroup charter says "no personal attacks", and the
quoted section falls into that category.
Second, this thread has been rather heated, which is not
necessarily bad, but we have gotten to the point where some
are accusing others of bad faith. It is possible for honest
people to disagree honestly, and I believe that is the case
here, since I am fortunate enough to know all the people
involved personally. They are all very smart and talented
programmers with years of experience in complex systems.
The other moderators and I have agreed to reject posts that
stray over the line of technical discussion into personal
references on this thread in particular.
-sdc ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/01 Raw View
P.J. Plauger<pjp@dinkumware.com> wrote:
>Nathan Myers <ncm@nospam.cantrip.org> wrote in article
><6kq9mb$ieh$1@shell7.ba.best.com>...
>>
>> Most of the appeal of the EC++ crippled library is based on the
>> lack of one minor pre-linker optimization. This optimization
>> (as has been demonstrated) takes just a few days' work to implement.
>
> Amusing. It has been well known since C++ was born that unused
> virtual member functions get dragged in by the vtable.
It has been equally well-known that these functions are dead code,
and subject to elimination like any dead code.
> Compiler vendors
> have had over a decade (since C++ became at all popular) to do
> something about it. Why haven't they? I can think of at least two
> reasons, neither of which is nefarious:
The real reason is hasn't been implemented much is simple: most current
compilers depend on the regular C linker, with a "pre-linker" to jimmy
things to fit. (a) and (b), presented below, are entirely spurious.
> a) It isn't quite as easy as it sounds.
> As I recall, the recent discussion ran down after a few
> comments of the form, ``Oh yes, I forgot that part.''
The discussion was whether standard ELF linkers could do it already,
with only changes in the compiler. Fergus Henderson concluded it
would "require an extension to the ELF object file format." In other
words, it depends on a (pre-)linker extension. (No surprise, there.)
> And *nobody* responded to Pete Becker's repeated request for the
> name of one single commercial product that has this ``minor pre-linker
> optimization.'' So we have no data on how much it will really help when
> it finally comes along.
I noticed a report that Symantec had this optimization, in addition
to Richard Henderson's implementation (due out soon). (How many times
must it be implemented before it's counted as possible?)
> b) Until recently, the optimization wasn't all that important. Most
> good programmers know to minimize the use of virtuals, certainly in
> code that gets used a lot. It was not until Standard C++ came along
> that we found ourselves with a library that is awash with unused
> virtuals.
Does PJ *really* mean to suggest that only the standard library makes
any substantial use for virtual functions? This really is a remarkable
statement.
Use of advanced features in the standard library has already had a
salutary effect on compilers; when the STL was adopted all existing
compilers would crash trying to compile it. Nobody (sane) argued
for a crippled STL just so compilers would not need to improve.
>> Only a misled customer would ask a vendor for a crippled library
>> in place of that optimization, not least because a crippled library
>> helps avoid bloat from that one library but does not help with any
>> other libraries.
>
> Hmm. I have heard Stroustrup, on several occasions now, say that
> he favors a version of the library that supports only one locale, and
> streams only of type char, as a way to avoid the obvious inefficiencies
> of the full C++ library. THIS IS THE ESSENCE OF THE EC++
> LIBRARY DESIGN. I couldn't possibly characterize him as a misled
> customer.
Stroustrup has already spoken out, in print, against EC++ and
its dubious "ESSENCE".
I doubt he appreciates having his name dragged in to support it
over his specific objections. Here is his quote:
"What could a group do to make C++ more effective ... ?
... Popularize implementation techniques ... that are efficient in
time and space. Lobby for ... efficient implementations of the
standard library and, where necessary, subsets thereof." Further:
"Only the ability of individual organizations to pick suitable
proper subsets ... will provide sufficient flexibility." [1]
Stroustrup is not misled: he favors efficient implementations and,
failing that, expedient subsets (plural). This does not imply any
support for blessing one such subset as a desirable alternative
to an efficient implementation, and particularly not for the subset
promoted by EC++.
-------
[1] From Embedded System Programming (Miller-Freeman), April 1998, p.10
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mark Williams <markw@silicon-spice.com>
Date: 1998/06/02 Raw View
P.J. Plauger wrote:
> Nathan Myers <ncm@nospam.cantrip.org> wrote in article
> <6kq9mb$ieh$1@shell7.ba.best.com>...
> > P.J. Plauger<pjp@plauger.com> wrote:
> > > ... given current compiler technology, I can't see how to come close
> > >to matching the efficiencies of the EC++ library by optimizing the
> > >full C++ library -- not for years to come, in fact.
> >
> > Most of the appeal of the EC++ crippled library is based on the
> > lack of one minor pre-linker optimization. This optimization
> > (as has been demonstrated) takes just a few days' work to implement.
>
> Amusing. It has been well known since C++ was born that unused
> virtual member functions get dragged in by the vtable. Compiler vendors
> have had over a decade (since C++ became at all popular) to do
> something about it. Why haven't they? I can think of at least two reasons,
> neither of which is nefarious:
>
This argument just doesnt hold water. Look at the (*MUCH* simpler) problem of
dead stripping normal functions/data, and how many linkers fail to implement
that (and how long the vendors have had to implement it!). Its been a standard
feature on the Mac for 10 years or more, but I was recently horrified to find
that unix linkers just dont do it at all. The best you get is dead file
stripping, and then only if the file is a part of a library. It seems that
unix has such good demand paged virtual memory that nobody cares about the size
of the executable...
Now that really _is_ a trivial problem to solve... I added an option to the gnu
linker in a couple of hours to strip any unreferenced functions/data regardless
of the file/library structure.
So its hardly surprising that a problem which could take a couple of weeks to
solve, and requires collaboration between the compiler writers & linker writers
is not yet in widespread use...
Incidently, this reminds me of a related, and only slightly harder problem to
solve, which is to identify "most derived" virtual function calls, and convert
them to direct dispatch (better still, inline them... but I dont see that
happening at the linker stage for a while :-) Again, something that could
easily be achieved, but which doesnt seem to have received any attention
outside of research.
Mark Williams
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/06/02 Raw View
In article <6ktuvv$5iq$1@shell7.ba.best.com>, Nathan Myers
<ncm@nospam.cantrip.org> writes
>P.J. Plauger<pjp@dinkumware.com> wrote:
>Stroustrup has already spoken out, in print, against EC++ and
>its dubious "ESSENCE".
>
>I doubt he appreciates having his name dragged in to support it
>over his specific objections. Here is his quote:
>
> "What could a group do to make C++ more effective ... ?
> ... Popularize implementation techniques ... that are efficient in
> time and space. Lobby for ... efficient implementations of the
> standard library and, where necessary, subsets thereof." Further:
> "Only the ability of individual organizations to pick suitable
> proper subsets ... will provide sufficient flexibility." [1]
>
This is the crux for me, I will need to use various parts of C++ on a
per project basis and I do not want compiler vendors to have a fig leaf
to hide behind when they state that they do not support a feature that I
need to use.
It seems to me that the only argument for not supporting a feature of
C++ *at all* (as opposed to supporting it inefficiently) is that you
can't be bothered to implement it.
If you can be bothered to implement it then do so and supply Johnny
Punter with #pragmas for the cases where the overhead might be an
insupportable burden.
I speak as a consumer of programming languages, not a producer.
Cordially,
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/06/02 Raw View
In article <01bd8cdd$39b0efc0$8a1ec2d0@porky>,
"P.J. Plauger" <pjp@dinkumware.com> wrote:
> Understand, this is powerful machinery, based on a clever design.
> But it does violence to an oft-neglected design goal of C++ that you
> only pay for what you use. That's what I mean when I say that the
> cost is intrinsic to the specification, not just a limitation of current
> compiler technology.
Just to make it clear what we are talking about:
Most of my work today is on workstations, and in an international
environment -- I used setlocale intensively, and found it wanting
in many cases. On paper, the new locale seems perfect, and what
little I've been able to try has confirmed my impressions. For
my work today, pulling in a couple of 100 K or more in the link
phase is a small price to pay for these facilities. Especially as
it is virtual memory anyway, and won't even get loaded if I don't
touch the page.
In the past, however, I've also worked on real embedded systems, without
disk and with limited ROM. The only user output was for debugging
and configuration purposes -- even the French accept that this can
be in American English. On such systems, locale is an unacceptable
space overhead, even with the best theoretical optimizations (which
aren't available yet). And pulling in locale simply because I have
a user dialog to configure an EEPROM more or less means that I will
have to use FILE* instead of iostream. (Just to situate things:
my last project of this nature had 16K PROM. No more.)
There's nothing new about "crippling" libraries; in C, most of the
libraries for such platforms didn't support floating point in printf;
for that matter, even the early PC C's required a compiler option
to support it. So why all the noise about EC++? In what way is it
different?
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/06/02 Raw View
In article <6kq9mb$ieh$1@shell7.ba.best.com>,
ncm@nospam.cantrip.org (Nathan Myers) wrote:
> The design of the entire Standard C++ Library (not just locale) was
> optimized for mature compilers.
I was going to drop this thread, but I can't resist here: the number
of new features adopted by the standards committee is enough to ensure
that we don't have mature compilers for the next few years. (I
suppose that it depends on what you mean by mature -- as a minimum,
I would think that there would be no new added features since about
five years, or at least not major ones.)
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/06/02 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> wrote in article
<SzUF4FAdGxc1EwdW@noco.demon.co.uk>...
> It seems to me that the only argument for not supporting a feature of
> C++ *at all* (as opposed to supporting it inefficiently) is that you
> can't be bothered to implement it.
> If you can be bothered to implement it then do so and supply Johnny
> Punter with #pragmas for the cases where the overhead might be an
> insupportable burden.
I quite agree. Dinkumware supplies a Standard C++ library that fully
complies
with the FDIS. It has been shipping for months. We also supply the proper
subset library required by Embedded C++. It has been shipping for well over
a year. Take your pick.
There has been some discussion of EC++ *as a language dialect* that
intentionally omits features that are not widely implemented. Ironically,
the most widely used front end for EC++ compilers is the full-featured
front end from EDG. Other companies that now advertise EC++
*language* support -- Metrowerks and Cygnus -- do so by adding
compiler switches to reasonably complete C++ compilers. So the
reality is that the EC++ *language* is used to turn off compiler features,
such as exception handling, where the overhead might be an insupportable
burden.
I actually generate both the full C++ library and the EC++ library from the
same baseline. It's all done with edit scripts, but the basic conditional
machinery is the same as #ifdef logic.
Whether it's #pragmas, compiler switches, or #ifdefs, we're talking about
the age-old practice of applying pragmatic extensions to a
standard-conforming compiler and library, to meet the more stringent
performance needs of a community of developers. This ain't rocket science,
and it ain't a rebellion against the C++ Standard.
Embedded C++ differs from past practice in one significant respect --
it has been developed by a consortium of (mostly Japanese) vendors as
a voluntary industry standard for embedded systems development. Many
of us would welcome even a de facto standard for: name mangling, DLLs,
IDEs, GUIs, <your API here>. Why not one for high-performance C++?
> I speak as a consumer of programming languages, not a producer.
Quite rightly. And I speak as a producer who has no business unless
enough consumers are happy.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/02 Raw View
<jkanze@otelo.ibmmail.com> wrote:
>In article <01bd8cdd$39b0efc0$8a1ec2d0@porky>,
> "P.J. Plauger" <pjp@dinkumware.com> wrote:
>
>> Understand, this is powerful machinery, based on a clever design.
>> But it does violence to an oft-neglected design goal of C++ that you
>> only pay for what you use. That's what I mean when I say that the
>> cost is intrinsic to the specification, not just a limitation of current
>> compiler technology.
>
>There's nothing new about "crippling" libraries; in C, most of the
>libraries for such platforms didn't support floating point in printf;
>for that matter, even the early PC C's required a compiler option
>to support it. So why all the noise about EC++? In what way is it
>different?
This is a valid question. Nobody has objected to anybody writing or
selling non-standard subsets of any standard library, C or C++. The
objection to EC++ as a "standard" is that the rationale for standardizing
it is seriously flawed:
1. The overheads it is supposed to avoid can be better avoided by
improved compiler and library implementation techniques.
(A library subset avoids certain overheads for that one library,
but does not help with such overheads in other, user, libraries.)
2. The language subset EC++ represents is a poor match not only for
real user requirements, but also for the real overheads one
encounters with current compilers. For example, EC++ lacks
templates even though in typical implementations templates
impose no overhead and (indeed) are a key tool for user-level
optimization. EC++ has no support for namespaces, despite
that these cannot cause any overhead even in the most naive
implementation.
3. Standardizing a single subset ignores the needs of everyone who
needs any of the features omitted, or who has no need for many
of the features included. It's a procrustean bed.
We all use temporary expedients to work around problems, but to
standardize such an expedient actually stalls progress on the
real problem: immature implementations of the Standard.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/06/03 Raw View
Nathan Myers wrote:
>
> 3. Standardizing a single subset ignores the needs of everyone who
> needs any of the features omitted, or who has no need for many
> of the features included. It's a procrustean bed.
Apparently Nathan thinks that if the ANSI/ISO committee adopts EC++ it
is thereby prevented from adopting any other subset. The committee is,
of course, free to make such a decision, but nobody has proposed such a
thing, and I doubt very much that anyone will.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/06/03 Raw View
P.J. Plauger<pjp@dinkumware.com> wrote:
>EC++ ... has been developed by a consortium of (mostly Japanese)
>vendors as a voluntary industry standard for embedded systems development.
>Many of us would welcome even a de facto standard for: name mangling,
>DLLs, IDEs, GUIs, <your API here>. Why not one for high-performance C++?
There is no possible objection to a good de-facto standard for
high-performance C++. However, EC++ is not it. The first criterion
of the EC++ design is hobbled language features (regardless of
performance impact), with performance a distant second.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: tony@ns.cook.ml.org (Tony Cook)
Date: 1998/06/04 Raw View
P.J. Plauger (pjp@dinkumware.com) wrote:
: a) It isn't quite as easy as it sounds. As I recall, the recent discussion
: ran down after a few comments of the form, ``Oh yes, I forgot that part.''
: And *nobody* responded to Pete Becker's repeated request for the
: name of one single commercial product that has this ``minor pre-linker
: optimization.'' So we have no data on how much it will really help when
: it finally comes along.
Someone did respond. In message <35640E53.C9A@aks.com> Eyal Ben-David
mentioned that Watcom C/C++ supports this feature (in version 11.0).
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/06/05 Raw View
Tony Cook wrote:
>
> P.J. Plauger (pjp@dinkumware.com) wrote:
> : a) It isn't quite as easy as it sounds. As I recall, the recent discussion
> : ran down after a few comments of the form, ``Oh yes, I forgot that part.''
> : And *nobody* responded to Pete Becker's repeated request for the
> : name of one single commercial product that has this ``minor pre-linker
> : optimization.'' So we have no data on how much it will really help when
> : it finally comes along.
>
> Someone did respond. In message <35640E53.C9A@aks.com> Eyal Ben-David
> mentioned that Watcom C/C++ supports this feature (in version 11.0).
His statement was pretty weak - it started with "AFAIK". I posted a
simple test program earlier in this thread; does it compile to the same
size both ways under Watcom C/C++?
Removing unused virtual function calls is a technically more complicated
task than ordinary dead-function analysis. It's been claimed that it
cannot be done within the tradition link model. The few people who've
responded to Pete's challenge have given the impression they didn't
understand the full implications of that distinction.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "David J. Littleboy" <davidjl@gol.com>
Date: 1998/06/05 Raw View
Nathan Myers wrote in message <6l1olm$kor$1@shell7.ba.best.com>...
>The
>objection to EC++ as a "standard" is that the rationale for standardizing
>it is seriously flawed:
>
> 1. The overheads it is supposed to avoid can be better avoided by
> improved compiler and library implementation techniques.
> (A library subset avoids certain overheads for that one library,
> but does not help with such overheads in other, user, libraries.)
This appears to ignore the locale problem, and others have pointed out the
naivete of expecting compiler vendors to get it right in time to be usefull.
> 2. The language subset EC++ represents is a poor match not only for
> real user requirements, but also for the real overheads one
> encounters with current compilers. For example, EC++ lacks
> templates even though in typical implementations templates
> impose no overhead and (indeed) are a key tool for user-level
> optimization. EC++ has no support for namespaces, despite
> that these cannot cause any overhead even in the most naive
> implementation.
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1998/05/22 Raw View
Oleg Zabluda <zabluda@math.psu.edu> writes:
|> Pete Becker <petebecker@acm.org> wrote:
|> : Fortunately, most members of the ISO/ANSI committee have not
|> : prejudged this issue [EC++ -- O.Z] , and prefer technical
|> : discussions to polemics.
|>
|> I seem to recall that there used to be quite a polemic
|> about EC++ when the effort initialy started. I vaguely
|> remember that the problem was that EC++ was not a strict
|> subset of C++, but mutated some C++ features. I seem to
|> remember very angry posts on the subject from Stroustrup.
|> Fortunately, EC++ people gave in or it seems so. As usual,
|> my memory might be failing me, and I can't find any traces
|> of it on DejaNews, so don't believe any of the above
|> until you get another confirmation.
The language is not a strict subset in the sense that some things,
particularly in the library, are specified differently. It is, and as
far as I can tell, always has been a strict subset in the sense that any
program which conforms to the EC++ standard is also a legal C++ program,
with the same defined semantics.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1998/05/22 Raw View
"greg" <yo@mama.com> writes:
|> > It's both. There is a great deal that the library writer can do to
|> > minimize overhead in the library. That goes for locale, and for a
|> > lot else as well. Yes, some help from the compiler makes it easier,
|> > but pointing fingers (at the standard, or at compilers) is easier yet.
|> >
|> > "Embedded C++", as it's being promoted, is an exercise in just such
|> > finger-pointing. Eventually some consortium members will implement
|> > conforming (even efficient) compilers. Then the official "Embedded C++"
|> > subset will be forgotten, and their customers (like the rest of us)
|> > will be able to use whatever language subset matches their needs,
|> > without need for a special blessing. In the meantime, those vendors
|> > try to make a virtue of having a less-efficient, non-conforming
|> > implementation by slapping on a catchy tag.
|>
|> I agree that there should be no need for an embeddable subset of the
|> C++ language, but it is perfectly reasonable to have an embeddable
|> subset of the C++ library.
There *should* be no need for either. Today, there is a need for both.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1998/05/22 Raw View
ncm@nospam.cantrip.org (Nathan Myers) writes:
|> <jkanze@otelo.ibmmail.com> wrote:
|> >In article <6jbdbm$f1p$1@shell7.ba.best.com>,
|> > ncm@nospam.cantrip.org (Nathan Myers) wrote:
|> >
|> >> "Embedded C++", as it's being promoted, is an exercise in just such
|> >> finger-pointing. ... vendors
|> >> try to make a virtue of having a less-efficient, non-conforming
|> >> implementation by slapping on a catchy tag.
|> >
|> >...
|> >I think that embedded C++ is largely a question of expectations -- we all
|> >know that some features of C++ are more expensive than others, and that
|> >in some applications, this expense is not acceptable.
|>
|> That's precisely the problem, and precisely why this "Embedded C++"
|> is such an oily proposition. On ill-designed implementations, some
|> constructs are far more expensive than necessary. Enshrining those
|> inefficiencies in a spurious "standard" creates disinformation:
|> people will come to believe that only the features retained in
|> that "standard" can be used in applications that are sensitive to
|> overhead.
This is regrettably true. A number of inefficiencies are "standard"
today. In all existing compilers.
No one would like it more than I that all compilers suddenly
miraculously were to be fully compliant, efficient and free from
errors. It's just not going to happen.
|> Those implementers who have done the extra work to make the constructs
|> efficient are penalized, and users suffer from not using the features
|> that would simplify their designs.
Again, I fear you are right. Thus, for example, no major compiler
vendor provides garbage collection, although we know that its absense is
a major problem in writing robust C++ code. And of course, even if a
major compiler vendor did, I couldn't write portable code which depended
on it.
I don't have an answer for this, except to say that that's reality.
There is no perfect solution; EC++ offers an answer to a specific
problem, today.
|> > The idea behind
|> >embedded C++, as I understand it, is to define a subset in which I
|> >have a right to expect efficiency. If I limit myself to this subset,
|> >none of my code should turn out to be unexpectedly expensive on any
|> >platform.
|>
|> That is what they would like you to believe. In fact, it's just
|> a subset that the late-comer implementers already have implemented,
|> regardless of efficiency. For example, the subset omits templates,
|> not because they add any overhead whatsoever, or because they are
|> not incredibly useful in embedded system design, but simply because
|> the consortium members haven't got (and want an excuse not to buy)
|> a good implementation of templates.
There are two aspects involved with embedded computers. One is (space)
efficiency, and I agree that templates are not, per se, a problem here.
(Things like templating iostream might be, but then, most embedded
systems won't use iostream anyway.)
The other is robustness, and to date, I've yet to see an implementation
of templates that really works, much less conforms to the draft
standard. (A number of implementations work "well enough" for many
practical uses, but none have the reliability for the types of
applications I used to do.)
|> >Obviously, if some vendor manages to make a full C++ adequately efficient
|> >for a particular embedded platform, he will have a definite marketing
|> >advantage.
|>
|> This is far from obvious. If a vendor makes an efficient full C++ and
|> finds customers artificially restricting their use of the language to
|> avoid the features they have implemented efficiently, that cancels
|> much of the marketing advantage.
See my comments concerning garbage collection, above. A vendor who
makes a full C++ adequately efficient will have an advantage with
regards to users who can standardize on it. Portability constraints
will still prevent most customers from using anything but the guaranteed
subset.
But how is this different from today, except that the guaranteed subset
is specified by an organisation, rather than being driven by the
unknown. (At least one major portability guide says to not use
templates. At all.)
|> >And equally obviously, there will be vendors who use this as an excuse
|> >not to do the harder job of a full implementation, even when it is, or
|> >should be possible. ... But the fact that vendors can abuse some standard
|> >in order to gain sales position doesn't mean that the standard is bad.
|>
|> The "standard" *is* bad if that is the main reason for its existence.
|> The ISO/ANSI committee is forming a subgroup to discuss the real
|> concerns of real embedded-system builders. This group will help to
|> identify and publicize techniques to allow language features to be
|> implemented without unnecessary overhead. That is a reasonable way
|> to address the problem, rather than cobbling up a phony language
|> subset for embedded-system builders to try to shoehorn themselves
|> into.
There are many reasonable ways to address the problem.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1998/05/22 Raw View
ncm@nospam.cantrip.org (Nathan Myers) writes:
|> <jkanze@otelo.ibmmail.com> wrote:
|> > I think it also worth pointing out
|> >that between the time a vendor decides to use some technology, and the
|> >time it actually is usable in the released version of the vendors
|> >compiler, you should count at least a year.
|>
|> Sorry, James, this is silly. *Some* vendors take forever to do
|> things, others act very quickly. Examples of the latter include
|> KAI (kcc) and Cygnus (egcs). A responsive compiler vendor tends
|> to have other virtues in its favor.
|>
|> You can't generalize from experience with a single vendor.
No, I'm judging from actually having developed large scale systems,
including compilers, myself.
I have no experience with regards to KAI, but I would say that egcs is
exactly a proof of what I am saying: you can have an up to date compiler
(egcs), or you can have a reasonably stable and reliable compiler (g++
2.7.2), but you can't have both in the same product. Egcs (and g++
2.8.0, for that matter) are in the process of recreating the image g++
had three or four years ago (back in the days of the "version of the
day"). An image that made g++ more or less a laughing stock among
people doing serious work.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: herbs@cntc.com (Herb Sutter)
Date: 1998/05/22 Raw View
jkanze@otelo.ibmmail.com wrote:
>IMHO, there is also a second point of EC++. Reliability is a critical
>factor in many embedded systems, and EC++ eliminates some parts of C++
>more on the grounds that we still do not have enough experience in
>compiling them to be sure that they can be implemented reliably. (More
>exactly, we may feel sure that there exists a solution for implementing
>them reliably, but the solution is not generally known, or part of
>standard practice, and of course, experience may show that we were
>wrong to feel so sure of it.)
Just a note: I don't remember this being raised as an issue when the EC++
proposal was made to the committee. The main issues were efficiency (time
and space) and predictability.
---
Herb Sutter (mailto:herbs@cntc.com)
Current Network Technologies Corp 2695 North Sheridan Way, Suite 150
www.cntc.com www.peerdirect.com Mississauga Ontario Canada L5K 2N6
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@plauger.com>
Date: 1998/05/22 Raw View
Oleg Zabluda <zabluda@math.psu.edu> wrote in article
<6k1dvp$cgm@marianna.psu.edu>...
> Pete Becker <petebecker@acm.org> wrote:
> : Fortunately, most members of the ISO/ANSI committee have not
> : prejudged this issue [EC++ -- O.Z] , and prefer technical
> : discussions to polemics.
>
> I seem to recall that there used to be quite a polemic
> about EC++ when the effort initialy started. I vaguely
> remember that the problem was that EC++ was not a strict
> subset of C++, but mutated some C++ features. I seem to
> remember very angry posts on the subject from Stroustrup.
> Fortunately, EC++ people gave in or it seems so. As usual,
> my memory might be failing me, and I can't find any traces
> of it on DejaNews, so don't believe any of the above
> until you get another confirmation.
As is so often the case, this was primarily a misunderstanding. The
initial EC++ Technical Specification, released in September 1996,
was keyed to CD1, released in April 1995. At the time, CD1 was the
nearest thing to an official (albeit preliminary) draft of the C++
Standard.
It was always the clearly stated intention of the EC++ Technical
Committee to track the C++ Standard as it evolved, but that small
piece of information got overlooked in some circles. The accusation
was raised that EC++ would ever be based on CD1.
In fact, the Dinkum EC++ Library -- which is the only commercially
available implementation of the EC++ library to date -- is a proper
subset of the library mandated by the FDIS. No capitulation necessary,
just explanation.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1998/05/22 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> writes:
|> In article <355DD9FB.62F0E0C7@acm.org>, Pete Becker <petebecker@acm.org>
|> writes
|> >Mike Davies wrote:
|> >>
|> >> In article <6jf2eg$ds5$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
|> >> writes:
|> >>
|> >> >I think that embedded C++ is largely a question of expectations -- we all
|> >> >know that some features of C++ are more expensive than others, and that
|> >> >in some applications, this expense is not acceptable.
|> >>
|> >> So don't use these features in your application. The overhead goes away,
|> >> no?
|> >
|> >Sure. Don't use exceptions, don't use multiple inheritance, don't use
|> >iostreams, don't use RTTI, don't use dynamic_cast. ... Pretty soon
|> >you're writing C code. And that's the problem: C++ as it's defined today
|> >can be too big for applications that demand a small memory footprint.
|>
|> No, (once more for the Gipper...) C++ has been designed so that the
|> parts you don't use need carry no overhead. If you use just the parts
|> you need / can afford then you can have the bits of C++ you want and an
|> equivalent footprint to C.
And what are the parts you can afford? How do you know?
If you're just using one compiler, you suggestion is exactly the one I
would adopt. If you aren't sure what compilers you might have to use in
the future, some sort of "official" version of what you can expect to be
able to afford is useful.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@plauger.com>
Date: 1998/05/22 Raw View
Nathan Myers <ncm@nospam.cantrip.org> wrote in article
<6jgedi$aeb$1@shell7.ba.best.com>...
> Pablo Halpern<phalpern@truffle.ma.ultranet.com> wrote:
> >ncm@nospam.cantrip.org (Nathan Myers) wrote:
>
> Most participants in the Embedded C++ consortium are not liars.
Glad to hear that. Which of us, specifically, *are*?
> But much of what has been published has implied that they were
> selling incomplete implementations to avoid imposing a mythical
> "unavoidable overhead", where in fact they are selling incomplete
> implementations mainly because that's all they have to sell.
This is profoundly untrue. The best case in point is Green Hills Software,
a
major vendor of embedded C++ compilers for multiple platforms. They license
the EDG front end, which arguably supplies the most complete implementation
of the Standard C++ language available on the market today. They also
license
the Dinkum libraries -- all of them. The Dinkum C++ Library is arguably the
most
complete implementation of the Standard C++ librar available on the market
today. It matches the FDIS already, at least with EDG 2.38 or a similarly
advanced compiler.
Why then does GHS see fit to also license the Dinkum EC++ Library
and the Dinkum Abridged Library (EC++ with STL)? Because they are useful
options for their customers. In a separate posting to this reflector, I
outlined
some of the techniques I've brought to bear to mitigate the large overheads
caused by locale objects in the full C++ library. I've worked hard for
years
to make that product efficient, and I will continue to do so. But given
current
compiler technology, I can't see how to come close to matching the
efficiencies
of the EC++ library by optimizing the full C++ library -- not for years to
come,
in fact. It is the *specification* mandated by the FDIS that causes the
library
to bloat, far more than the putative shortcomings of current compiler
technology.
So should GHS focus on making their back end and tool chain more efficient?
You bet. And they're doing so, continually. But neither they nor their
customers
are going to wait for pie in the sky by and by, not when a pragmatic useful
solution is available off the shelf today. Not while those unavoidable
overheads
remain far from mythical.
EC++ is *not* all that Green Hills has to sell. Yet they choose to sell it,
alongside
one of the best implementations of the FDIS you can buy right now today.
And
their customers are happily buying both, from what I hear.
> The lie harms those who implement the full language and avoid the
> mythical "unavoidable overhead". It harms those who believe the
> myth and unnecessarily shoehorn their designs into a language subset
> arbitrarily chosen by compiler vendors for their own convenience.
>
> Overhead is a real problem on many implementations, but the techniques
> to eliminate it are not terribly difficult, and are entirely compatible
> with the full standard language. Some of the best and simplest (e.g.
> eliminating virtual functions that cannot be called) don't appear in
> the compilers sold by "Embedded C++" vendors. This demonstrates their
> true nature.
I read this as saying, ``Any compiler vendor who claims to generate
efficient code
but fails to remove uncalled virtual functions from an executable image is
a liar.''
I hope that's my misunderstanding, because it doesn't leave very many truth
tellers in the world of commercial C++ compiler vendors.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/22 Raw View
Herb Sutter wrote:
>
> jkanze@otelo.ibmmail.com wrote:
> >IMHO, there is also a second point of EC++. Reliability is a critical
> >factor in many embedded systems, and EC++ eliminates some parts of C++
> >more on the grounds that we still do not have enough experience in
> >compiling them to be sure that they can be implemented reliably. (More
> >exactly, we may feel sure that there exists a solution for implementing
> >them reliably, but the solution is not generally known, or part of
> >standard practice, and of course, experience may show that we were
> >wrong to feel so sure of it.)
>
> Just a note: I don't remember this being raised as an issue when the EC++
> proposal was made to the committee. The main issues were efficiency (time
> and space) and predictability.
Well then, James has a lot of nerve bringing it up at this late date.
<g> Seriously, the committee's discussion of this question has not begun
yet. I'm sure there will be many new points brought up in the course of
the discussion. That's why it's important not to prejudge this issue.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/05/22 Raw View
J. Kanze wrote:
>
> ncm@nospam.cantrip.org (Nathan Myers) writes:
>
> |> <jkanze@otelo.ibmmail.com> wrote:
> |> > I think it also worth pointing out
> |> >that between the time a vendor decides to use some technology, and the
> |> >time it actually is usable in the released version of the vendors
> |> >compiler, you should count at least a year.
> |>
> |> Sorry, James, this is silly. *Some* vendors take forever to do
> |> things, others act very quickly. Examples of the latter include
> |> KAI (kcc) and Cygnus (egcs). A responsive compiler vendor tends
> |> to have other virtues in its favor.
> |>
> |> You can't generalize from experience with a single vendor.
>
> No, I'm judging from actually having developed large scale systems,
> including compilers, myself.
>
> I have no experience with regards to KAI, but I would say that egcs is
> exactly a proof of what I am saying: you can have an up to date compiler
> (egcs), or you can have a reasonably stable and reliable compiler (g++
> 2.7.2), but you can't have both in the same product. Egcs (and g++
> 2.8.0, for that matter) are in the process of recreating the image g++
> had three or four years ago (back in the days of the "version of the
> day"). An image that made g++ more or less a laughing stock among
> people doing serious work.
While egcs certainly works this way (the 'e' stands for experimental!),
I don't see that for g++ 2.8.0 (how long did it take to get that out?).
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/05/24 Raw View
Matt Austern wrote:
>
> Pete Becker <petebecker@acm.org> writes:
>
> > Matt Austern wrote:
> > >
> > >
> > > It's not a terribly esoteric optimization: it's just straightforward
> > > dead function elimination in the inter-procedural analysis phase.
> > > Compilers that do inter-procedural analysis (yes, even across the
> > > translation unit boundary) aren't so hard to come by anymore.
> >
> > As I keep asking, give me a reference to a commercially available
> > compiler that does this reliably and efficiently.
>
> Compilers that do interprocedural analysis and dead function
> elimination? Lots of them. SGI's compiler has had interprocedural
> analysis for years, and I don't think we have the only good compiler
> on the planet.
I'm working on an SGI machine, and I have access to a program named c++,
which is not the same as the g++ that I also have access to. I don't
know how to tell whether or not it's SGI's compiler. I don't know what
version it is, except that it apparantly doesn't have a fully up-to-date
implementation: It had to use <iostream.h> instead of <iostream>. I
wrote the following test code:
virtual.h:==============================================
#ifndef VIRTUAL_H
#define VIRTUAL_H
class B{
public:
virtual int doit() { return 0; }
};
class D: public B {
int doit();
};
#endif
========================================================
virtual.cpp:============================================
#include "virtual.h"
#ifdef BIG
#include <iostream.h>
#endif
int D::doit(){
#ifdef BIG
cout << "Hello World!";
#endif
return 1;
}
========================================================
virtest.cpp: ===========================================
#include <cstdlib>
#include "virtual.h"
int main(void)
{
D d;
// some code to force it to actually create d:
return &d != NULL ? EXIT_SUCCESS : EXIT_FAILURE;
}
========================================================
The command:
c++ virtest.cpp virtual.cpp -o virtest
produced a 13852 byte executable. The command
c++ -DBIG virtest.cpp virtual.cpp -o virtest
produced a 238688 byte executable. It doesn't look to me like it's
eliminating the unused virtual function doit(). Does anyone have a
compiler which produces the same size executable in both cases?
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/19 Raw View
Fergus Henderson wrote:
>
>
> ELF already has "weak references": a compiler can spit out a weak
> reference to a symbol, and the linker will fill it with NULL if the
> symbol's value is not used elsewhere, or with the symbol's value, if
> there are some "strong" references to the symbol.
>
> ELF also allows multiple sections, including user-defined ones.
>
> So all the compiler needs to do is as follows:
>
> - For each class, generate a link unit containing a vtable
> definition in the read-only data section; in each vtable
slot
> of such definitions, generate a weak reference to the
> corresponding virtual function.
>
> - For each class C, for each virtual function F, generate a
> link unit containing a vtable-slot entry in the
> "vtable_slots_for__C__F" section; this entry should contain
a
> strong reference to the function F that occupies that slot.
> Similarly, for each direct or indirect base class B from
> which C is derived, generate a link unit containing a
> vtable-slot entry in the "vtable_slots_for__B__F" section.
>
> - For each virtual function call which cannot be resolved
> statically, generate (in the same link unit) an entry in
the
> "vtable_slot_references" section which contains a strong
> reference to the corresponding vtable-slot section.
>
> This will force the vtable-slot entries for that class and slot to be
> linked in whenever the virtual function call is linked in, which will
> in turn force the corresponding vtable-slot entries for all derived
> classes to also be linked in. These vtable-slot entries will will
> force the corresponding virtual functions to be linked in. And that
> will ensure that the weak references in the vtables get filled in with
> the correct values.
It's not clear to me how this pulls in virtual functions in derived
classes where the only call to the virtual function is through a
reference or pointer to the base. I can see how that might be done,
provided the linker also supports "reverse causality". That is, in the
traditional compile and link cycle, the compiler knows which external
functions a given function uses, so it can generate records that say
"here's the code for f, and it needs g and h". That can get you the base
class versions, 'cause that's information that the compiler has when it
compiles a function. To get derived class functions you need the
additional capability to say, independently from the definition of f,
"when you link in f you also need to link in g and h". That's probably
doable, but it's not trivial, and it's significantly different from
"what the linker does anyway", which is the assertion that I objected to
in the first place.
In any event, I come back to my original point: EC++ exists today, and
several compiler vendors support it. What compiler products support this
proposed technique today or will support it in the near future?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/19 Raw View
Matt Austern wrote:
>
>
> It's not a terribly esoteric optimization: it's just straightforward
> dead function elimination in the inter-procedural analysis phase.
> Compilers that do inter-procedural analysis (yes, even across the
> translation unit boundary) aren't so hard to come by anymore.
As I keep asking, give me a reference to a commercially available
compiler that does this reliably and efficiently.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Matt Austern <austern@sgi.com>
Date: 1998/05/19 Raw View
Pete Becker <petebecker@acm.org> writes:
> Matt Austern wrote:
> >
> >
> > It's not a terribly esoteric optimization: it's just straightforward
> > dead function elimination in the inter-procedural analysis phase.
> > Compilers that do inter-procedural analysis (yes, even across the
> > translation unit boundary) aren't so hard to come by anymore.
>
> As I keep asking, give me a reference to a commercially available
> compiler that does this reliably and efficiently.
Compilers that do interprocedural analysis and dead function
elimination? Lots of them. SGI's compiler has had interprocedural
analysis for years, and I don't think we have the only good compiler
on the planet.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: fjh@cs.mu.OZ.AU (Fergus Henderson)
Date: 1998/05/20 Raw View
Matt Austern <austern@sgi.com> writes:
>It's not a terribly esoteric optimization:
Agreed.
>it's just straightforward
>dead function elimination in the inter-procedural analysis phase.
Here I don't agree. Eliminating virtual functions that aren't
called is more difficult than eliminating ordinary functions
that aren't called. Not exceptionally difficult, but more difficult.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/20 Raw View
Matt Austern wrote:
>
> Compilers that do interprocedural analysis and dead function
> elimination?
No, compilers that eliminate unused virtual functions.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/05/20 Raw View
Pete Becker wrote:
>
> Fergus Henderson wrote:
> >
> >
> > ELF already has "weak references": a compiler can spit out a weak
> > reference to a symbol, and the linker will fill it with NULL if the
> > symbol's value is not used elsewhere, or with the symbol's value, if
> > there are some "strong" references to the symbol.
> >
> > ELF also allows multiple sections, including user-defined ones.
> >
> > So all the compiler needs to do is as follows:
> >
> > - For each class, generate a link unit containing a vtable
> > definition in the read-only data section; in each vtable
> slot
> > of such definitions, generate a weak reference to the
> > corresponding virtual function.
> >
> > - For each class C, for each virtual function F, generate a
> > link unit containing a vtable-slot entry in the
> > "vtable_slots_for__C__F" section; this entry should contain
> a
> > strong reference to the function F that occupies that slot.
> > Similarly, for each direct or indirect base class B from
> > which C is derived, generate a link unit containing a
> > vtable-slot entry in the "vtable_slots_for__B__F" section.
> >
> > - For each virtual function call which cannot be resolved
> > statically, generate (in the same link unit) an entry in
> the
> > "vtable_slot_references" section which contains a strong
> > reference to the corresponding vtable-slot section.
> >
> > This will force the vtable-slot entries for that class and slot to be
> > linked in whenever the virtual function call is linked in, which will
> > in turn force the corresponding vtable-slot entries for all derived
> > classes to also be linked in. These vtable-slot entries will will
> > force the corresponding virtual functions to be linked in. And that
> > will ensure that the weak references in the vtables get filled in with
> > the correct values.
>
> It's not clear to me how this pulls in virtual functions in derived
> classes where the only call to the virtual function is through a
> reference or pointer to the base. I can see how that might be done,
> provided the linker also supports "reverse causality". That is, in the
> traditional compile and link cycle, the compiler knows which external
> functions a given function uses, so it can generate records that say
> "here's the code for f, and it needs g and h". That can get you the base
> class versions, 'cause that's information that the compiler has when it
> compiles a function. To get derived class functions you need the
> additional capability to say, independently from the definition of f,
> "when you link in f you also need to link in g and h". That's probably
> doable, but it's not trivial, and it's significantly different from
> "what the linker does anyway", which is the assertion that I objected to
> in the first place.
> In any event, I come back to my original point: EC++ exists today, and
> several compiler vendors support it. What compiler products support this
> proposed technique today or will support it in the near future?
Does ELF have a concept of "two-component" links, that is, links
which are weak, but "harden" if both types of link are encountered?
If yes, the problem is simple to solve:
1. Each derived class virtual function overriding a base class virtual
function adds to the base class vtbl slot section a weak link of
type 1 to the derived class vtbl slot section.
2. Each derived class vtbl section contains a weak link of type 2
to each of its vtbl slots.
Now, a virtual function is included exactly if
1. The virtual function is called on the class or one of it's bases
through the vtbl slot, and
2. The virtual table itself is referenced (which happens as soon
as an object of that type is constructed).
(Of course the virtual function is included as well if there's
a direct reference to it, like through qualified call).
This way, all used virtual functions are guaranteed to be included
(since they all have an object instatiated, and they all have either
the according virtual slot or the function itself referenced). However,
virtual functions are not included if either there isn't a reference
to the class, or there isn't a reference to the virtual function
in the hierarchy.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/05/20 Raw View
In article <35618AD6.8C06A6A4@acm.org>,
Pete Becker <petebecker@acm.org> wrote:
> In any event, I come back to my original point: EC++ exists today, and
> several compiler vendors support it. What compiler products support this
> proposed technique today or will support it in the near future?
With regards to what Pete is saying, I think it also worth pointing out
that between the time a vendor decides to use some technology, and the
time it actually is usable in the released version of the vendors
compiler, you should count at least a year. Unless, of course, the
vendor prefers releasing without thorough internal testing or beta
tests, in which case, I'd rather not use the compiler in critical
embedded systems.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: rdamon@BeltronicsInspection.com (Richard Damon)
Date: 1998/05/20 Raw View
One question, given
class B {
public:
virtual int foo();
}
class D : public B {
public:
virtual int foo();
}
B* pb;
in module 1:
pb = new D;
in module 2 (having only class B's declaration visible)
pb->foo();
The compiler can generate the reference to B::foo but how does it generate a
reference to D::foo when it has not seen the class, and which might not even
exist yet.
class D would need some why of saying if B::foo is referenced, then consider
D::foo referenced which seems above the ability of most linkers I know.
--
richard_damon@iname.com (Redirector to my current best Mailbox)
rdamon@beltronicsInspection.com (Work Adddress)
Richad_Damon@msn.com (Just for Fun)
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/05/20 Raw View
In article <35601DB3.F4006423@acm.org>,
Pete Becker <petebecker@acm.org> wrote:
>
> James Kuyper wrote:
> >
> > Pete Becker wrote:
> > >
> > > Nathan Myers wrote:
> > > >
> > > > Of course, any implementation can have this optimization; it doesn't
> > > > depend on any restricted subset of the language.
> > >
> > > Of course, no compiler does that today, so if you're stuck trying to
fit
> > > 80k of code into 16k of ROM you may well want a restricted subset of
the
> > > language. Speculation about what might happen at some unspecified time
> > > in the future won't get your product out the door.
> >
> > Neither will suggesting changes to the language standard.
>
> Of course it will. That's the point of the EC++ technical specification:
> it defines a smaller subset which typically results in executables that
> are less than half the size of those produced by the same compiler using
> the full language. (okay, 80k to 16k was a bit of an exaggeration...).
Of course, for any given compiler, you don't need EC++ to do this. You
just experiment, and find out what doesn't result in code bloat for that
compiler.
The real point of EC++ is the expectations it creates: if I only use the
EC++ subset of C++, I have a right to not expect code bloat, even when
I move to a new compiler. In this way, it is somewhat like the C++
standard itself: realistically, until we got the final draft, you could
use new features if they were supported by your particular compiler, but
if you wanted to be portable, all you had a right to expect on some
unknown compiler was the ARM. In the case of features which were being
changed by the committee, you couldn't even count on that. I don't
know of any C++ compiler off-hand that doesn't support templates in
some form, but in order to use them in portable code, you still need a
lot of #ifdef hacking. Now that we have a final draft, however, I have
a right to expect that any new release will do them in a compatible way.
IMHO, there is also a second point of EC++. Reliability is a critical
factor in many embedded systems, and EC++ eliminates some parts of C++
more on the grounds that we still do not have enough experience in
compiling them to be sure that they can be implemented reliably. (More
exactly, we may feel sure that there exists a solution for implementing
them reliably, but the solution is not generally known, or part of
standard practice, and of course, experience may show that we were
wrong to feel so sure of it.)
This last argument sounds somewhat like the criticism that EC++ is to
let implementors who don't know how to do something off the hook. In a
way, it is, although expressing it that way is loaded. The problem is
that most implementors today DON'T know how to do templates, for example,
with what I would consider adequate quality. That's life, and if you
have to write high reliability systems today, it's an aspect you have
to take into account. Vendors implementing EC++ are taking it into
account; rather than giving me a complete system that sometimes introduces
subtle buts, they say straight out: if you want your program to work,
you're going to have to limit yourself to this subset.
Note that most of the problems I'm continually running into result in
compile or link time errors, and not wrong code which makes it into
the production system. And for most systems, the cost of not using the
added features, at least if portability is not an issue, is more than
the cost due to the risk of a code generation error. But I've written
such things as a locomotive brake system -- I can assure you that if I
were writing it today, I would be using EC++, and not the full language.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/05/20 Raw View
In article <355DD9FB.62F0E0C7@acm.org>, Pete Becker <petebecker@acm.org>
writes
>Mike Davies wrote:
>>
>> In article <6jf2eg$ds5$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
>> writes:
>>
>> >I think that embedded C++ is largely a question of expectations -- we all
>> >know that some features of C++ are more expensive than others, and that
>> >in some applications, this expense is not acceptable.
>>
>> So don't use these features in your application. The overhead goes away,
>> no?
>
>Sure. Don't use exceptions, don't use multiple inheritance, don't use
>iostreams, don't use RTTI, don't use dynamic_cast. ... Pretty soon
>you're writing C code. And that's the problem: C++ as it's defined today
>can be too big for applications that demand a small memory footprint.
No, (once more for the Gipper...) C++ has been designed so that the
parts you don't use need carry no overhead. If you use just the parts
you need / can afford then you can have the bits of C++ you want and an
equivalent footprint to C.
If you need to use the features you list in a language like C you will
also pay a price, I think.
>The arrogant answer is "too bad, find something else".
I'd like to point out that that wasn't my answer :-)
>A more
>enlightened one is "let's see what we can do to make C++ more acceptable
>here."
I agree, and what we can do to make C++ more acceptable here is to
educate the individual programmer to use the parts they can afford and
demand improvements from compiler vendors for the parts that have an
overhead.
It is a far more arrogant answer IMO to cripple the language for all
embedded programmers by removing the parts that are harder to implement
properly.
There is no part of C++ that I know of that won't be missed by somebody
if it is left out.
--
Mike Davies
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/20 Raw View
Nathan Myers wrote:
>
>
> Those implementers who have done the extra work to make the constructs
> efficient are penalized,
And what implementers would those be?
> and users suffer from not using the features
> that would simplify their designs.
Yup. The Japanese desparately need to be able to handle Tamil characters
in their rice cookers.
> The ISO/ANSI committee is forming a subgroup to discuss the real
> concerns of real embedded-system builders.
Yes, and one of the things that that subgroup will need to concern
itself with is the real concerns of the real embedded system builders
who developed and use the EC++ specification.
> This group will help to
> identify and publicize techniques to allow language features to be
> implemented without unnecessary overhead.
Maybe, but then again, maybe not. Since the subgroup has not been formed
yet, and the proposed work item hasn't been written yet, much less
discussed, it's quite premature to talk about what the subgroup will or
won't do.
> That is a reasonable way
> to address the problem,
Maybe. Then again, maybe not.
> rather than cobbling up a phony language
> subset for embedded-system builders to try to shoehorn themselves
> into.
Fortunately, most members of the ISO/ANSI committee have not prejudged
this issue, and prefer technical discussions to polemics.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/21 Raw View
Mike Davies wrote:
>
> In article <355DD9FB.62F0E0C7@acm.org>, Pete Becker <petebecker@acm.org>
> writes
> >Mike Davies wrote:
> >>
> >> In article <6jf2eg$ds5$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
> >> writes:
> >>
> >> >I think that embedded C++ is largely a question of expectations -- we all
> >> >know that some features of C++ are more expensive than others, and that
> >> >in some applications, this expense is not acceptable.
> >>
> >> So don't use these features in your application. The overhead goes away,
> >> no?
> >
> >Sure. Don't use exceptions, don't use multiple inheritance, don't use
> >iostreams, don't use RTTI, don't use dynamic_cast. ... Pretty soon
> >you're writing C code. And that's the problem: C++ as it's defined today
> >can be too big for applications that demand a small memory footprint.
>
> No, (once more for the Gipper...) C++ has been designed so that the
> parts you don't use need carry no overhead.
No. That was one of the goals. It has not been achieved. Every one of
the things I listed in the preceding paragraph (except multiple
inheritance) carries overhead even if you don't use it. Try it and see.
In the benchmarks that have been done so far the EC++ spec has lead to
executable files that were less than half the size of the executables
produced with full C++, using the same compiler and the same
optimization settings and the same library implementation (cut back for
EC++).
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/21 Raw View
Richard Damon wrote:
>
>
> The compiler can generate the reference to B::foo but how does it generate a
> reference to D::foo when it has not seen the class, and which might not even
> exist yet.
>
> class D would need some why of saying if B::foo is referenced, then consider
> D::foo referenced which seems above the ability of most linkers I know.
>
That's the core of the problem (assuming you've got weak references
already). It's what I earlier called "reverse causality", but would now
call a "me too" reference. It says "if he gets in, I get in too."
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Eyal Ben-David <eyal.ben-david@aks.com>
Date: 1998/05/21 Raw View
Richard Damon wrote:
>
> One question, given
>
> class B {
> public:
> virtual int foo();
> }
>
> class D : public B {
> public:
> virtual int foo();
> }
>
> B* pb;
>
> in module 1:
> pb = new D;
>
> in module 2 (having only class B's declaration visible)
> pb->foo();
>
> The compiler can generate the reference to B::foo but how does it generate a
> reference to D::foo when it has not seen the class, and which might not even
> exist yet.
>
> class D would need some why of saying if B::foo is referenced, then consider
> D::foo referenced which seems above the ability of most linkers I know.
In this case the linker must include all foo's in the final executable.
But if you never call foo (or setlocal)? I think that the linker can
safely put NULL in the foo vtable entry (for all classes).
AFAIK Watcom C++ has this feature as a compiler/linker option.
Eyal.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/05/21 Raw View
Pete Becker <petebecker@acm.org> wrote:
>Don't use exceptions, don't use multiple inheritance, don't use
>iostreams, don't use RTTI, don't use dynamic_cast. ... Pretty soon
>you're writing C code. And that's the problem: C++ as it's defined today
>can be too big for applications that demand a small memory footprint.
>The arrogant answer is "too bad, find something else". A more
>enlightened one is "let's see what we can do to make C++ more acceptable
>here."
The problem is not with C++ as it's defined today, it's with C++
as it's implemented today. The arrogant answer is to define
something else and steal the name. The enlightened one is to
make conforming implementations of the Standard efficient.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: fjh@cs.mu.OZ.AU (Fergus Henderson)
Date: 1998/05/21 Raw View
Pete Becker <petebecker@acm.org> writes:
> It's not clear to me how this pulls in virtual functions in derived
>classes where the only call to the virtual function is through a
>reference or pointer to the base.
Yes, on second thoughts, I think you're right: the method I suggested
wouldn't quite work. I don't see how to do it using existing ELF
features. I think it would instead require an extension to the ELF
object file format.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/05/21 Raw View
<jkanze@otelo.ibmmail.com> wrote:
> I think it also worth pointing out
>that between the time a vendor decides to use some technology, and the
>time it actually is usable in the released version of the vendors
>compiler, you should count at least a year.
Sorry, James, this is silly. *Some* vendors take forever to do
things, others act very quickly. Examples of the latter include
KAI (kcc) and Cygnus (egcs). A responsive compiler vendor tends
to have other virtues in its favor.
You can't generalize from experience with a single vendor.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/21 Raw View
Nathan Myers wrote:
>
>The arrogant answer is to define something else and steal the name.
Better watch out: that ANSI/ISO committee is out to steal the name
"C++". Can't let them do that. Somebody call the cops, quick!
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/21 Raw View
Nathan Myers wrote:
>
>
> The problem is not with C++ as it's defined today, it's with C++
> as it's implemented today. The arrogant answer is to define
> something else and steal the name. The enlightened one is to
> make conforming implementations of the Standard efficient.
Someday we'll have magical compilers that will solve all our
development problems instantaneously, and then life will be wonderful.
In the meantime, folks who live in the real world have to ship products.
A commercial standard must be rooted in reality, not in imagined future
developments.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Oleg Zabluda <zabluda@math.psu.edu>
Date: 1998/05/21 Raw View
Pete Becker <petebecker@acm.org> wrote:
: Fortunately, most members of the ISO/ANSI committee have not
: prejudged this issue [EC++ -- O.Z] , and prefer technical
: discussions to polemics.
I seem to recall that there used to be quite a polemic
about EC++ when the effort initialy started. I vaguely
remember that the problem was that EC++ was not a strict
subset of C++, but mutated some C++ features. I seem to
remember very angry posts on the subject from Stroustrup.
Fortunately, EC++ people gave in or it seems so. As usual,
my memory might be failing me, and I can't find any traces
of it on DejaNews, so don't believe any of the above
until you get another confirmation.
Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/21 Raw View
James Kuyper wrote:
>
> Pete Becker wrote:
> >
> > That's the point of the EC++ technical specification:
> > it defines a smaller subset which typically results in executables that
> > are less than half the size of those produced by the same compiler using
> > the full language. (okay, 80k to 16k was a bit of an exaggeration...).
>
> But if, as you said earlier, your concern is that "no compiler does that
> today", if "Speculation about what might happen at some unspecified tim
> in the future" is irrelevant, then changes to the language standard are
> irrelevant. No compiler today will have been written to match the
> proposed change to standard; the nature of any changes to the standard
> unambiguously falls into the category of "Speculation", particularly
> since any such changes will have to wait for the next release - it's too
> late for this one.
The proposal that the Japanese made to the ISO/ANSI committee was that
they produce a new work item aimed at developing a technical report.
That can be done at any time, just like the Numeric C Extensions Group
did under the auspices of X3J11, issuing a technical report a couple of
years before the C standard began its revision process. It's independent
of the current standard and its schedule.
Producing a specification for an embedded subset is something that can
be done in a predictable time frame. Waiting around in the hope that
some compiler vendor will magically improve their compiler enough to
solve the space problems has no such boundedness. Not even if you
believe the people here who like to imply that such compilers are just
around the corner, but don't answer when you ask for details.
There are several compilers today that support the EC++ specification.
They're being used in environments that full C++ compilers can't touch.
That's not speculation, it's fact.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/05/27 Raw View
J. Kanze<kanze@gabi-soft.fr> wrote:
>"greg" <yo@mama.com> writes:
>
>|> > There is a great deal that the library writer can do to
>|> > minimize overhead in the library. That goes for locale, and for a
>|> > lot else as well. Yes, some help from the compiler makes it easier,
>|> > but pointing fingers (at the standard, or at compilers) is easier yet.
>|> >
>|> > "Embedded C++", as it's being promoted, is an exercise in just such
>|> > finger-pointing. ... those vendors
>|> > try to make a virtue of having a less-efficient, non-conforming
>|> > implementation by slapping on a catchy tag.
>|>
>|> I agree that there should be no need for an embeddable subset of the
>|> C++ language, but it is perfectly reasonable to have an embeddable
>|> subset of the C++ library.
>
>There *should* be no need for either. Today, there is a need for both.
Everyone agrees that it may be *expedient* to use some non-standard,
crippled library while waiting for vendors to implement the new Standard
efficiently. What is at issue is whether it is sensible to divert
resources into actually standardizing one or other crippled subset.
The ISO/ANSI answer was: "NO". The study group they have initiated
is not tasked to produce a language or library subset -- despite some
misleading reports to the contrary. It is to produce a technical
report on techniques to implement the full language efficiently, without
gratuitious overhead, and without need to impose a predefined subset
on users.
One (obvious) such technique is for the compiler vendor to provide a
variety of "library subsets" for the user to choose among. Different
customers would of course make different choices. All such libraries
would be "conforming", in that the lack of something not used would
be detectable only in the resulting program size. Of course a better
compiler/linker and a better-implemented library, when available, make
such a clumsy expedient unnecessary.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/05/27 Raw View
J. Kanze <kanze@gabi-soft.fr> wrote:
>A number of inefficiencies are "standard" today. In all
>existing compilers.
No, only in the few compilers James says he is familiar with.
>... To date, I've yet to see an implementation
>of templates that really works, much less conforms to the draft
>standard. (A number of implementations work "well enough" for many
>practical uses, but none have the reliability for the types of
>applications I used to do.)
James has already remarked that he has had no experience with
the more-robust of the available compilers. In my own experience,
it has been a long time since I ran into a template bug in the
compilers I use. (This is not to say I never find bugs.)
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/05/27 Raw View
J. Kanze<kanze@gabi-soft.fr> wrote:
>Egcs (and g++ 2.8.0, for that matter) are in the process of recreating
>the image g++ had three or four years ago (back in the days of the
>"version of the day"). An image that made g++ more or less a laughing
>stock among people doing serious work.
This is nothing but FUD. First, gcc-2.8 and Egcs-1.0 are very different
products; you cannot generalize from one to the other. Second, the Egcs
numbered releases (unlike gcc-2.8's) have been very thoroughly tested and
are as reliable as any compiler on the market -- and substantially more
reliable than the ones James says he uses. (Comments about "snapshots",
which have not been tested or indeed "released" in any formal sense, may
be sent to alt.flame.)
This is not to say Egcs has no bugs. But it is to say that (1) there are
fewer than in James' workhorse compilers, and (2) they get fixed sooner.
(Followups to comp.lang.c++.moderated.)
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/28 Raw View
Nathan Myers wrote:
>
>
> The ISO/ANSI answer was: "NO".
Absolutely false. See below.
> The study group they have initiated
> is not tasked to produce a language or library subset -- despite some
> misleading reports to the contrary. It is to produce a technical
> report on techniques to implement the full language efficiently, without
> gratuitious overhead, and without need to impose a predefined subset
> on users.
No. Its task has not been defined yet, but the intent of those at the
meeting (Nathan was not present) was clear: the working group is to
explore the issues of size and speed problems in C++ and to recommend
solutions. There were no constraints on the nature of those solutions,
and, in particular, there was no indication of any intent to exlude
anything along the lines of the EC++ proposal.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/28 Raw View
Pete Becker wrote:
>
> There were no constraints on the nature of those solutions,
> and, in particular, there was no indication of any intent to exlude
> anything along the lines of the EC++ proposal.
Let me say that more clearly: the Japanese request that the committee
consider EC++ was accepted, and extended to include looking at other
techniques, as well.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/05/28 Raw View
Pete Becker <petebecker@acm.org> wrote:
>Nathan Myers wrote:
>>
>>
>> The ISO/ANSI answer was: "NO".
>
>Absolutely false. See below.
What Pete reveals below does not make my statement "absolutely false",
or even somewhat false.
>> The study group they have initiated
>> is not tasked to produce a language or library subset -- despite some
>> misleading reports to the contrary. It is to produce a technical
>> report on techniques to implement the full language efficiently,
>> without gratuitious overhead, and without need to impose a predefined
>> subset on users.
>
>... the working group is to
>explore the issues of size and speed problems in C++ and to recommend
>solutions. There were no constraints on the nature of those solutions,
>and, in particular, there was no indication of any intent to exlude
>anything along the lines of the EC++ proposal.
Pete would like us to believe that "no indication of any intent to
exclude X" is the same as "intent to specify X". Reports from some
quarters have been that the ISO group is meant to define a language
subset, and these reports are blatantly false. To quote from Bjarne,
before the meeting:
What could a group do to make C++ more effective for the
embedded systems community? Document efficiencies and
inefficiencies in generated code. Popularize implementation
techniques and programming techniques that are efficient in
time and space. Lobby for compiler options to turn off
features that don't meet the zero-overhead principle and
for efficient implementations of the standard library and,
where necessary, subsets [note plural] thereof. ...
Does this require a formal specification of yet another
C/C++ dialect? I doubt it, and every dialect does some harm
by fragmenting the community... Nor do I see the embedded
systems C++ community as a monolith whose needs can be
completely served by a single subset language and almost-
subset standard library. ... Only the ability of
individual organizations to pick suitable proper subsets
of ISO C++ will provide sufficient flexibility and
portability of code. ...
He returned from France happy with the result. Whatever may
have been written, the technical report *will not* define a
language subset if Bjarne has any influence.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/28 Raw View
Nathan Myers wrote:
>
> Pete Becker <petebecker@acm.org> wrote:
> >Nathan Myers wrote:
> >>
> >>
> >> The ISO/ANSI answer was: "NO".
> >
> >Absolutely false. See below.
>
> What Pete reveals below does not make my statement "absolutely false",
> or even somewhat false.
>
> Pete would like us to believe that "no indication of any intent to
> exclude X" is the same as "intent to specify X".
No. What I said, and what is absolutely true, is that "no indication of
any intent to exclude X" is not the same as "the ... answer was 'NO'".
> Reports from some
> quarters have been that the ISO group is meant to define a language
> subset, and these reports are blatantly false.
I haven't seen anyone here say that. Nathan is tearing down his own
strawman. What I have consistently said, and what the ISO/ANSI committee
decided, is to consider how to approach this problem. The proposal that
led to this decision was that ISO/ANSI consider adopting the EC++ spec,
and the committee's decision was expand that inquiry to include other
possible approaches. The committee has not ruled out adopting the EC++
spec.
> To quote from Bjarne, before the meeting:
Bjarne does not speak for the ISO/ANSI committee, nor does what anyone
says prior to a meeting that considers an issue constitute the
committee's decision on that issue. The committee, despite Nathan's
obvious desires to the contrary, follows a democratic process.
>
> What could a group do to make C++ more effective for the
> embedded systems community? Document efficiencies and
> inefficiencies in generated code. Popularize implementation
> techniques and programming techniques that are efficient in
> time and space. Lobby for compiler options to turn off
> features that don't meet the zero-overhead principle and
> for efficient implementations of the standard library and,
> where necessary, subsets [note plural] thereof. ...
> Does this require a formal specification of yet another
> C/C++ dialect? I doubt it, and every dialect does some harm
> by fragmenting the community... Nor do I see the embedded
> systems C++ community as a monolith whose needs can be
> completely served by a single subset language and almost-
> subset standard library. ... Only the ability of
> individual organizations to pick suitable proper subsets
> of ISO C++ will provide sufficient flexibility and
> portability of code. ...
>
> He returned from France happy with the result.
I would not be so bold as to put words in Bjarne's mouth: he's
perfectly capable of speaking for himself.
But let's think a bit about what Nathan claims that Bjarne thinks.
Bjarne could be "happy with the result" because his mind is completely
closed, and he got his way. That's what Nathan wants people to conclude.
Or he could be "happy with the result" because, unlike Nathan, he
listened to and took part in the discussion at the meeting, and now
understands the problem and the goals of the proposers better.
> Whatever may
> have been written, the technical report *will not* define a
> language subset if Bjarne has any influence.
That's a prediction, not a decision. I suppose that's a good change:
Nathan is no longer asserting that this has already been decided, but
merely stating what he thinks will happen. At least he's got his tenses
right.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/17 Raw View
Mike Davies wrote:
>
> In article <6jf2eg$ds5$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
> writes:
>
> >I think that embedded C++ is largely a question of expectations -- we all
> >know that some features of C++ are more expensive than others, and that
> >in some applications, this expense is not acceptable.
>
> So don't use these features in your application. The overhead goes away,
> no?
Sure. Don't use exceptions, don't use multiple inheritance, don't use
iostreams, don't use RTTI, don't use dynamic_cast. ... Pretty soon
you're writing C code. And that's the problem: C++ as it's defined today
can be too big for applications that demand a small memory footprint.
The arrogant answer is "too bad, find something else". A more
enlightened one is "let's see what we can do to make C++ more acceptable
here."
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/05/17 Raw View
<jkanze@otelo.ibmmail.com> wrote:
>In article <6jbdbm$f1p$1@shell7.ba.best.com>,
> ncm@nospam.cantrip.org (Nathan Myers) wrote:
>
>> "Embedded C++", as it's being promoted, is an exercise in just such
>> finger-pointing. ... vendors
>> try to make a virtue of having a less-efficient, non-conforming
>> implementation by slapping on a catchy tag.
>
>...
>I think that embedded C++ is largely a question of expectations -- we all
>know that some features of C++ are more expensive than others, and that
>in some applications, this expense is not acceptable.
That's precisely the problem, and precisely why this "Embedded C++"
is such an oily proposition. On ill-designed implementations, some
constructs are far more expensive than necessary. Enshrining those
inefficiencies in a spurious "standard" creates disinformation:
people will come to believe that only the features retained in
that "standard" can be used in applications that are sensitive to
overhead.
Those implementers who have done the extra work to make the constructs
efficient are penalized, and users suffer from not using the features
that would simplify their designs.
> The idea behind
>embedded C++, as I understand it, is to define a subset in which I
>have a right to expect efficiency. If I limit myself to this subset,
>none of my code should turn out to be unexpectedly expensive on any
>platform.
That is what they would like you to believe. In fact, it's just
a subset that the late-comer implementers already have implemented,
regardless of efficiency. For example, the subset omits templates,
not because they add any overhead whatsoever, or because they are
not incredibly useful in embedded system design, but simply because
the consortium members haven't got (and want an excuse not to buy)
a good implementation of templates.
>Obviously, if some vendor manages to make a full C++ adequately efficient
>for a particular embedded platform, he will have a definite marketing
>advantage.
This is far from obvious. If a vendor makes an efficient full C++ and
finds customers artificially restricting their use of the language to
avoid the features they have implemented efficiently, that cancels
much of the marketing advantage.
>And equally obviously, there will be vendors who use this as an excuse
>not to do the harder job of a full implementation, even when it is, or
>should be possible. ... But the fact that vendors can abuse some standard
>in order to gain sales position doesn't mean that the standard is bad.
The "standard" *is* bad if that is the main reason for its existence.
The ISO/ANSI committee is forming a subgroup to discuss the real
concerns of real embedded-system builders. This group will help to
identify and publicize techniques to allow language features to be
implemented without unnecessary overhead. That is a reasonable way
to address the problem, rather than cobbling up a phony language
subset for embedded-system builders to try to shoehorn themselves
into.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/18 Raw View
James Kuyper wrote:
>
> Pete Becker wrote:
> >
> > Nathan Myers wrote:
> > >
> > > Of course, any implementation can have this optimization; it doesn't
> > > depend on any restricted subset of the language.
> >
> > Of course, no compiler does that today, so if you're stuck trying to fit
> > 80k of code into 16k of ROM you may well want a restricted subset of the
> > language. Speculation about what might happen at some unspecified time
> > in the future won't get your product out the door.
>
> Neither will suggesting changes to the language standard.
Of course it will. That's the point of the EC++ technical specification:
it defines a smaller subset which typically results in executables that
are less than half the size of those produced by the same compiler using
the full language. (okay, 80k to 16k was a bit of an exaggeration...).
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/05/18 Raw View
Pete Becker wrote:
>
> James Kuyper wrote:
> >
> > Pete Becker wrote:
> > >
> > > Nathan Myers wrote:
> > > >
> > > > Of course, any implementation can have this optimization; it doesn't
> > > > depend on any restricted subset of the language.
> > >
> > > Of course, no compiler does that today, so if you're stuck trying to fit
> > > 80k of code into 16k of ROM you may well want a restricted subset of the
> > > language. Speculation about what might happen at some unspecified time
> > > in the future won't get your product out the door.
> >
> > Neither will suggesting changes to the language standard.
>
> Of course it will. That's the point of the EC++ technical specification:
> it defines a smaller subset which typically results in executables that
> are less than half the size of those produced by the same compiler using
> the full language. (okay, 80k to 16k was a bit of an exaggeration...).
But if, as you said earlier, your concern is that "no compiler does that
today", if "Speculation about what might happen at some unspecified tim
in the future" is irrelevant, then changes to the language standard are
irrelevant. No compiler today will have been written to match the
proposed change to standard; the nature of any changes to the standard
unambiguously falls into the category of "Speculation", particularly
since any such changes will have to wait for the next release - it's too
late for this one.
Personally, I'm concerned on a longer time scale than that; but your
objections are only relevant on time scales much shorter than the time
between consecutive releases of the standard.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Matt Austern <austern@sgi.com>
Date: 1998/05/19 Raw View
Pete Becker <petebecker@acm.org> writes:
> > It's not rocket science. Furthermore, it would be a terribly helpful
> > optimization for any program that uses library virtual functions,
> > regardless of whether it uses the standard library. Any compiler
> > that doesn't implement this optimization really isn't doing much for
> > embedded system builders, regardless of what a vendor might trumpet
> > in its advertising.
>
> I don't know of any compiler today that does this "optimization", nor
> have I heard any rumors of compilers that will do this in the near
> future. It's hard to do, and even harder to do efficiently. Unless, of
> course, you want to scrap separate translation. That's a high price to
> pay.
It's not a terribly esoteric optimization: it's just straightforward
dead function elimination in the inter-procedural analysis phase.
Compilers that do inter-procedural analysis (yes, even across the
translation unit boundary) aren't so hard to come by anymore.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "P.J. Plauger" <pjp@plauger.com>
Date: 1998/05/19 Raw View
Howard Hinnant <hinnant@_anti-spam_lightlink.com> wrote in article
<hinnant-0405981436380001@isdn3-15.lightlink.com>...
>
> I'm afraid I've stumbled across a fairly large flaw in <locale>. I'm
> hoping someone (maybe Nathan?) can set me straight...
> .....
> Since the classic locale instantiates every standard facet for both char
> and wchar_t, a conforming implementation may well instantiate 95% of the
> templated code in <locale> (twice). I estimate this code to be
> approximately several hundred Kb on a typical platform.
> .....
> A conforming implementation may well stuff into this executable all of
the
> code to read and write integers, floating point numbers, money, time,
> collation, character classification and messaging, even though this code
> is all templated, and never used (that's for both char streams, and to
the
> newer whar_t streams). No wonder C++ has gotten a reputation for bloated
> applications!! Why don't we just go ahead and build a *&@#% runtime
> environment! <sarcasm>
> .....
> As I see it, an implementation either MUST NOT automatically instantiate
> virtual members of template classes, or standard facets MUST NOT have
> virtual members. Else we have a language that's too fat to be useful.
> I'm not smart enough about compilers to know if the former is feasable.
I
> do think we could live with the latter.
>
> Or perhaps we just have a language in which I/O is not feasible. Could
> this be the major cause of the EC++ movement?
>
> Hoping to hear I'm wrong...
This *is* a major cause of the EC++ movement, but it is not an insoluble
problem. Mr. Hinnant is correct that the extensive use of virtual functions
in Standard C++ locales can cause hundreds of kilobytes of code to be
loaded even if it is never used. And typically, much of the code is *not*
used. Few programmers are even aware that they can read and parse
dates, or write monetary amounts, with the code that comes with every
locale object.
Yes, you can put all this stuff in a DLL, which mitigates the problem for a
hosted system. But that doesn't help people who need small executables,
of which embedded systems programmers are just a prominent example.
Yes, the problem is analogous to that of printf, which also drags in code
that is often unused. But the problem is *hundreds* of times worse.
The Standard C++ library I wrote mitigates this problem by loading only
those standard facets that are actually accessed by the program. A
simple program that normally pulls in several hundred kilobytes of facet
virtuals actually pulls in only about 50 kb. (I wish it were even less.)
This
takes a bit of trickery with templates, but it does not require any magic
on the part of linkers. It has been in the field for two years now, as part
of Microsoft Visual C++ V4.2 and V5.0. The same technology, slightly
improved, is now available from Dinkumware, Ltd.
P.J. Plauger
President
Dinkumware, Ltd.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/19 Raw View
Nathan Myers wrote:
>
> It's reasonable (and essential!) to have *many* embeddable subsets of
> the C++ library. But you, the programmer, should choose, and not let
> some cabal of backward compiler vendors choose for you.
>
> You choose by using the standard features you need, and not using the
> ones you don't. It's the compiler vendor's job to link in the ones
> you use, and not the ones you don't. If they don't do their job, what
> are you paying them for?
You're paying them to do the best job they can of compiling and linking
C++ programs given current technology. Since you haven't pointed to a
single compiler in existence today that can compile a program that uses
iostreams and not link in any unused virtual locale functions it
certainly appears that the problem here is not one of "backward compiler
vendors" but one of feasibility. Instead of stooping to name calling,
can you suggest a workable technique for handling this problem?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/19 Raw View
Nathan Myers wrote:
>
> Pete Becker <petebecker@acm.org> wrote:
> >Nathan Myers wrote:
> >> It's not rocket science. Furthermore, it would be a terribly helpful
> >> optimization for any program that uses library virtual functions,
> >> regardless of whether it uses the standard library. Any "Embedded C++"
> >> compiler that doesn't implement this optimization really isn't doing
> >> much for embedded system builders, regardless of what a vendor might
> >> trumpet in its advertising.
> >
> >I don't know of any compiler today that does this "optimization", nor
> >have I heard any rumors of compilers that will do this in the near
> >future. It's hard to do, and even harder to do efficiently. Unless, of
> >course, you want to scrap separate translation. That's a high price to
> >pay.
>
> It took Richard Henderson a couple of days to implement. He didn't
> say it was "hard to do", and it is both efficient and supports
> separate compilation. Now, Richard is practically a god among men,
> but it shouldn't take an ordinary compiler hack more than a week
> or two.
Since I haven't heard of Richard Henderson, perhaps you could say more
about him. In particular, has what he did been tested in the real world?
>
> Conceptually: if the only reference to a virtual function is from a
> vtbl cell, and no object file in the complete program mentions that
> cell, then the virtual function itself need not be linked. As I
said,
> not rocket science. Modern ELF linkers do far more complicated
things
> with (more-or-less) ordinary C code.
>
> That Pete hasn't heard of any compilers that "will do this in the near
> future" suggests to me that he doesn't know of any compiler vendors
> who *really* are interested in the *real* needs of *real* embedded-system
> builders. That's not Pete's fault, of course, but as an embedded-system
> builder I'd be very disappointed in the performance of the compiler
> vendors he does know.
I notice that you still haven't mentioned any commercial compilers that
do this, or will in the near future.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: fjh@cs.mu.OZ.AU (Fergus Henderson)
Date: 1998/05/19 Raw View
Pete Becker <petebecker@acm.org> writes:
>Nathan Myers wrote:
>>
>> It's not much different from what the linker does anyway: if you
>> don't call setlocale(), then when the linker examines all the
>> object files and finds no reference to setlocale(), it doesn't link
>> that in. If your program never references the vtbl slot occupied by
>> num_put<char>::put(...,double), then a good linker can simply leave
>> that slot empty.
>
>It's quite a bit different. The linker does not make decisions about
>what identifiers are needed. The compiler generates a list for each
>translation unit, and the linker simply finds things from that list.
>Adding the capability to decide that something the compiler thought it
>needed isn't really needed is a big step.
ELF already has "weak references": a compiler can spit out a weak
reference to a symbol, and the linker will fill it with NULL if the
symbol's value is not used elsewhere, or with the symbol's value, if
there are some "strong" references to the symbol.
ELF also allows multiple sections, including user-defined ones.
So all the compiler needs to do is as follows:
- For each class, generate a link unit containing a vtable
definition in the read-only data section; in each vtable slot
of such definitions, generate a weak reference to the
corresponding virtual function.
- For each class C, for each virtual function F, generate a
link unit containing a vtable-slot entry in the
"vtable_slots_for__C__F" section; this entry should contain a
strong reference to the function F that occupies that slot.
Similarly, for each direct or indirect base class B from
which C is derived, generate a link unit containing a
vtable-slot entry in the "vtable_slots_for__B__F" section.
- For each virtual function call which cannot be resolved
statically, generate (in the same link unit) an entry in the
"vtable_slot_references" section which contains a strong
reference to the corresponding vtable-slot section.
This will force the vtable-slot entries for that class and slot to be
linked in whenever the virtual function call is linked in, which will
in turn force the corresponding vtable-slot entries for all derived
classes to also be linked in. These vtable-slot entries will will
force the corresponding virtual functions to be linked in. And that
will ensure that the weak references in the vtables get filled in with
the correct values.
Once the executable has been linked, the "vtable_slots_for_*" and
"vtable_slot_references" sections are not needed and can be stripped.
In the above I talk about "link units". Traditional brain-dead
Unix linkers allow only one link unit per object file (i.e.
any reference to any part of the object file caused the whole
object file to be linked in). If your linker doesn't allow
multiple link units per object file, then you can emulate this
by generating multiple object files for each C++ translation unit
(but for convenience you can merge them all into a single archive).
>> It's not rocket science.
Nathan Myers is absolutely right here.
I may have got some of the details wrong in the above explanation,
but I don't see any great problems in principle.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Valentin Bonnard <bonnardv@pratique.fr>
Date: 1998/05/11 Raw View
Pete Becker wrote:
>
> Christopher Eltschka wrote:
> >
> > Howard Hinnant wrote:
> >
> > > A conforming implementation may well stuff into this executable
lots of things, yes, that's possible
> > Well, I'd say this is a quality of implementation issue.
>
> Partly. But it's very hard to write library code that doesn't pull in a
> large amount of code
[...]
Isn't it a quality of the compiler issue (not the library) ?
Same comment about code size using the STL.
--
Valentin Bonnard mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/12 Raw View
Valentin Bonnard wrote:
>
> Pete Becker wrote:
> >
> > Christopher Eltschka wrote:
> > >
> > > Howard Hinnant wrote:
> > >
> > > > A conforming implementation may well stuff into this executable
>
> lots of things, yes, that's possible
>
> > > Well, I'd say this is a quality of implementation issue.
> >
> > Partly. But it's very hard to write library code that doesn't pull in a
> > large amount of code
> [...]
>
> Isn't it a quality of the compiler issue (not the library) ?
Not if you're a library vendor trying to write a high quality library.
Very few people will buy my library if the best I can tell them is
"maybe in a few years compilers will be good enough to make my library
usable."
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: hinnant@_anti-spam_lightlink.com (Howard Hinnant)
Date: 1998/05/12 Raw View
> Isn't it a quality of the compiler issue (not the library) ?
There have been several comments about this being a quality issue.
Perhaps ... like I said in my original post, I'm not knowledgable about
what is feasable with compilers.
I am very curious if there are ANY compilers on the planet that pass this
particular "quality" test. If there are, then perhaps this IS a quality
issue. If there are not, then I consider it possible that this is not a
"quality" issue, but rather the standard has asked for the impossible (or
at least not practical).
I don't have access to a wide variety of compilers. Can anyone compile this?
template <class T>
class A
{
public:
virtual void doSomething() {data_.doit();}
private:
T data_;
};
int main()
{
A<int> a;
}
I don't believe that this is portable code so compilers failing to compile
this are not non-standard. To make the above portable, remove the virtual
keyword.
-Howard
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1998/05/13 Raw View
In article 1205981009410001@port71.lightlink.com, hinnant@_anti-spam_lightlink.com (Howard Hinnant) writes:
>
>I am very curious if there are ANY compilers on the planet that pass this
>particular "quality" test. ...
>
>I don't have access to a wide variety of compilers. Can anyone compile this?
>
>template <class T>
>class A
>{
>public:
> virtual void doSomething() {data_.doit();}
>private:
> T data_;
>};
>
>int main()
>{
> A<int> a;
>}
>
>I don't believe that this is portable code so compilers failing to compile
>this are not non-standard. To make the above portable, remove the virtual
>keyword.
If you remove the virtual keyword, the code is OK, because the compiler
is not allowed to instantiate a non-virtual member function unless it
is used.
The draft standard says in 14.7.1 "Implicit instantiation" that it is
"unspecified" whether a virtual function is implicitly instantiated.
"Unspecified" means that the compiler might or might not instantiate
the function implicitly, and is not required to document under what
circumstances it would be instantiated.
Common implementations need to instantiate all virtual functions in
order to populate the vtable associated with the class. If the
implementation does not instantiate the function, it would have
to detect somehow that the function was called and issue an
appropriate diagnostic. I think a run-time diagnostic like "function
not found" might satisfy the requirements of the standard, but would
be unlikely to satisfy programmers.
Detecting at compile time whether the virtual function is really called
is impossible in general. Example:
#include <iostream>
class D : public A<int> {
public:
// override A<int> version
void doSomething() { /* empty */ }
};
int main()
{
int i;
cout << "Enter a number less than 10: ";
cin >> i; // user enters some value
A<int>* p = (i<10) ? new D : new A<int>;
p->doSomething(); // which one gets called?
}
I would rather have an unnecessary compile-time failure that required
me to re-think my design than to find the program mysteriously failing
for some customers. (If you really need A<int>, you can make a
specialization that doesn't require int to have member functions.)
---
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/05/13 Raw View
Valentin Bonnard wrote:
> Pete Becker wrote:
> > Christopher Eltschka wrote:
> > > Howard Hinnant wrote:
> > >
> > > > A conforming implementation may well stuff into this executable
>
> lots of things, yes, that's possible
And lots else besides. "Conformance" imposes *no* upper limit
on what gets stuffed into an executable. The permission to
instantiate virtual members is not a requirement to put them
anywhere. Any that can be proven not to be called can certainly
be left out, and it's really not very hard to get a compiler/linker
to do that, if you care to.
> > > Well, I'd say this is a quality of implementation issue.
> >
> > Partly. But it's very hard to write library code that doesn't pull in a
> > large amount of code
> [...]
>
> Isn't it a quality of the compiler issue (not the library) ?
It's both. There is a great deal that the library writer can do to
minimize overhead in the library. That goes for locale, and for a
lot else as well. Yes, some help from the compiler makes it easier,
but pointing fingers (at the standard, or at compilers) is easier yet.
"Embedded C++", as it's being promoted, is an exercise in just such
finger-pointing. Eventually some consortium members will implement
conforming (even efficient) compilers. Then the official "Embedded C++"
subset will be forgotten, and their customers (like the rest of us)
will be able to use whatever language subset matches their needs,
without need for a special blessing. In the meantime, those vendors
try to make a virtue of having a less-efficient, non-conforming
implementation by slapping on a catchy tag.
There's not *much* wrong with selling that snake oil -- business is
war, and all that -- but that doesn't mean you have to swallow it.
A compiler vendor who has completed a fully-conforming implementation
can spend attention on optimizing its output. Those who are way behind
must spend it on catching up. Your programs can benefit by using exactly
the language subset you need and taking advantage of those optimizations,
rather than by working around the holes in a language spec arbitrarily
curtailed to match what the laggards have already got implemented.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Paul D. DeRocco" <pderocco@ix.netcom.com>
Date: 1998/05/13 Raw View
Pete Becker wrote:
>
> Partly. But it's very hard to write library code that doesn't pull in
> a large amount of code that the application doesn't actually use, and
> gets all the semantics of locales correct.
This is important from the point of view of executable size, but some
OSes at least leave it up to the paging system to load only those pages
that are actually touched. Note that some OSes also do the opposite,
gangloading the whole program in one operation, under the assumption
that practically all of it will turn out to be needed anyway, and it's
faster to load it in one fell swoop. (Is there any other kind of swoop,
by the way?)
--
Ciao,
Paul
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/05/14 Raw View
Steve Clamage<clamage@Eng.Sun.COM> wrote:
>
>The draft standard says in 14.7.1 "Implicit instantiation" that it is
>"unspecified" whether a virtual function is implicitly instantiated.
>"Unspecified" means that the compiler might or might not instantiate
>the function implicitly, and is not required to document under what
>circumstances it would be instantiated.
>
>Common implementations need to instantiate all virtual functions in
>order to populate the vtable associated with the class. ...
>Detecting at compile time whether the virtual function is really called
>is impossible in general. ...
Impossible in general, but possible in very useful specific cases.
In particular, if a class A has virtual member functions A::f, A::g,
and A::h, and the compiler/linker can determine that only A::f can
can be called by a particular program, then it need not link g or h
into the resulting executable.
Addressing Howard's original question, if your program never formats
a floating-point number, then num_put<char>::put(..., double) cannot
be called, and the linker can omit that function from the executable.
In the big world of shared libraries this may not make a lot of
difference, but in embedded systems it can make a great difference.
Of course, any implementation can have this optimization; it doesn't
depend on any restricted subset of the language.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/05/14 Raw View
In article <6jbdbm$f1p$1@shell7.ba.best.com>,
ncm@nospam.cantrip.org (Nathan Myers) wrote:
> "Embedded C++", as it's being promoted, is an exercise in just such
> finger-pointing. Eventually some consortium members will implement
> conforming (even efficient) compilers. Then the official "Embedded C++"
> subset will be forgotten, and their customers (like the rest of us)
> will be able to use whatever language subset matches their needs,
> without need for a special blessing. In the meantime, those vendors
> try to make a virtue of having a less-efficient, non-conforming
> implementation by slapping on a catchy tag.
I think that this is an unfair characterization of "Embedded C++". I
think that embedded C++ is largely a question of expectations -- we all
know that some features of C++ are more expensive than others, and that
in some applications, this expense is not acceptable. If I am only
targetting a single platform with my software, there is no need for
embedded C++. I will find out what features of my compiler are too
expensive, and avoid them. If I'm targetting a number of embedded
processors, however, the problem is more difficult. The idea behind
embedded C++, as I understand it, is to define a subset in which I
have a right to expect efficiency. If I limit myself to this subset,
none of my code should turn out to be unexpectedly expensive on any
platform.
Obviously, if some vendor manages to make a full C++ adequately efficient
for a particular embedded platform, he will have a definite marketing
advantage. But it still won't help the people who have to be portable
to any number of embedded platforms.
And equally obviously, there will be vendors who use this as an excuse
not to do the harder job of a full implementation, even when it is, or
should be possible. Just as there were C compiler vendors who used the
compilation limits clause as an excuse to use fixed sized tables, rather
than to do the extra memory management. In the long, the market should
weed out such vendors. But the fact that vendors can abuse some standard
in order to gain sales position doesn't mean that the standard is bad.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "greg" <yo@mama.com>
Date: 1998/05/14 Raw View
> It's both. There is a great deal that the library writer can do to
> minimize overhead in the library. That goes for locale, and for a
> lot else as well. Yes, some help from the compiler makes it easier,
> but pointing fingers (at the standard, or at compilers) is easier yet.
>
> "Embedded C++", as it's being promoted, is an exercise in just such
> finger-pointing. Eventually some consortium members will implement
> conforming (even efficient) compilers. Then the official "Embedded C++"
> subset will be forgotten, and their customers (like the rest of us)
> will be able to use whatever language subset matches their needs,
> without need for a special blessing. In the meantime, those vendors
> try to make a virtue of having a less-efficient, non-conforming
> implementation by slapping on a catchy tag.
I agree that there should be no need for an embeddable subset of the
C++ language, but it is perfectly reasonable to have an embeddable
subset of the C++ library.
Greg Colvin
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/15 Raw View
Nathan Myers wrote:
>
> Of course, any implementation can have this optimization; it doesn't
> depend on any restricted subset of the language.
Of course, no compiler does that today, so if you're stuck trying to fit
80k of code into 16k of ROM you may well want a restricted subset of the
language. Speculation about what might happen at some unspecified time
in the future won't get your product out the door.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: hinnant@_anti-spam_lightlink.com (Howard Hinnant)
Date: 1998/05/15 Raw View
In article <6jcpnj$ikg$1@shell7.ba.best.com>, ncm@nospam.cantrip.org
(Nathan Myers) wrote:
> Impossible in general, but possible in very useful specific cases.
>
> In particular, if a class A has virtual member functions A::f, A::g,
> and A::h, and the compiler/linker can determine that only A::f can
> can be called by a particular program, then it need not link g or h
> into the resulting executable.
>
> Addressing Howard's original question, if your program never formats
> a floating-point number, then num_put<char>::put(..., double) cannot
> be called, and the linker can omit that function from the executable.
> In the big world of shared libraries this may not make a lot of
> difference, but in embedded systems it can make a great difference.
I'm not clear on how A::f or num_put<char>::do_put(..., double) are
specific cases that differentiate themselves from the general problem
(which is now stated to be impossible). In num_put's case, it could be
called from num_put<char>::put(..., double) (as would be normal), or the
user could call it from a class derived from num_put.
Are you suggesting that the compiler have hardwired knowledge of num_put?
Check for num_put::put instantiation, and only then decide to instantiate
num_put::do_put? And also check for any class derived from num_put that
might call num_put::do_put?
And do the same for the other 100 or so standard virtual members?
-Howard
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: phalpern@truffle.ma.ultranet.com (Pablo Halpern)
Date: 1998/05/15 Raw View
ncm@nospam.cantrip.org (Nathan Myers) wrote:
>"Embedded C++", as it's being promoted, is an exercise in just such
>finger-pointing. Eventually some consortium members will implement
>conforming (even efficient) compilers. Then the official "Embedded C++"
>subset will be forgotten, and their customers (like the rest of us)
>will be able to use whatever language subset matches their needs,
>without need for a special blessing. In the meantime, those vendors
>try to make a virtue of having a less-efficient, non-conforming
>implementation by slapping on a catchy tag.
>
>There's not *much* wrong with selling that snake oil -- business is
>war, and all that -- but that doesn't mean you have to swallow it.
Well, a simple rule of business is that a non-optimal solution today is
better than a perfect solution tomorrow. I wouldn't consider offering an
efficient, though slightly kludgy library subset to be snake oil, if it
makes your project come in a year sooner or cuts $50 in memory off the
cost of each unit produced. Done right, a better solution can be plugged
right in when it becomes available.
>A compiler vendor who has completed a fully-conforming implementation
>can spend attention on optimizing its output. Those who are way behind
>must spend it on catching up. Your programs can benefit by using exactly
>the language subset you need and taking advantage of those optimizations,
>rather than by working around the holes in a language spec arbitrarily
>curtailed to match what the laggards have already got implemented.
I wouldn't consider those who consider a low bug count to be higher
priority than optimizations and bells and wistles to be "laggards."
Until FDIS, the standard was a moving target. Writing an
industrial-strength compiler that handles all of the intricacies of
templates and exceptions AND which compiles and links efficient,
low-bloat code is much harder than implementing a subset of the library
that doesn't stretch the compiler's capabilities too much. The library
can be done today. The excellent compiler will take a while, even with
non-laggards doing the work.
One other thing. Most compilers are designed for hosted environments
like Windows and Unix, where code bloat can be mitigated by using DLLs,
and virtual memory. The compiler vendors are more likely to optimize
other aspects of the compiler before they aggressively attack code
bloat. This leaves the imbedded systems vendor with few good compiler
choices. The use of something like EC++ can make life much more livable
for them.
P.S. I don't know anything about EC++ except what I have read in a few
articles in this newsgroup.
-------------------------------------------------------------
Pablo Halpern phalpern@truffle.ultranet.com
I am self-employed. Therefore, my opinions *do* represent
those of my employer.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/05/15 Raw View
Howard Hinnant<hinnant@_anti-spam_lightlink.com> wrote:
>In article <6jcpnj$ikg$1@shell7.ba.best.com>, ncm@nospam.cantrip.org
>(Nathan Myers) wrote:
>>
>> ... if a class A has virtual member functions A::f, A::g,
>> and A::h, and the compiler/linker can determine that only A::f can
>> can be called by a particular program, then it need not link g or h
>> into the resulting executable.
>>
>> ... if your program never formats
>> a floating-point number, then num_put<char>::put(..., double) cannot
>> be called, and the linker can omit that function from the executable.
>
>I'm not clear on how A::f or num_put<char>::do_put(..., double) are
>specific cases that differentiate themselves from the general problem
>(which is now stated to be impossible). In num_put's case, it could be
>called from num_put<char>::put(..., double) (as would be normal), or the
>user could call it from a class derived from num_put.
>
>Are you suggesting that the compiler have hardwired knowledge of num_put?
It's not much different from what the linker does anyway: if you
don't call setlocale(), then when the linker examines all the
object files and finds no reference to setlocale(), it doesn't link
that in. If your program never references the vtbl slot occupied by
num_put<char>::put(...,double), then a good linker can simply leave
that slot empty.
It's not rocket science. Furthermore, it would be a terribly helpful
optimization for any program that uses library virtual functions,
regardless of whether it uses the standard library. Any compiler
that doesn't implement this optimization really isn't doing much for
embedded system builders, regardless of what a vendor might trumpet
in its advertising.
(Of course a compiler vendor who has already implemented the full
standard is much more likely to be equipped to respond to a request
for this optimization, because they are not frantically trying to
catch up on getting the core language features working.)
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/05/15 Raw View
Pablo Halpern<phalpern@truffle.ma.ultranet.com> wrote:
>ncm@nospam.cantrip.org (Nathan Myers) wrote:
>
>>"Embedded C++", as it's being promoted, is an exercise in just such
>>finger-pointing. ... vendors try to make a virtue of having
>>a less-efficient, non-conforming implementation by slapping on a
>>catchy tag.
>>
>>There's not *much* wrong with selling that snake oil -- business is
>>war, and all that -- but that doesn't mean you have to swallow it.
>
>Well, a simple rule of business is that a non-optimal solution today is
>better than a perfect solution tomorrow. I wouldn't consider offering an
>efficient, though slightly kludgy library subset to be snake oil, if ...
Of course. It's snake oil only if they lie about what it is.
Most participants in the Embedded C++ consortium are not liars.
But much of what has been published has implied that they were
selling incomplete implementations to avoid imposing a mythical
"unavoidable overhead", where in fact they are selling incomplete
implementations mainly because that's all they have to sell.
The lie harms those who implement the full language and avoid the
mythical "unavoidable overhead". It harms those who believe the
myth and unnecessarily shoehorn their designs into a language subset
arbitrarily chosen by compiler vendors for their own convenience.
Overhead is a real problem on many implementations, but the techniques
to eliminate it are not terribly difficult, and are entirely compatible
with the full standard language. Some of the best and simplest (e.g.
eliminating virtual functions that cannot be called) don't appear in
the compilers sold by "Embedded C++" vendors. This demonstrates their
true nature.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: hinnant@_anti-spam_lightlink.com (Howard Hinnant)
Date: 1998/05/15 Raw View
In article <6jgccf$4d7$1@shell7.ba.best.com>, ncm@nospam.cantrip.org
(Nathan Myers) wrote:
> It's not much different from what the linker does anyway: if you
> don't call setlocale(), then when the linker examines all the
> object files and finds no reference to setlocale(), it doesn't link
> that in. If your program never references the vtbl slot occupied by
> num_put<char>::put(...,double), then a good linker can simply leave
> that slot empty.
Sounds very interesting... Not being a compiler/linker expert, I
anxiously await comments (pro or con) from those who are.
-Howard
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/05/15 Raw View
Pete Becker wrote:
>
> Nathan Myers wrote:
> >
> > Of course, any implementation can have this optimization; it doesn't
> > depend on any restricted subset of the language.
>
> Of course, no compiler does that today, so if you're stuck trying to fit
> 80k of code into 16k of ROM you may well want a restricted subset of the
> language. Speculation about what might happen at some unspecified time
> in the future won't get your product out the door.
Neither will suggesting changes to the language standard. The thing to
do is complain to your compiler vendor about the poor quality of
implementation; point out that it can be done better.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/05/15 Raw View
Paul D. DeRocco wrote:
...
> that practically all of it will turn out to be needed anyway, and it's
> faster to load it in one fell swoop. (Is there any other kind of swoop,
> by the way?)
Yes, you can also have a slow, clumsy swoop; it doesn't tend to impress
anybody, though ;-) For example, I declared a million element array, to
be initialized with {0}. The compiler happily created the equivalent of
a seperate assignment statement to initialize each element of the array.
That's not quite what I'd wanted :-{.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/05/16 Raw View
In article <6jf2eg$ds5$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
writes:
>I think that embedded C++ is largely a question of expectations -- we all
>know that some features of C++ are more expensive than others, and that
>in some applications, this expense is not acceptable.
So don't use these features in your application. The overhead goes away,
no?
--
Mike Davies
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/16 Raw View
Nathan Myers wrote:
>
>
> It's not much different from what the linker does anyway: if you
> don't call setlocale(), then when the linker examines all the
> object files and finds no reference to setlocale(), it doesn't link
> that in. If your program never references the vtbl slot occupied by
> num_put<char>::put(...,double), then a good linker can simply leave
> that slot empty.
It's quite a bit different. The linker does not make decisions about
what identifiers are needed. The compiler generates a list for each
translation unit, and the linker simply finds things from that list.
Adding the capability to decide that something the compiler thought it
needed isn't really needed is a big step.
> It's not rocket science. Furthermore, it would be a terribly helpful
> optimization for any program that uses library virtual functions,
> regardless of whether it uses the standard library. Any compiler
> that doesn't implement this optimization really isn't doing much for
> embedded system builders, regardless of what a vendor might trumpet
> in its advertising.
I don't know of any compiler today that does this "optimization", nor
have I heard any rumors of compilers that will do this in the near
future. It's hard to do, and even harder to do efficiently. Unless, of
course, you want to scrap separate translation. That's a high price to
pay.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/05/17 Raw View
greg<yo@mama.com> wrote:
>> There is a great deal that the library writer can do to minimize
>> overhead in the library. ... Help from the compiler makes it easier,
>> but pointing fingers (at the standard, or at compilers) is easier yet.
>> "Embedded C++", as it's being promoted, is an exercise in just such
>> finger-pointing. ... those vendors
>> try to make a virtue of having a less-efficient, non-conforming
>> implementation by slapping on a catchy tag.
>
>I agree that there should be no need for an embeddable subset of the
>C++ language, but it is perfectly reasonable to have an embeddable
>subset of the C++ library.
It's reasonable (and essential!) to have *many* embeddable subsets of
the C++ library. But you, the programmer, should choose, and not let
some cabal of backward compiler vendors choose for you.
You choose by using the standard features you need, and not using the
ones you don't. It's the compiler vendor's job to link in the ones
you use, and not the ones you don't. If they don't do their job, what
are you paying them for?
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/05/17 Raw View
Pete Becker <petebecker@acm.org> wrote:
>Nathan Myers wrote:
>> It's not rocket science. Furthermore, it would be a terribly helpful
>> optimization for any program that uses library virtual functions,
>> regardless of whether it uses the standard library. Any "Embedded C++"
>> compiler that doesn't implement this optimization really isn't doing
>> much for embedded system builders, regardless of what a vendor might
>> trumpet in its advertising.
>
>I don't know of any compiler today that does this "optimization", nor
>have I heard any rumors of compilers that will do this in the near
>future. It's hard to do, and even harder to do efficiently. Unless, of
>course, you want to scrap separate translation. That's a high price to
>pay.
It took Richard Henderson a couple of days to implement. He didn't
say it was "hard to do", and it is both efficient and supports
separate compilation. Now, Richard is practically a god among men,
but it shouldn't take an ordinary compiler hack more than a week
or two.
Conceptually: if the only reference to a virtual function is from a
vtbl cell, and no object file in the complete program mentions that
cell, then the virtual function itself need not be linked. As I said,
not rocket science. Modern ELF linkers do far more complicated things
with (more-or-less) ordinary C code.
That Pete hasn't heard of any compilers that "will do this in the near
future" suggests to me that he doesn't know of any compiler vendors
who *really* are interested in the *real* needs of *real* embedded-system
builders. That's not Pete's fault, of course, but as an embedded-system
builder I'd be very disappointed in the performance of the compiler
vendors he does know.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/05/07 Raw View
In article <3550233A.185E@pratique.fr>#1/1,
Valentin Bonnard <bonnardv@pratique.fr> wrote:
> A conforming implementation may also simply copy the whole
> C++ std library in the executable; it could even be interresting
> if it speeds-up links.
Isn't this the status quo today, at least on most systems? I haven't
checked it to be sure, but I would imagine that libc is a (single) DLL;
if it isn't yet the case for the C++ library, it is probably because of
the lack of stability, even in the interface.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1998/05/09 Raw View
Christopher Eltschka wrote:
>
> Howard Hinnant wrote:
>
> [...]
>
> > #include <iostream>
> >
> > int main()
> > {
> > std::cout << "How big am I?\n";
> > }
> >
> > A conforming implementation may well stuff into this executable all of the
> > code to read and write integers, floating point numbers, money, time,
> > collation, character classification and messaging, even though this code
> > is all templated, and never used (that's for both char streams, and to the
> > newer whar_t streams). No wonder C++ has gotten a reputation for bloated
> > applications!! Why don't we just go ahead and build a *&@#% runtime
> > environment! <sarcasm>
>
> Well, I'd say this is a quality of implementation issue.
Partly. But it's very hard to write library code that doesn't pull in a
large amount of code that the application doesn't actually use, and gets
all the semantics of locales correct. That's part of the reasoning
behind the Japanese notion of Embedded C++ (EC++), in which iostreams
are not templates and do not support locales. For most consumer
appliances you don't need the missing capabilities, and the size savings
are significant.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: hinnant@_anti-spam_lightlink.com (Howard Hinnant)
Date: 1998/05/05 Raw View
Hi,
I'm afraid I've stumbled across a fairly large flaw in <locale>. I'm
hoping someone (maybe Nathan?) can set me straight...
First, some background on class templates with virtual methods:
<quote>
9 An implementation shall not implicitly instantiate a function tem-
plate, a member template, a non-virtual member function, a member
class or a static data member of a class template that does not
require instantiation. It is unspecified whether or not an implemen-
tation implicitly instantiates a virtual member function of a class
template if the virtual member function would not otherwise be instan-
tiated.
<end quote>
Summary: a conforming implementation may implicitly instantiate all
virtual members of all instantiated template classes, even though the
virtual members may never be used.
Now some background on a typical facet:
template <class charT>
class Typical_Facet
: public locale::facet
{
public:
explicit Typical_Facet(size_t refs = 0);
charT something() const {return do_something();}
protected:
virtual charT do_something() const;
};
And finally a note about the default (or classic) locale: It constructs
(instantiates) at least two flavors (char and wchar_t) of every standard
facet.
A typical <locale> implementation is quite large, and mostly templated.
The facets in <locale> contain all of the instructions on how to read and
write integers, floating point numbers, money and time. Additionally
there are facets for collating, character classification and messages.
All of this knowledge is found under the facet virtual members
(do_something()).
Since the classic locale instantiates every standard facet for both char
and wchar_t, a conforming implementation may well instantiate 95% of the
templated code in <locale> (twice). I estimate this code to be
approximately several hundred Kb on a typical platform.
Let's look at a familiar example:
#include <iostream>
int main()
{
std::cout << "How big am I?\n";
}
A conforming implementation may well stuff into this executable all of the
code to read and write integers, floating point numbers, money, time,
collation, character classification and messaging, even though this code
is all templated, and never used (that's for both char streams, and to the
newer whar_t streams). No wonder C++ has gotten a reputation for bloated
applications!! Why don't we just go ahead and build a *&@#% runtime
environment! <sarcasm>
As I see it, an implementation either MUST NOT automatically instantiate
virtual members of template classes, or standard facets MUST NOT have
virtual members. Else we have a language that's too fat to be useful.
I'm not smart enough about compilers to know if the former is feasable. I
do think we could live with the latter.
Or perhaps we just have a language in which I/O is not feasible. Could
this be the major cause of the EC++ movement?
Hoping to hear I'm wrong...
-Howard
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/05/05 Raw View
Howard Hinnant wrote:
[...]
> #include <iostream>
>
> int main()
> {
> std::cout << "How big am I?\n";
> }
>
> A conforming implementation may well stuff into this executable all of the
> code to read and write integers, floating point numbers, money, time,
> collation, character classification and messaging, even though this code
> is all templated, and never used (that's for both char streams, and to the
> newer whar_t streams). No wonder C++ has gotten a reputation for bloated
> applications!! Why don't we just go ahead and build a *&@#% runtime
> environment! <sarcasm>
Well, I'd say this is a quality of implementation issue. Note that
an implementation is also allowed to include all functions from a
library
into the executable, even if you just reference a static char variable
of it. Indeed, if you replace "library" by "object file", this is
actually what compilers do today (this is the reason why libraries
usually consist of a huge bunch of small object files).
However, I guess any sensible implementation which does not support
on-demand instantiation of virtual functions would put all of those
virtual standard functions into a shared std library (together with
all this non-templated stuff which belongs to a C++ implementation).
So the actual program code would be small again.
Also note that C suffers from a similar effect: Take the program:
#include <stdio.h>
int main()
{
printf("Hello world\n");
}
This harmless program will probably include
- code for handling of varargs
- code for parsing the printf format string (although you don't use
the formatting features)
- string handling functions (to support the parsing)
- code for formatting ints, chars, char*s, floats, doubles
- heap management routines (it's usual for printf to use malloc/free,
maybe also realloc)
- code for file handling
- did I forget something?
[...]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Valentin Bonnard <bonnardv@pratique.fr>
Date: 1998/05/06 Raw View
Howard Hinnant wrote:
> I'm afraid I've stumbled across a fairly large flaw in <locale>.
Well, I don't think so.
> Summary: a conforming implementation may
It may generate a table of size N for a switch with two cases 0
and N (for large values of N). It may do very silly things (and
remain conforming). You can also switch to one which doesn't.
> Now some background on a typical facet:
>
> template <class charT>
> class Typical_Facet
> : public locale::facet
> {
> public:
> explicit Typical_Facet(size_t refs = 0);
> charT something() const {return do_something();}
> protected:
> virtual charT do_something() const;
> };
Using non-virtual public members to call virtual protected
ones is a useful idiom, I use it, but the locales don't seem
to get anything from it (no filtering, nothing is done in
xxx except calling do_xxx).
> The facets in <locale> contain all of the instructions on how to read and
> write integers, floating point numbers, money and time.
> I estimate this code to be
> approximately several hundred Kb on a typical platform.
>
> Let's look at a familiar example:
>
> #include <iostream>
>
> int main()
> {
> std::cout << "How big am I?\n";
> }
>
> A conforming implementation may
A conforming implementation may also simply copy the whole
C++ std library in the executable; it could even be interresting
if it speeds-up links.
> well stuff into this executable all of the
> code to read and write integers, floating point numbers, money, time,
> collation, character classification and messaging, even though this code
> is all templated, and never used (that's for both char streams, and to the
> newer whar_t streams).
The problem is worse with printf, with which you don't know what
types are printed, so you must include all the floating point library
(in case of fp emulation).
> Hoping to hear I'm wrong...
Some vendors consider code bload as a non issue and won't
do anything about that. Other won't include unused functions.
--
Valentin Bonnard mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]