Jeff Schwab said:
Rather the reverse. virtual typically appears in abstract interfaces.
Since those interfaces have no private members, they are often declared as
structs.
That I'd regard as poor style (although of course that doesn't mean it
may not often occur). Putting aside that the sole purpose of this is to
save a few keystrokes, and keystrokes are cheap, and that it conflicts
with about the only useful reason to have both struct and class, to allow
struct to be used for basic C-style structs (and another case I note below)
and class when not, there is a more serious reason.
Lets's suppose I have
struct Base
{
// virtual declarations.
};
Now I write some code, in foo.cpp
#include "base.h";
#include "foo.h"
void foo(const Base & base)
{
// ...
}
and in foo.h
void foo(const Base &);
But I need a forward declaration of Base before that (no point including
base.h).
And the natural thing to use is
class Base;
However the last compiler I ran that code (or something similar) through
gave
me a warning that I'd mixed class and struct. And warnings are not good,
it's generally recognised as good style to avoid them.
So now I need to have it published whether Base is actually defined
using struct or class in order to painlessly forward declare it, regardless
of that this conveys no information ... no, thank you, let's stick to class
everwhere (as that is the usual convention for something that's not a
C-style struct, or possibly something never used in an interface, which
ironically ,in view of where this came from, means that private base
classes without virtual may have no problem being structs).
While on this topic there is another problem, which is if Base is actually
a typedef, which doesn't forward declare well (something that could do
with fixing). Currently also defining a base_fwd.h may be the least bad
solution
to that. Of course you could also do that just to specify struct Base, but
that
I think would be the worst idea in this posting.
[1]) you design that door so