Re: Future of C++
Andre Kaufmann wrote:
Bo Persson wrote:
Andre Kaufmann wrote:
Eugene Gershnik wrote:
On Aug 11, 3:58 pm, Andre Kaufmann <akfmn...@t-online.de> wrote:
Eugene Gershnik wrote:
[...]
You are wrong. Even ignoring the fact that these extensions do not
Stating it doesn't proof it.
In C++ there is no guarantee of the VTABLE layout, or am I wrong ?
So why should there be a guarantee of a C++ class to have the same
layout as COM specifies ?
It could be implementation defined, which it is.
So it's relying on a proprietary implementation detail and if the C++
standard is changed, it is the task of the compiler vendor to stay
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).
Even though C++ does not specify an ABI, when proposing any changes to
the C++ language, you should consider what effect that would have on
the possible/likely ABIs that underly the different C++
implementations.
Any change that breaks the ABI of an important platform is not likely to
be accepted or implemented unless the added value of the change heavily
outweighs the costs of breaking binary backwards compatibility.
For the Windows platform, COM is part of the ABI.
The COM spec was specifically designed so that the existing vtable
layout for Visual C++ complied with the requirements. Now, changing
the language standard so that this is no longer possible, seems like
a VERY bad idea!
See my other post. I still think the compiler can add automatically
functions to it's internal vtables and still be interface compatible
to the previous version of this C++ compiler.
It only mustn't change the start offset of the first interface
function and the order of the interface functions.
Then please explain how a compiler can generate *binary identical*
v-tables for these two sets of interface classes:
/* current rules */
class ISomething
{
public:
~ISomething();
virtual unsigned long foo() = 0;
};
class ISomethingElse : public ISomething
{
public:
virtual unsigned long bar() = 0;
};
and
/* destructor automatically made virtual, written as the equivalent
under the current rules */
class ISomething
{
public:
virtual ~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.
Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]