What's wrong with the current C++ compiler?

QNX Newsgroups (Archives) qdn.public.qnxrtp.devtools
1

Possible dumb question department…

I read with some concern the posts claiming that the GNU C++ compiler is not
very good, and their development website which puts a ‘new improved’ C++
compiler as one of their main priorities. Also, there seems to be a
hankering after the Comceau C++ compiler even though it is only a translator
(correct me if I’m wrong).

Would those in the know please tell me what is wrong with the current
compiler? Compared with Watcom on QNX4 it its painfully slow I know, and I
have suspicions about executable size and speed of execution, particularly
with Photon, but these may not be compiler issues.

As someone who hasn’t written a vanilla C application in years, should I be
worried?

Jim Douglas

2

In article <9ounll$4mf$1@inn.qnx.com>, Jim Douglas <jim@dramatec.co.uk> wrote:

Possible dumb question department…

I read with some concern the posts claiming that the GNU C++ compiler is not
very good, and their development website which puts a ‘new improved’ C++
compiler as one of their main priorities. Also, there seems to be a
hankering after the Comceau C++ compiler even though it is only a translator
(correct me if I’m wrong).

Would those in the know please tell me what is wrong with the current
compiler? Compared with Watcom on QNX4 it its painfully slow I know, and I
have suspicions about executable size and speed of execution, particularly
with Photon, but these may not be compiler issues.

As someone who hasn’t written a vanilla C application in years, should I be
worried?

I’m not a QNX programmer… yet:) … and so I’m not qualified
to detail all the specifics. But, I’ve heard conflicting information
here about the performance of gcc, both in compile time and
execution code for the code it generates. I have not heard anthing
else specific except normal/general things about gcc on any platform.

Re “new and improved” gcc, well, Comeau is already there. But of course,
we are not yet available for QNX. But of course too, neither is the
alledged new and improved gcc. Our product is real, it’s just
the port that is not, and getting it to QNX is not trivial, but it
can be accomplished in a significantly shorter time frame than
obtaining the equivalent gcc.

This is not to slash gcc. IMO, even if it were available and fine,
there’s nothing better than having a choice, even if it’s not
Comeau C++.

As to Comeau being “only a translator”, well, then, any compiler
is just that. So if you “only” want a quality one, then we’re
the choice, as others have said. Look, we’re years ahead of
the other vendors not only in all the features that we support,
but in getting the features right, and w/o the compiler aborting or
something like that.

So, we can talk about what vendors are doing, but we can
also talk about what’s already available and quite tangible.
Similarly, we can talk about 1/2 supporting features, or we
can talk about supporting them completely and correctly.

So, yes, while speed of compilation and executable performance
are significant, so are other things. Comeau + Dinkumware
already is capable of supporting all of C90, C99 and almost
all of C++ except export. Those’s parts are done and known
entities. Imagine what’s next? :slight_smile:

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?

3

G++ isn’t that bad. Personally, I like it much better than the Watcom
compiler, since I value standard compliance, and g++ is much closer than
Watcom is. I would love to see Comeau C++ since it is reportedly one of
the closest compilers to the ISO standard. I have no problem with the
concept of emitting C as object code, if it is done well (I think some
perceive the concept as bad, simply because they have encountered a poor
implementation).

For now, I continue to use g++ and besides compiles that take forever, I
am pretty happy.

-----Original Message-----
From: Jim Douglas [mailto:jim@dramatec.co.uk]
Posted At: Thursday, September 27, 2001 1:25 AM
Posted To: devtools
Conversation: What’s wrong with the current C++ compiler?
Subject: What’s wrong with the current C++ compiler?


Possible dumb question department…

I read with some concern the posts claiming that the GNU C++ compiler is
not
very good, and their development website which puts a ‘new improved’ C++
compiler as one of their main priorities. Also, there seems to be a
hankering after the Comceau C++ compiler even though it is only a
translator
(correct me if I’m wrong).

