为什么STL容器中存储的类禁止重载operator&()？
突然在 这篇文章（“问题 2”） 我看到一个声明，如果该类具有重载的 operator&()，则 C++ 标准禁止使用 STL 容器来存储该类的元素。
重载operator&() 确实可能有问题，但看起来可以通过 一组看起来脏兮兮的转换，用于 < code>boost::addressof() 并被认为是可移植的且符合标准。
为什么在存在 boost::addressof() 解决方法的同时，禁止对存储在 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&().
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.
Why is having an overloaded operator&() prohibited for classes stored in STL containers while the boost::addressof() workaround exists?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在没有查看链接的情况下，我认为
boost::addressof()中的技巧是在要求不重载对象的一元前缀&之后发明的。保存在标准库的容器中。我依稀记得 Pete Becker（当时在 Dinkumware 从事标准库实现工作）曾经说过，每个重载地址运算符并期望其标准库实现仍然可以工作的人都应该受到惩罚，因为必须实现一个执行此操作的标准库。
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.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.
可能是因为仅仅禁止使用重载的operator&()类比创建std::addressof()函数并替换&的每次使用要麻烦得多。在容器代码中使用它。
Probably because it's less hassle to just prohibit the use of overloaded operator&() classes than to create a std::addressof() function and replace every use of & in container code with it.
该标准于 1998 年最终确定，并于 2003 年进行了修复，而
boost::addressof日期可以追溯到 2002 年初。此外，还不清楚
addressof是否就是答案。operator&()的重载表明应避免使用原始指针。Allocator::address成员提供了从Allocator::reference到Allocator::pointer的最佳接口，因此一般来说，您应该能够有效地引入一个operator&重写到一个具有自定义分配器的其他行为良好的类。考虑到引用几乎可以完成指针所做的所有事情，并且 Allocator 接口抽象了其他所有内容，因此应该不需要原始指针。
图书馆实施者的便利不应该成为问题。
Allocator::pointer定义不明确的语义是一个问题，到目前为止我在 C++0x 中读到的内容并没有弄清楚这一点。C++0x 从 CopyConstructible 中删除了任何对
operator&的提及，而且根本不需要任何可构造的容器参数 — 用户可以坚持使用emplace。即使vector也只需要 Destructible，尽管我认为实际使用insert或erase需要更多。（请注意，在最严格的阅读中，C++03 中不禁止重载。只是不允许更改内置函数的值或类型。）
The standard was finalized in 1998 with fixes in 2003, whereas
boost::addressofdates to early 2002.Moreover, it's not clear that
addressofis the answer. Overloads ofoperator&()indicate that raw pointers are supposed to be avoided. TheAllocator::addressmember provides the best interface to get fromAllocator::referencetoAllocator::pointer, so in general theory, you should be able to effectively introduce anoperator&override to an otherwise well-behaved class with a custom allocator.Considering that references do almost everything that pointers do, and the Allocator interface abstracts everything else, there should be no need for raw pointers.
Convenience to the library implementers should not be an issue. The ill-defined semantics of
Allocator::pointerare a problem, and what I've read so far in C++0x doesn't clear that up.C++0x removes any mention of
operator&from CopyConstructible, and furthermore doesn't require anything-Constructible for container arguments at all — the user can stick toemplace. Evenvectoronly requires Destructible, although I suppose actually usinginsertorerasewould require more.(Note that, in the strictest reading, overloads are not forbidden in C++03. You are just not allowed to change the value or type of the builtin.)