This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: operator== missing on std::__debug::map<>::iterator

On 11/12/12 16:54, Jonathan Wakely wrote:
On 11 December 2012 14:01, Chris Jefferson <> wrote:
On 11/12/12 13:45, Gabriel Dos Reis wrote:
On Tue, Dec 11, 2012 at 5:53 AM, Pedro Larroy
<> wrote:
I'm not discussing if the member operator== is correct or wrong, but
the code compiles fine in several C++ compilers and the only problem I
found was with libstdc++ in debug mode, my point is that it should
either compile or fail in both modes.

Surely it is better for users if we try to avoid inconsistencies between debug mode and non-debug mode which have no good reason for existence? Getting C++ programs to run on a variety of compilers and settings is complicated enough already, why not try to reduce the inconsistencies where possible, where there is no cost?
If normal mode was changed to not use a member function, as Paolo
suggested doing, how would that help the code that assumes operator==
is a member function? It would still be making non-portable
assumptions that don't hold for all implementations, it would still be
broken, and it should still be changed to use a==b not a.operator==(b)

Some code deserves to be broken.

There's a simple, portable workaround. I see no good reason to change
the library to accomodate one example of bad code.

Oh, I certainly don't think the library should accomodate bad code. I just think, as Pedro said, that the bad code should do the same thing (compile, or not compile) in both debug and non-debug mode. In this case breaking the bad code in release mode is the right thing to do I think we both agree (sorry if that's me putting words in your mouth).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]