Would those in the know please tell me what is wrong with the current
compiler? Compared with Watcom on QNX4 it its painfully slow I know,
and I
have suspicions about executable size and speed of execution,
particularly
with Photon, but these may not be compiler issues.

As someone who hasn’t written a vanilla C application in years, should I
be
worried?

Jim Douglas

4

I agree with you. Especially with the dinkum libraries I find gnu C++
to be quite a good compiler.

Gregor


Rennie Allen wrote:

G++ isn’t that bad. Personally, I like it much better than the Watcom
compiler, since I value standard compliance, and g++ is much closer than
Watcom is. I would love to see Comeau C++ since it is reportedly one of
the closest compilers to the ISO standard. I have no problem with the
concept of emitting C as object code, if it is done well (I think some
perceive the concept as bad, simply because they have encountered a poor
implementation).

For now, I continue to use g++ and besides compiles that take forever, I
am pretty happy.

-----Original Message-----
From: Jim Douglas [mailto:> jim@dramatec.co.uk> ]
Posted At: Thursday, September 27, 2001 1:25 AM
Posted To: devtools
Conversation: What’s wrong with the current C++ compiler?
Subject: What’s wrong with the current C++ compiler?


Possible dumb question department…

I read with some concern the posts claiming that the GNU C++ compiler is
not
very good, and their development website which puts a ‘new improved’ C++
compiler as one of their main priorities. Also, there seems to be a
hankering after the Comceau C++ compiler even though it is only a
translator
(correct me if I’m wrong).

Would those in the know please tell me what is wrong with the current
compiler? Compared with Watcom on QNX4 it its painfully slow I know,
and I
have suspicions about executable size and speed of execution,
particularly
with Photon, but these may not be compiler issues.

As someone who hasn’t written a vanilla C application in years, should I
be
worried?

Jim Douglas
\

5

“Jim Douglas” <jim@dramatec.co.uk> wrote in message
news:9ounll$4mf$1@inn.qnx.com…

Possible dumb question department…

I read with some concern the posts claiming that the GNU C++ compiler is
not
very good, and their development website which puts a ‘new improved’ C++
compiler as one of their main priorities. Also, there seems to be a
hankering after the Comceau C++ compiler even though it is only a
translator
(correct me if I’m wrong).

Would those in the know please tell me what is wrong with the current
compiler? Compared with Watcom on QNX4 it its painfully slow I know, and
I
have suspicions about executable size and speed of execution, particularly
with Photon, but these may not be compiler issues.

I have 4 main problems with g++, listed in order of annoyance:

  1. Executable size - with template code the executables are often truly
    enormous. This is partly due to the inability of the compiler to remove
    duplicate instantiations of templates in separate compilation units.
  2. Compiler bugs - I see “Internal compiler error” with alarming regularity.
    Workarounds have wasted me hours.
  3. Compile speed - with the addition of the Dinkumware libraries this has
    actually got a lot worse (I was using STLport before which compiled much
    quicker).
  4. Conformance - g++ isn’t too bad here if used with Dinkumware or STLport,
    but there are a number of missing features that annoy me. Still, it is
    heaven having inhabited the massively unconforming MSVC++6 world in Windows.

I think Comeau will address 1 a bit (it won’t generate duplicate
instantiations and it will probably improve once the conformance is 100%), 2
very well, 3 I’m not sure about and 4 very well.

As for executable speed, I am “happy” with g++ having nothing else to
compare it against on QNX. g++ tests on cygwin seem to demonstrate that
overall it is overall only a little slower than MSVC++6 - slower at some
things, faster at others. I expect Comeau C++ to produce slightly slower
executables than g++, but I also expect this to improve over the next year
or so.

Tom

6

Isn’t #1 a linker issue? I thought there was a segment type that said that
if a segment was the sxame name is included to just ignore it.

Does that exist in the GNU linker?

