stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: test for lib.string.swap
Date Thu, 18 May 2006 22:03:57 GMT
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>
     std::allocator<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).

Martin

Mime
View raw message