Do I kill a kitten each time I use struct everywhe

Question

struct is public by default while class is private by default.

Lets take Ogre3D for example; if I change all class occurences with struct, it compiles (I guess), and the engine works just as before.

If I'm right, the compiled code is exactly the same as before, because it's only the compiler that does check if a private/protected methods are called, it's not checked at runtime.

If I'm still right, class is just a keyword that just makes its cute eyes and begging "please encapsulate your data: you'll save a kitten", while private/protected scopes are still up to the user.

I know I sound kinda lame or irrelevantly rebel (something like "C is KISS dude, don't go "

Back to the question: what does the standard say about this little difference between struct and class while generating machine code ? Why add a keyword and try to impress programmers with the so called "OO model" while it's totally not enforced then ? Was it influenced by java ?

Answer 1

There are people who try to use the 'struct' keyword to mean various things. For example, some people attempt to use struct to specify POD-ness or to be only data classes (classes with only public member variables and no functions).

In my opinion this is a serious mistake and all the reasons I've heard for it are flawed. For one thing, a keyword like struct is not sufficient to express the conditions they are attempting to use it to document. Since the keyword actually doesn't mean anything in particular people either accept this, or attempt to assert their own idea of what it should mean. There are too many incompatible opinions on what struct should mean in code for it to document any of them. You want to document things like, "This object must always be a POD," as clearly as possible instead of relying on obscure team standard details that can be difficult to remember. So, in order to document such a thing the only sufficient thing, honestly, is, // This object must always be a POD. It's clear, simple, and can't be misinterpreted by anyone who knows what a POD is, and this is well defined.

The best argument I've ever heard for using the keyword class instead of struct is that you should prefer private access to public access, revealing only that which is necessary. In other words, the "default" kind of inheritance and access exposure should be private until it is shown that more access is necessary. I agree with this opinion but I don't agree it is necessary to use the struct keyword to adhere to this principle.

Whatever one decides is going to be fairly arbitrary. Reasons can later be asserted for the decision but I find people who've chosen one or the other aren't easy to convince. I switched from 'class' to 'struct' because I read too many books on modern C++ and too much boost code; you'll rarely see the 'class' keyword in either. Truth be told, it doesn't matter; follow the standards of the team you are in at the time. In my opinion, adding a keyword that is essentially meaningless was a mistake.

Edit: Although, I do have to say that another reason I dislike using class is that it means too many things even while it also means nothing in particular. For example, you can use class instead of typename in template parameter specifications. Even if you use the class keyword you can pass any type and not necessarily any kind of class (like int). The only time I like to use the class keyword is where it actually does mean something and where you actually absolutely have to: specifying template template parameters.

Answer 2

No other differences but default access. Actually you may even write something like:

class X;

X* pX;

struct X {};

And it must compile.

Answer 3

The difference between struct and class is just the default access level of the bases and attributes, and access levels are only verified at compile time, so you might be tempted to get some library edit the headers and change all class with struct to gain access to the internal details.

Don't

Compilers are not required to generate exactly the same code if you change the default access specifier. In particular this two classes could or not have the same memory layout, depending on the compiler:

struct a {
   int a;
private:
   int b:
};
class b {
   int a;
public:
   int b;
};

The reason is that the standard requires all member attributes to be laid out in memory in increasing positions within the same access qualifier. Compilers are allowed (I don't know any that does, but since this is not a requisite it may well change in the next version), to reorder the fields from different access blocks. A compiler could decide that public attributes come first, while private come at the end of the object, and that would mean that the position of fields a and b in the two classes would be swapped.

Answer 4

No. The difference between a struct and class is limited to the default accesibility of their members and inheritance. Both are public for struct and private for class

Answer 5

struct exists for legacy reasons and that's it. You don't kill a kitten or anything anytime you use struct instead of class or indeed vice versa- they're the same thing, realistically, with a slightly different keyword and default.

Answer 6

No, it was definitely not influenced by Java. Check the timeline. :)

Even if it doesn't do any more than control default visibility, that's still pretty meaningful. It somewhat becomes a matter of having the semantics available that allow you to say what you mean. The idea that, if you're using struct, then you're probably working within an older paradigm where public visibility is the only kind that would normally be thought of, and if you're using class, you're thinking in more OO terms where private visibility is held in higher esteem -- I dunno, makes sense to me dude.