[boost] JSON Parser + Boost Fusion + adapted structs

[Stephan Bourgeois]

Hi everybody,

I am writing a prototype for the JSON parser for the GSoC with the support
of Bjorn Reese. When discussing the proposal, Michael Marcin suggested an
interface that allows the user to define a struct reflecting the JSON data
structure. I have been looking at Boost.Fusion to enable the parser to
"fill in" the values in the struct.

It looks like I'm after a solution described in the following post:
http://stackoverflow.com/questions/13830792/simulate-compile-time-reflection-in-c

Could anyone tell me if this is a good starting point, and/or if there are
other ways of achieving this.
Thank you,
Stephan.

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

[Max Skvortsov]

Stephan Bourgeois <stephanb2 <at> gmail.com> writes:

>
I have been looking at Boost.Fusion to enable the parser to
> "fill in" the values in the struct.
>
> It looks like I'm after a solution described in the following post:
> http://stackoverflow.com/questions/13830792/simulate-compile-time-
reflection-in-c

I used BOOST_FUSION_ADAPT_STRUCT in conjuction with boost.serialization to
automate serialization of messages between clients and server in my
application. It just reflects simple C++ structs with data to XML/TEXT for
pass them throughout network.
After few experiments with RTTI, some kind of type erasure (with "variant"
and
"any" types), true object-oriented approach and boost.fusion I have found
that
the last one gives more benefits and fit in static type system of C++ more
naturally.

>
> Could anyone tell me if this is a good starting point, and/or if there are
> other ways of achieving this.
> Thank you,
> Stephan.
>

As alternate you look at implementation of serialization in
Different ORM libraries, but they use external tools
Message passing and RMI libraries like Apache.Thief or libcppa, but they use
RTTI AFAIK.

I think boost.fusion is the only one way to implement true compile-time
reflection. With certain restrictions, of course.

[Michael Marcin]

This may be useful for your library.

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


Code sample:
https://gist.github.com/1528856

Motivating discussion:
http://thread.gmane.org/gmane.comp.lib.boost.devel/226883/focus=226889

[Julien Nitard]

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

[Niall Douglas]

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

Easiest of all is to expose the compiler's internal state via a magic
namespace in the form of pseudo-template definitions. Then one has, at
metaprogramming stage, access to everything the compiler knows at that
point.

I posited that idea to Chandler Carruth for clang at C++ Now. He didn't seem
adamantly opposed.

Third party libraries (e.g. a Boost one) could wrap up each compiler's
internal magic namespace into something portable and therefore useful.

Niall

[Richard]

[Please do not mail me a copy of your followup]

bo...@lists.boost.org spake the secret code
<CAJosjANCA=jj+QseaaA63KrhmT8E-G...@mail.gmail.com> thusly:

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

They interface great; it's common practice to adapt a structure with
BOOST_FUSION_ADAPT_STRUCT and have that tied into a Spirit grammar.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>