Reference gives a different guarantee than pointers. Ok Could still be cast to a pointer but ....

T& x = my_obj(); // reference *feels* like more obvious semantics than pointer. x.do_it();

*Ideally* my_obj always holds something... never empty. That is I guess problematic from the implementation viewpoint, as it may cause a large number of allocations. However it makes the thing extremely simple to use. Dont really want to have to do this all the time:

if( !my_obj.is_empty()){ my_obj().do_it(); }

Actually, reference isn't all that different from a pointer except that you can use the dot operator (and operator <<, +, -, ==, etc.) on it without dereferencing first. I think you're looking for "smart references," but C++ doesn't really do them because you can't overload the dot operator. I bet you could get something very close to what you want by defining another class smart_object<T> that inherits from shared_ptr<T>, but suppresses the -> and = operators and has an implicit conversion to T&. (Implicit conversions are often a bad idea, and I don't know if this is an exception, but...) As far as reference semantics, all you really want is a guarantee that a shared_ptr<T> is always initialized to a non-null value, so make sure there is no default constructor and you're in business. I don't know if I recommend actually *doing* this, though. shared_ptr should probably be sufficient for giving you reference semantics, and while it's nice to use operators without dereferencing (*myPtr), it's probably not worth messing with implicit conversions to achieve it. Max

OTOH maybe could do: share_object<T> my_empty_obj(leave_empty()); // then make sure its not empty before going public...

I believe that shared_ptr throws an exception if you try to dereference it while it's empty. If you are mathematically positive that a shared_ptr has a value (e.g. no default constructor), you don't even need to set a catch block (although you still ought to run unit tests, etc.). -- Ubi solitudinem faciunt, pacem appellant. They make a desert and call it peace. -Tacitus

...

Reference gives a different guarantee than pointers. Ok Could still be cast to a pointer but ....

T& x = my_obj(); // reference *feels* like more obvious semantics

"Maximilian Wilson" <wilson.max@gmail.com> wrote in message news:2ddbda5f04100821532684f2f8@mail.gmail.com... than

...

pointer. x.do_it();

*Ideally* my_obj always holds something... never empty. That is I guess problematic from the implementation viewpoint, as it may cause a large number of allocations. However it makes the thing extremely simple to use. Dont really want to have to do this all the time:

if( !my_obj.is_empty()){ my_obj().do_it(); }

Actually, reference isn't all that different from a pointer except

The critical difference between a reference and a pointer (in the classical sense) is that a reference is guaranteed to refer to some object, else the program is ill-formed. Further a reference cannot be rebound. This makes it much more closely associated with a particular object, which in this case is the desired semantics IMO. If I have two functions: T* get_pointer(); T& get_reference(); There is no need to (nor can you) check the result of the second but it would be Very Wise to check always that the result of the first is not 0. (Otherwise presumably it would return a reference). Hey... I know this is obvious but just trying to put this in context.

that you can use the dot operator (and operator <<, +, -, ==, etc.) on it without dereferencing first. I think you're looking for "smart references," but C++ doesn't really do them because you can't overload the dot operator.

It Might be useful that the shared_object doesnt feel exactly like a stack allocated object. Typically == would be used to check that two shared_objects are in fact referring to the same object, rather than that the values in objects they refer to are the same. Function call is one way to provide access.

I don't know if I recommend actually *doing* this, though. shared_ptr

I don't know either... I'm just *mucking about* with it. Bearing in mind that the default ctor allocates this is *amusing*: struct Someclass{ shared_object<Someclass> x; }; Causes an infinite recursion. I used the create_empty() ctor to prevent this in quick tests... which then leads to requirement for a create() function ala MFC CWnd. Perhaps they hit the same sort of issues. It seems that neither the tentative shared_object above, nor a shared_ptr give quite the perfect semantics for a shared object (hence the proliferation of smart pointers). Perhaps there is a new type lurking here somewhere... OTOH perhaps I'm trying to invent a perpetual motion machine...:-) regards Andy Little