RE: Why is this C++ code incorrect?

["Jiutao Nie" <njt at mprc dot pku dot edu dot cn>]

The 5.3.4 para 16 is also important.

16 If the newexpression creates an object or an array of objects of class
type,
      access and ambiguity control are done for the allocation function, the
      deallocation function (12.5), and the constructor (12.1). If the new
expression
      creates an array of objects of class type, access and ambiguity
control are
      done for the destructor (12.4). 

According to it, when calling new operator for a class, access and ambiguity
control should also be done for the delete operator.  This is because when
the class's constructor failed by throwing an exception, the delete must be
called to free the memory.  I dumped the generic tree generated by g++ and
found that when using a original base class, there is no try-catch generated
for the trivial constructor of B, so no delete calling are generated, while
for virtual base class, the implicit constructor of B is not trivial, so the
try-catch and delete calling are generated and the access control is also
done for it.  It seems that the essential problem is whether the constructor
is trivial rather than whether it has a virtual base class.  However, I
don't know whether the passing of compilation for original base class
violates the standard.


-----Original Message-----
From: jimblandy@gmail.com [mailto:jimblandy@gmail.com] On Behalf Of Jim
Blandy
Sent: Wednesday, December 21, 2005 1:25 AM
To: Nathan Sidwell
Cc: Jiutao Nie; gcc@gcc.gnu.org
Subject: Re: Why is this C++ code incorrect?

On 12/20/05, Nathan Sidwell <nathan@codesourcery.com> wrote:
> >   Compiling the following code with g++ will report error:`static 
> > void A::operator delete(void*)' is protected.  It's correct If B is 
> > derived from A without "virtual".  Why does the "new B" expression 
> > need to check the delete operator's accessibility when B is virutally
derived from A?
>
> 5.3.4 paras 8, 17 and 18 say so.

I don't see how the below is affected by the use of a virtual base class,
rather than an ordinary base class.

8 A new-expression obtains storage for the object by calling an
  allocation function (3.7.3.1). If the new- expression terminates by
  throwing an exception, it may release storage by calling a
  deallocation function (3.7.3.2). If the allocated type is a
  non-array type, the allocation function's name is operator new and
  the deallocation function's name is operator delete. If the
  allocated type is an array type, the alloca- tion function's name
  is operator new[] and the deallocation function's name is operator
  delete[]. [Note: an implementation shall provide default definitions
  for the global alloca- tion functions (3.7.3, 18.4.1.1, 18.4.1.2). A
  C++ program can provide alternative definitions of these func- tions
  (17.4.3.4) and/or class-specific versions (12.5). ] ...
17 If any part of the object initialization described above71)
   terminates by throwing an exception and a suitable deallocation
   function can be found, the deallocation function is called to free
   the memory in which the object was being constructed, after which
   the exception continues to propagate in the context of the new-
   expression. If no unambiguous matching deallocation function can be
   found, propagating the exception does not cause the object's
   memory to be freed. [Note: This is appropriate when the called
   allocation func- tion does not allocate memory; otherwise, it is
   likely to result in a memory leak. ]

18 If the new-expression begins with a unary :: operator, the
   deallocation function's name is looked up in the global
   scope. Otherwise, if the allocated type is a class type T or an
   array thereof, the deallocation function's name is looked up in
   the scope of T. If this lookup fails to find the name, or if the
   allocated type is not a class type or array thereof, the
   deallocation function's name is looked up in the global scope.