So now struct can have virtual function and support inheritance ? What difference with classes then ? What the true purpose of information hiding?

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...).

Solution

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.

Comments

[Prasoon Saurav]

@Steve : Good Answer. +1 :)

[jokoon]

These are very little advantages... And I still don't understand what is the purpose of inheritance when you can just spawn an object from another class inside it... OOP is really my progamming nightmare... When thinking about code speed and memory footprint I still can't really know what's the purpose, except making the source more "reality friendly"...

[Steve Jessop]

@gokoon: you didn't ask about the purpose of inheritance, that's a whole other question from the purpose of information-hiding. I'd advise you to stop thinking much about code speed and memory footprint, though. My PC has approximately 10-100 times the speed and memory I usually need, so I can afford quite a lot in return for source that's easier to work with. In the unusual cases where speed or memory use is within a factor of 10 of the danger zone, that's when you spend a lot of time thinking about it. The rest of the time just avoid totally inappropriate algorithms and structures.

[Steve Jessop]

And I'm sorry, I don't know what you mean by, "you can just spawn an object from another class inside it".

[jokoon]

in game programming speed is some kind of vital matter... maybe I'm not yet at the level of making a game with a lot a cpu requirements, but I think about it...

[jokoon]

I meant struct a; struct b { a A; }; here the object is inside, but instead I could have done struct b : public a {}; to just inherit from a... I can do both, and I can't find any advantage...

[Steve Jessop]

Ironically, many high-performance games write a significant amount of code in lua, which is an object-oriented, scripting-style language that typically runs in an interpreter in the game. For the unusual cases demanding high performance (physics engine, graphics manipulation) they break into C++, or into GPU stuff like shader pipelines that I don't understand.

[Steve Jessop]

@gokoon: regarding interitance vs. embedding, the main difference is whether you want your objects of type b to actually be whatever it is that a represents, or whether you just want them to have/use an object of type a. For instance if a is std::fstream, then is your class b a specific kind of filestream (inherit), or is it just that it has a filestream that it uses for some purpose (embed)?

[jokoon]

I don't understand the irony...

[Steve Jessop]

Well, humorous incongruity. That while you're worried about the overheads of C++, other games programmers are bashing out vast amounts of code that's far less run-time efficient. Actually, though, the reason they do this is so that skilled developers can focus their time optimising the few bits that matter, rather than dispersing their efforts worrying about the whole code base. Even a solo developer should do likewise: most code doesn't need optimisation.

[jokoon]

I meant that when you implement code, you answer a problem with a solution. That's what programming is all about. What is bugging me, is that embedding vs. inheriting is just a design or philosophical choice, not a programming one. Also, polymorphism is not really a feature if you constantly require to cast your objects pointers.

[Mooing Duck]

@jokoon: You should not be casting object pointers. If you are, you aren't doing polymorphism right.

[jokoon]

How so? How do you not cast while using polymorphism?