Re: how to recognize whether code is C or C++?
On May 22, 1:17 am, Noah Roberts <n...@nowhere.com> wrote:
Phlip wrote:
Ian Collins wrote:
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).
Nonsense, why would you se anything else when there is
nothing bu a public interface?
Because style guidelines often reserve 'struct' to mean
"behaviorless data bucket", where a pure virtual interface
is the exact opposite - dataless behavior.
Can you state any technical reason for that guideline or is
this yet another irrational standard you like to harp on?
Communicating information to the reader? That's the "technical
reason" behind most guidelines. (The compiler doesn't care if
we indent, either, or even if we put the entire class definition
on a single line. Readers do.)
What happens when what used to be a "behaviorless data bucket"
suddenly gains behavior?
You've broken client code expectations, so all client code has
to be re-reviewed, and probably updated.
Is a "behaviorless data bucket" really an object that has
enough responsibility to survive?
It depends on what you mean by "behaviorless data bucket", and
whether C compatibility is an issue.
Is a C language structure that has member function pointers a
class or not?
Is this a class?
class X
{
int x;
friend ostream& operator<<(ostream&,X const&);
};
It's not even usable, since it only has a default
constructor:-).
Is this less of a class?
struct X
{
int x;
};
ostream& operator<<(ostream&,X const&);
According to the language, they're both classes. A user will
doubtlessly use them in different ways, however.
Is this a class?
class X
{
public:
int x;
X() : x(42) {}
};
Put that guideline together with "all publics should appear
at the top of a class", and our industry is fated to forever
write only class Foo{ public:...
Why put it together with the former?
Because they're both common guidelines.
There's no reason to use 'class' over 'struct' since they mean
the same thing.
To the compiler. Not to the human reader.
[...]
As I learned the other day, even a union is a "class" in C++.
According to the standard. In practice, there's is a clear
distinction between unions and other classes (and you can't
forward declare a union with "class" or "struct", or vice
versa).
Since the only difference between 'struct' and 'class' in C++
is default permission, and it is more common to inherit
publicly and write public members first, it is more efficient
and sensible to use the 'struct' keyword for everything.
Efficient in what sense. Although it pleases me to see that
finally someone has enough sense to use the word for something
other than runtime efficiency (since I'm sure you didn't mean
that), I would like to know what efficiency you are talking
about. Since you have two distinct keywords, it would seem to
me that "efficiency" argues in favor of giving them different
meanings, even if the language doesn't.
This does two things:
1. saves us from the pointless typing of 'public' everywhere.
Whoopy do.
2. Points out uncommon inheritance by using keywords for the
uncommon permission rather than the common one.
In practice, that rules seems little enough known that it makes
sense to always specify access in inheritance. At least, except
for demonstrations in standards discussions, I've never seen
anyone not specifying access in inheritance.
The standards committee could do us all a favor and get rid of
the 'class' keyword all together.
Or making class and struct mean two different things. Or doing
any other number of things which would in fact break all
existing C++ code.
I don't call that a favor.
--
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