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:[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
