wt., 6 paź 2020 o 13:29 Peter Dimov via Boost napisał(a):

Andrzej Krzemienski wrote:

...

3. The library buds on a basic concept of "Base-less aggregate".

That's not really true though, is it? E.g.

#include #include <string> #include <iostream>

struct X { std::string a; };

struct Y { std::string b; };

struct Z: X, Y { std::string c; };

int main() { std::cout << boost::pfr::tuple_size_v<Z> << std::endl; }

compiles and prints "3". Bases are treated as members by the precise API.

But this is only for tuple_size. If you do a for_each, the compilation breaks: ``` Z z {{}, {}, {}}; boost::pfr::for_each_field(z, [](auto const&){}); ``` This is because brace initialization of aggregates is "incompatible" with structured binding for aggregates now in C++20. I still acknowledge that I may have not understood the requirement that PFR puts on types. This makes my request even stronger: I have to know what it expects of my types to work. I expect that this would work when I switch between C++17 and C++20. (C++20 changed the initialization of aggregates: base is treated as yet another member. But it did not change the structured binding.) Regards, &rzej;

вт, 6 окт. 2020 г. в 14:42, Andrzej Krzemienski via Boost :

wt., 6 paź 2020 o 13:29 Peter Dimov via Boost napisał(a):

...

Andrzej Krzemienski wrote:

...

3. The library buds on a basic concept of "Base-less aggregate".

That's not really true though, is it? E.g.

#include #include <string> #include <iostream>

struct X { std::string a; };

struct Y { std::string b; };

struct Z: X, Y { std::string c; };

int main() { std::cout << boost::pfr::tuple_size_v<Z> << std::endl; }

compiles and prints "3". Bases are treated as members by the precise API.

But this is only for tuple_size. If you do a for_each, the compilation breaks:

``` Z z {{}, {}, {}}; boost::pfr::for_each_field(z, [](auto const&){}); ```

This is because brace initialization of aggregates is "incompatible" with structured binding for aggregates now in C++20.

I think we took the wrong turn in C++17, when allowed inheritance for aggregates. Unfortunately that's not getting better with time :( -- Best regards, Antony Polukhin

On 06.10.20 21:50, Andrzej Krzemienski via Boost wrote:

struct Person { std::string firstName; std::string lastName; int age; };

struct Employee : Person { double salary; };

struct Prisoner : Person { int cellNumber; }; ``` This (a) avoids duplication, and (b) I have the slicing do exactly what I need: convert an Employee to a Person. Now, I am disappointed with what C++17 did to aggregate initialization. My natural expectation would be that:

``` Employee e {"Bilbo", "Baggins", 111, 1000.00}; ``` Flattens the class hierarchy and initializes each of the four members. Apparently , the C++ committee has a different vision for it. But I have noticed that if I changed derivation into aggregation (as I indicated earlier), the "flat" part of FPR would do exactly what I needed.

Does that example really work? My expectation would be that flat reflection would try to break apart the std::strings, and fail with a compile-time error because std::string is not an aggregate. If it does work, then flat reflection is a lot more useful than I had initially thought! -- Rainer Deyke (rainerd@eldwood.com)

śr., 7 paź 2020 o 09:58 Andrzej Krzemienski napisał(a):

śr., 7 paź 2020 o 09:22 Rainer Deyke via Boost napisał(a):

...

...

struct Person { std::string firstName; std::string lastName; int age; };

struct Employee : Person { double salary; };

struct Prisoner : Person { int cellNumber; }; ``` This (a) avoids duplication, and (b) I have the slicing do exactly what I need: convert an Employee to a Person. Now, I am disappointed with what C++17 did to aggregate initialization. My natural expectation would be

On 06.10.20 21:50, Andrzej Krzemienski via Boost wrote: that:

...

``` Employee e {"Bilbo", "Baggins", 111, 1000.00}; ``` Flattens the class hierarchy and initializes each of the four members. Apparently , the C++ committee has a different vision for it. But I have noticed that if I changed derivation into aggregation (as I indicated earlier), the "flat" part of FPR would do exactly what I needed.

Does that example really work? My expectation would be that flat reflection would try to break apart the std::strings, and fail with a compile-time error because std::string is not an aggregate.

If it does work, then flat reflection is a lot more useful than I had initially thought!

The following compiles and outputs "1 2 3 " on my GCC compiler:

``` struct A { int x, y; };

struct B { A a; int z; };

int main() { B b = {{1, 2}, 3}; boost::pfr::flat_for_each_field(b, [](auto const& field){ std::cout << field << " "; }); } ```

However, when I substitute strings for ints it no longer compiles. I am not sure if this is just a bug in the implementation or an inherent limitation of this library.

