[K42-discussion] virtual destructors
Maria Butrico
butrico at us.ibm.com
Tue Jul 11 07:36:56 EST 2006
It is not clear to me that anyone is actually invoking this method. We
could define such method to panic, to catch any actual invocations.
Also Donour told us that he needed to add a destructor becuase
"C++ requires that classes with virtual methods define a virtual
destructor. Older versions of gcc allow you to get away without it, but
gcc4 enforces it."
and that he added one such to the VAllocServices class.
Maria Butrico <internet or sametime: butrico at us.ibm.com; Notes:
Maria Butrico/Watson/IBM>
Bryan S
Rosenburg/Watson/
IBM at IBMUS To
Sent by: Discussion about K42
k42-discussion-bo <k42-discussion at ozlabs.org>
unces+butrico=us. cc
ibm.com at ozlabs.or
g Subject
Re: [K42-discussion] virtual
destructors
07/10/2006 05:27
PM
Please respond to
Discussion about
K42
<k42-discussion at o
zlabs.org>
We shouldn't be calling delete on any class that doesn't use the DEFINE_NEW
machinery. Can you tell what actual delete is causing the undefined
symbol? We can't do a generic delete operator. We depend on knowing the
size of the storage block independent of the storage itself.
- Bryan
Donour Sizemore <donour at cs.unm.edu>
Sent by:
k42-discussion-bounces+rosnbrg=us.ibm. To
com at ozlabs.org Discussion about K42
<k42-discussion at ozlabs.o
rg>
07/10/2006 11:50 AM cc
Subject
Please respond to Re: [K42-discussion]
Discussion about K42 virtual destructors
<k42-discussion at ozlabs.org>
Ok. There are a variety of ways to define operator delete(void*) that
will build and pass regress. My next question is which is the
appropriate for the k42. The std library definition of operator delete
looks something like this.
void operator delete(void *ptr){
if (ptr)
free(ptr);
}
The problem is there isn't a generic free that I can use throught k42.
Rather, I need to know the allocation object used to know which free
function to use. For classes that don't use the NEW primitives
(DEFINE_NEW), this is a problem. Should these classes just have their
own operator delete inline?
donour
Maria Butrico wrote:
> The class VAllocServices does not use the NEW primitives and that might
be
> part of why your fix did not work.
>
> Maria Butrico <internet or sametime: butrico at us.ibm.com; Notes:
> Maria Butrico/Watson/IBM>
>
>
>
>
> Donour Sizemore
> <donour at cs.unm.ed
> u>
To
> Sent by: Discussion about K42
> k42-discussion-bo <k42-discussion at ozlabs.org>
> unces+butrico=us.
cc
> ibm.com at ozlabs.or
> g
Subject
> Re: [K42-discussion] virtual
> destructors
> 07/07/2006 01:41
> PM
>
>
> Please respond to
> Discussion about
> K42
> <k42-discussion at o
> zlabs.org>
>
>
>
>
>
>
> Patrick G. Bridges wrote:
>
>> On Jul 6, 2006, at 4:49 PM, Andrew Baumann wrote:
>>
>>
>>
>>> On Friday 07 July 2006 06:15, Donour Sizemore wrote:
>>>
>>>
>>>> When compiling the above example, a strange symbol is being
>>>> referenced
>>>> (_ZdlPv) but isn't defined and I can't figure out what it is or
>>>> where it
>>>> comes from. It doesn't appear to be a mangled version of anything I
>>>> recognize. Does anybody have an idea what could be happening here?
>>>>
>>>>
>>> Actually, it is something mangled:
>>>
>>> $ c++filt _ZdlPv
>>> operator delete(void*)
>>>
>>> Googling for _ZdlPv is informative... apparently a call to this
>>> symbol is
>>> emitted when you do a delete(void *), and it should be part of the
>>> standard
>>> libraries.
>>>
>>> Andrew [still learning something new about C++ every day]
>>>
>>>
>> The DEFINE_NEW macro in AllocPool.C looks like it only defines
>> operator delete(void *, uval size), note operator delete(void *). Is
>> simply adding this operator the appropriate solution, or is something
>> more general needed?
>>
>>
> That doesn't appear to work in this case. More specifically, even adding
> an operator delete(void*) to that macro, the symbol still doesn't get
> defined.
>
> donour
> _______________________________________________
> K42-discussion mailing list
> K42-discussion at ozlabs.org
> https://ozlabs.org/mailman/listinfo/k42-discussion
>
>
> _______________________________________________
> K42-discussion mailing list
> K42-discussion at ozlabs.org
> https://ozlabs.org/mailman/listinfo/k42-discussion
>
_______________________________________________
K42-discussion mailing list
K42-discussion at ozlabs.org
https://ozlabs.org/mailman/listinfo/k42-discussion
_______________________________________________
K42-discussion mailing list
K42-discussion at ozlabs.org
https://ozlabs.org/mailman/listinfo/k42-discussion
More information about the K42-discussion
mailing list