Library addition request

Gerrit Daniels

11 Jun 2016 11 Jun '16

6:17 p.m.

Hello, I've written a library that implements automatic serialization of user defined types. You can find it here: https://github.com/gerritdaniels/ctrl. I was wondering if this is something that could be added to the boost library. Kind regards, Gerrit Daniels.

Show replies by date

Vladimir Batov

13 Jun 13 Jun

2:28 a.m.

On 2016-06-12 04:17, Gerrit Daniels wrote:

...

I've written a library that implements automatic serialization of user defined types. You can find it here: https://github.com/gerritdaniels/ctrl. I was wondering if this is something that could be added to the boost library.

Boost has quite a comprehensive serialization library. Therefore, questions about how you lib is different/better compared to boost::serialization, why people might want/need/prefer your serialization library are inevitable. That'd probably be beneficial if you had it written/answered in your documentation.

Damien Buhl

9:45 a.m.

On 11/06/2016 20:17, Gerrit Daniels wrote:

...

Hello,

I've written a library that implements automatic serialization of user defined types. You can find it here: https://github.com/gerritdaniels/ctrl. I was wondering if this is something that could be added to the boost library.

Kind regards,

Gerrit Daniels.

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. I made some toy implementation based on metaparse as well to generate type traits for structs by parsing their declarations, so I would like to see a good reflection library happen. Cheers, -- Damien Buhl alias daminetreg

Beman Dawes

11:31 a.m.

On Mon, Jun 13, 2016 at 5:45 AM, Damien Buhl wrote:

...

On 11/06/2016 20:17, Gerrit Daniels wrote:

...
Hello,

I've written a library that implements automatic serialization of user defined types. You can find it here: https://github.com/gerritdaniels/ctrl. I was wondering if this is something that could be added to the boost library.

Kind regards,

Gerrit Daniels.

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. --Beman

Damien Buhl

1:48 p.m.

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 ? Cheers,

Beman Dawes

4:46 p.m.

On Mon, Jun 13, 2016 at 9:48 AM, Damien Buhl wrote:

...

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

Beman Dawes

6:40 p.m.

...

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.

Axel reports that P0385R0 now contains the design rationale + background info with the link to the implementation, and that the "clang implementation is not complete but a start; Matus hopes to make more progress over summer." See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0385r0.pdf --Beman

Damien Buhl

7:55 p.m.

On 13/06/2016 20:40, Beman Dawes wrote:

...

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

Axel reports that P0385R0 now contains the design rationale + background info with the link to the implementation, and that the "clang implementation is not complete but a start; Matus hopes to make more progress over summer."

See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0385r0.pdf

--Beman

Thank you very much. I'll try out the experimental implementation, that's pretty interesting. I'll check if I can easily bring Boost.Fusion to use the informations provided by the reflexpr header. I wonder if Daniel Gerrit is interested in generating metaobjects from his library ?

Gerrit Daniels

15 Jun 15 Jun

9:02 a.m.

Based on the feedback I've gotten I created a new implementation that separates the reflection information from the serialization. It can be found at: https://github.com/gerritdaniels/reflection. The basic usage is: class DerivedClass : public SimpleClass { REFLECTION(DerivedClass, ((public, SimpleClass)) ((private, int, count)) ((protected, std::string, name)) ) REFLECTED_SERIALIZATION() }; Here the REFLECTED_SERIALIZATION call generates a serialize method that is compatible with boost::serialization. If any further meta information needs to be generated by the REFLECTION macro, just let me know. On Mon, Jun 13, 2016 at 9:55 PM, Damien Buhl wrote:

...

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

On 13/06/2016 20:40, Beman Dawes wrote: 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.

Axel reports that P0385R0 now contains the design rationale + background info with the link to the implementation, and that the "clang implementation is not complete but a start; Matus hopes to make more progress over summer."

See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0385r0.pdf

--Beman

Thank you very much. I'll try out the experimental implementation, that's pretty interesting.

I'll check if I can easily bring Boost.Fusion to use the informations provided by the reflexpr header.

I wonder if Daniel Gerrit is interested in generating metaobjects from his library ?

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Thomas Heller

5:46 p.m.

Am 15.06.2016 7:00 nachm. schrieb "Gerrit Daniels"

...

:

Based on the feedback I've gotten I created a new implementation that separates the reflection information from the serialization. It can be found at: https://github.com/gerritdaniels/reflection.

The basic usage is:

class DerivedClass : public SimpleClass {

REFLECTION(DerivedClass, ((public, SimpleClass)) ((private, int, count)) ((protected, std::string, name)) )

REFLECTED_SERIALIZATION() };

Here the REFLECTED_SERIALIZATION call generates a serialize method that is compatible with boost::serialization.

Wouldn't it be possible to have a generic implementation for serialization that's SFINAEed properly?

...

If any further meta information needs to be generated by the REFLECTION macro, just let me know.

On Mon, Jun 13, 2016 at 9:55 PM, Damien Buhl

wrote:

...

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

On 13/06/2016 20:40, Beman Dawes wrote: 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

...

...
...
...
...
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 the

...

...
...
...
paper.

Axel reports that P0385R0 now contains the design rationale + background info with the link to the implementation, and that the "clang implementation is not complete but a start; Matus hopes to make more progress over summer."

See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0385r0.pdf

--Beman

Thank you very much. I'll try out the experimental implementation, that's pretty interesting.

I'll check if I can easily bring Boost.Fusion to use the informations provided by the reflexpr header.

I wonder if Daniel Gerrit is interested in generating metaobjects from his library ?

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Bjorn Reese

18 Jun 18 Jun

12:14 p.m.

On 06/15/2016 07:46 PM, Thomas Heller wrote:

...

Wouldn't it be possible to have a generic implementation for serialization that's SFINAEed properly?

That can be done with Boost.Serialization today if you bounce the boost::serialization::serialize() function to a trampoline function object and do your SFINAE on the function object. I have described the general technique here: http://breese.github.io/2015/12/20/partiality-for-functions.html I am using this technique together with Boost.Serialization here: https://github.com/breese/trial.protocol/blob/develop/include/trial/protocol... with a SFINAE (well, partial specialization) example here: https://github.com/breese/trial.protocol/blob/develop/include/trial/protocol...

3086

Age (days ago)

3093

Last active (days ago)

List overview

Download

10 comments

6 participants

participants (6)

Beman Dawes
Bjorn Reese
Damien Buhl
Gerrit Daniels
Thomas Heller
Vladimir Batov