On 03/01/13 18:31, ecyrbe wrote:
2013/1/1 Rob Stewart <robertstewart@comcast.net>
That leaves only four options for Boost:
1. Ignore C++11 compatibility. 2. Provide exactly C++11 API and behavior. 3. Provide 2 plus pure extensions. 4. Provide both 1 and 2 via two namespaces or classes.
If vincent wants some users opinion, I'm all for option 1 or 4. I know that option 4 is a maintenance nightmare, so sticking with option 1 is fine for me.
I'm concerned about distribution maintenance. Boost.Thread is not a header library. so it is packaged once for all applications in a linux distribution (like debian). breaking compatibility on a header only library is not a problem, but for the other few dynamic libraries of boost, breaking compatibility is a big deal beacause you can't have control.
The changes in question do not break binary compatibility.