> On March 5, 2014, 10:51 p.m., Ben Mahler wrote: > > 3rdparty/libprocess/3rdparty/stout/include/stout/tuple.hpp, line 20 > > <https://reviews.apache.org/r/18360/diff/3/?file=502379#file502379line20> > > > > Question: why not include <tr1/tuple> when C++11 is not available? > > > > This is what the other headers do: > > > > lambda.hpp > > memory.hpp > > > > I can't tell from the discussion on this review, was there a reason to > > do it differently for tuple? > > Till Toenshoff wrote: > Because we are relying on boost-tuple in other places already > (3rdparty/libprocess/3rdparty/stout/include/stout/foreach.hpp, > 3rdparty/libprocess/include/process/tuples/tuples.hpp) and I wanted to stay > in line with those instead of dragging in another variant. > > Ben Mahler wrote: > It's still not clear to me that we should be using boost's tuple instead > of tr1's tuple: > > 1. That process/tuples folder looks like dead code, and is only used by > httpd.cpp and test-master.cpp. These also appear dead, do they even compile? > > 2. Does foreach.hpp need tuple.hpp to compile? It doesn't appear so at > first glance so we should add a comment. If so, will you be updating > foreach.hpp to include stout/tuple.hpp rather than doing a custom boost > include? > > 3. Will you be updating src/zookeeper/zookeeper.cpp to not directly > include from boost now that we have this? > > The motivation for tr1 is so that we consistently fall back to tr1 > headers when we don't have C++11.
Yes, you are right, tr1/tuple can be used and for keeping things consistent as you drafted, is used in my upcoming, latest revision of this patch. re 1. That code could indeed be removed then from a mesos point of view. re 2. Nope, not needed. Will add another RR that removes that include. re 3. Yes, yet another RR upcoming :) Thanks for looking into this, it makes more sense this way. - Till ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18360/#review36278 ----------------------------------------------------------- On Feb. 24, 2014, 6:48 p.m., Till Toenshoff wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/18360/ > ----------------------------------------------------------- > > (Updated Feb. 24, 2014, 6:48 p.m.) > > > Review request for mesos, Adam B, Benjamin Hindman, Ben Mahler, Niklas > Nielsen, and Vinod Kone. > > > Bugs: MESOS-1026 > https://issues.apache.org/jira/browse/MESOS-1026 > > > Repository: mesos-git > > > Description > ------- > > Namespace pull-in of std::tuple or boost::tuples::tuple, depending on the > availability of C+11. The results are part of a tuples namespace of stout. > > Example usage including fully qualified namespaces: > > #include <stout/tuple.hpp> > tuples::tuple<int, bool> tuple = tuples::make_tuple(42, true); > int foo = tuples::get<0>(tuple); > > > Diffs > ----- > > 3rdparty/libprocess/3rdparty/stout/Makefile.am 5d5a760 > 3rdparty/libprocess/3rdparty/stout/include/stout/tuple.hpp PRE-CREATION > > Diff: https://reviews.apache.org/r/18360/diff/ > > > Testing > ------- > > make check (clang c++11, gcc), functional testing > > > Thanks, > > Till Toenshoff > >
