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 Mon, 22 Oct 2007 23:06:38 GMT
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!

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

Martin

> 
> Here is a simple testcase that illustrates the compile failure that was
> introduced with this change.
> 
>   #include <vector>      // for vector
> 
>   struct S
>   {
>       void operator& () const {};
>   };
> 
>   int main ()
>   {
>       std::vector<S> v;
>       v.insert (v.begin (), S ());
> 
>       return 0;
>   }
> 
> Travis
> 
> 


Mime
View raw message