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