Subject: Re: [boost] [review][mp11] Formal review of Mp11
From: Peter Dimov (lists_at_[hidden])
Date: 2017-07-17 10:20:39
Joaquin M LÃ³pez MuÃ±oz wrote:
> El 17/07/2017 a las 1:06, Peter Dimov via Boost escribiÃ³:
> > > Joaquin M LÃ³pez MuÃ±oz wrote:
> > >
> > >> 1.1 I really don't like the mp_ prefix. I understand this is meant to
> > >> minimize clashes when using namespace::mp11, but the same purpose can
> > >> be served by simply using namespace mp=boost::mp11.
> > Well... it's also meant to make it possible to move mp11 into std
> > without changes. :-)
> We already have subnamespaces in std (e.g. std::chrono), so your
> standardization plan could be realized as s/boost/std.
It could if I wanted to propose std::mp::if_, but I don't. I want to propose
I know that this makes the library more difficult to use in other Boost
libraries where there's no convenient place to put the using directive. :-/
> > Set operations are only provided for the cases where the generic
> > list-based algorithm would be unsuitable or less efficient.
> I'm not sure this observation entirely addresses my question.
> * mp_set_find is not provided because mp_find does the job --OK, but
> consider my point 1.5.1 then.
> * If mp_set_push_(back|front) is provided (no suitable list-based
> algorithm), why not mp_map_push_back|front)?
Our disagreement here rests on whether set should be the same as map. I do
not view them the same at all. Set is a list with an added constraint, but
it's still a list, and list-like things can be done to it. It's lower level,
so order matters. Map is a higher-level key-based structure, where order
doesn't matter (logically.)
> Something more generic can be provided
> struct mp_mpl_sequence_folder
It can, but it ties me to MPL, so I've chosen not to provide it.
> * "A metafunction is a class template or a template alias [...]":
> s/"template alias"/"alias template"?
> * "mp_unique<L> returns a list of the same type as L [...]": being "the
> same type" needs definition. This is found in other places throughout the
You're right, the documentation is not particularly rigorous. I use C++
terms here and the colloquial meaning of "type" there.
I tend to think that the meaning is more or less clear, but things could be
tightened up at the expense of terseness.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk