----- Mensaje original ----- De: David Abrahams <dave@boost-consulting.com> Fecha: Domingo, Marzo 28, 2004 7:41 am Asunto: [boost] Re: Formal Review: Indexed Set
JOAQUIN LOPEZ MU?Z <joaquin@tid.es> writes:
Hi Jeff
----- Mensaje original ----- De: Jeff Garland <jeff@crystalclearsoftware.com> Fecha: Sábado, Marzo 27, 2004 4:55 pm Asunto: Re: [boost] Formal Review: Indexed Set
// why doesn't this work? //typedef nth_iterator_type<date_to_string_bimap,2>::type to_map_itr;> It is
typedef nth_iterator_type<date_to_string_bimap,1>::type to_map_itr;
Index numbering is 0-based. I think this is the only problem in the program. If you have further problems please tell me so.
Not having looked at the proposal at all, I still think I should raise the usual concerns about "metafunctions" not accepting type parameters, which don't play nice with MPL and lambda expressions.
IMHO nth_iterator_type and familiy are user-level facilities (similar vg to Boost.Tuple get<>) and accepting mpl integral constants instead of raw constants does not make much sense here. Please somebody correct me if I'm wrong. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
"JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> wrote:
IMHO nth_iterator_type and familiy are user-level facilities (similar vg to Boost.Tuple get<>) and accepting mpl integral constants instead of raw constants does not make much sense here. Please somebody correct me if I'm wrong.
One positive thing that could result from this would be the possibility of specializing the class to determine the type of the index, such as instead of nth_index_type<1>::type to use index_type<mpl::int_<1> >::type //rather clumzy, but doesn't clash with index_type<tag>::type If you then create some typedefs (possibly with the preprocessor), something like: typedef mpl::int_<1> _1; ... typedef mpl::int_<10> _10; This might look like: index_type<_1>::type; Regards, Arkadiy
participants (13)
-
Arkadiy Vertleyb -
JOAQUIN LOPEZ MU?Z