> On Sept. 9, 2015, 5:16 p.m., Joris Van Remoortere wrote: > > 3rdparty/libprocess/3rdparty/stout/include/stout/os/posix/fork.hpp, line 278 > > <https://reviews.apache.org/r/37876/diff/1/?file=1057697#file1057697line278> > > > > Some places in this review chain you use the provided typedefs > > `std::atomic_XXX`, whereas elsewhere you provide the explicit > > specialization `std::atomic<int64_t>`. > > > > Can you put a review at the front of this chain to provide guidance for > > consistency in the style guide regarding atomics? I would add examples and > > policies for: > > 1. Always using the explicit specializations; or when to use the > > typedef over the explicit (if you have a good argument for that) > > 2. Why we use the explicit functions such as `store(X)` as opposed to > > the `operator=` as we discussed in person. > > > > Once that's done, please make any changes required in the chain to stay > > consistent.
Thanks for the review, Joris! This is a great point -- I'll update the style guide. As far as when to use the explicit specialization over the typedef, I only used an explicit specialization when C++11 doesn't provide a typedef. e.g., C++ doesn't provide std::atomic_int64_t, so I used std::atomic<int64_t> (the standard provides std::atomic_fast_int64_t, which seems a bit painful to type/read). I don't have strong feelings here, though: for example, you could argue that we should always use the explicit specializations for the sake of consistency. - Neil ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/37876/#review98209 ----------------------------------------------------------- On Sept. 9, 2015, 4:02 p.m., Neil Conway wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/37876/ > ----------------------------------------------------------- > > (Updated Sept. 9, 2015, 4:02 p.m.) > > > Review request for mesos, Joris Van Remoortere and switched to 'mcypark'. > > > Bugs: MESOS-3326 > https://issues.apache.org/jira/browse/MESOS-3326 > > > Repository: mesos > > > Description > ------- > > MESOS-3326. > > > Diffs > ----- > > 3rdparty/libprocess/3rdparty/stout/include/stout/os/posix/fork.hpp > d43433aeab5a1a68ff76eb75416672fae456c70d > > Diff: https://reviews.apache.org/r/37876/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Neil Conway > >
