On Wed, Nov 21, 2012 at 7:48 AM, Tobias Grosser <tob...@grosser.es> wrote:
> Is it correct to state that every translation unit that includes iostream
> will include the iostream static constructors?
C++ requires the definitions of globals such as std::cin, std::cout,
and std::cerr
that must be contructed (by any magic) before users attempt to use them. To aid
with this, the C++ standard formalizes the programming pattern known as
`nifty counter' in the form of the class std::ios_base::Init such that
(quoting C++)
The class Init describes an object whose construction ensures the
construction of the eight objects declared in <iostream> (27.4)
that associate
file stream buffers with the standard C streams provided for by the
functions declared in <cstdio> (27.9.2).
Whether a compiler decides to implement this with "static constructor" is
an implementation detail issue. Of course, since no object is constructed
more than once, no actual iostream object constructor is run more than
once. You can see how we implemented this in libstdc++
http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/src/c%2B%2B98/ios_init.cc?revision=184997&view=markup
> Will the number of static
> constructors increase linearly with the number of translation units? Is it
> necessary to include iostream in a core header, in case we want to use
> iostream for the debugging functionality?
I think this is the case or premature optimization and you are worrying
about the wrong thing. Every translation unit that includes <iostream>
gets a static global variable of an empty class type (therefore occupying
1 byte). See
http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/std/iostream?revision=184997&view=markup
That 1 byte triggers a *dynamic* intialization from the corresponding
translation unit. However, the actual iostream objects are constructed
only once.
>
>
>> e of it. Only the translation that includes
>> iostream gets the niftty counters.
>>
>> Furthermore, not including iostream does not mean you don't
>> get static constructors -- GCC has lot of global variables and if
>> any of them incures dynamic initialization, you get
>> dynamic initialization. Note also that if you explicitly delay
>> initialization to runtime, you are going to pay for it anyway
>> through brittle manual initialization.
>
>
> I was mainly interested in compering FILE* and iostream. To my knowledge the
> FILE* interface does not have any significant construction overhead.
You are kidding me, right?
Anyway, I think you are focusing on the wrong thing.
For GCC's homegrown IO occurs far more overhead than
you appear to believe - I am saying this from my work on the
diagnostic machinery; we can do a better job if we had
a more typed interface. This is true not only for the
diagnostic machinery, which is partly used by the various
debug systems, but also of the debug systems themselves.
You are worrying about something I suspect you would not be able to
measure compared to the performance of the existing
debug systems.
-- Gaby
