On Monday, May 06, 2013 14:19:12 Henning Pohl wrote: > Documentation: > Member functions which are private or package are never virtual, > and hence cannot be overridden. > > I was about to write a bug report about this, because in my code > there are tons of overridden methods which actually should be > private/package. Can anyone tell me why this decision has been > made? To inline them? > > Do I really need to write interfaces to be able to override these > methods?
The decision was made to make member functions virtual by default. As soon as that function was made, there had to be a choice for every access level as to whether it would be virtual or not. public and protected obviously have to be virtual, and in general, there's no real benefit in making private virtual (and there's a definite permorfance cost to programs in general if you do), so it's non-virtual. There's a bit of disagreement with regards to package, but it was decided that it wouldn't be virtual either, as it had nothing to do with inheritance. There's actually quite a bit of disagreement on whether member functions should be virtual by default (in particular, the guys working at companies which need high performance really don't like it), but at least for the moment, that's the way it is. And in order to make private or package functions virtual, we'd need a way to do so explicitly, which we don't currently have. I'm considering creating a DIP on the matter, but I think that I'm going to wait until some of the current discussions die off; otherwise it wouldn't get the attention that it deserves (the rvalue discussion in particular is likely to be quite large). - Jonathan M Davis
