I have just started playing with the “Abridged C++ library” (aka ecpp)
“alpha” release from developers.qnx.com.
While it does seem to go some way to addressing the compile speed and code
size issues, it seems to be missing some pretty fundamental pieces, the two
I have found so far being “cerr” and indeed “iostream” itself (although
“cin” and “cout” are present, as are “istream” and “ostream”).
Is this some kind of finger trouble on my part? Or maybe just a reflection
of the pre-release status of this code?
Surely “cerr” isn’t considered too heavy for an embedded application?
I have just started playing with the “Abridged C++ library” (aka ecpp)
“alpha” release from developers.qnx.com.
While it does seem to go some way to addressing the compile speed and code
size issues, it seems to be missing some pretty fundamental pieces, the two
I have found so far being “cerr” and indeed “iostream” itself (although
“cin” and “cout” are present, as are “istream” and “ostream”).
Is this some kind of finger trouble on my part? Or maybe just a reflection
of the pre-release status of this code?
Surely “cerr” isn’t considered too heavy for an embedded application?
I have just started playing with the “Abridged C++ library” (aka ecpp)
“alpha” release from developers.qnx.com.
While it does seem to go some way to addressing the compile speed and code
size issues, it seems to be missing some pretty fundamental pieces, the two
I have found so far being “cerr” and indeed “iostream” itself (although
“cin” and “cout” are present, as are “istream” and “ostream”).
Is this some kind of finger trouble on my part? Or maybe just a reflection
of the pre-release status of this code?
Surely “cerr” isn’t considered too heavy for an embedded application?
Yup. It (iostreams), was probably dropped because it can throw
exceptions, which means all the runtime exception handling stuff has to
be there.
My personal opinion ? if an embedded system is so resource or demand
constrained, that exceptions aren’t viable, then you have to seriously
consider coding everything in ‘C’. The good news ? Most embedded
systems are not so constrained. The bad news ? you can’t use the
Abridged library to speed up compiles, and reduce size on embedded
systems, that have sufficient resources for C++ (i.e. you can’t have
your cake and eat it to
I have just started playing with the “Abridged C++ library” (aka ecpp)
“alpha” release from developers.qnx.com.
While it does seem to go some way to addressing the compile speed and
code
size issues, it seems to be missing some pretty fundamental pieces, the
two
I have found so far being “cerr” and indeed “iostream” itself (although
“cin” and “cout” are present, as are “istream” and “ostream”).
Is this some kind of finger trouble on my part? Or maybe just a
reflection
of the pre-release status of this code?
Surely “cerr” isn’t considered too heavy for an embedded application?
I haven’t measured the overhead of having a cerr but I can’t imagine it’s
very much. Dropping clog might be worthwhile - who actually uses that? But
cerr is used a lot…
Yup. It (iostreams), was probably dropped because it can throw
exceptions, which means all the runtime exception handling stuff has to
be there.
No, just the class “iostream” has been dropped (equivalent to the
basic_iostream template from the full library), and this was purely to
remove the need for virtual inheritence of istream and ostream from ios. I
assume virtual inheritence is expensive enough to be worth removing from the
library. Similarly, “fstream” and “stringstream” have been dropped. You have
to use e.g. ifstream and ofstream instead.
My personal opinion ? if an embedded system is so resource or demand
constrained, that exceptions aren’t viable, then you have to seriously
consider coding everything in ‘C’. The good news ? Most embedded
systems are not so constrained. The bad news ? you can’t use the
Abridged library to speed up compiles, and reduce size on embedded
systems, that have sufficient resources for C++ (i.e. you can’t have
your cake and eat it to >
The Abridged library does actually have full exception support. I would
suspect an option to turn it off will be offered though - it is an option
according to Dinkumware’s website.
Ok… I really didn’t want to start a religious war about what should or
shouldn’t be included in a C++ library that is intended for embedded
systems.
I was coming from the perspective of someone who was merely looking for some
light at the end of the “it takes 10 times longer to compile” tunnel. It had
been mentioned that the “Abridged” library might provide that, but it seems
that it only does so at the expense of compatibility with our existing code
base. This is too high a price to pay
How hard would it be to take the non-templated strings implementation out of
the Abridged library and use it with the standard library? I suspect this
would buy some (a lot of?) improvement on its own.
I have just started playing with the “Abridged C++ library” (aka ecpp)
“alpha” release from developers.qnx.com.
While it does seem to go some way to addressing the compile speed and
code
size issues, it seems to be missing some pretty fundamental pieces,
the
two
I have found so far being “cerr” and indeed “iostream” itself
(although
“cin” and “cout” are present, as are “istream” and “ostream”).
Is this some kind of finger trouble on my part? Or maybe just a
reflection
of the pre-release status of this code?
Surely “cerr” isn’t considered too heavy for an embedded application?
I haven’t measured the overhead of having a cerr but I can’t imagine it’s
very much. Dropping clog might be worthwhile - who actually uses that? But
cerr is used a lot…
Yup. It (iostreams), was probably dropped because it can throw
exceptions, which means all the runtime exception handling stuff has to
be there.
No, just the class “iostream” has been dropped (equivalent to the
basic_iostream template from the full library), and this was purely to
remove the need for virtual inheritence of istream and ostream from ios. I
assume virtual inheritence is expensive enough to be worth removing from
the
library. Similarly, “fstream” and “stringstream” have been dropped. You
have
to use e.g. ifstream and ofstream instead.
My personal opinion ? if an embedded system is so resource or demand
constrained, that exceptions aren’t viable, then you have to seriously
consider coding everything in ‘C’. The good news ? Most embedded
systems are not so constrained. The bad news ? you can’t use the
Abridged library to speed up compiles, and reduce size on embedded
systems, that have sufficient resources for C++ (i.e. you can’t have
your cake and eat it to >
The Abridged library does actually have full exception support. I would
suspect an option to turn it off will be offered though - it is an option
according to Dinkumware’s website.
Ok… I really didn’t want to start a religious war about what should or
shouldn’t be included in a C++ library that is intended for embedded
systems.
Probably a good idea. But I’d expect that the modifications made were based
on actually testing their effect on code size rather than guessing - who
knows the compiler used though. Dinkumware could certainly spend a bit of
time improving compile time and code size of their regular library - others
have proved that it is possible.
I was coming from the perspective of someone who was merely looking for
some
light at the end of the “it takes 10 times longer to compile” tunnel. It
had
been mentioned that the “Abridged” library might provide that, but it
seems
that it only does so at the expense of compatibility with our existing
code
base. This is too high a price to pay >
My compile times seemed to drop by nearly 50% (I’ll have to actually do some
timing on this) and executable sizes dropped by a similar amount. My code is
very template intensive however - others might fare better.
How hard would it be to take the non-templated strings implementation out
of
the Abridged library and use it with the standard library? I suspect this
would buy some (a lot of?) improvement on its own.
You’d need the non-templated iostreams too.
I actually found that my code required very few changes. Nowhere have I ever
used fstream (always ifstream and ofstream) but in a few places I use
stringstream, which has had to move to an inefficient ostringstream and then
istringstream. Other than that, the missing header gave me grief,
so I ported the one from the full Dinkumware library; only a few lines
required changing to reflect the fact that strings and streams aren’t
templated. Finally, I had to remove a bit of custom locale facet code -
locales are also completely dropped from the Abridged lib.
I’ve found two bugs though - ostream_iterator (or what it i?) has a missing
default template argument, and is missing include guards.
So I got a substantial C++ code base that uses the C++ standard library
throughout compiling with the Abridged library in about 1 hour. I wouldn’t
have thought that most people would have a big problem either - the whole
STL component is basically unchanged and to fix the rest simply requires a
grep on cerr, fstream and stringstream. If you use wchar_t, locales or the
template features of strings and streams, the porting process will be more
substantial.
So I got a substantial C++ code base that uses the C++ standard library
throughout compiling with the Abridged library in about 1 hour. I wouldn’t
have thought that most people would have a big problem either - the whole
STL component is basically unchanged and to fix the rest simply requires a
grep on cerr, fstream and stringstream. If you use wchar_t, locales or the
template features of strings and streams, the porting process will be more
substantial.
I, too, got past cerr and some of the other issues pretty quickly. It was
iostream that killed me as we have a bunch of third party software (eg
sockstream) that uses this and I couldn’t justify spending the time/effort
to fix it.
I think, however, that this is missing the point to some extent. Part of the
attraction of Dinkumware in the first place was its high degree of
compliance with the Standard. Now it seems that in order to get improved
compile speed I have to give up substantial amounts of compliance.
For me that’s a no brainer - I’ll take compliance over compile speed any
time.
But I’m greedy - I want both! And there had been an implication out there
that the Abridged library would address this. Well, it doesn’t, at least not
in our environment. I guess it’s time to order some of those 2GHz P4s.
But I’m greedy - I want both! And there had been an implication out there
that the Abridged library would address this. Well, it doesn’t, at least
not
in our environment. I guess it’s time to order some of those 2GHz P4s.
Nah, from compilation an Athlon is faster then a 2Ggh P4. This has been
benchmark by compiling the Linux Kernel.
If you want speed get a dual AthlonMP, it will be cheaper then a 2G P4…
Have you tried adding -fno-default-inline. A large amount of the slowdown
is caused by the default inlining policy of gcc, which is a little
heavy handed. Turning it off speeds things up quite a bit, and
uses less memory to compile and (especially) optimise.
So I got a substantial C++ code base that uses the C++ standard library
throughout compiling with the Abridged library in about 1 hour. I wouldn’t
have thought that most people would have a big problem either - the whole
STL component is basically unchanged and to fix the rest simply requires a
grep on cerr, fstream and stringstream. If you use wchar_t, locales or the
template features of strings and streams, the porting process will be more
substantial.
I, too, got past cerr and some of the other issues pretty quickly. It was
iostream that killed me as we have a bunch of third party software (eg
sockstream) that uses this and I couldn’t justify spending the time/effort
to fix it.
I think, however, that this is missing the point to some extent. Part of the
attraction of Dinkumware in the first place was its high degree of
compliance with the Standard. Now it seems that in order to get improved
compile speed I have to give up substantial amounts of compliance.
For me that’s a no brainer - I’ll take compliance over compile speed any
time.
But I’m greedy - I want both! And there had been an implication out there
that the Abridged library would address this. Well, it doesn’t, at least not
in our environment. I guess it’s time to order some of those 2GHz P4s.
Have you tried adding -fno-default-inline. A large amount of the slowdown
is caused by the default inlining policy of gcc, which is a little
heavy handed. Turning it off speeds things up quite a bit, and
uses less memory to compile and (especially) optimise.
So I got a substantial C++ code base that uses the C++ standard library
throughout compiling with the Abridged library in about 1 hour. I
wouldn’t
have thought that most people would have a big problem either - the
whole
STL component is basically unchanged and to fix the rest simply
requires a
grep on cerr, fstream and stringstream. If you use wchar_t, locales or
the
template features of strings and streams, the porting process will be
more
substantial.
I, too, got past cerr and some of the other issues pretty quickly. It
was
iostream that killed me as we have a bunch of third party software (eg
sockstream) that uses this and I couldn’t justify spending the
time/effort
to fix it.
I think, however, that this is missing the point to some extent. Part of
the
attraction of Dinkumware in the first place was its high degree of
compliance with the Standard. Now it seems that in order to get improved
compile speed I have to give up substantial amounts of compliance.
For me that’s a no brainer - I’ll take compliance over compile speed any
time.
But I’m greedy - I want both! And there had been an implication out
there
that the Abridged library would address this. Well, it doesn’t, at least
not
in our environment. I guess it’s time to order some of those 2GHz P4s.
That increased the compile time of one of our apps from 205 secs to 332
secs.
Any other brilliant suggestions? <big grin
Bl%$#@dy Ozzie W$#@kers! };v)
Go to developers.qnx.com, download the freakin’ sort to gcc and install
the libstdc++ stuff?
Robert
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:9tmbqf$a17$> 1@nntp.qnx.com> …
Have you tried adding -fno-default-inline. A large amount of the slowdown
is caused by the default inlining policy of gcc, which is a little
heavy handed. Turning it off speeds things up quite a bit, and
uses less memory to compile and (especially) optimise.
So I got a substantial C++ code base that uses the C++ standard library
throughout compiling with the Abridged library in about 1 hour. I
wouldn’t
have thought that most people would have a big problem either - the
whole
STL component is basically unchanged and to fix the rest simply
requires a
grep on cerr, fstream and stringstream. If you use wchar_t, locales or
the
template features of strings and streams, the porting process will be
more
substantial.
I, too, got past cerr and some of the other issues pretty quickly. It
was
iostream that killed me as we have a bunch of third party software (eg
sockstream) that uses this and I couldn’t justify spending the
time/effort
to fix it.
I think, however, that this is missing the point to some extent. Part of
the
attraction of Dinkumware in the first place was its high degree of
compliance with the Standard. Now it seems that in order to get improved
compile speed I have to give up substantial amounts of compliance.
For me that’s a no brainer - I’ll take compliance over compile speed any
time.
But I’m greedy - I want both! And there had been an implication out
there
that the Abridged library would address this. Well, it doesn’t, at least
not
in our environment. I guess it’s time to order some of those 2GHz P4s.
That increased the compile time of one of our apps from 205 secs to 332
secs.
Any other brilliant suggestions? <big grin
Bl%$#@dy Ozzie W$#@kers! };v)
Go to developers.qnx.com, download the freakin’ sort to gcc and install
the libstdc++ stuff?
Err, seriously, I believe 6.1.1 will have the libstdc++ stuff available again,
although it won’t be considered a ‘supported’ product. But it will be nice
to once again be able to ftp/configure/make on free C++ stuff.
Robert
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:9tmbqf$a17$> 1@nntp.qnx.com> …
Have you tried adding -fno-default-inline. A large amount of the slowdown
is caused by the default inlining policy of gcc, which is a little
heavy handed. Turning it off speeds things up quite a bit, and
uses less memory to compile and (especially) optimise.
So I got a substantial C++ code base that uses the C++ standard library
throughout compiling with the Abridged library in about 1 hour. I
wouldn’t
have thought that most people would have a big problem either - the
whole
STL component is basically unchanged and to fix the rest simply
requires a
grep on cerr, fstream and stringstream. If you use wchar_t, locales or
the
template features of strings and streams, the porting process will be
more
substantial.
I, too, got past cerr and some of the other issues pretty quickly. It
was
iostream that killed me as we have a bunch of third party software (eg
sockstream) that uses this and I couldn’t justify spending the
time/effort
to fix it.
I think, however, that this is missing the point to some extent. Part of
the
attraction of Dinkumware in the first place was its high degree of
compliance with the Standard. Now it seems that in order to get improved
compile speed I have to give up substantial amounts of compliance.
For me that’s a no brainer - I’ll take compliance over compile speed any
time.
But I’m greedy - I want both! And there had been an implication out
there
that the Abridged library would address this. Well, it doesn’t, at least
not
in our environment. I guess it’s time to order some of those 2GHz P4s.
