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 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:
>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

>> 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.


View raw message