>
> > > "Alan Ellis" <alan@xxxxxxxxxxxxxx> wrote:
> > > [keeping the mangled symbol]
> > > > yep.
> > > >
> > > > you will need to keep the mangled symbol in the lib, but not
> > > > export
> > > > it
> > > > from the header.
> > >
> > > Why is that=3F Does really anyone refers to that symbol in real
> > > life=
> > > 3F
> >
> > I'm wildly speculating, but I could imagine, that a subclass fills
> > in
> > the private base class slots of its vtable with pointers to the
> > actual
> > (private) functions defined in the base class. If that was so, it
> > would
> > also mean, that a virtual function that was formerly just a
> > reserved
> > slot won't work in apps compiled with the old version of the
> > headers.
> > Something to be investigated.
>
> It seems that exactly that happens. That means, we need to be
> extremely
> carefully.
To continue my monologue: It's not as bad as one might think. The dummy
function simply needs to be defined with all parameters the new virtual
has (plus the object pointer, of course) and invoke the latter one.
In my example, adding an int parameter to NewVirtual() and changing the
following functions accordingly:
// test
void
A::test()
{
printf("A::test()\n");
#if USE_NEW_VERSION
NewVirtual(7);
#endif
}
// NewVirtual
void
A::NewVirtual(int x)
{
printf("A::NewVirtual(%d)\n", x);
}
// NastyVirtual
extern "C"
void
NastyVirtual__1A(A *a, int x)
{
printf("A::NastyVirtual() (obsolete)\n");
a->A::NewVirtual(x);
}
I get:
$ g++ a.cpp -o liba.so -nostart -DUSE_NEW_VERSION
$ LIBRARY_PATH=$LIBRARY_PATH:. ./app
A::test()
A::NastyVirtual() (obsolete)
A::NewVirtual(7)
Looks good, I would say.
CU, Ingo