Re: fusion vector, spirit, phoenix actor and forwarding constructor

On Tue, 12 Jul 2016 20:49:31 +0100 MM <[email protected]> wrote:
> Hello,
> 
> In this user constructor for struct store in
> /usr/include/boost/fusion/container/vector/vector.hpp:175:44
> 
>             template <typename U>
>             BOOST_CONSTEXPR BOOST_FUSION_GPU_ENABLED
>             store(U&& rhs
>                 , typename disable_if<is_same<typename pure<U>::type,
> store>, detail::enabler_>::type = detail::enabler)  
>                 : elem(std::forward<U>(rhs))
> <= error is here
>             {}
> 
> type of rhs is:
>    const boost::phoenix::actor<boost::spirit::attribute<1> >&
> 
> the compiler meets this error:
> 
> no matching function for call to
> ‘boost::phoenix::actor<boost::spirit::attribute<1> >::actor(const
> boost::spirit::attribute<1>&)’
> 
> candidates are the default ctor,
> 1) constexpr boost::phoenix::actor<boost::spirit::attribute<1>
> >::actor()
> 
> and the copy constructor
> 2) constexpr boost::phoenix::actor<boost::spirit::attribute<1>
> >::actor(const boost::phoenix::actor<boost::spirit::attribute<1> >&)  
> 
> This seems to be a problem only for >=c++11, also, it was ok with
> 1.58, but not now with develop.
> 
> I haven't managed to extract a small reproducible case yet, and but
> i'll keep trying.
> 
> Thanks,
> 
> MM
>

Does it work with Boost 1.61 or the master branch? Or is it only broken
on the develop branch? I made a recent pull request to `fusion::vector`
that fixed a few cases but broke single element nested cases:

  vector<int> internal;
  vector<vector<int>&> external(internal); // compile error on develop

I think this is _not_ the problem, but rather another one I am
simultaneously trying to fix with the above case - the C++11 vector
implementation in Boost 1.61 always returns true when it is the
destination type for `boost::is_convertible`. I am wondering whether the
type-traits change screws up Spirit in some way, but I have not taken
the time to determine if and how this would be problematic. I have
almost completed a solution which fixes both issues with no additional
runtime overhead (no additional unelidable-by-the-frontend move/copy),
and hopefully a minimal compile-time performance drop. 

More information about this compile error would be useful. This will
either validate that SFINAE'ing available constructors is necessary, or
that there are other outstanding differences in behavior between the two
versions.

Lee

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Spirit-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spirit-general