Question

Possible Duplicate:
What are the differences between struct and class in C++

http://www.cplusplus.com/reference/std/typeinfo/type_info/

I guess my “teacher” didn’t tell me a lot about the differences between struct and classes in C++.

I read in some other question that concerning inheritance, struct are public by default… I also guess struct doesn’t have constructors/destructors…

What are the other differences then ? Do they matter that much ?

And when speaking about private/protected attributes/methods, they aren’t accessible at runtime, only because the compiler tells it so at compile time and reports an error, right ? Then comparing those features with classes, what does “information hiding” really bring to the programmer ? Is it here so that when somebody reuse the class, this person won’t misuse the class because the private/protected stuff will be reported by the compiler ?

I still struggle with the real purpose of information hiding, it still want to sound in my head like it brings more security in programs, meaning less security breaches, but I’m really confused about the goal of such design in the language… (And I Don’t intend to be against C++ in any way, I just to understand in what cases this feature can be interesting or not; if not, that’s not a problem, but I just like to know…).

Answer 1

As far as the compiler is concerned, there is no difference between struct and class other than the default accessibility. They’re just two different keywords for defining the same thing. So, structs can have constructors, destructors, base classes, virtual functions, everything.

As far as programmers are concerned, it’s a common convention to use struct for classes with none of those things (specifically which are POD), or to go even further and use struct only for classes with no user-defined member functions at all, only public data members. People sometimes mess this convention up, because it’s surprisingly easy to think a class is POD when it isn’t, but at least they’re trying.

In C++, at least, information hiding is absolutely nothing to do with security. Put that right out of your mind. It does not provide any security, except in the same general way that any good coding practice makes for code that’s easier to reason about, and hence programmers make fewer mistakes.

The purpose of information hiding is to allow you to change the implementation later, perhaps to remove or rename private members, safe in the knowledge that none of the users of your class, outside the class itself and friends, is referring to them. Obviously it’s useful to do exactly that, but less obviously and perhaps more importantly, its useful because it makes explicit in the code what your class’s interface is, that you want clients to use, and that users of your class can rightfully expect to work. You can achieve the same thing in principle with documentation, but in practice it’s nice for the compiler to enforce the rules.

It’s not “secure” because on any given compiler it’s possible to work around public/private protection. But if users of your class do that, they’re using some grotesque hack, they deserve for their code to stop compiling/working when you change your class, and if they come to you to complain you can laugh at them.