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