Re: A subtle access issue (may be advanced :-) )
* James Kanze:
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).
As you write further down, you don't *know* that.
And neither do I. :-)
But one might suspect that the destructor needing access is correct wrt. to the
standard, and that the standard therefore ideally should be corrected, for
access has nothing to do with machine code.
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.)
Yes, since I explained that further down in the (very short) original article, I
know that.
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.
Yes, I explained also this further down in the (very short) original article.
The issue is, however, why the heck *access* should be affected.
Given that the code compiles fine with at least one common compiler it's not a
problem for the compiler to generate machine code to do what the (uncommented)
code expresses, and then the access rules should ideally be unaffected by the
implementation detail of how exactly things are done at the machine code level.
For access isn't about machine code.
It's about logical access.
Cheers & thanks (but didn't help, and I think standard's probably screwed up),
- Alf