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]

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


Jerry, I'm just going to assume you read this list.

I think the end goal should be to have something like this work:

#include <ostream>
 
using namespace std;
 
class bufferstream : public ostream
{
  // Types.
  typedef char                          char_type;
  typedef __locale_cache<char_type>     cache_type;
 
  // Data.
  //cache_type  data;
 
public:
 
  bufferstream() : ostream()
  {
    // Zero alloc.
    //this->init(NULL, &data);
    this->init(NULL);
  }
};

However, the problem is more than allocating the __locale_cache, it's
what is inside of the __locale_cache.

Fixing that problem is what I thought you were up to.... however, no
worries. Now that the gcc-3.3 deadline is looming, let's try to get this
wrapped up.

>Oops.  The following patch moves the hook to pass the static cache to
>the stream constructors.  It passes make check-abi, but is it actually
>safe?

Additional non-virtual functions and be appropriately versioned.

>Umm, ICK!  Actually, there is another leak waiting to happen here,
>unrelated to locale cache.  The above leak happens because the
>destructors are never called for the static streams.  If someone
>happens to store a new'd object in e.g. cout.pword(10) and register a
>callback to clean up the storage, this will never get cleaned up.
>
>This scenario makes me think that we MUST call the standard stream
>destructors.

No. See libstdc++/10132 for more info on why this is not possible.

-benjamin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]