[diff.cpp03.containers] Add overdue compatibility note on allocators #5835
Conversation
Revisiting my abandoned paper P0177, there was approval to add this historical compatibility with C++03 text back in 2016, but I never turned it into an editorial request after abandoning the paper.
| \effect | ||
| \tcode{allocator_traits} supplies default definitions for many allocator type | ||
| names and operations. Valid \CppIII{} code that follows the original | ||
| allocator-aware container requirements may not support allocators written to |
There was a problem hiding this comment.
There were no "allocator-aware container requirements" before C++11, so it's unclear what "the original" ones are. We did have Allocator requirements in C++03, and those are what changed dramatically.
Maybe it would help to have an example showing a function template with an Allocator parameter, assuming the presence of pointer and construct members, which need to be accessed via allocator_traits since C++11.
|
Additional note: turns out this is Pending NAD Editorial issue http://cplusplus.github.io/LWG/lwg-closed.html#2178. I will try to clean this up so we can finally remove the Pending! |
| \tcode{allocator_traits} supplies default definitions for many allocator type | ||
| names and operations. Valid \CppIII{} code that follows the original | ||
| allocator-aware container requirements may not support allocators written to | ||
| the simpler set of requirements in this standard, and may propagate allocators |
There was a problem hiding this comment.
IMO allocator propagation deserves a separated paragraph since corresponding change in C++11 doen't seemly simplify user codes.
Library supports for stateful allocators were essentially conditionally-supported extensions in C++03, while being precisely required and specified since C++11. Incompatibility may come from the conflict between standard and (pre-standard) extented mechanisms (only when using stateful allocators with standard containers).
|
Annex C is for previously-valid code that becomes invalid or changes meaning with a new standard. Are there any actual allocators in later C++ that had their pointer and construct members removed? Otherwise, all allocators that were written for C++-old will have those members, and nothing breaks. There should be no Annex C entry for stuff that merely was underspecified or a popular extension. Please provide an example of previously-valid code that becomes invalid or changes meaning with a new standard. |
|
The code that breaks is user authored container templates, instantiated with an allocator specified according to C++11. I will add an example when I revise the PR later today. |
|
But that's not a breakage we can meaningfully record in Annex C: The code you sketch wouldn't compile with C++03, so it's not the case of valid code becoming invalid or changing meaning. |
|
As noted, I extracted this edit from the abandoned P0177 (which may resurface shortly). This passed LEWG review as maybe worthwhile in 2016, but I could not honestly claim it was a strong endorsement :). I wrote this wording up as I recall concerns during the C++11 standardization of this feature that we were breaking backwards compatibility for concepts (not implying the language term) though, rather than existing code. Templates that satisfied their requirements would no longer serve their purpose without change when updating to C++11. So while I think this is a change worth documenting, as something to be aware of when upgrading, I have done my due diligence and am not strongly attached to this change. If the editors believe it is a mistake to add it, please close the issue. |
|
I think I've figured the "real" incompatibilities out. (Although I guess they didn't happen for real codes.) Requirements on new members may matter. A C++03 allocator may have its Likewise, a non-conventional Perhaps the A non-conventional |
Revisiting my abandoned paper P0177, there was approval to add this historical compatibility with C++03 text back in 2016, but I never turned it into an editorial request after abandoning the paper.