Boost logo

Boost :

Subject: Re: [boost] JSON Parser + Boost Fusion + adapted structs
From: Julien Nitard (julien.nitard_at_[hidden])
Date: 2013-05-28 11:46:47


Hi,

A few things to note:

The ISO C++ committee is preparing compile time reflection for C++. It
could be worth to have a look at what they have in mind. Sadly the
associated forum looks empty (
https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/reflection)

There's probably something that can be done with boost.spirit to write
efficient parser/generators. I don't know how well they interface with
Fusion.

I personally like this implementation better than fusion (it would be a
mistake to bring that in boost but it has one advantage: the macros are
slightly less verbose as they don't require the types of the members, just
their names) https://github.com/bytemaster/boost_reflect

Then, there's boost.mirror that hasn't given much news recently, but that
had one thing right: you need something to generate the metadata to avoid
the pitfalls of writing the macro by hand. I had in mind a tool based on
clang to do that but never had time to care about it since my very naive
perl code was enough for my small needs.

Finally, if you do that kind of effort, the applications will be far
greater than JSON, it's definitely worth it !

Suggestion:
> http://bloglitb.blogspot.com/**2010/07/access-to-private-**
> members-thats-easy.html<http://bloglitb.blogspot.com/2010/07/access-to-private-members-thats-easy.html>
>

I think that should not be a starting point at all. The types being parsed
or serialized should be POD-like, ideally. It's much simpler to write code
that deals with variables than with functions. If not, they should be meant
to be serializable in their design. Then, if given no choice, with
unmodifiable 3rd party code, we hack the privacy away. I could do without
that last step.

Regards,

Julien


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