Jeffrey Walton noloader@gmail.com
Tue Aug 16 00:13:00 GMT 2011

On Mon, Aug 15, 2011 at 7:48 PM, Jonathan Wakely <jwakely.gcc@gmail.com> 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.


More information about the Gcc-help mailing list