----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/63933/#review191451 -----------------------------------------------------------
Ship it! Glad to see C++17 enforces the order! - Benjamin Mahler On Nov. 18, 2017, 12:03 a.m., Michael Park wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/63933/ > ----------------------------------------------------------- > > (Updated Nov. 18, 2017, 12:03 a.m.) > > > Review request for mesos and Benjamin Mahler. > > > Repository: mesos > > > Description > ------- > > ``` > 3rdparty/libprocess/src/process.cpp:2298:33: > warning: 'message' used after it was moved [misc-use-after-move] > poll_socket.get().connect(message.to.address) > ^ > 3rdparty/libprocess/src/process.cpp:2299:16: note: move occurred here > .onAny(lambda::bind( > ^ > 3rdparty/libprocess/src/process.cpp:2298:33: note: the use and move are > unsequenced, i.e. there is no guarantee about the order in which they > are evaluated > poll_socket.get().connect(message.to.address) > ^ > ``` > > Given an expression like `x.f(a).g(b)`, in C++11/4, there's no guarantee > that `f(a)` is fully evaluated before `b` is evaluated. > > Either of the following are valid evaluation order: > - `a`, `f(a)`, `b`, `g(b)` or > - `a`, `b`, `f(a)`, `g(b)` > > More so if there `a` and `b` actually contain subexpressions. > > In C++17, we could rely on this order since it is guaranteed to be: > - `a`, `f(a)`, `b`, `g(b)` > > http://eel.is/c++draft/expr.compound#expr.call-5 > > > Diffs > ----- > > 3rdparty/libprocess/src/process.cpp > 3942a3ae01e56b76e7b27035e705abdb7e3c4828 > > > Diff: https://reviews.apache.org/r/63933/diff/1/ > > > Testing > ------- > > > Thanks, > > Michael Park > >
