By definition here, POD is a simple class with no user-defined constructors, non static members, and containing simple data types only.
The question is, will these 2 classes below be equivalent as POD types (in terms of memory footprint):
class pod
{
public:
int x;
double y;
};
class pod1
{
public:
int x;
double y;
enum POD_TYPE
{
POD1 = 0,
POD = 1
};
};
In other words does adding enum to the class only affects scope resolution of enum and does not affect properties of the class itself? By observation, it seems that class is still pod, but I would like to confirm based on the standard.
Yes, that type is still POD. The definition is given by C++11 9/10:
A POD struct is a non-union class that is both a trivial class and a standard-layout class, and has no non-static data members of type non-POD struct, non-POD union (or array of such types).
Trivial means that it doesn't do any funny business when creating, destroying or copying objects. Standard-layout means that it doesn't do any funny business with the layout of data members: no polymorphism, and restrictions on what you can do with access specifiers and inheritance. These terms are fully defined in C++11 9/6 and 9/7, if you want more detail.
Nested types (such as your enumeration), static data members and non-virtual member functions (apart from constructors etc. which would make it non-trivial) will not effect any of those things, so it is still POD.
UPDATE: Since you say you're interested in historic definitions, C++03 defined:
9/4 A POD-struct is an aggregate class that has no non-static members of type non-POD-struct, non-POD-union (or array of such types), and has no user-defined copy assignment operator and no user-defined destructor"
8.5.1/1 An aggregate is an array or class with no user-declared constructors, no private or protected non-static data members, no base classes and no virtual functions.
So there were more restrictions; but nested types were still allowed. I don't have a copy of C++98, but I'm sure that would be identical to C++03.
It doesn't make any difference regarding POD status because defining a nested enum does not add data members to the class. In fact, you could also define a nested class that is not POD inside pod1 and it would still not make a difference regarding the PODness of pod1.
The enum POD_TYPE is a type and won't effect the layout, we can see this from the draft C++ standard section 9.2 Class members paragraph 1 which says:
[...]Members of a class are data members, member functions (9.3), nested types, and
enumerators. Data members and member functions are static or non-static; see 9.4. Nested types are classes (9.1, 9.7) and enumerations (7.2) [...]
as opposed to data members and we can further see that the definition of a standard layout class depends only on data member from paragraph 16 which says:
Two standard-layout struct (Clause 9) types are layout-compatible if they have the same number of non-static data members and corresponding non-static data members (in declaration order) have layout-compatible types (3.9).
and we further see going back to section 9 Classes paragraph 10 which says(emphasis mine):
A POD struct108 is a non-union class that is both a trivial class and a standard-layout class, and has no non-static data members of type non-POD struct, non-POD union (or array of such types). Similarly, a POD union is a union that is both a trivial class and a standard layout class, and has no non-static data members of type non-POD struct, non-POD union (or array of such types). A POD class is a class that is either a POD struct or a POD union.
As far as I can tell the pre C++11 standard does not diff much in the above items.
Related
Standard-layout class describes a standard layout class that:
has no non-static data members of type non-standard-layout class (or array of such types) or reference,
has no virtual functions and no virtual base classes,
has the same access control for all non-static data members,
has no non-standard-layout base classes,
has all non-static data members and bit-fields in the class and its base classes first declared in the same class, and
given the class as S, has no element of the set M(S) of types as a base class, where M(X) for a type X is defined as:
If X is a non-union class type with no (possibly inherited) non-static data members, the set M(X) is empty.
If X is a non-union class type whose first non-static data member has type X0 (where said member may be an anonymous union), the set M(X) consists of X0 and the elements of M(X0).
If X is a union type, the set M(X) is the union of all M(Ui) and the set containing all Ui, where each Ui is the type of the ith non-static data member of X.
If X is an array type with element type Xe, the set M(X) consists of Xe and the elements of M(Xe).
If X is a non-class, non-array type, the set M(X) is empty.
(numbered for convivence)
However, the following fails:
#include <type_traits>
struct A {
int a;
};
struct B : A {
int b;
};
static_assert(std::is_standard_layout<A>::value, "not standard layout"); // succeeds
static_assert(std::is_standard_layout<B>::value, "not standard layout"); // fails
Demo
I see that 1-4 are true, so is one of points under 5 false? I find the points under 5 a little confusing.
The cppreference description is a little confusing.
The standard (search "standard-layout class is") says:
A standard-layout class is a class that:
has no non-static data members of type non-standard-layout class (or array of such types) or reference,
has no virtual functions (10.3) and no virtual base classes (10.1),
has the same access control (Clause 11) for all non-static data members,
has no non-standard-layout base classes,
either has no non-static data members in the most derived class and at most one base class with non-static data members, or has no base classes with non-static data members, and
has no base classes of the same type as the first non-static data member.
You can see from the part I emphasized that a class with a non-static data member and a base class that itself has a non-static data member is not standard-layout.
I suspect this point is described as follows in cppreference:
has all non-static data members and bit-fields in the class and its base classes first declared in the same class
The point is that you must be able to cast the address of a standard-layout class object to a pointer to its first member, and back. It boils down to compatibility between C++ and C.
See also: Why is C++11's POD "standard layout" definition the way it is?.
In c/c++ (I am assuming they are the same in this regard), if I have the following:
struct S {
T a;
.
.
.
} s;
Is the following guaranteed to be true?
(void*)&s == (void*)&s.a;
Or in other words, is there any kind of guarantee that there will be no padding before the first member?
In C, yes, they're the same address. Simple, and straightforward.
In C++, no, they're not the same address. Base classes can (and I would suspect, do) come before all members, and virtual member functions usually add hidden data to the struct somewhere. Even more confusing, a C++ compiler may also rearrange members at will, unless the class is a standard layout type (though I don't know that any compiler does so)
Finally, if the C++ struct is composed of standard layout types, contains no base classes nor virtual functions and all members have the same visibility, and possibly other limitations I forgot, then it falls back on the C rules, and requires the first member to be at the same address as the object itself.
§ 9.2/7
A standard-layout class is a class that:
— has no non-static data members of type non-standard-layout class (or array of such types) or reference,
— has no virtual functions (10.3) and no virtual base classes (10.1),
— has the same access control (Clause 11) for all non-static data members,
— has no non-standard-layout base classes,
— either has no non-static data members in the most derived class and at most one base class with non-static data members, or has no base classes with non-static data members, and
— has no base classes of the same type as the first non-static data member.
§ 9.2/20
A pointer to a standard-layout struct object, suitably converted using a reinterpret_cast, points to its initial member (or if that member is a bit-field, then to the unit in which it resides) and vice versa. [ Note: There might therefore be unnamed padding within a standard-layout struct object, but not at its beginning, as necessary to achieve appropriate alignment. —end note ]
Yes, it is.
It is guaranteed there is no padding before the first struct member in C and in C++ (if it is a POD).
C quote:
(C11, 6.7.2.1p15) "There may be unnamed padding within a structure object, but not at its beginning."
C++ quote:
(C++11, 9.2p20) "There might therefore be unnamed padding within a standard-layout struct object, but not at its beginning, as necessary to achieve appropriate alignment"
Does ISO C++ (11) permit a private non-static class member variable to be optimised away?
This could be detected:
class X { int x; };
assert (sizeof(X) >= sizeof(int));
but I am not aware of a clause that demands the assertion above.
To clarify: (a) Is there a clause in the C++ Standard that ensure the assertion above.
(b) Can anyone think of any other way to detect the elision of x?
[offsetof?]
(c) Is the optimisation permitted anyhow, despite (a) and (b)?
I have a feeling the optimisation could be possible if the class is local to a function but not otherwise (but I'd like to have a definitive citation).
I do not think it is forbidden, but I think it is impractical.
§9 Classes [class]
7/ A standard-layout class is a class that:
has no non-static data members of type non-standard-layout class (or array of such types) or reference,
has no virtual functions (10.3) and no virtual base classes (10.1),
has the same access control (Clause 11) for all non-static data members,
has no non-standard-layout base classes,
either has no non-static data members in the most derived class and at most one base class with non-static data members, or has no base classes with non-static data members, and
has no base classes of the same type as the first non-static data member.107
8/ A standard-layout struct is a standard-layout class defined with the class-key struct or the class-key class.
... thus class X { int x; }; is a standard-layout struct.
§9.2 Class members [class.mem]
16/ Two standard-layout struct (Clause 9) types are layout-compatible if they have the same number of non-static data members and corresponding non-static data members (in declaration order) have layout-compatible types (3.9).
... thus class X { int x; }; is layout-compatible with struct Y { int y; };.
The unfortunate thing is that layout-compatible is not formally defined in the Standard. However given the use of the word layout it seems the intent is to declare that two layout-compatible types should have the same underlying representation.
Therefore, to be able to remove the x in X one would have to prove that all structures that are layout-compatible (such as Y) are amenable to the same optimization (to keep the layout compatibility). It seems quite... improbable... in any non-trivial program.
I am new to C++. I read very frequently from some sites that variant member?.
class School
{
int x; -> data member.
}
I know data member. but what is variant member ?
NOTE:
From the c++ specification: Under Constructor page.
X is a union-like class that has a variant member with a non-trivial default constructor.
"Variant member" is defined in 9.5/8 of C++11:
A union-like class is a union or a class that has an anonymous union
as a direct member. A union-like class X has a set of variant members.
If X is a union its variant members are the non-static data members;
otherwise, its variant members are the non-static data members of all
anonymous unions that are members of X.
In other words, all the non-static data members of a union are "variant members", and for a class containing any anonymous unions, their non-static data members are "variant members" of the class.
The context that you quoted is 12.1/5, saying that if a union-like class has a variant member with a non-trivial default constructor, then the default constructor of the class itself is deleted. The problem is which variant member should be constructed by the default constructor of the class, and the solution is not to have a default constructor. If all variant members have trivial default constructors there's no problem, since by doing nothing the default constructor of the class is constructing all/none of them equally.
boost::variant is a separate thing. I wouldn't be too surprised if "some sites" say "variant members" when they mean "the possible types that a given boost::variant can hold", that is to say the "members" of that variant. But that's not the meaning newly-defined in the C++11 standard.
The term variant is usually employed to identify a member that can hold a value of a set of different types. Similar to a union in the language, the term variant is usually reserved for types that allow the storage of the different options in a type safe way.
You might want to read over the documentation of the boost variant library for one such example, and if that does not clear up the concept, drop a comment/create a question with your doubts.
Boost Variant
A variant is a structure containing a union member and an unsigned integer member that describes which member of the union is currently being used. If you don't know what a union is, read about it first, and then come back.
I have a class and a const variable.
struct A
{
int b;
};
A const a;
The class A is POD and can be initialized like this.
A const a = { 3 };
IMHO, it looks fine to have a constructor like this.
struct A
{
int b;
A(int newB) : b(newB)
{
}
};
But Clang assumes A as non-aggregate type. Why I can't have constructor like that? Or should I do something else?
I modified question to present my original meaning. I had wrote the struct as class by mistake, and sorry for #Johannes about confusing :)
POD means Plain Old Data type which by definition cannot have user-defined constructor.
POD is actually an aggregate type (see the next quotation). So what is aggregate? The C++ Standard says in section §8.5.1/1,
An aggregate is an array or a class
(clause 9) with no user-declared
constructors (12.1), no private or
protected nonstatic data members
(clause 11), no base classes (clause
10), and no virtual functions (10.3).
And section §9/4 from the C++ Standard says,
[....] 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-defined
copy assignment operator and no
user-defined destructor. Similarly, a
POD-union is an aggregate union 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-defined copy assignment
operator and no user-defined
destructor. A POD class is a class
that is either a POD-struct or a
POD-union.
From this, its also clear that POD class/struct/union though cannot have user-defined assignment operator and user-defined destructor also.
There are however other types of POD. The section §3.9/10 says,
Arithmetic types (3.9.1),
enumeration types, pointer types, and
pointer to member types (3.9.2), and
cv-qualified versions of these types
(3.9.3) are collectively called scalar
types. Scalar types, POD-struct types,
POD-union types (clause 9), arrays of
such types and cv-qualified versions
of these types (3.9.3) are
collectively called POD types.
Read this FAQ : What is a "POD type"?
The class A is POD and can be initialized like this
Sorry, that is wrong. Because b is private, the class is not a POD.
But Clang assumes A as non-aggregate type. Why I can't have constructor like that? Or should I do something else?
This is a limitation of C++ as it exists currently. C++0x will not have this limitation anymore. While in C++0x your type is not a POD either, your initialization will work (assuming that you make that constructor public).
(Also, I think a better term for you to use here is "aggregate". The requirement for using { ... } is that your class is an aggregate. It doesn't have to be a POD).
The other answers describe the POD rules pretty well. If you want to get a similar initialization style to a constructor for a POD you can use a make_-style function, for example:
struct A
{
int i_;
};
A make_A(int i = 0)
{
A a = { i };
return a;
}
now you can get initialized POD instances like:
A a = make_A();