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