Hi Joaquín M López Muñoz, thank you for your quick answer! I appreciate that multi_index_container exist and I can use it. In my opinion this library is very useful and facilitate many programs.
44 //version B: DOES compile 45 typedef index<employee_set,id >::type employee_set_by_id; 46 typedef index<employee_set,age>::type employee_set_by_age;
OK, fine.
48 //remove the name index (lines 31, 32) for following versions 49 50 //version C: DOES compile 51 typedef index<employee_set,id >::type employee_set_by_id;;
OK, too.
52 53 //version D: does NOT compile 54 //causes ...\include\boost-1_32\boost\mpl\vector\aux_\preprocessed\no_ctps\vector10.hpp(398) : 55 // error C2039: 'item3' : is not a member of 'boost::mpl::vector2<T0,T1>' 56 typedef index<employee_set,age>::type employee_set_by_age;
!! Here I'm missing somethig... Isn't version D exactly the same as version B, which does work?
Exact this I wanted point out. Version D differs from version B in removing two lines 31, 32 only (i.e. the name index). Version C is nearly the same, too. Nevertheless there is a difference when compiling. best regards Volker Vieth
Wusel ha escrito:
!! Here I'm missing somethig... Isn't version D exactly the same as version B, which does work?
Exact this I wanted point out. Version D differs from version B in removing two lines 31, 32 only (i.e. the name index). Version C is nearly the same, too. Nevertheless there is a difference when compiling.
OK, I missed the part about removing lines 31 and 32. Well, I am as puzzled as you. The code should work, but somehow the compiler chokes on it. FWIW, it works OK on other compilers, as it should be. The error message seems to indicate that an mpl::iter_fold algorithm running over the list of indices somewhow goes out of bounds. I've tried to reduce the problem to something amenable to study, to no avail: simpler formulations of the internals do not fail. If Aleksey is reading this and wants to take a look at it, I'll be happy to provide as much info as needed, other than that we're stuck. You can always use numbers instead of tags (confirmed to work.) Sorry I can't be more helpful. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Adding to my answer yesterday, seems like the compiler is just choking: after reducing the complexity of the types involved, it works again OK. The following tecnhique, which I call "type hiding" solves this issue and also has other beneficial side effects in handicapped compilers. Instead of defining your container like typedef multi_index_container< employee, indexed_by<...>
employee_set;
do it as follows struct employee_set_indices: indexed_by<...> {}; typedef multi_index_container< employee, employee_set_indices
employee_set;
This generates much shorter symbol names and generally the compiler has a happier time with it. In your particular case, I've confirmed that it solves the problem with version D going crazy. Docs in the next Boost release has a section on type hiding, as I think it's a useful tecnhique when dealing with Boost.MultiIndex in not so powerful environments. Hope this helps, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo Wusel ha escrito:
Hi Joaquín M López Muñoz,
thank you for your quick answer! I appreciate that multi_index_container exist and I can use it. In my opinion this library is very useful and facilitate many programs.
44 //version B: DOES compile 45 typedef index<employee_set,id >::type employee_set_by_id; 46 typedef index<employee_set,age>::type employee_set_by_age;
OK, fine.
48 //remove the name index (lines 31, 32) for following versions 49 50 //version C: DOES compile 51 typedef index<employee_set,id >::type employee_set_by_id;;
OK, too.
52 53 //version D: does NOT compile 54 //causes ...\include\boost-1_32\boost\mpl\vector\aux_\preprocessed\no_ctps\vector10.hpp(398) : 55 // error C2039: 'item3' : is not a member of 'boost::mpl::vector2<T0,T1>' 56 typedef index<employee_set,age>::type employee_set_by_age;
!! Here I'm missing somethig... Isn't version D exactly the same as version B, which does work?
Exact this I wanted point out. Version D differs from version B in removing two lines 31, 32 only (i.e. the name index). Version C is nearly the same, too. Nevertheless there is a difference when compiling.
best regards Volker Vieth
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Joaquín M López Muñoz, meanwhile I'm glad to have a working version. I'll get a newer compiler besides.
Adding to my answer yesterday, seems like the compiler is just choking: after reducing the complexity of the types involved, it works again OK. The following tecnhique, which I call "type hiding" solves this issue and also has other beneficial side effects in handicapped compilers.
This is a good idea. I'll make use of it. Dividing this huge typedef block is better readable as well. Thank you much for your help and support. By the way I should seen the page compiler_specifics.html, when reading the docs. I'm sorry about unnecessary questions. best regards Volker Vieth
participants (2)
-
Joaquín Mª López Muñoz -
Wusel