Boost logo

Boost :

Subject: Re: [boost] [rpc] Introducing Boost.Reflect, Boost.CMT, and Boost.RPC
From: Daniel Larimer (dlarimer_at_[hidden])
Date: 2011-07-30 21:58:40


On Jul 30, 2011, at 7:16 PM, Brian Wood wrote:

> Daniel Larimer <dlarimer_at_[hidden]>
>
>> 1) No code generation required (best for C++ to C++, but with a proper
> JSON interface can communicate with any language)
>
> Code generation is being done by something here. In this case it is
> probably being done by a C++ compiler that starts from scratch for
> every file it has to compile.
>
I think there is a big difference between using the pre-processor / templates and using another program, another language, another dependency, another build step. Besides, even if you use a 3rd party tool like google protocol buffers, ICE, etc that does code generation, the C++ compiler still must start from scratch every time one of the generated headers is included. Often times you end up deriving from the generated interface and your code breaks if you change the interface file, etc. Furthermore, now you must maintain the code for the generator, find bugs, bootstrap by building the generator, etc. At the end of the day, code generation solutions require more code and effort. Their only redeeming value is that they can target multiple different languages from the same interface description. However, with the built in reflection, I see no reason why you could not write a tool to generate Java, PHP, etc code for any interface defined by Boost.Reflect.

In the case of Boost.RPC, there is no code generation because it is all handled by Boost.Reflect's type erasure features. Thus the entirety of the code generation is a single 1 line macro BOOST_REFLECT_ANY().

> --
> Brian Wood
> Ebenezer Enterprises
> http://webEbenezer.net
>
> "The heavens declare the glory of G-d; and the firmament
> shows His handiwork." Psalm 19:1
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


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