On 16 August 2011 00:48, 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.
>>
>>
>>> 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.
>
> 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.
>
Actually, in this case there's no conversion from zallocator<U> to
zallocator<T>, it's just using the copy constructor:
inline explicit zallocator(zallocator const&) { }
Why have you made that explicit?
That's definitely a problem, it means your type isn't implicitly
CopyConstructible, so can't be passed by value.
