Re: A subtle access issue (may be advanced :-) )
On Aug 29, 9:11 am, "Alf P. Steinbach" <al...@start.no> wrote:
The following code compiles as-is with g++ and Comeau Online,
but not when then the commented lines are uncommented:
<code>
#include <stddef.h>
template< class T > T* create();
class Base
{
template< class T > friend T* create();
private:
static void* operator new( size_t size )
{
return ::operator new( size );
}
// static void operator delete( void* p )
// {
// ::operator delete( p );
// }
protected:
virtual ~Base() {}
};
class Derived
: public Base
{
public:
Derived() {}
virtual ~Derived() {}
};
template< class T >
T* create() { return new T; }
int main()
{
create<Derived>();
}
</code>
With uncommenting the commented code both compilers complain
that the Derived destructor can't access Base::operator
delete.
Correctly (more or less). There are two potential problems, the
first I'm certain of, the second less so:
The first is simple: anytime you have a new expression, the
compiler must be able to access operator delete at the point of
the new expression, since if the constructor exits by an
exception, the corresponding delete will be called. (I.e. if it
is a placement new, placement delete will be called.)
The second is a bit more subtle, and I'm not too sure what the
standard says (and I'm not sure where it says it, and am too
lazy to spend a quarter of an hour or more looking for it in all
of the possible places), but one frequent implementation of
destructors implies passing a hidden argument stating whether
operator delete should be called or not from the destructor.
The reason for this is that the correct operator delete is the
one which is correct for the most derived class, and the
compiler can't know which one this is in the delete expression;
some derived class may have provided its class specific delete.
I seem to recall, vaguely, that the standard endorses this
solution by requiring access control on operator delete in the
destructor---but as I said, I'm not sure, and I have even less
of an idea where to look in the standard to find it.
They don't complain that the Derived constructor can't access
Base::operator new.
Because the Derived constructor doesn't need to access operator
new. At the construction site, the final class is known to the
compiler.
I can understand the lack of complaint for the constructor:
the constructor doesn't need to access the allocation
function, which is invoked by the new expression which is in
the context of the create function which has access.
I don't understand the complaint for the destructor. The new
expression has to potentially deallocate, if an expression is
thrown. But it manages well to use the allocation function, so
why can't it also use the deallocation function?
In short, why this different treatment?
In short: history and implementation techniques.
It almost seems as if the standard supports an implementation
technique where the call to the deallocation function is made
directly from *within* the most derived class' destructor?
More than "seems". Historically, at least, and maybe still,
that's by far the most frequent implementation technique.
The reason is simple: when I write "new Something", the compiler
knows the most derived class (Something). When I write "delete
pointer", however, the compiler doesn't know, so it has to call
the (virtual) destructor to find out. Other implementation
techniques are possible, but I can't really figure out one which
would correctly implement the access controls, e.g. reject the
delete (at compile time) if the dynamic type of the pointed to
object had a private operator delete.
--
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