[PATCH] Fix PR libstdc++/13462 std::set's pointer is not right

[Matt Austern]

On Dec 22, 2003, at 5:59 PM, Bo Persson wrote:

>
> ----- Original Message -----
> From: "Nathan Myers" <ncm-nospam@cantrip.org>
> To: <libstdc++@gcc.gnu.org>
> Sent: Monday, December 22, 2003 6:24 PM
> Subject: Re: [PATCH] Fix PR libstdc++/13462 std::set's pointer is not 
> right
>
>
>> On Mon, Dec 22, 2003 at 08:19:06AM -0800, Andrew Pinski wrote:
>>> The problem is that std::set's pointer is defined based on
>>> _Rep_type::const_pointer and not _Rep_type::pointer.
>>> This patch fixes that and others in libstdc++.
>>>
>>> ChangeLog:
>>> * include/bits/stl_multiset.h (__gnu_norm::multiset::pointer):
>>> Define based on pointer and not const_pointer.
>>> * include/bits/stl_set.h (__gnu_norm::set::pointer): Likewise.
>>> * include/ext/hash_set (__gnu_ext::hash_set::pointer): Likewise.
>>> (__gnu_ext::hash_multiset::pointer): Likewise.
>>
>> I'm not sure this is right.  The problem is that the elements of a
>> std::set<> are supposed to be immutable.  Exposing a non-const pointer
>> to the elements breaks that property.
>
>
> I think that problem is with iterator/const_iterator. Another issue.
>
> The standard defines pointer and const_pointer, which are then 
> otherwise not
> used by the containers.

It's also all mostly irrelevant.  It only matters if users supply
an allocator where Alloc::pointer is something other than
Alloc::value_type*.  In principle this is allowed by the standard
(sort of).  In practice, if we want to support it we have to do a
fair amount of work.  Changing the container's pointer type is the
least of it.

(I can get into details of what we'd have to do, if anyone is
curious.)

			--Matt