incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject RE: svn commit: r587164 - /incubator/stdcxx/branches/4.2.x/include/vector.cc
Date Tue, 23 Oct 2007 16:01:59 GMT


Travis Vitek-4 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. I think
>>you should be using the allocator_type::address() to get the physical
>>address of a given object.
>>
>>Here is a simple testcase that illustrates the compile failure that was
>>introduced with this change.
>>
> 
> FWIW, it appears that this problem exists when calling other methods of
> std::vector<S>. The vector implementation uses the function templates
> std::uninitialized_copy() and std::uninitialized_fill(), both of which
> require that the iterator types 'have operator* return an object for
> which operator& is defined and returns a pointer to T' [20.4.4 p1].
> 
> I think this is another bug. Martin?
> 
> 

The vector members should call the overloads of the uninitialized
algorithms that take a reference to Allocator as the last argument.


Travis Vitek-4 wrote:
> 
> 
> If so, I'll file it seperately. Here's the testcase for those who are
> interested.
> 
> 

Yes, please do.

Martin

-- 
View this message in context: http://www.nabble.com/RE%3A-svn-commit%3A-r587164----incubator-stdcxx-branches-4.2.x-include-vector.cc-tf4672892.html#a13366994
Sent from the stdcxx-dev mailing list archive at Nabble.com.


Mime
View raw message