Ralf Wildenhues wrote:
* Daniel Herring wrote on Mon, Nov 12, 2007 at 07:46:55AM CET:
Here's a relevant post from the GCC list; it mentions how to work around
some dlopen difficulties (including RTTI, exceptions, custom new/delete).
http://gcc.gnu.org/ml/gcc-help/2007-10/msg00248.html
Ralf Wildenhues wrote:
> * Daniel Herring wrote on Mon, Nov 12, 2007 at 07:46:55AM CET:
>>
>> Here's a relevant post from the GCC list; it mentions how to work around
>> some dlopen difficulties (including RTTI, exceptions, custom
>> new/delete).
>> http://gcc.gnu.org/ml/gcc-help/2007-10/msg00248.h
* Daniel Herring wrote on Mon, Nov 12, 2007 at 07:46:55AM CET:
>
> Here's a relevant post from the GCC list; it mentions how to work around
> some dlopen difficulties (including RTTI, exceptions, custom new/delete).
> http://gcc.gnu.org/ml/gcc-help/2007-10/msg00248.html
Thanks for this link. FWI
On Mon, 12 Nov 2007, Brendon Costa wrote:
I can see the call of the destructor method working correctly in all
cases. As you said it is just a virtual function call. However i was
wondering if the memory de-allocation is performed by the child or the
caller.
In general, memory management done b
Bob Friesenhahn wrote:
> On Mon, 12 Nov 2007, Brendon Costa wrote:
>>
>> * As for exceptions, I have defined all the methods for the plugins
>> interface as throw() so exceptions may occur inside the plguin but may
>> not propagate from the plugin to the application. I honestly dont know
>> if exce
If the vtable is functioning for normal virtual functions, why wouldn't it
also work for a virtual destructor? Destructors are not magic; they are
merely functions that get called just before memory is released. RTTI, a
common culprit in dlopen issues, doesn't get involved here.
Right. A mo
On Mon, 12 Nov 2007, Brendon Costa wrote:
* As for exceptions, I have defined all the methods for the plugins
interface as throw() so exceptions may occur inside the plguin but may
not propagate from the plugin to the application. I honestly dont know
if exceptions occurring only within the plug
Bob Friesenhahn wrote:
> On Sun, 11 Nov 2007, Daniel Herring wrote:
>>
>> If the vtable is functioning for normal virtual functions, why
>> wouldn't it also work for a virtual destructor? Destructors are not
>> magic; they are merely functions that get called just before memory is
>> released. RT
> If the vtable is functioning for normal virtual functions, why wouldn't
> it also work for a virtual destructor? Destructors are not magic; they
> are merely functions that get called just before memory is released.
> RTTI, a common culprit in dlopen issues, doesn't get involved here.
>
I can
On Sun, 11 Nov 2007, Daniel Herring wrote:
If the vtable is functioning for normal virtual functions, why wouldn't it
also work for a virtual destructor? Destructors are not magic; they are
merely functions that get called just before memory is released. RTTI, a
common culprit in dlopen iss
On Sun, 11 Nov 2007, Ralf Wildenhues - [EMAIL PROTECTED] wrote:
* Brendon Costa wrote on Fri, Nov 09, 2007 at 03:20:27AM CET:
Is using virtual destructors fine with a C++ plugin interface?
Good question.
If the vtable is functioning for normal virtual functions, why wouldn't it
also work f
Ralf Wildenhues wrote:
> Hello Brendon,
>
> Means you've got it to work with which set of compilers on what list of
> systems?
Just GCC 4 on Linux. I haven't tried any others yet.
> I don't know either. But if it helps you, we can put your example in
> the Libtool HEAD testsuite, to get some t
Hello Brendon,
* Brendon Costa wrote on Fri, Nov 09, 2007 at 03:20:27AM CET:
>
> Is using virtual destructors fine with a C++ plugin interface?
Good question.
> I have an example below that works.
Means you've got it to work with which set of compilers on what list of
systems?
> However i am
13 matches
Mail list logo
