Question

I didn’t know this before, but it turns out that:

[C++11: 3.7.5]: The storage duration of member subobjects, base class subobjects and array elements is that of their complete object (1.8).

That means that x->a in the example below has dynamic storage duration.

I’m wondering whether there are any elsewhere-defined semantics that make reference to storage duration that imbue member a with different behaviour between object *x and y? An example would be the rules governing object lifetime.

struct T
{
   int a;
};

int main()
{
   std::unique_ptr<T> x(new T);
   T y;
}

And how about if T were non-POD (and other kinds of UDTs)?

In short, my lizard brain expects any declaration looking like int a; to have automatic (or static) storage duration, and I wonder whether any standard wording accidentally expects this too.

---

Update:

Here’s an example:

[C++11: 3.7.4.3/4]: [..] Alternatively, an implementation may have strict pointer safety, in which case a pointer value that is not a safely-derived pointer value is an invalid pointer value unless the referenced complete object is of dynamic storage duration [..]

On the surface of it, I wouldn’t expect the semantics to differ between my x->a and my y.a, but it’s clear that there are areas, that are not obviously related to object lifetime, where they do.

I’m also concerned about lambda capture rules, which explicitly state “with automatic storage duration” in a number of places, e.g.:

[C++11: 5.1.2/11]: If a lambda-expression has an associated capture-default and its compound-statement odr-uses (3.2) this or a variable with automatic storage duration [..]

[C++11: 5.1.2/18]: Every occurrence of decltype((x)) where x is a possibly parenthesized id-expression that names an entity of automatic storage duration is treated as if x were transformed into an access to a corresponding data member of the closure type that would have been declared if x were an odr-use of the denoted entity.

and others.

Answer 1

No. This storage duration inheritance is what makes subobjects work. Doing anything else would simply be quite impossible. Else, you could not design any type that could be allocated both statically and dynamically.

Simply put, any violation of this rule would simply break everything.