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

[Gabriel Dos Reis]

On Tue, Dec 11, 2012 at 11:05 AM, Chris Jefferson <chris@bubblescope.net> wrote:
> On 11/12/12 16:54, Jonathan Wakely wrote:
>>
>> On 11 December 2012 14:01, Chris Jefferson <chris@bubblescope.net> wrote:
>>>
>>> On 11/12/12 13:45, Gabriel Dos Reis wrote:
>>>>
>>>> On Tue, Dec 11, 2012 at 5:53 AM, Pedro Larroy
>>>> <pedro.larroy.lists@gmail.com> 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.
>>>>
>>>> Why?
>>>
>>>
>>> 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.

Which is the subject of this thread.

> 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).
>
> Chris