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-02 11:02:04

On Dec 2, 2009, at 10:34 AM, Vladimir Prus wrote:

> Phil Endecott wrote:
> 
>> Vladimir Prus wrote:
>>> -O2 makes debugging experience sufficiently painful that nobody will ever
>>> want to use that in debug builds, except in very unusual circumstances
>> 
>> I routinely build with -O3 -g 
> 
> And is that the set of options you actually use when you wish to debug something
> that is know to be buggy? Or are those the set of options that permit you to
> get somewhat usable backtrace "in the field"?

Wow, I am often surprised by the tangential discussions that pop up here :-)

Yes, it is sometimes proper to use both -g and -O2 (or -O3); I do it at times, but not as often as only with -g.

BUT, this was not about "debug" vs "release" build. I know that you created a build without any optimization and with debug symbols (-g) when you got your big output (300k, right?) I just wanted to find out what the extra luggage of Boost.Serialization would be in a more relevant scenario, of a release build, i.e., I never stated that I created a "debug" build.

And regarding the linear space function (of some 40kB + N * 20 B) becoming a constant (40kB) when using a non-inline function wrapping the serialization: yes, I am quite aware that even an innocuous function call does require a few bytes (especially after having implemented a lot of compilers and abstract machines myself), did I state otherwise? This was about the *extra* space (or time) needed for Boost.Serialization, and I did not regard those function invocations to have anything to do with Boost.Serialization per se, so those bytes did not go into that account. Obviously, not all of those 20B could be attributable to Boost.Serialization, but at least it presented a decent upper limit on the linear function.

/David