Re: naked pointer vs boost::shared_ptr<T>

Dejan.Mircevski@gmail.com wrote:


More or less. I have objects which have an explicit lifetime.
Their lifetime doesn't depend on random internal factors like
who might or might not hold a pointer to them.


Originally, at least. Most of the time. That may be an
artifact of my applications (servers, where the "clients"
actually run on a different machine), however; I can easily
imagine cases where all of the clients actually do hold
pointers (e.g. GUI applications).


Well, lookup isn't necessarily successful, so you need a null
pointer. And of course, sometimes, the client will have to
reseat it, and very, very often, the raw pointers will end up in
containers.


It almost certainly will copy it. It will also call member
functions through it---that is generally the motivation for
having it. In many cases, in fact, it will start by calling a
member function to register itself as an observer of the object,
so that it can be notified of changes of state of the object.


Design. The relationships between objects are a vital part of
design.


When an object self-destructs, it's destructor is called. Which
does whatever is necessary to ensure that the object isn't used
in the future---it removes it from any registry, informs
observers, etc.


Because the object has arbitrary lifetime, and dynamic memory is
the only means to obtain arbitrary lifetime in C++.


Persistence depends on the application.

In my present application, for example, the server is stopped at
the end of the day, and restarted every morning. (This is,
IMHO, rather exceptional.) Objects will almost never be deleted
the same day they are created, however. On start-up, objects
are created from the persistent data base; all updates are also
mirrored to the persistent data base (before being acknowledged
to the client). And objects are also deleted---in our case,
because they have been "closed" for at least 24 hours. (When
they are deleted, they are in fact moved to a second persistent
database, backed up once a week on mag tape, because legally,
the data the objects represent is required to be kept
forever---or at least something like fifty or a hundred years.)

All of my previous server applications have run 24 hours a day,
7 days a week. Persistence was only used "just in case", if the
machine crashed, or something like that. Objects were created
as a result of client requests, and deleted as a result of other
client requests.

In the one large GUI application I worked on, except for
persistence, one could say it worked in a similar fashion.
Objects were created as a result of client interaction (in this
case, the client was the user, and his "requests" took the form
of mouse clicks and keyboard input), and were later deleted as a
result of other client interaction. But the same rules applied:
if a panel was removed from screen, because of some user action,
the object which represented it automatically became invalid,
and was "deleted". (In fact, the application was in Java, so
there was no delete, but rather a special member function
dispose(), which did whatever had to be done. I might add that
we modified Swing to support this, because we had problems
managing the lifetime of objects.)

In no case does the lifetime of an object depend on who has a
pointer to it. The problem is rather the reverse: when the
object's lifetime ends, you have to ensure that all interested
parties are notified.


I would definitly not recommend using "delete this" in the
destructor.

I think you're getting hung up on the "delete this". I've found
that it is usually convenient (and very OO:-)) to let the object
manage its own lifetime, but the important point is not who does
the delete, but the fact that it is an explicit action, taken in
response to an explicit stimulus, and is not "garbage
collection", or anything along those lines. (And that it is
really independant of memory management---even with garbage
collection, such objects need explicit lifetime management,
because their lifetime is part of the design.)


There are no benefits of RAII in this case. In fact, there is
absolutely no way to use it, except to artificially create other
objects, which have a manually managed lifetime. Technically,
what RAII does is associate the lifetime of the managed resource
to the lifetime of another object. It's a very powerful idiom
when you have another object which already has the correct
lifetime, and even more powerful when the lifetime corresponds
to one of the lifetimes C++ manages automatically. It's totally
irrelevant when the "resource" is itself an object, and the
lifetime of that object must be managed explicitly anyway.


Common sense, mostly. The semantics of the object are such that
it wouldn't even occur to anyone to create one other than
dynamically. The objects don't support copy or assignment, and
the semantics require explicit lifetime, with an explicit
creation (thus, no static lifetimes) and an explicit destruction
as a reaction to a different stimilus, at some unknown point in
the future.


I'm not sure I was clear: "whoever is holding the weak_ptr has
to delete the weak_ptr". Surely you have 1 to n relationships
in your software. How do you manage those? I generally use an
std::set< T* >, and register as an observer with whoever is
responsible for the lifetime of the T---the T objects
themselves, if "delete this" is being used, or with whoever is
responsible for the object lifetime otherwise.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
                    Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]