$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] compact_optional -- prompting interest
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-09-27 18:15:46
On 28.09.2015 01:07, Gavin Lambert wrote:
> On 26/09/2015 04:17, Andrey Semashev wrote:
>> On 25.09.2015 18:55, Marcel Raad wrote:
>>> Andrey Semashev-2 wrote
>>>> 1. You chose not to provide relational operators for compact_optional
>>>> because you don't know how to order 'empty' values. I think you don't
>>>> have to make that decision and simply forward the call to the
>>>> underlying
>>>> type. I mean, you always have the stored object constructed in some
>>>> state and as long as it implements operators you can always use them.
>>>
>>> This is exactly the problem I sometimes have with Boost.Optional: in
>>> some
>>> use cases, I want the compiler to remind me that my special value is
>>> special and always has to be checked explicitly instead of assuming it's
>>> always the lowest possible value. That doesn't apply to operator== and
>>> operator!=, of course.
>>
>> In my practice most of the time you just want some kind of ordering
>> (e.g. for binary lookup). For these cases it's useful for ordering to
>> just work out of the box. When the actual order matters you can always
>> provide your own operator overloads - something you will have to do
>> either way.
>
> Isn't the solution there to specialize std::less and/or std::hash
> instead of providing operators? (I vaguely recall there being a nicer
> way to do this proposed and/or implemented in one of the newer
> standards, but I don't recall the details.)
That's one alternative, surely. My point is that this should "just work"
by default and allow customization when something special is required.