[ostream.manip] Introduce SYNCBUF to detect basic_syncbuf LWG 3501#4300
[ostream.manip] Introduce SYNCBUF to detect basic_syncbuf LWG 3501#4300jwakely wants to merge 1 commit intocplusplus:masterfrom
Conversation
|
CI fails because of overfull hboxes
|
|
Say "Let p be SYNCBUF(os.rdbuf())." before \effects, then rephrase \effects in terms of "p": This should take care of the overfull hboxes, and reduces redundancy in the exposition. In any case, this seems not-obviously-correct, so I'd prefer a minuted LWG teleconference consensus that this editorial fix is desirable. (We probably don't need an LWG issue if there is no effective normative change and there are no objections in LWG.) |
7571786 to
ea4fd0d
Compare
|
Yes, that works and looks good. Thanks for the suggestion.
Yes, I'd prefer that too. That's why this is a draft and not submitted for review yet. |
This attempts to address the problem of `Allocator` being mentioned in the function descriptions without being defined. We cannot say that > `os.rdbuf()` is a `basic_syncbuf<charT, traits, Allocator>*` because firstly, that type is not defined, and secondly `os.rdbuf()` is a `basic_streambuf<charT, traits>*` and not any other type. By introducing SYNCBUF we can define the manipulators properly, by talking about a base class subobject rather than "is a". This introduces an apparently normative change that the syncbuf type must not use a program-defined specialization. Without that additional restriction the implementation suggested by the note doesn't work, because program-defined specializations cannot derive from the intermediate base class, and therefore cannot be detected by SYNCBUF.
ea4fd0d to
a320f4f
Compare
|
LWG has decided this needs a DR, so isn't editorial. |
|
A corresponding LWG issue has been created, this is LWG 3501. |
This attempts to address the problem of
Allocatorbeing mentioned inthe function descriptions without being defined. We cannot say that
because firstly, that type is not defined, and secondly
os.rdbuf()isa
basic_streambuf<charT, traits>*and not any other type.By introducing SYNCBUF we can define the manipulators properly, by
talking about a base class subobject rather than "is a".
This introduces an apparently normative change that the syncbuf type
must not use a program-defined specialization. Without that additional
restriction the implementation suggested by the note doesn't work,
because program-defined specializations cannot derive from the
intermediate base class, and therefore cannot be detected by SYNCBUF.