Why are struct and class essentially the same in C++?

Question

struct and class in C++ are nearly identical (as covered for example here).

But why is this so? What did happen when C++ was developed and eventually standardized, that struct was allowed to define a full OOP class, yet class keyword was also added? There must be a historical reason for this, but I did not find an answer by searching.

In contrast, for example C# uses these keywords too, but there they have different and distinct meaning. I would say this is quite a valuable feature in that language.

In hindsight, it would have for example made sense to keep C++ struct be always compatible with similar C struct in memory layout, and only those class features that are compatible with that would have been supported (so no "virtual" stuff, value always copyable by memcpy, maybe even some kind of C interoperability for struct methods). Or something else perhaps; point is, the distinction could have meant something and added to the language, instead of being a (small) source of confusion it is now.

So I am looking for some historical record, quote or story, which would explain this.

Answer 1

Bjarne Stroustrup writes in his The Design and Evolution of C++ book (item 3.5.1):

At this point, the object model becomes real in the sense that an object is more than the simple aggregation of the data members of a class. An object of a C++ class with a virtual function is a fundamentally different beast from a simple C struct. Then why did I not at this point choose to make structs and classes different notions?

My intent was to have a single concept: a single set of layout rules, a single set of lookup rules, a single set of resolution rules, etc. Maybe we could have lived with two sets of rules, but a single concept provides a smoother integration of features and simpler implementations. I was convinced that if struct came to mean "C and compatibility" to users and class to mean "C++ and advanced features" the community would fall into two distinct camps that would soon stop communicating. Being able to use as many or as few language features as needed when designing a class was an important idea to me. Only a single concept would support my ideas of a smooth and gradual transition from "traditional C-style programming," through data abstraction, to object-oriented programming. Only a single concept would support the notion of "you only pay for what you use" ideal.

In retrospect, I think these notions have been very important for C++'s success as a practical tool. Over the years, just about everybody has had some kind of expensive idea that could be implemented "for classes only," leaving low overhead and low features to structs. I think the idea of keeping struct and class the same concept saved us from classes supporting an expensive, diverse, and rather different set of features than we have now. 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. Some would have preferred that to happen.