[basic.stc.dynamic.general], [func.wrap.func], [any.class.general] "Dynamically allocated" is not defined

[Eisenwave]

In a number of normative paragraphs, we use the term "dynamically allocated", but it is never defined:

• "Objects can be created dynamically" ([basic.stc.dynamic.general] p1)
• "Implementations should avoid the use of dynamically allocated memory for small callable objects"
  • ([func.wrap.func.con] p5)
  • ([func.wrap.func.con] p7)
  • ([func.wrap.func.con] p15)
• "Implementations should avoid the use of dynamically allocated memory for a small contained value"
  • ([func.wrap.move.class] p2)
  • ([func.wrap.copy.class] p2)
  • ([any.class.general] p3)

We could generally fix this problem by talking about

objects with dynamic storage duration

... instead of

dynamically allocated objects

... or by talking about allocation functions.

Implementations should avoid the use of
-dynamically allocated memory
+storage obtained through allocation functions
for a small contained value.

Also, I'm not too hyped about the recommended practice being copied and pasted into three separate std::function constructors, but it's not the end of the world.

Note: I've noticed this issue when working on #7260.

[frederick-vs-ja]

Perhaps it's more consistent to say the way round (LWG4141) - implementations should make the small contained object nested within the constructed object.

[frederick-vs-ja]

I think there should be a follow-up LWG issue to ensure that when the target object is a function pointer or a reference_wrapper, it's always nested within the type-erased wrapper object. The current wording is too loose to ensure this.

[Eisenwave]

There is also [unique.ptr.general] p5:

[Note: The uses of unique_ptr include providing exception safety for dynamically allocated memory, passing ownership of dynamically allocated memory to a function, and returning dynamically allocated memory from a function. - end note]

I'm inclined to purging this note. It's not incorrect, but everyone and their dog knows what std::unique_ptr may be used for, so it's not too helpful. It also needs a "include, but are not limited to", since the current wording is needlessly exhaustive.

std::unique_ptr with a custom deleter can be used to manage all sorts of custom resources and is not limited to memory management.