Is there a value in preceding the names of pure virtual base classes with the letter 'I', as is common in C#/Java?

I don't see this very often, if at all, in C++. Any reason not to do this? I think it would be easier to identify the implications and intention开发者_运维问答s of the typename by doing this, as well as the sourcefile. Thoughts?

IMHO, It is a non-sense in any modern language/ide.

This kind of notation is a relic of Microsoft COM coding standards. It was very common among Visual C++ developer but nowadays even Microsoft discourages the use of this kind of "Hungarian notation" habits.

Using a modern IDE, if I want to know if a "class" is an "interface", I can look at the icons near the name of the "class". I do not need anymore confusing prefix before the class names.

In addition, this coding convention is error prone. It requires human attention and, probably, someone that checks if some "I" was forgot.

Nowadays its more common to have an application/company specific coding style than follow some general rules for what is right or wrong(*) i.e. if your team find it useful to prefix with an I then why not. What is more important (as with all coding styles) is to be consistent.

(*) in C++/C not speaking of other languages but could apply there as well.

In Symbian C++ programming pure virtual classes being with 'M' (for Mixin) by convention.

What's the real significance of a class having pure virtual functions? It means it can't be instantiated directly, that derived classes are forced to implement some features, but is that really significantly different from deriving from a base with virtual but no pure functions, where you might want to override a default implementation anyway? During evolution of code, a pure virtual function might be replaced with a default implementation, but that doesn't affect or undermine the usage or design of existing clients. So, this distinction isn't very useful as far as I can see. But, there is a cost...

To maintain the I prefix convention as you've suggested, a decision to provide default implementations of the virtual functions would require a name change and edits to all the client code. If this is not done, then I becomes actively misleading. So, you'd need to find significant advantage in the convention before you'd adopt it, and a lack of common use suggests that advantage isn't perceived.

Based on the issue above, you might reach for a convention where I only indicated a base class with some virtual members, irrespective of whether any are pure. But then a class would add a virtual function during the evolution of a system, and you'd still need to rename the class and correct client usage.

In C++, most people have found these kind of distinctions don't add enough value to warrant their maintenance. One priority is to maintain as much freedom as possible to vary code without affecting clients, though this can conflict with other priorities - e.g. pImpl idiom versus inline performance.