Re: [boost] Re: [indexed_set] revised naming proposal
----- Mensaje original ----- De: Jeremy Maitin-Shepard <jbms@attbi.com> Fecha: Jueves, Abril 15, 2004 7:50 pm Asunto: Re: [boost] Re: [indexed_set] revised naming proposal
How about just allowing any MPL sequence to specify the indices?
mpl_index_list does precisely this. Check the MPL part in the advanced topics section of the docs.
Also, it would be a nice syntactic convenience to allow the main container template to accept a "variable" number of parameters, and then allow the indices to be specified as parameters directly to the main container template.
Pardon? Do you mean something like multi_index_container < employee, ordered_unique<...>, unordered_unique<...>
without the index_list<> nesting? This cannot be done, as multi_index_container accepts an additional argument, the allocator class. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
How about just allowing any MPL sequence to specify the indices?
mpl_index_list does precisely this. Check the MPL part in the advanced topics section of the docs.
I think the question was why we need this intermediate class at all (or am I wrong?). No class -- no naming problem, and no need to provide the MPL wrapper (and no naming problem with the MPL wrapper). Just solving 3 problems in one shot :) Why not use an MPL sequence of indexes in the first place? Regards, Arkadiy
Arkadiy Vertleyb ha escrito:
How about just allowing any MPL sequence to specify the indices?
mpl_index_list does precisely this. Check the MPL part in the advanced topics section of the docs.
I think the question was why we need this intermediate class at all (or am I wrong?). No class -- no naming problem, and no need to provide the MPL wrapper (and no naming problem with the MPL wrapper). Just solving 3 problems in one shot :)
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. Of course, this decision of mine is debatable. Consider also that the burden of adopting this approach is nearly negligible, namely adding an additional index specification construct for MPL-aware users. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz <joaquin@tid.es> 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"? 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. 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. -- Jeremy Maitin-Shepard
Jeremy Maitin-Shepard ha escrito:
Joaquín Mª López Muñoz <joaquin@tid.es> 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
"Joaquín Mª López Muñoz" <joaquin@tid.es> wrote
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.
I don't quite agree with you here... Meta-programming has become a major part of C++, and allowing to specify a list of types is going to be more and more common thing. It may be expected in the future by more and more people (as it is expected by some people already) that, whenever multiple types are used, they have to be combined in a standard type sequence. MPL sequence is becomming such standard (as STL has become). Besides, explaining how to combine types in an mpl::vector is quite trivial, and I don't see why it is more difficult than explaining the "indexed_by" template. One compromise would be to use the MPL sequence concept, and have indexed_by implementing it (say derive it from mpl::vector). At least then there would be no need in the MPL converter. Regards, Arkadiy
Arkadiy Vertleyb <vertleyb <at> hotmail.com> writes:
"Joaquín Mª López Muñoz" <joaquin <at> tid.es> wrote
Why not use an MPL sequence of indexes in the first place?
[...]
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.
I don't quite agree with you here... Meta-programming has become a major part of C++, and allowing to specify a list of types is going to be more and more common thing. It may be expected in the future by more and more people (as it is expected by some people already) that, whenever multiple types are used, they have to be combined in a standard type sequence. MPL sequence is becomming such standard (as STL has become).
Well, our opinions differ. Just out of curiosity, ask your fellow programmers if they know what MPL is. I have done that, and hardly anyone knew about Boost, let alone MPL. Anyway, please read on. [...]
One compromise would be to use the MPL sequence concept, and have indexed_by implementing it (say derive it from mpl::vector). At least then there would be no need in the MPL converter.
I've done some tweakings and your proposal works. Besides, it makes sense. To sum it up, one would still be allowed to write multi_index_container < employee indexed_by< ...
*and* also multi_index_container < employee mpl::vector< ...
or whatever MPL forward sequence. OK, it seems to me a good compromise. If nobody's against it it'll go in the post review version. Thanx for discussing! Joaquín M López Muñoz Telefónica, Investigacón y Desarrollo
Joaquin M Lopez Munoz <joaquin <at> tid.es> writes:
Well, our opinions differ. Just out of curiosity, ask your fellow programmers if they know what MPL is. I have done that, and hardly anyone knew about Boost, let alone MPL. Anyway, please read on.
Well, lists-of-types are probably the simplest concept in MPL, and everyone has to start somewhere. And by definition, anyone who is trying to use the Boost.MultiIndexContainer library already knows about boost. I don't think this is a problem.
multi_index_container < employee indexed_by< ...
multi_index_container < employee mpl::vector< ...
I like it. Matt
participants (6)
-
Arkadiy Vertleyb -
Jeremy Maitin-Shepard -
JOAQUIN LOPEZ MU?Z -
Joaquin M Lopez Munoz
-
Joaquín Mª López Muñoz
-
Matthew Vogt