Re: Future of C++
Razvan Cojocaru wrote:
Bo Persson wrote:
There are many cases where you might want to adhere to an
interface, without dynamically allocating the derived classes.
Perhaps, but it's very dangerous to assume that that will always be
the case, and the next source code maintainer or library users will
feel the same way and not use the heap. It's wiser to impose
behaviour constraints upfront by design, than to write 100 pages
coding style documents telling your programmers not to use the heap.
Like adding a protected destructor, to disallow improper use. :-)
Heap allocation is still not a problem, unless you also have delete
through pointer to base. That is the only case that the virtual
destructor helps against.
Adding an entry at the end would affect derived classes. The
number of virtual functions in the interface is important.
As Maciej Sobczak observed in a previous reply, the standard is
silent about the virtual table layout. All talk about it is bound
to be speculative, and IMHO largely irrelevant, so I'd rather not
try to solve an imaginary problem.
The current language standard *allows* an implementation to define the
vtable layout so that it conforms to the Windows COM interface (or
rather, allowed the COM spec to use the existing vtable layout).
Changes to the language that might break this, is just about as
serious a backward compatibility break as you can get!
Doing this just to potentially save some clueless maintenance
programmer, definitely isn't worth it!
Bo Persson
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]