Why does C++ have classes?

Question

The title is deceptive; the question is really "why does C++ have classes and not only structs?"

Often, people ask why C++ has structs if they are functionally equivalent to classes. The answer is (as in most not-type-safe/not-OOP/not-modern/not-... things in C++), is "inherited from C to not break compatibility". Well.

But if we already have structs from C, and we're planning to add them OOP functionalities (encapsulation, inheritance, methods), why just not remain with them? Why add complexity to the language with redundant keyword class and introduce confusion about what's the difference between the two?

The only reasons I can think about are:

1. Default private accessibility. But anyway the recommendation is to be explicit, is it worth? I think that not.
2. Be consistent with other OO languages. I don't know much history about it so maybe there wasn't programming languages that use class at that time at all, but even if there was, you're creating a new language!

• candied_orange: Default private is wonderful. Almost as wonderful as default const. It's a pity..
• amon: In retrospect the class keyword is not particularly necessary or helpful, but it's not like C++ struct has the same meaning as in C where struct T and T can name different types. In a template parameter list you can say template<typename T> or template<class T> but not template<struct T>.
• Chayim Friedman: @amon So we would make it work... And remember that when adding classes Stroustrup didn't know his language will have templates (I imagine)
• phorgan1: Truth on the Stroustrup not knowing. 1979 - C with classes, 1985 - CFront 1.0, 1988 - Stroustrup proposes templates.

Answer 1

In his book "The design and the evolution of C++ ", Bjarne Stroustrup explains it himself:

• The very first version of the language was called "C with classes". Stroustrup's intent was to introduce Simula-like classes into C (October 1979). (page 27 of the book)

• From the start he wanted public/private access control and derived classes (no virtual functions at this stage). (feature overview, page 29)

• Very quickly C with classes gave birth to C++, one of the key driver being data abstraction and OOP.

• Stroustrup saw a class as a plain type that could be passed as parameter and returned. For those who remember C at that time: it was not possible to pass struct as argument other than passing a pointer to the struct, and same for the return type. (I think this was only changed by C89, but it's not excluded that some implementations allowed it before)

• Stroustrup explains that he hesitated between class and type (and not class and struct). He chose the former, since class was already used in Simula (his then favourite language). (page 31 of the book).

• He further explains that he wanted struct and class to be a same concept, because using a C-compatible low level struct and reserving advanced OO features only for class might have hampered the widespread use of OO design because of the convenience of backward compatibility. (page 76). Summary of a half page of arguments:

  In other words, the "a struct is a class" notion is what has stopped C++ from drifting into becoming a much higher-level language with a disconnected low-level subset.

• But on the other hand, he wanted some backwards compatibility for easily including unix headers that made extensive use of struct. Therefore the struct and the public access by default of its members. (page 48)

So in summary, this explains the origins: why class, why public/private, why class are private by default, why struct, and why struct is public by default. The rest is history ;-)

• Chayim Friedman: Thanks. I think I will read the book...
• Stack Exchange Broke The Law: (see Objective-C for an example of "a much higher-level language with a disconnected low-level subset." (or rather the opposite))

Answer 2

Because it would be C otherwise. That C++ evolved from the so called "C with Classes" is telling. As per Stroustrup motivation to add classes to C...

Stroustrup was working in a distributed system simulator, for which he was interested in modularity and concurrency. According to Stroustrup, the initial version was developed in Simula, from where he took the concept of classes.

Afterwards Stroustrup worked on extending C with such features. Which, please note, is not creating a new language. It is leveraging C's pre-processor. That work would lead to "C with Classes", and later to C++.

---

I suppose, it makes some to ask why not keep only struct or class, but not both, once C++ was a separate language. At some point C++ was intended to be a superset of C. Which it isn't. Yet, the revelation that it wasn't came after there was C++ code in the wild. Meaning that C++ could not be made fully compatible with C, because that would break code. Neither it could be made less compatible with C, because that would break code too.

---

Why no concurrency features? For that I quote:

I considered it crucial – as I still do – that more than one notion of concurrency should be expressible in the language. This decision has been reconfirmed repeatedly by me and my colleagues, by other C++ users, and by the C++ standards committee. There are many applications for which support for concurrency is essential, but there is no one dominant model for concurrency support; thus when support is needed it should be provided through a library or a special purpose extension so that a particular form of concurrency support does not preclude other forms.

-- Bjarne Stroustrup - A History of C++: 1979−1991.

Answer 3

It’s not just about capabilities, it is also about attitude. If I want to have a C struct in my C++ code, I use a C++ struct. If I want to go object oriented, I use a C++ class. The reader will hopefully know the difference.

Newer languages have structs and classes that are very different, like Swift. In Swift, one is a value type, the other is a reference type. If C++ hadn’t made that difference this would have been much more difficult.

Answer 4

Interfacing

From the perspective of a programming language and the machine compiling it. It does not matter how many ways the same construct can be specified, or how it is presented.

This one gives default X, but No Y. And this one gives No X, and default Y. This other one has No X, nor Y, but secret Z.

All perfectly fine as long as the language is clear, an consistent about what means what.

The real problem in developing a language is the Human.

• Meat ware is slow. So slow....
• Updates to Meat ware often fail, and have to be repeated many times.
• Meat Ware has limited concentration, at most 7 items. Usually around 4-5.
• Meat Ware has to interface with more than just this language.
• Meat Ware loves fashion, buzz words, and simplistic heuristic check boxes.
• Meat Ware loves comfort, and hates surprises (not surprising really a surprise tiger is not fun for meat).
• Meat Ware is lazy
• Meat ware loves Skinner boxes.

... and many more things.

This explains your two points very well:

1. Meat Ware is lazy. Meat ware hates surprises.

   • Every OO textbook dictates that Objects encapsulate, and keep information private. The exception being the public interface.
   • private: is 8 key presses too many.

2. Meat Ware hates surprises. Meat Ware is Lazy. Meat Ware interfaces using other languages. Meat Ware loves comfort.

   • Class is synonymous across many languages. It has a single clear meaning. And it feels right and comfortable to write OO code using a Class.
   • Struct is synonymous accross another language (C) which was (and is still) popular. To make this crowd feel comfortable, not provide any surprises, and encourage lazy adoption of C++ then the language has Struct.

These are only some of the eclectic platform features of meat ware, doubtlessly others can be found and used to answer your question.