Le 03/05/12 08:15, Andrey Semashev a écrit :
Eric Niebler wrote:
Say I'm rewriting an existing Boost library and targeting C++11 users. I plan to ship C++03 and C++11 versions of my library side-by-side, so back-compat isn't an issue for the new code. Is there a reason to prefer using Boost's versions of utilities like enable_if, type traits, integral constant wrappers (e.g. mpl::int_), tuples, etc., over the now-standard ones?
I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason. Isn't easier to just use the boost versions knowing that they will be implemented in the most efficient/appropriate way for the compiler in question? Although I wouldn't be so sure about the "most efficient/appropriate"
On Thu, May 3, 2012 at 10:30 AM, Robert Ramey<ramey@rrsd.com> wrote: part, I would still use boost for several reasons. This is the code we're in control of (so if there are bugs we can fix them ASAP), we know how it works (i.e. potential pitfalls and advantages) and it's available everywhere.
There is an additional advantage, we can extend it intrusively to try new improvements to the standard libraries. E.g. I don't see how we can implement thread cancelation/interruption on top of the standard Thread (well I have not tried it ;-)), or shared mutex without modifying the unique_lock. I guess that there are a lot of more examples. These extensions to the standard should be stated explicitly in the documentation. IMO, every Boost library that has a counterpart in the standard should comply with the standard as much as possible and should use the standard whenever it is possible (that is the class/function is available and the library don't introduce extensions on them). Any deviation from the standard could be seen as a defect and should either be fixed or described explicitly as a limitation on the documentation. Best, Vicente