search

cplusplus / draft

C++ standards drafts
http://www.open-std.org/jtc1/sc22/wg21/
5.68k stars 749 forks source link

[allocator.requirements.general] The meaning of "parameterized in terms of allocators" seems unclear #5528

Open frederick-vs-ja opened 2 years ago

frederick-vs-ja commented 2 years ago

[allocator.requirements.general]/1 says

All of the string types, containers (except array), string buffers and string streams ([input.output]), and match_results are parameterized in terms of allocators.

It's not very clear for me whether this sentence imposes some normative requirements, or if it does, what the requirements are, and [syncstream] is not yet covered.

Perhaps it means

If any template in [strings], [containers], [input.output], or [re] is instantiated and any template parameter named Allocator, Alloc, or SAlloc is substituted with a type that does not meet the Cpp17Allocator requirements, the behavior is undefined.

Not sure whether an LWG issue is needed.

jwakely commented 2 years ago

No, there is requirement imposed by that wording. It's just telling you that you can use allocators with them.

jwakely commented 2 years ago

i.e. they have a template parameter that gets substituted with an allocator type.

If those class templates have a precondition that their Allocator parameter meets the Allocator requirements, then those class templates should state that themselves. [allocator.requirements.general] is the wrong place to do that.

frederick-vs-ja commented 2 years ago

So... is the current wording implying that basic_syncbuf<CharT, Traits, NonAllocator> may be well-defined, while basic_osyncstream<CharT, Traits, NonAllocator> results in UB?

jwakely commented 2 years ago

No. Like I said, there is no normative requirement being imposed here.

It's just an informative remark saying "hey, there are types in the library that have a template parameter where you can put an allocator". It's not saying "and if you do it wrong you will die".

The list of types is incomplete, which should be fixed, but you should not be trying to infer some deep meaning from this sentence, or from the fact the list is incomplete.

frederick-vs-ja commented 2 years ago

Oh I see. Thank you for interpretation!

The Cpp17Allocator requirement is seldom used in the library spec. Is it intended that most allocator-aware utilities (e.g. containers) don't actually require their allocator_type to be Cpp17Allocator?

jensmaurer commented 2 years ago

Yes. Those places use the magic word "allocator", which is defined in [allocator.requirements.general]p1 (note italics). So, anywhere we say "allocator" we mean a class satisfying [allocator.requirements.general].