Re: [FPR] Review of FPR starts Today: Sept 28 - Oct 7

From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2020-10-06 11:19:34

пт, 2 окт. 2020 г. в 21:03, Richard Hodges via Boost <boost_at_[hidden]>:
<...>
> *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.tutorial.custom_printing_of_aggregates

> *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