NewLC - auto_cleanup (an auto_ptr equivalent for R classes) - Comments

Re: auto_cleanup (an auto_ptr equivalent for R classes)

ssalmine — Tue, 28 Aug 2007 22:46:32 +0200

Note that s60v3 has support for c++ exceptions, so normal stack unwind calls dtors if object is in automatic (local) variable. This means that you can do auto_ptr and this trick here without cleanupstack.

You can also get rid of two-phased construction (using auto_ptr member variables).

NOTE: AFAIK, haven't actually tested these in practise.

This might also interest people: http://marcoplusplus.blogspot.com/2007/05/stlport-for-symbian-os-released.html

That should have working auto_ptr.

Re: auto_cleanup (an auto_ptr equivalent for R classes)

makom — Fri, 24 Aug 2007 10:46:48 +0200

Your are correct: For destructors that is obvious. I just wanted to point out that a programmer who uses auto_cleanup<> has to keep his eyes open for this condition.

Re: auto_cleanup (an auto_ptr equivalent for R classes)

alh — Fri, 24 Aug 2007 10:06:21 +0200

I think 99% of all cleanup methods take no arguments and return void. So I created a templated class TCleanupFunctor which makes the auto_cleanup class usefull for 99% of all the R classes.

All cleanup-functions should be argument-less and return void, or their design is broken.

You can't have a cleanup-function return something, because that means you have to handle the return value some way...
cleanup-functions must always succeed, or they wont be useful in error handling...

By the same logic, they must not take an argument, because this implicitly means the function might fail (because of a faulty argument)

There is good reason destructors are argumentless and returns nothing

Re: auto_cleanup (an auto_ptr equivalent for R classes)

svdwal — Thu, 23 Aug 2007 12:31:32 +0200

Programming is subject to the same economic laws as are all other types of work. This means that 1) over time, people doing a certain kind of job need to become more productive, and 2) the more productive you are, the more money you can make.

In the old days, people wrote assembly code themselves. Nowadays people use compilers. People using compilers are orders of magnitude more productive than people using assembly. A the time compilers became available, the discussion was that people should know what assembly code was generated, because it had to be fast, compact and whatnot. A discussion nobody is participating in anymore, for obvious reasons.

The same can be said for the auto_ptr<> discussion. With auto_ptr<> and similar classes, you get automatic behaviour that can be coded explicitly by the programmer too. But why bother? The automatic code is good enough for almost everybody. Besides, that is counting when doing Symbian memory management is to use as little as possible. auto_ptr<> can be used as easily as cleanupstack calls. You can always put an auto_ptr<> var inside a local scope, for instance. And as in any computing situation, the algorithm used is much more important than some local decisions on the order of allocation and deallocation.

Anyway, I never found the cleanupstack hard to use, not harder than similar schemes to protect you against resource leaks.

auto_ptr<> can be implemented using the cleanupstack, so it is a way of abstacting the cleanupstack away, using Standard C++ constructs instead of Symbian C++ ones.

Programmers should be carefull, but not only at the micro level. The macro level is much more important.

auto_ptr<> can *not* be used to ditch Symbian C++ 2-phase construction, in the same way that the cleanup stack can not be used to ditch 2-phase construction. Personally, I would use 2-phase construction in portable code, because it makes destructors much easier to write. In Symbian C++ you are guarantueed that all member vars are initialised when the destructor is called, a luxury you do not have in Standard C++.

Making code portable is an economic decision.

Sander van der Wal
www.mBrainSoftware.com

Re: auto_cleanup (an auto_ptr equivalent for R classes)

pirosl — Thu, 23 Aug 2007 11:25:58 +0200

Agree with you Sander for most of the points....but not at one single point and this is "leaving the programmer free to do usefull work." . I think a programmer should always know what's the status of pointers/objects he/she uses in his/her application. This mean lazy in my opionion - leaving everything to compiler and forget about the lifetime af your objects In fact, I think we can discuss a lot arround this subject ...and some of the point can be sumarized as:
- is indeed CleanupStack suck a difficult or usseless terminology that programmers keep complaining about it?
- is really auto_ptr a replacement for CleanupStack? (e.g. instead of putting smth on CS, programmer has to create aut_ptr)
- is it or is it not nattural that programmer should be so carerfull with memory management in Symbian environment?
- one good think about auto_ptr is that using it you can put all your object initialization in constructor (no more second phase construction needed)
- auto_ptr just hides CS .....and in this case code portability is just a matter of design

Re: auto_cleanup (an auto_ptr equivalent for R classes)

