Re: When is a destructor "used"?
On Mar 27, 9:23 am, Greg Herlihy <gre...@pacbell.net> wrote:
On 3/26/07 8:05 PM, in article
1174953024.263063.243...@p15g2000hsd.googlegroups.com, "Andrew J. Bromage"
<degue...@gmail.com> wrote:
On Mar 26, 7:50 pm, "James Kanze" <james.ka...@gmail.com> wrote:
I don't think that the standard actually addresses this issue.
Obviously, the destructor must be instantiated at some point,
since it will be called by the destructor of Bar.
Sure, but because Container is a template, it's instantiated lazily.
Container's destructor must be instantiated when Bar's destructor is
compiled - so one way or the other Container's destructor is certain to be
instantiated.
Not necessarily. The code snippet he posted never defined Bar's
destructor, so it won't trigger the instantiation of Container's
destructor for this reason. (Presumably, Bar's destructor is
defined in some other translation unit; although the standard
doesn't require it to be defined, not defining it definitly
limits what you can do with a Bar.)
The real
question is: if a compiler can determine that a given function
or block of code cannot throw, is it permitted to not require a
definition of code that would only be executed if it did throw?
The real question is slightly more subtle than that.
It's unreasonable to require a C++ compiler to examine how a
member is implemented in order to work out whether or not some
other member of some other class is correct or not. That falls
squarely in the realm of "optimisation".
But there is no issue of "correctness" being raised by this program - there
is nothing that could be at all incorrect with Bar's constructor.
Bar's constructor is correct. Bar's constructor, however,
implicitly calls Container's constructor, and thus triggers its
instantiation. The whole question turns around whether Bar's
constructor also implicitly calls Container's destructor, or
whether the exception specifications means that this implicit
call isn't necessary (or perhaps even allowed).
It would be interesting to consider the case where there is only
one instance of Container<Foo> in the class. Presumably, if
Andrew added the second in his example, it is because everything
compiled correctly with only one: all of the compilers detected
that there was no possible exception in Bar once the constructor
of Container had returned. His question hinges on whether the
compiler can or is required to take into consideration the
exception specification on Container's constructor to deduce
that no exception can occur after the first constructor has
finished, so there will never be a need to destruct foo1.
Besides, in this situation it would be incorrect. If the
constructor of Container were not declared as throw-none, then
the compiler couldn't guarantee that the constructor would
never throw. (A specialisation might throw, for example.)
Exception specifications never prevent a function from throwing any kind of
exception that it wants to. A throw exception prevents exceptions from being
caught - it does not prevent them from being thrown.
It prevents returning from the function by means of an
exception, which is the problem here.
Specifically, if a
function lets an exception that is not allowed by the its exception
specification propagate past its scope, then the program essentially
terminates - thereby preventing any handler in any calling function from
being able to catch the thrown exception.
And also preventing stack walkback, and the destruction of the
fully constructed subobjects.
However, in the case presented here, a compiler can determine
that the constructor of Bar will not throw from the types alone.
The standard states (I forget precisely where) that all
specialisations of Container are constrained to also have their
constructors be throw-none, though I don't recall whether or not
the compiler is required to check this. Most likely not.
Bar's constructor can be declared without or without a throw() specification
regardless of how Container's constructor is declared.
But that's not the issue here. The issue is whether the
compiler can, or is required to know that the constructor for
the foo2 subobject cannot trigger stack walkback, and thus
require the calling the destructor of foo1.
--
James Kanze (GABI Software) mailto: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! ]