Re: Future of C++
Bart van Ingen Schenau wrote:
Andre Kaufmann wrote:
[...]
compatible, not of the C++ standard itself, because the VTABLE layout
isn't standardized (correct me if I'm wrong)
Technically, that is true.
But this kind of change can not be easily made without breaking binary
compatibility and I think that implementors will deem the change to be
too hard and ignore the new requirement (just like they mostly did with
export).
C++ should have some kind of alpha standard or fast track standard with
features, which will be only implemented for testing. If the new feature
is stable and simple to implement it could be made part of the current
standard - otherwise simply not.
IIRC GCC is already some kind of playground for early adoptions of new
language features - why not extend it and using the feedback to estimate
the stability / side effects of new features / language changes.
[...]
Then please explain how a compiler can generate *binary identical*
v-tables for these two sets of interface classes:
O.k. since nothing is to difficult for an engineer I at least (have to)
give it a try ;-) :
[...]
class ISomething
{
public:
~ISomething();
virtual unsigned long foo() = 0;
};
class ISomethingElse : public ISomething
{
public:
virtual unsigned long bar() = 0;
};
[...]
I don't see any way to keep the offset and order of the v-table entries
for ISomethingElse identical in both cases.
First layout of vtables:
[0] = Index 0 [1] = Index 1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!Let's assume that the vtable pointer points always to index [0].!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ISomething:
[0] foo
ISomethingElse:
[0] foo
[1] bar
-----------------------------
After the compiler has made the destructor automatically virtual:
ISomething:
[-1] ~ISomething
[ 0] foo
ISomethingElse:
[-2] ~ISomethingElse
[-1] ~ISomething
[ 0] foo
[ 1] bar
This layout should be still binary compatible, since the vtable pointer
still points to index[0] this shouldn't break COM compatibility. The
compiler "only" has to know the negative index of the different
destructors.
We also should keep in mind that the automatic destructor would not be
visible to COM anyways, since the interface description isn't affected
by internal compiler changes. And there is no need to be visible either,
since the destructor shouldn't be called directly by COM.
[...]
Bart v Ingen Schenau
Andre
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]