Joel de Guzman comments

Results 505 comments of


                                            Joel de Guzman

Adapt bimaps::relation::structured_pair, container::detail::pair, and compressed_pair

Awesome!

Adapt bimaps::relation::structured_pair, container::detail::pair, and compressed_pair

I suppose it makes sense to merge this. I have a request though: would you take care of support related issues related to these additions?

Consider making containers trivially copyable when possible

Makes sense! Would you contribute a patch or a PR? ;-)

make_map<int>(make_vector()) cannot be compiled

It looks like a bug with `make_map`. In the meantime, a workaround not using `make_map`, but directly using `map`. Something like: ```c++ #include #include #include using namespace boost::fusion; typedef map<...

make_map<int>(make_vector()) cannot be compiled

> I wonder why `arg` is lvalue reference rather than forwarding reference Well, actually fusion predates c++11. There are still some things need to be reworked, but care must be...

'J': is not a valid type for non-type template parameter 'J' error in boost\fusion\container\vector\vector.hpp

If you think this is a fusion issue, please post an MVCE (without any dependencies). I have no expertise on the other dependent libraries.

'J': is not a valid type for non-type template parameter 'J' error in boost\fusion\container\vector\vector.hpp

> Has this issue been solved？ Again, please post an MVCE https://stackoverflow.com/help/minimal-reproducible-example

'J': is not a valid type for non-type template parameter 'J' error in boost\fusion\container\vector\vector.hpp

> #include This is not directly a Boost.Fusion issue, and should probably be redirected to Boost.Numeric.Odeint instead.

What about "boost pfr" extension?

What is `non_fusion_tag` ? [edit, sorry if that was not clear]... I meant why is the link pointing to the `non_fusion_tag` ?

What about "boost pfr" extension?

Ah. Makes sense. Go for it.