Re: how to recognize whether code is C or C++?
On May 21, 7:19 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
Christopher Dearlove wrote:
"Jeff Schwab" <j...@schwabcenter.com> wrote in message
news:FLudnZSz0JYC6IjXnZ2dnUVZ_j-dnZ2d@giganews.com...
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).
I got it from Bjarne Stroustrup, in The C++ Programming
Language. It's not poor style.
Style is a matter of taste. I know a lot of people who consider
it poor style. I also know some (a minority, but it does
include some experts) who use it systematically: struct if all
members are public.
The only absolute rule here is to use whatever style the other
programmers in your company are using.
Furthermore, it is very popular, which is the exact opposite
of the main claim from your previous post (which you snipped).
I don't know how popular it is. Stroustrup uses it, but I've
not seen many others recommending it. The most frequent rule
seems to be either "use struct for PODS, class for everything
else", or "use struct if there are data members and they are
public, class for everything else". And there are doubtless
other reasonable rules.
Putting aside that the sole purpose of this is to
save a few keystrokes,
"Save" a few keystrokes? That presumes that writing class,
followed by public:, is somehow the natural order of things,
and that using struct deviates from that order. That's
ridiculous; if you don't have any private members, why use a
keyword whose sole purpose is to make a struct's default
access level private?
Because it is the accepted convention where you work.
Like most people (I think), I always start my classes with the
public members. (This is really a questionable policy, but so
many places I've worked in have had it that I tend to do it
automatically.) And still use class, although the first
elements are public. For better or for worse, the words
"struct" and "class" speak to the reader, and you want to use
one which tells the reader the truth, when interpreted as he
interprets it.
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
That's one possible convention, being your favorite does not
make it "about the only useful reason."
class foo
{
public:
// ...
};
Is more verbose, and IMO no clearer, than:
struct foo
{
// ...
};
Clarity depends on the local conventions. If the local
convention says that "struct" means PODS, then using it for
anything else is less clear.
(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.
In the first place, that's a useless warning, since there is
no difference between a class and a struct. They're the same
thing. The keywords just introduce different default access
levels, when used to begin a definition.
In the second place, your compiler may not be configured in a
sane way. GCC, with the warnings cranked up, produces no such
warning, nor should it.
Off hand, I can't find a compiler that warns about it, even with
the warnings cranked up.
In the very distant past, VC++ 6 didn't just warn, it treated it
as an error (IIRC). But seriously, VC++ 6 is decidedly
pre-standard, and while I don't think one should constantly run
to use the latest version of every compiler, there's really no
excuse for going to the opposite extreme, and using compilers
that are more than ten years old (and no longer supported by
their vendor).
In the third place, if you really just want to be consistent,
the thing to change is the forward declaration, not the
definition. The following two declarations are semantically
identical:
class base;
struct base;
The problem is that if the rule depends on the contents of the
class, and you change the contents (in a way that should be
transparent to the user), all client code has to be modified.
In the fourth place, forward declarations smell bad. There's
rarely any good reason to start declaring code to work with
classes whose definitions have not even been seen.
Forward declarations reduce coupling and dependencies. They
should be used whenever possible. (Of course, if you use the
compilation firewall idiom, you don't even need the forward
declarations.)
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).
It doesn't need to be "fixed," because it isn't broken. If
you need to work with a type that hasn't been defined yet, you
can easily give it a name by making it a template parameter.
That's the right thing to do. Then, you don't have to care
whether it's a class name, a typedef, or a primitive type.
But you have introduced significant extra complexity, for
nothing. And in the absense of export, significant extra
coupling. Templates are something to be avoided (except when
the alternatives are worse, of course).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34