On Wed, 12 Mar 2014 08:32:14 -0400, Michel Fortin
<[email protected]> wrote:
On 2014-03-12 03:04:38 +0000, Manu <[email protected]> said:
virtual-by-default is incompatible with optimisation, and it's reliable
to
assume that anybody who doesn't explicitly care about this will stick
with
the default, which means many potentially useful libraries may be
eliminated for use by many customers.
I'll add another argument to the mix.
Currently, you can't have private/package functions that are virtual,
contrary to what TDPL says.
To make things coherent we could change private function so they become
virtual by default. You might be able to see the problem with this
option: making private function virtual by default is likely to add many
performance regressions in existing code, silently.
Private virtual functions make 0 sense. A private function cannot be
accessed by a derived class. Who gets to access a overriden virtual
function? The base class only? If I'm writing a function, I certainly
should be able to access it, no? Even if you want to restrict my access,
you cannot, I'm in control of that code!
Package, I'm less concerned about. You can make that virtual, I don't ever
use package functions.
-Steve
