[Bf-committers] Boost dependency

Lukas Tönne lukas.toenne at gmail.com
Mon Nov 5 17:22:03 CET 2012

I agree with Sergey. Boost certainly looks huge in downloads for
coders, but AFAIK when linking static libraries it actually strips not
just unused libraries but even all unused *symbols* from a library.
Since we're using only a small subset of boost it does not increase
the binary size more than what would be needed if we tried to
implement all those features ourselves.

It's true that using templates excessively can lead to
incomprehensible code. However, the typical use case for templates is
generic container classes (lists, hash, etc.), for which there is
usually just one template parameter and that is really not so hard to
understand. Code can be further simplified by making typedefs for such
templated classes, so the template only has to be used in one place:

typedef boost::unordered_map<Blah> BlahMap;

Some of the features we're using from boost are really quite complex
(e.g. boost::unordered [1]). Implementing these types on our own would
be just stupid IMHO, especially if you want to avoid templates at all
cost and have to do that for every type (or even do it C style with
untyped void*, which is even more confusing and less efficient).

I don't see the advantage in kicking out boost.

[1] http://www.boost.org/doc/libs/1_51_0/doc/html/unordered.html

On Mon, Nov 5, 2012 at 4:47 PM, Sergey Sharybin <sergey.vfx at gmail.com> wrote:
> Boost is only 50Mb, and it consists of lots of smaller libraries (like 28
> libs) and we're only using few of them (like 3 or 4). This libs are getting
> stripped further when linking blender. We're also using some header-based
> classes from boost, but that's not so much i guess.
> Not sure why portability would be an issue -- boost is used by lots of
> other applications and it's nicely supported on all platforms we're
> compiling blender for
> We're not using so much templates from boost atm. There are much more
> templates in eigen library. And much more templates in libmv/ceres. But
> that's not issue there -- without templates here the could would have been
> completely unmanageable. Be my guest to make it templateless with the same
> readability.
> And i'm still not sure what's the issue here? We're already using boost in
> quite a lot of areas and not sure why don't use it in other areas?
> P.S. If you're worried about size let's switch to discussing dependency
> from SDL, which we're using as one of possible backends for audio. SDL is
> like 150-200Mb of dependencies we're actually using (only helps that it's
> possible to link dynamically against SDL and keep it working) -- it
> includes SDL itself, ALSA which is used by SDL and so on.
> On Mon, Nov 5, 2012 at 9:30 PM, Ton Roosendaal <ton at blender.org> wrote:
>> Hi,
>> Can I get advice from the c/c++ devs here if Boost is going to be a
>> default dependency now?
>> It is currently possible to disable Boost by excluding some libs (like for
>> mini blender compiles).
>> I'm concerned about portablity too. And from my limited POV any library
>> takes 200 MB diskpace is suspicious!
>> Next to that - we do serious attempts to keep code readable in Blender.
>> Heavy use of templates can lead to constructions nobody will ever be able
>> to debug. It's a common issue with C code too - but in C++ hacking even
>> more. In other developer environments people agree together on sticking to
>> only a limited subset of all C++ features for that reason.
>> (Our audio library now uses Boost, that's the reason)
>> Laters,
>> -Ton-
>> ------------------------------------------------------------------------
>> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
>> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> --
> With best regards, Sergey Sharybin
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list