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 <[email protected]> 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 <[email protected]> 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 [email protected] www.blender.org >> Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands >> >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > > > -- > With best regards, Sergey Sharybin > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
