[haiku-commits] Re: haiku: hrev52133 - src/apps/mediaconverter
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Fri, 27 Jul 2018 12:30:56 +0000
27 juillet 2018 10:13 "Stephan Aßmus" <superstippi@xxxxxx> a écrit:
By C++ standard, do you mean this link:
https://en.cppreference.com/w/cpp/language/union
? In there, it says
"The union is only as big as necessary to hold its largest data member. The
other data members are
allocated in the same bytes as part of that largest member. The details of
that allocation are
implementation-defined, ..."
In C++98 (
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf, ;
section 9.5), we have this:
"
In a union, at most one of the data members can be active at any time, that is,
the value of at most one of the data
members can be stored in a union at any time. [Note: one special guarantee is
made in order to simplify the use of
unions: If a POD-union contains several POD-structs that share a common initial
sequence (9.2), and if an object of
this POD-union type contains one of the POD-structs, it is permitted to inspect
the common initial sequence of any of
POD-struct members; see 9.2. — end note ] The size of a union is sufficient to
contain the largest of its data members.
Each data member is allocated as if it were the sole member of a struct. A
union can have member functions (including
constructors and destructors), but not virtual (10.3) functions. A union shall
not have base classes. A union shall not
be used as a base class. An object of a class with a non-trivial default
constructor (12.1), a non-trivial copy constructor
(12.8), a non-trivial destructor (12.4), or a non-trivial copy assignment
operator (13.5.3, 12.8) cannot be a member of a
union, nor can an array of such objects. If a union contains a static data
member, or a member of reference type, the
program is ill-formed.
"
So we have:
- A constraint on the minimal size of the union,
- A constraint on allowing access to the common part of the nested structs, but
only if they are POD (plain old data)
How this is actually implemented is not defined (in C++14 an additional
restriction is that all members of the union start at the same address), but in
C++98 this was not the case.
Moreover, these restrictions only apply if the content of the union is POD
("plain old data"). So, if an union contains non-POD, the second restriction is
removed and there is little we know about how the union is implemented. It may
have its own private fields in this case, or do anything else the compiler
finds suitable.
The next question is wether what we put in media_format is indeed a POD. The
definition of POD in C++98 was a bit more restrictive than needed, and as
Barrett mentionned, later on it was split into less restrictive things, one of
which is "standard layout". But as we are using C++98 in Haiku, let's focus on
that.
We find the definition of POD in chapter 9, paragraph 4:
"
A POD-struct is an
aggregate class that has no non-static data members of type non-POD-struct,
non-POD-union (or array of such types) or
reference, and has no user-declared copy assignment operator and no
user-declared destructor.
"
So, the checklist is (recursively, if there are nested structs and unions)
- No C++ references
- No copy assignment operator (operator= with the same type as a parameter)
- No destructor.
A custom destructor or copy assignment operator is already ruled out by the
definition of an union, as well as references. Which leaves me wondering in
which cases an union may be non-POD, and as such may have extra internal data
stored inside it by the compiler?
--
Adrien.
Other related posts:
