[mpl] vector_c with enumerators?
Is the following supposed to compile: enum visitor_numerals { visitor_n0 , visitor_n1 }; typedef mpl::vector_c<visitor_numerals,visitor_n0> vec_viz_type; typedef mpl::at_c<vec_viz_type,0>::type vec_viz0_type; it does with intel but with gcc, I get: bjam --v2 toolset=gcc vector_enum_test ...patience... ...found 751 targets... ...updating 4 targets... gcc.compile.c++ ../../../../bin.v2/lje/libs/fields_visitor/test/vector_enum_test.test/gcc/debug/vector_enum_test.o /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/aux_/preprocessed/gcc/vector_c.hpp: In instantiation of `boost::mpl::vector_c<visitor_numerals, 0l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l>': /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/aux_/has_tag.hpp:20: instantiated from `boost::mpl::aux::has_tag<test()::vec_viz_type, mpl_::bool_< false> >' /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/sequence_tag.hpp:115: instantiated from `boost::mpl::sequence_tag<test()::vec_viz_type>' /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/at.hpp:45: instantiated from `boost::mpl::at_c<test()::vec_viz_type, 0l>' vector_enum_test.cpp:11: instantiated from here /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/aux_/preprocessed/gcc/vector_c.hpp:47: error: invalid conversion from `long int' to `visitor_numerals'
On 01/28/2005 04:27 PM, Larry Evans wrote:
Is the following supposed to compile:
enum visitor_numerals { visitor_n0 , visitor_n1 };
typedef mpl::vector_c<visitor_numerals,visitor_n0> vec_viz_type; typedef mpl::at_c<vec_viz_type,0>::type vec_viz0_type;
it does with intel but with gcc, I get: [snip] /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/aux_/preprocessed/gcc/vector_c.hpp:47: error: invalid conversion from `long int' to `visitor_numerals' I'm seriously thinking about coding a workaround. Are there any suggestions about how best to do it?
TIA.
Larry Evans writes:
Is the following supposed to compile:
enum visitor_numerals { visitor_n0 , visitor_n1 };
typedef mpl::vector_c<visitor_numerals,visitor_n0> vec_viz_type; typedef mpl::at_c<vec_viz_type,0>::type vec_viz0_type;
Theoretically, I see no good reason to disallow it.
it does with intel but with gcc, I get:
[snip errors] I'll look into making this work. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy <agurtovoy <at> meta-comm.com> writes:
Larry Evans writes:
Is the following supposed to compile:
[snip code]
Theoretically, I see no good reason to disallow it. [snip] I'll look into making this work.
Great! Thanks very much. Let me know if I can help. I've got gcc, intel 8.1 and como4.3.3 compilers on linux to help with any testing.
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote
Larry Evans writes:
Is the following supposed to compile:
enum visitor_numerals { visitor_n0 , visitor_n1 };
typedef mpl::vector_c<visitor_numerals,visitor_n0> vec_viz_type; typedef mpl::at_c<vec_viz_type,0>::type vec_viz0_type;
Theoretically, I see no good reason to disallow it.
I think that one major problem is that you promise next<> and prev<> on integrals. It would be quite problematic to satisfy this for enums staying in the same enum type. Regards, Arkadiy
Arkadiy Vertleyb <vertleyb <at> hotmail.com> writes: [snip]
I think that one major problem is that you promise next<> and prev<> on integrals. It would be quite problematic to satisfy this for enums staying in the same enum type. The same problem exits with any integral type if you use next enough times. Beside, you can enable checking when the end or beginning is reached by defining specialziations of:
max_value<T>::value min_value<T>::value just as, at present, in largest_int, there are specializations for integral_rank<T> for each T that is an integral type.
On 02/01/2005 12:34 PM, Larry Evans wrote: [snip]
is reached by defining specialziations of:
max_value<T>::value min_value<T>::value
just as, at present, in largest_int, there are specializations for integral_rank<T> for each T that is an integral type. Or maybe integral_rank<T> can be modified similar to: template<> struct integral_rank<long> : int_<10> { static long const max_value=LONG_MAX; static long const min_value=LONG_MIN; };
where LONG_MAX and LONG_MIN are, I guess, macros defined in <climits.hpp>. I guess this is where LONG_MAX in: boost/mpl/aux_/preprocessed/plain/vector_c.hpp comes from. OTOH, it seems this is more of a type trait, and maybe such a definition belongs in boost/type_traits. Any thoughts? I'd like to know where's the best place since I currently have a use for it to replace the enum_size in: http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/indexed_types/enum_size.hpp?rev=1.1&view=auto
On 02/01/2005 07:28 AM, Arkadiy Vertleyb wrote:
I think that one major problem is that you promise next<> and prev<> on integrals. It would be quite problematic to satisfy this for enums staying in the same enum type.
In the sandbox vault, there's range_all.zip which, IFAICT, solves this problem by having a separate class, range_c_max, for including the max value in the enumeration. Also next<> and prev<> have been specialized as well as integral_rank. In addition, files in aux_/ preprocessed/gcc had to be modified by supplying an explicit cast from an integral to the enumeration. Anyway, the tests provided are for size and for_each (which actually iterates over the whole enumeration). Also, mpl::minus had to be specialized for size to work. Comments and suggested improvements are welcome.
On 02/10/2005 04:38 PM, Larry Evans wrote:
On 02/01/2005 07:28 AM, Arkadiy Vertleyb wrote:
I think that one major problem is that you promise next<> and prev<> on integrals. It would be quite problematic to satisfy this for enums staying in the same enum type.
In the sandbox vault, there's range_all.zip which, IFAICT, solves this problem by having a separate class, range_c_max, for including the max value in the enumeration. Also next<> and prev<> have been specialized as well as integral_rank. In addition, files in aux_/ preprocessed/gcc had to be modified by supplying an explicit cast from an integral to the enumeration.
OOPS. Sorry, wrong subject. Actually, only the change to the preprocessed/gcc files is relevant to this subject and maybe the next<> and prev<> specializations. The subject I had in mind was creating a range_c for enumerations which was a subject I'd emailed Aleksey about.
participants (3)
-
Aleksey Gurtovoy -
Arkadiy Vertleyb -
Larry Evans