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. With best wishes, Anton Pevtsov -----Original Message----- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, May 19, 2006 02:04 To: [email protected] 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
