Boost logo

Boost :

From: Anthony Williams (anthony.williamsNOSPAM_at_[hidden])
Date: 2003-09-01 07:04:58


"Peter Dimov" <pdimov_at_[hidden]> writes:
> Eric Friedman wrote:
>> Peter Dimov wrote:
>>> When there is one and only one strict weak ordering (equality) for a
>>> type, not using operator< and operator== because some users might
>>> have different expectations is misguided. It is pretty clear what
>>> set<variant> or find(first, last, v) is supposed to do; variant_less or
>>> variant_equal is "required boilerplate" as Howard says. :-)
>>
>> I'm not sure I agree. If the ordering scheme proposed by Dirk were
>> 'natural' in some way (as in the case of arithmetic types,
>> std::string, etc.) then I would offer no objection. But in fact it's
>> quite arbitrary.
>
> It's not arbitrary at all. Ask several randomly selected programmers what
> operator< should do. It is not reasonable to declare the ordering
> "unnatural" just because you don't like it. If there is one ordering, then
> this is the natural ordering, whether we like it or not.

I just started reading this thread, half way through, and so I didn't know
what Doug's proposed ordering was until I looked it up. It turns out that his
ordering is exactly what I assumed it would be --- if the types are different,
then the one which comes first in the list is "less" than the other; if the
types are the same, compare the values. It seems natural to me.

>> My point is that different users may reasonably desire differing
>> semantics. Worse still, I imagine many users will not realize their
>> desired semantics are not universally desired, and so they may never
>> think to read the docs for operator<(variant,variant).
>
> Note heavy speculation. May make sense in certain contexts. May make sense
> in other contexts. May be desirable. Users may reasonably desire different
> semantics. Have you considered the possibility that, in practice, it/they
> perhaps might not?

Indeed, if people need different semantics, they are free to provide a
function; they can even supply it to standard algorithms and containers if
they wish.

>> The absence of such an operator forces the user to read the docs.
>> That's my argument for boost::variant_before. It requires the user to
>> demonstrate his/her intent explicitly.
>>
>> Other than the additional typing (the "required boilerplate"), are
>> there other more fundamental objections?
>
> The fundamental objection is that you should not penalize the majority
> because someone "might need" different operator< semantics. Provide
> operator<. Wait six months. Collect feedback. If there is evidence that
> operator< is evil, remove it and document why it is not supplied.

I agree with Peter.

Anthony

-- 
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely response.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk