Re: zero-alloc cache (was Re: [v3] Fix PR libstdc++/10276)

[Carlo Wood <carlo at alinoe dot com>]

On Fri, Apr 18, 2003 at 12:29:32AM -0400, Jerry Quinn wrote:
> Hi, Carlo.  I took BenK's patch and fleshed it out some.  This is the
> potential patch for 3.3.  I'm working up one for mainline as well.
> 
> What do you think?  Does this do the job for 3.3?

Hi again Jerry,

I started testing with your patch now (already (in) CVS)
and there seems to be another problem.

Every class that is derived from 'ostream' somehow WILL
allocate memory - which is what we are trying to avoid no?

For example, I have this class:

class bufferstream_ct : public std::basic_ostream<char, std::char_traits<char> > { ... };

this class should not allocate memory (for the locale stuff),
but what happens is this: basic_ostream only has a single
constructor.  If we look at $PREFIX/include/c++/3.3/ostream
we see only:

      explicit
      basic_ostream(__streambuf_type* __sb)
      { this->init(__sb); }

therefore, it is garanteed that this will call
std::basic_ios<char, std::char_traits<char> >::init(__sb, 0)

by not having the possibility to pass a cache, nothing has
changed and std::basic_ios will do the two allocations we
are trying to avoid.

The same holds for the standard streams as you can see
for example in the following backtrace:

#1  0x400913be in operator new(unsigned) (size=60) at debugmalloc.cc:3482
#2  0x40109bb3 in std::basic_ios<char, std::char_traits<char> >::_M_cache_locale(std::locale const&, std::__locale_cache<char>*) (this=0x8052908, __loc= at 0x8052970, __cache=0x0) at memory:183
#3  0x401099d1 in std::basic_ios<char, std::char_traits<char> >::init(std::basic_streambuf<char, std::char_traits<char> >*, std::__locale_cache<char>*) (this=0x8052904, __sb=0x40175140, __cache=0x3c) at basic_ios.tcc:152
#4  0x4010b1e5 in std::ios_base::Init::_S_ios_create(bool) (__sync=64) at ostream:106
#5  0x4010b865 in Init (this=0x401759f0) at /usr/src/gcc/gcc-cvs-3.3/libstdc++-v3/src/ios.cc:236
#6  0x4010aed7 in __static_initialization_and_destruction_0 (__initialize_p=1075254032, __priority=65535) at iostream:77

this is simply because in ios_base::Init::_S_ios_create(bool __sync)
in ios.cc, you still do:

new (&cout) ostream(&buf_cout);

which calls the above constructor
and therefore allocates memory for new
locale. 

A bit later you call cout.init:

new (&cout) ostream(&buf_cout);
new (&cin) istream(&buf_cin);
new (&cerr) ostream(&buf_cerr);
new (&clog) ostream(&buf_cerr);
cout.init(&buf_cout, &locale_cache_cout);

but the "harm" is already done.

-- 
Carlo Wood <carlo at alinoe dot com>