Re: Future of C++
On Aug 10, 9:01 am, Andre Kaufmann <akfmn...@t-online.de> wrote:
Perhaps we are discussing different things and all statements are
correct in the context we are speaking of ?
I think you mean:
-----------------
If a virtual destructor (function) would be added to a COM interface,
this would break compatibility, since the interface would be changed.
The abstract COM interfaces can have only abstract functions by
definition. So such an interface shouldn't have an destructor at all and
therefore it can't (by definition) be made virtual.
Well, yes but this is not the main problem. See below
We are thinking of:
-------------------
I thought of the implementation of the interfaces in the object derived
from the interface (or multiple interfaces) and I think Razvan Cojocaru
meant this too.
Changing the destructor in this object from "non virtual" to virtual
wouldn't affect COM compatibility.
The problem is that C++ doesn't have a special interface concept/
keyword. An interface is just an abstract base class. COM (or XPCOM or
many others) interfaces look like
class ISomething
{
public:
virtual unsigned long foo() = 0;
};
class ISomethingElse : public ISomething
{
public:
virtual unsigned long bar() = 0;
};
Imagine these declarations compiled with a "new" compiler that
silently injects virtual destructors and an "old" (i.e. current) one.
The code produced by one wouldn't be able to use the implementations
produced by the other.
Regardless of abstract reasoning whether interfaces should or
shouldn't have a destructor there is a backward compatibility problem
here.
--
Eugene
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]