Re: [Boost-users] [Phoenix] Ignore last post.

Subject: Re: [Boost-users] [Phoenix] Ignore last post.
From: James Knight (james.nate.knight_at_[hidden])
Date: 2009-11-24 14:37:41

I realized some of the things I was doing in the sample code are pretty
stupid.  I'm still not sure why the compilation was failing on the phoenix
code.  I'll repost once I figure out what I'm doing.  Sorry for the noise.

On Tue, Nov 24, 2009 at 12:09 PM, James Knight
<james.nate.knight_at_[hidden]>wrote:

> I'm having a problem using Boost.Phoenix.  I'm currently building against
> Boost 1.41 using gcc 4.3.2.
>
> I've simplified my use case quite a bit, so please forgive the obtuseness
> of the example.  The following code fails to compile:
>
> ~~~~~~~~~~~~~~~~~~~~
>
> #include <boost/fusion/include/std_pair.hpp>
> #include <boost/spirit/home/phoenix/core/argument.hpp>
> #include <boost/spirit/home/phoenix/fusion.hpp>
> #include <boost/spirit/home/phoenix/operator.hpp>
>
> #include
> <vector>
>
> #include
> <map>
> #include <algorithm>
>
> namespace phx = boost::phoenix;
> using namespace phx::arg_names;
> using phx::at_c;
> using std::map;
>
> using std::multimap;
> using std::vector;
>
> int main()
> {
>
>     typedef map<vector<char>,int>
> char_int_map_t;
>     typedef multimap<int,char_int_map_t::iterator>
> int_iter_map_t;
>     typedef map<vector<char>, char_int_map_t::iterator>
> char_iter_map_t;
>
>
>     int int_key =
> 5;
>
>
>
>     char_int_map_t
> int_map;
>
>     int_iter_map_t
> int_iter_map;
>
>
>
>     char_iter_map_t char_iter_map1,
> char_iter_map_t2;
>
>
>     int_iter_map_t::iterator
> start,stop;
>
> std::pair<int_iter_map_t::iterator,int_iter_map_t::iterator>
>
>         er = int_iter_map.equal_range(int_key);
>
>     std::set_intersection(
>         char_iter_map1.begin(), char_iter_map1.end(),
>         er.first,er.second,
>         inserter(char_iter_map_t2,char_iter_map_t2.begin()),
>         phx::at_c<0>(arg1) < phx::at_c<0>(*phx::at_c<1>(arg2))    // <-
> COMPILE FAILURE
>     );
> }
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Here is the information I can offer,
>
> 1) When the key in char_int_map_t and char_iter_map_t is a char rather than
> a vector<char> this compiles without problems.
> 2) The gcc error shows that the arguments to the generated function object
> are being switched (I think, see below)
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ...
> .../comparison.hpp:29:5: error: no match for ‘operator<’ in
> ‘result_of_less<const int&, const vector<char>&>::x < result_of_less<const
> int&, const vector<char>&>::y’
> .../comparison.hpp: In instantiation of ‘const int result_of_less<const
> int&, const vector<char>&>::index’:
> .../comparison.hpp:29:   instantiated from ‘result_of_less<const int&,
> const vector<char>&>’
> .../mpl/eval_if.hpp:38:   instantiated from ‘eval_if<or_<is_actor<const
> int&>, is_actor<const vector<char>&>, mpl_::bool_<false>,
> mpl_::bool_<false>, mpl_::bool_<false> >, re_curry<less_eval, const int&,
> const vector<char>&>, result_of_less<const int&, const vector<char,
> allocator<char> >&> >’
> .../comparison.hpp:39:   instantiated from ‘
>
> boost::phoenix::less_eval::result<
>     boost::phoenix::basic_environment<
>
> std::pair<
> // This should be the second argument, no?
>             const
> int,
>
>             std::_Rb_tree_iterator<std::pair<const std::vector<char,
> std::allocator<char> >, int>>
>         >,
>         std::pair<
>             const std::vector< char, std::allocator<char> >,
>             std::_Rb_tree_iterator<std::pair<const std::vector<char,
> std::allocator<char> >, int>>
>         >
>     >,
>     boost::phoenix::composite<
>         boost::phoenix::at_eval<0>,
>         boost::fusion::vector<
>             boost::phoenix::argument<0>
>         >
>     >,
>     boost::phoenix::composite<
>         boost::phoenix::at_eval<0>,
>         boost::fusion::vector<
>             boost::phoenix::composite<
>                 boost::phoenix::dereference_eval,
>                 boost::fusion::vector<
>                     boost::phoenix::composite<
>                         boost::phoenix::at_eval<1>,
>                         boost::fusion::vector<
>                             boost::phoenix::argument<1>
>                         >
>                     >
>                 >
>             >
>         >
>     >
> >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> 3) Finally, if I use the expression
>
>     phx::at_c<0>(arg1) < *phx::at_c<1>(arg2)
>
> the code still fails to compile (obviously), but does seem to get the
> arguments in the correct order.
>
> Any ideas?
>
> Thanks
> Nate
>