“Tom” <tom_usenet@hotmail.com> wrote in message
news:9pdog7$el7$1@inn.qnx.com…

“Jim Douglas” <> jim@dramatec.co.uk> > wrote in message
news:9ounll$4mf$> 1@inn.qnx.com> …
Possible dumb question department…

I read with some concern the posts claiming that the GNU C++ compiler is
not
very good, and their development website which puts a ‘new improved’ C++
compiler as one of their main priorities. Also, there seems to be a
hankering after the Comceau C++ compiler even though it is only a
translator
(correct me if I’m wrong).

Would those in the know please tell me what is wrong with the current
compiler? Compared with Watcom on QNX4 it its painfully slow I know,
and
I
have suspicions about executable size and speed of execution,
particularly
with Photon, but these may not be compiler issues.

I have 4 main problems with g++, listed in order of annoyance:

  1. Executable size - with template code the executables are often truly
    enormous. This is partly due to the inability of the compiler to remove
    duplicate instantiations of templates in separate compilation units.
  2. Compiler bugs - I see “Internal compiler error” with alarming
    regularity.
    Workarounds have wasted me hours.
  3. Compile speed - with the addition of the Dinkumware libraries this has
    actually got a lot worse (I was using STLport before which compiled much
    quicker).
  4. Conformance - g++ isn’t too bad here if used with Dinkumware or
    STLport,
    but there are a number of missing features that annoy me. Still, it is
    heaven having inhabited the massively unconforming MSVC++6 world in
    Windows.

I think Comeau will address 1 a bit (it won’t generate duplicate
instantiations and it will probably improve once the conformance is 100%),
2
very well, 3 I’m not sure about and 4 very well.

As for executable speed, I am “happy” with g++ having nothing else to
compare it against on QNX. g++ tests on cygwin seem to demonstrate that
overall it is overall only a little slower than MSVC++6 - slower at some
things, faster at others. I expect Comeau C++ to produce slightly slower
executables than g++, but I also expect this to improve over the next year
or so.

Tom

7

In article <9pecaq$ou2$1@inn.qnx.com>,
Bill Caroselli (Q-TPS) <qtps@earthlink.net> wrote:

Isn’t #1 a linker issue? I thought there was a segment type that said that
if a segment was the sxame name is included to just ignore it.

Does that exist in the GNU linker?

Some compiler/linkers do do something like that. But it’s an
implementation detail, and it’s not the only way to address the issue.

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?

8

Greg Comeau <comeau@panix.com> wrote:

In article <9pecaq$ou2$> 1@inn.qnx.com> >,
Bill Caroselli (Q-TPS) <> qtps@earthlink.net> > wrote:
Isn’t #1 a linker issue? I thought there was a segment type that said that
if a segment was the sxame name is included to just ignore it.

Does that exist in the GNU linker?

Some compiler/linkers do do something like that. But it’s an
implementation detail, and it’s not the only way to address the issue.

Ahh, I’ve checked out GNU ld under QNX and it does seem to collapse
together duplicate instantiations after all (try compiling with
-W1,–warn-common in the g++ link step to get a list of the merged
duplicate instantiations).

So the executable size must be down to something else. I think what is
needed is a clever template instantiation manager that has the ability
to merge “similar” instantiations. In addition, a virtual function
model that didn’t rely solely on vtables might generate considerably
smaller (not to mention faster) exes.

This paper elaborates some interesting ideas:

http://extreme.indiana.edu/~tveldhui/papers/2000/tmpw00/index.html

In addition, the SmallEiffel compiler uses non-vtable techniques for
polymorphism that could probably be used by a C++ compiler, although
dynamically loaded objects could cause problems with this.

Greg, do you have any plans in these directions?

A simple but possibly not particularly useful optimisation is this:
If two different template instantiations generate identical code,
then they could be merged at the very least.

Tom

9

“Tom” <tom_usenet@hotmail.com> wrote in message
news:9pdog7$el7$1@inn.qnx.com…

