C + + When to use a struct, when to use class

struct is introduced by C language. In the C language, it is the standard choice for defining structured data.

C + + supports both struct and class. One reason is that C + + is a superset of C, covering the language features supported by C, will better support backward compatibility (originally able to work C source program ported to C + +, can pay very little or even 0 cost)

In fact, the C + + class has completely covered the struct, that is to say, the original struct implemented with structs, can be completely replaced by class.

So the problem comes out, a new project, when should use a struct, the same thing, with a struct or class implementation, there is no difference in performance.

Structs and classes are practically indistinguishable in C + +.

Structs can still inherit from another struct (rarely seen by someone doing so).

The default field type for a struct is public, the default is public, and the default field type for class is private, and the default inheritance is private.

No documentation has been described that the struct is faster than class. Personal feeling since struct and class are interchangeable in implementation, that is, to support the same language-level infrastructure and complexity, there should be no faster problem (same-level object, you can't take a rect struct with 4 fields and a Hashtable Compared to Resmanager)

Because of the substitution of struct and class, it is quite subjective to choose when to use a struct and when to use class. Often everyone's intuition is consistent: structs should be applied to objects of the pod (Plain old data) type. In a word, they are more like records, a simple set, with several fields, such as struct Color, struct Rect, struct point, and so on, which are our common structures.

While class is actually more appropriate for abstract active objects, they can often have complex inheritance relationships (individuals think too complex is a dead behavior, explained later). There may be more methods and logic. For class, the internal data, in addition to being recorded, is part of the "state".

Another benefit of a struct is:

It can be conveniently serialized and deserialized, for example, to get a pointer to a struct directly. sizeof gets the size that directly stores the object to a file or writes to the network. For some reason, of course. I don't recommend it either.

I'm actually more inclined to object-based and against pure object-oriented.

In textbooks, to teach people to use C + +, this is usually the example:

Well, now that you define a "person", then his inheritance tree should look like this:

There is MO, there is no such.

People also have such methods as talking, eating, and deceiving other people's feelings and bodies.

Monkeys have to be simple, they only call, but since they all inherit from mammals, they all inherit from the mammalian method of feeding. As for the plant system, of course, it is not so advanced, but he and mammals, like, and from the livingthing there inherited something, such as growth and death. Of course I admit that the vegetable is joking.

There are some examples of transportation. It looks so elegant, code reusability is super high.

For this object-oriented way of thinking, I just want to say that see this code, you can directly dragged out to shoot. The reason is, a slightly more complex project, no one would do so. Because the depth of the inheritance tree affects complexity in exponential ways. One day you will find that you want to achieve a Superman, do not have the means to change a base class method, do not know which classes he will eventually affect.

I agree with Muduo's author who's opinion:

When you want to modify a code (probably fix a bug or add a new feature), the first thing to do, is definitely not to go straight to the sleeve to start the dry code. The first is to figure out how to change. In order to come up with a plan, you first need to understand the current code, to understand the code, just like memory loading data. Elegant code, you just need to know very little about the relevant code (which is why it advocates decoupling). So if the code is shown: I'd like to ask if your brain has been upgraded this year.

I myself accept the principle that service and data separate, modularity is more important than object-oriented, but also in the premise that the infrastructure framework is stable. Component-based design principles are also extremely cool, especially for game development. The engine of Unity3d is component-based. Everything is a component.

Well, of course this is another issue. I seem to be in a serious digression.

So this year is 2015 years. Last time I updated my blog, it's been 7 years since I wiped the 2008 from now.

Now I'm back.

Sometimes in the head a lot of specious things, rather seriously to investigate, and then write a log as a record.

Anyone brawl taunt is also welcome.

C + + When to use a struct, when to use class