Re: test for lib.string.swap

[Martin Sebor <se...@roguewave.com>]

Anton Pevtsov wrote:
> The updated test version is here:
> http://people.apache.org/~antonp/stdcxx05192006/
> 
> Now it exercises the swap when strings allocators are different.
> Also I made small change to 21.strings.cpp to correct info string
> format.

Have these changes been applied? (Sorry, I'm behind on email...)

Martin

> 
> With best wishes,
> Anton Pevtsov
> 
> 
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com] 
> Sent: Friday, May 19, 2006 02:04
> To: stdcxx-dev@incubator.apache.org
> 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>
>      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
>