为什么禁止对存储在 STL 容器中的类重载 operator&()?
突然在这篇文章(问题 2") 我看到一个声明,即 C++ 标准禁止使用 STL 容器来存储类的元素,如果该类具有重载的 operator&()代码>.
Suddenly in this article ("problem 2") I see a statement that C++ Standard prohibits using STL containers for storing elemants of class if that class has an overloaded operator&()
.
重载 operator&()
确实有问题,但看起来可以通过一组看起来很脏的演员表在 boost::addressof()
中使用,被认为是可移植和符合标准的.
Having overloaded operator&()
can indeed be problematic, but looks like a default "address-of" operator can be used easily through a set of dirty-looking casts that are used in boost::addressof()
and are believed to be portable and standard-compilant.
为什么在存在 boost::addressof()
解决方法的情况下禁止存储在 STL 容器中的类使用重载的 operator&()
?
Why is having an overloaded operator&()
prohibited for classes stored in STL containers while the boost::addressof()
workaround exists?
推荐答案
在没有查看链接的情况下,我认为 boost::addressof()
中的技巧是在要求不为要保存在 std lib 容器中的对象重载一元前缀 &
.
Without having looked at the links, I suppose the tricks in boost::addressof()
were invented well after the requirement to not to overload unary prefix &
for objects to be held in containers of the std lib.
我依稀记得 Pete Becker(当时为 Dinkumware 的标准库实现工作)曾经说过,每个重载 address-of 运算符并希望他们的标准库实现仍然有效的人都应该受到惩罚,必须实现一个标准库做这个.
I vaguely remember Pete Becker (then working for Dinkumware on their standard library implementation) once stating that everyone who overloads the address-of operator and expects their standard library implementation still to work should be punished by having to implement a standard library which does this.
相关文章