[Bug libstdc++/14245] problem with user-defined allocators in std::basic_string

["cbotev at yahoo dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From cbotev at yahoo dot com  2004-02-25 14:01 -------
No. I tend to disagree.

My point is that the copy constructor of basic_string should provide "the most
possible information" to the constructor of the allocator. In the case of the
copy constructor of basic_string, this means invoking the copy constructor of
the allocator and not the default constructor. I don't have the C++ standard
handy:  does it require a copy constructor for the allocators?

Let me give you an example. The project I work on uses memory pools. We have
allocators that provide an interface for the STL objects to a memory pool. To be
properly initialized, these allocators need to get a pointer to a memory pool.
Therefore, we cannot possibly initialize the allocator using the default
constructor. On the other hand, if the copy constructor of the allocator is
invoked, it can use the memory pool associated with the other allocator.

I am also not sure what do you mean by using _M_refcopy instead of _M_clone. Do
you mean changing _M_grab()? If yes, this is not correct. _M_grab() is also used
by the assignment operator and the latter needs the _M_clone() functionality. If
you mean using _M_refcopy() in the copy constructor of basic_string (instead of
_M_grab()), I also think this may be incorrect. You don't know what the
constructor of the allocator does (whether the default or the copy constructor).
For example, in the case of memory pools, it may decide to create/use another
memory pool. In this case, the string should be cloned and not copied.

In any case, if the C++ standard requires the implementation of a copy
constructor for allocators, then I think it should be used in the copy
constructor of basic_string. Then, the implementation of the == operator for
allocators will determine, whether _M_refcopy() or _M_clone() will be used in
_M_grab(). If the copy constructor for allocators is not required, I guess I
have to live with my current workaround: subclassing basic_string and
implementing the copy constructor using the assignment operator instead of the
copy constructor of basic_string. Presumably, it is less efficient but it does
the job.

Cheers,
Chavdar

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14245