transforming ex. boost lib into C++11-only lib?

newer
Enhanced Vector and Deque...

older
[endian] Testing floating point...

Oliver Kowalke

22 Jan 2015 22 Jan '15

2:20 p.m.

Hello, is it permitted to transform an existing boost library into a C++11-only library? best, Oliver

Show replies by date

Thijs van den Berg

22 Jan 22 Jan

2:36 p.m.

On Thu, Jan 22, 2015 at 3:20 PM, Oliver Kowalke 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..

Oliver Kowalke

2:47 p.m.

2015-01-22 15:36 GMT+01:00 Thijs van den Berg :

...

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.).

Jason Roehm

3:41 p.m.

On 01/22/2015 09:47 AM, Oliver Kowalke wrote:

...

2015-01-22 15:36 GMT+01:00 Thijs van den Berg :

...
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

Ben Pope

3:37 p.m.

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

Vicente J. Botet Escriba

6:35 p.m.

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

Ion Gaztañaga

8:45 p.m.

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

Adam Romanek

23 Jan 23 Jan

7:37 a.m.

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

Stephen Kelly

24 Jan 24 Jan

4:16 p.m.

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?

David Stone

5:31 p.m.

On Fri, Jan 23, 2015 at 8:37 AM, Adam Romanek 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.

Niall Douglas

22 Jan 22 Jan

4:05 p.m.

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/

Robert Ramey

6:05 p.m.

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.

Oliver Kowalke

6:17 p.m.

2015-01-22 19:05 GMT+01:00 Robert Ramey :

...

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

Pete bartlett

23 Jan 23 Jan

5:17 p.m.

...

OK - thx for your suggestions. Who do I have to ask for an additional coroutine2 ?

Coroutine11, perhaps?

Stephen Kelly

24 Jan 24 Jan

4:13 p.m.

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!

Roland Bock

4:55 p.m.

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.

Stephen Kelly

5:38 p.m.

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.

Roland Bock

25 Jan 25 Jan

9:21 a.m.

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 :-)

Ahmed Charles

23 Mar 23 Mar

12:38 p.m.

...

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.

Paul A. Bristow

22 Jan 22 Jan

4:34 p.m.

...

-----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

3536

Age (days ago)

3596

Last active (days ago)

List overview

Download

19 comments

15 participants

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