Larry Evans wrote:
On 04/26/2005 05:22 PM, Giovanni P. Deretta wrote: [snip]
As your code demonstrates, enumerators can be used without duplicating information, but an enum and map enum->type is required for each tuple. This is verbose and should be wrapped in a macro. Then again, I don't
Agreed.
like macros a lot :)
But mpl and fusion are profuse with macros, or at least boost/preprocessor.
Sure, I write macros myself, but i try to avoid them if i can.
In the end, getting 'by type' has the same expressive power of using enumerators, i simply think that it would have a better syntax and it would work out of the box with all tuples without the need of a map.
But it wouldn't work for repeated types, unless, as you noted previously, some sort of "tag" were "associated" with the type, which is what an mpl::map does, only it assures there's only one type associated with each tag; whereas the example:
tuple<mpl::list<element1_type, element1_tag>, mpl::list<element2_type, element2_tag>,.....>
in one of your previous messages:
http://article.gmane.org/gmane.comp.lib.boost.devel/122595
doesn't assure this, AFAICT. Also, I'd think mpl::pair would be more succinct.
Why not? You would get by 'tag' i.e. get<element1_tag>(tuple). An extended_tuple<mpl::pair<type1, tag1>, mpl::pair<type2, tag2>...>; is almost exactly the same of a TR1 tuple<type1, type2 ...>; the extra tags are only used to accessing the tuple. I think i failed to expain this, from your next example i think you thought that my extended_tuple where some sort of mpl-like container. The extended_tuple probably requires modification to tuple code, so it is not really viable. And yes, mpl::pair would be better, but i couldn't find it in the mpl documentation :)
So, the tuple version of the following: struct employ { string name; float salary; int ssn; };
could be:
struct name{}; struct salary{}; struct ssn{};
tuple < mpl::pair<string,name> , mpl::pair<float,salary> , mpl::pair<int,ssn>
::type;
which is not that much shorter than the enum_map_0 shown in my previous post:
http://article.gmane.org/gmane.comp.lib.boost.devel/122661
After all, for each enum_map_0::f_i, for i=0..2, there's got to be a tag with your method:
struct name{}; struct salary{}; struct ssn{};
and there's also got to be a pairing of tags to types, just as in the enum_map_0::field_map.
Am I missing something?
Well, in my extended tuple example tags are _not_ associated with a tuple. Different tuples can reuse the same tag set or part of it. This is very useful for generic programming, for example, i may have a function that accept a tuple having a some_tag slot. Doing this with enum is clumsy and not type safe. I.e. a tuple might not map the whole enum set enum {a, b, c}, but get<a>(tuple_foo) would still compile even if 'a' is not logically part of tuple_foo. Also you are forced to use the enum ordering. Anyway, i don't think you proposed to reuse the same enums, only the names, but then you are forced to write enums for every tuple. Anyway, I think i will try fusion now :) -- Giovanni P. Deretta