Oh, I know why it is doing this. In general, the library cannot know to what level the user wants her structure to be flattened: ``` struct W { // you do not know what is inside }; ostream& operator<<(ostream&, const W&); struct A { W x, y; }; struct B { A a; W z; }; int main() { B b = {{w1, w2}, w3}; boost::pfr::flat_for_each_field(b, [](auto const& field){ std::cout << field << " "; }); } ``` Here, it is not clear whether you want to just print the W, or flatten it further down if it happens to be an aggregate. So maybe the "flat" part in PFR cannot solve my problem. Regards, &rzej;

śr., 7 paź 2020 o 12:30 Antony Polukhin napisał(a):

ср, 7 окт. 2020 г. в 10:59, Andrzej Krzemienski via Boost :

...

śr., 7 paź 2020 o 09:22 Rainer Deyke via Boost napisał(a):

...

On 06.10.20 21:50, Andrzej Krzemienski via Boost wrote:

...

struct Person { std::string firstName; std::string lastName; int age; };

struct Employee : Person { double salary; };

struct Prisoner : Person { int cellNumber; }; ``` This (a) avoids duplication, and (b) I have the slicing do exactly

...

...

...

need: convert an Employee to a Person. Now, I am disappointed with what C++17 did to aggregate initialization. My natural expectation would be that:

``` Employee e {"Bilbo", "Baggins", 111, 1000.00}; ``` Flattens the class hierarchy and initializes each of the four members. Apparently , the C++ committee has a different vision for it. But I have noticed that if I changed derivation into aggregation (as I indicated earlier), the "flat" part of FPR would do exactly what I needed.

Does that example really work? My expectation would be that flat reflection would try to break apart the std::strings, and fail with a compile-time error because std::string is not an aggregate.

If it does work, then flat reflection is a lot more useful than I had initially thought!

The following compiles and outputs "1 2 3 " on my GCC compiler:

``` struct A { int x, y; };

struct B { A a; int z; };

int main() { B b = {{1, 2}, 3}; boost::pfr::flat_for_each_field(b, [](auto const& field){ std::cout << field << " "; }); } ```

However, when I substitute strings for ints it no longer compiles. I am not sure if this is just a bug in the implementation or an inherent

what I limitation

...

of this library.

That's an inherent limitation of flat reflection. Flat reflection is kind of a legacy - it's the first implemented "reflection", and it was working only for PODs. Since early versions of PFR new precise ways of reflection were discovered. Moreover, precise reflection turned out to be much portable and works on more compilers.

...

I wonder what is your *primary* motivation for removing it: A. Because it is not implementable in many cases? B. Because there is not enough motivation for it, and people don't understand what it is for? C. Because it can be accidentally confused with the "precise" version?

It's rather 'D.' - unlike flat reflection, precise representation work in much more cases and on more platforms (MSVC fails to do flat reflection)

Interesting. I do not understand enough about the implementation to be making definite statements, but based on my superficial knowledge I expect that it should be possible to reimplement a "flat" reflection on top of "precise" one. 1. First you call structure_to_tuple() and you get std::tuple 2. For every Tn that is an aggregate type you apply structure_to_tuple() recursively. 3. Then you potentially get a tuple of nested tuples and you need to flatten it. Maybe this is more difficult than it seems at first. You may also run into different implementation limits. Maybe someday when I have more free time I will try to write a prototype. Regards, &rzej;

śr., 7 paź 2020 o 17:11 Antony Polukhin napisał(a):

...

Interesting. I do not understand enough about the implementation to be making definite statements, but based on my superficial knowledge I expect

ср, 7 окт. 2020 г. в 15:48, Andrzej Krzemienski : that it should be possible to reimplement a "flat" reflection on top of "precise" one.

...

1. First you call structure_to_tuple() and you get std::tuple 2. For every Tn that is an aggregate type you apply structure_to_tuple() recursively. 3. Then you potentially get a tuple of nested tuples and you need to flatten it.

Yes, that's doable. But is that really a popular feature?

Flat representation was useful, because there was no precise representation in the early versions of the library. That was the only way to do things.

Back to your example:

struct Person { std::string firstName; std::string lastName; int age; };

struct Employee : Person { double salary; };

struct Prisoner : Person { int cellNumber; };

Probably composition would work better than inheritance for your needs?

struct Person { std::string firstName; std::string lastName; int age; };

struct Employee { Person person; double salary; };

struct Prisoner { Person person; int cellNumber; };

With composition you get more flexibility:

std::ostream& operator<<(std::ostream& os, const Person& p) { os << "person: "; pfr::write(os, p); return os; }

std::ostream& operator<<(std::ostream& os, const Prisoner& p) { using pfr::ops; return os << p; }

// Outputs: {person: {"Harley ", "Quinn", 21}, 100500} std::cout << Prinsoner{{"Harley ", "Quinn", 21}, 100500};

I admit that the motivation for the flat reflection is much smaller than for the precise one, so in the end it may not be worth the effort. Regards, &rzej;