Re: [boost] feature request for optional

From: Sascha Krissler (boost-dev_at_[hidden])
Date: 2006-08-07 11:48:58

On Mon, Aug 07, 2006 at 10:25:08AM -0300, Fernando Cacciola wrote:
> Sascha Krissler wrote:
> > 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.
> >
> So your problem boils down to sizeof(optional<T>)=sizeof(T)+sizeof(bool)?

Yes, thats my main problem.

> 
> I'm not sure I like your proposal from a semantic POV, so it might help if 
> you could give more detail that just "optional is bigger than I want".

As i intend to optimize the inline NaT case my first problem is gone.
The next problem is *i* have to handle the special case though some
template specializations.
If the whole source was under my control i would change optional<>
In the end i intend to use it as an interface concept to handle the
handling of optional values.

> Can you show me a _concrete_ example for the iniline NaT case? Along with an 
> example of a non inline case?

I am hashing std::type_info *, which cannot be NULL for a valid type.
The (pefect) hash map should be usable for any other type too (no concrete
example available).
See
http://archives.free.net.ph/message/20060806.164337.843542fc.en.html
for the relationship between hash maps and NaT