[Boost-users] optional_shared_ptr or shared_lazy_ptr extension

From: Ovanes Markarian (om_boost_at_[hidden])
Date: 2007-01-11 13:41:14

Hello all,

after some time spent for evaluating the possible scenarios I came up with the following idea.
Design of a type wrapper similar to functionality offered by boost:shared_ptr and boost:optional.
Let me try to explain the requirements:

1. The new type must model pointer semantics to wrapped type.
2. It must be refernece countable and multi-thread safe in regards of shared operations (copy
etc.) as it is the case with shared_ptr
3. It should be able to create the wrapped type on first non-const member access request, which
assumes a multi-thread safe operation (when shared accross multiple threads)
4. It should support InPlace factory and custom deleter types
5. It should not pre-allocate the storage for the contained type
6. It should be possible to use static_pointer_cast, dynamic_pointer_cast and const_pointer_cast
operations with the new type.

Why is optional not an option for me:
1. It preallocates memory, which I would like to save and allocate at first request only
2. The type should not implement deep copy semantics for the contained value type if copied, but
act much like a shared_ptr (shallow copy)

The most important use case:

class A;

Main Thread
lazy_ptr<A>   ptr;

Thread 1    | Thread 2           | Thread 3
------------+--------------------+-------------
copy of ptr | copy of ptr        | copy of ptr  (use_count == 4, get()const returns NULL)
            | ptr.get()non-const |              (use_count == 4, get()non-c will return valid A*)
use(*ptr)   |                    | use(*ptr)    (using the same instance as created from Thread 2)

If dealing intensively with big size data structures this approach can save a lot of memory if
none of the threads needs an instance.

All comments are highly appreciated. I also posted some comments on the similar issue, but got a
suggestion to use boost::optional. Since I was not aware of all the requirements at that time I
could not go ahead with a discussion.

With Kind Regards,

Ovanes Markarian