Also I don't really believe that the footprint is that large. You
could indeed take this same view with using STL... but I don't
think we should go there.
The difference is the current STL is included with the compiler...
- boost itself has quite some footprint to put into that projects
SCM.
Why? It isn't something you have to SCM... you don't SCM other
libraries do you?
For pretty much every project I've worked on, regardless of the
employer, 3rd party library go to SCM. Sometimes in compressed form,
but they definitely belong there. Xerces, Xalan, any sourceforge
libraries, boots, libzip, libtiff, libjpeg, whatever.
One typical requirement is that for every release / tag it is
possible to build exactly the same binary from the SCM, checked out
on a machine with a fresh, default developer tools install.
Boost 1.33 is more than 10 MB compressed. 1.34_RC takes nearly 1 GB
diskspace for the checked out and buildt i386 only version.
Working with boost 1.33, there were some changes I needed to apply to
get boost::filesystem, 1_3x had some bugs in shared_ptr that needed
patching on PPC / Metrowerks etc (see the Adobe Indesign2 SDK for
details). Where would you store those patches, if not in your SCM?
YMMV, but it's a decision that should be carefully evaluated.
With respect I disagree. boost is mature, established and highly
respected. A great deal of ratification occurs prior to boost
modules becoming accepted.
Reread my OP to find where I "disrespect" boost. In contrary.
It just needs to be useful enough for the particular project to
justify the footprint. It is not "tiny".
I use it for projects that benefit really from it. But I don't throw
it into every of my projects just because it's cool.
Regards,
Tom_E
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/xcode-users/email@hidden
