This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: <iostream> now part of the libstdc++ binary


On Nov 17, 2006, at 12:22 PM, Joe Buck wrote:

On Fri, Nov 17, 2006 at 11:48:48AM -0500, Howard Hinnant wrote:
Hello,

I was wondering if there was a rationale somewhere for http://
gcc.gnu.org/ml/libstdc++-cvs/2006-q1/msg00049.html .

This patch modifies 4.1 to #include <iostream> into itself.  The
inclusion of <iostream> is unique in libstdc++ sources and prior to
4.1 not done (well, only checked 4.0, not sure about 3.x).
<iostream> is the only C++ header which adds a run time cost just by
its inclusion, by adding a static ios_base::Init object to the
translation unit.  The construction of this static is what
initializes the terminal streams: cin, cout, cerr, clog, wcin, wcout,
wcerr, wclog.  This appears to mean that now every client (which
links to libstdc++) has these streams initialized whether or not they
use them or want them.

iostream-inst.cc will produce a module iostream-inst.o in the library, but
it looks to me that this unit will only be included in a statically linked
executable if some symbol in basic_iostream<char> or
basic_iostream<wchar_t> is referred to.


So I guess you're talking about dynamically linked executables?  Will
minimalists who want to avoid streams even link against libstdc++.so?

Actually I was concerned about both static and dynamic clients. My understanding was that dead-stripping static initialization lists could cause conforming C++ code to break (unless the linker could prove the static code had no side effects). I've seen the bug reports trickle in over the years when over ambitious linkers did this...


-Howard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]