Ask union and bit-field! !! !! !! !! !!

diamond52

1. The members in the union cannot be static, refer to, define the constructor, destructor, object of class type operator =
2. bit-field cannot be a static member of a class

Waiting for expert advice.

diamond52

My personal feeling
It may have something to do with references and class objects that provide explicit construction. From this point of view, static members are also the same. Its initialization is done by the system. It feels like this, but even if this is not very clear The specific internal mechanism, experts advise

diamond52

The bit field I understand so, because for the bit field, the type is to the compiler
It is still a common type, but the storage space is relatively special and can be specified. This work is left to the user to do. The initialization of static variables is carried out according to the original. An int is still allocated 32 bytes. If this is the case, the compiler handles static objects No special judgment

julines

Speculate
Once something is declared as static, it means that the thing is independent. For example, the static data members of the class are not placed in the object. For the union of shared space, the static keyword is completely meaningless. Since you have a place to stay outside, what else do you share here?

diamond52

This idea also makes sense, thank you

superandy

It will be different under each compiler.
Use unions and bit fields as little as possible.

diamond52

Doessuperandyhave this information?

superandy

There is no other information, only this sentence.

diamond52

...
Is my understanding correct?
What is the usual practice, general

珈蓝易拉罐

I think the first thing I should think of is that the union and bit fields in the C++ language are largely left for compatibility with C. This fact itself easily leads to the designers of the language just want to be compatible with them, and not want them to It is “perfectly” integrated with the other features of the language. In other words, on the basis of ensuring maximum compatibility, don’t bother with trouble. The simpler the better.

Regarding references, whether non-POD types can be members of union, this should be able to come up with a lot of negative reasons, such as:
(1) The reference is syntactically an alias of another object. So, how do you imagine a union instance, which can be an int and at the same time a "double alias"? (This is much more difficult to understand than "it can be an int or a double")
(2) Defining a union instance generally does not have explicit initialization, so how do you behave like one of its members (and also the common carrier of all other members) but must be explicitly initialized when it is defined?
(3) During the processing of operator=, the contents of previous objects are often cleaned first. How can one member be responsible for cleaning the information of another member?
(4) If two objects sharing the same memory have destructors, who will destruct when the entire union instance terminates?
(5) Similarly, when a union instance is created, whose constructor is called by default?
(6) What if one of the members does not have a default constructor?
In short, non-POD objects may be extremely complicated, "two objects share the same memory", my God, - don't think about it anymore. : P

There can be no static members in the union, one may be for compatibility, and the other is really not meaningful. The same is true for bit fields.
C++ is compatible with them, and of course, we should try not to change their original intention when they were designed in C language. (Think about what bit field and union are used for in C language? Adding a static member to union or making bit field as a static member should be things that their designers had never considered. )