Re: [Boost-users] [fusion] sequence conversion

From: Zeljko Vrba (zvrba_at_[hidden])
Date: 2008-07-22 02:45:12

On Mon, Jul 21, 2008 at 07:08:15PM +0200, Istvan Buki wrote:
> 
> Here is a small example that read data from a CSV file, filter out a column
> and write the result to another CSV file.
> 

> 
> struct AddressBook
> {
>   typedef fusion::map <
>     fusion::pair< fields::first_name::type, fields::first_name::value_type
> >,
>     fusion::pair< fields::last_name::type, fields::last_name::value_type >,
>     fusion::pair< fields::age::type, fields::age::value_type >,
>     fusion::pair< fields::address::type, fields::address::value_type >,
>     fusion::pair< fields::postal_code::type, fields::postal_code::value_type
> >
>   > type ;
> } ;
> 
Hm, this looks like a lot of duplication and grunt work.  I wonder whether MPL
or fusion could be used to generate the above given just the type list:

<first_name, last_name, age, address, postal_code>

(because the pattern is very regular.. each type expands to two types (base
type suffixed by ::type and ::value_type), wrapped in fusion::pair,
concatenated into a list handed over to fusion::map>)

> 
> {
>   metl::csv_istream< AddressBook >::impl in_file( "addrbook.csv" ) ;
> 
>   typedef metl::filter< AddressBook, fields::age >::impl filter_t ;  //
> remove the 'age' column
>
>   typedef metl::result_of::filter< AddressBook, fields::age >
> filter_result_t ;
> 
Why do you have to use metl::result_of?  Wouldn't it be simpler to have a
result typedef inside the filter? ('typedef filter_t::result filter_result_t')

Thanks for the example, a while back I did something similar:
http://zvrba.net/software/data_stream_toolkit.html

The code was used to process huge amounts of data, but it was at the same time
my own experiment with "declarative programming" in C++.  I wanted to extend
the toolkit to be able to reuse the same "declarative computation" at several
places without actually redoing the computation several times, but that
required storing the functors into variables of unwieldy types..  I also tried
experimenting with Phoenix-2 at that time, but it was too difficult (my first
experience with megabyte-sized messages from the compiler.)  So I ended up with
my own conventions for argument and result-types and coding something less
general that fullfiled my needs at that time.

I'd like to extend the above idea to something like a "subset of SQL in C++",
but.. that'll have to wait better times :-(