This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: <iostream> now part of the libstdc++ binary
- From: Joe Buck <Joe dot Buck at synopsys dot COM>
- To: Howard Hinnant <hhinnant at apple dot com>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Fri, 17 Nov 2006 09:22:46 -0800
- Subject: Re: <iostream> now part of the libstdc++ binary
- References: <C5AA7BE8-B54D-46DF-9E3D-A41FBB0D1532@apple.com>
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?