Re: A subtle access issue (may be advanced :-) )

* Gil:


Thank you.

I think this "be accessible" wording in ?12.4/11, together with corresponding
wording in ?12.5/4 about the accessibility of the *dynamically* chosen
deallocation function, constitutes a double defect in the standard.

Defect (A), the most obvious, is that ?12.5/4 as I see it contains a
self-contradiction, while defect (B) goes to the rationale.

For defect (A), self-contradiction, ?12.5/4 says that "if the delete-expression
is used to deallocate a class whose static type has a virtual destructor, the
deallocation function is the one found by the lookup in the definition of the
dynamic type's virtual destructor. ... If the result of the lookup is ambiguous
or inaccessible ... the program is ill-formed".

If the word "inaccessible" here talks about whether the delete expression itself
has access to the dynamically chosen deallocation function, then any program
doing 'delete p' where p is of static type Base* and the dynamic type of *p is
Derived, where Derived has a protected or private deallocation function, and the
delete expression isn't in a context with access to such things in Derived,
would be ill-formed. Which is clearly not the case. So that interpretation is
not tenable.

On the other hand, if the word "inaccessible" here talks about whether the
dynamic type's destructor has access to the dynamically chosen deallocation
function, then a delete expression would be valid as long as that's the case,
even if the delete expression itself does not have access (for nothing is then
said about that) to the deallocation function of the static type. Which clearly
isn't the case either. So that interpretation is not tenable.

Since neither possible choice of which function it is that needs access yields a
tenable interpretation, perhaps "the lookup" isn't meant to refer to the lookup
described earlier in the paragraph, but rather to a lookup in the static type of *p.

For defect (B), about the rationale of ?12.4/11 (destructor needs access):

(1) nowhere else is static accessibility restricted by what function might be
dynamically selected for invocation,

(2) the restriction apparently serves no useful purpose except as an unnatural
and easily circumvented means of creating a "final" class, and

(3) the restriction disallows at least one useful expression of a restriction on
derived classes, namely restricting use of 'delete this' as in the code I
presented at the start of the thread.

Regarding (1), that this rule is contrary to the spirit of C++, consider the
inconsistency when compared to the situation for destructors:

   class Base { virtual ~Base() {} };

   class Derived
   {
   private:
       virtual ~Derived() {}
   public:
       static Derived* newInstance() { return new Derived(); }
   };

   int main()
   {
       Base* p = Derived::newInstance();
       delete p; // OK, even though no access to dynamically selected destructor.
   }

Why should the delete not be OK just because the dynamically selected destructor
is inaccessible to the delete expression? That would be nonsense. What matters
wrt. accessibility, here and elsewhere in C++, is the static typing.

And so it's IMO also nonsense to have such a requirement for the dynamically
selected deallocation function. Especially considering that what it requires is
not even direct accessibility, but indirect accessibility: that the dynamically
selected deallocation function must be accessible to the dynamically selected
destructor. Of course that indirection is the only way to express something so
absurd as the dynamic choice having to be statically "accessible" in a sense.

Regarding (2), no apparent useful purpose, at least not any very evident one,
what C++ constructs would be permitted if this rule were replaced with plain
static accessibility (as one has everywhere else in C++)?

One could then write such dangerous code (note: irony) as

   class Base1 { virtual ~Base1() {} };

   class Base2
   {
   private:
       void* operator new( size_t size ) { ... }
       void operator delete( void* p ) { ... }
   public:
       virtual ~Base2() {}
       static Base1* newBase1();
   };

   class Derived: public Base1, public Base2
   {}; // AIUI not allowed, has virtual destructor but inaccessible op delete.

   Base1* Base2::newBase1() { return new Derived; }

   int main()
   {
       Base1* p = Base2::newBase1();
       delete p;
   }

The "trouble" here being that the delete dynamically invokes a statically
inaccessible deallocation function, just as -- but of course allowed in
current C++, since it's the normal rule! -- in the first example the delete
dynamically invokes a statically inaccessible destructor function.

Perhaps someone can come up with some purpose that isn't of the sort "be
inconsistent with the rest of C++", but currently I fail to see it.

Regarding (3), that the language's restriction disallows useful expressions of
programmer-selected restrictions on derived classes, the original code in this
thread is an example.

Cheers,

- Alf