[Exceptional C++ Style] Item 18 - Virtuality

Ric Parkin ric.parkin at ntlworld.com
Tue Jan 4 06:56:20 EST 2005


On Tue, 4 Jan 2005 11:12:19 -0000, Paul Grenyer <paul at paulgrenyer.co.uk>  
wrote:
> 2. I agree with all the ideas and arguments for the NVI pattern.  
> However, I
> am in two minds about the extra code overhead. I suppose in many ways the
> overhead is similar to things like the pimpl idiom, which I often use,  
> but
> do find time consuming to expand and retract. I think I'd find the same  
> with
> NVI.

The perceived overhead does feel irritatingly high - you have to write all  
this extra forwarding stuff before you can actually use it, which slows  
down your train of thought. This is something that a simple refactoring  
tool *ought* to be able to do fairly easily.

Or even a simple code generator - type in return type, function name, and  
a list of parameter types and names, it both functions could be generated.  
I've an old tool that does something a bit like this, and it can be really  
useful. Visual Studio 8 has something like it too (although only for VB  
and C#, not C++ IIRC)


Other things from the original - I've always found the DoXXXX naming  
slightly icky , but haven't found anything better. Given you need two  
names, and they ought to have the main bit in common, I think you need a  
wart like "Do" or "Impl" or a trainling underscore. Suggestions welcome.



And the final guideline:
"Guideline: A base class destructor should be either
public and virtual, or protected and nonvirtual."

and

"Herb suggests that an empty but protected destructor should be given to  
classes like
std::unary_function."

I didn't think it was really clear that this only applies to classes that  
are *never* instantiated, but only used as base classes.

There a rule about the visibility of the destructor when you create a  
local variable:

int main()
{
    Foo foo; // destructor of Foo must be publically visible
}

So there's another guideline for these types of classes, but it's not  
covered by this item.

Ric










More information about the Effective-cpp mailing list