Re: Unifying the GCC Debugging Interface

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

I forgot to add this important information: you don't get the nifty
counters if you don't include <iostream>.  Specifically.
That means including <istream> or <ostream> does not
introduce any nifty counter. Including <ssteam>, which
allows you to perform in-memory formatted IO, does not
introduce any nifty counter.  Said, differently, the worry
about IOStreams introducing unnecessary "static
constructor" is either overblown or misplaced, or both.

-- Gaby

On Wed, Nov 21, 2012 at 8:25 AM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> On Wed, Nov 21, 2012 at 7:48 AM, Tobias Grosser <tobias@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