Shared objects and virtual functions

  • Thread starter david.sanderson
  • Start date
D

david.sanderson

Hi,
Hopefully this is thecorrect group, its a bit C++ and a bit POSIX...

Ive had a look in the archives, and Im a bit confused....

I have some classes in a shared library (a .so on a QNX system) which I
want to instantiate into shared memory so that 2 processes can both
operate on the same data. The classes have a quite derived ineritance
tree (not sure if this is the correct term) where I have several
classes derived from a base class. The problem I think ill have is that
the base class has virtual functions istypeA() istypeB() etc all return
false in the base class and return true in the derived classes which
only implement the appropriate one. This allows easy determination of
type from a base class ptr. There are also other virtual functions but
its late and I cant remember what for. Some classes have ptrs to other
ones, which I think I can fix either by having 2 ptrs one for each
process, or by using physical addresses in the ptrs.
I understand that the vtable (this only contains virtual funcs right?)
will be process memory map specific, and if the objects dont get mmaped
into the same location then the second ones will not work, probably in
'interesting ways' I come from a c / asm background, where this sort
of dynamic problem doenst occur (well, i havent come accross it)
Can anyone sugest a way around this? I cannot guarentee the virtual
addresses will be the same, though its likely. is it possible to
'fiddle' with the vtable in an elegant way?
Or a way to get rid of the virtual funcs but still allow the baseptr
determination (implement each function in all the derived classes?)
I could (from memory) create a set of data only classes and some
accessor classes, but this is a port of a legacy system, so Id like to
avoid changing it *to* much if possible. (and Im not entirely sure how
to do this either...)

The design is not yet set, so suggestions / comments appreciated.

thanks

Dave
 
B

Bart

Hi,
Hopefully this is thecorrect group, its a bit C++ and a bit POSIX...

It's mostly off-topic here, but see below for a C++ solution.
Ive had a look in the archives, and Im a bit confused....

I have some classes in a shared library (a .so on a QNX system) which I
want to instantiate into shared memory so that 2 processes can both
operate on the same data. The classes have a quite derived ineritance
tree (not sure if this is the correct term) where I have several
classes derived from a base class. The problem I think ill have is that
the base class has virtual functions istypeA() istypeB() etc all return
false in the base class and return true in the derived classes which
only implement the appropriate one. This allows easy determination of
type from a base class ptr. There are also other virtual functions but
its late and I cant remember what for. Some classes have ptrs to other
ones, which I think I can fix either by having 2 ptrs one for each
process, or by using physical addresses in the ptrs.
I understand that the vtable (this only contains virtual funcs right?)
will be process memory map specific, and if the objects dont get mmaped
into the same location then the second ones will not work, probably in
'interesting ways' I come from a c / asm background, where this sort
of dynamic problem doenst occur (well, i havent come accross it)
Can anyone sugest a way around this? I cannot guarentee the virtual
addresses will be the same, though its likely. is it possible to
'fiddle' with the vtable in an elegant way?
Or a way to get rid of the virtual funcs but still allow the baseptr
determination (implement each function in all the derived classes?)
I could (from memory) create a set of data only classes and some
accessor classes, but this is a port of a legacy system, so Id like to
avoid changing it *to* much if possible. (and Im not entirely sure how
to do this either...)

You don't need any ugly hacks. The C++ language has a typeid operator
to determine types dynamically. You may need to use a compiler switch
to enable RTTI. Check the compiler manual.

Regards,
Bart.
 
D

david.sanderson

Bart said:
It's mostly off-topic here, but see below for a C++ solution.


You don't need any ugly hacks. The C++ language has a typeid operator
to determine types dynamically. You may need to use a compiler switch
to enable RTTI. Check the compiler manual.

Regards,
Bart.

Thanks, I didnt know about that, and its used in other places already
(I wonder how much attention the original coder was paying from day to
day...)
I think I can work around most of the virtuals using this. I have to do
some ugly 'not inherited - call the correct derived one' code to remove
the rest, but the legacy system part of this hasnt changed in years, so
the loss of OO approach is probably no problem for this small subset
and the amount of other work it would save.

Dave
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,431
Messages
2,571,679
Members
48,796
Latest member
Greg L.

Latest Threads

Top