Eric Lemings wrote:
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2008 3:32 PM
To: [email protected]
Subject: Re: [STDCXX-709] ContainerData ctor and
UserClass::from_char()
...
So you think there's a mismatch between the allocation function
invoked in value.cpp and the deallocation function called in the
header? Why would that be? IIUC, tests that replace operator new
and operator delete (such as 23.list.assign) replace it for the
whole process. If there's a mismatch, it can only be because
the operators aren't replaced consistently. Making sure this
replacement happens across the whole process, including any
libraries, is the responsibility of the C++ runtime (i.e.,
the compiler). If your analysis is correct, the C++ runtime
on IPF would have to be buggy.
Or did I misunderstand what you were trying to say?
Sounds about right.
I just noticed there's a runtime link error in the config test
OPERATOR_NEW_ARRAY_PLACEMENT on HP-UX IPF platforms. May be the
culprit.
[EMAIL PROTECTED] ./include/OPERATOR_NEW_ARRAY_PLACEMENT
/usr/lib/hpux32/dld.so: Unsatisfied code symbol '_ZnamPv' in load
module './stdcxx/include/OPERATOR_NEW_ARRAY_PLACEMENT'.
Killed
That's a check for placement new in the runtime library. I don't
think that has any bearing on the replaceability of operator new.
I.e., the first one is not replaceable:
void* operator new(size_t, void*) throw();
void* operator new[](size_t, void*) throw();
while the second one is:
void* operator(size_t) throw (bad_alloc);
void* operator[](size_t) throw (bad_alloc);
The first form is usually defined inline in <new>, like so:
inline void* operator new(size_t, void *ptr) throw() {
return ptr;
}
and so it's not defined in the runtime library. That's why I assume
the OPERATOR_NEW_ARRAY_PLACEMENT test fails: it declares the operator
and calls it without providing a definition to see if one exists in
the runtime. Unless the test finds one we need to provide our own
definition in our <new>. Otherwise we just declare it.
Martin
