Topic: C++ as PL/1
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/08/01 Raw View
David Abrahams wrote:
>
> On 22 Jul 1998 21:08:47 GMT, jkanze@otelo.ibmmail.com wrote:
>
> >In article <35B4C954.A187AE43@eng.sun.com>,
> > Michael Ball <michael.ball@Eng.Sun.COM> wrote:
> >
> >> David Abrahams wrote:
> >> > Isn't that case dependent on the compiler's ability to analyze that no
> >> > exceptions are thrown? In other words, if T::~T() has no throw()
> >> > specification, and is not inline, the compiler still has to generate
> >> > the try/catch block for auto_ptr<T>::~auto_ptr()... yes?
> >>
> >> That's correct. It can only use information it has.
> >
> >But in the specific case in question (auto_ptr), it has the information
> >that if T::~T() exits by an exception, undefined behavior occurs. Which
> >should be sufficient to allow suppression of the try block for this
> >particular case.
>
> In an ideal world that's true. But compilers with a knowledge of where
> the standard says there's undefined behavior for specific classes and
> templates defined in std... heh, heh... well... let's just say it'll
> be a while before we see any of those
it would be simple with a compiler extension, like
#pragma no unexpected
template<class T>
auto_ptr<T>::~auto_ptr() throw()
{
}
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jstern@citilink.com (Josh Stern)
Date: 1998/07/25 Raw View
David R Tribble <dtribble@technologist.com> wrote:
>Josh Stern wrote:
>> When a function with the exception signature
>> throw() is called, it is known that such a function cannot throw
>> an exception that will be seen by the caller. At worst it
>> will throw an exception and the function unexpected() will
>> be called. However, that situation is a kind of mistake anyway
>> and it doesn't affect what happens in the caller.
>> My point is that the use of throw(), where it does not lead
>> to unexpected(), will result in an efficiency savings in the
>> caller and the program overall. Ideally, compilers/linkers
>> should be able to at least warn people when throw() is used
>> in a situation where unexpected() would be generated, though
>> I realize that tracking this automatically may take some
>> work. In the mean time, the programmer has the option of
>> trying to track it herself in order to realize this efficency.
>What if we allowed a 'throw(nothrow)' clause to tell the compiler
>that there is no way that the function could ever throw an
>exception? And by extension, that a call to unexpected() is
>not needed?
>I realize that this would be fodder for programmer errors, but
>on the other hand it might allow the compiler to optimize (reduce)
>function call overhead.
It seems to me that the only difference between throw() and
the hypothesized "throw(nothrow)" is that in situations where
the function with the exception signature throw() could
potentially lead to a call to unexpected(), the function
substituting throw(nothrow) would error out at compile
time (rather than produce a warning). Code production
in the cases where neither errors nor warnings are
necessary should really be the same. Or did I misunderstand
the idea?
- Josh
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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/25 Raw View
Jason Merrill <jason@cygnus.com> writes:
>>>>>> jkanze <jkanze@otelo.ibmmail.com> writes:
>
>> Of course, I'm not sure that eliminating duplicate copies isn't easier
>> for the compiler implementor than leaving them. If he leaves them, he
>> still has to ensure that the address of the functions compare equal, that
>> all of the copies used use a single instance of any local static variables,
>> etc. The program must behave as if there were only one copy.
>
>On targets that use the ELF object format, it is easy to emit multiple
>copies but have only one be used, through the use of weak symbols.
>Removing the unused copies from the output file is significantly harder,
>and requires some linker magic.
If you generate only one symbol per object file
(i.e. multiple object files per translation unit),
then the linker won't link in unused weak symbols.
Generating one object file per symbol increases compilation/link times
significantly, but this can be an option that you only enable for cases
where space optimization is important, e.g. for embedded programs,
or for the static version of the standard library.
This option is quite easy to implement, too -- I did it for the Mercury
implementation, and according to our CVS logs it took me 6 hours to do
the initial implementation and then it took us about another 12 hours
to integrate those changes with the rest of the Mercury implementation.
--
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: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/07/27 Raw View
Josh Stern wrote:
>
> David R Tribble <dtribble@technologist.com> wrote:
>
> >What if we allowed a 'throw(nothrow)' clause to tell the compiler
> >that there is no way that the function could ever throw an
> >exception? And by extension, that a call to unexpected() is
> >not needed?
>
> >I realize that this would be fodder for programmer errors, but
> >on the other hand it might allow the compiler to optimize (reduce)
> >function call overhead.
>
> It seems to me that the only difference between throw() and
> the hypothesized "throw(nothrow)" is that in situations where
> the function with the exception signature throw() could
> potentially lead to a call to unexpected(), the function
> substituting throw(nothrow) would error out at compile
> time (rather than produce a warning). Code production
> in the cases where neither errors nor warnings are
> necessary should really be the same. Or did I misunderstand
> the idea?
I think his idea was to let the compiler *assume* that no exceptions
can be get out, and therefore omit the handling code, while still
telling the calling functions that the function does not throw
(that is, compile the functions as if no throw specification was
given, but compile all callers as if an empty throw specification was
given). Of course, if the function unexpectedly leaks an exception
anyway, undefined behaviour would occur instead of a call to
unexpected().
The result would be a bypass of the C++ safety net for the advantage
of less code bloat and possibly more efficiency. A way to tell the
compiler, "You might not see that there are no exceptions, but I know
better; so just assume it and omit EH 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: abrahams@motu.com (David Abrahams)
Date: 1998/07/27 Raw View
On 25 Jul 1998 00:29:39 GMT, Jason Merrill <jason@cygnus.com> wrote:
>> I don't think it's actually a problem if this behavior is undefined.
>
>I assume you mean unspecified?
Yes, thanks. Undefined would be a big 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/27 Raw View
In article <35BC7112.A3B95111@physik.tu-muenchen.de>,
Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
> The result would be a bypass of the C++ safety net for the advantage
> of less code bloat and possibly more efficiency. A way to tell the
> compiler, "You might not see that there are no exceptions, but I know
> better; so just assume it and omit EH code."
This could be done already, without violating the standard, by
supplying a #pragma directive for this purpose. The catch, of course,
is that this would work for one compiler, and be ignored by all the
other compilers. But in this case the #pragma enables an optimization
technique, and the code will compile correctly if the #pragma is
ignored.
-----== 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: jstern@citilink.com (Josh Stern)
Date: 1998/07/22 Raw View
David Abrahams <abrahams@motu.com> wrote:
>I wrote:
>>David Abrahams <abrahams@motu.com> wrote:
>>>Unfortunately, throw() doesn't really mean what it seems to mean. When
>>>you write throw() on a function definition, what it really says is:
>>>"If this function does end up throwing an exception, catch it and call
>>>unexpected() instead."
>>But it does mean what it seems to mean from the viewpoint of a
>>function that might call the function with the throw()
>>signature.
>>>So effectively, it wraps each call to the function in a try/catch
>>>block.
>>I don't think that is correct. It would be silly.
>Silly or not, it is true. Whether the try/catch occurs inside the
>called function body or outside in the caller is an implementation
>detail.
I am explicitly talking about a situation in which no try/catch
block is needed. When a function with the exception signature
throw() is called, it is know that such a function cannot throw
an exception that will be seen by the caller. At worst it
will throw an exception and the function unexpected() will
be called. However, that situation is a kind of mistake anyway
and it doesn't affect what happens in the caller.
My point is that the use of throw(), where it does not lead
to unexpected(), will result in an efficiency savings in the
caller and the program overall. Ideally, compilers/linkers
should be able to at least warn people when throw() is used
in a situation where unexpected() would be generated, though
I realize that tracking this automatically may take some
work. In the mean time, the programmer has the option of
trying to track it herself in order to realize this efficency.
>>>>Does this turn
>>>>out to be significant with existing implementations?
>>>I've never heard of a compiler that could take advantage of throw()
>>>specifications for optimization.
>>See Steve Clamage's posting.
>Yes, that's good news. Still, I wouldn't try to take advantage of
>those optimizations unless you know this about *your* compiler,
Well the particular optimization we are talking about is analogous
to not generating code for an "if(0)" conditional. It would
be great if compilers were even smarter than that and could
do global optimizations in situations where there is not a
throw() specification and yet an exception cannot occur.
But I am not expecting that with current technology. So
in some sense I am the one being conservative about the
compiler's capabilities on this particular issue.
> Even with aggressive EH
>optimization, the use of non-empty exception specifications will
>usually waste more space than it saves.
I think this is probably wrong, and if it is not it soon will be.
Nathan's comments on my original posting with regard to the use
of throw() everywhere made sense, but he was responding to my
question as stated and not to what I intended. I meant to
ask about the use of throw() where it can be determined that
it will not lead to unexpected() - as someone else mentioned,
it is analogous to const correctness. I believe that the
use of throw() rather than empty specification in this situations
should eliminate code bloat (probably at least one address pointer
per function call) and is also good software engineering.
>BTW, here's an interesting question to which I can't find the answer
>in FDIS. What does this program do?
>
>class X
>{
> X( const X& ) { throw 1; }
> const X& operator=( const X& ) { throw 'x'; return *this; }
>};
>
>X f() throw()
>{
> return X();
>}
>
>
>int main()
>{
> try
> {
> X x = f();
> }
> catch( int e )
> {
> cout << "copy constructor";
> }
> catch (char e )
> {
> cout << "assignment";
> }
It's a good question. I'm inclined to think that the
answer is implementation defined, with the two possible
choices being that the program prints nothing or the
program prints "copy constructor".
- Josh
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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/07/22 Raw View
On 22 Jul 98 19:07:27 GMT, jstern@citilink.com (Josh Stern) wrote:
>David Abrahams <abrahams@motu.com> wrote:
>>I wrote:
>>>>So effectively, it wraps each call to the function in a try/catch
>>>>block.
>
>>>I don't think that is correct. It would be silly.
>
>>Silly or not, it is true. Whether the try/catch occurs inside the
>>called function body or outside in the caller is an implementation
>>detail.
>
>I am explicitly talking about a situation in which no try/catch
>block is needed. When a function with the exception signature
>throw() is called, it is know that such a function cannot throw
>an exception that will be seen by the caller. At worst it
>will throw an exception and the function unexpected() will
>be called. However, that situation is a kind of mistake anyway
>and it doesn't affect what happens in the caller.
That's true. It pushes the need for the try/catch block deeper into
the call tree.
>My point is that the use of throw(), where it does not lead
>to unexpected(), will result in an efficiency savings in the
>caller and the program overall.
Depending on the compiler, that may be true. How many EH
implementations have you looked at? I've looked at a few otherwise
excellent compilers, and none of them optimized for this case.
>>>See Steve Clamage's posting.
>
>>Yes, that's good news. Still, I wouldn't try to take advantage of
>>those optimizations unless you know this about *your* compiler,
>
>Well the particular optimization we are talking about is analogous
>to not generating code for an "if(0)" conditional.
No, it's more complicated than that. To optimize that case away, you
need to know that none of the functions you call can throw, and it's
not going to simply "fall out" of other optimization code for free. It
would have to be explicitly written. This is not an optimization
that's likely to have a high priority for implementation in many
compilers, since few people use throw() diligently the way you intend
to.
>It would
>be great if compilers were even smarter than that and could
>do global optimizations in situations where there is not a
>throw() specification and yet an exception cannot occur.
>But I am not expecting that with current technology. So
>in some sense I am the one being conservative about the
>compiler's capabilities on this particular issue.
Suit yourself. Personally, I'd run some tests. With the state of
current technology you stand as good a chance of making your code
bigger.
>> Even with aggressive EH
>>optimization, the use of non-empty exception specifications will
>>usually waste more space than it saves.
>
>I think this is probably wrong, and if it is not it soon will be.
>Nathan's comments on my original posting with regard to the use
>of throw() everywhere made sense, but he was responding to my
>question as stated and not to what I intended. I meant to
>ask about the use of throw() where it can be determined that
>it will not lead to unexpected() - as someone else mentioned,
>it is analogous to const correctness. I believe that the
>use of throw() rather than empty specification in this situations
I think you've misunderstood me. An empty exception-specification
looks like this:
throw()
A non-empty one looks like this:
throw( bad_alloc )
>should eliminate code bloat (probably at least one address pointer
>per function call) and is also good software engineering.
As I've said before, that depends on your implementation. Check it
before you assume.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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
Michael Ball <michael.ball@Eng.Sun.COM> wrote:
>David Abrahams wrote:
>
>> In other words, if T::~T() has no throw()
>> specification, and is not inline, the compiler still has to generate
>> the try/catch block for auto_ptr<T>::~auto_ptr()... yes?
>
>That's correct. It can only use information it has.
No... if ~auto_ptr() is inline (which is normal), and it says
something vaguely like
try { p->~T(); } catch (...) { }
then the compiler has all the information it needs.
--
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/22 Raw View
In article <EwGyBs.HCB@msi.com>,
jpb@msi.com (Jan Bielawski) wrote:
> In article <35B0C06E.A512D14F@acm.org> Pete Becker <petebecker@acm.org>
writes:
> < Mike Davies wrote:
> < >
> < > In article <35AE4945.69E6@noSPAM.central.beasys.com>, David R Tribble
> < > <david.tribble@noSPAM.central.beasys.com> writes
> < >
> < > ...snip...
> < >
> < > >Summary:
> < > > Source Lang OBJ EXE code data Notes
> < > > ---------- ---- ------ ------ ----- ---- ------
> < > > hello1.c C 432 27,648 18 14 printf
> < > > hello2.cpp C++ 432 27,648 18 14 printf
> < > > hello3.cpp C++ 432 27,648 18 14 printf
> < > > hello4.cpp C++ 11,857 63,488 2,029 14 cout
> < > >
> < > >Maybe I'm wrong, but it sure looks like using 'cout' brings a
> < > >lot more baggage into an object file that 'printf' does.
> < >
> < > It may using *that* library, but MS are not reknowned for small object
> < > files in any case.
> <
> < Please point to an implementation that does better. And include a
> < similar set of data points, so that meaningful comparisons can be made.
>
> OK, here it is on the SGI:
>
> hello1.c:
> #include <stdio.h>
>
> int
> main()
> {
> printf( "Hello\n" );
> return 1;
> }
>
> hello2.c:
> #include <iostream.h>
>
> int
> main()
> {
> cout << "Hello\n";
> return 1;
> }
>
> hello1.o: 1732, a.out: 12680
> hello2.o: 2896, a.out: 13192
>
> After stripping:
>
> a.out (hello1): 9076
> a.out (hello2): 9076
It would appear that the object files are actually larger. As for the
executable, I'm not familiar with the SGI, but on a Sun, the command
you used would link against a shared library for the system libraries;
unless the MS version is also using a DDL in this case, the comparison
is not valid.
--
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: abrahams@motu.com (David Abrahams)
Date: 1998/07/23 Raw View
On 22 Jul 1998 21:09:01 GMT, ncm@nospam.cantrip.org (Nathan Myers)
wrote:
>Michael Ball <michael.ball@Eng.Sun.COM> wrote:
>>David Abrahams wrote:
>>
>>> In other words, if T::~T() has no throw()
>>> specification, and is not inline, the compiler still has to generate
>>> the try/catch block for auto_ptr<T>::~auto_ptr()... yes?
>>
>>That's correct. It can only use information it has.
>
>No... if ~auto_ptr() is inline (which is normal), and it says
>something vaguely like
>
> try { p->~T(); } catch (...) { }
>
>then the compiler has all the information it needs.
Uh, okay, that's an interesting trick, but it sort of begs the
question. You've just replaced an implicitly-generated try/catch block
with an explicitly-generated one. I guess you saved a call to
unexpected()...
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Michael Ball <michael.ball@Eng>
Date: 1998/07/23 Raw View
Nathan Myers wrote:
> >> In other words, if T::~T() has no throw()
> >> specification, and is not inline, the compiler still has to generate
> >> the try/catch block for auto_ptr<T>::~auto_ptr()... yes?
> >
> >That's correct. It can only use information it has.
>
> No... if ~auto_ptr() is inline (which is normal), and it says
> something vaguely like
>
> try { p->~T(); } catch (...) { }
>
> then the compiler has all the information it needs.
Certainly inline code provides the data. Thus it's common to be
able to optimize, but certainly not guaranteed. It's obvious enough
that inline functions let you do this that I didn't consider
discussing that case. This was clearly a mistake.
jkanze@otelo.ibmmail.com wrote:
>
> But in the specific case in question (auto_ptr), it has the information
> that if T::~T() exits by an exception, undefined behavior occurs. Which
> should be sufficient to allow suppression of the try block for this
> particular case.
This is true, and within the auto_ptr destructor itself we do not need
to
generate a block (and we don't.) Destructors are special cases. In
fact, I should have pointed it out, but I didn't think of it at the
time.
-Mike Ball-
Sun MicroSystems Inc.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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/23 Raw View
David Abrahams<abrahams@motu.com> wrote:
>What does this program do?
>
>class X
>{
> X( const X& ) { throw 1; }
> const X& operator=( const X& ) { throw 'x'; return *this; }
>};
>
>X f() throw() { return X(); }
>
>int main()
>{
> try { X x = f(); }
> catch( int e ) { cout << "copy constructor"; }
> catch (char e ) { cout << "assignment"; }
>}
>
>I wonder how many compilers that implement the elision of temporaries
>optimization get this right...
It's illegal: X has no default constructor. Anyway, operator=
cannot be called in this program. Maybe there's some other
program that would be better to ask about.
--
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/07/23 Raw View
James Kuyper <kuyper@wizard.net> wrote:
>
>Removal of unreferenced ordinary functions is a widely implemented
>option. Detection of unused virtual functions is a much more difficult
>issue.
This has been asserted many times, but never supported. Yes, it's
more difficult. Is it more difficult than all of a hundred other
intricate things a modern linker does (never mind what intricate
things a compiler does)? No, it can be described in detail in a
few sentences, and _has_ been implemented in just a few days.
Certainly it's simpler than namespaces, or overloading, or virtual
functions.
Please, can we let the discussion proceed and not keep dragging
it back to points already long since cleared up? Lately the question
had been whether omitting unused functions might actually make a
difference in program size (surprise, surprise), but I think that
has mercifully been laid to rest. We were just beginning to be
allowed to discuss other actually-interesting optimization techniques.
--
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: abrahams@motu.com (David Abrahams)
Date: 1998/07/23 Raw View
On 22 Jul 1998 21:08:47 GMT, jkanze@otelo.ibmmail.com wrote:
>In article <35B4C954.A187AE43@eng.sun.com>,
> Michael Ball <michael.ball@Eng.Sun.COM> wrote:
>
>> David Abrahams wrote:
>> > Isn't that case dependent on the compiler's ability to analyze that no
>> > exceptions are thrown? In other words, if T::~T() has no throw()
>> > specification, and is not inline, the compiler still has to generate
>> > the try/catch block for auto_ptr<T>::~auto_ptr()... yes?
>>
>> That's correct. It can only use information it has.
>
>But in the specific case in question (auto_ptr), it has the information
>that if T::~T() exits by an exception, undefined behavior occurs. Which
>should be sufficient to allow suppression of the try block for this
>particular case.
In an ideal world that's true. But compilers with a knowledge of where
the standard says there's undefined behavior for specific classes and
templates defined in std... heh, heh... well... let's just say it'll
be a while before we see any of those
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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/07/23 Raw View
On 22 Jul 1998 21:08:44 GMT, jkanze@otelo.ibmmail.com wrote:
>In article <35b4dd22.80125327@news.motu.com>,
> abrahams@motu.com intended to write
>
>> BTW, here's an interesting question to which I can't find the answer
>> in FDIS. What does this program do?
>>
>> struct X
>> {
>> X();
>> X( const X& ) { throw 1; }
>> const X& operator=( const X& ) { throw 'x'; return *this; }
>> };
>>
>> X f() throw()
>> {
>> return X();
>> }
>>
>> int main()
>> {
>> try
>> {
>> X x = f();
>> }
>> catch( int e )
>> {
>> cout << "copy constructor";
>> }
>> catch (char e )
>> {
>> cout << "assignment";
>> }
>> }
>>
>> I wonder how many compilers that implement the elision of temporaries
>> optimization get this right...
>
>It's hard to say. As written, the program won't compile, first, because
>all of the constructors are private, and secondly, because there is
>no default constructor, so the return X() in f is illegal.
Oops. Please allow the amendment above.
>Correcting these two problems, I think that the output is undefined,
>although I'm far from up to date on the final status of elision of
>temporaries. Basically, the last time I looked (and the text in this
>section HAS changed significantly since then), a compiler could legally
>either call the default constructor, followed by the copy constructor,
>or just call the default constructor.
I should have been clearer. I'm asking specifically what is the scope
of the implicit try block generated for f(). How much of the mechanism
of the return statement does it contain? I suppose, given the
semantics of exception-specifications, the question is equivalent to
this one: What does this program do?
struct X
{
X();
X( const X& ) { throw 1; }
};
X f()
{
try {
return X();
}
catch(..) { std::cout << "inside"; throw; }
}
int main()
{
try { f(); } catch(...) {}
}
>In no case could it call the assignment operator, since there isn't a
>single assignment in the program. The program would be legal, and
>required to compile and work even if I failed to provide an implementation
>of the assignment operator.
Of course you are correct.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jstern@citilink.com (Josh Stern)
Date: 1998/07/23 Raw View
David Abrahams <abrahams@motu.com> wrote:
>jstern@citilink.com (Josh Stern) wrote:
>>David Abrahams <abrahams@motu.com> wrote:
>>>I wrote:
>>I am explicitly talking about a situation in which no try/catch
>>block is needed. When a function with the exception signature
>>throw() is called, it is know that such a function cannot throw
>>an exception that will be seen by the caller. At worst it
>>will throw an exception and the function unexpected() will
>>be called. However, that situation is a kind of mistake anyway
>>and it doesn't affect what happens in the caller.
>That's true. It pushes the need for the try/catch block deeper into
>the call tree.
The function with the throw() signature doesn't need a
try catch block either unless it throws an exception or
calls something which does...and so forth.
>>Well the particular optimization we are talking about is analogous
>>to not generating code for an "if(0)" conditional.
>No, it's more complicated than that. To optimize that case away, you
>need to know that none of the functions you call can throw, and it's
>not going to simply "fall out" of other optimization code for free.
I expect that just doing a check on the exception signatures of all
the functions that are called in a give scope (and making sure that
throw itself is not called in this scope) is not a hard test. In fact, I
think it would not be too hard to do this with a fairly short
shell script.
Also, even if some functions in the scope are permitted to throw
exceptions, there may still be the possibility of space savings
related to the omission of unecessary information for the
uncessary handling of exceptions
from the functions that cannot throw them through this scope.
The object code must somehow keep track of
which local objects have already been constructred prior
to each call to a function that may throw an exception.
So, at a mininum, there must be some sort of bookkeeping
for this that will add overhead every time a new local object
is constructed followed by a new call to a function
that can throw an exception. This incremental overhead
is salvageable when the function signature is throw().
Steve Clamage's report on the Sun compiler
implied that this sayings is achieved there.
>>> Even with aggressive EH
>>>optimization, the use of non-empty exception specifications will
>>>usually waste more space than it saves.
>>I think this is probably wrong, and if it is not it soon will be.
>>Nathan's comments on my original posting with regard to the use
>>of throw() everywhere made sense, but he was responding to my
>>question as stated and not to what I intended. I meant to
>>ask about the use of throw() where it can be determined that
>>it will not lead to unexpected() - as someone else mentioned,
>>it is analogous to const correctness. I believe that the
>>use of throw() rather than empty specification in this situations
>I think you've misunderstood me. An empty exception-specification
>looks like this:
> throw()
>A non-empty one looks like this:
> throw( bad_alloc )
Yes I thought you were using the term empty exception-spec
to refer to this: <space>. Now that I understand your
terminology, it sounds like you were agreeing with me
in the quoted paragraph (>>>) above.
- Josh
p.s. I understood what you were trying to get at with your
original example. I think that the essence of the
answer (ignoring the access issues, etc.) is that it
is implementation defined because copy constructor,
which would be the function to throw the exception
could be used to construct a temporary in the
function return, or not, at the discretion of
the implementation. That's a reason why it is
always bad to have copy constructors with side effects.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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
Mike Davies wrote:
...
> I should say that by "unused" I meant "unreferenced". The Microsoft
> Visual C++ 5.0 has the facility to avoid linking in unreferenced
> functions/data, The linker switch is /OPT:UNREF or /OPT:REF or something
Nathan Myers wrote:
>
> James Kuyper <kuyper@wizard.net> wrote:
> >
> >Removal of unreferenced ordinary functions is a widely implemented
> >option. Detection of unused virtual functions is a much more difficult
> >issue.
>
> This has been asserted many times, but never supported. Yes, it's
> more difficult.
Your second statement is all the support that my second statement needs;
I didn't mean to imply anything much stronger than that. I made the
distinction solely for the purpose of setting up the question:
[I said:]
> Are you sure this compiler option removes unused virtual
> functions?
I've not seen an answer yet, but it's been less than a day since I first
asked 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: kanze@my-dejanews.com
Date: 1998/07/23 Raw View
In article <35b65fc3.179117644@news.motu.com>,
abrahams@motu.com wrote:
> On 22 Jul 1998 21:08:44 GMT, jkanze@otelo.ibmmail.com wrote:
> >Correcting these two problems, I think that the output is undefined,
> >although I'm far from up to date on the final status of elision of
> >temporaries. Basically, the last time I looked (and the text in this
> >section HAS changed significantly since then), a compiler could legall=
y
> >either call the default constructor, followed by the copy constructor,
> >or just call the default constructor.
>
> I should have been clearer. I'm asking specifically what is the scope
> of the implicit try block generated for f(). How much of the mechanism
> of the return statement does it contain? I suppose, given the
> semantics of exception-specifications, the question is equivalent to
> this one: What does this program do?
>
> struct X
> {
> X();
> X( const X& ) { throw 1; }
> };
>
> X f()
> {
> try {
> return X();
> }
> catch(..) { std::cout << "inside"; throw; }
> }
>
> int main()
> {
> try { f(); } catch(...) {}
> }
I still think that it might depend on whether the compiler has elided
the copy constructor or not. But you're right that there are two
questions. One concerns the elided copy constructor -- if the constructo=
r
isn't there, it obviously cannot throw. And the second concerns
where the copy takes place -- I would expect it to be at the point of
call, after having left the function, but I'll admit that this is more
my personal feeling of what I'd expect, rather than something I've read
from the standard.
--
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=E9e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----=3D=3D Posted via Deja News, The Leader in Internet Discussion =3D=3D=
-----
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: Jason Merrill <jason@cygnus.com>
Date: 1998/07/24 Raw View
>>>>> kanze <kanze@my-dejanews.com> writes:
> In article <35b65fc3.179117644@news.motu.com>,
> abrahams@motu.com wrote:
>> I should have been clearer. I'm asking specifically what is the scope
>> of the implicit try block generated for f(). How much of the mechanism
>> of the return statement does it contain? I suppose, given the
>> semantics of exception-specifications, the question is equivalent to
>> this one: What does this program do?
>>
>> struct X
>> {
>> X();
>> X( const X& ) { throw 1; }
>> };
>>
>> X f()
>> {
>> try {
>> return X();
>> }
>> catch(..) { std::cout << "inside"; throw; }
>> }
>>
>> int main()
>> {
>> try { f(); } catch(...) {}
>> }
> I still think that it might depend on whether the compiler has elided the
> copy constructor or not. But you're right that there are two questions.
> One concerns the elided copy constructor -- if the constructor isn't
> there, it obviously cannot throw.
Yup. The return statement may or may not throw, depending on whether or
not the copy constructor is elided. This is why you shouldn't write copy
constructors that do strange things.
> And the second concerns where the copy takes place -- I would expect it
> to be at the point of call, after having left the function, but I'll
> admit that this is more my personal feeling of what I'd expect, rather
> than something I've read from the standard.
No, the copy takes place at the return statement.
6.6.3 - The return statement [stmt.return]
The expression is implicitly converted to the return type of the function
in which it appears. A return statement can involve the construction and
copy of a temporary object (class.temporary).
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: Jason Merrill <jason@cygnus.com>
Date: 1998/07/24 Raw View
>>>>> jkanze <jkanze@otelo.ibmmail.com> writes:
> Of course, I'm not sure that eliminating duplicate copies isn't easier
> for the compiler implementor than leaving them. If he leaves them, he
> still has to ensure that the address of the functions compare equal, that
> all of the copies used use a single instance of any local static variables,
> etc. The program must behave as if there were only one copy.
On targets that use the ELF object format, it is easy to emit multiple
copies but have only one be used, through the use of weak symbols.
Removing the unused copies from the output file is significantly harder,
and requires some linker magic.
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: abrahams@motu.com (David Abrahams)
Date: 1998/07/24 Raw View
On 24 Jul 98 05:20:04 GMT, Jason Merrill <jason@cygnus.com> wrote:
>>>>>> kanze <kanze@my-dejanews.com> writes:
>
>> In article <35b65fc3.179117644@news.motu.com>,
>> abrahams@motu.com wrote:
>
>>> What does this program do?
>>>
>>> struct X
>>> {
>>> X();
>>> X( const X& ) { throw 1; }
>>> };
>>>
>>> X f()
>>> {
>>> try {
>>> return X();
>>> }
>>> catch(..) { std::cout << "inside"; throw; }
>>> }
>>>
>>> int main()
>>> {
>>> try { f(); } catch(...) {}
>>> }
>
>> I still think that it might depend on whether the compiler has elided the
>> copy constructor or not. But you're right that there are two questions.
>> One concerns the elided copy constructor -- if the constructor isn't
>> there, it obviously cannot throw.
>
>Yup. The return statement may or may not throw, depending on whether or
>not the copy constructor is elided. This is why you shouldn't write copy
>constructors that do strange things.
Are you seriously suggesting throwing an exception from a copy
constructor is a strange thing to do and should be avoided? That would
seriously limit the kinds of classes we can write. Any class with
non-reference-counted deep data would be outlawed, for example.
I don't think it's actually a problem if this behavior is undefined.
The only "strange" thing about my example program is the side-effect
of the catch clause in f(), which allows us to distinguish an
exception which occurs inside from one which occurs in main().
Normally, you wouldn't write code like that. This is really nothing
more than another example of the rule: "don't write code which depends
on the absence or presence of the elision of temporaries
optimization".
>> And the second concerns where the copy takes place -- I would expect it
>> to be at the point of call, after having left the function, but I'll
>> admit that this is more my personal feeling of what I'd expect, rather
>> than something I've read from the standard.
>
>No, the copy takes place at the return statement.
>
> 6.6.3 - The return statement [stmt.return]
>
> The expression is implicitly converted to the return type of the function
> in which it appears. A return statement can involve the construction and
> copy of a temporary object (class.temporary).
Well, the word "involves" doesn't give a very clear indication that
the work all occurs at the return statement, but it's certainly the
best indicator I've seen so far. Thanks for digging that up.
-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: Jason Merrill <jason@cygnus.com>
Date: 1998/07/25 Raw View
>>>>> David Abrahams <abrahams@motu.com> writes:
>> Yup. The return statement may or may not throw, depending on whether or
>> not the copy constructor is elided. This is why you shouldn't write copy
>> constructors that do strange things.
> Are you seriously suggesting throwing an exception from a copy
> constructor is a strange thing to do and should be avoided?
Not at all, I just mean a copy constructor that does something other than
copy should be avoided. If the process of copying happens to throw, that's
fine.
> I don't think it's actually a problem if this behavior is undefined.
I assume you mean unspecified?
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: David R Tribble <david.tribble@noSPAM.central.beasys.com>
Date: 1998/07/25 Raw View
Josh Stern wrote:
> I am explicitly talking about a situation in which no try/catch
> block is needed. When a function with the exception signature
> throw() is called, it is know that such a function cannot throw
> an exception that will be seen by the caller. At worst it
> will throw an exception and the function unexpected() will
> be called. However, that situation is a kind of mistake anyway
> and it doesn't affect what happens in the caller.
>
> My point is that the use of throw(), where it does not lead
> to unexpected(), will result in an efficiency savings in the
> caller and the program overall. Ideally, compilers/linkers
> should be able to at least warn people when throw() is used
> in a situation where unexpected() would be generated, though
> I realize that tracking this automatically may take some
> work. In the mean time, the programmer has the option of
> trying to track it herself in order to realize this efficency.
What if we allowed a 'throw(nothrow)' clause to tell the compiler
that there is no way that the function could ever throw an
exception? And by extension, that a call to unexpected() is
not needed?
I realize that this would be fodder for programmer errors, but
on the other hand it might allow the compiler to optimize (reduce)
function call overhead.
-- 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: James Kuyper <kuyper@wizard.net>
Date: 1998/07/22 Raw View
Mike Davies wrote:
>
> In article <35B3B5D5.453A@noSPAM.central.beasys.com>, David R Tribble
> <david.tribble@noSPAM.central.beasys.com> writes
>
> ...snip...
>
> >Summary:
> > Source Lang OBJ EXE code data Notes
> > ---------- ---- ------ ------ ----- ---- ------
> > hello1.c C 432 27,648 18 14 printf
> > hello2.cpp C++ 432 27,648 18 14 printf
> > hello3.cpp C++ 432 27,648 18 14 printf
> > hello4.cpp C++ 11,857 63,488 2,029 14 cout, iostream
> > hello5.cpp C++ 539 35,328 22 14 cout, iostream.h
> >
> >So it looks like the old version of 'cout' yanks in a similar
> >amount of overhead as 'printf' (only 4 more bytes of object code),
> >while the new 'std::cout' yanks in a great deal more (113 times
> >as much code).
>
> I'm interested to know how that 11k in the object file turns into nearly
> 30k in the executable file ? I would have expected the linker to have
> discarded unreferenced code, not expanded it ?
Which file are you referring to? The 11 K object file produced a 63 K
executable. The only things that produced (approximately) 30 K
executables were the 432 and 539 byte object files.
In any event, I would assume that the bulk of the increase was from
linking in the standard libraries, and adding in the startup code; in
other compilers I'm familiar with, the actual outermost function is
_start(), which calls _main(), which calls main(). The startup code does
things like loading command line arguments into argv.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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
Jan Bielawski wrote:
>
> OK, here it is on the SGI:
>
> hello1.c:
> #include <stdio.h>
>
> int
> main()
> {
> printf( "Hello\n" );
> return 1;
> }
>
> hello2.c:
> #include <iostream.h>
>
> int
> main()
> {
> cout << "Hello\n";
> return 1;
> }
>
> hello1.o: 1732, a.out: 12680
> hello2.o: 2896, a.out: 13192
>
> After stripping:
>
> a.out (hello1): 9076
> a.out (hello2): 9076
I suppose if the asserting is "Microsoft produces large executables"
that this is interesting. But this thread started out talking about the
size of executables that use the standard C++ library, and leaving out
templated iostreams makes this data not particularly useful.
--
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: abrahams@motu.com (David Abrahams)
Date: 1998/07/22 Raw View
On 22 Jul 1998 03:17:22 GMT, AllanW@my-dejanews.com wrote:
>
>> Josh Stern<jstern@citilink.com> wrote:
>> >I'd like to ask about how much (if any) efficiency is gained
>> >with existing C++ compilers when throw() is added to
>> >all function definitions where it is permissible to add it.
>>
>In article <6p04db$as$1@shell7.ba.best.com>,
> ncm@nospam.cantrip.org (Nathan Myers) wrote:
>> If the function does anything that *might* throw (including call
>> a function not declared throw() itself) the compiler is obliged
>> to add a try/catch block to call unexpected() if something throws.
>
>In this case, is the compiler still required to "clean up" objects
>that were constructed and not destructed? If not, the post-call
>code becomes considerably simpler.
>
> function a() { // Might throw
> if (0==rand()) throw 1;
> }
>
> function b() throw() {
> Object myObject(1);
> for (int i=0; i<5; ++i) a();
> }
I think these functions are missing return values of type "function"
;)
>The programmer has (incorrectly, in this case) guaranteed that a()
>will not throw. If a does throw, is myObject guaranteed to call
>the destructor? Because if not, we could simplify the call to a()
>by simply jumping to unexpected() if a() throws, rather than
>unwinding the stack first.
As Bjarne Stroustrup points out in his "C++ Programming Language, 3rd
Edition", b's definition is precisely equivalent to:
void b()
{
try {
Object myObject(1);
for (int i=0; i<5; ++i) a();
}
catch(...) {
std::unexpected();
}
}
So if a() throws, myObject will be destroyed before the catch block is
entered, i.e. before unexpected() is called. If myObject were not
destroyed, the rewrite of b above would have different semantics from
the original version.
>If stack unwinding is still guaranteed even in throw() functions,
>then it seems impossible to implement exceptions without generating
>code much fatter than C ever generated.
I wouldn't be so quick to jump to that conclusion. The case you are
talking about handling is one in which an unexpected error occurs and
you want to terminate the program. Does that arise often in your C
code? If so, start calling terminate() instead of throwing exceptions
in the C++ version ;). As I pointed out in a previous post, getting an
optimization benefit from exception specifications requires two
things:
1. that you are disciplined about using throw() all the way down to
the leaf functions (or at least through many levels).
2. That your compiler supports the appropriate optimizations.
There are two ways to manage exceptions in any function: with
try/catch blocks or with cleanup objects. Using try/catch can more
easily have a lower runtime cost (in the case where no exceptions
occur), since you are giving the compiler very complete information
about which code is dedicated to error handling. This code can be
moved to separate areas of memory to improve locality of reference and
remove local branching. Using cleanup objects can more easily have a
lower cost in space, since the code to execute the destructors on exit
is already generated as part of the function body. A good compiler can
arrange its exception tables to jump into the part of the function
where the destructors are being executed.
The more potential places an error can occur such that the program
needs to begin unwinding with the same destructor, the greater its
potential code size advantage over the corresponding "C" code. I'm
thinking of something like this:
if ( err = op1() ) goto cleanup;
if ( err = op2() ) goto cleanup;
if ( err = op3() ) goto cleanup;
if ( err = op4() ) goto cleanup;
...
the C++ version can turn all of those individual test/branch cases
into a single exception-table entry which specifies the range of
addresses from which the throw() occurs and the address of the cleanup
code.
Most of the time, I try to avoid try/catch and instead use objects to
manage resources and program state. This results in cleaner and
usually smaller code which is easier to understand (there are fewer
special cases to examine). In time-critical code like the STL,
however, I use try/catch for the best possible performance.
My first concern is readability/maintainability, though, and these
performance guidelines may not hold across all implementations. Of
course, your mileage may vary.
-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: jstern@citilink.com (Josh Stern)
Date: 1998/07/22 Raw View
David Abrahams <abrahams@motu.com> wrote:
>I wrote:
>>David Abrahams <abrahams@motu.com> wrote:
>>>Unfortunately, throw() doesn't really mean what it seems to mean. When
>>>you write throw() on a function definition, what it really says is:
>>>"If this function does end up throwing an exception, catch it and call
>>>unexpected() instead."
>>But it does mean what it seems to mean from the viewpoint of a
>>function that might call the function with the throw()
>>signature.
>>>So effectively, it wraps each call to the function in a try/catch
>>>block.
>>I don't think that is correct. It would be silly.
>Silly or not, it is true. Whether the try/catch occurs inside the
>called function body or outside in the caller is an implementation
>detail.
I am explicitly talking about a situation in which no try/catch
block is needed. When a function with the exception signature
throw() is called, it is know that such a function cannot throw
an exception that will be seen by the caller. At worst it
will throw an exception and the function unexpected() will
be called. However, that situation is a kind of mistake anyway
and it doesn't affect what happens in the caller.
My point is that the use of throw(), where it does not lead
to unexpected(), will result in an efficiency savings in the
caller and the program overall. Ideally, compilers/linkers
should be able to at least warn people when throw() is used
in a situation where unexpected() would be generated, though
I realize that tracking this automatically may take some
work. In the mean time, the programmer has the option of
trying to track it herself in order to realize this efficency.
>>>>Does this turn
>>>>out to be significant with existing implementations?
>>>I've never heard of a compiler that could take advantage of throw()
>>>specifications for optimization.
>>See Steve Clamage's posting.
>Yes, that's good news. Still, I wouldn't try to take advantage of
>those optimizations unless you know this about *your* compiler,
Well the particular optimization we are talking about is analogous
to not generating code for an "if(0)" conditional. It would
be great if compilers were even smarter than that and could
do global optimizations in situations where there is not a
throw() specification and yet an exception cannot occur.
But I am not expecting that with current technology. So
in some sense I am the one being conservative about the
compiler's capabilities on this particular issue.
> Even with aggressive EH
>optimization, the use of non-empty exception specifications will
>usually waste more space than it saves.
I think this is probably wrong, and if it is not it soon will be.
Nathan's comments on my original posting with regard to the use
of throw() everywhere made sense, but he was responding to my
question as stated and not to what I intended. I meant to
ask about the use of throw() where it can be determined that
it will not lead to unexpected() - as someone else mentioned,
it is analogous to const correctness. I believe that the
use of throw() rather than empty specification in this situations
should eliminate code bloat (probably at least one address pointer
per function call) and is also good software engineering.
>BTW, here's an interesting question to which I can't find the answer
>in FDIS. What does this program do?
>
>class X
>{
> X( const X& ) { throw 1; }
> const X& operator=( const X& ) { throw 'x'; return *this; }
>};
>
>X f() throw()
>{
> return X();
>}
>
>
>int main()
>{
> try
> {
> X x = f();
> }
> catch( int e )
> {
> cout << "copy constructor";
> }
> catch (char e )
> {
> cout << "assignment";
> }
It's a good question. I'm inclined to think that the
answer is implementation defined, with the two possible
choices being that the program prints nothing or the
program prints "copy constructor".
- Josh
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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 <BcuxTfAwTOt1EwEI@noco.demon.co.uk>,
Mike Davies <mike_davies@noco.demon.co.uk> wrote:
> In article <6p070r$fs4$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
> writes
> >In article <sf67PJAgKPs1Ew5M@noco.demon.co.uk>,
> > Mike Davies <mike_davies@noco.demon.co.uk> wrote:
> >
> >> Well, some of the features required to reduce executable size are
> >> available in *free* compilers (the template repository for example).
> >
> >I know that repositories (the standard technique in the UNIX world)
> >reduce compile and link times, but how do they reduce executable size?
>
> They can eliminate duplicate copies of templated functions being emitted
> into the executable. Of course there are also other methods of doing
> this.
Good point. I hadn't thought of this, because none of my compilers leave
duplicate copies around. (Most use repositories, and VC++ uses some other
technique.)
Of course, I'm not sure that eliminating duplicate copies isn't easier
for the compiler implementor than leaving them. If he leaves them, he
still has to ensure that the address of the functions compare equal, that
all of the copies used use a single instance of any local static variables,
etc. The program must behave as if there were only one copy.
--
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/22 Raw View
In article <6p3dtb$r4e$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
writes
>"FWIW" means For What It's Worth.
>What does "FW(L)IW" mean?
for what (little) it's worth
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: jkanze@otelo.ibmmail.com
Date: 1998/07/22 Raw View
In article <6p2laq$vtf$1@nnrp1.dejanews.com>,
CapuletJ@ix.netcom.com wrote:
>
>
> Pete Becker wrote:
>
> Tim Ottinger wrote:
> >
> > And you'd need a way to determine that you don't need to setup any of
> > the standard streams, or which ones to setup, etc.
> >
> > Surely a linker issue for the most part, no?
>
> Well, yes and no. The compiler and the linker have to work
together:
> the compiler generates the information that the linker uses.
> The key thing in this discussion is not whether the linker should
do
> various things, but being clear on what's a goal versus what's a
> technique for getting to that goal. A couple of good goals are: don't
> link in any unused non-virtual functions (easy -- library writers have
> known how to do this for years); don't link in any unused virtual
>
> The thing is, what counts as "unused" these days ? You don't in general know
> if an application is going to do a GetProcAddress/dlsym on your functions.
You do and you don't. The compiler/linker can trivially know whether
it is used non-polymorphicly, although I think that most don't try. For
polymorphic use, GetProcAddress is part of a hierarchy, in which dlsym
is declared multiply, possibly some times as a pure virtual. A compiler
could note the necessary information, for the linker to use, as to whether
any of the dlsym in the hierarchy are called. If none are, then
GetProcAddress::dlsym cannot be called, even polymorphically.
None of the compilers I use do this, but in fairness to them, none
target platforms where memory is a 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/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
Mike Davies <mike_davies@noco.demon.co.uk> wrote in article <Wse0fXAzGOt1EwkR@noco.demon.co.uk>...
> > Source Lang OBJ EXE code data Notes
> > ---------- ---- ------ ------ ----- ---- ------
> > hello1.c C 432 27,648 18 14 printf
> > hello2.cpp C++ 432 27,648 18 14 printf
> > hello3.cpp C++ 432 27,648 18 14 printf
> > hello4.cpp C++ 11,857 63,488 2,029 14 cout, iostream
> > hello5.cpp C++ 539 35,328 22 14 cout, iostream.h
> >
> I'm interested to know how that 11k in the object file turns into nearly
> 30k in the executable file ? I would have expected the linker to have
> discarded unreferenced code, not expanded it ?
I think you will find that all of that 11 KB included in the object file is used.
Much of it represents template member functions pulled out of the standard
headers. The added code in the executable represents still more stuff
pulled in from precompiled objects.
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 <4$6PbKAivNt1Ewxw@noco.demon.co.uk>,
Mike Davies <mike_davies@noco.demon.co.uk> wrote:
> In article <35B14870.D78F1E97@acm.org>, Pete Becker <petebecker@acm.org>
> writes
>
> >Let me say it again: nobody has given any evidence that Watcom's
> >optimizations are effective for the full C++ library.
>
> I don't understand your reasons for doubting it ?
Maybe experience:-). Can you say that all vendor claims have always been
true. My experience with optimization is that the vendors claim a lot, but
a lot of what they claim only works for small test programs. (Back in
the days of MS-DOS, it was amazing how well compilers could optimize
the Byte benchmarks. And how little these optimizations helped real
code.)
[...]
> I should say that by "unused" I meant "unreferenced". The Microsoft
> Visual C++ 5.0 has the facility to avoid linking in unreferenced
> functions/data, The linker switch is /OPT:UNREF or /OPT:REF or something
> (I don't have a copy here to check). The relevant compiler switch I
> don't recall at all, try searching for COMDEF in the docs.
For what definition of referenced? I'll bet you'll find that the
reference to the function in a vtbl is all that is needed for the
function to count as referenced. (I'm not saying that this should
be the case, or even that Microsoft in particular does it, since I
haven't actually checked. But it is the usual case, and given the
usual size of Windows programs anyway, I don't think that space
optimization is one of the top priorities at Microsoft.)
> If you are writing libraries for VC++ (pace another post in this thread)
> then you must know that so I suppose there is a misunderstanding here ?
>
> >>
> >> Well, some of the features required to reduce executable size are
> >> available in *free* compilers (the template repository for example).
> >
> >What "template repository" is this? cfront had one, and apparently it
> >caused more problems that it solved.
>
> The Gnu compiler uses a repository, I understand that it works well (on
> some platforms anyway)
All of the UNIX compilers I've used except g++ have used some sort of
repository: ptrepository for CFront based compilers, Template.DB for
Sun CC, inctemp for CSet++, etc. I'm not sure what the remark about
"caused more problems than it solved" is supposed to mean--modern UNIX
compilers continue to use repositories, and I've not heard of any problems
due per se to repositories concerning CFront.
The major problem I've heard concerning CFront is (or was) outrageously
long compile times. This was mainly due (I think) to a link-time template
instantiation policy, and recompiling each function separately--without
precompiled headers, this doubtlessly meant rereading and reparsing the
same header files hundreds of times at each link.
A general problem with repositories is detecting when you have to regenerate
the contents. But the MS-DOS/Windows model of generating all necessary
instances in the object file, then throwing away the duplicates, only
avoids this problem if the linker verifies that the copies being thrown
away really are duplicates, and not different versions. It also leads to
significantly bigger object files.
My personal feeling is that no one really knows how to implement templates.
Every one hacks around, and gets something that sort of works, and we put
up with it because the alternative is generic.h.
--
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 <35B4C954.A187AE43@eng.sun.com>,
Michael Ball <michael.ball@Eng.Sun.COM> wrote:
> David Abrahams wrote:
> > Isn't that case dependent on the compiler's ability to analyze that no
> > exceptions are thrown? In other words, if T::~T() has no throw()
> > specification, and is not inline, the compiler still has to generate
> > the try/catch block for auto_ptr<T>::~auto_ptr()... yes?
>
> That's correct. It can only use information it has.
But in the specific case in question (auto_ptr), it has the information
that if T::~T() exits by an exception, undefined behavior occurs. Which
should be sufficient to allow suppression of the try block for this
particular case.
--
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 <35b4dd22.80125327@news.motu.com>,
abrahams@motu.com wrote:
> BTW, here's an interesting question to which I can't find the answer
> in FDIS. What does this program do?
>
> class X
> {
> X( const X& ) { throw 1; }
> const X& operator=( const X& ) { throw 'x'; return *this; }
> };
>
> X f() throw()
> {
> return X();
> }
>
> int main()
> {
> try
> {
> X x = f();
> }
> catch( int e )
> {
> cout << "copy constructor";
> }
> catch (char e )
> {
> cout << "assignment";
> }
> }
>
> I wonder how many compilers that implement the elision of temporaries
> optimization get this right...
It's hard to say. As written, the program won't compile, first, because
all of the constructors are private, and secondly, because there is
no default constructor, so the return X() in f is illegal.
Correcting these two problems, I think that the output is undefined,
although I'm far from up to date on the final status of elision of
temporaries. Basically, the last time I looked (and the text in this
section HAS changed significantly since then), a compiler could legally
either call the default constructor, followed by the copy constructor,
or just call the default constructor.
In no case could it call the assignment operator, since there isn't a
single assignment in the program. The program would be legal, and
required to compile and work even if I failed to provide an implementation
of the assignment operator.
--
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: john@mail.interlog.com (John R MacMillan)
Date: 1998/07/22 Raw View
|The third type of optimisation is link time optimisation. Of course,
|the linker won't do real code transformation, [...]
Don't be so sure. I have seen a link-time optimiser that did
inlining, and I believe some other simple code transformations.
I've also seen an experimental object file optimizer that moved
code blocks, even across modules, in order to improve locality
of reference. These could easily be `part' of the linker.
This certainly isn't common, but I expect it to become more so.
|IMHO the role of the linker should not be underestimated. The linker
|has - especially in languages with separate compilation - the
|big advantage to see the whole code, and therefore to be able to
|make desicions based on general measures.
Right, which is why I expect to see more and more complex linker
optimisations.
--
To reply by mail, please remove "mail." from my address -- but please
send e-mail or post, not both
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: stephen.clamage@sun.com (Steve Clamage)
Date: 1998/07/21 Raw View
jstern@citilink.com (Josh Stern) writes:
>Since the de facto topic of this thread is code bloat
>in C++ and its relationship to quality of implementation,
>I'd like to ask about how much (if any) efficiency is gained
>with existing C++ compilers when throw() is added to
>all function definitions where it is permissible to add it.
With the Sun C++ compiler, there is no direct runtime penalty
for exception code when exceptions are not thrown. If
exceptions might occur, extra code must be generated to deal
with them. Catch block addresses are entered into static tables
that help locate the appropriate handler for an exception.
The extra amount of code and tables can lead to increased
working set size, and thus indirectly slow down a program.
The compiler does take notice of empty throw-specifications,
and omits generating code to deal with exceptions that
cannot occur. Of course, the function with an empty
throw specification needs extra code to be sure no
exceptions escape, but if that function contains nothing
that can throw an exception, that extra code is also omitted.
I don't have figures for selective use of empty throw
specifications. We have done some measurement of some
programs compiled with exceptions disabled and again with
exceptions enabled. When exceptions are enabled, the
total program size increases by about 10 to 15 percent.
>Also, I'm wondering whether it would be a sensible
>language extension for a compiler to offer, as a flag
>option, a processing mode where all functions
>that do not have throw signatures are interpreted as
>if they had the signature throw() and an error is
>issued where this does not work.
The standard library is going to cause problems. Few of the
functions have throw specifications, and many of them can
throw exceptions. The compiler doesn't see the code for
those functions when it compiles your program, so the
only error you can get is "terminate" when an exception
occurs at run time.
Now consider container templates. The exception behavior
of the member functions depends on the exception behavior
of the classes they are instantiated on.
--
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: abrahams@motu.com (David Abrahams)
Date: 1998/07/21 Raw View
On 20 Jul 98 06:27:04 GMT, jstern@citilink.com (Josh Stern) wrote:
>Since the de facto topic of this thread is code bloat
>in C++ and its relationship to quality of implementation,
>I'd like to ask about how much (if any) efficiency is gained
>with existing C++ compilers when throw() is added to
>all function definitions where it is permissible to add it.
>This question is motivated by the idea that a function
>with local objects that have non-trivial destructors may
>be able to optimize the scheduling of those destructors
>more efficiently when it knows that all of the functions
>it calls will not throw exceptions.
Unfortunately, throw() doesn't really mean what it seems to mean. When
you write throw() on a function definition, what it really says is:
"If this function does end up throwing an exception, catch it and call
unexpected() instead."
So effectively, it wraps each call to the function in a try/catch
block. The compiler has two options:
1. Add the try/catch block externally to the function. In most
implementations that would amount to a lot of extra code. A reeaally
smart implementation could probably take advantage of the knowledge
that unexpected handlers aren't allowed to return, but I doubt if you
can totally eliminate the space overhead implied by any cleanup
action.
2. Add the try/catch internally. Think about what happens to simple
functions with non-trivial destructors. Now they have to support the
call to unexpected. One example which, I regret, crept into the
standard is std::auto_ptr<T>::~auto_ptr() throw(). Without the throw
specification all it needs to do is a single call to delete T. I hope
most implementors will at least include an option to remove the
throw() specifications from std::auto_ptr, since they force the
compiler to deal specially with exceptions in T's destructor, adding
code size in all implementations I've seen.
In my opinion, throw() specifications do more harm than good most of
the time.
>Does this turn
>out to be significant with existing implementations?
I've never heard of a compiler that could take advantage of throw()
specifications for optimization. Aside from that, there are
significant disadvantages as detailed above.
>Also, I'm wondering whether it would be a sensible
>language extension for a compiler to offer, as a flag
>option, a processing mode where all functions
>that do not have throw signatures are interpreted as
>if they had the signature throw() and an error is
>issued where this does not work. Even if this did
>not lead to efficiency gains, I personally
>prefer to program with an exception handling style
>where I know very explicitly what can be thrown
>from where and such a flag would help with intergration
>of third party source.
I agree that "does not throw any exceptions" is an important thing to
know about a function. The most useful way to know that in C++ is to
practice and rely on good documentation.
-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: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/07/21 Raw View
Josh Stern<jstern@citilink.com> wrote:
>Since the de facto topic of this thread is code bloat
>in C++ and its relationship to quality of implementation,
>I'd like to ask about how much (if any) efficiency is gained
>with existing C++ compilers when throw() is added to
>all function definitions where it is permissible to add it.
It's a tradeoff. The function declared throw() may get bigger
or smaller, depending on the compiler and what's in the function.
The caller might get smaller, but shouldn't get bigger. In current
compilers, expect worse performance overall, except in certain cases.
(See below.) There's no point in declaring an inline function
throw(), because the compiler can see for itself.
If the function does anything that *might* throw (including call
a function not declared throw() itself) the compiler is obliged
to add a try/catch block to call unexpected() if something throws.
If the compiler doesn't check what the statements in the function
might throw, it must add the try/catch block regardless. Probably
most current compilers are in this camp.
When calling a function declared throw(), the compiler can take
advantage of knowing that the function will return, and doesn't
need to ensure there's enough state available at that point to
clean up. This means, at least, that the call site doesn't need
to be added to the state table.
Optimization for exceptions is still new in current compilers,
so they generally treat it pessimistically. Many ignore whether
the called function is declared throw(). Those that don't might
do certain optimizations that leave variable values in registers
only, which would otherwise need to be flushed out to memory before
the call. (The catch handler might need the values of some
variables.)
It makes sense at least to declare extern "C" functions throw(),
because there is a possibility that optimizations will be possible,
and no cost.
>Also, I'm wondering whether it would be a sensible
>language extension for a compiler to offer, as a flag
>option, a processing mode where all functions
>that do not have throw signatures are interpreted as
>if they had the signature throw() and an error is
>issued where this does not work. Even if this did
>not lead to efficiency gains, I personally
>prefer to program with an exception handling style
>where I know very explicitly what can be thrown
>from where and such a flag would help with intergration
This wouldn't work in practice unless you avoid templates.
It's generally impractical to declare a list of exceptions
that might be thrown by a template when you don't know what
the operations it depends upon might throw. Trying to catch
and relabel all exceptions thrown all such operations would
make your template code unreadable, slow it way down, and
discard useful information about what happened.
Anyway to use such an option would mean you couldn't use libraries,
which would not be declared compatibly.
(I'll deal with my Lakos complaints in a separate posting.)
--
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/21 Raw View
In article <RMq1XKA6G+r1EwXw@noco.demon.co.uk>,
Mike Davies <mike_davies@noco.demon.co.uk> wrote:
> In article <35AE4945.69E6@noSPAM.central.beasys.com>, David R Tribble
> <david.tribble@noSPAM.central.beasys.com> writes
>
> ...snip...
>
> >Summary:
> > Source Lang OBJ EXE code data Notes
> > ---------- ---- ------ ------ ----- ---- ------
> > hello1.c C 432 27,648 18 14 printf
> > hello2.cpp C++ 432 27,648 18 14 printf
> > hello3.cpp C++ 432 27,648 18 14 printf
> > hello4.cpp C++ 11,857 63,488 2,029 14 cout
> >
> >Maybe I'm wrong, but it sure looks like using 'cout' brings a
> >lot more baggage into an object file that 'printf' does.
>
> It may using *that* library, but MS are not reknowned for small object
> files in any case.
I'll have to agree with Mike with regards to the OBJECT size: the
technique that Microsoft (and many others) use for template instantiation
will result in very large object files. All of the UNIX compilers do
better here.
On the other hand, the issue was NOT the size of the object files, but
of the executable (which is all you would have to put in memory in an
embedded system, typically developped using a cross-compiler. I just
repeated the tests myself, using <stdio.h>, <iostream.h> and <iostream>:
file size text segment size
<stdio.h> 30720 16384
<iostream.h> 37376 36352
<iostream> 66048 65024
The <iostream.h> is the classical iostream, without templates. The
difference is significant. (But I'm particularly curious about the
difference between the first two. Logically, printf must pull in
all of the conversion routines, whereas the only function necessary
in the ostream is to output a string. Can it be that the stdio.h uses
a shared library?)
Anyway, I'm not sure what all of this signifies. It is only one data
point in a case where there is significant variance.
--
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: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/07/21 Raw View
James Kuyper <kuyper@wizard.net> wrote:
>
>No one's claiming that removing unused virtual functions wouldn't solve
>most of the bloat problem. What some people are claiming is that doing
>so is very difficult without the use of weak references, and no one has
>provided evidence that any implementation that it is close to conforming
>with the new standard has actually removed most of the bloat by using
>weak references.
Sorry, I don't think this is an accurate summary.
Omitting unused virtual functions is an important tool for eliminating
some bloat, but weak references by themselves (as Pete likes to remind
us) are not sufficient to omit unused virtual functions; that takes a
linker extension. It is possible to omit some unused virtual functions
anyway (even without weak references) at some cost in performance,
through what I think PJ likes to call "heroics". ("Heroics" are a bitch
to maintain, so nobody likes them much.) In any case, weak references
and unused-virtual-function-omission are just tools in the hands of a
library implementer, and it is the implementer who eliminates bloat,
not the compiler or linker. Besides these tools, the implementer needs
cleverness, a big bag of tricks, and a near-fanatical devotion to ...
(sorry about that ;-).
In other words, if the implementer doesn't care about bloat, then
the best mature compiler/linker won't help much. If the implementer
_does_ care about bloat, a good compiler/linker can make the job a
lot easier.
Compilers and linkers are maturing rapidly, and library implementers'
bags of tricks are getting better all the time. This time next year
everybody will wonder why there was all this talk about bloat.
--
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/21 Raw View
In article <sf67PJAgKPs1Ew5M@noco.demon.co.uk>,
Mike Davies <mike_davies@noco.demon.co.uk> wrote:
> Well, some of the features required to reduce executable size are
> available in *free* compilers (the template repository for example).
I know that repositories (the standard technique in the UNIX world)
reduce compile and link times, but how do they reduce executable size?
--
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/21 Raw View
> hello4.cpp:
> #include <iostream>
>
> int main(void)
> {
> std::cout << "Hello, world\n";
> return 0;
> }
I also added another version of the hello program which uses the
old <iostream.h> header (also compiled under Microsoft Visual C++
5.0):
hello5.cpp:
#include <iostream.h>
int main(void)
{
::cout << "Hello, world\n";
return 0;
}
539 hello5.obj
35328 hello5.exe
Summary:
Source Lang OBJ EXE code data Notes
---------- ---- ------ ------ ----- ---- ------
hello1.c C 432 27,648 18 14 printf
hello2.cpp C++ 432 27,648 18 14 printf
hello3.cpp C++ 432 27,648 18 14 printf
hello4.cpp C++ 11,857 63,488 2,029 14 cout, iostream
hello5.cpp C++ 539 35,328 22 14 cout, iostream.h
So it looks like the old version of 'cout' yanks in a similar
amount of overhead as 'printf' (only 4 more bytes of object code),
while the new 'std::cout' yanks in a great deal more (113 times
as much 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: jstern@citilink.com (Josh Stern)
Date: 1998/07/21 Raw View
Steve Clamage <stephen.clamage@sun.com> wrote:
>jstern@citilink.com (Josh Stern) writes:
>>Since the de facto topic of this thread is code bloat
>>in C++ and its relationship to quality of implementation,
>>I'd like to ask about how much (if any) efficiency is gained
>>with existing C++ compilers when throw() is added to
>>all function definitions where it is permissible to add it.
>With the Sun C++ compiler, there is no direct runtime penalty
>for exception code when exceptions are not thrown. If
>exceptions might occur, extra code must be generated to deal
>with them. Catch block addresses are entered into static tables
>that help locate the appropriate handler for an exception.
>The extra amount of code and tables can lead to increased
>working set size, and thus indirectly slow down a program.
>The compiler does take notice of empty throw-specifications,
>and omits generating code to deal with exceptions that
>cannot occur. Of course, the function with an empty
>throw specification needs extra code to be sure no
>exceptions escape, but if that function contains nothing
>that can throw an exception, that extra code is also omitted.
This all sounds like optimal behavior - what I was
hoping for. I only have the Dec. 1996 draft to go
by, but it seems to me that a call to a function with
throw() for its exception signature falls under the the
category of something that cannot throw an exception from
the viewpoint of the caller. So it sounds like for
the Sun C++ compiler the user of a throw() signature in
a given function may lead to space savings in callers
of that function which are otherwise devoid of exception
generating code.
>>Also, I'm wondering whether it would be a sensible
>>language extension for a compiler to offer, as a flag
>>option, a processing mode where all functions
>>that do not have throw signatures are interpreted as
>>if they had the signature throw() and an error is
>>issued where this does not work.
>The standard library is going to cause problems. Few of the
>functions have throw specifications, and many of them can
>throw exceptions. The compiler doesn't see the code for
>those functions when it compiles your program, so the
>only error you can get is "terminate" when an exception
>occurs at run time.
That's a good point. I wonder whether it would be
permissible for an implementation to add more
informative throw specifications to its standard library.
It shouldn't break any source outside of the library.
Lacking such mods, I expect that I would generate
link time errors or undefined behavior, by effectively
changing the exception specification of a header after
an object file depending on it had been compiled.
A workaround might be to write some wrappers for
standard library functions with desired exception
specifications and only reference those in my source...
but that has a lot of drawbacks in terms of generated
inefficiencies and obscurities.
>Now consider container templates. The exception behavior
>of the member functions depends on the exception behavior
>of the classes they are instantiated on.
In this case, my ideal would be to have a compile time
error and diagnostic generated (causing me to then modify
my code). That is what I meant above by an "error".
- Josh
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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
jkanze@otelo.ibmmail.com wrote in article <6p0512$cnb$1@nnrp1.dejanews.com>...
> I'll have to agree with Mike with regards to the OBJECT size: the
> technique that Microsoft (and many others) use for template instantiation
> will result in very large object files. All of the UNIX compilers do
> better here.
Be that as it may, the problem here is *not* due to the use of templates,
per se (other than the structural issues I've raised several times).
> file size text segment size
> <stdio.h> 30720 16384
> <iostream.h> 37376 36352
> <iostream> 66048 65024
>
> The <iostream.h> is the classical iostream, without templates. The
> difference is significant. (But I'm particularly curious about the
> difference between the first two. Logically, printf must pull in
> all of the conversion routines, whereas the only function necessary
> in the ostream is to output a string. Can it be that the stdio.h uses
> a shared library?)
Even more important is the significant difference in *functionality* between
traditional iostreams and the full C++ library. Compare the code in my book,
The Draft Standard C++ Library, with the current VC++ headers. Both do
very much the same job for simple char I/O from/to streams, but they
differ dramatically in the amount of machinery involved. The book code
largely codifies existing practice -- it is traditional iostreams just a few
features added. The latest headers have to contend with locale objects,
facets, wide iostreams, etc., in ways that make it hard to optimize away
unused code.
Traditional iostreams has it even better than the book code. It doesn't have
to worry about exceptions, or about synchronizing I/O with the standard C
streams. Adding this functionality also tends to make code larger.
> Anyway, I'm not sure what all of this signifies. It is only one data
> point in a case where there is significant variance.
Indeed. We have to be careful when comparing apples and oranges,
particularly when we try to explain the reasons for the differences.
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/07/21 Raw View
In article <76JfqKAps4s1EwIf@noco.demon.co.uk>,
mike_davies@noco.demon.co.uk says...
[ ... ]
> Compilers with full implementations of the C++ library are not freely
> available yet are they ?
None of which I'm aware, though those using the Dinkumware library are
generally quite close.
> FW(L)IW Microsoft Visual C++ V5.0 gives a Win32 Console app "hello
> world" executable of 27648 bytes if "stdio.h" & "printf()" are used
> versus 35328 bytes if "iostream.h and "cout <<" are used.
Here you're using the older (quite non-standard) version of the
library. If you use iostream instead of iostream.h, you'll quickly
see a big difference.
--
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: jstern@citilink.com (Josh Stern)
Date: 1998/07/21 Raw View
David Abrahams <abrahams@motu.com> wrote:
>Unfortunately, throw() doesn't really mean what it seems to mean. When
>you write throw() on a function definition, what it really says is:
>
>"If this function does end up throwing an exception, catch it and call
>unexpected() instead."
But it does mean what it seems to mean from the viewpoint of a
function that might call the function with the throw()
signature.
>So effectively, it wraps each call to the function in a try/catch
>block.
I don't think that is correct. It would be silly.
>>Does this turn
>>out to be significant with existing implementations?
>I've never heard of a compiler that could take advantage of throw()
>specifications for optimization.
See Steve Clamage's posting.
- Josh
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jstern@citilink.com (Josh Stern)
Date: 1998/07/21 Raw View
Nathan Myers <ncm@nospam.cantrip.org> wrote:
>Josh Stern<jstern@citilink.com> wrote:
>>Since the de facto topic of this thread is code bloat
>>in C++ and its relationship to quality of implementation,
>>I'd like to ask about how much (if any) efficiency is gained
>>with existing C++ compilers when throw() is added to
>>all function definitions where it is permissible to add it.
>It's a tradeoff. The function declared throw() may get bigger
>or smaller, depending on the compiler and what's in the function.
>The caller might get smaller, but shouldn't get bigger.
I didn't really mean "permissible" in the sense of adding
the throw() signature to a function that actually has throw
statements or calls functions that do. What I meant to
ask was whether there would be a savings by adding the
maximally restrictive signature that doesn't lead to
a call to unexpected(). I'm sure were have all seen
lots of code that has no explicit exception signature,
and yet does simple things without throwing any
exceptions. By adding throw() in such cases, I would
expect some space savings, and certainly no space
increase.
>If the function does anything that *might* throw (including call
>a function not declared throw() itself) the compiler is obliged
>to add a try/catch block to call unexpected() if something throws.
>If the compiler doesn't check what the statements in the function
>might throw, it must add the try/catch block regardless. Probably
>most current compilers are in this camp.
>
>When calling a function declared throw(), the compiler can take
>advantage of knowing that the function will return, and doesn't
>need to ensure there's enough state available at that point to
>clean up. This means, at least, that the call site doesn't need
>to be added to the state table.
Yes, this was the kind of case that I was aiming for with
my mis-phrased question.
>>Also, I'm wondering whether it would be a sensible
>>language extension for a compiler to offer, as a flag
>>option, a processing mode where all functions
>>that do not have throw signatures are interpreted as
>>if they had the signature throw() and an error is
>>issued where this does not work. Even if this did
>>not lead to efficiency gains, I personally
>>prefer to program with an exception handling style
>>where I know very explicitly what can be thrown
>>from where and such a flag would help with intergration
>This wouldn't work in practice unless you avoid templates.
>It's generally impractical to declare a list of exceptions
>that might be thrown by a template when you don't know what
>the operations it depends upon might throw. Trying to catch
>and relabel all exceptions thrown all such operations would
>make your template code unreadable, slow it way down, and
>discard useful information about what happened.
You're probably right about "in practice", but I'd argue
that coders should take more care to distinguish between
exceptions that are really related to conditions
external to a program and exceptions that are functioning
like glorified 'assert' statements to catch programmer
errors. I'd like to be able to control the latter
with the usual variety of #ifdef options, and remove
the bloat from properly working programs. The former,
mostly related to I/O and input data, should probably
be handled in I/O and date verification modules.
- Josh
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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/21 Raw View
Steve Clamage wrote:
[...]
I want to add a third type of optimisation to the list, which IMHO
is the type most relevant to the current discussion.
>
> "Optimizing" is a catch-all term. Here are two aspects:
>
[... Front end optimisation of parse tree ...]
[... Back end optimisation of code ...]
The third type of optimisation is link time optimisation. Of course,
the linker won't do real code transformation, but it can do things
like omitting unused code, choosing between different versions of code
depending on other referenced symbols (or may be some other measures),
glueing together code snippets, ...
It's this stage where the problems discussed in this thread are
to be solved. Here the main work must be done by the library vendor
and the linker writer, the compiler itself must just provide a way
to pass the relevant information to the linker (of course the compiler
might make use of the linker capabilities himself as well).
IMHO the role of the linker should not be underestimated. The linker
has - especially in languages with separate compilation - the
big advantage to see the whole code, and therefore to be able to
make desicions based on general measures. Of course it doesn't know
anything about the meaning of the code it links, this is the
reason why the "instructions" what to do must come from the compiler
or library.
There are already good features in link formats like ELF (f.ex.
weak links/weak symbols), which can (and should) be used for
optimisation. There can possibly be done even more at link time.
There's another good point about the link time optimisation: Since
the linker is (mostly) language independant, it can do the same
optimisation for any language, provided the compiler lets you
generate the necessary linker info. Even assembler programs can
take advantage of that optimisation.
>
> >>and writing a compiler that doesn't
> >>optimize costs considerable less time than one that optimizes intensively.
>
> >Says who ?
>
> Optimizing is difficult. It takes a lot of time and effort to
> perform optimizations correctly, time and effort that you are
> then not spending on other things. Optimizing takes compile-time
> resources as well -- the more a compiler does, the longer it
> takes to generate an executable.
I think the link time optimisations will in general not take too
much time. The logic is generally quite simple (if that symbol
is referenced, put this code there, otherwise put that code there;
put this code after that code; if that symbol is defined, write the
value there, otherwise write that default value there; ...), and
it's basically the type of operation the linker has to do 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: Pete Becker <petebecker@acm.org>
Date: 1998/07/21 Raw View
Nathan Myers wrote:
>
> Compilers and linkers are maturing rapidly, and library implementers'
> bags of tricks are getting better all the time. This time next year
> everybody will wonder why there was all this talk about bloat.
I hope you're right, but I think you're a bit optimistic about the time
frame.
--
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: David Chase <chase@naturalbridge.com>
Date: 1998/07/21 Raw View
Steve Clamage wrote:
> With the Sun C++ compiler, there is no direct runtime penalty
> for exception code when exceptions are not thrown. If
> exceptions might occur, extra code must be generated to deal
> with them. Catch block addresses are entered into static tables
> that help locate the appropriate handler for an exception.
> The extra amount of code and tables can lead to increased
> working set size, and thus indirectly slow down a program.
If I recall correctly, (some of) those tables are in
a different linker section, and contain no runtime
relocations or writeable data. (On a paged memory
machine) if there's no exceptions, they need not
ever be read in from disk. On systems that share
non-writeable or non-written application or library
pages among processes, there will be at most one copy
of the tables in memory.
This didn't happen by accident :-).
David Chase
NaturalBridge LLC
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Ryszard Kabatek <rysio@rumcajs.chemie.uni-halle.de>
Date: 1998/07/21 Raw View
jkanze@otelo.ibmmail.com wrote:
>
> In article <6oocgp$6s2$1@shell7.ba.best.com>,
> ncm@nospam.cantrip.org (Nathan Myers) wrote:
> >
> > No, it doesn't. Everybody already knew that immature implementations
> > of the standard C++ library create bloat. The useful discussion would
> > be (and was starting to be) what tools are available to eliminate any
> > such bloat, and how to use them.
>
> Excellent point. So what tools are available? Are they available under
> UNIX (AIX or Solaris)? Windows NT?
>
> James Kanze
There's IBM's VisualAge C++ 4.0 (FDIS) for AIX, OS/2, WinNT:
http://www.software.ibm.com/ad/visualage_c++/
Ryszard Kabatek
--
Martin-Luther University Halle-Wittenberg
Department of Physical Chemistry
Geusaer Str. 88, 06217 Merseburg, Germany
Tel. +49 3461 46 2487 Fax. +49 3461 46 2129
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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/07/21 Raw View
On 21 Jul 1998 01:07:21 GMT, stephen.clamage@sun.com (Steve Clamage)
wrote:
>jstern@citilink.com (Josh Stern) writes:
>
>>Since the de facto topic of this thread is code bloat
>>in C++ and its relationship to quality of implementation,
>>I'd like to ask about how much (if any) efficiency is gained
>>with existing C++ compilers when throw() is added to
>>all function definitions where it is permissible to add it.
>
>With the Sun C++ compiler, there is no direct runtime penalty
>for exception code when exceptions are not thrown. If
>exceptions might occur, extra code must be generated to deal
>with them. Catch block addresses are entered into static tables
>that help locate the appropriate handler for an exception.
>The extra amount of code and tables can lead to increased
>working set size, and thus indirectly slow down a program.
Doesn't the Sun compiler put this code and tables someplace where they
won't be loaded unless needed?
>The compiler does take notice of empty throw-specifications,
>and omits generating code to deal with exceptions that
>cannot occur. Of course, the function with an empty
>throw specification needs extra code to be sure no
>exceptions escape, but if that function contains nothing
>that can throw an exception, that extra code is also omitted.
Isn't that case dependent on the compiler's ability to analyze that no
exceptions are thrown? In other words, if T::~T() has no throw()
specification, and is not inline, the compiler still has to generate
the try/catch block for auto_ptr<T>::~auto_ptr()... yes?
>I don't have figures for selective use of empty throw
>specifications. We have done some measurement of some
>programs compiled with exceptions disabled and again with
>exceptions enabled. When exceptions are enabled, the
>total program size increases by about 10 to 15 percent.
Just for completeness, I'll point out that in the cases with
exceptions disabled, the program contains no error handling at all ;).
Once the features Steve mentions are widely supported, I may change my
own policy w.r.t. the empty exception specification (only - the others
will always impose unwanted overhead).
In a way it's like const: if you're going to use it, it has a ripple
effect. Callers with the throw() specification need throw() on their
callees (to gain an optimization advantage). But in another important
way it is unlike const, namely, there is no compile-time assurance
that the ripple effect has been instituted. If it hasn't, a move
intended to reduce code overhead could easily backfire. This is
perhaps one area where a Java-like "checked exception" would be
useful. I'd like to see the specification throw(0) mean the same as
throw(), with the addition of some compile-time checks.
-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: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/21 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> wrote in article <76JfqKAps4s1EwIf@noco.demon.co.uk>...
> Compilers with full implementations of the C++ library are not freely
> available yet are they ?
We've been shipping fully conforming implementations of the Standard
C++ library to our OEM customers since about March. We don't usually
track our customers' shipping schedules, and we certainly don't speak
for them, so I can't say for certain whether our library is ``freely available''
at the moment. But any vendors who haven't shipped by now will probably
do so fairly soon.
Any compiler vendor who uses the latest version of the EDG front end
can support a fully conforming library today. (Yes, I know that EDG is
still missing some language features, but none that are needed by the
library.)
> FW(L)IW Microsoft Visual C++ V5.0 gives a Win32 Console app "hello
> world" executable of 27648 bytes if "stdio.h" & "printf()" are used
> versus 35328 bytes if "iostream.h and "cout <<" are used.
>
> This is a disimprovement of course, but not a huge one in absolute
> terms.
Glad you think so. I, for one, would like the full C++ library to weigh in
at the same size or smaller.
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: CapuletJ@ix.netcom.com
Date: 1998/07/21 Raw View
Pete Becker wrote:
Tim Ottinger wrote:
>
> And you'd need a way to determine that you don't need to setup any of
> the standard streams, or which ones to setup, etc.
>
> Surely a linker issue for the most part, no?
Well, yes and no. The compiler and the linker have to work together:
the compiler generates the information that the linker uses.
The key thing in this discussion is not whether the linker should do
various things, but being clear on what's a goal versus what's a
technique for getting to that goal. A couple of good goals are: don't
link in any unused non-virtual functions (easy -- library writers have
known how to do this for years); don't link in any unused virtual
The thing is, what counts as "unused" these days ? You don't in general know
if an application is going to do a GetProcAddress/dlsym on your functions.
Nick
-----== 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 <6p0512$cnb$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
writes
...snip...
>> It may using *that* library, but MS are not reknowned for small object
>> files in any case.
>
>I'll have to agree with Mike with regards to the OBJECT size: the
>technique that Microsoft (and many others) use for template instantiation
>will result in very large object files. All of the UNIX compilers do
>better here.
I was speaking loosely, by object file I meant executable, it's a common
enough idiom. It's true that MS Windows executables often have a
largish footprint anyway, regardless of what's inside them.
>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: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/21 Raw View
In article <35B14870.D78F1E97@acm.org>, Pete Becker <petebecker@acm.org>
writes
>Let me say it again: nobody has given any evidence that Watcom's
>optimizations are effective for the full C++ library.
I don't understand your reasons for doubting it ?
...snip...
>> Well, we're talking about whether the *language standard* leads to large
>> executables, or whether it is due to the implementation aren't we ?
>
>No, we're talking about whether engineering decisions should be based on
>actual data or on slogans.
I think your being misled by your particular circumstances : you're
trying to implement an efficient version of the standard library using
the particular compiler you're stuck with.
I'm as happy to find a solution in the compiler as the library inter-
dependencies, as long as there is one.
>> If there exists an implementation that can eliminate unused
>> functions/data then that is a *proof* that it is a QoI problem not a
>> language standard problem
>
>Nathan just agreed that ther is no such implementation currently. Do you
>know of one that he doesn't know of, or is this merely a red herring?
I should say that by "unused" I meant "unreferenced". The Microsoft
Visual C++ 5.0 has the facility to avoid linking in unreferenced
functions/data, The linker switch is /OPT:UNREF or /OPT:REF or something
(I don't have a copy here to check). The relevant compiler switch I
don't recall at all, try searching for COMDEF in the docs.
If you are writing libraries for VC++ (pace another post in this thread)
then you must know that so I suppose there is a misunderstanding here ?
>>
>> Well, some of the features required to reduce executable size are
>> available in *free* compilers (the template repository for example).
>
>What "template repository" is this? cfront had one, and apparently it
>caused more problems that it solved.
The Gnu compiler uses a repository, I understand that it works well (on
some platforms anyway)
...snip...
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: ark@research.att.com (Andrew Koenig)
Date: 1998/07/21 Raw View
In article <35B49039.E7A664F8@acm.org>,
Pete Becker <petebecker@acm.org> wrote:
> I hope you're right, but I think you're a bit optimistic about the time
> frame.
I removed the context to which this quote was replying because
it doesn't matter -- people in the software industry are *always*
optimistic about time frames.
Hofstadter's law: Things take longer than you expect,
even when you take Hofstadter's law into account.
:-)
--
--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: Pete Becker <petebecker@acm.org>
Date: 1998/07/22 Raw View
Andrew Koenig wrote:
>
> In article <35B49039.E7A664F8@acm.org>,
> Pete Becker <petebecker@acm.org> wrote:
>
> > I hope you're right, but I think you're a bit optimistic about the time
> > frame.
>
> I removed the context to which this quote was replying because
> it doesn't matter -- people in the software industry are *always*
> optimistic about time frames.
>
> Hofstadter's law: Things take longer than you expect,
> even when you take Hofstadter's law into account.
>
> :-)
Yup. The first 90% of the project takes 90% of the time, and the last
10% takes the next 90%.
--
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: peter.garner@toward.com (Crazy Pete)
Date: 1998/07/22 Raw View
In article <35B450B8.76EB6DC2@rumcajs.chemie.uni-halle.de>,
Ryszard Kabatek <rysio@rumcajs.chemie.uni-halle.de> writes:
> jkanze@otelo.ibmmail.com wrote:
>>
>> Excellent point. So what tools are available? Are they available under
>> UNIX (AIX or Solaris)? Windows NT?
>>
>> James Kanze
>
> There's IBM's VisualAge C++ 4.0 (FDIS) for AIX, OS/2, WinNT:
> http://www.software.ibm.com/ad/visualage_c++/
>
Is that vapourware or have they actually released V4.0? BTW KAI C++
http://www.kai.com
is also an excellent FDIS compiler.
Peace
Peter
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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
Mike Davies wrote:
>
> In article <35B14870.D78F1E97@acm.org>, Pete Becker <petebecker@acm.org>
> writes
>
> >Let me say it again: nobody has given any evidence that Watcom's
> >optimizations are effective for the full C++ library.
>
> I don't understand your reasons for doubting it ?
It's not a matter of doubting it, but of making decisions based on
knowledge rather than guessing. That's one of the fundamental tenets 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: Pete Becker <petebecker@acm.org>
Date: 1998/07/22 Raw View
Mike Davies wrote:
>
>
> I think your being misled by your particular circumstances : you're
> trying to implement an efficient version of the standard library using
> the particular compiler you're stuck with.
I'm not being misled by anything. I'm asking for concrete data instead
of speculation.
>
> I should say that by "unused" I meant "unreferenced". The Microsoft
> Visual C++ 5.0 has the facility to avoid linking in unreferenced
> functions/data, The linker switch is /OPT:UNREF or /OPT:REF or something
> (I don't have a copy here to check). The relevant compiler switch I
> don't recall at all, try searching for COMDEF in the docs.
COMDEF has very little to do with unreferenced functions. What COMDEFs
let you do is provide multiple definitions of the same object in
different translation units. If they're in COMDEF records the linker
picks one and ignores the others. It's there mostly for FORTRAN, but MSC
used to let you define the same global variable many times. I haven't
tried it lately.
>
> >>
> >> Well, some of the features required to reduce executable size are
> >> available in *free* compilers (the template repository for example).
> >
> >What "template repository" is this? cfront had one, and apparently it
> >caused more problems that it solved.
>
> The Gnu compiler uses a repository, I understand that it works well (on
> some platforms anyway)
How does having a repository reduce executable size?
--
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/22 Raw View
> Josh Stern<jstern@citilink.com> wrote:
> >I'd like to ask about how much (if any) efficiency is gained
> >with existing C++ compilers when throw() is added to
> >all function definitions where it is permissible to add it.
>
In article <6p04db$as$1@shell7.ba.best.com>,
ncm@nospam.cantrip.org (Nathan Myers) wrote:
> If the function does anything that *might* throw (including call
> a function not declared throw() itself) the compiler is obliged
> to add a try/catch block to call unexpected() if something throws.
In this case, is the compiler still required to "clean up" objects
that were constructed and not destructed? If not, the post-call
code becomes considerably simpler.
function a() { // Might throw
if (0==rand()) throw 1;
}
function b() throw() {
Object myObject(1);
for (int i=0; i<5; ++i) a();
}
The programmer has (incorrectly, in this case) guaranteed that a()
will not throw. If a does throw, is myObject guaranteed to call
the destructor? Because if not, we could simplify the call to a()
by simply jumping to unexpected() if a() throws, rather than
unwinding the stack first.
If stack unwinding is still guaranteed even in throw() functions,
then it seems impossible to implement exceptions without generating
code much fatter than C ever generated.
-----== 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 <76JfqKAps4s1EwIf@noco.demon.co.uk>,
Mike Davies <mike_davies@noco.demon.co.uk> wrote:
> FW(L)IW Microsoft Visual C++ V5.0 gives a Win32 Console app "hello
> world" executable of 27648 bytes if "stdio.h" & "printf()" are used
> versus 35328 bytes if "iostream.h and "cout <<" are used.
Sorry if this is off-topic; I'll keep it very short.
"FWIW" means For What It's Worth.
What does "FW(L)IW" mean?
-----== 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: jpb@msi.com (Jan Bielawski)
Date: 1998/07/22 Raw View
In article <35B0C06E.A512D14F@acm.org> Pete Becker <petebecker@acm.org> writes:
< Mike Davies wrote:
< >
< > In article <35AE4945.69E6@noSPAM.central.beasys.com>, David R Tribble
< > <david.tribble@noSPAM.central.beasys.com> writes
< >
< > ...snip...
< >
< > >Summary:
< > > Source Lang OBJ EXE code data Notes
< > > ---------- ---- ------ ------ ----- ---- ------
< > > hello1.c C 432 27,648 18 14 printf
< > > hello2.cpp C++ 432 27,648 18 14 printf
< > > hello3.cpp C++ 432 27,648 18 14 printf
< > > hello4.cpp C++ 11,857 63,488 2,029 14 cout
< > >
< > >Maybe I'm wrong, but it sure looks like using 'cout' brings a
< > >lot more baggage into an object file that 'printf' does.
< >
< > It may using *that* library, but MS are not reknowned for small object
< > files in any case.
<
< Please point to an implementation that does better. And include a
< similar set of data points, so that meaningful comparisons can be made.
OK, here it is on the SGI:
hello1.c:
#include <stdio.h>
int
main()
{
printf( "Hello\n" );
return 1;
}
hello2.c:
#include <iostream.h>
int
main()
{
cout << "Hello\n";
return 1;
}
hello1.o: 1732, a.out: 12680
hello2.o: 2896, a.out: 13192
After stripping:
a.out (hello1): 9076
a.out (hello2): 9076
--
Jan Bielawski )\._.,--....,'``.
Molecular Simulations Inc. /, _.. \ _\ ;`._ ,.
San Diego, CA fL `._.-(,_..'--(,_..'`-.;.'
jpb@msi.com http://www.msi.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 <76JfqKAps4s1EwIf@noco.demon.co.uk>,
Mike Davies <mike_davies@noco.demon.co.uk> wrote:
> In article <35AE3CCA.AED976B4@acm.org>, Pete Becker <petebecker@acm.org=
>
> writes
>
> ...snip...
>
> >Thus returning to the point where this all started six weeks ago. <g>
> >Yes, it's been asserted that executable size is largely a quality of
> >implementation issue. The problem is that nobody has been able to poin=
t
> >to an implementation that makes a reasonably small version of "Hello,
> >world" with the full C++ library.
>
> Compilers with full implementations of the C++ library are not freely
> available yet are they ?
>
> FW(L)IW Microsoft Visual C++ V5.0 gives a Win32 Console app "hello
> world" executable of 27648 bytes if "stdio.h" & "printf()" are used
> versus 35328 bytes if "iostream.h and "cout <<" are used.
>
> This is a disimprovement of course, but not a huge one in absolute
> terms.
See my other posting: iostream.h implements the classical iostream's,
without templates. Using "iostream", the image is significantly larger,
something around 64K.
Of course, on a Windows NT machine, even this significantly larger is
not enough to worry about. With 2G of virtual memory, who's going to
worry about 64K more or less. According to what I read, however, the
targetted machines of EC++ have between 64K and 128K of memory. An
additional 64K there could be important.
--
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=E9e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----=3D=3D Posted via Deja News, The Leader in Internet Discussion =3D=3D=
-----
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: Michael Ball <michael.ball@Eng.Sun.COM>
Date: 1998/07/22 Raw View
David Abrahams wrote:
> >With the Sun C++ compiler, there is no direct runtime penalty
> >for exception code when exceptions are not thrown. If
> >exceptions might occur, extra code must be generated to deal
> >with them. Catch block addresses are entered into static tables
> >that help locate the appropriate handler for an exception.
> >The extra amount of code and tables can lead to increased
> >working set size, and thus indirectly slow down a program.
>
> Doesn't the Sun compiler put this code and tables someplace where they
> won't be loaded unless needed?
The current release (4.2) does not put exception handling code in a
distant
section. This a result of certain backend limitations. Tables do go
into
a separate section and are loaded on demand.
The next release (coming soon to a Sun dealer near you) does put
exception handling code in a separate section, so it will not pay this
penalty.
> >The compiler does take notice of empty throw-specifications,
> >and omits generating code to deal with exceptions that
> >cannot occur. Of course, the function with an empty
> >throw specification needs extra code to be sure no
> >exceptions escape, but if that function contains nothing
> >that can throw an exception, that extra code is also omitted.
>
> Isn't that case dependent on the compiler's ability to analyze that no
> exceptions are thrown? In other words, if T::~T() has no throw()
> specification, and is not inline, the compiler still has to generate
> the try/catch block for auto_ptr<T>::~auto_ptr()... yes?
That's correct. It can only use information it has.
-Mike Ball-
Sun Microsystems
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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/07/22 Raw View
On 21 Jul 1998 16:25:17 GMT, in comp.std.c++ you wrote:
>David Abrahams <abrahams@motu.com> wrote:
>
>>Unfortunately, throw() doesn't really mean what it seems to mean. When
>>you write throw() on a function definition, what it really says is:
>>
>>"If this function does end up throwing an exception, catch it and call
>>unexpected() instead."
>
>But it does mean what it seems to mean from the viewpoint of a
>function that might call the function with the throw()
>signature.
>
>>So effectively, it wraps each call to the function in a try/catch
>>block.
>
>I don't think that is correct. It would be silly.
Silly or not, it is true. Whether the try/catch occurs inside the
called function body or outside in the caller is an implementation
detail. A good implementation will do it in the called function, but
when the function being called is inlined, there is no practical
difference anyway.
>>>Does this turn
>>>out to be significant with existing implementations?
>
>>I've never heard of a compiler that could take advantage of throw()
>>specifications for optimization.
>
>See Steve Clamage's posting.
Yes, that's good news. Still, I wouldn't try to take advantage of
those optimizations unless you know this about *your* compiler, AND
you can be sure of your own discipline in using throw(). I've looked
at the EH implementation in a few compilers, and as Nathan says, most
do not (yet) optimize EH aggressively. Even with aggressive EH
optimization, the use of non-empty exception specifications will
usually waste more space than it saves.
-Dave
BTW, here's an interesting question to which I can't find the answer
in FDIS. What does this program do?
class X
{
X( const X& ) { throw 1; }
const X& operator=( const X& ) { throw 'x'; return *this; }
};
X f() throw()
{
return X();
}
int main()
{
try
{
X x = f();
}
catch( int e )
{
cout << "copy constructor";
}
catch (char e )
{
cout << "assignment";
}
}
I wonder how many compilers that implement the elision of temporaries
optimization get this 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: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/22 Raw View
In article <35B3B5D5.453A@noSPAM.central.beasys.com>, David R Tribble
<david.tribble@noSPAM.central.beasys.com> writes
...snip...
>Summary:
> Source Lang OBJ EXE code data Notes
> ---------- ---- ------ ------ ----- ---- ------
> hello1.c C 432 27,648 18 14 printf
> hello2.cpp C++ 432 27,648 18 14 printf
> hello3.cpp C++ 432 27,648 18 14 printf
> hello4.cpp C++ 11,857 63,488 2,029 14 cout, iostream
> hello5.cpp C++ 539 35,328 22 14 cout, iostream.h
>
>So it looks like the old version of 'cout' yanks in a similar
>amount of overhead as 'printf' (only 4 more bytes of object code),
>while the new 'std::cout' yanks in a great deal more (113 times
>as much code).
I'm interested to know how that 11k in the object file turns into nearly
30k in the executable file ? I would have expected the linker to have
discarded unreferenced code, not expanded it ?
>-- David R. Tribble, dtribble@technologist.com --
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/22 Raw View
In article <6p070r$fs4$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
writes
>In article <sf67PJAgKPs1Ew5M@noco.demon.co.uk>,
> Mike Davies <mike_davies@noco.demon.co.uk> wrote:
>
>> Well, some of the features required to reduce executable size are
>> available in *free* compilers (the template repository for example).
>
>I know that repositories (the standard technique in the UNIX world)
>reduce compile and link times, but how do they reduce executable size?
They can eliminate duplicate copies of templated functions being emitted
into the executable. Of course there are also other methods of doing
this.
My post was in response to a comment about the user ending up paying for
compiler features.
>--
>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: James Kuyper <kuyper@wizard.net>
Date: 1998/07/22 Raw View
Mike Davies wrote:
>
> In article <35B14870.D78F1E97@acm.org>, Pete Becker <petebecker@acm.org>
> writes
>
> >Let me say it again: nobody has given any evidence that Watcom's
> >optimizations are effective for the full C++ library.
>
> I don't understand your reasons for doubting it ?
Because the same person who posted the Watcom results explained in a
follow-up message that he was using a version of the compiler which did
not implement most of the new features added by the new C++ standard.
Presumably that includes the locale and facets features that have added
so much bulk to the iostreams library. Whether or not that bulk is
removable has been the main bone of contention.
...
> I should say that by "unused" I meant "unreferenced". The Microsoft
> Visual C++ 5.0 has the facility to avoid linking in unreferenced
> functions/data, The linker switch is /OPT:UNREF or /OPT:REF or something
> (I don't have a copy here to check). The relevant compiler switch I
> don't recall at all, try searching for COMDEF in the docs.
>
> If you are writing libraries for VC++ (pace another post in this thread)
> then you must know that so I suppose there is a misunderstanding here ?
Removal of unreferenced ordinary functions is a widely implemented
option. Detection of unused virtual functions is a much more difficult
issue. From the point of view of a simple-minded linker, the definition
of a vtable entry looks like a reference to each of the virtual
functions it points to, while the linker has no idea at link time which
function is being referenced by any given virtual call of a virtual
function. Are you sure this compiler option removes 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: "P.J. Plauger" <pjp@dinkumware.com>
Date: 1998/07/20 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> wrote in article <sf67PJAgKPs1Ew5M@noco.demon.co.uk>...
> Um, I don't know what makes you think Watcom didn't apply this to their
> whole C++ library ? I would have thought that was their main motivation
> for implementing the option ?
Without asking the Watcom guys directly, I can guess that they did it
because some loud customers demanded it. That's what motivates most
compiler improvements. The traditional iostreams library doesn't *need*
this optimization. It typically has only a few unused virtuals, and they
tend to be trivial. Indeed, it is the piling on of well over a hundred unused
virtuals in the Standard C++ library that has suddenly made most of the
linkers in the world ``immature.''
> I would be interested to hear your guess at what percentage code
> shrinkage a well-implemented compiler option of this type would have on
> *your* library :-)
Not too much, in the case of the Dinkum C++ Library, but it would still
be a help. We avoid loading unused facets by a different kind of trickery.
> It might even be worth your while to try the Watcom compiler youselves
> (it's pretty cheap) that way you could use it as a stick to prod your
> compiler people with if you found a big improvement :-)
We've got a free copy, but like many of our customers, we can't afford free
software. The real cost is the time to deal with all the dialect issues,
particularly with template processing, between compilers. Moving a full
C++ library about is way more work than moving a C library, which I've
done dozens of times over the past couple of decades.
> By platform you mean compiler system right ? I understood weak
> references to be a technique by which a linker could omit a function it
> found defined in an object module that wasn't referenced elsewhere. I
> am relying upon my interpretation of the OMF386 file format document by
> Intel which (very briefly) describes this practice for the Microsoft
> compiler.
I haven't found out how to use weak references in VC++ or Borland yet.
Any more precise pointers would be appreciated. Once again, the use
of weak references won't solve all our problems with code bloat, but it
will help.
> Well, we're talking about whether the *language standard* leads to large
> executables, or whether it is due to the implementation aren't we ?
>
> If there exists an implementation that can eliminate unused
> functions/data then that is a *proof* that it is a QoI problem not a
> language standard problem
Well, yes, sort of -- and that proof is not yet forthcoming despite numerous
claims about what ``mature'' implementations can do even today. But the
issues are not as separable as you indicate. If a language standard gets
too far ahead of technology, then screaming ``quality of implementation''
is blaming the victim, in this case the poor implementors whose protests
were ignored. If you standardize it, they will come -- maybe, one day,
sooner or later.
> We know the lives of compiler writers are hard, so are ours. We need you
> to do your job well so that we can do ours well.
We're trying to. Any concrete advice on how we can become more mature
is appreciated.
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: "Bradd W. Szonye" <bradds@concentric.net>
Date: 1998/07/20 Raw View
> > In article <35AFD822.80D1A4E6@acm.org>, Pete Becker > > <petebecker@acm.org> writes
> > >A couple folks have pointed to a compiler that
> > >they say does it, and given evidence that it works in a trival
> > >program, but have not applied it to the full C++ library);
> Mike Davies wrote:
> >
> > Um, I don't know what makes you think Watcom didn't apply this to
> > their whole C++ library ? I would have thought that was their main
> > motivation for implementing the option ?
Pete Becker wrote:
>
> Let me say it again: nobody has given any evidence that Watcom's
> optimizations are effective for the full C++ library.
I suspect that the Watcom dead-virtual-stripping would improve the final
size of programs which use iostreams without using all the facilities of
iostreams and locales. However, I also suspect that the size improvement
would not be optimal without special attention to the way the included
library implementation was written; it might not even be possible to
completely eliminate, say, locale code without more support from the
compiler AND library.
For example, the compiler might need to detect that the program does not
change the locale at all in order to link a version of the iostream
library that has use of the C locale hardwired into the routines.
Otherwise it will call more generic locale facilities within the
streams, which might make dead virtual stripping less effective.
So I agree that part of the argument is whether it's "just" a QoI issue
or a library specification issue. While I think it may be possible to
link "Hello World" optimally, the library specification may make such an
implementation so costly as to be unlikely. In other words, QoI versus
specification trouble is a spectrum over cost, and the cost of stripping
"unused" parts of IO+locale may be acceptable only to implementations
with the tightest code-size requirements.
> > Well, we're talking about whether the *language standard* leads to
> > large executables, or whether it is due to the implementation
> > aren't we ?
>
> No, we're talking about whether engineering decisions should be based
> on actual data or on slogans.
You're both right: the standard does *lead* to large executables, but
doesn't necessarily mandate them. However, it's not a yes or no
question; it's a cost analysis. Therefore actual data is more important
than the simple "It's QoI" slogan.
> > If there exists an implementation that can eliminate unused
> > functions/data then that is a *proof* that it is a QoI problem not a
> > language standard problem
Well, it's *proof* that at least part of the solution exists in some
compilers.
> > We know the lives of compiler writers are hard, so are ours. We
> > need you to do your job well so that we can do ours well.
>
> I don't write compilers, sorry.
Well, okay, maybe not, but you are an Implementor, in that your company
produces an important part of the implementation. And I believe that
creating optimal C++ library implementations requires great skill on the
part of compiler and library writers, probably with close cooperation on
some points.
One last point: there are so many parts to a C++ compiler, and there is
such a strong desire to make the backend parts work with other parts of
the computer system (like other languages), that there tends to be some
fragmentation of repsonsibility. Furthermore, it's fairly common right
now to buy major pieces (parser, frontend, library) from outside
vendors. Take all the pieces: preprocessor, parser, semantic analyzer,
intermediate code generator, machine code generator, front-end
optimizater, peephole optimizater, global optimizer, linker, link
optimizer, template instantiator, run-time support library, language
support library, user-level language library, system libraries.
Now consider where all those pieces come from. Some are bought as-is
from other vendors, some created in cooperation between vendors, some
bought from outside then modified, some created by the C++ project, some
created by the C project, some created by cross-language teams, some
kept from legacy projects. Now estimate the cost of a feature (like dead
virtual stripping or more specifically dead locale stripping), and you
see why such a feature might be very expensive.
I agree that compiling "slim" iostream libraries is desirable, but the
cost and politics involved in actually making it *work* are probably
prohibitive at worst, slow at best. The easiest way to get a minimal IO
library is to write it as a seperate subset library, linked in by
explicit user request. Yes, it's an intrusive method (from the user's
point of view), but probably the most cost-effective one from
everybody's point of view.
I don't especially endorse language subsets, and I find subset options
annoying from a user's point of view; I hate having to pick my thread
model, shared library use, etc. at the project level; the compiler
should be able to figure it out, right? But I don't know whether I want
to pay for the alternative, because it just might not be worth it.
--
Bradd W. Szonye|bradds@concentric.net|http://www.concentric.net/~Bradds
My reply address is correct as-is. The courtesy of providing a correct
reply address is more important to me than time spent deleting spam.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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/20 Raw View
Mike Davies (mike_davies@noco.demon.co.uk) wrote:
: Um, I don't know what makes you think Watcom didn't apply this to their
: whole C++ library ? I would have thought that was their main motivation
: for implementing the option ?
Watcom currently don't implement the standard library, so it would not
be a fair comparison.
The Watcom library actually has some factoring problems, here's
dtribble's test code as compiled by Watcom. Note that hello4.c uses
older style iostreams, since Watcom don't support the new style.
Source Lang OBJ EXE code data Notes
---------- ---- ----- ------ ----- ----- -----
hello1.c C 453 37,888 26 14 printf
hello2.cpp C++ 499 37,888 26 14 printf
hello4.cpp C++ 644 37,888 30 14 cout
hello5.c C 447 33,792 23 13 puts
(hello3.cpp isn't supported.)
It would be interesting to try an implementation of the Standard
Library to see how well Watcom handled it, but currently the existing
C library bloat is enough to reduce it's use for generating small
programs.
Another data point: a release mode 32-bit program produced with Watcom
C and a release mode 16-bit program produced with Borland C: the
Watcom version is 471,040 bytes and the Borland version is 807,440
bytes. This is essentially single source.
So while Watcom demonstrates that it's possible to remove unused
virtual functions, it doesn't necessarily imply that this option is
useful in reducing bloat from the Standard 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: galibert@pobox.com (Olivier Galibert)
Date: 1998/07/20 Raw View
In article <01bdb322$ad7f4120$8a1ec2d0@porky>, P.J. Plauger wrote:
>Mike Davies <mike_davies@noco.demon.co.uk> wrote in article <sf67PJAgKPs1Ew5M@noco.demon.co.uk>...
>> Um, I don't know what makes you think Watcom didn't apply this to their
>> whole C++ library ? I would have thought that was their main motivation
>> for implementing the option ?
>
>Without asking the Watcom guys directly, I can guess that they did it
>because some loud customers demanded it. That's what motivates most
>compiler improvements.
AFAIK, there are a lot of third party libraries Out There[tm] that use
some orders of magnitude more virtuals than the C++ library.
Especially in the GUI area.
OG.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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/20 Raw View
Pete Becker <petebecker@acm.org> wrote:
>
>> If there exists an implementation that can eliminate unused
>> functions/data then that is a *proof* that it is a QoI problem not a
>> language standard problem
>
>Nathan just agreed that ther is no such implementation currently.
I said no such thing. Don't put words in my mouth.
Implementations that can omit some unused functions are commonplace,
even in C. Implementations that can omit some unused virtual
functions are also commonplace. Implementations that can omit
more virtual functions are available, if you care to try them.
A library implementor who cares to take advantage of this ability
can certainly use it to advantage. The suggestion that omitting
unused functions might have no effect on executable size is
frankly ludicrous.
--
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: jstern@citilink.com (Josh Stern)
Date: 1998/07/20 Raw View
Since the de facto topic of this thread is code bloat
in C++ and its relationship to quality of implementation,
I'd like to ask about how much (if any) efficiency is gained
with existing C++ compilers when throw() is added to
all function definitions where it is permissible to add it.
This question is motivated by the idea that a function
with local objects that have non-trivial destructors may
be able to optimize the scheduling of those destructors
more efficiently when it knows that all of the functions
it calls will not throw exceptions. Does this turn
out to be significant with existing implementations?
Also, I'm wondering whether it would be a sensible
language extension for a compiler to offer, as a flag
option, a processing mode where all functions
that do not have throw signatures are interpreted as
if they had the signature throw() and an error is
issued where this does not work. Even if this did
not lead to efficiency gains, I personally
prefer to program with an exception handling style
where I know very explicitly what can be thrown
from where and such a flag would help with intergration
of third party source.
- Josh (still wondering what Nathan dislikes in Lakos' book)
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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/20 Raw View
Mike Davies wrote:
>
> In article <35AFD822.80D1A4E6@acm.org>, Pete Becker <petebecker@acm.org>
> writes
...
> > The key thing in this discussion is not whether the linker should do
> >various things, but being clear on what's a goal versus what's a
> >technique for getting to that goal. A couple of good goals are: don't
> >link in any unused non-virtual functions (easy -- library writers have
> >known how to do this for years); don't link in any unused virtual
> >functions (harder -- nobody on this forum has described a technique for
> >doing this that works. A couple folks have pointed to a compiler that
> >they say does it, and given evidence that it works in a trival program,
> >but have not applied it to the full C++ library);
>
> Um, I don't know what makes you think Watcom didn't apply this to their
> whole C++ library ? I would have thought that was their main motivation
> for implementing the option ?
Well, they apply this to the whole library they provide, but previous
messages on this newsgroup indicate that the version of C++ they
implement lacks a great many of the features required by the new
standard. In particular, I believe they didn't have a iostreams library
that implements locales and facets in anything close to the full
functionality of the standard. This reduces greatly the significance of
the numbers that were quoted.
> >don't link in
> >initialization code that isn't used (usually straightforward).
> > Be wary, though, of overly generalized comments. "Use weak references",
> >for example, is meaningless if your platform doesn't support them.
>
> By platform you mean compiler system right ? I understood weak
> references to be a technique by which a linker could omit a function it
> found defined in an object module that wasn't referenced elsewhere. I
Author: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/21 Raw View
In article <35AE3CCA.AED976B4@acm.org>, Pete Becker <petebecker@acm.org>
writes
...snip...
>Thus returning to the point where this all started six weeks ago. <g>
>Yes, it's been asserted that executable size is largely a quality of
>implementation issue. The problem is that nobody has been able to point
>to an implementation that makes a reasonably small version of "Hello,
>world" with the full C++ library.
Compilers with full implementations of the C++ library are not freely
available yet are they ?
FW(L)IW Microsoft Visual C++ V5.0 gives a Win32 Console app "hello
world" executable of 27648 bytes if "stdio.h" & "printf()" are used
versus 35328 bytes if "iostream.h and "cout <<" are used.
This is a disimprovement of course, but not a huge one in absolute
terms.
--
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/07/21 Raw View
In article <6oocgp$6s2$1@shell7.ba.best.com>,
ncm@nospam.cantrip.org (Nathan Myers) wrote:
> David R Tribble <dtribble@technologist.com> wrote:
> >I compiled the following programs under Microsoft Visual C++ 5.0
> >and got the following results:
> >...
> >Maybe I'm wrong, but it sure looks like using 'cout' brings a
> >lot more baggage into an object file that 'printf' does.
> >
> >Hope this helps.
>
> No, it doesn't. Everybody already knew that immature implementations
> of the standard C++ library create bloat. The useful discussion would
> be (and was starting to be) what tools are available to eliminate any
> such bloat, and how to use them.
Excellent point. So what tools are available? Are they available under
UNIX (AIX or Solaris)? Windows NT?
--
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: Pete Becker <petebecker@acm.org>
Date: 1998/07/18 Raw View
Tim Ottinger wrote:
>
> And you'd need a way to determine that you don't need to setup any of
> the standard streams, or which ones to setup, etc.
>
> Surely a linker issue for the most part, no?
Well, yes and no. The compiler and the linker have to work together:
the compiler generates the information that the linker uses.
The key thing in this discussion is not whether the linker should do
various things, but being clear on what's a goal versus what's a
technique for getting to that goal. A couple of good goals are: don't
link in any unused non-virtual functions (easy -- library writers have
known how to do this for years); don't link in any unused virtual
functions (harder -- nobody on this forum has described a technique for
doing this that works. A couple folks have pointed to a compiler that
they say does it, and given evidence that it works in a trival program,
but have not applied it to the full C++ library); don't link in
initialization code that isn't used (usually straightforward).
Be wary, though, of overly generalized comments. "Use weak references",
for example, is meaningless if your platform doesn't support them. "Only
needs a few minor extensions" is only meaningful if you know what the
referenced extensions are and agree that they are minor and they are or
will be supported on your platform. "It's a quality of implementation
issue" is not a goal, not a technique, and not an argument. It's a
conclusion. It means "it is my opinion that the cost of solving this
problem should be borne by the purchasers of products developed in C++
(because of higher tool costs to developers and delayed availability of
those tools)."
--
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/18 Raw View
David R Tribble <david.tribble@noSPAM.central.beasys.com> wrote in article <35AE4945.69E6@noSPAM.central.beasys.com>...
> Summary:
> Source Lang OBJ EXE code data Notes
> ---------- ---- ------ ------ ----- ---- ------
> hello1.c C 432 27,648 18 14 printf
> hello2.cpp C++ 432 27,648 18 14 printf
> hello3.cpp C++ 432 27,648 18 14 printf
> hello4.cpp C++ 11,857 63,488 2,029 14 cout
>
> Maybe I'm wrong, but it sure looks like using 'cout' brings a
> lot more baggage into an object file that 'printf' does.
I'll be darned. Real numbers instead of just talk. FWIW, hello4.cpp
weighed in at over 250,000 bytes with just a straightforward implementation
of the Standard C++ library, before I began playing dirty tricks to make it
smaller. I got it down to a shade over 50,000 bytes by turning on every
compiler optimization I could think of. But all in all, I'd say that your quick
test is an accurate enough measure of the current situation.
I'd love to get hello4.cpp under 20,000 bytes with VC++, but I have yet to
figure out how.
> Hope this helps.
Indeed it does. Thanks.
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:
>I compiled the following programs under Microsoft Visual C++ 5.0
>and got the following results:
>...
>Maybe I'm wrong, but it sure looks like using 'cout' brings a
>lot more baggage into an object file that 'printf' does.
>
>Hope this helps.
No, it doesn't. Everybody already knew that immature implementations
of the standard C++ library create bloat. The useful discussion would
be (and was starting to be) what tools are available to eliminate any
such bloat, and how to use them.
--
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 <35AE4945.69E6@noSPAM.central.beasys.com>, David R Tribble
<david.tribble@noSPAM.central.beasys.com> writes
...snip...
>Summary:
> Source Lang OBJ EXE code data Notes
> ---------- ---- ------ ------ ----- ---- ------
> hello1.c C 432 27,648 18 14 printf
> hello2.cpp C++ 432 27,648 18 14 printf
> hello3.cpp C++ 432 27,648 18 14 printf
> hello4.cpp C++ 11,857 63,488 2,029 14 cout
>
>Maybe I'm wrong, but it sure looks like using 'cout' brings a
>lot more baggage into an object file that 'printf' does.
It may using *that* library, but MS are not reknowned for small object
files in any case.
>Hope this helps.
No, try again
>-- 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: Pete Becker <petebecker@acm.org>
Date: 1998/07/18 Raw View
Mike Davies wrote:
>
> In article <35AE4945.69E6@noSPAM.central.beasys.com>, David R Tribble
> <david.tribble@noSPAM.central.beasys.com> writes
>
> ...snip...
>
> >Summary:
> > Source Lang OBJ EXE code data Notes
> > ---------- ---- ------ ------ ----- ---- ------
> > hello1.c C 432 27,648 18 14 printf
> > hello2.cpp C++ 432 27,648 18 14 printf
> > hello3.cpp C++ 432 27,648 18 14 printf
> > hello4.cpp C++ 11,857 63,488 2,029 14 cout
> >
> >Maybe I'm wrong, but it sure looks like using 'cout' brings a
> >lot more baggage into an object file that 'printf' does.
>
> It may using *that* library, but MS are not reknowned for small object
> files in any case.
Please point to an implementation that does better. And include a
similar set of data points, so that meaningful comparisons can be made.
--
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
In article <35AFD822.80D1A4E6@acm.org>, Pete Becker <petebecker@acm.org>
writes
>Tim Ottinger wrote:
>>
>> And you'd need a way to determine that you don't need to setup any of
>> the standard streams, or which ones to setup, etc.
>>
>> Surely a linker issue for the most part, no?
>
> Well, yes and no. The compiler and the linker have to work together:
>the compiler generates the information that the linker uses.
> The key thing in this discussion is not whether the linker should do
>various things, but being clear on what's a goal versus what's a
>technique for getting to that goal. A couple of good goals are: don't
>link in any unused non-virtual functions (easy -- library writers have
>known how to do this for years); don't link in any unused virtual
>functions (harder -- nobody on this forum has described a technique for
>doing this that works. A couple folks have pointed to a compiler that
>they say does it, and given evidence that it works in a trival program,
>but have not applied it to the full C++ library);
Um, I don't know what makes you think Watcom didn't apply this to their
whole C++ library ? I would have thought that was their main motivation
for implementing the option ?
I would be interested to hear your guess at what percentage code
shrinkage a well-implemented compiler option of this type would have on
*your* library :-)
It might even be worth your while to try the Watcom compiler youselves
(it's pretty cheap) that way you could use it as a stick to prod your
compiler people with if you found a big improvement :-)
>don't link in
>initialization code that isn't used (usually straightforward).
> Be wary, though, of overly generalized comments. "Use weak references",
>for example, is meaningless if your platform doesn't support them.
By platform you mean compiler system right ? I understood weak
references to be a technique by which a linker could omit a function it
found defined in an object module that wasn't referenced elsewhere. I
am relying upon my interpretation of the OMF386 file format document by
Intel which (very briefly) describes this practice for the Microsoft
compiler.
>"Only
>needs a few minor extensions" is only meaningful if you know what the
>referenced extensions are and agree that they are minor and they are or
>will be supported on your platform.
>"It's a quality of implementation
>issue" is not a goal, not a technique, and not an argument. It's a
>conclusion.
Well, we're talking about whether the *language standard* leads to large
executables, or whether it is due to the implementation aren't we ?
If there exists an implementation that can eliminate unused
functions/data then that is a *proof* that it is a QoI problem not a
language standard problem
> It means "it is my opinion that the cost of solving this
>problem should be borne by the purchasers of products developed in C++
>(because of higher tool costs to developers and delayed availability of
>those tools)."
Well, some of the features required to reduce executable size are
available in *free* compilers (the template repository for example).
We know the lives of compiler writers are hard, so are ours. We need you
to do your job well so that we can do ours well.
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/19 Raw View
Mike Davies wrote:
>
> In article <35AFD822.80D1A4E6@acm.org>, Pete Becker <petebecker@acm.org>
> writes
> >A couple folks have pointed to a compiler that
> >they say does it, and given evidence that it works in a trival
program,
> >but have not applied it to the full C++ library);
>
> Um, I don't know what makes you think Watcom didn't apply this to
their
> whole C++ library ? I would have thought that was their main
motivation
> for implementing the option ?
Let me say it again: nobody has given any evidence that Watcom's
optimizations are effective for the full C++ library.
> >"Only
> >needs a few minor extensions" is only meaningful if you know what the
> >referenced extensions are and agree that they are minor and they are or
> >will be supported on your platform.
> >"It's a quality of implementation
> >issue" is not a goal, not a technique, and not an argument. It's a
> >conclusion.
>
> Well, we're talking about whether the *language standard* leads to large
> executables, or whether it is due to the implementation aren't we ?
No, we're talking about whether engineering decisions should be based on
actual data or on slogans.
>
> If there exists an implementation that can eliminate unused
> functions/data then that is a *proof* that it is a QoI problem not a
> language standard problem
Nathan just agreed that ther is no such implementation currently. Do you
know of one that he doesn't know of, or is this merely a red herring?
>
> > It means "it is my opinion that the cost of solving this
> >problem should be borne by the purchasers of products developed in C++
> >(because of higher tool costs to developers and delayed availability of
> >those tools)."
>
> Well, some of the features required to reduce executable size are
> available in *free* compilers (the template repository for example).
What "template repository" is this? cfront had one, and apparently it
caused more problems that it solved.
>
> We know the lives of compiler writers are hard, so are ours. We need you
> to do your job well so that we can do ours well.
I don't write compilers, sorry.
--
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: James Kuyper <kuyper@wizard.net>
Date: 1998/07/15 Raw View
Al Stevens wrote:
>
> >You can implement a maximally efficient heap sort
> >requiring just as many lines of code and the just as many man-hours of
> >development and debugging effort as an insertion sort? If so, please
> >write a book about how you do it - you'll make millions selling it.
>
> A bit of an exaggeration. Computer book authors don't make millions on a
> single book, particularly on programming books, and most particularly
> programming books about a single algorithm, and most, most particularly
> about books on a sorting algorithm, and most, most, most particularly about
> heap sort. You might sell a hundred copies if you could get anyone to
> publish it.
>
> Just want to set the record straight lest some souls think that we book
> authors are raking in the dough from you unsuspecting programming book
> buyers.
Ah, but I was assuming that the same technique might apply in other
areas as well, such as manufacturing. ;-) Imagine that we could build
Rolls Royces as easily as Yugos, and Crays would be no more expensive
than pocket calculators. A book revealing the secret for such a
technique would make millions!
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Tim Ottinger <ottinger@oma.com>
Date: 1998/07/16 Raw View
Pete Becker wrote:
> Now wait a minute. You're mixing topics. This comparison does not claim
> to be based on weak references. In any event, a 4% difference in size
> for a trivial program doesn't say much at all about what will happen to
> "Hello, world".
I'm admitting some confusion as to what is the correct topic. Are we discussing
the standard and its implementations, or extensions not listed there? Also, what
measurement are you looking for? If you're looking for the one-time cost of
the iostreams library, then "hello world" will give you something to start with,
I guess, and expand to find out how much is IO streams v. something else.
I just don't remember the minimal link size being anything but a QoI thing.
tim
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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
Tim Ottinger wrote:
>
> Pete Becker wrote:
>
> > Now wait a minute. You're mixing topics. This comparison does not claim
> > to be based on weak references. In any event, a 4% difference in size
> > for a trivial program doesn't say much at all about what will happen to
> > "Hello, world".
>
> I'm admitting some confusion as to what is the correct topic. Are we discussing
> the standard and its implementations, or extensions not listed there? Also, what
> measurement are you looking for? If you're looking for the one-time cost of
> the iostreams library, then "hello world" will give you something to start with,
> I guess, and expand to find out how much is IO streams v. something else.
> I just don't remember the minimal link size being anything but a QoI thing.
Thus returning to the point where this all started six weeks ago. <g>
Yes, it's been asserted that executable size is largely a quality of
implementation issue. The problem is that nobody has been able to point
to an implementation that makes a reasonably small version of "Hello,
world" with the full C++ library.
--
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/16 Raw View
Tim Ottinger <ottinger@oma.com> wrote:
>
>Pete Becker wrote:
>
>> Now wait a minute. You're mixing topics. This comparison does not claim
>> to be based on weak references. In any event, a 4% difference in size
>> for a trivial program doesn't say much at all about what will happen to
>> "Hello, world".
>
>I'm admitting some confusion as to what is the correct topic. Are we
>discussing the standard and its implementations, or extensions not
>listed there? Also, what measurement are you looking for? If you're
>looking for the one-time cost of the iostreams library, then
>"hello world" will give you something to start with, I guess, and
>expand to find out how much is IO streams v. something else.
>I just don't remember the minimal link size being anything but
>a QoI thing.
It's understandable that you would be confused about the topic.
The topic of this thread, until Pete weighed in, was the use of
weak references in library space optimization. In any case it's
entirely about QoI matters.
The goal in this case is to arrange that "hello world" does *not*
reveal a "one-time-cost" of using iostream, because on a good
implementation different iostream facilities have different
costs that are only incurred when the facility is used.
A linker that discards uncallable virtual functions can make a
big difference. A library constructed with careful use of weak
references can also make a big difference. A library written
with careful use of specialization can make a big difference.
--
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/16 Raw View
Nathan Myers wrote:
>
> The topic of this thread, until Pete weighed in, was the use of
> weak references in library space optimization. In any case it's
> entirely about QoI matters.
Sorry to have broken your rules. I thought the topic of this thread was
"C++ as PL/1".
--
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: Tim Ottinger <ottinger@oma.com>
Date: 1998/07/17 Raw View
Pete Becker wrote:
> Thus returning to the point where this all started six weeks ago. <g>
> Yes, it's been asserted that executable size is largely a quality of
> implementation issue. The problem is that nobody has been able to point
> to an implementation that makes a reasonably small version of "Hello,
> world" with the full C++ library.
Not too surprizing. The C++ library really is huge, and most linkers don't
break things down smaller than the object file (some template repos being
broken into tiny bits). A big library is both curse and cure.
And I missed parts of the conversation. Maybe I missed the part I took
us back to.
Wouldn't the ability to make very small "hello world" really be a major
change to linkage and object file layout? Maybe I'm behind the times,
but I understand that that's the case. If methods within an obj file could
be linked without the other methods of the obj file it looks like you could
start to square this away. I'm not sure it's even a compiler issue.
Of course, the other side of it is the dependency structure of the standard
library. If it's unnecessarily interdependent, you couldn't even separate the
methods in a reasonable way.
And link time would go through the roof. You'd seriously need a parallel
linker for any reasonably-large-sized project.
And you'd need a way to determine that you don't need to setup any of
the standard streams, or which ones to setup, etc.
Surely a linker issue for the most part, no?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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
Tim Ottinger wrote:
> I'm admitting some confusion as to what is the correct topic. Are we
> discussing the standard and its implementations, or extensions not
> listed there?
FWIW, I started this thread with the topic of comparing C++ with
PL/1, in that they were/are both alleged to be rather large
and complex languages. The topic has gradually morphed into a
discussion of the excess baggage you get when you use iostreams.
> Also, what measurement are you looking for? If you're
> looking for the one-time cost of the iostreams library, then "hello
> world" will give you something to start with, I guess, and expand to
> find out how much is IO streams v. something else. I just don't
> remember the minimal link size being anything but a QoI thing.
I compiled the following programs under Microsoft Visual C++ 5.0
and got the following results:
hello1.c:
#include <stdio.h>
int main(void)
{
printf("Hello, world\n");
return 0;
}
432 hello1.obj
27648 hello1.exe
hello2.cpp:
#include <stdio.h>
int main(void)
{
printf("Hello, world\n");
return 0;
}
432 hello2.obj
27648 hello2.exe
hello3.cpp:
#include <cstdio>
#if HAS_STD
using std::printf;
#endif
int main(void)
{
printf("Hello, world\n");
return 0;
}
432 hello3.obj
27648 hello3.exe
hello4.cpp:
#include <iostream>
int main(void)
{
std::cout << "Hello, world\n";
return 0;
}
11857 hello4.obj
63488 hello4.exe
Summary:
Source Lang OBJ EXE code data Notes
---------- ---- ------ ------ ----- ---- ------
hello1.c C 432 27,648 18 14 printf
hello2.cpp C++ 432 27,648 18 14 printf
hello3.cpp C++ 432 27,648 18 14 printf
hello4.cpp C++ 11,857 63,488 2,029 14 cout
Maybe I'm wrong, but it sure looks like using 'cout' brings a
lot more baggage into an object file that 'printf' does.
Hope this helps.
-- 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: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/07/17 Raw View
Tim Ottinger <ottinger@oma.com> wrote:
>Wouldn't the ability to make very small "hello world" really be a major
>change to linkage and object file layout? ...
>Surely a linker issue for the most part, no?
It's a quality-of-implementation issue. The linker is part of
the implementation.
Fortunately, the ELF object format already provides most of what's
needed, and permits the (minor) extensions needed 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/07/18 Raw View
Tim Ottinger <ottinger@oma.com> wrote in article <35AE76BE.FFCF98E0@oma.com>...
> Wouldn't the ability to make very small "hello world" really be a major
> change to linkage and object file layout? Maybe I'm behind the times,
> but I understand that that's the case. If methods within an obj file could
> be linked without the other methods of the obj file it looks like you could
> start to square this away. I'm not sure it's even a compiler issue.
The problem with large executables is not caused by poor granularity in
object modules. We implementors generally get that right these days.
It's the interdependencies you cite below.
> Of course, the other side of it is the dependency structure of the standard
> library. If it's unnecessarily interdependent, you couldn't even separate the
> methods in a reasonable way.
Exactly.
> And link time would go through the roof. You'd seriously need a parallel
> linker for any reasonably-large-sized project.
Even with large link times, it's hard to make ``hello world'' as small as many
of us would like it to be.
> And you'd need a way to determine that you don't need to setup any of
> the standard streams, or which ones to setup, etc.
>
> Surely a linker issue for the most part, no?
Uh, yeah. We've been soliciting advice on how to solve those linker issues
for several weeks now. So far, I haven't learned any techniques that make
a significant difference with any of the compilers that use our libraries.
Still hoping.
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/13 Raw View
Mike Davies wrote:
>
> In article <6o5cib$d69$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
> writes
>
> >It's not a question of inefficient methods. It's a question of how a
> >compiler works.
>
> ie it *is* a question of (in)efficient methods
>
> >> >and writing a compiler that doesn't
> >> >optimize costs considerable less time than one that optimizes intensively.
> >>
> >> Says who ?
> >
> >Says anyone who has actually written a compiler. Have you ever actually
> >written a compiler? (I have.)
>
> No, I haven't. I have written lots of embedded system code that has had
> to be efficient. If there are several techniques readily available (ie
> published and understood by the SW engineer), it is as easy to use the
> efficient one as any other. There is such a thing as *progress* even in
> programming !
Are you seriously claiming that it is always just "as easy to use the
efficient one as any other"? In my personal experience, many tasks have
both simple and efficient algorithms, but the most efficient algorithms
are often significantly more complex, and correspondingly more difficult
to code correctly. You can implement a maximally efficient heap sort
requiring just as many lines of code and the just as many man-hours of
development and debugging effort as an insertion sort? If so, please
write a book about how you do it - you'll make millions selling 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: "Al Stevens" <alstevens@midifitz.com>
Date: 1998/07/14 Raw View
>You can implement a maximally efficient heap sort
>requiring just as many lines of code and the just as many man-hours of
>development and debugging effort as an insertion sort? If so, please
>write a book about how you do it - you'll make millions selling it.
A bit of an exaggeration. Computer book authors don't make millions on a
single book, particularly on programming books, and most particularly
programming books about a single algorithm, and most, most particularly
about books on a sorting algorithm, and most, most, most particularly about
heap sort. You might sell a hundred copies if you could get anyone to
publish it.
Just want to set the record straight lest some souls think that we book
authors are raking in the dough from you unsuspecting programming book
buyers.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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/09 Raw View
In article <XpGkeBAEC7o1Ewc5@noco.demon.co.uk>,
Mike Davies <mike_davies@noco.demon.co.uk> wrote:
> In article <6nj1q0$jm2$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
> writes
>
> >Assuming that someone today invented a technique which would magically
> >eliminate all of the extra space overhead. How long do you think it will
> >be before this technique is available in production compilers for the small
> >machines
>
> As long as it takes a compiler writer to write a C++ compiler starting
> from a base of C, I guess. If they're starting from scratch then what
> would be the point of implementing the compiler inefficiently ?
First, of course, writing a C++ compiler starting from C takes more time
than writing it from scratch. But that is irrelevant to the point; not
all known optimization techniques are used in all, or even most, compilers.
Optimization is almost an add-on, and writing a compiler that doesn't
optimize costs considerable less time than one that optimizes intensively.
In real life, between the moment a new optimization technique is invented,
and the moment it actually appears in commercial compilers, can be quite
long -- years, or even decades.
--
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/09 Raw View
In article <6o2fbi$o0h$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
writes
>In article <XpGkeBAEC7o1Ewc5@noco.demon.co.uk>,
> Mike Davies <mike_davies@noco.demon.co.uk> wrote:
>> In article <6nj1q0$jm2$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
>> writes
>>
>> >Assuming that someone today invented a technique which would magically
>> >eliminate all of the extra space overhead. How long do you think it will
>> >be before this technique is available in production compilers for the small
>> >machines
>>
>> As long as it takes a compiler writer to write a C++ compiler starting
>> from a base of C, I guess. If they're starting from scratch then what
>> would be the point of implementing the compiler inefficiently ?
>
>First, of course, writing a C++ compiler starting from C takes more time
>than writing it from scratch. But that is irrelevant to the point; not
>all known optimization techniques are used in all, or even most, compilers.
>Optimization is almost an add-on,
Says who ? If I were writing a compiler and I knew a technique that was
efficient, then that is the technique I'd use. I bet most compiler
writers would do the same if starting from scratch. It is only changes
to existing code that have an inertial weight behind leaving inefficient
methods in place.
>and writing a compiler that doesn't
>optimize costs considerable less time than one that optimizes intensively.
Says who ?
>In real life, between the moment a new optimization technique is invented,
>and the moment it actually appears in commercial compilers, can be quite
>long -- years, or even decades.
Or - like eliminating unused virtuals in Watcom 11 - it can appear
before the requirement reaches the language spec.
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/09 Raw View
In article <359E2C13.255C3AAF@acm.org>, Pete Becker <petebecker@acm.org>
writes
>The use of weak references to avoid code bloat from unused virtual
>functions (the actual subject under discussion here) has not been
>demonstrated to work. That's probably because weak references alone
>are not sufficient.
> Once again: where are the numbers to support these claims?
>
They were posted here before, I've dug out the article :
>James Kuyper (kuyper@wizard.net) wrote:
...snip...
>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.]
HTH,
--
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/10 Raw View
Pete Becker wrote:
>Nathan Myers wrote:
>>
>> Pete Becker wrote:
>> >Note, also, that the folks who recommended weak references as a
>> >solution here quickly realized that their proposed solutions did not
>> >work.
>>
>> This is a false and misleading statement.
>
>No, it is an absolutely accurate statement about the discussions that
>have taken place here.
It appears to me that Pete has confused this thread ("C++ as PL/I")
with a different thread. In this thread we were most recently
discussing library optimization in general, and the use of weak
references for the purpose.
I can't imagine what claim could be supported by pointing to an
off-hand speculation about an implementation technique that turned
out not to work (besides making fun of the poster). In particular,
it says nothing about:
- The practicality of removing unused virtual functions.
- The usefulness of removing unused virtual functions.
- The usefulness of weak references for other purposes.
The usefulness and practicality of removing unused virtuals (by
whatever means) was established some time ago. The usefulness of
weak references in library optimization in general _was_ under
discussion and (as it happens) has been well-proven in industrial
practice. An assertion that weak references are *not* actually
useful (which is what Pete appeared to be saying, in context)
would be extraordinary and would require serious documentary
support.
If we had not got sidetracked, I was hoping that this thread might
lead into discussion of precisely *how* weak references are useful
in library optimization. I think many people would find such an
exposition valuable. Does anybody know of a summary in print or
on the web that interested readers might be referred to?
--
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/07/10 Raw View
Mike Davies wrote:
>
> In article <359E2C13.255C3AAF@acm.org>, Pete Becker <petebecker@acm.org>
> writes
> >The use of weak references to avoid code bloat from unused virtual
> >functions (the actual subject under discussion here) has not been
> >demonstrated to work. That's probably because weak references alone
> >are not sufficient.
> > Once again: where are the numbers to support these claims?
> >
>
> They were posted here before, I've dug out the article :
>
> >James Kuyper (kuyper@wizard.net) wrote:
[figures showing that Watcom 11.0 does in fact seem to require little
space for unused virtual functions from the iostream.h library, and that
the space required can be reduced by choosing the vfremoval option.]
I am of course, pleased to see my name publicised. However, you gave the
credit to the wrong person. The one who actually wrote every character
you quoted was tony@ns.cook.ml.org (Tony Cook). His message was a reply
to one of mine, part of which was quoted in his message, but you
included none of my text in your excerpt.
Note that his test did not make the crucial test of comparing two
versions of the code, one of which had unusued virtual references, and
the other of which did not. It also involved <iostream.h>, not
<iostream>. Finally, note that his message contained no meantion of weak
references, which is the current topic of discussion; it only mentions
the removal of unused virtual functions, without specifying the
technique used.
In article <6nek5c$n4d$1@ns.cook.ml.org>, Tony Cook wrote:
...
> 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.
To me it seems that these deficiencies significantly reduce the
relevance of his earlier figures. The real question is whether a fully
standard-compliant implementation could achieve the same efficiency.
I've no opionion on that matter, and eagerly await relevant evidence.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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/11 Raw View
In article <mtToPEAXyPp1EwSD@noco.demon.co.uk>,
Mike Davies <mike_davies@noco.demon.co.uk> wrote:
> In article <6o2fbi$o0h$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
> writes
> >In article <XpGkeBAEC7o1Ewc5@noco.demon.co.uk>,
> > Mike Davies <mike_davies@noco.demon.co.uk> wrote:
> >> In article <6nj1q0$jm2$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
> >> writes
> >>
> >> >Assuming that someone today invented a technique which would magically
> >> >eliminate all of the extra space overhead. How long do you think it will
> >> >be before this technique is available in production compilers for the
small
> >> >machines
> >>
> >> As long as it takes a compiler writer to write a C++ compiler starting
> >> from a base of C, I guess. If they're starting from scratch then what
> >> would be the point of implementing the compiler inefficiently ?
> >
> >First, of course, writing a C++ compiler starting from C takes more time
> >than writing it from scratch. But that is irrelevant to the point; not
> >all known optimization techniques are used in all, or even most, compilers.
> >Optimization is almost an add-on,
>
> Says who ? If I were writing a compiler and I knew a technique that was
> efficient, then that is the technique I'd use. I bet most compiler
> writers would do the same if starting from scratch. It is only changes
> to existing code that have an inertial weight behind leaving inefficient
> methods in place.
It's not a question of inefficient methods. It's a question of how a
compiler works. If you just compile straightforward, the generated code
is not particularly good -- look at what comes out without optimisation.
Optimisation is an *additional* step. Writing an optimizer is additional
work; you do it after you finish the compiler, and the more you optimize,
the more work it is for the compiler writer. And of course, adding
optimization increases the chance of errors.
> >and writing a compiler that doesn't
> >optimize costs considerable less time than one that optimizes intensively.
>
> Says who ?
Says anyone who has actually written a compiler. Have you ever actually
written a compiler? (I have.)
> >In real life, between the moment a new optimization technique is invented,
> >and the moment it actually appears in commercial compilers, can be quite
> >long -- years, or even decades.
>
> Or - like eliminating unused virtuals in Watcom 11 - it can appear
> before the requirement reaches the language spec.
There is no "requirement" in the language specification to eliminate
unused virtuals. And it's easy to do in the simple cases (which is not
necessarily the case we are talking about). Nevertheless, it takes
added effort: Sun, HP and IBM (under AIX) don't bother, probably because
it's not worth the added effort. Watcom probably does it because their
customer's do care, and there are enough of them to pay for the effort.
At a still lower end, you have the problem on one side that there are
not enough C++ customers to pay for the effort, and on the other that
the amount of IO, etc. is extremely limited, so they don't need all
of the fancy functionality, and providing a stripped down library is
more cost efficient.
In the end, if a lot of customers want something, and are willing to
pay for it, they will get it, even if the technology isn't yet there.
If, on the other hand, there are cheaper ways of achieving the same
goals, the customer will probably prefer them.
--
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/11 Raw View
In article <35A4D078.41C6@wizard.net>,
James Kuyper <kuyper@wizard.net> wrote:
> Pete Becker wrote:
> >
> > Nathan Myers wrote:
> > >
> > > Pete Becker <petebecker@acm.org> wrote:
> > > >Note, also, that the folks who recommended weak references as a
> > > >solution here quickly realized that their proposed solutions did not
> > > >work.
> > >
> > > This is a false and misleading statement.
> >
> > No, it is an absolutely accurate statement about the discussions that
> > have taken place here.
>
> Some people have recommended the use of weak references, and you have
> argued that this solution would not work. However, not all of the
> original proposers have publicly stated that they found your arguments
> convincing. To say "they ... realized" in the absence of such public
> statements requires either private communications or mind-reading.
With regards to weak references, I think that Pete is basically right.
There was a proposal suggesting how to use them; it was immediately
pointed out why this didn't work. If I recall right, the proponent
even posted after admitting that he hadn't thought of that.
Can we at least agree on the points we disagree on. Globally, I think
that the following statements should not draw much opposition:
1. Just declaring virtual functions as "weak links" is not sufficient.
2. If you control the entire compile and link procedure, you can certainly
eliminate some of the unused virtual functions (Watcom does). How many
is uncertain (as is how many you have to eliminate for the standard library
to be acceptable in any given environment).
3. Eliminating unused virtual functions is work. Vendors to large systems
are unlikely to do it, because it isn't worth the effort. Vendors for
little used systems are also unlikely to do it, because their target
market is too small to pay for it. For this reason, the technology is
not wide spread. Not knowing how Watcom do it, I couldn't even say if
it would be applicable to other systems (but I suspect that it would).
Finally, reality is that modern compilers DO generate enormous task
images with the standard library, and that this is not likely to change
in the immediate future -- the first priority of most compiler implementors
will be to become fully conform, and only then to consider C++ specific
optimization issues.
--
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: Pete Becker <petebecker@acm.org>
Date: 1998/07/11 Raw View
Mike Davies wrote:
>
> In article <359E2C13.255C3AAF@acm.org>, Pete Becker <petebecker@acm.org>
> writes
> >The use of weak references to avoid code bloat from unused virtual
> >functions (the actual subject under discussion here) has not been
> >demonstrated to work. That's probably because weak references alone
> >are not sufficient.
> > Once again: where are the numbers to support these claims?
> >
>
> They were posted here before, I've dug out the article :
>
> >James Kuyper (kuyper@wizard.net) wrote:
>
> ...snip...
>
> >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.
Now wait a minute. You're mixing topics. This comparison does not claim
to be based on weak references. In any event, a 4% difference in size
for a trivial program doesn't say much at all about what will happen to
"Hello, world".
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: stephen.clamage@sun.com (Steve Clamage)
Date: 1998/07/11 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> writes:
>>than writing it from scratch. But that is irrelevant to the point; not
>>all known optimization techniques are used in all, or even most, compilers.
>>Optimization is almost an add-on,
>Says who ? If I were writing a compiler and I knew a technique that was
>efficient, then that is the technique I'd use. I bet most compiler
>writers would do the same if starting from scratch. It is only changes
>to existing code that have an inertial weight behind leaving inefficient
>methods in place.
"Optimizing" is a catch-all term. Here are two aspects:
A C++ compiler front end can apply semantic rules to the parse
tree to simplify the code, resulting in more efficient runtime
programs. Compilers typically do a fair amount of that, because
it usually is not too difficult and has a good payoff. Examples
are constant folding and propagation, and elimination of
temporaries. This front-end work is inexpensive and can reduce
the amount of later optimizing required, speeding up the
compilation process as well as the final generated program.
Once the front-end work is done (syntax and sematic analysis)
and you get into code generation issues, you have a compeletely
different category of optimizing (or "code improvement" as it
is more properly known). The basic techniques are flow-graph
analysis and transformation at the higher level (such as
loop unrolling and hoisting code out of loops), and pattern
matching of code sequences at a lower level (combining
instruction patterns into a single more efficient instruction
on CISC architectures, finding the best instruction ordering
on RISC architectures, and the best use of registers on most
any architecture).
These latter code improvements are add-ons. With some compilers
they are even a separate pass which can be elminated to get
faster compilation.
>>and writing a compiler that doesn't
>>optimize costs considerable less time than one that optimizes intensively.
>Says who ?
Optimizing is difficult. It takes a lot of time and effort to
perform optimizations correctly, time and effort that you are
then not spending on other things. Optimizing takes compile-time
resources as well -- the more a compiler does, the longer it
takes to generate an executable.
Borland, for example, became very successful with first Pascal and
later C and C++ compilers that did no optimization but which were
very fast. They spent their resources on making compilers that were
easy to use. (I don't think that decision was the reason for Borland's
current less-successful circumstances, but that another subject.)
--
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: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/12 Raw View
In article <6o5cib$d69$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
writes
>It's not a question of inefficient methods. It's a question of how a
>compiler works.
ie it *is* a question of (in)efficient methods
>> >and writing a compiler that doesn't
>> >optimize costs considerable less time than one that optimizes intensively.
>>
>> Says who ?
>
>Says anyone who has actually written a compiler. Have you ever actually
>written a compiler? (I have.)
No, I haven't. I have written lots of embedded system code that has had
to be efficient. If there are several techniques readily available (ie
published and understood by the SW engineer), it is as easy to use the
efficient one as any other. There is such a thing as *progress* even in
programming !
>
>> >In real life, between the moment a new optimization technique is invented,
>> >and the moment it actually appears in commercial compilers, can be quite
>> >long -- years, or even decades.
>>
>> Or - like eliminating unused virtuals in Watcom 11 - it can appear
>> before the requirement reaches the language spec.
>
>There is no "requirement" in the language specification to eliminate
>unused virtuals.
It is a user efficiency issue required by features in the language spec.
>--
>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: "David J. Littleboy" <davidjl@gol.com>
Date: 1998/07/12 Raw View
Mike Davies wrote in message ...
> jkanze@otelo.ibmmail.com writes
>>It's not a question of inefficient methods. It's a question of how a
>>compiler works.
>
>ie it *is* a question of (in)efficient methods
>
>>> >and writing a compiler that doesn't
>>> >optimize costs considerable less time than one that optimizes
intensively.
>>>
>>> Says who ?
>>
>>Says anyone who has actually written a compiler. Have you ever actually
>>written a compiler? (I have.)
>
>No, I haven't. I have written lots of embedded system code that has had
>to be efficient. If there are several techniques readily available (ie
>published and understood by the SW engineer), it is as easy to use the
>efficient one as any other. There is such a thing as *progress* even in
>programming !
Mike, you are just plain wrong here: optimizations in a compiler are
separate and independent phases that are *in addition to* the zeroth level
work required to translate from source to parse tree and from parse tree to
machine code. Being independent phases, they represent *additional* work up
and beyond meeting the requirements of the language definition. Even worse,
they may be impacted by changes in the language defintion, since the data
and data structures that are their input may change. This means that
optimizations are always additional work and you never get them for free
just for doing it right in the first place.
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/07/13 Raw View
In article <fe3q1.10$mn4.259009@mothra.gol.ad.jp>, "David J. Littleboy"
<davidjl@gol.com> writes
>
>Mike Davies wrote in message ...
...snip...
>>>> Says who ?
On reflection, and not having ever written a compiler, I should say I
regret the tone of the above remark.
>
>Mike, you are just plain wrong here: optimizations in a compiler are
>separate and independent phases that are *in addition to* the zeroth level
>work required to translate from source to parse tree and from parse tree to
>machine code. Being independent phases, they represent *additional* work up
>and beyond meeting the requirements of the language definition. Even worse,
>they may be impacted by changes in the language defintion, since the data
>and data structures that are their input may change. This means that
>optimizations are always additional work and you never get them for free
>just for doing it right in the first place.
Except that it might be possible to re-architecture the compiler/linker
system so that this was done differently. For instance maybe you could
have a database of machine resources/generated code and select the
appropriate code snippet according to what resources were still free in
the machine ?
I don't want to seeem to say that compilers are easy to write, or that I
am able to design compiler architectures off the top of my head better
than the existing proven methods. All I was trying to say is that new
techniques are likely to be easier to apply in a new product than retro-
fitted to an old one.
Steve Clamages post to this thread describes current compiler
architecture and shows why I am wrong (as you say above) to say that
optimisations are free when you write a compiler under this
architecture.
I hadn't expected that my post to be interpreted as only suggesting new
post generation optimisation phases (peepholes etc). I thought it was
common ground in C++ implementation circles that compilers/linkers were
going to have to get more intelligent or see a bigger picture than just
the single file. If I'm wrong then I'm wrong, Im not a compiler expert.
Of course the current architecture may be the only feasible one ?
>
>David J. Littleboy <davidjl@gol.nonspam.com>
(dons asbestos overcoat and climbs under desk),
--
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: jstern@citilink.com (Josh Stern)
Date: 1998/07/07 Raw View
Nathan Myers <ncm@nospam.cantrip.org> wrote:
>Josh Stern<jstern@citilink.com> wrote:
>>There is a very good book devoted to the topic of how to structure
>>a large C++ code base in order to achieve fast compilation,
>>good maintainability, readability, testability, etc.
>>John Lakos, _Large-Scale C++ Software Design_.
>> Addison-Wesley, 1996. ISBN 0-201-63362-0
>>The book is somewhat dry reading, but chock full of
>>recommendable content related to its title.
>The book contains a great deal of good advice, mixed with a
>substantial amount of very bad advice. Most of the bad advice
>seemed to be in the first couple of chapters.
I'm interested in your opinions. What would you like to take
a red pen to if you were the book's editor?
- Josh
jstern@citlink.com
[ moderator's note: We're straying off topic. "How to design
large software projects" does not belong in this newsgroup.
The impact of standard C++ on program design and implementation
is ok. Let's keep standard C++ in focus. -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: Mike Davies <mike_davies@noco.demon.co.uk>
Date: 1998/07/08 Raw View
In article <6nj1q0$jm2$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
writes
>Assuming that someone today invented a technique which would magically
>eliminate all of the extra space overhead. How long do you think it will
>be before this technique is available in production compilers for the small
>machines
As long as it takes a compiler writer to write a C++ compiler starting
from a base of C, I guess. If they're starting from scratch then what
would be the point of implementing the compiler inefficiently ?
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: john@mail.interlog.com (John R MacMillan)
Date: 1998/07/08 Raw View
|... [Hint to compiler writers: A
|compilation mode that specifically looks for things that might break
|when optimized - even if it takes significant analysis to find them -
|might be a big win.]
A good compiler with full warnings will catch some of them
(uninitialized variables are a very common one), but many of
them are impossible to detect. It's pretty much the same as
trying to diagnose undefined behaviour (which is where most
of the problems-under-optimization crop up): sometimes you
can, sometimes you can't.
Compiler writers do have some incentive, though; I obviously
can't speak for others but about half of the bug reports I used
to get against the optimizer were really problems in the user's
code, and I would have much rather spent my time finding and
fixing my own bugs. :-)
--
To reply by mail, please remove "mail." from my address -- but please
send e-mail or post, not both
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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/09 Raw View
Nathan Myers wrote:
>
> Pete Becker <petebecker@acm.org> wrote:
> >Note, also, that the folks who recommended weak references as a
> >solution here quickly realized that their proposed solutions did not
> >work.
>
> This is a false and misleading statement.
No, it is an absolutely accurate statement about the discussions that
have taken place here.
> The "proposed solution" referred to was a way to implement removing
> unused virtual functions without a linker (or pre-linker) extension.
Yes, and it was abandoned when I pointed out a flaw in the logic.
> That was when Pete was arguing that such an optimization was too
> difficult to implement at all,
I never made any such argument.
> instead of just complaining that nobody
> had quoted numbers to show it does anybody any good.
What I have said consistently is that it is harder than most people
think, and that was quite well demonstrated by the suggested technique
for using weak references: it didn't work. The ultimate demonstration
that a technique works is in benchmarks. If this is as easy to do as Myers
keeps saying, he ought to be able to point to some benchmarks to show
that it works. The fact that he instead resorts to smoke and
mirrors clearly demonstrates the lack of engineering foundation
in his statements.
> The use of weak references for library optimization (the subject under
> discussion here) not only _works_, it is a proven technique in routine
> use in the best-quality libraries. A library supplier who doesn't
> understand the use of weak references in library optimization is
> likely not to understand other proven optimization techniques.
<sigh>.
The use of weak references to avoid code bloat from unused virtual
functions (the actual subject under discussion here) has not been
demonstrated to work. That's probably because weak references alone
are not sufficient.
Once again: where are the numbers to support these claims?
--
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: James Kuyper <kuyper@wizard.net>
Date: 1998/07/09 Raw View
Pete Becker wrote:
>
> Nathan Myers wrote:
> >
> > Pete Becker <petebecker@acm.org> wrote:
> > >Note, also, that the folks who recommended weak references as a
> > >solution here quickly realized that their proposed solutions did not
> > >work.
> >
> > This is a false and misleading statement.
>
> No, it is an absolutely accurate statement about the discussions that
> have taken place here.
Some people have recommended the use of weak references, and you have
argued that this solution would not work. However, not all of the
original proposers have publicly stated that they found your arguments
convincing. To say "they ... realized" in the absence of such public
statements requires either private communications or mind-reading.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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/04 Raw View
Pete Becker <petebecker@acm.org> wrote:
>Note, also, that the folks who recommended weak references as a
>solution here quickly realized that their proposed solutions did not
>work.
This is a false and misleading statement.
The "proposed solution" referred to was a way to implement removing
unused virtual functions without a linker (or pre-linker) extension.
That was when Pete was arguing that such an optimization was too
difficult to implement at all, instead of just complaining that nobody
had quoted numbers to show it does anybody any good.
The use of weak references for library optimization (the subject under
discussion here) not only _works_, it is a proven technique in routine
use in the best-quality libraries. A library supplier who doesn't
understand the use of weak references in library optimization is
likely not to understand other proven optimization techniques.
--
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/07/06 Raw View
Dominic North <Dominic.North@ping.be> wrote in article <VA.0000055e.87b651c9@dominic-viglen>...
> 1) In general, the creation of factions and dialects of C++ is a bad
> thing, having only just achieved a standard.
I agree, believe it or not.
> 2) If current compilers do not do the optimisations which would allow
> some facilities to adhere to the principal of only paying for what you
> use, then pressure should be put on compiler makers to rectify the
> situation, rather than remove the facilities.
I can attest from personal experience that the pressure is very much
there, both on library and compiler vendors.
> 3) An initiative like EC++ may distract the compiler makers from
> improving their standard C++ compilers. On the other hand, it might
> actually encourage them. After all, it might be easier to improve an
> existing compiler and compete with EC++, rather than create a new one for
> EC++ itself. This might not be good for EC++, but it would be good for
> the users of all variants of C++, including those developing for embedded
> systems. If this were to be the result of EC++, then it would have been a
> good thing, even if it did not survive itself.
Or a compiler vendor can improve an existing compiler to the point where
it supports EC++ for now, as a stepping stone toward full C++ support
eventually. This is the commonest scenario I've seen so far. Is this a
``distraction'' or ``encouragement''? Depends on your fears, I suppose.
> 4) Is a new compiler standard really necessary, or would an STL-like ESTL be a
> better solution? (I know IO streams are not strictly STL, but you know what I
> mean)
It sounds like you're arguing for a widely available alternative library that
lacks the cachet of being a formal ISO standard. That's effectively the
role of the various STL implementations kicking about today, though they
are nowhere near full libraries. If so, then that's *exactly* the role
envisioned for EC++. (BTW, Dinkumware uses the term ESTL to refer to
our standard-conforming implementation of STL as it is modified to work
properly atop our EC++ library.) Nobody I know wants to make EC++ an
ISO standard.
> 5) However, if, in the short term, a variant of C++ really, really is the
> only way of achieving the space efficiency required for some embedded
> systems, then it is not for me to condemn it. Like many, I have my doubts
> whether it is necessary, but I don't think acrimonious debate is very
> helpful, and would rather let the EC++ people get on with it. Time, and
> standard C++ compiler development, will tell whether EC++ becomes an
> important development, or a minor sideline.
I absolutely agree, and I appreciate your ecumenical attitude.
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: Jerry Leichter <leichter@smarts.com>
Date: 1998/07/06 Raw View
| > 2) If current compilers do not do the optimisations which would
| > allow some facilities to adhere to the principal of only paying for
| > what you use, then pressure should be put on compiler makers to
| > rectify the situation, rather than remove the facilities.
|
| I can attest from personal experience that the pressure is very much
| there, both on library and compiler vendors.
There is also the pressure of reality.
Optimization is expensive. For as long as I've been in this business (I
hate to think about how long that is ... let's just say that many of the
posters to this group were undoubtedly not yet born when I wrote my
first programs) we've been promised that machines would soon be so fast
that even the most powerful optimizations would be practical. It hasn't
quite worked out that way....
We build and maintain a moderately large C++ system here. It's compiled
and runs on a number of platforms. We're running into a severe problem
on one platform. (It happens to be AIX, but the problem is a matter of
degree - this note is *not* to be taken as a criticism of AIX or the xlC
compiler.) When compiled without optimization, a complete build takes
us something on the order of 6 hours. This makes it our second-fastest
build platform.
With the lowest supported level of optimization, building *one*
subsystem - not the largest - took over 18 hours (and the resulting code
fails some tests that it passes in other configurations - which may very
well be our bug, not the compiler's!). We have yet to succeed in
building our entire system - our best estimate is that it will take over
3 days. There's no way we can work with a build cycle anywhere near
that long; we'll probably have to ship code compiled without optimiza-
tion.
The code at hand is large but not immense (~175K lines, including
comments, in about 180 files, in this subsystem), and makes moderately
heavy use of templates. At the moment, I have no idea what about the
code makes it so expensive to optimize. In practice, just how much am I
willing to modify code to keep the optimizer happy? Not a whole load -
since I've got at least 3 other platforms/compilers to worry about, and
it's all too likely that changes made for the benefit of one compiler
will just make things worse for another.
This situation is getting worse, not better. Newer computer architec-
tures are making it more and more important to do aggressive optimiza-
tion if you want decent performance. From all indications, Merced will
be another big step in that direction. The additional optimization
costs typically outweigh - often far outweigh - the speedup you get from
running the compiler on the new chips. It's quite true that the
ultimate compiled program will run thousands of times for each compiler
run, so the amortized cost may be worth it - but a development build may
only live through a couple of days of testing, and may not come close to
making up the cost. (Yes, I know, we can test unoptimized code and ship
optimized code. Anyone who's tried this will tell you want a dreadful
idea it is: Optimizers have bugs - more and more, and subtler and
subtler, bugs as optimizers get larger and more sophisticated. Code has
bugs that only show up in optimized code. [Hint to compiler writers: A
compilation mode that specifically looks for things that might break
when optimized - even if it takes significant analysis to find them -
might be a big win.] You *have* to test what you ship!)
I don't know what the solution is, but closing our collective eyes to
the problem and adding more and more work for the compiler on the theory
that somehow, magically, all those super-linear algorithms will run fast
enough isn't doing anyone any good.
-- Jerry
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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/06 Raw View
Mike Davies <mike_davies@noco.demon.co.uk> wrote:
>> The current status of this discussion AFAI have been able to discern
>> is that the *language* does not require any overhead for iostreams,
>> but that specific implementations (particularly those that don't use
>> weak references as an efficiency aid) do currently have overheads.
P.J. Plauger wrote:
> No, nothing particular about weak references. You can have a nice
> strong reference to cout and still drag in all sorts of goodies --
> given available technology -- that you don't want. You can avoid
> loading most unused virtuals -- and I do, by the way -- and still drag
> in stuff that you don't want.
>
> Two or three techniques have been suggested for mitigating the
> problems
> that occur when the requirements of the C++ Standard interact with
> current technology. None are standardized or at all widespread, AFAIK.
> Bringing all of them to bear still leaves much to be desired.
>
> This is not a simple issue. Making simplistic statements about it will
> not increase understanding.
One thing that hasn't been mentioned in this thread so far is that
the move towards shared libraried (or DLLs, whatever) reduces *some*
of the problems (but my no means all) mentioned about code bloat.
At least this is true for multitasking systems where multiple
simultaneously executing programs drag in the same shared library,
such as the standard C/C++ library functions. (You're more likely
to see code sharing of this fashion on multiuser Unix systems than
on single-user Windows boxes.)
What shared libraries don't solve in this regards, though, is that
a given program still requires the overhead of symbol resolution
at load (run) time. If the compiler generates references to lots
of extraneous symbols that your code didn't explicitly ask for,
you still pay the price by enduring slow load times.
There's also the issue of getting unwanted initializers and
constructors that execute before ::main() gets called. This also
slows down execution at load time.
So even though shared libraries can reduce disk and virtual memory
requirements, they still can't solve all the overhead problems of
sloppy library implementations.
-- 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: David R Tribble <david.tribble@noSPAM.central.beasys.com>
Date: 1998/07/07 Raw View
Jerry Leichter wrote:
> ...
> Optimization is expensive. ...
> We build and maintain a moderately large C++ system here. It's
> compiled and runs on a number of platforms. ...
> When compiled without optimization, a complete build takes
> us something on the order of 6 hours. This makes it our
> second-fastest build platform.
>
> With the lowest supported level of optimization, building *one*
> subsystem - not the largest - took over 18 hours (and the resulting
> code fails some tests that it passes in other configurations - which
> may very well be our bug, not the compiler's!). We have yet to
> succeed in building our entire system - our best estimate is that it
> will take over 3 days. There's no way we can work with a build cycle
> anywhere near that long; we'll probably have to ship code compiled
> without optimiza-tion.
>
> The code at hand is large but not immense (~175K lines, including
> comments, in about 180 files, in this subsystem), and makes moderately
> heavy use of templates.
Geez, you must have rather complicated code. By way of comparison,
we have about 500,000 lines of C++ code in about 1,500 files that
compiles on five machines (including AIX), and our builds take less
than an hour. Granted, we use very little template code, but even
so, your code shouldn't be taking so long to compile.
Here's a few thoughts off the top of my head that might help your
code compile faster.
1. Perhaps you are including too many header files in your code?
This would make the compiler's symbol table quite large, and
unnecessarily so; most symbols in the header files aren't needed most
of the time. My suggestion is to make sure you only include what you
need, and try not including some headers at all. (I've seen projects
where every source file included 90% of all the header files, when
they only needed two or three.) For example, if you need a struct
'Foo' declared but you're only using pointers and references to it,
try declaring only the class:
class Foo; //#include "foo.h"
It's much, much cheaper than including the whole header file.
(This made a big difference in our compile times, for the simple
reasons that the compiler performed less I/O and used a smaller
symbol table during compilation.)
2. Maybe you're doing too much inlining in the header files?
Remember, the compiler has to keep track of all that during the
code generation phase. All of which makes it use more memory, which
leads to more virtual memory use, which leads to disk thrashing...
You'll probably find (after profiling) that 80% of your inlining
doesn't affect performance, for the simple reason that 80% of the
time, your program is executing only 20% of your code. The rule
of thumb about inlining is "Don't do it unless you really need it".
3. Perhaps your functions are too big? Block optimization usually
requires multiple passes over the entire function block, which can
take time and eat up lots of memory. You can also add local
blocks to your code, moving local variables into them, so that
the compiler has a better idea of when a variable is really needed
and when it's no longer used.
4. At lastly, perhaps you're asking for too much optimization?
Maybe your compiler optimization switch has levels to choose from,
so try setting the optimization down a notch or two.
-- 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: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/07/07 Raw View
Josh Stern<jstern@citilink.com> wrote:
>There is a very good book devoted to the topic of how to structure
>a large C++ code base in order to achieve fast compilation,
>good maintainability, readability, testability, etc.
>
>John Lakos, _Large-Scale C++ Software Design_.
> Addison-Wesley, 1996. ISBN 0-201-63362-0
>
>The book is somewhat dry reading, but chock full of
>recommendable content related to its title.
The book contains a great deal of good advice, mixed with a
substantial amount of very bad advice. Most of the bad advice
seemed to be in the first couple of chapters.
--
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/02 Raw View
In article <359ABF69.794B@wizard.net>,
James Kuyper <kuyper@wizard.net> wrote:
>
> jkanze@otelo.ibmmail.com wrote:
> >
> > In article <359A5F30.167E@wizard.net>,
> > James Kuyper <kuyper@wizard.net> wrote:
> > >
> > > jkanze@otelo.ibmmail.com wrote:
> > > >
> > > > In article <3597F820.3C89@noSPAM.central.beasys.com>,
> > > > dtribble@noSPAM.technologist.com wrote:
> > > >
> > > > > And then there's the problem with getting too much of what you
> > > > > didn't ask for (such as locale facets in iostreams).
> > > >
> > > > Who didn't ask for it? While I share Plauger's concern about untested
> > >
> > > Locales serve a very real need of a lot of people; there are also a lot
> > > of people who don't share that need, and would prefer not to be saddled
> > > with the burdens imposed to meet that need.
> >
> > So what is the burden? As a programmer, you don't see them unless you
> > want to; everything happens behind your back, so to speak. About the
> > only thing you might notice is that your linked program is larger, but
> > on most platforms, you don't care -- what's another couple of 100KB,
> > when it's all virtual memory anyway.
>
> Not all C++ users can afford to treat 100KB as a negligible amount of
> memory. Not all systems that C++ can be implemented on use virtual
> memory.
That's why we've got EC++:-).
Seriously, where I work, it's hard to imagine a program not concerned
with locales. Even some of the embedded processors are concerned.
--
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/03 Raw View
In article <6ne650$5pr$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com
writes
...snip...
>> Locales serve a very real need of a lot of people; there are also a lot
>> of people who don't share that need, and would prefer not to be saddled
>> with the burdens imposed to meet that need.
>
>So what is the burden? As a programmer, you don't see them unless you
>want to; everything happens behind your back, so to speak. About the
>only thing you might notice is that your linked program is larger, but
>on most platforms, you don't care -- what's another couple of 100KB,
>when it's all virtual memory anyway.
This thread has centered on resource (ie memory ) constrained systems.
The main thrust of the discussion has been whether *any* memory overhead
(let alone 100k) is *required* by the C++ *language* (as opposed to
particular implementations).
The current status of this discussion AFAI have been able to discern is
that the *language* does not require any overhead for iostreams, but
that specific implementations (particularly those that don't use weak
references as an efficiency aid) do currently have overheads.
...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: James Kuyper <kuyper@wizard.net>
Date: 1998/07/03 Raw View
jkanze@otelo.ibmmail.com wrote:
...
> Seriously, where I work, it's hard to imagine a program not concerned
> with locales. Even some of the embedded processors are concerned.
You work in France, I work in the US. A product marketed in the US using
only the "C" locale and only American English could sell more copies
than would be true for any other single language/locale combination.
People here can get away with ignoring locales. None of my paid work has
ever required their use.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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/03 Raw View
In article <359BF6B7.2781@wizard.net>,
James Kuyper <kuyper@wizard.net> wrote:
>
> jkanze@otelo.ibmmail.com wrote:
> ...
> > Seriously, where I work, it's hard to imagine a program not concerned
> > with locales. Even some of the embedded processors are concerned.
>
> You work in France, I work in the US. A product marketed in the US using
> only the "C" locale and only American English could sell more copies
> than would be true for any other single language/locale combination.
> People here can get away with ignoring locales. None of my paid work has
> ever required their use.
(Where I currently work is actually Germany:-). Where I live is France.)
That was exactly my point. Even if the program in question will not
be deployed outside of a single country, it will likely have to deal
with files from other countries, etc.
Of course, while the English language market is significantly bigger
than any other single market, adding internationalization opens the
doors to many other markets, not just one. And the total non-English
speaking markets are together significantly larger than the English
speaking one. So you may still be cutting yourself off from more than
half your potential market. (I say may, since it depends on the product.
If I write a program to calculate French tax returns, I will not bother
making it available in anything but French.)
Not all American firms have this attitude; both Solaris and AIX change
languages at the drop of an enviroment variable, for example, and under
Windows NT, I can even have a different keyboard configuration for
each window (a feature which I regularly 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=E9e 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: Pete Becker <petebecker@acm.org>
Date: 1998/07/03 Raw View
Mike Davies wrote:
>
> The current status of this discussion AFAI have been able to discern is
> that the *language* does not require any overhead for iostreams, but
> that specific implementations (particularly those that don't use weak
> references as an efficiency aid) do currently have overheads.
This is a bit of an exaggeration: newcomers to this thread might not
understand that "specific implementations" here means "all
implementations". Nobody has yet given any figures to show actual
compilation of the full C++ library without code bloat from locales.
Note, also, that the folks who recommended weak references as a
solution here quickly realized that their proposed solutions did not
work.
--
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
Mike Davies <mike_davies@noco.demon.co.uk> wrote in article <mOYY3OAGw8m1EwYW@noco.demon.co.uk>...
> This thread has centered on resource (ie memory ) constrained systems.
> The main thrust of the discussion has been whether *any* memory overhead
> (let alone 100k) is *required* by the C++ *language* (as opposed to
> particular implementations).
I agree that the C++ Standard permits an implementation to translate
a C++ compiler to a 20-byte executable. It's a good thing that it doesn't
*require* that level of optimization, however. This is semantic hairsplitting.
The C++ Standard does require certain behavior. It is clearly written with
available (and potential) technology in mind. The discussion has been
about how the requirements of the C++ Standard interact with that
available (and potential) technology. Pragmatists focus on the available,
optimists on the potential.
> The current status of this discussion AFAI have been able to discern is
> that the *language* does not require any overhead for iostreams, but
> that specific implementations (particularly those that don't use weak
> references as an efficiency aid) do currently have overheads.
No, nothing particular about weak references. You can have a nice strong
reference to cout and still drag in all sorts of goodies -- given available
technology -- that you don't want. You can avoid loading most unused
virtuals -- and I do, by the way -- and still drag in stuff that you don't
want.
Two or three techniques have been suggested for mitigating the problems
that occur when the requirements of the C++ Standard interact with
current technology. None are standardized or at all widespread, AFAIK.
Bringing all of them to bear still leaves much to be desired.
This is not a simple issue. Making simplistic statements about it will
not increase understanding.
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/03 Raw View
In article <mOYY3OAGw8m1EwYW@noco.demon.co.uk>,
Mike Davies <mike_davies@noco.demon.co.uk> wrote:
> This thread has centered on resource (ie memory ) constrained systems.
> The main thrust of the discussion has been whether *any* memory overhead
> (let alone 100k) is *required* by the C++ *language* (as opposed to
> particular implementations).
>
> The current status of this discussion AFAI have been able to discern is
> that the *language* does not require any overhead for iostreams, but
> that specific implementations (particularly those that don't use weak
> references as an efficiency aid) do currently have overheads.
The current status is a bit more complex than that. One one hand, you
have people claiming that implementing the standard does result in
extra overhead; at least one of those people has actually implemented
it, and has been unable to avoid extra overhead. On the other side,
you have people claiming that any extra overhead is due to sloppiness
on the part of the compiler writers, and can be avoided. When specific
cases are cited where the extra overhead occurs, of course, there are
either no suggests as to how a compiler can avoid it, or the suggestions
don't work, or only cover a few cases.
There is, of course, no proof that eliminating the extra overhead is
impossible. Still, I tend to be a sceptic. Theoretically, optimization
can result in faster programs than well tuned, hand written assembler.
I've yet to see it. While I sort of suspect that eliminating the extra
space overhead may actually be slightly simpler, the techniques are NOT
widespread, or even known, today, and there is much less motivation to
persue them, since the extra memory is not an issue on the machines where
the money is.
Assuming that someone today invented a technique which would magically
eliminate all of the extra space overhead. How long do you think it will
be before this technique is available in production compilers for the small
machines, considering that the market is small (thus, little money to
finance the implementation) and that while techniques permitting compiled
code to have the same speed, or greater, than hand crafted assembler have
been known for 10 or 15 years, they are still not available in most
production compilers.
--
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/01 Raw View
David R Tribble wrote:
>
> 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.
>
> J. Kanze wrote:
...
> alleged complexity of PL/1 in the 60s and 70s. I've asked this
> before, but does any one single mortal comprehend the entire
> C++ standard?
I think Stroustrup does, but perhaps he doesn't count as a mortal.
More seriously, I've been watching this newsgroup for two years, and
reading relevant sections of the draft standard. In the course of that,
I've learned a lot. I think that most competent compiler designers could
learn to comprehend the whole thing in a reasonable amount of time.
Actually having to write code implementing the standard would help, 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: James Kuyper <kuyper@wizard.net>
Date: 1998/07/01 Raw View
jkanze@otelo.ibmmail.com wrote:
>
> In article <3597F820.3C89@noSPAM.central.beasys.com>,
> dtribble@noSPAM.technologist.com wrote:
>
> > And then there's the problem with getting too much of what you
> > didn't ask for (such as locale facets in iostreams).
>
> Who didn't ask for it? While I share Plauger's concern about untested
Locales serve a very real need of a lot of people; there are also a lot
of people who don't share that need, and would prefer not to be saddled
with the burdens imposed to meet that 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: jkanze@otelo.ibmmail.com
Date: 1998/07/01 Raw View
In article <359A5F30.167E@wizard.net>,
James Kuyper <kuyper@wizard.net> wrote:
>
> jkanze@otelo.ibmmail.com wrote:
> >
> > In article <3597F820.3C89@noSPAM.central.beasys.com>,
> > dtribble@noSPAM.technologist.com wrote:
> >
> > > And then there's the problem with getting too much of what you
> > > didn't ask for (such as locale facets in iostreams).
> >
> > Who didn't ask for it? While I share Plauger's concern about untested
>
> Locales serve a very real need of a lot of people; there are also a lot
> of people who don't share that need, and would prefer not to be saddled
> with the burdens imposed to meet that need.
So what is the burden? As a programmer, you don't see them unless you
want to; everything happens behind your back, so to speak. About the
only thing you might notice is that your linked program is larger, but
on most platforms, you don't care -- what's another couple of 100KB,
when it's all virtual memory anyway.
And the nice thing is; you have them, even though you don't need them.
So when your boss comes to you saying that you now have to deliver to
France, the internationalization effort is already halfway done.
--
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: James Kuyper <kuyper@wizard.net>
Date: 1998/07/02 Raw View
jkanze@otelo.ibmmail.com wrote:
>
> In article <359A5F30.167E@wizard.net>,
> James Kuyper <kuyper@wizard.net> wrote:
> >
> > jkanze@otelo.ibmmail.com wrote:
> > >
> > > In article <3597F820.3C89@noSPAM.central.beasys.com>,
> > > dtribble@noSPAM.technologist.com wrote:
> > >
> > > > And then there's the problem with getting too much of what you
> > > > didn't ask for (such as locale facets in iostreams).
> > >
> > > Who didn't ask for it? While I share Plauger's concern about untested
> >
> > Locales serve a very real need of a lot of people; there are also a lot
> > of people who don't share that need, and would prefer not to be saddled
> > with the burdens imposed to meet that need.
>
> So what is the burden? As a programmer, you don't see them unless you
> want to; everything happens behind your back, so to speak. About the
> only thing you might notice is that your linked program is larger, but
> on most platforms, you don't care -- what's another couple of 100KB,
> when it's all virtual memory anyway.
Not all C++ users can afford to treat 100KB as a negligible amount of
memory. Not all systems that C++ can be implemented on use virtual
memory.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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/06/30 Raw View
David R Tribble:
> I've asked this before, but does any one single mortal comprehend
> the entire C++ standard?
Yes, more than one. But not I ;->
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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 Chase <chase@naturalbridge.com>
Date: 1998/06/30 Raw View
David R Tribble wrote:
> When I compare C++ to PL/1, I mean that C++ has become such a huge
> language (and library) that it seems fair to compare it to the
> alleged complexity of PL/1 in the 60s and 70s.
I'm not at all sure this is fair to PL/1. I've written many
lines of code in PL/1, and read the entire IBM language spec,
and in many ways it was a much more tractable language than
C++. It had its set of weird quirks, but C++ has an entire
quirk-generation facility (think operator overloading, think
copy-constructor invocation, think templates).
(I've also written many lines of code in C++, and worked on
a couple of C++-processing systems.)
> Hopefully C++ will have a better fate than PL/1.
Quicker oblivion?
> And I would
> hope that we as language designers have learned some lessons from
> the mistakes of the past.
I don't think that the C++ designers have (what's this "we" stuff?
I sure as hell didn't design template syntax, nor would I ignore
Tom Pennello's advice on alternatives to that syntax.)
David Chase
NaturalBridge LLC
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: lruss@superlink.net
Date: 1998/07/01 Raw View
David R Tribble wrote:
> [snip]
> >|> David R Tribble <david.tribble@noSPAM.central.beasys.com> wrote:
> >|> > C++, the PL/1 of the 90s.
> [snip]
> When I compare C++ to PL/1, I mean that C++ has become such a huge
> language (and library) that it seems fair to compare it to the
> alleged complexity of PL/1 in the 60s and 70s. I've asked this
> before, but does any one single mortal comprehend the entire
> C++ standard?
PL/1 is full of surprises. But couldn't you also ask this same question
about much 'simpler' languages, like FORTRAN or COBOL. There are a
number of nasty complications (and portablility issues) in these too.
I hate to say it, but complexity is just a part of life. As programmers
(or engineers) we have to deal with complexity issues all the time. And
complexity can not be done away with. I think that complexity is
conserved. You can hide it someplace else. In the compiler. In a
function. In a class. But I don't think that you can really do away with
it. I don't think that the question is: 'Is the language I am using
complex?' because *all* programming languages have some complexity
either in definition or in use. I think that the question should be,
'Does the language I am using help me deal with the complexity in my
problem domain and in the end allow *most* of my code to be less
complex?'.
In my opinion, PL/1 added much complexity for little gain. Much of PL/1
simply allowed the users of FORTRAN and COBOL to use one language if
they wanted to. And of course, they mostly didn't want to.
> I also am comparing the promises made about the power and
> flexibility that C++ will give to the programmer to the same
> promises made about PL/1.
No I don't think that the promise is the same. It's not simply the
addition of complexity that is the issue here. It's what you can do
with the complexity that was added. PL/1 didn't really add very much
that couldn't be done in a mixed language environment. C++ allows you
to more easily change how you program, by adding classes. I happen to
think that the language features are alot more accessable in C++. A
show of hands please, how many PL/1 programmers made extensive use of
the PL/1 preprocessor? Not many I bet. And how many C++ programmers are
using templates? (Almost) all of us, one way or another.
> Hopefully C++ will have a better fate than PL/1.
I hope so too. There are a coupla things I'd like to see added to the
standard, but that's another discussion.
> And I would hope that we as language designers have learned some > lessons from the mistakes of the past. (Remember Algol? Pascal? > Ada?)
There are still people using these. And I'm not sure that they are
failures. That may depend on how you define your design goals.
> [snip]
> -- David R. Tribble, dtribble@technologist.com --
> C++, the PL/1 of the 90s.
>
Thanks for provoking some thought.
LR.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use 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 <3597F820.3C89@noSPAM.central.beasys.com>,
dtribble@noSPAM.technologist.com wrote:
> And then there's the problem with getting too much of what you
> didn't ask for (such as locale facets in iostreams).
Who didn't ask for it? While I share Plauger's concern about untested
technology, and I'd have rather seen the standard available earlier,
with a few less features, putting facets in iostreams is an answer (or
at the very least, an attempt at an answer) to a very real problem:
files from different sources may be in different locales. The problem
has become particularly accute since the opening up of eastern Europe,
since we are now doing significant business with countries which do not
even use the same code set for 8 bit files.
Whether the solution adopted is the best, or whether it even belonged
in this version of the standard, is an unanswered question. That they
respond to a very real need, on the other hand, is without question.
--
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: David R Tribble <david.tribble@noSPAM.central.beasys.com>
Date: 1998/06/29 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.
J. Kanze wrote:
> Which is, I think, irrelevant to his point.
Thank you.
When I compare C++ to PL/1, I mean that C++ has become such a huge
language (and library) that it seems fair to compare it to the
alleged complexity of PL/1 in the 60s and 70s. I've asked this
before, but does any one single mortal comprehend the entire
C++ standard?
I also am comparing the promises made about the power and
flexibility that C++ will give to the programmer to the same
promises made about PL/1.
Hopefully C++ will have a better fate than PL/1. And I would
hope that we as language designers have learned some lessons from
the mistakes of the past. (Remember Algol? Pascal? Ada?)
> 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.
PL/1 had recognized subsets, so that a shop could "disable" certain
features (such as exceptions - yes, PL/1 had them) if it didn't
want or need the extra baggage; apparently, the language could
be implemented in discrete pieces. C++ has no such thing as subsets
(although EC++ is trying hard to be one), and has no way to
"disable" unwanted features. Some vendors have compiler switches
to turn off code generation for exceptions and RTTI, but I'll bet
that you can't choose to omit these features from their libraries.
And then there's the problem with getting too much of what you
didn't ask for (such as locale facets in iostreams).
-- 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 ]