why did c++ add the class keyword?

[440gtx]

The class keyword created a lot of confusion that resulted in a popular
style that says struct is appropriate for POD (plain old data) and
class is appropriate for fancier things (member functions, data hiding,
inheritance). And indeed the FAQ even advocates this usage model. I
myself have broken from this tradition because I find the public
defaulting of struct more appropriate than class and thus prefer it
100% of the time. The benefit is I no longer need to unhide the
constructor and I don't lose any explicit control over privacy. So what
was the reason for introducing the class keyword?

 

[Steve Pope]

The class keyword created a lot of confusion that resulted in a popular
style that says struct is appropriate for POD (plain old data) and
class is appropriate for fancier things (member functions, data hiding,
inheritance). And indeed the FAQ even advocates this usage model. I
myself have broken from this tradition because I find the public
defaulting of struct more appropriate than class and thus prefer it
100% of the time.

(OT)

I also always use struct, since normally the first element of
a struct or class is public, and therefore it saves a keyword.
I find the theory that if there's so much as a member function it
should be a class unconvincing. Everyone knows a struct
and a class are the same thing.

But please note I am not a software engineer in the first place.

Steve

 

[Thomas Matthews]

The class keyword created a lot of confusion that resulted in a popular
style that says struct is appropriate for POD (plain old data) and
class is appropriate for fancier things (member functions, data hiding,
inheritance). And indeed the FAQ even advocates this usage model. I
myself have broken from this tradition because I find the public
defaulting of struct more appropriate than class and thus prefer it
100% of the time. The benefit is I no longer need to unhide the
constructor and I don't lose any explicit control over privacy. So what
was the reason for introducing the class keyword?

Most of the time, I use the class keyword and
annotate the sections. I have sections for public,
protected and private in my stencil. The class
keyword helps me to distinguish object-oriented
projects from ad-hoc or C style projects.

My philosophy is that everything should be private
unless proven otherwise. Information is distributed
on a need to know basis (high encapsulation). This
really helps in debugging, especially on large
projects.

For demos and experiments, I use the struct.


--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

 

[Bo Persson]

The class keyword created a lot of confusion that resulted in a
popular style that says struct is appropriate for POD (plain old
data) and class is appropriate for fancier things (member functions,
data hiding, inheritance). And indeed the FAQ even advocates this
usage model. I myself have broken from this tradition because I find
the public defaulting of struct more appropriate than class and thus
prefer it 100% of the time. The benefit is I no longer need to
unhide
the constructor and I don't lose any explicit control over privacy.
So what was the reason for introducing the class keyword?

I believe the current state is just an accident in the evolution of
the language.

