Re: [boost] [rpc] Introducing Boost.Reflect, Boost.CMT, and Boost.RPC

Subject: Re: [boost] [rpc] Introducing Boost.Reflect, Boost.CMT, and Boost.RPC
From: Brian Wood (woodbrian77_at_[hidden])
Date: 2011-07-31 02:19:04

Daniel Larimer:

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.
Yes, there's another dependency and build step, but at least if you're
using the approach I advocate you are rewarded with a cleaner build.
I've been comparing the differences (between Boost.Serialization and
the C++ Middleware Writer) for a number of years now.  The most
recent comparison using Boost 1.47.0 shows the Boost executables
are between 1.7 and 2.8 times larger than the functionally equivalent
Ebenezer executables.  I haven't compared the build times though so
can't say which is faster, but obviously it takes more time to produce
a chubby file than a svelte file.

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

Only a fraction of the code is in headers.  As much as possible
is in source files that don't have to be processed again and again.

> 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.
I don't think there is any more maintaining the code or finding bugs
involved
with this approach than with the approach you are describing.   The code
is just in an executable form as opposed to in a library.  With most
serialization
libraries you bootstrap by building a large library.  What I advocate takes
1/10 as long to get bootstrapped as the Boost Serialization library.

-- 
Brian Wood
Ebenezer Enterprises
http://webEbenezer.net <http://webebenezer.net/>