那么现在struct可以有虚函数并且支持继承吗？那和上课有什么区别呢？信息隐藏的真正目的是什么？
可能的重复：
C++中struct和class有什么区别
http://www.cplusplus.com/reference/std/typeinfo/type_info /
我想我的“老师”并没有告诉我很多关于 C++ 中结构体和类之间的区别。
我在其他一些问题中读到，关于继承，结构默认是公共的...我还猜想结构没有构造函数/析构函数...
那么还有什么其他区别？它们有那么重要吗？
当谈到私有/受保护的属性/方法时，它们在运行时无法访问，只是因为编译器在编译时告诉它并报告错误，对吗？那么将这些特性与类进行比较，“信息隐藏”到底给程序员带来了什么？在这里，当有人重用该类时，这个人不会滥用该类，因为编译器将报告私有/受保护的内容？
我仍然在与信息隐藏的真正目的作斗争，它仍然想在我的脑海中听起来像是它为程序带来了更多的安全性，意味着更少的安全漏洞，但我真的对这种语言设计的目标感到困惑...... （我无意以任何方式反对 C++，我只是想了解在什么情况下这个功能可能有趣或不有趣；如果不是，那不是问题，但我只是想知道......）。
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...).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
就编译器而言，除了默认的可访问性之外，
struct和class之间没有任何区别。它们只是定义同一事物的两个不同关键字。因此，结构可以有构造函数、析构函数、基类、虚函数等等。就程序员而言，对于没有这些东西的类使用
struct是一种常见的约定（特别是 POD），或者更进一步，仅对根本没有用户定义成员函数、仅公共数据的类使用struct成员。人们有时会搞乱这个约定，因为很容易认为一个类是 POD，但实际上它不是，但至少他们在尝试。至少在 C++ 中，信息隐藏与安全性绝对无关。把它从你的脑海中抹去。它不提供任何安全性，除非以同样的一般方式，任何良好的编码实践都会使代码更容易推理，因此程序员会犯更少的错误。
信息隐藏的目的是允许您稍后更改实现，也许是删除或重命名私有成员，因为您知道班级本身和朋友之外的班级用户都不会引用它们。显然，这样做很有用，但不太明显，也许更重要的是，它很有用，因为它在代码中明确了您的类的接口是什么，您希望客户端使用，以及您的用户阶级可以理所当然地期待工作。原则上您可以通过文档实现相同的目标，但实际上编译器强制执行规则是件好事。
它不是“安全”的，因为在任何给定的编译器上都可以解决公共/私有保护。但是，如果你的班级的用户这样做，他们正在使用一些怪诞的黑客，当你改变你的班级时，他们应该停止编译/工作他们的代码，如果他们来找你抱怨你可以嘲笑他们。
As far as the compiler is concerned, there is no difference between
structandclassother 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
structfor classes with none of those things (specifically which are POD), or to go even further and usestructonly 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.