transforming ex. boost lib into C++11-only lib?
Hello, is it permitted to transform an existing boost library into a C++11-only library? best, Oliver
On Thu, Jan 22, 2015 at 3:20 PM, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
Hello, is it permitted to transform an existing boost library into a C++11-only library? best, Oliver
Interesting question. I think there are two types: * a library that's completely standalone -no dependencies to anything boost- and requires C++11 * a library that's coupled to libs in boost, but one that doesn't compile with a pre C++11 compiler. The benefit of an aditional C++11 version of an existing lib would IMO be decoupeling from dependency of other libs -like the first type-. The second type is a rewrite where some dependencies to boost are replaces with C++11 dependencies for various reasons: perhaps less lines,or better performance,or better maintainability..
2015-01-22 15:36 GMT+01:00 Thijs van den Berg <thijs@sitmo.com>:
The benefit of an aditional C++11 version of an existing lib would IMO be decoupeling from dependency of other libs -like the first type-. The second type is a rewrite where some dependencies to boost are replaces with C++11 dependencies for various reasons: perhaps less lines,or better performance,or better maintainability..
In the case of boost.coroutine both applies (decoupling from dependency of other libs and better maintainability because of using C++11 features like lambdas etc.).
On 01/22/2015 09:47 AM, Oliver Kowalke wrote:
2015-01-22 15:36 GMT+01:00 Thijs van den Berg <thijs@sitmo.com>:
The benefit of an aditional C++11 version of an existing lib would IMO be decoupeling from dependency of other libs -like the first type-. The second type is a rewrite where some dependencies to boost are replaces with C++11 dependencies for various reasons: perhaps less lines,or better performance,or better maintainability..
In the case of boost.coroutine both applies (decoupling from dependency of other libs and better maintainability because of using C++11 features like lambdas etc.).
The one thing I would argue against would be the disappearance of the existing C++03-supporting Coroutine. I understand the quality-of-life improvements that C++11 brings for a library developer, but I would hope that the existing Coroutine wouldn't be removed from the Boost distribution. One of the past releases had issues with the immediate and mostly silent deprecation of the coroutine class interface from the previous version, so I thought I would note my request that something similar doesn't happen to today's Coroutine. Jason
On Thursday, January 22, 2015 10:20 PM, Oliver Kowalke wrote:
Hello, is it permitted to transform an existing boost library into a C++11-only library? best, Oliver
There has been some discussion on a C++11-only Boost, and Niall has BindLib-soon-to-be-called-something-else-lib, which may reify some of the specifics surrounding that. In my personal opinion, I would say go for it (I've upgraded to C++14 on multiple compilers and platforms); anybody that cannot upgrade to a C++11 compiler should either fight harder, do it anyway and then ask for forgiveness, or change jobs (in that order). However, some authors/maintainers of various libraries are stuck with older compilers for their customers and there's pretty much no way you can convince them to help in a C++11-only effort, or to help maintain a C++11-only branch. Also, if it ain't broke, don't fix it. Ultimately, if it's your library and you feel it impractical to support pre C++11 in your library, that's your choice, but you risk upsetting customers if you break existing code. So... onto the discussions of inline namespaces, suitable notice and backporting bugfixes. To pick a specific example (and not to pick on anybody or any library in particular, but just because it's in my mind), I would say it's easier and more convenient to move to say, Thread/v4 than it is to consistently supply myriad defines across multiple build systems. I would say go for a V(x+1) library and enjoy your coding life. Be responsible where bugfixes are appropriate, but don't let it prevent you from making progress*. *Really; please don't let it prevent you from making progress. Ben
Le 22/01/15 16:37, Ben Pope a écrit :
On Thursday, January 22, 2015 10:20 PM, Oliver Kowalke wrote:
Hello, is it permitted to transform an existing boost library into a C++11-only library? best, Oliver
There has been some discussion on a C++11-only Boost, and Niall has BindLib-soon-to-be-called-something-else-lib, which may reify some of the specifics surrounding that.
In my personal opinion, I would say go for it (I've upgraded to C++14 on multiple compilers and platforms); anybody that cannot upgrade to a C++11 compiler should either fight harder, do it anyway and then ask for forgiveness, or change jobs (in that order).
However, some authors/maintainers of various libraries are stuck with older compilers for their customers and there's pretty much no way you can convince them to help in a C++11-only effort, or to help maintain a C++11-only branch. Also, if it ain't broke, don't fix it.
Ultimately, if it's your library and you feel it impractical to support pre C++11 in your library, that's your choice, but you risk upsetting customers if you break existing code.
So... onto the discussions of inline namespaces, suitable notice and backporting bugfixes.
To pick a specific example (and not to pick on anybody or any library in particular, but just because it's in my mind), I would say it's easier and more convenient to move to say, Thread/v4 than it is to consistently supply myriad defines across multiple build systems. Completely agreed. I plan to create an independent version Boost.Thread V5 that supports only C++11 compilers. This version will live in a separated directory and namespace of course. This should be ready for C++Now 2014.
I would say go for a V(x+1) library and enjoy your coding life. Be responsible where bugfixes are appropriate, but don't let it prevent you from making progress*.
*Really; please don't let it prevent you from making progress.
Agreed again. Best, Vicente
El 22/01/2015 a las 16:37, Ben Pope escribió:
In my personal opinion, I would say go for it (I've upgraded to C++14 on multiple compilers and platforms); anybody that cannot upgrade to a C++11 compiler should either fight harder, do it anyway and then ask for forgiveness, or change jobs (in that order).
In many industrial environments you need to maintain C++98 code for many years. I'm not saying they should use Boost, but that's also real life. I plan to maintain C++03 for many years in my libraries. Best, Ion
On 22.01.2015 21:45, Ion Gaztañaga wrote:
El 22/01/2015 a las 16:37, Ben Pope escribió:
In my personal opinion, I would say go for it (I've upgraded to C++14 on multiple compilers and platforms); anybody that cannot upgrade to a C++11 compiler should either fight harder, do it anyway and then ask for forgiveness, or change jobs (in that order).
In many industrial environments you need to maintain C++98 code for many years. I'm not saying they should use Boost, but that's also real life. I plan to maintain C++03 for many years in my libraries.
My 2 cents... I work in one of such companies and old compilers are pain in the ass, but there's just no way to force SoC vendors to provider newer ones. It happens that we need to run our code on a platform with gcc 4.2, thus I don't expect anyone to take the decision to move to C++11 in the next 4-5 years or so. On the other hand we've been using Boost for a few years now and it has changed our lifes for better. The truth is we're hoping that Boost will maintain majority of its libraries in C++98/03 flavor as long as possible. If that does not happen we'd be forced to stick to one of older Boost releases forever. My suggestion would be to develop C++11 only libraries as a separate code to what has already been released to the community. I will have no problem with that as long as the already released code stays untouched and is reasonably maintained. Thanks for all your work. Best regards, Adam Romanek
Adam Romanek wrote:
On 22.01.2015 21:45, Ion Gaztañaga wrote:
El 22/01/2015 a las 16:37, Ben Pope escribió:
In my personal opinion, I would say go for it (I've upgraded to C++14 on multiple compilers and platforms); anybody that cannot upgrade to a C++11 compiler should either fight harder, do it anyway and then ask for forgiveness, or change jobs (in that order).
In many industrial environments you need to maintain C++98 code for many years. I'm not saying they should use Boost, but that's also real life. I plan to maintain C++03 for many years in my libraries.
My 2 cents...
I work in one of such companies and old compilers are pain in the ass, but there's just no way to force SoC vendors to provider newer ones. It happens that we need to run our code on a platform with gcc 4.2, thus I don't expect anyone to take the decision to move to C++11 in the next 4-5 years or so.
Maybe people in that position should come together and create a LTS branch. What do you think?
On Fri, Jan 23, 2015 at 8:37 AM, Adam Romanek <romanek.adam@gmail.com> wrote:
My suggestion would be to develop C++11 only libraries as a separate code to what has already been released to the community. I will have no problem with that as long as the already released code stays untouched and is reasonably maintained.
Is the current version of Boost not reasonably maintained enough? When you are back on gcc 4.2, you (as a group, not you specifically) have already said that known software bugs are not a serious enough issue to warrant an upgrade, and the current Boost is stable enough.
On 22 Jan 2015 at 15:20, Oliver Kowalke wrote:
Hello, is it permitted to transform an existing boost library into a C++11-only library?
If you meant here "transform an existing boost library into a C++11-only *Boost* library with C++ 11 only APIs" then I think you need to cycle the library name. Precedent here is that Signals went to Signals2, here I should think Coroutine ought to become Coroutine2. If you meant here "transform an existing boost library into a C++11 STL _capable_ *standalone* library" i.e. you do as Chris did in ASIO and I've done in AFIO via BindLib and provide a macro based framework for swapping out Boost STL for C++ 11 STL, then no I don't think the name needs to change as ASIO already did this some time ago, and I doubt anyone in Boost even noticed. The precedent here says this is okay so long as 03 Boost STL support still works. If finally you really meant here "I'd like a totally different internal implementation of Coroutine when C++ 11 mode is switched on, but still provide a legacy if orphaned but mostly API compatible C++ 03 implementation" then I'd personally say no name change needed. Precedent here is probably Boost.Thread where an increasing chunk of it uses different implementations depending on the C++ standard being used. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote
On 22 Jan 2015 at 15:20, Oliver Kowalke wrote:
Hello, is it permitted to transform an existing boost library into a C++11-only library?
If you meant here "transform an existing boost library into a C++11-only *Boost* library with C++ 11 only APIs" then I think you need to cycle the library name. Precedent here is that Signals went to Signals2, here I should think Coroutine ought to become Coroutine2.
agreed
If you meant here "transform an existing boost library into a C++11 STL _capable_ *standalone* library" i.e. you do as Chris did in ASIO and I've done in AFIO via BindLib and provide a macro based framework for swapping out Boost STL for C++ 11 STL, then no I don't think the name needs to change as ASIO already did this some time ago, and I doubt anyone in Boost even noticed. The precedent here says this is okay so long as 03 Boost STL support still works.
agreed
If finally you really meant here "I'd like a totally different internal implementation of Coroutine when C++ 11 mode is switched on, but still provide a legacy if orphaned but mostly API compatible C++ 03 implementation" then I'd personally say no name change needed. Precedent here is probably Boost.Thread where an increasing chunk of it uses different implementations depending on the C++ standard being used.
disagree here. I hate when some programmer tries to "outsmart" me by doing what he "knows" I need and does what he thinks I should want rather than what I say I want. It's very confusing to the user and a lot more work for the developer. This was done for spirit - they did a good job and it works, but its very confusing to me if I have to look into some sort of problem. Boost Build has the same issue in that if it fails, I just can't figure out what I have to change to make it work. It's too smart for my own good. google bjam coke machine. So in this case, I would prefer the creation of Library2 as in the first case above. Certainly this worked well with signals and other libraries should follow that model. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/transforming-ex-boost-lib-into-C-11-only-... Sent from the Boost - Dev mailing list archive at Nabble.com.
2015-01-22 19:05 GMT+01:00 Robert Ramey <ramey@rrsd.com>:
Niall Douglas wrote
On 22 Jan 2015 at 15:20, Oliver Kowalke wrote:
Hello, is it permitted to transform an existing boost library into a C++11-only library?
If you meant here "transform an existing boost library into a C++11-only *Boost* library with C++ 11 only APIs" then I think you need to cycle the library name. Precedent here is that Signals went to Signals2, here I should think Coroutine ought to become Coroutine2.
So in this case, I would prefer the creation of Library2 as in the first case above. Certainly this worked well with signals and other libraries should follow that model.
OK - thx for your suggestions. Who do I have to ask for an additional coroutine2 sub-module? Oliver
On 2015-01-24 17:13, Stephen Kelly wrote:
Pete bartlett wrote:
OK - thx for your suggestions. Who do I have to ask for an additional coroutine2 ? Coroutine11, perhaps?
In fact, make TWO new libraries: Coroutine11 and Coroutine14!
IF Coroutine benefits from C++14 over C++11, I would skip the C++11 version and go for the C++14 version directly. Just my 2ct.
Roland Bock wrote:
On 2015-01-24 17:13, Stephen Kelly wrote:
Pete bartlett wrote:
OK - thx for your suggestions. Who do I have to ask for an additional coroutine2 ? Coroutine11, perhaps?
In fact, make TWO new libraries: Coroutine11 and Coroutine14!
IF Coroutine benefits from C++14 over C++11, I would skip the C++11 version and go for the C++14 version directly.
FYI: I was kidding.
On 2015-01-24 18:38, Stephen Kelly wrote:
Roland Bock wrote:
On 2015-01-24 17:13, Stephen Kelly wrote:
Pete bartlett wrote:
OK - thx for your suggestions. Who do I have to ask for an additional coroutine2 ? Coroutine11, perhaps?
In fact, make TWO new libraries: Coroutine11 and Coroutine14!
IF Coroutine benefits from C++14 over C++11, I would skip the C++11 version and go for the C++14 version directly. FYI: I was kidding.
In hindsight it seems obvious :-)
Date: Sun, 25 Jan 2015 10:21:05 +0100 From: rbock@eudoxos.de To: boost@lists.boost.org Subject: Re: [boost] transforming ex. boost lib into C++11-only lib?
On 2015-01-24 18:38, Stephen Kelly wrote:
Roland Bock wrote:
On 2015-01-24 17:13, Stephen Kelly wrote:
Pete bartlett wrote:
OK - thx for your suggestions. Who do I have to ask for an additional coroutine2 ? Coroutine11, perhaps?
In fact, make TWO new libraries: Coroutine11 and Coroutine14!
IF Coroutine benefits from C++14 over C++11, I would skip the C++11 version and go for the C++14 version directly. FYI: I was kidding.
In hindsight it seems obvious :-)
I just noticed this thread and I find it weird that no one pointed to the requirements for being a Boost library: http://www.boost.org/development/requirements.html There are no requirements about which standard is required for use, only that the library be portable and follow the standard. I also did not noticed any requirements which restrict breaking API or ABI compatibility between versions of Boost (and in fact, various Boost libraries have done this in the past, in some cases due to wanting to be compatible with changes made during standardization). And, most importantly, every Boost maintainer is the Monarch with the library, the Kingdom. So, far be it for anyone to suggest that you can't break compatibility with older versions of the standard in your own library if you so desire. Everyone else gave answers that seemed to be about their feelings rather than actual Boost policy, though if my interpretation of documented policy is incorrect, I'd be interested in knowing.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Oliver Kowalke Sent: 22 January 2015 14:21 To: boost Subject: [boost] transforming ex. boost lib into C++11-only lib?
Hello, is it permitted to transform an existing boost library into a C++11-only library?
Yes, of course, but please do it very noisily ;-) And preferably with at least one release versions notice. So Flag up in the next Release Notes warning that "1.5? will be C++11 only". And consider if a version 2 would be better? (No necessarily it would appear in your case). Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
participants (15)
-
Adam Romanek -
Ahmed Charles -
Ben Pope -
David Stone -
Ion Gaztañaga -
Jason Roehm -
Niall Douglas -
Oliver Kowalke -
Paul A. Bristow -
Pete bartlett -
Robert Ramey -
Roland Bock -
Stephen Kelly -
Thijs van den Berg -
Vicente J. Botet Escriba