Originally the class concept was added to C (in the language "C with
classes"). At that stage structs and unions were still identical to
their C language counterparts.

Only later did someone ask "Why can't I have member functions in a
struct?". And there were no good reasons...



Bo Persson

 

[Gregory Currie]

The class keyword created a lot of confusion that resulted in a popular
style that says struct is appropriate for POD (plain old data) and
class is appropriate for fancier things (member functions, data hiding,
inheritance). And indeed the FAQ even advocates this usage model. I
myself have broken from this tradition because I find the public
defaulting of struct more appropriate than class and thus prefer it
100% of the time. The benefit is I no longer need to unhide the
constructor and I don't lose any explicit control over privacy. So what
was the reason for introducing the class keyword?

When C++ was designed, it was to be mostly compatible with C, while
providing an object orientated language. Proper OO dictates that
objects should have private data by default, and let members be
explicitly public. If they were to make struct public by default, it
would break a lot of C code so therefore the class keyword would be used
for classes, and struct for classes that default to public. Over the
years it became accepted that structs should be used for POD types, and
classes for proper OO types. This system, while a little confusing,
allowed people to code C++ in a proper OO manner, while keeping C++ as
compatible with C as possible.

In all cases, it is probably best to explicitly state if a member is to
be private, protected or public.

 

[Earl Purple]

I also always use struct, since normally the first element of
a struct or class is public, and therefore it saves a keyword.

My first element is usually private because I put members first then
functions. Just my style, I guess. I know a lot of people like the
public at the top because then as users they see first what they are
going to need to use the class.

Private methods (other than possibly a disabled copy-constructor and
operator=) generally go at the bottom of my classes, thus I have 2
private sections.

I find the theory that if there's so much as a member function it
should be a class unconvincing. Everyone knows a struct
and a class are the same thing.

I will sometimes use struct for functors that have no member variables
at all. Probably because I've seen others use it in sample code.

Generally I will use the class keyword unless everything in it is
public. And generally member variables will be public only if it's
grouped-together data and then it would generally have no member
functions other than trivial constructors (often one default
constructor and one that has initial values for all the members).

 

[Walter Bright]

I believe the current state is just an accident in the evolution of
the language.

Originally the class concept was added to C (in the language "C with
classes"). At that stage structs and unions were still identical to
their C language counterparts.

Only later did someone ask "Why can't I have member functions in a
struct?". And there were no good reasons...

My beef with class is that it's also in the tag name space. The tag name
space is a language design mistake. I suggested back in the 80's to
Bjarne that the class be in the regular name space, and leave struct in
the tag name space for C compatibility. He replied there was too much
existing C++ code to make such a change.

With the D programming language there was a chance to fix that. Structs
are for POD, classes are for objects, and both are in the regular name
space (there is no tag name space in D). Both class and struct default
to public.

Walter Bright
www.digitalmars.com C, C++, D programming language compilers

 

[Bo Persson]

My beef with class is that it's also in the tag name space. The tag
name space is a language design mistake.

I guess so. I don't seem to write code where it matters, so it's not a
big deal for me. Perhaps more of a problem to compiler writers?

I suggested back in the 80's
to Bjarne that the class be in the regular name space, and leave
struct in the tag name space for C compatibility. He replied there
was too much existing C++ code to make such a change.

With the D programming language there was a chance to fix that.
Structs are for POD, classes are for objects, and both are in the
regular name space (there is no tag name space in D).

So it seems that there really _were_ reasons to keep the structs
unchanged. Some of the memcpy-guys are now arguing that they need a
pod_struct or something, to have the compiler assure the POD-ness of
their data.

So, keeping structs as C-style PODs might have been a good idea after
all. But now there is *way* too much C++ code to make such a change.

Both class and struct default to public.

Typing an additional "public:" per class definition is not big deal,
and it also serves as documentation. Making it optional could satisfy
both sides, of course.


Bo Persson

 

[Earl Purple]

So it seems that there really _were_ reasons to keep the structs
unchanged. Some of the memcpy-guys are now arguing that they need a
pod_struct or something, to have the compiler assure the POD-ness of
their data.

Better solution is to have a standard is_pod that can be overloaded for
user-defined types.

So, keeping structs as C-style PODs might have been a good idea after
all. But now there is *way* too much C++ code to make such a change.

Useful for optimisation but something that is_pod can resolve, even if
the data members are private. basic types and pointers (including
pointers to functions) would be pods by default.

Somewhere in between POD and non-POD are movable classes/structs. A
class is movable if you can move it to another memory location without
invalidating any of its members. Obviously any external pointers to it
or its members may become invalidated by such a move.

Note that not everything is copyable or moveable with memcpy/memmove
even in C. Well not as a whole set anyway. (How do you copy or move a
linked-list?).

Typing an additional "public:" per class definition is not big deal,
and it also serves as documentation. Making it optional could satisfy
both sides, of course.

I agree though having inheritance default to public would be useful
because that's the most common type of inheritance. I guess they made
the default private to be "orthogonal".

 

[Walter Bright]

I guess so. I don't seem to write code where it matters, so it's not a
big deal for me. Perhaps more of a problem to compiler writers?

It's not too much of a problem in C because the lookups are always
qualified with 'struct' or 'union', but it's a bit of a mess in C++. The
names default to being in the main space, but then are pushed into the
tag space if there are any other declarations with the same name. The
semantic analyzer has to look in the tag space if it's expecting to see
a class name based on the context, after first looking in the regular
space and finding a name that isn't a tag. It's just goofy - and it
didn't have to be that way.

So it seems that there really _were_ reasons to keep the structs
unchanged. Some of the memcpy-guys are now arguing that they need a
pod_struct or something, to have the compiler assure the POD-ness of
their data.

POD objects and OOP objects are just different and serve different
design goals. I think that any code design that tries to mix them
together (with, say, inheritance) is probably a mistake. People coming
to D programming from C++ at first find the struct(POD)/class(OOP)
dichotomy to need a bit of getting used to, but once they do, the
feedback on the choice is clearly positive.

Structs and classes are like ints and floats. Sure, you can use a float
as a loop counter, but it's just not meant for that.

So, keeping structs as C-style PODs might have been a good idea after
all. But now there is *way* too much C++ code to make such a change.

I agree. C++ is boxed in by legacy code based on decisions made 20 years
ago. This happens, of course, to all successful languages.

Typing an additional "public:" per class definition is not big deal,
and it also serves as documentation. Making it optional could satisfy
both sides, of course.

It's a minor thing, I agree. It's like a story my father told me. We
lived in a small town, and he once asked the mayor what the biggest
problem he faced was. The mayor replied that the town was evenly divided
between dog lovers and dog haters. Neither side could gain ascendancy,
so his work was occupied with constantly trying to compromise and
reconcile the two <g>.

Walter Bright
http://www.digitalmars.com
C, C++, D programming language compilers