Classes vs Unions and Structs
No one has really told me how to know when to and when not to use classes. Validate whether the statements below are true or false:
- Unions can contain variables, arrays, pointers and references, but nothing else.
- Structs can contain as much as unions can. They cannot contain functions except for constructors and de-constructors.
- Classes can contain anything. They can also control what is accessible to other parts of the program.
Also, I don't get why you need to separate things to either be private or public. Does it make your program run faster? Why not just make everything accessible?
This is where I fail at computer science. Sorry if I sound like an idiot.
- Unions can contain variables, arrays, pointers and references, but nothing else.
- Structs can contain as much as unions can. They cannot contain functions except for constructors and de-constructors.
- Classes can contain anything. They can also control what is accessible to other parts of the program.
Also, I don't get why you need to separate things to either be private or public. Does it make your program run faster? Why not just make everything accessible?
This is where I fail at computer science. Sorry if I sound like an idiot.
Last edited on
Unions can contain only PODs
Structs and Classes are the same but with different default member access ( public for struct and private for class )
See
http://www.cplusplus.com/doc/tutorial/other_data_types/
http://www.cplusplus.com/doc/tutorial/structures/
http://www.cplusplus.com/doc/tutorial/classes/
Structs and Classes are the same but with different default member access ( public for struct and private for class )
See
http://www.cplusplus.com/doc/tutorial/other_data_types/
http://www.cplusplus.com/doc/tutorial/structures/
http://www.cplusplus.com/doc/tutorial/classes/
Okay, this makes a lot more sense. So do those tutorials you posted explain why member access is needed? I don't get the point of it. I mean, is it performance related?
member access does not have anything to do with performance. It's about "encapsulation".
The idea with OOP/encapsulation is that you have a class which represents a very specific thing. By hiding some information (by making it protected/private), you prevent the user of the class from misusing it.
The user doesn't need to know how the class works internally. They just need to know how to interact with it.
A good example of this is the std::string class. Under the hood, this class does all sorts of things, like dynamic memory allocation, buffer sharing, reference counting, etc, etc. It's all a kind of magic. But none of that really matters because you don't have to know about any of it to use the class. You can just use its member functions and operator overloads to do all the work. In short -- it prevents the user from misusing the class. As a result, any novice can pick up and use std::string and not have to worry about memory leaks and other maintenance problems. The class "just works".
Encapsulation improves organization by keeping specific jobs the responsibility of specific classes. Keeping responsibilities organized like this makes it much easier to manage, especially when the program gets larger.
As a contrast... let's say you have a dynamically allocated buffer in your program. Something like this:
Now let's say that buffer does not have a clear owner, and the responsibility for reallocating/destroying it is not restricted to a single class (ie: any part of the program that needs to resize the buffer does it directly).
What happens when your program is 20+ source files large? What if there's a memory leak or heap corruption? How can you possibly hope to find the problem in such a large program -- because there was no clear organizational structure, the problem could be anywhere in the 20+ files.
Whereas if you encapsulte, the problem will be isolated to a few functions and will be much easier to find and fix (not to mention you'll be less likely to make the mistake in the first place).
The idea with OOP/encapsulation is that you have a class which represents a very specific thing. By hiding some information (by making it protected/private), you prevent the user of the class from misusing it.
The user doesn't need to know how the class works internally. They just need to know how to interact with it.
A good example of this is the std::string class. Under the hood, this class does all sorts of things, like dynamic memory allocation, buffer sharing, reference counting, etc, etc. It's all a kind of magic. But none of that really matters because you don't have to know about any of it to use the class. You can just use its member functions and operator overloads to do all the work. In short -- it prevents the user from misusing the class. As a result, any novice can pick up and use std::string and not have to worry about memory leaks and other maintenance problems. The class "just works".
Encapsulation improves organization by keeping specific jobs the responsibility of specific classes. Keeping responsibilities organized like this makes it much easier to manage, especially when the program gets larger.
As a contrast... let's say you have a dynamically allocated buffer in your program. Something like this:
|
|
Now let's say that buffer does not have a clear owner, and the responsibility for reallocating/destroying it is not restricted to a single class (ie: any part of the program that needs to resize the buffer does it directly).
What happens when your program is 20+ source files large? What if there's a memory leak or heap corruption? How can you possibly hope to find the problem in such a large program -- because there was no clear organizational structure, the problem could be anywhere in the 20+ files.
Whereas if you encapsulte, the problem will be isolated to a few functions and will be much easier to find and fix (not to mention you'll be less likely to make the mistake in the first place).
Topic archived. No new replies allowed.