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, Erwin Sent from my iPhone On Nov 5, 2012, at 8:22 AM, Lukas Tönne <[email protected]> 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 [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 _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
