basic_osyncstream move assignment and destruction calls basic_syncbuf::emit() twice
Tim Song

Created on 2019-11-06.00:00:00 last changed 7 months ago


Date: 2020-02-14.07:30:42

Proposed resolution:

This wording is relative to N4849.

[Drafting note: There is no need to explicitly call emit at all in these functions; memberwise move-assignment/destruction is sufficient, so we can strike the specification entirely and rely on the wording in [functions.within.classes]. — end drafting note]

  1. Edit [syncstream.osyncstream.cons] as indicated:


    -6- Effects: Calls emit(). If an exception is thrown from emit(), that exception is caught and ignored.

  2. Strike [syncstream.osyncstream.assign]:

    basic_osyncstream& operator=(basic_osyncstream&& rhs) noexcept;

    -1- Effects: First, calls emit(). If an exception is thrown from emit(), that exception is caught and ignored. Move assigns sb from rhs.sb. [ Note: This disassociates rhs from its wrapped stream buffer ensuring destruction of rhs produces no output. — end note ]

    -2- Postconditions: nullptr == rhs.get_­wrapped() is true. get_­wrapped() returns the value previously returned by rhs.get_­wrapped().

Date: 2020-02-14.07:30:42

[ 2020-02 Status to Immediate Thursday afternoon in Prague. ]

Date: 2020-02-13.00:00:00

[ 2020-02-13 Tim adds wording after discussion with Peter ]

Date: 2019-11-06.00:00:00

These functions are specified to call emit(), which calls emit() on the basic_syncbuf and sets badbit if it fails. Then, the move assignment is specified to move-assign the basic_syncbuf, while the destructor implicitly needs to destroy the basic_syncbuf data member. This calls emit() on the basic_syncbuf again.

Is this intended?

Date User Action Args
2020-02-24 16:02:59adminsetstatus: immediate -> wp
2020-02-14 07:30:42adminsetmessages: + msg11096
2020-02-14 07:30:42adminsetstatus: new -> immediate
2020-02-13 12:19:21adminsetmessages: + msg11053
2020-02-13 12:19:21adminsetmessages: + msg11052
2019-11-06 00:00:00admincreate