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 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?


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