I have 4 main problems with g++, listed in order of annoyance:

  1. Executable size - with template code the executables are often truly
    enormous. This is partly due to the inability of the compiler to remove
    duplicate instantiations of templates in separate compilation units.
  2. Compiler bugs - I see “Internal compiler error” with alarming
    regularity.
    Workarounds have wasted me hours.
  3. Compile speed - with the addition of the Dinkumware libraries this has
    actually got a lot worse (I was using STLport before which compiled much
    quicker).
  4. Conformance - g++ isn’t too bad here if used with Dinkumware or
    STLport,
    but there are a number of missing features that annoy me. Still, it is
    heaven having inhabited the massively unconforming MSVC++6 world in
    Windows.
    …

I’m convinced the problems with executable size and compiler speed (not just
executables, actually but all object code) are caused by the use of the new
C++ header files in 6.1. A simple “hello world” program that uses
compiles to about 5k on 6.0 and 24k on 6.1. Compilation also
takes 7 times longer on 6.1.

A “hello world” program that uses instead of compiles to
about 4.5k on both systems and takes about the same amount of time. So it’s
not the compiler that is at fault.

However, we’re building embedded systems here and the excessive object code
and executable size is a complete show-stopper for us. Until 6.1 we’ve been
able to build reasonably compact embedded software using C++. We can’t move
to 6.1 until the Gnu C++ library, or another that generates smaller code
sizes is ported.

The internal compile errors are much more prevalent in the 6.1 version but
in my experience these all occur in the generation of debug code under the
compiler option -g. If you use -gdwarf-2 the problems go away; you also get
better behaviour out of gdb as a result.

Ken Appleby
Soft Optics Ltd

10

Ken Appleby <ken@soft-optics.co.uk> wrote:

“Tom” <> tom_usenet@hotmail.com> > wrote in message
news:9pdog7$el7$> 1@inn.qnx.com> …

I have 4 main problems with g++, listed in order of annoyance:

  1. Executable size - with template code the executables are often truly
    enormous. This is partly due to the inability of the compiler to remove
    duplicate instantiations of templates in separate compilation units.
  2. Compiler bugs - I see “Internal compiler error” with alarming
    regularity.
    Workarounds have wasted me hours.
  3. Compile speed - with the addition of the Dinkumware libraries this has
    actually got a lot worse (I was using STLport before which compiled much
    quicker).
  4. Conformance - g++ isn’t too bad here if used with Dinkumware or
    STLport,
    but there are a number of missing features that annoy me. Still, it is
    heaven having inhabited the massively unconforming MSVC++6 world in
    Windows.
    …

I’m convinced the problems with executable size and compiler speed (not just
executables, actually but all object code) are caused by the use of the new
C++ header files in 6.1. A simple “hello world” program that uses
iostream> compiles to about 5k on 6.0 and 24k on 6.1. Compilation also
takes 7 times longer on 6.1.

A “hello world” program that uses instead of compiles to
about 4.5k on both systems and takes about the same amount of time. So it’s
not the compiler that is at fault.

However, we’re building embedded systems here and the excessive object code
and executable size is a complete show-stopper for us. Until 6.1 we’ve been
able to build reasonably compact embedded software using C++. We can’t move
to 6.1 until the Gnu C++ library, or another that generates smaller code
sizes is ported.

The change in header files to 6.1 was a bit of a different change for
me that for you, since before I was using STLport, which also
produced quite large object code - only about 20% smaller than
Dinkumware.

Why are the executables so large? It comes down mainly to templated
library code. The old gcc headers use non-standard non-templated
iostreams/locales which means that the non-inline code could be
compiled into libstdc++. Templated code can’t in general be compiled
into a library, but must be compiled each time it is seen in the
header. Explicit specialisations for char and wchar_t of all templated
iostreams classes would remove most of this issue (both in compile
time and executable size), but unfortunately Dinkumware chose not to
add them, so they can’t be compiled into their shared library. This is
a quality of implementation issue, and besides conformance, I don’t
consider the Dinkumware implementation to be very good yet, although I
expect that their MSVC.NET port is better (because of the huge
royalties for that port I expect they took the time to use the dll
facilities of Windows to their full).

