Lets say I have two local objects. When the function returns, is it guaranteed which one will go out of the scope first?
For example:
I have a class like this:
class MutexLock
{
/* Automatic unlocking when MutexLock leaves a scope */
public:
MutexLock (Mutex &m) { M.lock(); }
~MutexLock(Mutex &m) { M.unlock(); }
};
This is a very common trick used to automatically release the mutex when going out of scope. But what if I need two mutexes in the scope?
void *func(void *arg)
{
MutexLock m1;
MutexLock m2;
do_work();
} // m1 and m2 will get unlocked here. But in what order? m1 first or m2 first?
This really can't cause any deadlock. But there may be instances in which order of releasing the resource might be useful to the user. In that case is it important to be explicit rather than relying on destructors?
Also, can destruction be delayed by the compiler in any case? What I mean is
func()
{
{
foo f();
} ---------> Can compiler choose to not destroy f here, rather do it at the time when func() is returning.
}
The destruction happens in reverse order of construction: first
m2
thenm1
.Compiler can never delay object's lifetime behind scope end (
}
).The destructors will be called in the reverse order of construction:
m2
thenm1
.The order of destruction is well-specified so that you can rely on it.
No. If it did, that would break a lot of RAII-based code (your
MutexLock
class is a very good example of that).The object is always destroyed when it goes out of scope - this is not java. f Will get destroyed where you indicate and will never be destroyed at the end of func. in general the destructors are called in order reverse to the order of their construction.
In that case is it important to be explicit rather than relying on destructors?
No, it is not required.
The order of destruction of objects in a scope is well defined.
It is exact opposite of the order in which they were constructed.
Also, can destruction be delayed by the compiler in any case?
No.
The compiler cannot and that is the purpose of RAII. It provides the mechanism to implicitly clean & deallocate resources without any explicit manual effort on part of the programmer.
Your requirement of delaying the destruction is parallel to the very purpose of RAII, it calls for manual resource management.
If you need manual resource management you can have pointers allocated on heap through
new
and the objects pointed by them would be valid unless and until, you explicitly deallocate them throughdelete
call and the order in which you call them.Of-course, it is nor advisable nor encouraged to do so.