This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Hello
- To: libstdc++ at gcc dot gnu dot org
- Subject: Re: Hello
- From: Martin Sebor <sebor at roguewave dot com>
- Date: Thu, 10 May 2001 14:38:08 -0600
- Organization: Rogue Wave Software, Inc.
- References: <20010509052826.A17915@alinoe.com>
Carlo Wood wrote:
>
> Did anyone see my last (and first) post on this list? :)
> Just wondering, because I've seen no reaction so far
> and I'd really like to know what is the deal with allocator
> objects and stringstreams.
>
> http://gcc.gnu.org/ml/libstdc++/2001-05/msg00027.html
>
> A summary of the Question is:
>
> When I do:
>
> basic_stringstream<char, char_traits<char>, ALLOCATOR> ss;
>
> ss << 123;
>
> Then I expect that ANY allocation is done by calling
> ALLOCATOR::allocate(). But it turns out that (due to
> the allocation of a locale related object) operator new
> is called directly. Isn't that a bug?
I have wondered about this myself when we were reworking our
implementation of string streams, but the standard doesn't say
one way or the other. It seems reasonable to expect that the
allocator argument will be used, otherwise the argument is
redundant in the template declaration and should be instead used
only in the members that take or return string as an argument.
That way the same stream type could be used to generate distinct
specializations of basic_string.
The interface is limited in another way: there is no way to
preserve the state of the allocator, and there is no mechanism
to pass an allocator object to the stream. I.e., a new allocator
object must be created (via a call to the default ctor) every
time it is needed. To get around this limitation, str would
have to take an argument of type Allocator (perhaps with a
default value) so that an existing allocator object could be
passed to it, or the allocator object would have to be stored
in the stream.
Regards
Martin