|
Boost : |
From: Doug Gregor (dgregor_at_[hidden])
Date: 2005-03-23 13:47:05
On Mar 23, 2005, at 1:19 PM, Robert Ramey wrote:
> At least in the serialization library it can occur that the library
> calls
> back into the users code. Also there are lots of c style asserts.
> These
> can be helpful in debugging users code. Finally, the release libraries
> collapse inline code to the point its impossible to figure out how one
> got
> to where he did.
All great reasons to have the option to build debug libraries, but not
reasons to build debug versions by default.
Here's one reason not to build debug versions by default: they could
give the user the impression that Boost is bulky and slow, because
they're using code only meant for debugging the library itself or
errors in the use of the library.
> Sometimes debug and release code is built with
> incompatible options. A users code built for debug might call a
> function
> that was inlined in the release version of the library and left out of
> line
> in the debug version of the library. If this happens, an application
> built
> for debug may fail to link with one built for release - even though
> they use
> the same headers.
We know of one compiler where this does occur (Visual C++), but I
believe this is the exception and not the rule.
> So there are case where the debug libraries are useful for things
> other than
> debugging the library itself.
Agreed.
Doug
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk