Boost logo

Boost :

From: Sascha Krissler (boost-dev_at_[hidden])
Date: 2006-08-06 12:44:33


Fernando wrote:
> > [...]
> > But when i store values where the type has an
> > inline NaT value (for example NULL pointers) i cannot and need not
> > use optional.
>
> Can you explain why you cannot use optional<>?
> I definitely see that you don't need it, but for the sake of genericity I
> just wouldn't mind the fact that some types do have an identifiable null
> value and use optional<> all along.

Well i could use it but i do not want to.
The space complexity is linear as i have to
store it for every entry and a perfect hash could grow alot even for
a small number of entries.

Further arguments:

The interface change would be backward compatible as you add a
template parameter which has a default value (indicating the old
behaviour).

With the change i would have both the more optimal solution and
the genericity.

My problem is that the implementation of optional is not as trivial as
it seems and i cannot wrap the class so i would have to copy and modify
the source. And i guess using optional in containers and having both
types of values (pointers are a good example for the inline NaT case)
is not such a far fetched scenario.
In the special case of pointers it would make sense not to have a static
member indicating the null value but a Discriminate template parameter
having the special value 'class NullPtrTag { };'.

Another solution would be to make a detail::generic_optional with all
the operator foo and let optional inherit from it.
That would be infinitesimal backward-incompatible ;)


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