Re: [boost] [explore] Library Proposal: Container Streaming

Subject: Re: [boost] [explore] Library Proposal: Container Streaming
From: David Bergman (David.Bergman_at_[hidden])
Date: 2009-12-01 13:37:35

On Dec 1, 2009, at 1:21 PM, Jeremy Pack wrote:

> Responding to two e-mails from David:
> 
> 
>>> And that code still has
>>> to be parsed by the compiler.
>> 
>> This is a different issue. Is that your problem, that you think compilers
>> have a problem with some complex constructs inside the Boost.Serialization
>> library? Does the compiler fail? Consume too much resources? Too much time?
>> 
>> And:
> 
>> 
>> Vladimir's claim is that his solution is lighter in two aspects (I think):
>> 
>> 1. Easier to use
>> 
>> 2. Not dependent on Boost
>> 
>> I hope we all realize that, no, #1 is not the case, and if so, one can
>> create a simple wrapper as the one above to make it easier. So, what about
>> #2? Well, as a proposed Boost library, it is no longer that important.
>> 
>> 
> I agree with Volodya here. In my environment at least, we would not be
> willing to include all of the serialization headers just to be able to print
> a vector to the screen. We'd write yet another custom vector printing
> function instead (which we have). The reason is that we have very large
> binaries, and if we included the serialization library into many of our
> compilation units, it would have a non-trivial effect on compilation time.
> C++ compile times are a concern to many of us, I think - hence the invention
> of languages such as Go (without the exclamation point).
> 
> Besides, I like the Explore library as is (other than the name, sorry).

So, we have two issues:

1. Compilation time. Have you a guesstimate as to much time is spent on parsing, compiling and linking (see #2 below) Boost.Serialization for a case with N simple container outputs?

2. The extra size on executables (or libraries) given the linked-in; to give you some insight into this, when compiling the examples provided in this thread, the code size increased by 28k when linking the (MT version) of Boost.Serialization with the executable.

I assume the issue of "easy to use" is a non-issue, right, i.e., that the examples provided show that one can use very few lexemes in outputting containers using Boost.Serialization?

I still believe it is a false notion that Boost.Serialization would add that much more than any non-trivial proposal in terms of compilation time or size of output.

If I see some figures regarding #1 and #2 above that scare me - even for dreaded embedded targets :-) - OR a much simpler way to output containers than the

        boost::archive::text_oarchive(std::cout) << v;

in any reasonable typedef'd or wrapped version (e.g., "arch(std::cout) << v"), then I will gladly stand behind a new outputter in our joyous family.

/David