Details
-
Bug
-
Resolution: Done
-
Major - P3
-
None
-
None
-
None
-
ALL
Description
The pre-C+11 standard for C+ does not confer POD-ness on derived types (subclasses), types with non-default constructors, non-default destructors, non-public non-static members, or virtual methods, or types that contain non-POD types.
C++11 defines a slightly more relaxed notion, called Standard Layout Types, which can have at most 1 superclass with non-static data members, plus some other rules, that is typically what we're after.
I don't have a recommended course of action, right now, but we're definitely relying on staying in the compiler's good graces, right now. One problem with non-POD types is that GCC won't let you use the offsetof() builtin to verify that the structure has the layout you desire, which means no static assertions that the structures have the expected shape in memory.
The following is an incomplete list of types where we count on the compiler choosing a particular layout, but the type itself is non-POD:
BSONObj::Holder
QueryResult
OpTime?
MaxKeyData
MinKeyData
JHeader
JSectFooter
DiskLoc
AtomicUInt
AtomicWord<T> (AtomicUInt64, AtomicUInt32)