views:

84

answers:

1

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

+8  A: 

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.

OK, 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 give 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.

Steve Jessop
@Steve : Good Answer. +1 `:)`
Prasoon Saurav
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"...
gokoon
@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".
Steve Jessop
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...
gokoon
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...
gokoon
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)?
Steve Jessop
I don't understand the irony...
gokoon
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.
Steve Jessop