stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <>
Subject RE: svn commit: r587164 - /incubator/stdcxx/branches/4.2.x/include/
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:
>>>or even:
>>>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.


View raw message