STLport has smaller executables because much more code seems to be
compiled into the shared library meaning that much less has to be
compiled into your own object code.

What can be done about large library size overhead?
http://www.dinkumware.com/libecpp.html details one approach - simply
have a standard embedded C++ library that does away with the
templated iostreams and string (not to mention the whole STL)
replacing them with non-templated ones. I really don’t think that
this hatchet approach would be necessary if the g++ Dinkumware
libraries were written with thought for code size. g++ has support
for a number of techniques to place specific instantiations of
templates in libraries (using the extern keyword in front of an
explicit template instantiation to forward declare it is one
technique). STLport uses this technique extensively and it has a good
effect on both compile times and object code sizes.

One interesting thing in the existence of a Standard Library
implementation that produces a 4k statically linked hello world
executable using g++ under Linux. How is this done? Ask Dietmar
Kuehl, author of the (unfortunately a little incomplete and
currently Linux only) standard library implementation cxxrt. You can
download it from: http://www.dietmar-kuehl.de/cxxrt/ although it’s
only any use in Linux. I may have a go at porting it to QNX, since it
would probably be the answer to some of our executable size and even
compile time problems. I expect this is quite a big job though.

So I agree that the Dinkumware library is mainly to blame. STLport
is only about 20% better (although the library .so it produces is
pretty huge), and there are no other standard libraries available on
QNX at present, so you must use the horrible non-standard g++ ones in
6.0 if you need small executables. If I decide I need it I will port
STLport to 6.1 QNX. The current dire compile times are pushing me
that way, although it was nice to be using the standard tool chain
for a while…

Standard C++ is not too big to use for embedded applications.
However, finding a compiler and library implementation that is up to
it is still very difficult. Personally I don’t want to use
non-standard C++, since our in house library code is much more useful
if it is portable.


The internal compile errors are much more prevalent in the 6.1 version but
in my experience these all occur in the generation of debug code under the
compiler option -g. If you use -gdwarf-2 the problems go away; you also get
better behaviour out of gdb as a result.

I don’t use -g but -gstabs+ (so that I can trace into inline code).
I’ve never had any compiler errors specific to using -gstabs+,
although I have had some from -O1/2/3 forcing me to compile some
files with no optimisation at all.

Tom

11

In article <9pfcto$eqb$1@inn.qnx.com>, <tom_usenet@hotmail.com> wrote:

Greg Comeau <> comeau@panix.com> > wrote:
In article <9pecaq$ou2$> 1@inn.qnx.com> >,
Bill Caroselli (Q-TPS) <> qtps@earthlink.net> > wrote:
Isn’t #1 a linker issue? I thought there was a segment type that said that
if a segment was the sxame name is included to just ignore it.

Does that exist in the GNU linker?

Some compiler/linkers do do something like that. But it’s an
implementation detail, and it’s not the only way to address the issue.

Ahh, I’ve checked out GNU ld under QNX and it does seem to collapse
together duplicate instantiations after all (try compiling with
-W1,–warn-common in the g++ link step to get a list of the merged
duplicate instantiations).

So the executable size must be down to something else. I think what is
needed is a clever template instantiation manager that has the ability
to merge “similar” instantiations.

We do something like that in that we don’t even generate them in
the first place.

In addition, a virtual function
model that didn’t rely solely on vtables might generate considerably
smaller (not to mention faster) exes.

This paper elaborates some interesting ideas:

http://extreme.indiana.edu/~tveldhui/papers/2000/tmpw00/index.html

In addition, the SmallEiffel compiler uses non-vtable techniques for
polymorphism that could probably be used by a C++ compiler, although
dynamically loaded objects could cause problems with this.

