[Bf-committers] Boost dependency
erwin.coumans at gmail.com
Mon Nov 5 18:00:18 CET 2012
It would be interesting to what you are using from boost.
Containers (replacements for vector, list, hashmap/unordered) doesn't seem enough for all those megabytes dependency. In our Bullet library they are just a few files. A threading abstraction or smart pointer isn't convincing either.
Pointing to other large or templated libraries that are"just as bad or worse" is not a good argument either.
My few cents,
Sent from my iPhone
On Nov 5, 2012, at 8:22 AM, Lukas Tönne <lukas.toenne at gmail.com> wrote:
> 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 ). 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.
>  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
>> 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:
>>> 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)
>>> 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
>> With best regards, Sergey Sharybin
>> Bf-committers mailing list
>> Bf-committers at blender.org
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers