Re: overloading address operator and standard containers
* Kai-Uwe Bux:
Hi folks,
please consider:
#include <list>
struct aaa {};
struct bbb {
aaa operator & ( void ) const {
return aaa();
}
};
int main ( void ) {
std::list< bbb > a;
}
Is this required to compile or is a compiler within its rights to reject the
code?
It can reject the code.
I'm sure you can find the standard's requirements yourself, so I just mention
the infamous case of Microsoft's ATL workarounds for this issue. They originally
designed the ATL library with address operators overloaded, incompatible with
the standard C++ library. So now you know that it's real issue you can safely
invest the time to find the standard's requirements (if u still feel u need it).
I recently posted a bug report and have been told that the code is invalid.
The address operator is supposed to be not overloaded. This, I have learned,
should follow from the provisions in C++03 about allocator::address().
Uh, it's that way also in C++98.
I am
still trying to understand the reasoning, but I feel that I need some help.
Part of the reasoning is, I think, that with overloaded address operator any
container that does low-level things has to do CounterIntuitive Things(TM) to
obtain the real address of an object.
Say, you have a raw array of formal type T[n], where the first k elements are in
use, and you want to emplace an object at a[k]. With the T address operator
overloaded you can't just do ::new(&a[k])T(args). You have to do silly things
such as ::new(&reinterpret_cast<void&>(a[k]))T(args). Or, well, I guess you
could do ::new(a+k)T(args), but it's a bother when a+k and &a[k] mean two
different things. And presumably the standard library code shouldn't have to
guard against this...
The Boost library has some wrapper for the reinterpret_cast.
Cheers & hth.,
- Alf