Compatibility layer with visit_struct

[cbeck88]

Hi,

I developed a small library for struct-field reflection some time ago that I have used for various projects: https://github.com/cbeck88/visit_struct

A user posted an interesting idea today, that we seek to create a compatibility layer with cereal: cbeck88/visit_struct#10

The idea that I am envisioning is, a patch for cereal so that when it is attempting to serialize or deserialize a struct, it uses SFINAE to

(1) Check if the ::archive member function exists (i.e. the expression that uses it is well-formed), and if so, then use that
(2) If not, then check if the struct is "visitable" as determined by the type trait visit_struct::traits::is_visitable<S>::value, and if so, then use visit_struct::for_each to bring the archiver to each member of the struct in sequence. Also we can get the names of the field members this way if the archiver wants that.

A nice aspect of this is that, because visit_struct already has compatibility layers for the boost::hana and boost::fusion libraries, if the user has structs that are already registered with these libraries, and has included the visit_struct compatibility headers, then visit_struct::traits::is_visitable will return true, and then cereal would be able to use them without further registration.

This would also be really nice for me because then I could try to use cereal in some of these projects and potentially improve the performance of their serialization without too much work.

Does this sound like a patch that the cereal developers are interested in? Do you see any obvious problems that would arise when implementing this plan?

Let me know what you think, thanks.

[AzothAmmo]

This sounds quite interesting - I'm assuming these changes would have to affect all serialization code, likely through changing code in either access.hpp, traits.hpp, or similar locations. Do you have an idea of where and what types of changes you would need to make for this?

It would of course be ideal if this could be implemented solely on an opt-in basis (e.g., by including some type implementation), but it doesn't sound like this would be possible. Any implementation would need to require no dependencies on outside libraries.

Ultimately this really depends on how much code it needs to touch and how intrusive the changes are.

[cbeck88]

Any implementation would need to require no dependencies on outside libraries.

Agree, I would have to commit to an API for these type traits and not ever break it. Which should be fine.

It would of course be ideal if this could be implemented solely on an opt-in basis... but it doesn't sound like this would be possible.

I think in principle this should be possible using SFINAE. I haven't completely thought it through.

An issue with using SFINAE to detect configuration like that if in one compilation unit, visit struct is included before cereal, so cereal would see the presence of the visit struct templates, but in another compilation unit, visit_struct is included after cereal, so it doesn't see the templates, the SFINAE might resolve differently in different units and lead to an ODR violation. However, in reality in those cases, I think you would just get a build failure if you are trying to use visit struct with cereal for a given struct and cereal doesn't find the visit struct templates.

I don't right now see any other issues that might prevent this from working correctly.

Ultimately this really depends on how much code it needs to touch and how intrusive the changes are.

I would have to study cereal in more detail to figure out where the code changes would be needed. This is kind of backlog for me now, but thanks for following up and sharing your thoughts.