Accessibility of virtual functions

[PredicateNormative]

Does anyone know if there are there technical reasons for these prohibitions or are they just arbitrary?

I'm not sure of the technical reasons as to why it is the case, but the standard (or, at least the 2005 draft that I have) in section 14.7.18 says:

In an explicit specialization declaration for a member of a class template or a member template that appears in namespace
scope, the member template and some of its enclosing class templates may remain unspecialized, except that the declaration
shall not explicitly specialize a class member template if its enclosing class templates are not explicitly specialized
as well. In such explicit specialization declaration, the keyword template followed by a template-parameter-list shall
be provided instead of the template<> preceding the explicit specialization declaration of the member. The types of
the template-parameters in the template-parameter-list shall be the same as those specified in the primary template
definition. [ Example:

template < class T1 > class A {
  template < class T2 > class B {
    template < class T3 > void mf1(T3 );
    void mf2 ();
  };
};
template <> template < class X>
class A<int >::B {
  template < class T > void mf1(T);
};
template <> template <> template < class T>
void A<int >::B<double >:: mf1(T t ) { }
template < class Y > template <>
void A<Y >::B<double >:: mf2 () { } / / ill-formed; B<double> is specialized but
                                    / / its enclosing class template A is not

I did once hear that the reason why the behaviour was prevented, was because it is technically difficult for the compilers to allow such behaviour, and therefore the standard disallowed it. But that explanation seems a little odd to me and I don't trust it. If anyone can give a good technical explanation as to why the behaviour was prevented, then I'd be happy to hear it.

Incidently, although there have been rumours that C++0x will make the above legal, it doesn't look like this will be the case as the Oct 2008 version of the C++0x draft keeps the above quotation unchanged. Therefore, VS allows you to get away with ill-formed code, which is a bit annoying.

[Russco]

It wouldn't be so bad if it was a language extension, but even with language extensions turned off those templates still compile on MSVC9.

Anyway the discussion was relating to virtual functions and not to templates.

Is virtual an implementation detail or is it important virtual makes it to the public interface?

Is there any difference from the client code's point of view if the client code calls func() or virtual func()?

[JohnW@Wessex]

Anyway the discussion was relating to virtual functions and not to templates.

Keeping a thread on track is sometimes akin to herding cats. It'll go where it wants to.

[TheCPUWizard]

When discussing this topic, I think it is important to keep the focus on functionallity that MUST BE exposed as a public member, and the decision of having a non-virtual public that calls a virtual non-public.

There are (possibly thousands of) other use cases for on-public members, which dont directly apply to this topic.

I think _UJ said it very well....

I found NVI a good idea and started applying it everywhere but stopped after a while because I felt it made the code more complex really. Now I will only using it for situations described in the advice.

I look at it from two specific angles...

1) It increases complexity. In the worst case doubling the number of members in the class. This is an objective measurement, the importantance of it is subjective...

2) It decreases the understanding of the class. This is subjective, but consider the case where ONLY the public imformation is included in the header and documentation. If the public function is virtual, it is immeditely clear that the behaviour will potentially change for different derived classes. Using NVI, this aspect is hidden from the user of the class. IMHO for most cases this is a negative impact.

[Russco]

2) It decreases the understanding of the class. This is subjective, but consider the case where ONLY the public imformation is included in the header and documentation. If the public function is virtual, it is immeditely clear that the behaviour will potentially change for different derived classes. Using NVI, this aspect is hidden from the user of the class. IMHO for most cases this is a negative impact.

I disagree here. Just because virtuals are private doesn't mean they cant be seen by someone reading through the header. Its only possible to hide private data and functions but not virtuals. If you hide the virtuals too behind some sort of compiler firewall (pimpl idiom) then the class itself is no longer a base class.

class MyType
{
   public:
      // non virtual interface calling nonpublic virtuals
      // allows a semblance of programming by contract
   protected:
      // virtual interface to derived classes if they need call base virtuals
      // possibly pure with default implementations
   private:
      // forward dec of pimpl
      // pimpl pointer
      // virtuals not needed to be called by derived classes
      // probably pure without default implementations
};

Wheres the hidden virtuals? Sure users of the header will not have much idea whats going on behind the pimpl but the virtuals are in plain sight to see.
You can still see the virtuals, hence you know the class is meant for use as a base class and that polymorphism will take place. You are exposing nothing that doesn't need to be exposed. Isn't that a better encapsulation?
Yes theres a downside of a bit of code bloat, but then this is also a common idiom to use when you need overloaded virtuals to avoid some of the problems they can cause.

You probably use streams often. They expose no virtual functions, but polymorphism is going on inside of the iostreams hierarchy. Do you need to know that to use streams??
Would you use streams differently if the protected virtuals had been public?

[TheCPUWizard]

I disagree here. Just because virtuals are private doesn't mean they cant be seen by someone reading through the header. Its only possible to hide private data and functions but not virtuals.

Technically I agree, but a good number of software firms I have had as clients use the following:

MyClass.h

class MyClass
{
    public:
        // All public methods go here
#include 'MyClass_Internal.inh"
};

MyClass_Internal.inh
protected:
     // Protected Methods
private:
    // Private Methods and non-PIMPL fields.

While it sometimes takes a bit of getting used to, it really allows users of the class to Focus on what they can access. If the ".h" files are in one directory, and the ".inh" files are in another you can even to FS based text searches to find all of the Public Methods with a given name, and not have to wade through the information that does not matter. Even in the IDE, the fact that only the public methods are "on the screen" really reduces clutter.

[Russco]

Another possibility would be...

#define VIRTUAL_DISPATCH

class MyType
{
   public:
      VIRTUAL_DISPATCH void func();
   // more stuff
};

For the cost of 1 empty macro, you can still use NVI but its now blatent that if func() is called it effects a virtual dispatch.