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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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.