> On June 9, 2015, 6:34 a.m., Cody Maloney wrote: > > 3rdparty/libprocess/3rdparty/stout/include/stout/path.hpp, line 58 > > <https://reviews.apache.org/r/35179/diff/2/?file=980529#file980529line58> > > > > I'm still against using enable_if here, it's a lot of extra complexity > > (And will be slightly greater compile time, as well as more complexity the > > compiler has to sort out for runtime). I don't see it providing great value > > over not using it. Hiding it behind a macro doesn't make it simpler. > > Anand Mazumdar wrote: > I removed the usage but is it fine with you if I keep require.hpp i.e. > the macro intact ? It might benefit others who find the "std::enable_if" > syntax too cumber-some ? ( I can see a couple of places in the code-base > already where this can be used already ) > > Also, I did not quite understand your argument around "a lot of extra > complexity". Did you mean syntaxtic complexity around std::enable_if ? ( That > is what the macro was trying to achieve to make it as painless to use it. ) > > As for the compile-time complexity , I wouldn't think about it too much > with the modern compilers et al.
Just found a good presentation about the concepts in general: https://youtu.be/eR34r7HOU14?t=27m13s. At the very end of that presentation (Around 1 hour, 22 minutes in), Chandler talks in specific about doing stuff inside recursive variadic templates. More or less, the template ends up generating a mountain of code and function calls which is very hard to analyze as a compiler back end. - Cody ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/35179/#review87140 ----------------------------------------------------------- On June 9, 2015, 3:56 p.m., Anand Mazumdar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/35179/ > ----------------------------------------------------------- > > (Updated June 9, 2015, 3:56 p.m.) > > > Review request for mesos, Adam B and Cody Maloney. > > > Bugs: MESOS-1733 > https://issues.apache.org/jira/browse/MESOS-1733 > > > Repository: mesos > > > Description > ------- > > This change takes an un-complicated/naive route ( no trimming of values etc ) > at making path::join(...) variadic mainly in order to preserve the earlier > over-loaded join functionality. > > Might have some C++ style issues owing to this being my first commit here. > > > Diffs > ----- > > 3rdparty/libprocess/3rdparty/stout/include/stout/path.hpp > d4df6502d1297ea3ad8e2a1e3bb16ea9d7c7913c > > Diff: https://reviews.apache.org/r/35179/diff/ > > > Testing > ------- > > make check + added some additional tests. > > > Thanks, > > Anand Mazumdar > >
