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
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
for the relationship between hash maps and NaT
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk