We should add a note to the style guide. I think that the STL/TR1 is fine for non-critical path, but I wouldn't go so far as to rewrite currently working code. The STL tends to hide costs and tends to use algorithms with relatively high constant but low asymptotic costs by default which makes tuning it for the critical path just as hard as writing custom code IMHO. However, off the critical path, the familiarity of the STL probably is a win.
john On Mon, Jul 26, 2010 at 5:25 AM, Alan M. Carroll < a...@network-geographics.com> wrote: > I understand the issue with allocation and critical path. Fortunately my > current intended use is in an optional, non-critical path case. > > Are there any concerns about exception safety? Should I take care to wrap > any potentially allocating calls in try/catch to handle out of memory > conditions? Or is the concern primarily about performance? > > Personally I like Boost very much, and use it in all my other projects > extensively, but I can how others might not like its interconnectedness. I > think it might be reasonable to permit those parts of Boost which have been > adopted in to TR1 and others only on a case by case basis, depending on how > "untangled" they can be adopted. For instance, there was a note recently > about wrapper code for the API. I think we might do better to look at Boost > smart pointers, if we can get those by themselves > >
