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