Boost logo

Boost :

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2004-04-16 02:55:49


Jeremy Maitin-Shepard ha escrito:

> Joaquín Mª López Muñoz <joaquin_at_[hidden]> writes:
>
> >> [snip]
>
> >> Why not use an MPL sequence of indexes in the first place?
>
> > Well, this has been previously discussed before. The rationale is that
> > I'd like to isolate common users from MPL as much as possible. Imagine
> > the tutorial somehow pointed to the MPL reference for a forward
> > compile-time sequence: IMHO, many readers would scare away. Which
> > percentage of *users* of Boost are acquainted with such a complex
> > library as MPL? MPL is an extremely powerful library, but I honestly don't
> > expect it to to be part of the common knowledge shared by the C++
> > community.
>
> But aren't you just effectively aliasing or reproducing mpl::list in
> your "index_list"?

Yes, the point is that users need not even know what MPL is.

> I do not see that as a very good solution. If you
> want to use a type users might be more familiar with, you could allow
> them to use boost::tuple to specify the index types.

Very first versions of the container (about a year ago) did use
boost::tuple, but:

1. Implementation is much harder, as tuples are not MPL sequences,
a feature the lib internally relies in for building the container out of the
indices.
2. More importantly, tuples do not feel as compile-time specifications
devices: they are rather run-time objects, meant to be constructed
and passed around. Index specifiers are purely syntactic constucts,
they need not even be copyable. The "indexed_by" renaming
enforces this syntactic feel, that's why I like it.

> As I said in a previous message though, what I would really like to see
> would be allowing specifying the indices directly as parameters to the
> container template, as a convenience syntax.

I answered that mail, were the reasons given there not convincing to you?

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk