Re: FW: Variadic fusion

I was working on this some time ago and have recently come back to it.

I have implemented the method suggested by Larry Evans to simplify the code and reduce the need to modify other parts of fusion.

If there is interest I am happy to contribute this, with apologies for the delay.  Of course it only works with C++0x.  I have only tested it with gcc compilers.

John

________________________________________
From: Fletcher, John P [[email protected]]
Sent: 19 January 2009 23:10
To: Spirit Development
Subject: Re: [Spirit-devel] FW: Variadic fusion

Larry

It looks like your idea is better.  Mine was modelled on what is provided in the extension kit which comes with fusion.  I will have a look and see if I can implement what I want with your method.

I am not an expert on the use of mpl.  I am coming much more from run time functional programming.

I have done a lot of work using FC++ (which nearly made it into boost some time ago now).
See http://www.cc.gatech.edu/~yannis/fc++/ or the pages on it in wiki e.g .http://www.c2.com/cgi/wiki?FunctoidsInCpp

I have been experimenting with a variadic version of it and more recently on converting it to use concepts instead of return type signatures.

In the variadic tuple the idea of the keys was very much so that the programmer can set keys which are meaningful in the problem domain, and therefore memorable.  I want to build some examples to explore it in use, and that is what lead me to the IO to be able to get output neatly.

John
________________________________________
From: Larry Evans [[email protected]]
Sent: 19 January 2009 20:12
To: [email protected]
Subject: Re: [Spirit-devel] FW: Variadic fusion

On 01/18/09 15:59, Fletcher, John P wrote:
 > As there has been some discussion of what I am doing I am posting
 > this as it explains more.
 >
 > John
 > ________________________________________
 > From: Fletcher, John P
 > Sent: 14 December 2008 16:49
 > To: Joel de Guzman
 > Subject: Variadic fusion
 >
 > Joel
 >
 > Some time ago I had some electronic discussions with you and Doug
 > Gregor about combining fusion with variadic tuple.

[snip]
 > It is possible to get the numerical value after careful reading of
 > the boost fusion manual.
 >
 > std::cout << "first_pos::pos::value = " << first_pos::pos::value <<
std::endl;
 >
 >
 >
 > I have found a way to let the user define their own set of keys as
 > well as using the default ones.

The user-defined-keys feature solves what I'll call the "numeric name
problem", i.e. it's hard to remember what a number means, but much
easier to remember what a name means.

 >
 > namespace local_keys
 >
 > {
 >
 > struct A;
 >
 > struct B;
 >
 > struct C;
 >
 > struct D;
 >
 > struct E;
 >
 > struct F;
 >
 > struct G;
 >
 > }
 >
 >
 >
 > using namespace local_keys;
 >
 > typedef boost::mpl::vector<A, B, C, D, E, F> local_key_types;
 >
 > std::cout << "two_numbers.pos<A,local_key_types>() = "
 >
 > << two_numbers.pos<A,local_key_types>() << std::endl;
 >

What's the advantage of using a set of structs, then putting them into
an mpl::vector, and then using another template instantiation, pos
to get the index and then using yet another template instantiation to
get the value out of the tuple vs just using an enumerator in some
enumeration:

enum local_key_enums{A,B,C,D,E,F,G};

together with the single instantiation to get the value with at<N>(s):

http://www.boost.org/doc/libs/1_37_0/libs/fusion/doc/html/fusion/sequence/concepts/random_access_sequence.html

where, N is, for example, mpl::integral<local_key_enums,D>?

This use of enumerations was dicussed in the thread:

http://archives.free.net.ph/message/20050427.104528.7ac74c5f.en.html

Since there would be fewer instantiations using the local_key_enums vs
the local_key_types, and fewer instatiations means faster compile
times, it would seem an advantage.  OTOH, as mentioned in that thread,
the local_key_enums has disadvantages also.  However, I think using
fusion::map would solve both the compile time problem and the numeric
name problem.

 > All the other access methods also work.  I have extended at_key to
 > allow for local keys. This has to be done using at_key2:
 >
 > std::cout << "at_key2<A,local_key_types>(two_numbers) = "
 >
 > << at_key2<A,local_key_types>(two_numbers) << std::endl;
 >

Why is this better than the aforementioned mpl::integral_c method.
IOW, use a fusion::map for two_numbers and then:

   at_key<integral_c<local_key_enums,A> >(two_numbers_map)








------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Spirit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spirit-devel

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Spirit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spirit-devel
------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev