Definition of the term: free store

[FrankHB]

A recent change has altered the heading of [class.free]. This still leaves the term "free store" in the index. Unfortunately, there are no other places normativelly define that term (only mentioned as "free store management operators" in [intro.scope]), leading to confusions (e.g. in the comments in this SO answer).

For clarity, either all the occurrence should be removed, or there should be some more concrete normative definition of "free store", with its traditional meaning in computer science, being more consistent with the old uses in Bjarne Stroustrup's publications (than the old wording in [class.free]).

Further, it is still not sufficiently clear what is the "dynamic storage" (in [basic.stc.dynamic.general] et al.). Since we may have translation-time allocations, what does the "dynamic" here precisely mean? Moreover, should be "dynamic storage" and "dynamic storage management" in the index? These questions may deserve another issue, but are likely depending on the treatment on the problem above, so also included here for now.

[jensmaurer]

If we removed "free store" from the index, would that leave the mention in [intro.scope] as an English-level mention, or should we instead fix [intro.scope] to say "management operators for dynamic memory" and re-point the index entry of "free store" to "dynamic storage duration"?

(Those two are the only mentions of "free store" we have.)

[FrankHB]

The English-level mention may not work well, as the word "free" is ambiguous in English, and this is exactly the source of some confusions. Pointing "free store" to "dynamic storage duration" is also problematic in this sense.

I'm OK with "free store" once it is well-defined, albeit not the fact that we are lacking of the canonical/authoritative source besides ISO C++. (So searching the Web has little help at current.)

Whether to remove it away or not, we'd still better have the term to denote the region of the storage providing space for the allocation functions by default along with the storage duration. Anyway, the allocated storage are almost mandatory (except for impractical implementations always fail in standard allocation function calls) in C++, so it is virtually a part of the default configuration of the C++ abstract machine. This does deserve some core wording. Fix of [intro.scope] (if any) may better come later.

(BTW, I am personally not satisfied with the approach in ISO C which defers the descriptions of "allocated storage" to library clauses.)

[jensmaurer]

Ok, so removing mention of the undefined term "free store" from [intro.scope] is what we should do.

Note that we do know what "dynamic storage duration" is; where the memory comes from, is not really the standard's business. (Automatic variables might not be allocated on the stack, either.)

[FrankHB]

That would be OK to keep it editorial.

The standard does not care about where the source of the memory space is, but it may need to name it. This is not strictly needed in the current standard, but necessary for some finer-grained model, say, operational semantics, or readers would face to meta variables denoting such unnamed things.

Avoiding naming the stack is good, because C++ does not rely on the LIFO nature or the layout of the activation records, so it simplifies the specification and improves portability... until teaching users how "stack unwinding" or "stacktrace" is defined by the standard. (BTW, since the space is invisible, a conforming implementation is allowed to have arbitrary small space for automatic objects and any calls involving them would be fail randomly, i.e. UB. This is ... not that portable. Is this a well-known issue?)

[jwakely]

Yes, it's known, but there is no point worrying about hypothetical implementations that have such low resource limits that they are unusable. There are more important things to care about.

[frederick-vs-ja]

Ok, so removing mention of the undefined term "free store" from [intro.scope] is what we should do.

Note that we do know what "dynamic storage duration" is; where the memory comes from, is not really the standard's business. (Automatic variables might not be allocated on the stack, either.)

Oops, is the decision changed since then? @jensmaurer

[jensmaurer]

Uhm, sorry, didn't read all the history here.