> 100% of the using structs like they are C structs vs using class as objects is cultural not a part of the language.

I think this take is completely wrong. There is nothing cultural about it. C++ was created as a strict superset of C, and thus from the inception it supported all features made available in C. This design goal remains true up to this day, and only started to diverge relatively recently when C was updated to include features that were not supported (yet) by C++.

When someone declares a plain old struct in C++, they are declaring a struct that is perfectly compatible and interoperable with C. This is by design. From the inception.

> This design goal remains true up to this day, and only started to diverge relatively recently when C was updated to include features that were not supported (yet) by C++.

This is not really the case. See https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B for a non-exhaustive list.

It is true that both sides agree that compatibility is an important goal, but it's only a goal, not something that's 100% the case.

What if, after 20 years of C++, you spend 10 years doing python, only to go back to C++ and realise that all this private/protected stuff is a crock and most of the time you are doing real work you just use struct and start typing your C++, virtual functions, constructors, destructors etc?

Just asking, for a friend.

> you spend 10 years doing python, only to go back to C++ and realise that all this private/protected stuff is a crock

Just a friendly reminder that two leading underscores wont protect your member functions in C++. Even if people insist that those are totally not supposed to be private in python.

I think OP meant discarding public/private constructs entirely, no protection, like in python.

Except python started mangling double underscore in a futile attempt to implement private members/methods.

The underscore prefix is more about communication. It's not a bad convention as it makes you feel a bit dirty when you are using them outside a class, but, do what you want, we are consenting adults.

Whenever I say "I'm no longer attached to all that private stuff", people always reply, "wait until you work on a large code base". I work on a million line+ code base. Whatever.

This argument aside, I'm not a total philistine. RAII is awesome but C++ is full to the boot with crusty stuff to keep the compatibility. I always feel there is a language better than anything trying to come out.

Python will literally mangle the names of double underscore members by prefixing them with the class name, to make it harder to access from the outside, so it is not just about communication.

These days I'm for minimalism, most of my structs are aggregates of public members, but sometimes you really want to make sure to maintain the invariant that your array pointer and your size field are in sync.

Using double underscore is advised against, and the name mangling is largely considered a mis-feature these days. Most style guides will tell you to use a single underscore to mark something as not for public consumption.

Of course neither double nor single underscore will stop anyone who wants to touch your privates badly enough. Which is big part of the python philosophy: You're not stopped from doing inadvisable things. Instead there's a strong culture around writing "pythonic" code, which largely avoids these pitfalls.

And neither does C++'s 'private' stop any other code from messing with your data, either, if they want to do that badly enough.

I'm not super familiar with C++, but I imagine you'd need some chicanery to access privates, while in python you can just use them by name.

Well, you can always cast and access stuff by memory address.

I can't rally upvote this without breaking the rules about obscenities. But I'll give it a :)

In python, if any of this gives you an trouble you can just replace the stuff in the class dict with your own functions. You don't even need to cast.

Any similarly of keyword naming between C and C++ is purely coincidental. :P

C++ is somewhat unique in that it started out as a few extra features on top of C before gradually splitting off and mutating into a totally separate programming language.

"Unique" in a world where Objective-C, Objective-C++, Groovy, and TypeScript exist.

What I meant wasn't that it was a language that was compatible with an earlier language. Groovy just compiles to the JVM; lots of things do. TypeScript is just JavaScript with type safety; Python did that too. Objective-C was just NeXT attempting to make the ugliest-looking programming language possible and they succeeded immediately.

But Cfront was released circa 1983 and you basically just wrote C, but it added a bit of new syntax that generated extra C behind the scenes. Object-oriented programming was still fetal in 1983! It didn't get really hyped until the mid-90's. So C++ kind of mutated for decades as this gross appendage on C until it became this whole separate blob that ate half of programming. It was 15 years later when the C++98 "standard" started trying to reign in Dr. Stroustrup's monster.

Then in 2005 we threw away all our textbooks that were like "Look! `Apple` derives from `Fruit`! `Car` derives from `Engine`! This is going to change the world!" because adding object-orientedness to everything became uncool when our bosses became fans of Java. But by this point the C++ blob had taken on a life of its own...

So yeah. Very few programming languages have a story as long and insane as C++.

Objective-C was originally a macro processor just like CFront on top of C.

Objective-C++ likewise on top of CFront.

Until like with CFront, they became selfhosted compilers.

Groovy code is Java code, regardless of targeting the JVM, the same syntax is supported and extended with dynamic capabilities.

Object Pascal was created for Lisa project, exactly in 1983.

Tom Love and Brad Cox created Objective-C in 1984.

Support for POD (plain old datatype) structs in C++ is definitely part of the language.

The public vs. private aspect also affects inheritance. structs publicly inherit from base types by default, classes privately inherit from base types.