Andrey Melnikov wrote:
Calum Grant wrote:
Andrey Melnikov wrote:
I hate extra dynamic memory allocation even more than I hate extra copies, because the former cannot be optimized out and
usually takes
more time than 10 extra copies. Well, pool allocators help a lot sometimes, but it's an optimization technology.
I like Boost.Optional because it offers a good way to deal with optonality without any extra pointers, memory allocations, special "NULL" values or construction or copy operations . I think it's way different from the concept of smart pointers.
But we're talking about private implementation. From a semantic perspective, Optional behaves like a smart pointer with a "copy on assign" policy. Perhaps there would be fewer howls of disapproval if I called it a smart container, not a smart pointer.
It's just a terminology question. Boost.Optional isn't a "pointer". It isn't an enhanced C pointer, it isn't used like a pointer, it doesn't use pointers internally. It can be "dereferenced", but it's just a syntactic feature.
Also it isn't a container in STL sense. It doesn't provides range interface, iterators etc.
I would call Boost.Optional a proxy.
Perhaps a broker.
If an implementation improves a smart container/pointer in this circumstance then that's fanstastic.
I don't understand you here.
All I'm saying is that one could regard in-object storage as an optimization over out-of-object storage, which is a "good thing". Calum