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?
If so, I'll file it seperately. Here's the testcase for those who are
interested.
#include <vector> // for vector
struct S
{
void operator& () const {};
};
int main (int argc, char** argv)
{
const S s [3];
std::vector<S> v;
// this is just a compile test, it is not intended to run
v.assign (1, s [0]);
v.assign (s, s+3);
v.at (0);
v.back ();
v.begin ();
v.capacity ();
v.empty ();
v.end ();
v.front ();
v.insert (v.begin (), s [0]);
v.insert (v.begin (), s, s+3);
v.insert (v.begin (), 2, s [0]);
v.erase (v.begin ());
v.erase (v.begin (), v.end ());
v.max_size ();
v.pop_back ();
v.push_back (s[0]);
v.rbegin ();
v.rend ();
v.reserve (10);
v.resize (10);
v.size ();
std::vector<S>().swap (v);
return 0;
}
