stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject RE: svn commit: r587164 - /incubator/stdcxx/branches/4.2.x/include/
Date Tue, 23 Oct 2007 15:53:40 GMT

Travis Vitek-4 wrote:
> 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

How so? Issue 634 points out that allocator::address(x) is required to
return &x. A type that overloads operator&() to return void instead of
T* (or pointer) breaks the function. Issue 580 notes that containers
aren't currently required to use allocator::address() but they are not
forbidden, either. And if N2257 should be adopted as a solution to
issue 580, containers wouldn't even be allowed to call address()
since the function would no longer exist.

View this message in context:
Sent from the stdcxx-dev mailing list archive at

View raw message