Greg, do you have any plans in these directions?

There is immense room for many things, and yes, we do have
such plans. There’s a lot of this kind of stuff which is
mostly not even attempted by anybody to date and it’s well
worth pursuing…

A simple but possibly not particularly useful optimisation is this:
If two different template instantiations generate identical code,
then they could be merged at the very least.

…As well, there are some things which can sometimes be done
at the code end of things by programmers which are not being done.

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?

12

In article <9phatm$jt4$1@inn.qnx.com>,
Ken Appleby <ken@soft-optics.co.uk> wrote:

“Tom” <> tom_usenet@hotmail.com> > wrote in message
news:9pdog7$el7$> 1@inn.qnx.com> …

I have 4 main problems with g++, listed in order of annoyance:

  1. Executable size - with template code the executables are often truly
    enormous. This is partly due to the inability of the compiler to remove
    duplicate instantiations of templates in separate compilation units.
  2. Compiler bugs - I see “Internal compiler error” with alarming
    regularity.
    Workarounds have wasted me hours.
  3. Compile speed - with the addition of the Dinkumware libraries this has
    actually got a lot worse (I was using STLport before which compiled much
    quicker).
  4. Conformance - g++ isn’t too bad here if used with Dinkumware or
    STLport,
    but there are a number of missing features that annoy me. Still, it is
    heaven having inhabited the massively unconforming MSVC++6 world in
    Windows.
    …
    nced the problems with executable size and compiler speed (not just
    executables, actually but all object code) are caused by the use of the new
    C++ header files in 6.1. A simple “hello world” program that uses
    iostream> compiles to about 5k on 6.0 and 24k on 6.1. Compilation also
    takes 7 times longer on 6.1.

I’m not convinced it’s the only cause, but surely it is one of them.

A “hello world” program that uses instead of compiles to
about 4.5k on both systems and takes about the same amount of time. So it’s
not the compiler that is at fault.

Maybe, maybe not.

However, we’re building embedded systems here and the excessive object code
and executable size is a complete show-stopper for us. Until 6.1 we’ve been
able to build reasonably compact embedded software using C++. We can’t move
to 6.1 until the Gnu C++ library, or another that generates smaller code
sizes is ported.

Yes, and this is significant for those apps/market.
This is a general problem vendors still need to address better.

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?

13

In article <9phov7$rkn$1@inn.qnx.com>, <tom_usenet@hotmail.com> wrote:

Ken Appleby <> ken@soft-optics.co.uk> > wrote:
“Tom” <> tom_usenet@hotmail.com> > wrote in message
news:9pdog7$el7$> 1@inn.qnx.com> …
I have 4 main problems with g++, listed in order of annoyance:

  1. Executable size - with template code the executables are often truly
    enormous. This is partly due to the inability of the compiler to remove
    duplicate instantiations of templates in separate compilation units.
  2. Compiler bugs - I see “Internal compiler error” with alarming
    regularity.
    Workarounds have wasted me hours.
  3. Compile speed - with the addition of the Dinkumware libraries this has
    actually got a lot worse (I was using STLport before which compiled much
    quicker).
  4. Conformance - g++ isn’t too bad here if used with Dinkumware or
    STLport,
    but there are a number of missing features that annoy me. Still, it is
    heaven having inhabited the massively unconforming MSVC++6 world in
    Windows.
    …

I’m convinced the problems with executable size and compiler speed (not just
executables, actually but all object code) are caused by the use of the new
C++ header files in 6.1. A simple “hello world” program that uses
iostream> compiles to about 5k on 6.0 and 24k on 6.1. Compilation also
takes 7 times longer on 6.1.

A “hello world” program that uses instead of compiles to
about 4.5k on both systems and takes about the same amount of time. So it’s
not the compiler that is at fault.

