Re: Article on possible improvements to C++
"Nick Keighley" <nick_keighley_nospam@hotmail.com>
there are objects with very long lifetimes. Lifetimes comparable but
not necessarily equal to the lifetime of the system. For instance
calls in some mobile radio systems can be of unlimited duration. But
not all calls are like this. So clearing/hanging up calls must be
properly managed or all sorts of precious reocurces will leak away.
I can't see anyway to do this apart from having objects
(CurrentCallList) that are effectivly global.
See my other post.
It's
easy to extend this idea to shared ownership. Optionally, you can free
resources early as long as the resource still has an owner which would
still free the resource if you "accidentally" commented out the early
release.
so the CurrentCallList in my example gets destructed when the program
terminates and any calls left in are destructed then. Which might be a
bit late. I suppose it would close the call log and tell the user his
call has terminated.
Exactly what I just said. But... what can you do about it? The call is
either needed to linger, than it is the correct thing, or it must be
terminated, that was due well before exit. That is likely a leak in the
*design* (like at the abstract/UML level). If not, it's a bug of translation
of design to code.
RAII
is all about ownership responsibilities. I haven't taken enough time
to look through all examples, so please treat this as a tentative idea
from myself. Obviously there will be exceptions to this rule, I think.
objects that don't follow a FIFO life cycle. Which is pretty much
anything in the real world!
My observation are the "is-init" part, that truly enforces FIFO is pretty
rare kind of use. Partly due to some widespread library designs.
MFC uses 2-phase init extensively, and even the true RAII cases are broken
with the interface, see CSingleLock -- who in right mind would make it take
= false as default param?
Still RRID handles most of the practical cases for good -- and the order is
many times not as direct.
That's practicly the same thing I was talking about. Not stupid at all,
and
passed the test of the real life in practice.
managed equipment, calls, circuits, channels, routes, messages, logged
in users, drawable objects in animations, etc. etc. etc.
LOL, made ton of all all those and more :)
Possibly my ise of "client"
code is not clear -- I keep [] the handlers themselves (that have the
dtors) as "library" code. Which has a different life cycle. Maybe
"framework" would be a better name.
don't follow you
Too bad. More specificly?
Early drop can be done through the .reset() interface (or its equivalent
in
the manager), and commenting it out just results in keeping the thing
little
longer.
if the system nver terminates that means the object is kept forever.
So as soon as we've used all the available radio channels the system
hangs.
See earlier and other post.
I don't get what would be the problem with non-stack-frame limited
resources -- the manager may be at some outer block, or a member of the
class, but eventually it will bite the dust too.
oh it will bite the dust eventually but system termination time (weeks
later? months later?) is waay too late. There are well defined times
when a call terminates (the user hang up, we lose contact with him,
something breaks)- BUT THEY DONT FOLLOW A FIFO LIFE CYCLE!
Never occoured to me they are ;-) The important part is they do follow a
LIFE CYCLE. You maintain that. Most importantly at paper design. I saw
way more problems messed up right there, what leaves no chance in the
implementation to be correct. If your system allows (or overlooks) endless
calls, and it is a permanent system, yes, it will eventually run out of
juice. Protocol steps that wait trigger from outside have attached timers
for a good reason...
(Actually one of my main lines of work is duning all kind of communications.
At high level, middle level, low level, you name it, and most systems
planned for non-stop use. And they work too, many years a chunk, sometimes
stopped for some hardware maitainance or accident.... When I say it works it
is not theory, but life-proven practice, and on failure I'd probably not
talk here unless usenet is mainstream in jails. ;-)