Re: destructors moved out of place ?
On Mar 5, 4:13 pm, viki...@gmail.com wrote:
On Mar 5, 4:48 pm, peter koch <peter.koch.lar...@gmail.com> wrote:
On 5 Mar., 15:18, viki...@gmail.com wrote:
On Mar 5, 2:59 pm, Michael DOUBEZ <michael.dou...@free.fr> wrote:
viki...@gmail.com a =E9crit :
I have a question whether compiler can move destructors past
the place when it's normal out-of-scope place is. Is this true ?
Example:
I have a lock/unlock wrapped into the object SafeLock,
where SafeLock::SafeLock() { m_lock.Lock(); }
and SafeLock::~SafeLock() { m_lock.Unlock(); }
void Class::Method(void) {
SafeLock lock; // lock in ctor, unlocks in dtor
......
// (1) lock is automatically unlocked here, ok.
}
So far, so good. The lock is unlocked at point (1), when it goes o=
ut
of scope.
Now let's look at the more complex case, with innner block:
void Class::Method(void) {
......
{ // inner block
SafeLock lock; // (4)
} // (5)
... // (6)
}
Normally, lock(4) is destroyed at (5).
But I was told this is not necessarily so;
that C++ compiler is free to delay destruction of lock
until later, until end of bigger bklock at (6).
Is this true ? Is it indeed allowd ? I have difficulty
to believe that standard allows this. Indeed,
destructors can have side effects like closing files.
The compiler could delay the destruction of the object
if the overall behavior is the same (as you said, if
there is no side effect).
You are right, the lock is unlocked at (5).
Is it possible to have standard reference that
explicitly prohibits this "optimization" ?
The relevant parts are =A712.4-10:
Destructors are invoked implicitely [...] for a
constructed object with automatic storage duration
(3.7.2) when the block in which the object exits [...]
And =A73.7.2-3:
If a named object has initialization or a destructor with side effec=
ts,
it shall not be destroyed before the end of its block
^^^^^^
Hmmm stange wording. It says "not before".
"Shall not be destroyed before end of its block".
But it does not say "not after".
Well, I believe the standard is quite clear - and all was quoted by
Michael:
Destructors are invoked implicitely [...] for a
constructed object with automatic storage duration
(3.7.2) when the block in which the object exits [...]
and:
If a named object has initialization or a destructor
with side effects, it shall not be destroyed before the
end of its block
so it must not be destroyed before ever - not even if it looks as it
is unused.
So as Michael said, it is destroyed at exactly the point where the
scope ends.
So the destructor is implicitly invoked when the block exits.
Shall we interpreted it as permission to invoke the
destructor with side effects *after* end of the block ?
What good would be this for ?
I can see situations where this could be bad.
, nor shall it be eliminated as an optimization even if
it appears to be unused, except that a class object or
its copy may be eliminated as specified in 12.8.
So the destructor is implicitly invoked when the block
exits.
I do not see what you see. Optimizers are known to shuffle pieces of
code around.
People *observed* the destructors to be invoked at the end and
*bigger* block because optimizer moved it and supposedly
because standard does not disabllow it such optimizations
*especially* for no-side-effects destructor.
I do not mind optimizer shuffling around the no-side-effect
destructors (provided that behaviour is preserved).
For side-effects destructor, Michael showed that standard
disallows moving the destructor invocation to *earlier* point.
Which is really an unnecessary clarification---the standard
defines precisely at what point the destructor should be called.
A compiler is only allowed to change it if it can prove that the
observable effects of the program are not modified.
The reason the words are there is because it is a common
optimization to detect and remove dead variables, i.e. variables
that are no longer "used". The standard here is making it clear
that if the variable has a non-trivial destructor, the compiler
must consider that it is "used" until its normal place of
destruction, even if there is no visible evidence of "use".
To me, that looks like permission for the optimizer to move
destructor invocation to the later point, for side-effects
dtors, and
(2) to move the no-side-effects dtors invocation forward or
backward (conditioned that it preserves results and behaviour,
of course).
No. The sentence which is bothering you is there for authors of
optimizers, to remind them that "use", here, has a special
meaning in the case of objects with non-trivial destructors,
which must be taken into account in dead variable analysis.
(Don't forget that many of the authors of the standard are
compiler writers, who tend to think in these terms.)
Technically, it neither gives nor takes away any liberty that
wasn't there otherwise. The standard states exactly when the
destructor is called. The abstract machine which the standard
uses to define the semantics of a program always calls it at
exactly that place. A conformant implementation must ensure
that the observable behavior of the compiled program is
identical with the observable behavior which would result in
calling it at that place.
(The standard doesn't say anything with regards to locking and
unlocking mutexes, of course, but that is presumably "observable
behavior". Even if there's really no way a program can
tell---the fact that another thread can acquire the lock
immediately after it is released doesn't guarantee that it will
actually behave as if it did, and interrupt the thread which
released it.)
I *do not* see where standard disallows the optimizer to move
the side-effect destructor to later point. Where do you see
this ?
The basic definition of the semantics of a program, which
Michael also quoted.
And given that people observed that optimizer moved destructor
invocation to the end of *bigger* block,
Who, when and with what compiler?
my question still remains, is this standard conformant, and
does it make the diffence whether dtor has side effects or not
wrt standard conformance ?
The standard has something called the "as if" rule: the compiler
can do absolutely anything it wants, as long as the observable
behavior is identical to what one instance of the abstract
machine would have created, i.e. as long as it behaves "as if"
it had conformed to the exact semantics of the abstract machine.
It could thus move a destructor, or eliminate it entirely, if it
could prove that its side effects do not affect the "observable
behavior". (Note that the "observable behavior" is basically
only the order of external function calls---basically system
calls, except, of course, a C++ program doesn't see those---and
accesses to volatile objects. Time is never considered
"observable", so the fact that the program runs faster---or
slower---need not be considered with regards to correctness.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34