пт, 2 окт. 2020 г. в 21:03, Richard Hodges via Boost <boost@lists.boost.org>: <...>
*test-1:* see: https://github.com/madmongo1/pfr_review/blob/master/pre-cxx20/test-1.cpp
Looking into the code I found that there are overloads of quoted_helper(T&&) in the pfr::detail namespace in order to ensure proper quoting of std::string and (if present) std::string_view.
However, there is no means for me to provide a customisation of the quoting concept for unsupported types that I might want to quote (such as boost::string_view, std::exception, json::string, etc). In my view this is a design oversight.
Added an example into the docs on customization of printing: http://apolukhin.github.io/magic_get/boost_pfr/tutorial.html#boost_pfr.tutor...
*test-2 and test-3:* https://github.com/madmongo1/pfr_review/blob/master/pre-cxx20/test-2.cpp Seems to produce infinite recursive template expansion
The example should not compile, because the nested types are not aggregates. In C++14 it gives a correct static assert ../../../boost/pfr/detail/core14_classic.hpp:509:5: error: static_assert failed "====================> Boost.PFR: Type can not be used is flat_ functions, because it's not POD" in C++17 it also gives a correct static assert ../../../boost/pfr/detail/fields_count.hpp:225:9: error: static assertion failed: ====================> Boost.PFR: Type must be aggregate initializable. Clang crashes after that. GCC goes into an infinite loop, ignoring all the template instantiation depth limitations and static_assert messages printing. Using BOOST_PFR_PRECISE_FUNCTIONS_FOR now gives a complaint of missing sd::hash specialization: ../../../boost/pfr/detail/functional.hpp:133:9: error: static_assert failed due to requirement 'sizeof(boost::basic_string_view<char, std::char_traits<char> >) && false' "====================> Boost.PFR: std::hash not specialized for type T" I've added the tests and will report issues to the compiler developers soon. If the behavior is surprising for you, please elaborate on expected behavior.
https://github.com/madmongo1/pfr_review/blob/master/pre-cxx20/test-3.cpp Complains about lack of std::hash for boost::string_view
Made the complaint more explicit.
*test-4:* https://github.com/madmongo1/pfr_review/blob/master/pre-cxx20/test-4.cpp
This may be controversial, but I wonder whether it would be a good idea to provide specialisations for operations on containers in the pfr::ops namespace, or a sub-namespace of it.
Given:
struct family { std::vector<animal> members; } f;
the following code will not compile because of the lack of streaming operator for std::basic_vector<>
int main() { using namespace boost::pfr::ops; std::cout << f << '\n'; }
For my anticipated use case of this library, this would be a common requirement, and having to write an overload of operator<< for family would defeat the purpose of using PFR.
The library does not intend to provide ostream operators for any type. This is out of the library scope.
*test-5:* https://github.com/madmongo1/pfr_review/blob/master/pre-cxx20/test-5.cpp
flat_structure_tie doesn't work with const references.
this line refused to compile:
auto& [a, b, c] = boost::pfr::flat_structure_tie(n);
when n was const. It was fine when n was a mutable lvalue.
Fixed -- Best regards, Antony Polukhin