However, we’re building embedded systems here and the excessive object code
and executable size is a complete show-stopper for us. Until 6.1 we’ve been
able to build reasonably compact embedded software using C++. We can’t move
to 6.1 until the Gnu C++ library, or another that generates smaller code
sizes is ported.

The change in header files to 6.1 was a bit of a different change for
me that for you, since before I was using STLport, which also
produced quite large object code - only about 20% smaller than
Dinkumware.

Why are the executables so large? It comes down mainly to templated
library code. The old gcc headers use non-standard non-templated
iostreams/locales which means that the non-inline code could be
compiled into libstdc++. Templated code can’t in general be compiled
into a library, but must be compiled each time it is seen in the
header. Explicit specialisations for char and wchar_t of all templated
iostreams classes would remove most of this issue (both in compile
time and executable size), but unfortunately Dinkumware chose not to
add them, so they can’t be compiled into their shared library.

Although this is all true, I just can’t bring muself to agree that
there is a sole reason why the executable are so large with various
compilers.

This is a quality of implementation issue,

I agree that’s involved.

and besides conformance, I don’t

consider the Dinkumware implementation to be very good yet, although I
expect that their MSVC.NET port is better (because of the huge
royalties for that port I expect they took the time to use the dll
facilities of Windows to their full).

There is no perfect lib or perfect compiler yet (not even in C IMO)
but I think getting it correct is a quality of implementation issue
as well, so saying “besides conformance” is kinda not fairish.
That aside, I sure do with somebody combines the various lib
strategies going on. As well, as per the other email, there is
various things that a “compiler system” can do to help here that
is still untapped.

STLport has smaller executables because much more code seems to be
compiled into the shared library meaning that much less has to be
compiled into your own object code.

It’s still somewhere then though, and making it a shared lib
can have an effect, but I think that needs to be approached
judiciously.

What can be done about large library size overhead?
http://www.dinkumware.com/libecpp.html > details one approach - simply
have a standard embedded C++ library that does away with the
templated iostreams and string (not to mention the whole STL)
replacing them with non-templated ones. I really don’t think that
this hatchet approach would be necessary if the g++ Dinkumware
libraries were written with thought for code size. g++ has support
for a number of techniques to place specific instantiations of
templates in libraries (using the extern keyword in front of an
explicit template instantiation to forward declare it is one
technique). STLport uses this technique extensively and it has a good
effect on both compile times and object code sizes.

I don’t particularly prefer that approach either, but I do
also recognize that for some people it’s just the thing to do.

One interesting thing in the existence of a Standard Library
implementation that produces a 4k statically linked hello world
executable using g++ under Linux. How is this done? Ask Dietmar
Kuehl, author of the (unfortunately a little incomplete and
currently Linux only) standard library implementation cxxrt. You can
download it from: > http://www.dietmar-kuehl.de/cxxrt/ > although it’s
only any use in Linux. I may have a go at porting it to QNX, since it
would probably be the answer to some of our executable size and even
compile time problems. I expect this is quite a big job though.

Probably. OTOH, it shows what is potentially possible.

So I agree that the Dinkumware library is mainly to blame. STLport
is only about 20% better (although the library .so it produces is
pretty huge), and there are no other standard libraries available on
QNX at present, so you must use the horrible non-standard g++ ones in
6.0 if you need small executables. If I decide I need it I will port
STLport to 6.1 QNX. The current dire compile times are pushing me
that way, although it was nice to be using the standard tool chain
for a while…

Standard C++ is not too big to use for embedded applications.
However, finding a compiler and library implementation that is up to
it is still very difficult. Personally I don’t want to use
non-standard C++, since our in house library code is much more useful
if it is portable.

I agree that it’s not too big. However, lots of work still needs
to be done. As well, iostreams and exception handling are two of
the most obvious issues that need to be dealt with in this market.

Greg Comeau export ETA: Dec 1 10% “End of Summer” Offer
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware’s Libraries… Have you tried it?