David Abrahams wrote: > "Edward Diener" <[EMAIL PROTECTED]> writes: > >> David Abrahams wrote: >>> Douglas Paul Gregor <[EMAIL PROTECTED]> 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost