> On Jan. 11, 2016, 1:26 p.m., Alexander Rojas wrote:
> > Why not trying this:
> > 
> > ```c++
> > template <typename ...FlagsTypes>
> > class Flags : public virtual FlagsTypes...
> > {
> >   static_assert(
> >       std::is_same<
> >           std::tuple<typename std::is_base_of<FlagsBase, 
> > FlagsTypes>::type...>,
> >           std::tuple<typename std::is_object<FlagsTypes>::type...>>::value,
> >       "Can only instantiate Flags with FlagsBase types.");
> > };
> > 
> > 
> > template <>
> > class Flags<> : public virtual FlagsBase
> > {};
> > ```
> > 
> > It seems more concise, it is easy to read and allows an arbitrary number of 
> > parameters. On the down side, you won't know exactly which type broke the 
> > condition.

That looks like a good idea! I personally find it pretty self-documenting, and 
it removes the dummy types for default template args; I'll check with my 
shepherd tomorrow to gauge what kind of additional documentation this might 
need for mesos.


- Benjamin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41882/#review113739
-----------------------------------------------------------


On Jan. 11, 2016, 10:25 a.m., Benjamin Bannier wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41882/
> -----------------------------------------------------------
> 
> (Updated Jan. 11, 2016, 10:25 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Till Toenshoff.
> 
> 
> Bugs: MESOS-4278
>     https://issues.apache.org/jira/browse/MESOS-4278
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Constrained types used in Flags instantiation.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp 
> addef78ddeb0007cf1e1c79738381138a18a35b6 
> 
> Diff: https://reviews.apache.org/r/41882/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Benjamin Bannier
> 
>

Reply via email to