POD's Revisited (original) (raw)
Doc. no. WG21/N2102=06-0172
Date: 2006-10-31
Project: Programming Language C++
Reply to: Beman Dawes <bdawes@acm.org>
POD's Revisited; Resolving Core Issue 568 (Revision 1)
Introduction
Summary of proposed changes
To Do
Features and benefits of POD types
Motivating examples
std::pair example
Endian example
Two structs example
Atomic example
Coupling between POD's and aggregates
Rationale for changes
Proposed changes to the Working Paper
POD in the Standard, with changes
Impact on existing code
Impact on existing ABI's
Interactions with other proposals
Revision history
Acknowledgements
References
Introduction
This paper proposes a resolution forCore Issue 568, Definition of POD is too strict, submitted by Matt Austern.
POD's as defined in the current working paper has several problems:
- Overly strict requirements. This forces users to make unwise design choices, such as reliance on undefined behavior. See Motivating examples.
- Coupling between POD's and aggregates. The current definition of POD depends by reference on the definition of aggregate, causing several difficulties. See Coupling between POD's and aggregates.
- Coupling between trivial special member function needs and other needs. The Standard describes requirements as POD or non-POD in many places where trivial construction, copy, assignment, and destruction is the only actual concern. Separating these needs would result in a cleaner specification.
Summary of proposed changes
- POD's are now defined in terms of two new categories of types; trivial classes and standard-layout classes.
- The definition of these types no longer depends on the definition of aggregate.
- POD's and trivial classes are now allowed to have constructors. Default constructors with effects, and copy constructors, are still not allowed.
- POD's, trivial types, and standard-layout types are now allowed to have base classes. The base classes are not allowed to have non-static data members, virtual members, or virtual bases.
- POD's and standard-layout types are now allowed to have access control. All non-static data members must have the same access control.
- Most uses of POD in the WP were found to actually be concerned with only trivial or standard-layout types. Such uses have been changed accordingly.
To Do
The current language rules for initialization (8.5) sometimes require POD types. In this proposal, such requirements have been relaxed to only require trivial types. It is anticipated that these rules can be further refined and relaxed, but that work is deferred pending proposed wording to implement theN2100 Initializer lists proposal.
Features and benefits of POD types
Features | Benefits |
---|---|
Byte copyable guarantees [3.9 **�**2-3, basic.types] | Programs can safely apply coding optimizations, particularly std::memcpy. |
C layout-compatibility guarantees, byte copyable guarantees [9.2 **�**14-17, class.mem], initialization rules. | C++ programs can interoperate with functions written in C and other languages. C++ programs can, after considering compiler, alignment, and data type constraints, perform binary I/O such that files to interoperate with other languages and platforms. C language compatibility. |
Static initialization guarantees [3.6.2, basic.start.init] | Programs can avoid order-of-initialization issues. Multi-threaded programs can avoid data races during initialization. |
Are aggregates | Brace-enclosed initializer lists allowed. |
Various rules for non-POD's | Compilers apply data layout optimizations to non-POD's. Compilers assume non-aliasing, allowing code generation optimizations for non-POD's. |
Motivating examples
std::pair
example
Matt Austern provided this example:
If a program has two arrays of type std::pair<int,int>
, then it is natural to expect that memcpy(A2,A1,sizeof(A2))
would be safe. Programmers have trouble imagining any implementation in which a byte-for-byte copy of std::pair<int,int>
wouldn't do the right thing. Unfortunately, that's not what the language standard says. It says that byte-for-byte copies are guaranteed to work only for PODs. std::pair<T,U>
isn't a class aggregate, since it has a user-defined constructor, and that means it also isn't a POD.
std::pair
has a user-defined constructor essentially for syntactic reasons: because in some cases it looks nicer to write "std::pair<int,int> p(1,2);
" than to write "std::pair<int,int> p = {1,2};
". It seems a shame that this syntactic change caused the loss of the important semantic property of PODness. It's especially a shame because it means something formally doesn't work when on all real-world implementations it actually does work. It also encourages programmers to rely on undefined behavior, which is something the standard should not encourage.
With the proposed resolution, the example pair becomes a POD, solving the issue.
Endian example
Beman Dawes provided this example:
Here is an example of something in development for Boost, based on classes used in industrial applications for many years. The fact that it is a template partial specialization isn't material to this discussion and can be ignored.
template <typename T, std::size_t n_bits> class endian< big, T, n_bits, unaligned > : cover_operators< endian< big, T, n_bits >, T > { BOOST_STATIC_ASSERT( (n_bits/8)*8 == n_bits ); public: typedef T value_type; endian() {} endian(T i) { detail::store_big_endian<T, n_bits/8>(bytes, i); } operator T() const { return detail::load_big_endian<T, n_bits/8>(bytes); } private: char bytes[n_bits/8]; };
But it isn't a POD, so it won't work at all in unions and uses such as binary I/O rely on undefined behavior. Since the primary rationale for the existence ofendian
is to do binary I/O, forcing the user to rely on undefined behavior is unfortunate to say the least.
Here is what would have to be done to make it a POD:
Remove the constructors. But that makes initialization painful, so boosters are proposing to add an ugly and unintuitive static init function, and an
operator=
from thevalue_type
. Those are partial workarounds, but not really what the designers, Beman Dawes and Darin Adler, wanted.Make the data member public. But this encourages a poor design practice.
Eliminate the base class. But the only way to do that without the highly error-prone duplication of the functions provided by the base class is to introduce a lengthy macro. Enough said.
In other words, making this class a POD under current language rules would do serious damage to interface ease-of-use and to code quality, and would encourage poor design practices. Yet the only data member in the class is an array of char, so programmers intuitively expect the class to be memcpyable and binary I/O-able.
With the proposed resolution, the class becomes a POD, solving all the issues.
Two structs example
Matt Austern provided this example in Core DR 568:
It�s silly for the standard to make layout and memcpy guarantees for this class:
struct A { int n; };
but not for this one:
struct B { int n; B(n_) : n(n_) { } };
With either A or B, it ought to be possible to save an array of those objects to disk with a single call to Unix�s write(2) system call or the equivalent. At present the standard says that it�s legal for A but not B, and there isn�t any good reason for that distinction.
With the proposed resolution, the class becomes a POD, solving all the issues.
Atomic example
Lawrence Crowl provided this example.
Consider a class providing atomic operations. Among other requirements, it should:
- Be C-layout compatible.
- Be non-copyable.
For best C++ coding practice, the data should be private and the usual copy constructor and copy assignment idioms used to make the class non-copyable. But that would make the class a non-POD under current rules.
With the proposed resolution, the class becomes a standard-layout class, solving both issues.
Coupling between POD's and aggregates
POD's provide object representation guarantees, layout-compatibility guarantees, memory contiguity guarantees, and memory copy-ability guarantees for fairly simple types, yet leave compilers much latitude in such matters for more complicated types.
Aggregates provide well-defined initialization from initializer-clauses.
The two concepts are at most tangential, if not completely orthogonal. Thus to define POD in terms of aggregates creates an unnecessary and confusing dependency. It makes otherwise straightforward changes to the Standard POD and aggregate sections much more difficult because of the need to analyze a potential change for impact on both POD's and aggregates. The coupling is confusing to users, causing them to make mistaken assumptions about POD's. The coupling may be part of the reason even committee members cannot accurately remember the full rules for POD-ness.
Rationale for changes
The proposed changes decompose the current POD requirements into _trivial_type requirements and standard-layout type requirements, and remove the dependency on the definition of aggregates. Because these decomposed requirements are somewhat less restrictive than the requirements for aggregates, the effect is to make POD's more broadly useful and solve the problems identified in the Introduction and Motivating examples. It also opens up the possibility of designing useful classes that meet one or the other, but not both, of the new trivial and standard-layout requirements.
As a consequence of allowing members of any access control in standard-layout types, the current requirement that POD data members have no intervening access-specifiers is changed to require only that such data members have the same access control. This change is believed to also be more in line with programmer expectations than the current requirements.
Changes are not proposed that would allow POD's to have base classes with non-static data members. There was no apparent way to allow these cases without putting undue restrictions on how compilers allocate base class data in relation to derived class data.
This table summaries the new decomposition of requirements:
Requirement | Classes and types requirement applies to |
---|---|
Trivial default constructor or default constructor with no effects, trivial copy constructor, trivial copy assignment, trivial destructor; ditto members and bases. | trivial, POD |
No virtual functions, no virtual bases | trivial, standard-layout, POD |
All non-static members have same access control; no base classes with non-static data members; no non-static members are references; non-static member arrays also meet requirements. | standard-layout, POD |
Proposed changes to the Working Paper
Added text is shown in green and underlined. Deleted text is shown in red with strikethrough.
Commentary is shown in boxed italics.
Since issue 538 is currently in review status, changes to clause 9 paragraph 4 are shown relative to 538's proposed wording.
The following table lists all uses of POD, and related topics, in the current working paper, with proposed changes. Because the change to clause 9, paragraph 4,is critical to understanding the other changes, it is presented first.
Working Paper Text |
---|
9 �4 Classes [class] A union is a class defined with the class-key union; it holds only one data member at a time (9.5). [Note: aggregates of class type are described in 8.5.1. �_end note_] A trivial-class is a class that has a trivial default constructor (12.1) or a default constructor defined in the class definition and having no effects, a trivial copy constructor (12.8), a trivial copy assignment operator (13.5.3, 12.8), and a trivial destructor (12.4). [Note: That precludes virtual functions, virtual bases, and members or bases with non-trivial default constructors having effects, non-trivial copy constructors, non-trivial copy assignments, or non-trivial destructors. _--end note_] 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, and� has no virtual functions (10.3) and no virtual base classes (10.1), and� has the same access control (clause 11) for all non-static data members, and � has no non-standard-layout base classes, and no base classes with non-static data members. A standard-layout-struct is a standard-layout class defined with the class-key struct or the class-key class. A standard-layout-union is a standard-layout class defined with the class-key union. [Note: Standard-layout classes are useful for communicating with code written in other programming languages. The layout is specified in 9.2. -- end note_] A POD class is |
1.8 �5 [intro.object] Unless it is a bit-field (9.6), a most derived object shall have a non-zero size and shall occupy one or more bytes of storage. Base class subobjects may have zero size. An object of |
3.6.2 �1 Initialization of non-local objects Objects with static storage duration (3.7.1) shall be zero-initialized (8.5) before any other initialization takes place. A reference with static storage duration and an object of |
3.8 �2 Object Lifetime [ Note: the lifetime of an array object or of an object of |
**3.8 �5 Object Lifetime**Before the lifetime of an object has started but after the storage which the object will occupy has been allocated39) or, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any pointer that refers to the storage location where the object will be or was located may be used but only in limited ways. Such a pointer refers to allocated storage (3.7.3.2), and using the pointer as if the pointer were of type void*, is well-defined. Such a pointer may be dereferenced but the resulting lvalue may only be used in limited ways, as described below. If the object will be or was of a class type with a non-trivial destructor, and the pointer is used as the operand of a delete-expression, the program has undefined behavior. If the object will be or was of a |
**3.8 �6 Object Lifetime**Similarly, before the lifetime of an object has started but after the storage which the object will occupy has been allocated or, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any lvalue which refers to the original object may be used but only in limited ways. Such an lvalue refers to allocated storage (3.7.3.2), and using the properties of the lvalue which do not depend on its value is well-defined. If an lvalue-to-rvalue conversion (4.1) is applied to such an lvalue, the program has undefined behavior; if the original object will be or was of a |
**3.9 �2 Types**For any object (other than a base-class subobject) of |
**3.9 �3 Types**For any |
**3.9 �4 Types**The object representation of an object of type T is the sequence of N unsigned char objects taken up by the object of type T, where N equals sizeof(T). The value representation of an object is the set of bits that hold the value of type T. For |
**3.9 �10 Types**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.Scalar types, trivial-class types (clause 9), arrays of such types and cv-qualified versions of these types (3.9.3) are collectively called trivial types.Scalar types, standard-layout-class types (clause 9), arrays of such types and cv-qualified versions of these types (3.9.3) are collectively called standard-layout types. |
_3.9 �11 Types_If two types T1 and T2 are the same type, then T1 and T2 are layout-compatible types. [ Note: Layout-compatible enumerations are described in 7.2. Layout-compatible |
_5.2 �7 Postfix expressions_When there is no parameter for a given argument, the argument is passed in such a way that the receiving function can obtain the value of the argument by invoking va_arg (18.8). The lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) standard conversions are performed on the argument expression. After these conversions, if the argument does not have arithmetic, enumeration, pointer, pointer to member, or class type, the program is ill-formed. If the argument has a |
**5.3.4 �16 New**A new-expression that creates an object of type T initializes that object as follows: � If the new-initializer is omitted: � If T is a (possibly cv-qualified) |
5.9 �7 Relational operators [expr.rel] Pointers to objects or functions of the same type (after pointer conversions) can be compared, with a result defined as follows: ... � If two pointers point to non-static data members of the same object, or to subobjects or array elements of such members, recursively, the pointer to the later declared member compares greater provided the two members |
_5.19 �4 Constant expressions_An address constant expression is a pointer to an lvalue designating an object of static storage duration, a string literal (2.13.4), or a function. The pointer shall be created explicitly, using the unary & operator, or implicitly using a non-type template parameter of pointer type, or using an expression of array (4.2) or function (4.3) type. The subscripting operator [] and the class member access . and -> operators, the & and * unary operators, and pointer casts (except dynamic_casts, 5.2.7) can be used in the creation of an address constant expression, but the value of an object shall not be accessed by the use of these operators. If the subscripting operator is used, one of its operands shall be an integral constant expression. An expression that designates the address of a subobject of a |
_5.19 �5 Constant expressions_A reference constant expression is an lvalue designating an object of static storage duration, a non-type template parameter of reference type, or a function. The subscripting operator [], the class member access . and -> operators, the & and * unary operators, and reference casts (except those invoking user-defined conversion functions (12.3.2) and except dynamic_casts (5.2.7)) can be used in the creation of a reference constant expression, but the value of an object shall not be accessed by the use of these operators. If the subscripting operator is used, one of its operands shall be an integral constant expression. An lvalue expression that designates a member or base class of a |
**6.7 �3 Declaration statement**It is possible to transfer into a block, but not in a way that bypasses declarations with initialization. A program that jumps82) from a point where a local variable with automatic storage duration is not in scope to a point where it is in scope is ill-formed unless the variable has |
**6.8 �4 Ambiguity resolution**The zero-initialization (8.5) of all local objects with static storage duration (3.7.1) is performed before any other initialization takes place. A local object of |
8.5 �5 Initializers To default-initialize an object of type T means: � if T is a |
**8.5 �9 Initializers**If no initializer is specified for an object, and the object is of (possibly cv-qualified) |
**8.5 �14 Initializers**When an aggregate with static storage duration is initialized with a brace-enclosed initializer-list, if all the member initializer expressions are constant expressions, and the aggregate is a |
8.5.1 �1 Aggregates An aggregate is an array or a class (clause 9) with no user-declared constructors (12.1), no private or protected non-static data members (clause 11), no base classeswith non-static data members (clause 10), and no virtual functions (10.3). Portland meeting: "no user-declared constructors" wording unchanged at request of CWG. |
9.2 �12 Class members [class.mem] Nonstatic data members of a (non-union) class |
9.2 �15-18 Class members [class.mem] 15 Two |
**9.5 �1 Unions**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 |
11.1 **�3 Access Specifiers**The order of allocation of data members with |
**12.6.2 �4 Initializing bases and members**If a given non-static data member or base class is not named by a mem-initializer-id (including the case where there is no mem-initializer-list because the constructor has no ctor-initializer), then � If the entity is a non-static data member of (possibly cv-qualified) class type (or array thereof) or a base class, and the entity class is a |
12.7 �1 Construction and destruction For an object of |
**17.1.3 character container type**a class or a type used to represent a character (17.1.2). It is used for one of the template parameters of the string and iostream class templates. A character container class shall be a POD (3.9) type. No change proposed; there is no known motivation for any change. |
**18.1 �4 Types**The macro offsetof(type, member-designator) accepts a restricted set of type arguments in this International Standard. If type is not a |
_20.4 type traits_To 20.4.2, Header <type_traits> synopsis [lib.meta.type.synop], type properties, add: template struct is_trivial; template struct is_standard_layout; To 20.4.5.3 Type properties [lib.meta.unary.prop], Type Property Predicates table, add: Template Condition Preconditions template struct is_trivial; T is a trivial type ([basic.types]) T shall be a complete type. template struct is_standard_layout; T is a standard-layout type ([basic.types]) T shall be a complete type. |
_21 �1 Strings library_This clause describes components for manipulating sequences of �characters,� where characters may be of any POD (3.9) type. In this clause such types are called char-like types, and objects of char-like types are called char-like objects or simply �characters.� No change. Users expect c_str() and data() to return pointers to POD types. |
**25.4 �4 C library algorithms**The function signature: qsort(void *, size_t, size_t, int (*)(const void *, const void *)); is replaced by the two declarations: extern "C" void qsort(void* base , size_t nmemb , size_t size, int (*compar )(const void*, const void*)); extern "C++" void qsort(void* base , size_t nmemb , size_t size, int (*compar )(const void*, const void*)); both of which have the same behavior as the original declaration. The behavior is undefined unless the objects in the array pointed to by base are of |
Impact on existing code
The proposed changes will cause some existing non-POD's to become POD's. This may result in less optimization being performed. The problem can be eliminated by adding a user-defined do-nothing destructor.
Adding a user-defined do-nothing destructor to existing code to leave POD-ness unchanged is simple enough that it could be done programmatically. If a compiler vendor felt this was a serious concern for their user-base, they might wish to provide such a program. Alternately, compilers may wish to issue warnings during a transition period if the new rules change a non-POD into a POD.
Impact on existing ABI's
Allowing standard-layout classes to have base classes, even restricted to base classes without non-static data members, forces compilers to implement the empty base optimization for standard-layout classes, and this could break a compiler's application binary interface (ABI). See 9.2/18above.
Although this issue is still being investigated, it is believed not to be a concern for modern compilers, except in the case of multiple inheritance. Since multiple inheritance is not central to this proposal, allowing standard-layout classes or their bases to use multiple inheritance will be eliminated from the proposal if it proves contentious.
Interaction with other proposals
SeeN1824, Extending Aggregate Initialization. Whichever proposal is accepted first, the other will have to be reviewed, and possibly revised, accordingly.
SeeN2100, Initializer lists (Rev. 2). The authors of the Initializer lists proposal and the POD proposal are committed to working together to ensure the two proposals stay in sync.
See Core issue 538, Definition and usage of structure, POD-struct,POD-union, and POD class. This issue, currently in review status, clarifies POD related terminology throughout the working paper. Since it makes changes to the same text modified by this proposal, care must be taken to ensure the two proposals do not diverge.
Revision history
Revision 1 -N2102
- Review and refinement of all wording.
- Changed name from byte-copyable-class to trivial-class, to reflect properties rather than uses.
- Added standard-layout class definition, in response to use cases that were legitimately non-copyable, but otherwise met POD requirements.
- Changed proposed wording to be relative to issue 538's proposed wording.
- Made corrections based on discussions with Core and Evolution working groups at the Portland committee meeting.
- Added section discussion ABI issues.
Initial version -N2062
Acknowledgements
Matt Austern, Greg Colvin, Alisdair Meredith, and Clark Nelson provided helpful comments during preparation of this proposal. Our cat Jane woke me up in the middle of the night, provoking this proposal as an alternative to counting sheep (or cats).
Revision 1 - Greg Colvin and Lawrence Crowl provided legitimately non-copyable use cases. Alberto Ganesh Barbati pointed out that the proposed resolution should be relative to the 538 proposed resolution. Martin Sebor pointed out the need for clarification of 11.1, p3. The EWG and CWG in Portland reviewed a draft of revision 1 and made many helpful comments and suggestions. Clark Nelson is facilitating progress through Core. A suggestion was made that trivial types be renamed inert POD's, or IPOD's. Mike Miller suggested that apod_cast
operation be provided to ensure interoperability between POD's and IPOD's.
References
N1824 Extending Aggregate Initialization, Alisdair Meredith, www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1824.htm
Core issue 538.www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#538, Definition and usage of structure, POD-struct, POD-union, and POD class.
Core issue 568.www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#568, Definition of POD is too strict.