Boost logo

Boost :

Subject: Re: [boost] Seeking endorsement for the reflection library (PFR)
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2017-11-06 19:37:19


6 нояб. 2017 г. 15:23 пользователь "Peter Dimov via Boost" <
boost_at_[hidden]> написал:

Antony Polukhin wrote:

> Yes, but the macro idea came to me first. MPL is slow and adds dependency
> to Boost library, so I'm avoiding it right now.
>

I was thinking about mp11, not MPL. :-)

> Flat/precise strikes me as odd though. Do we have to have both? Precise >
> seems to be what I'd always want.
>
> Flat reflection is left there mostly for users that wish to use library on
> a C++14 compiler and do not wish to exploit the core language defect. But
> you are right, most of the users will prefer precise reflection.
>

>From your talk I was left with the impression that everything needed for
precision already worked on C++14? The only problem is that you have to
reinterpret_cast to a layout-compatible type instead of using structured
bindings.

That was fixed. No more UB in that place. The trick is to get offsets and
then use pointer arithmetic to get correct pointer to the type directly.

Initially I though that flat is what you get because you can initialize
aggregates with the total "flat" element count due to brace elision:

struct X1
{
   int a, b;
};

struct X2
{
   double c, d;
};

struct X3
{
   X1 x1;
   X2 x2;
};

auto x3 = X3{ 1, 2, 3, 4 };

but then I tried it with ubiq{} and it doesn't work. So this is not a
problem and the fields can be counted "precisely". So what's the issue?

You can not extract the X1 and X2 types from ubiq{} without registering
them in the map first or exploiting core language issue. However you can
register all the builtin types in the map, flatten the X3 till builtin
types and extract that knowledge.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk