On Mon, Aug 15, 2011 at 7:48 PM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote:
> On 16 August 2011 00:43, Jonathan Wakely wrote:
>> On 16 August 2011 00:30, Jeffrey Walton wrote:
>>> Hi All,
>>>
>>> I'm testing a custom allocator. The allocator works well with vector,
>>> but fails to link with basic_string (see below).
>>>
>>> I looked through Stroustrup and could not find info on _Alloc_hider.
>>
>> It starts with an underscore followed by an upper case letter, so it's
>> in the implementation namespace i.e. it's an implementation detail, so
>> you're not going to find it in a book.
I thought it might have been a GCC extension that might have leaked to
the surface. It happens on occasion, especially with less frequently
used stuff.
>>
>>> Searching online doesn't reveal much either (perhaps I have not waded
>>> through enough irrelevant fodder). I did find [1], buts its just
>>> DoOxygen with no real content (its written in STL terseness with no
>>> comments).
>>>
>>> I believe I need another constructor, but I'm not sure what it takes
>>> or how to write it:
>>>
>>> inline explicit zallocator() { }
>>> inline ~zallocator() { }
>>> inline explicit zallocator(zallocator const&) { }
>>>
>>> template<typename U>
>>> inline explicit zallocator(zallocator<U> const&) { }
>>>
>>> How does one one provided an allocator for use by a basic_string?
>>
>> By writing a type that meets the C++03 Allocator requirements, which
>> yours doesn't.
For what its worth, I did not spicy -std=XXX.
> Hmm, I might have been too hasty - that constructor might be allowed
> to be 'explicit' which would make it a bug that we don't support
> allocators like yours - I'll have to investigate tomorrow.
>
> Removing 'explicit' should still fix the problem anyway.
You were right about the explicit:
template<typename U>
inline zallocator(zallocator<U> const&) { }
As always, thanks for the help.
Jeff
