[boost] Re: Re: Re: boost::optional feature request.

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-03-25 15:40:14

David Abrahams wrote:
> "Edward Diener" <eddielee_at_[hidden]> writes:
>
>> David Abrahams wrote:
>>> Douglas Paul Gregor <gregod_at_[hidden]> writes:
>>>
>>>> On Mon, 24 Mar 2003, Edward Diener wrote:
>>>>
>>>>> Do you really want the key to an associative container to be an
>>>>> optional value ? I would be hard-pressed to find a use for that.
>>>>
>>>> FWIW, the Signals library actually does this internally (although
>>>> with boost::any objects instead of boost::optional objects).
>>>> However, I would contend that the need is too specialized to
>>>> warrant adding an operator<.
>>>
>>> Seems entirely reasonable to me to add it.  It looks like at least
>>> two people have needed exactly those semantics.  What's the cost?
>>
>> I am not trying to shoot down the request but could someone give me a
>> practical example of the case where an optional value which does not
>> exist ( I hope that's the right term for when an optional value has
>> no valid value ) serves as a key in an associative container ?
>
> I guess you can look at how boost::any is used in the signals library
> for an example.

The boost::any idea is not the same as boost::optional. The main difference,
as I understand it, is that boost::optional is able to present a
"non-actual" value for a type in a way that makes it easy to check. My whole
point is that boost::any contains "actual" values, making its use as a key
in an associative container very reasonable, while boost::optional's main
purpose is to present the normal range of "actual" values along with a
"non-actual" value and the "non-actual" value possibility is the reason for
using boost::optional as opposed to the direct type. Therefore to justify
boost::optional as a key in an associative container, as opposed to its
direct type, I believe one has to justify a situation where the "non-actual"
value is really being used as a key. My reading of boost::optional shows
good examples where it could be used, all to be able to check whether a
"non-actual" value could exist, but I can't understand how being a key in an
associative container could be one of them. Or is the justification
something like, 'I am using a bunch of optionals in other ways to check for
a "non-actual" value and want to be able to use my results as a key in an
associative container without having to extract the actual values' ? While
that is possible, it must be very rare indeed, especially as the actual
values can be extracted rather than boost::optional with a minimum of extra
code.