This is the mail archive of the
mailing list for the libstdc++ project.
Re: operator== missing on std::__debug::map<>::iterator
On Tue, Dec 11, 2012 at 11:05 AM, Chris Jefferson <firstname.lastname@example.org> wrote:
> On 11/12/12 16:54, Jonathan Wakely wrote:
>> On 11 December 2012 14:01, Chris Jefferson <email@example.com> wrote:
>>> On 11/12/12 13:45, Gabriel Dos Reis wrote:
>>>> On Tue, Dec 11, 2012 at 5:53 AM, Pedro Larroy
>>>> <firstname.lastname@example.org> 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
>>> 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).