In article <19950417.181833.843814.NETNEWS@UICVM.UIC.EDU>,
dhanley@matisse.eecs.uic.edu says...
>
>        We've got an application that write objects to disk and reads
>them back off in a generic fashion, as binary images..  It works great
>so far, but there is a problem when we use virtual objects.
>
>        If we write and read them during one program run, everything
>works great.  However, is we do this during multiple program runs, the
>vtable is not guaranteed to be in the same place.  How might it be
>possible to fix up the vtable?
>

>       One possibility that I've considered would be to, after
>reading the object in, to use the placement suntax for new to call a
>dummy constructor which would do nothing to the data members.. Bit it
>would, of course, fill in the vtable entry as part of the construction
>syntax.
[...]

It seems to me that this is a major problem within C++, when dealing with
multiple processes.

Imagine for example some objects, which shall be transferred from process A to
process B using a shared memory mechanism. This works fine as long as the objects
do not include any virtual functions or other compiler generated "semiconstant"
information (RTTI comes to mind here). It also works, if process B doesn't use any
of this information. Otherwise it will fail miserably and may produce a very
strange behavour of the program (If you're lucky you will get a core dump/GPF
:-)).

The real problem with these kind of errors is that they may be quite hard to track
down because there may be hardly any hint within the source code.
For example:

[base.h]
class B
{
    virtual int f();
};


[derived.h]
class D : public B
{
    int f();
};

        We've got an application that write objects to disk and reads
them back off in a generic fashion, as binary images..  It works great
so far, but there is a problem when we use virtual objects.

        If we write and read them during one program run, everything
works great.  However, is we do this during multiple program runs, the
vtable is not guaranteed to be in the same place.  How might it be
possible to fix up the vtable?

        One possibility that I've considered would be to, after
reading the object in, to use the placement suntax for new to call a
dummy constructor which would do nothing to the data members.. Bit it
would, of course, fill in the vtable entry as part of the construction
syntax.

        Other portable possibilities--such as using the new casting
operators and the like--would be greatly appreciated.

--
------------------------------------------------------------------------------
| David James Hanley, KSC--dhanley@lac.eecs.uic.edu -- C++, OOD, martial arts|
| Laboratory for advanced computing      |      My employer barely KNOWS me. |
------------------------------------------------------------------------------
Join the C.C.C:

Campus
Crusade for
Cthulu!