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.
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.
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
On Mon, Jun 13, 2016 at 5:45 AM, Damien Buhl <damien.buhl@lecbna.org> 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
On 13/06/2016 13:31, Beman Dawes wrote:
On Mon, Jun 13, 2016 at 5:45 AM, Damien Buhl <damien.buhl@lecbna.org> 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,
On Mon, Jun 13, 2016 at 9:48 AM, Damien Buhl <damien.buhl@lecbna.org> wrote:
On 13/06/2016 13:31, Beman Dawes wrote:
On Mon, Jun 13, 2016 at 5:45 AM, Damien Buhl <damien.buhl@lecbna.org> 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
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
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 ?
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 <damien.buhl@lecbna.org> 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
Am 15.06.2016 7:00 nachm. schrieb "Gerrit Daniels" <gerrit.daniels@gmail.com
:
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 <damien.buhl@lecbna.org>
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
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...
participants (6)
-
Beman Dawes -
Bjorn Reese -
Damien Buhl -
Gerrit Daniels -
Thomas Heller -
Vladimir Batov