http://d.puremagic.com/issues/show_bug.cgi?id=3581
--- Comment #7 from Jonathan M Davis <[email protected]> 2011-03-01 14:48:17 PST --- They can't be kept apart as long as you can't specify whether a function is virtual or not. In C++, a member function is not virtual unless you mark it as virtual (or a base class has a function with the same name which is marked virtual). So, you can get into problems where you override functions but don't make them virtual, so which version of a function you call depends on what type of pointer you're using (yuck). D just makes all member functions virtual except those which it knows don't have to be. It currently treats private as non-virtual (and therefore non-overridable since all overridable functions must be virtual in D as just mentioned), presumably with the idea that there's no point in overriding a private function (forgetting NVI). C++ does allow the overiding of private functions. The typical case where you do that would be NVI, where you make a public function which is non-virtual and a private one which is virtual and overridden in derived classes. That way, the private, virtual function can only be called in the base class, and you can enforce that certain things happen before or after the call to the private function, because the only place that it ever gets called is within the public, non-virtual function in the base class. It's a nice idiom, but it can be pretty much done the same way using protected instead of private (particularly since there are ways to get around the uncallability, IIRC - probably by just casting the this pointer to the base class type). It also doesn't cause a penalty in C++, because your private functions are usually non-virtual and completely inlinable. In D, however, because you _can't_ specify a function as non-virtual, if you made private functions overridable, they must be virtual, and all of a sudden, the compiler can't inline _any_ private functions unless they're final. It doesn't know what all of the derived classes look like and whether they override a particular function, so it must assume that they'll be overriden and would have to make the virtual. So, if we make it possible to override private functions in D, it would pretty much have to become common practice to mark all private functions as final unless you were specifically using NVI, otherwise you're going to take a definite performance hit in a lot of cases. On the other hand, we could leave private as unoverridabel and just say that NVI has to use protected instead of private. It works just as well and doesn't require that you mark almost every private function that you ever write as final. You _can't_ separate access level from virtuality in D, because non-virtuality is done as an optimization rather than a function being virtual on non-virtual being at the programmer's request. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
