What does the error "non-placement deallocation function"?

I am getting the following error while compiling the serna-free package:

build/buildd-serna-free_4.3.0.20110221-2-i386-pAsDoD/serna-free-4.3.0.20110221/
  sfworks/common/RefCntStorage.h:76:10:
error: non-placement deallocation function 'static void
StringPrivate::RefCntData<E>::operator
delete(void*,StringPrivate::size_type) [with E = QChar,
StringPrivate::size_type = unsigned int]'
/build/buildd-ser开发者_如何学Pythonna-free_4.3.0.20110221-2-i386-pAsDoD/serna-free-4.3.0.20110221/
   sfworks/common/RefCntStorage.h:135:9:
error: selected for placement delete

Code looks like:

void operator delete(void* p, size_type)
{
    ::operator delete(p);
}

---

I think that the problem comes from this wording in the spec:

If class T does not declare such an operator delete but does declare a member deallocation function named operator delete with exactly two parameters, the second of which has type std::size_t (18.1), then this function is a usual deallocation function

This would mean that if you tried to declare a pair operator new and operator delete that took a size_t as the second parameter, the compiler would think that your operator delete with this signature:

void operator delete (void* memory, size_t arg)

was the standard (non-placement) deallocator rather than the placement deallocator that's supposed to match operator new(void*, size_t).

What's odd about this is that nowhere in the spec does it say that this should cause a compiler error. In fact, the spec just says that if you have this error, then if the custom new throws an exception then the memory just won't get cleaned up. If anyone knows why g++ is reporting this as an error, I'd love to know why (especially if I'm wrong and this really is supposed to be illegal).

EDIT: Ah! The problem seems to be from C++0x. According to the most recent draft of the new standard, §3.5.4/20:

If the lookup finds the two-parameter form of a usual deallocation function (3.7.4.2) and that function, considered as a placement deallocation function, would have been selected as a match for the allocation function, the program is ill-formed.

It specifically lists doing this as an example of what would cause the breakage. The fact that this is new in C++0x would explain why the error only started popping up in the newest version of g++.

---

It looks like the class was missing the single parameter non-placement delete operator. As can be seen on:

http://oorexx.svn.sourceforge.net/viewvc/oorexx/main/trunk/interpreter/memory/RexxMemory.hpp?r1=6219&r2=6218&pathrev=6219

and in more details in the bug report:

http://sourceforge.net/tracker/?func=detail&aid=2991134&group_id=119701&atid=684730

C++ PATCH for c++/34158 (template placement delete)

• From: Jason Merrill
• To: gcc-patches List
• Date: Tue, 10 Nov 2009 13:31:17 -0500

• Subject: C++ PATCH for c++/34158 (template placement delete)

• /* "If the lookup finds the two-parameter form of a usual deallocation

• function (3.7.4.2) and that function, considered as a placement
• deallocation function, would have been selected as a match for the
• allocation function, the program is ill-formed." */
• if (non_placement_deallocation_fn_p (fn))
• {
• error ("non-placement deallocation function %q+D", fn);
• error ("selected for placement delete");
• }