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 00:36:07 GMT
 

Martin Sebor wrote:
>
>Travis Vitek wrote:
>> Farid,
>> 
>> It seems that this change would cause some potentially 
>serious problems
>> in two different cases.
>> 
>>   1. _TypeT is a UDT with an implementation of operator& that returns
>> something that isn't convertible to a pointer type. [compile error]
>>   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. [runtime error]
>> 
>> 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

>> I think
>> you should be using the allocator_type::address() to get the physical
>> address of a given object.
>
>Agreed. We have implemented the proposed resolution to #634 for
>some time so we might as well be consistent with ourselves :)
>

FYI, this issue isn't isolated to the vector container. It exists for
most of the iterator/proxy types also. Everywhere you see
_RWSTD_OPERATOR_ARROW, and nearly everywhere you see '&*' will have some
issue with this. I'm sure that there are other places that the problem
happens, but those are the ones that are easily isolated.

Travis

Mime
View raw message