On Mon, Jun 13, 2016 at 9:48 AM, Damien Buhl
On 13/06/2016 13:31, Beman Dawes wrote:
On Mon, Jun 13, 2016 at 5:45 AM, Damien Buhl
wrote: [snip]
Hello,
I just looked briefly to the README of your library, and what I see is that most of the advantages of the library comes from the reflection facilities you've built. But I can be wrong, as I didn't looked more than that..
I think that yet-another Boost.Serialization doesn't make that much sense, however I think that a Reflection library, which generates easily traits about structs/classes to iterate upon, get information about name and so on would make sense.
Currently in Boost.Fusion we need a bit of that to adapt structures and classes to tuples, and therefore we generate in the same way as your library some meta information like struct_member_name. But Boost.Fusion is not intended to be a reflection library, so it won't go further than that.
What would be awesome in my opinion, from a library like yours, would be to reflect type information and get the reflected information be compatible with current libraries which leverage/could leverage such information like: Boost.Spirit, Boost.Serialization, Boost.Fusion, Boost.Hana...
It's just my 2cent and my opinion, I think there was already effort for a reflection library, but I think the effort stopped.
+1 If you haven't done so already, you also might want to look at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0194r1.html
IIUC, that proposal is progressing through the standards committee, and may move to the working paper (i.e. next) stage as soon as next week at the Oulu meeting.
Thanks that you are telling about it, indeed I should have told that such a library would be better if it produced traits that respects the API of the reflection proposal.
Do you know if there is already an implementation of the proposal, in terms of compiler extension, or even as a macro-based reflection type traits generator ?
https://github.com/matus-chochlik/clang/tree/mirror-reflection I had to ask; turns out that link got dropped from the R1 version of the paper. --Beman