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