incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <Travis.Vi...@roguewave.com>
Subject RE: svn commit: r587164 - /incubator/stdcxx/branches/4.2.x/include/vector.cc
Date Tue, 23 Oct 2007 21:39:09 GMT
 

Martin Sebor wrote:
>
>Travis Vitek-4 wrote:
>> 
>> Martin Sebor wrote:
>>>
>>>Travis Vitek wrote:
>>>>   1. _TypeT is a UDT with an implementation of operator& 
>>>>   that returns something that isn't convertible to a pointer
>>>>   type.
>>>>
>>>>   2. _TypeT is a UDT with an implementation of opreator& 
>>>>   that returns something convertible to pointer, but the
>>>>   returned value is not the address of the object.
>>>> 
>>>> I see no reason that either of these cases would not be legal.
>>>
>>>Except for:
>>>http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#634
>>>and:
>>>http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580
>>>or even:
>>>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html
>>>
>>>Allocators -- what a horrible mess!
>>>
>> 
>> Actually, none of those actually say it isn't legal to instantiate a
>> std::vector on a user-defined type that defines unary operator&. They
>> all relate to the 'defective' allocator interface. :P
>> 
>
>How so? Issue 634 points out that allocator::address(x) is required to
>return &x.


When I said

>>>>
>>>> I see no reason that either of these cases would not be legal.
>>>>

I mean that there is no restriction in the standard that says
std::vector<UDT> for a UDT with a void returning operator& is forbidden
or has any undefined behavior [note that the standard does add this
restriction to raw_storage_iterator, uninitialized_copy,
uninitialized_fill and uninitialized_fill_n]. Given that there is no
such restriction in the standard and that other implemenations handle
the case correctly, I take that as a pretty good indication that the
code is 'legal'.

The behavior may not be defined absolutely within the standard, but I
[and possibly a few C++ Standard Library users] would expect
std::vector<UDT> would behave like std::vector<int>. The user doesn't
[and shouldn't] care how we get the address of an object, provided that
their code compiles and runs with the expected behavior.

Travis


Mime
View raw message