On Nov 7, 2013, at 8:38 AM, Tom Browder wrote: > Is it fair to use any Boost code in BRL-CAD C++ code?
We obviously use it now, but our main usage is now obsolete. Our LIBPC (parametric constraint) library uses the Spirit parser in Boost, which is why most of src/other/boost is there. That usage is probably going to entirely go away, though. Without Spirit, the cost-benefit is limited. I was actually hoping to remove Boost. > If so, I think > the cmake files need to reflect that (i.e., point to the entire > BRL-CAD Boost if not found on the local host). As it is now it seems > to be there for the convenience of a small set of files and much local > boost cmake testing. That was experimental code that never made it to production use after a couple years of active development. > And I plan to use more Boost code such as unordered_map. Anything more compelling than an unordered_map? LIBBU's various containers are usually more than sufficient and more efficient. Even a std::map is often sufficient since we usually want things to display or get processed in a consistent order, even if we don't usually care what that order is. If the performance difference matters, it calls into question lots of other issues (i.e., demonstrate it matters). How much boost does bcp pull in if you only scan a usage of unordered_map? That said, that one is already in src/other/boost so you could just use it in some places. Cheers! Sean ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
