Re: std::vector error
Vladimir Grigoriev wrote:
No, you are mistaken! The problem is in Microsoft VC++ code. It breaks =
the
main principle of OOP that a server code should not depend on a client =
code.
This principle cannot be readily applied to STL - all it does is =
manipulate user-provided classes and naturally depends on their =
behavior. However, the implementation should avoid _unintended_ points =
of customization. Unfortunately, C++ makes it difficult to do so.
For discussion of a similar set of issues, see
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1387.htm
These defect reports attempt to plug a particular hole - that of picking =
up unintended user-defined functions by Koenig lookup. Your case doesn't =
involve Koenig lookup, so it's different in the letter though similar in =
spirit. It's not clear to me whether VC2005's implementation is outright =
non-conforming, but from a quality-of-implementation standpoint it could =
certainly be improved (which, apparently, it was in later versions).
Having said that, defining a generally-applicable templated overloaded =
operator in global scope is probably not the best idea. It's too easy to =
pick it up by accident.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not =
necessarily a good idea. It is hard to be sure where they are going to =
land, and it could be dangerous sitting under them as they fly overhead. =
-- RFC 1925