Bug 11339 - cannot instantiate class derived from base with public virtual destructor and private operator delete
Summary: cannot instantiate class derived from base with public virtual destructor and...
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.2.3
: P2 normal
Target Milestone: 3.4.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-06-26 21:29 UTC by Paul Brannan
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Brannan 2003-06-26 21:29:28 UTC
[pbrannan@zaphod tmp]$ cat test.cpp
class Foo
{
public:
  virtual ~Foo() { }

private:
  static void operator delete(void *) { }
};

class Bar
  : public Foo
{
};

int main()
{
  Bar b;
}

I can compile the above code on comeau, but not on g++.  I'm not sure which
compiler is correct.

[pbrannan@zaphod tmp]$ g++ test.cpp
test.cpp: In destructor `virtual Bar::~Bar()':
test.cpp:7: `static void Foo::operator delete(void*)' is private
test.cpp:17: within this context

[pbrannan@zaphod tmp]$ como test.cpp
Comeau C/C++ 4.3.0.1 (Aug 15 2002 09:47:16) for RedHat_LINUX_INTEL_ELF
Copyright 1988-2002 Comeau Computing.  All rights reserved.
MODE:non-strict warnings C++
Comment 1 Wolfgang Bangerth 2003-06-26 22:15:06 UTC
gcc is right. Section 5.3.4/16 states
  ...access control [is] done for the allocation function, the deallocation
  function (here: operator delete), and the cnostructor. [...]

W.
Comment 2 Paul Brannan 2003-06-27 13:42:52 UTC
5.3.4/16 specifically refers to objects created with new.  In this example, b is
created on the stack.
Comment 3 Wolfgang Bangerth 2003-06-27 14:31:17 UTC
Stupid me, indeed. I saw operator delete and looked up operator new. Sorry.
Will have to investigate again.

W.
Comment 4 Wolfgang Bangerth 2003-06-30 14:06:58 UTC
Volker Reichelt kindly did the work for me and notified me of clause
12.4/11 of the standard, which reads
  At the point of definition of a virtual destructor, non-placement
  operator delete shall be looked up in the scope of the destructor's
  class, and if found shall be accessible and unambiguous.

This is not the case in your example, so gcc is right to reject it.

W.