----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/42273/#review114440 -----------------------------------------------------------
src/scheduler/scheduler.cpp (line 261) <https://reviews.apache.org/r/42273/#comment175286> In general there are no guarantees on whether it is safe to assign to a `move`'d from object, but currently this looks safe (`std::queue` uses a `std::deque` as underlying container which can be assigned to if `move`'d from, cf. http://stackoverflow.com/a/7028318/176922). I am just worried if it is a good idea to rely on that behavior, e.g., we might pull in another `queue` w/o realizing (`using std::queue` above), or just declare an alias `queue` somehow that uses a different underlying container (OK, that is *currently* not something we would do in mesos); we would probably not realize that we might break the implicit assumptions here. - Benjamin Bannier On Jan. 14, 2016, 12:06 a.m., Anand Mazumdar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/42273/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2016, 12:06 a.m.) > > > Review request for mesos and Vinod Kone. > > > Repository: mesos > > > Description > ------- > > This trivial fix invokes `std::move` on the `queue` object to not perform a > copy before invoking the `async(..)` call. > > > Diffs > ----- > > src/scheduler/scheduler.cpp a17872b46ec600e0fae6c43247ccb63f5ee55ac0 > > Diff: https://reviews.apache.org/r/42273/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Anand Mazumdar > >
