stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Pevtsov" <>
Subject RE: test for lib.string.swap
Date Fri, 19 May 2006 15:08:12 GMT
The updated test version is here:

Now it exercises the swap when strings allocators are different.
Also I made small change to 21.strings.cpp to correct info string

With best wishes,
Anton Pevtsov

-----Original Message-----
From: Martin Sebor [] 
Sent: Friday, May 19, 2006 02:04
Subject: Re: test for lib.string.swap

Anton Pevtsov wrote:
> Here is another question. We use template class Allocator in the 
> tests, and it assumes that code should be valid for std:allocator too.

> But
> SharedAlloc a;
> Allocator<int> z (&a);
> wll not compile when Allocator is std::allocator. Is there any way to 
> use std::allocator and UserAlloc together (at the same time UserAlloc 
> objects should be not equal)?

Yeah, that wouldn't work. There are at least two approaches that I think
should work for us.

The first is to unconditionally construct a SharedAlloc object and set
SharedAlloc::instance() to point to it. That way the default UserAlloc
ctor will pick it up.

     template <..., class Allocator>
     void foo () {
         SharedAlloc a;
         // set a as the new global instance
         SharedAlloc* const save = SharedAlloc::instance (&a);
         Allocator z;   // uses a
         // ...
         // restore the original instance
         SharedAlloc::instance (save);

The second is to write a simple allocator adapter template
that would pass the SharedAlloc object to the UserAlloc ctor but avoid
passing it to Allocator:

     template <class charT>
     make_alloc (SharedAlloc&, std::allocator<charT>*) {
         return std::allocator<charT>();

     template <class charT, class Types>
     UserAlloc<charT, Types>
     make_alloc (SharedAlloc &shal, UserAlloc<charT, Types>*) {
         return UserAlloc<charT, Types>(&shal);

I suspect the second alternative is what we'll need to verify that the
string ctor creates and stores a copy of the allocator object passed to
it rather than storing some other default constructed allocator (since
the two would be indistinguishable).


View raw message