makom — Thu, 23 Aug 2007 10:37:11 +0200

Thanks, for your comment maxxxpayne:

Actually I did not know that such a templated class already exists. And yes the behaviour of TAutoClose an auto_cleanup<> is much the same.

But there is a major difference between both:
TAutoClose is only usable for R classes which have a void Close(); function - auto_cleanup<> instead is agnostic of this method as long as the cleanupfunction takes no arguments and returns void (most cleanupfunctions fullfill this condition).

A second reason for implementing auto_cleanup<> is that it shows a good example how you can use functors. Yes, there are very few reasons for using functors because M classes are used more often for similar reasons (callback interfaces - observers).

Re: auto_cleanup (an auto_ptr equivalent for R classes)

svdwal — Thu, 23 Aug 2007 09:07:16 +0200

As I am responsible for creating the Symbian C++ auto_ptr<> class, some comments:

auto_ptr<> is meant to make code portable between different C++ implementation while having full protection against resource leaks. Such code isn't likely to have much dependency on specific Symbian C++ constructs (such as the cleanup stack), in fact, these dependencies must be eliminated to make the code portable.

It does mean that you cannot mix explicit use of the cleanupstack and implicit use using auto_ptr<> and auto_cleanup<>. But that isn't a disadvantage. If you want portable code, explicit use of the cleanup stack is out of the question.

Therefore, a NewLC method is not likely to be found in portable code. Portable code will instead have some factory function that returns an auto_ptr<> or auto_cleanup<> variable.

Having to do one's own popping of the cleanup stack means that it is possible to mess this up. You can protect yourself against that by using the CleanupStack::PopAndDestroy() overload that checks whether the passed pointer is the one you would expect. But this is a kludge. With auto_ptr<> and auto_cleanup<> the compiler takes care of destruction, leaving the programmer free to do usefull work. So the programmer becomes more efficient, which is a good thing. This has nothing to do with being lazy. Writing code in such a way certain errors cannot occur is the hallmark of a good programmer.

Sander van der Wal
www.mBrainSoftware.com

Re: auto_cleanup (an auto_ptr equivalent for R classes)

maxxxpayne — Wed, 22 Aug 2007 20:44:10 +0200

Since you have tagged this article for beginners, I believe that you should have discussed TAutoClose also and a comparison of advantage/disadvantage of both approaches.

While not sophisticated as your implementation, it does get the job done, both for auto and member types.

Re: auto_cleanup (an auto_ptr equivalent for R classes)

makom — Wed, 22 Aug 2007 18:26:53 +0200

@pirosl: You are absolutely right:
Using these classes has a runtime overhead because of the additional created objects. You have to evaluate readability and toughness against performance of your code.
Mixing the usage of auto_ptr/auto_cleanup and using the cleanupstack in a conventional way will end in a mess. Thats why you should use auto_ptr/auto_cleanup only if you are familiar with the conventional techniques of the cleanupstack. If this is the case using auto_ptr/auto_cleanup can be very usefull. As the name says these classes should be only used for automatic variables - not for member variables! Exactly like the cleanupstack - this is not used for member variables too.

Re: auto_cleanup (an auto_ptr equivalent for R classes)

pirosl — Wed, 22 Aug 2007 18:05:56 +0200

Very nice article. As a personal opinion, auto_ptr are a very nice feature sometimes (for lazy developers ). It's very convenient to know that your pointer will be destroyed when auto_ptr is out of scope, but besides that there are a lot of drawnbacks.
For example:
- you can't implement NewLC using auto_ptr (or at least not returning a pointer to your object)
- by using CleanupStack::PopAndDestroy() you can check if the poped object is the one you want; you can't do this with auto_ptr
- using auto_ptr implies you create an extra object every time you want to use it (i know it's a small object...but ).....you can have same powerfull behaviour using CleanupStack::PushL(TCleanupItem).....and may be sometime it's worth it.
- a big disadvantage is that CleanupStack is not fully replaceable....eg. you can't have a medium-big project and work only with auto_ptr....so eventually you'll end up mixing auto_ptr with CS

auto_cleanup (an auto_ptr equivalent for R classes)

makom — Wed, 22 Aug 2007 15:47:05 +0200

An implemetation for cleaning up an instance of Symbians typical R classes automatically. As we all know an instance of an R class usually has to be cleaned up via a call to a certain cleanup method (e.g. Close(), Disconnect(), Release() etc.) For implementing the auto_cleanup class which should be agnostic of this cleanup method I have choosen to use a functor class...