On 24 Nov 2014 at 22:05, Pete Bartlett wrote:
I'd want to give authors a free hand, as much as possible. E.g. if a new library came along that needed a tuple facility, they should feel free to just use <tuple> / std::tuple rather than being obliged to template on tuple type (or more sophisticatedly, use the Boost.BindLib library that Niall says is around the corner), just in case someone is stuck with boost::tuple. If someone else is stranded on VS2005 (or whatever) and comes along with a patch to backport support to boost::tuple, then great.
Be aware that for the switchable underlying STL facility, BindLib absolutely requires template aliasing support in the compiler (otherwise he can't generate the binds from your library to either boost::tuple or std::tuple). And template aliasing is a C++ 11 feature, so your compiler needs to be C++ 11 mode. tuple, incidentally, is in the presupplied bindings, but I have absolutely no idea if it works. No reason it shouldn't, though.
For existing libraries on the other hand, it seems wrong to break backwards-compatibility without a really good reason so if a library is c++98 now, why not leave it that way. If someone thinks a particular domain can be done better using c++11 facilities, then I think a "v2" of the library makes sense.
One of BindLib's main goals is to solve the API and ABI versioning problem in all Boost libraries. Once a library enters Boost it is supposed to keep backwards API compatibility and optionally ABI compatibility, and doing this usually involves an awful lot of #ifdef which is a pain to debug and maintain. A BindLib based library lives in some unique namespace you don't need to care about as the binds and any inline namespace support in your compiler make that unique namespace not appear to code using your library. That way if I change AFIO to have a breaking API change, I can ship v1.2 of AFIO *and* v1.3 of AFIO and both versions coexist happily just as a Boost.Filesystem based AFIO coexists happily with a STL Filesystem based AFIO. Code using AFIO that is tied to particular version simply binds in a specific version of AFIO, and can carry on with that API version as long as it feels like, though probably without bug fixes. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/