This is the mail archive of the libstdc++@gcc.gnu.org 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 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.


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