On Fri, Jun 14, 2013 at 07:04:36PM +0100, Jonathan Wakely wrote:

On 14 June 2013 18:53, Lars Viklund wrote:

...

On Fri, Jun 14, 2013 at 04:21:38PM +0000, Niall Douglas wrote:

...

The existing code base being prepared for entry into Boost is pure C++11, or at least as much C++11 as is provided by the Nov 2012 CTP experimental MSVC compiler and therefore easily supported by GCC 4.6 and clang 3.x.

I hope that you do realize that the Nov12 CTP does not come with a go-live license, nor is recommended for any human consumption.

It seems quite odd to me to spend significant GSoC resources on making a library that targets only two compilers,

You make it sound like C++11 is going to disappear or be a temporary fad. Other compilers will catch up at some point.

...

and assumedly a rather narrow set of OSes.

Is there any compiler that targets more OSes than GCC?

Even if GCC can target an OS, it's not always as suitable as the native compiler on the OS, with the native runtime. There are also several alternative C++03 compilers that serve special purposes. Should projects needing their other features (excellent auto-vectorisation, etc.) have to completely drop Boost due to an urge to constantly target the bleeding edge.

In fact are there any OSes supported by Boost that GCC *doesn't* target?

That depends on what you consider supported by Boost. A lot of the courtesy support for the native compilers for many OSes out there seems to be dying out.

...

Was this C++11-only requirement part of the original project plan, and why didn't anyone object to it then?

Expecting authors of new libraries to refrain from using features of the current C++ standard seems a bit ridiculous to me. Not everyone will be able to use C++11-only libraries, but why should those users hold everyone else back?

I used to see Boost as an empowering library, enhancing and evening out the playing field among the compilers out there. Some seem to see it as a playground to gain recognition and fast-track things into the coming standard libraries, instead of producing something usable in the real world. I guess it's losing the goal and aim I perceived, if it ever had it to begin with. To me, it feels like a betrayal from the library I have spent many manhours supporting. I've been on this rant before on the lists, in the big sprawling discussions about the feasibility of a Boost 2.0, but it seems nothing was learned then, and I don't expect anything to be learned going forward either. As for limiting Boost authors, for leaf libraries that end users can avoid, sure, there might not be too much harm. It's creeping into the very core libraries as well, which _does_ bother me, as it can render whole swaths of the library utterly unusable. In the end, we need a definitive statement from whatever cabal is controlling Boost, so we don't get these kinds of discussion resurrections every few months. All this causes is a lack of faith in the project. -- Lars Viklund | zao@acc.umu.se

On 14 June 2013 19:41, Andreas Schäfer wrote:

Hi,

On 20:20 Fri 14 Jun , Lars Viklund wrote:

...

Even if GCC can target an OS, it's not always as suitable as the native compiler on the OS, with the native runtime. There are also several alternative C++03 compilers that serve special purposes. Should projects needing their other features (excellent auto-vectorisation, etc.) have to completely drop Boost due to an urge to constantly target the bleeding edge.

I'd like to add some examples here: if you work on any IBM big iron (e.g. Blue Gene), then you're expected to use XL C++, on Cray it's crayCC and finally Fujitsu ship their own compiler for their vector CPU machines, too. Even if you use GCC, you might need to use an older version, e.g. folks working with CUDA are currently tied to GCC 4.6.

Sure. And how many of those folks are currently relying on Boost.AFIO and so are affected by it being C++11-only? Hint: the answer is less than one.

On 16 June 2013 19:27, Hartmut Kaiser wrote:

...

...

On 20:20 Fri 14 Jun , Lars Viklund wrote:

...

Even if GCC can target an OS, it's not always as suitable as the native compiler on the OS, with the native runtime. There are also several alternative C++03 compilers that serve special purposes. Should projects needing their other features (excellent auto-vectorisation, etc.) have to completely drop Boost due to an urge to constantly target the bleeding edge.

I'd like to add some examples here: if you work on any IBM big iron (e.g. Blue Gene), then you're expected to use XL C++, on Cray it's crayCC and finally Fujitsu ship their own compiler for their vector CPU machines, too. Even if you use GCC, you might need to use an older version, e.g. folks working with CUDA are currently tied to GCC 4.6.

Sure. And how many of those folks are currently relying on Boost.AFIO and so are affected by it being C++11-only?

Hint: the answer is less than one.

Sorry, but I was under the impression, that Boost.AFIO is intended to be reviewed and added to Boost proper. Well, there is still the review, but if it ends up in Boost there probably will be many interesting use cases left out in the dark for other Boost authors if it's C++11 only. From my distant vantage point wrt this thread it seems that you're a bit too short sighted...

I think I'm being long-sighted, looking towards a time when C++11 is more widely available :-) My point is that those users of xlC and crayCC etc. who use Boost today would still be able to if Boost.AFIO is included, and since they are coping without AFIO today they could still, if needed, cope without it in the future when it is part of Boost. I was objecting to this idea that a new library being C++11-only prevents anyone using the rest of Boost. It doesn't.

(Do take some of the original reply with a bit of salt. It's something I feel very strongly about, so some superlative and emotion will have crept into my posting) On Fri, Jun 14, 2013 at 02:00:29PM -0500, Nevin Liber wrote:

On 14 June 2013 13:20, Lars Viklund wrote:

...

I guess it's losing the goal and aim I perceived, if it ever had it to begin with. To me, it feels like a betrayal from the library I have spent many manhours supporting.

Again, no one is stopping you from supporting C++03.

Support as in the end-user support and troubleshooting I provided for years and years on IRC out of belief that a strong community and responsive aid would help Boost. Not all contribute through libraries, and thus, cannot affect the path of the library in any way but discussion in the hope of aligning intents. I see a significant issue in that no-one with the power to do so has the guts to make a solid decision, instead letting the library waffle along without any overarching guidance in a situation that in my not so humble opinion needs some proper action. Deferring it to the benevolence of library authors might feel democratic and all, but it puts a big burden on them to each make decisions that in conjunction may not turn out well.

...

As for limiting Boost authors, for leaf libraries that end users can avoid, sure, there might not be too much harm. It's creeping into the very core libraries as well, which _does_ bother me, as it can render whole swaths of the library utterly unusable.

Again, what are the concrete examples of this? What previously useable libraries are now "utterly unusable" because of C++11 support?

You misread me. The last statement is speculative, about what I believe is going to happen if we continue on this path of slowly going from C++03 compatibility with a sprinkling of functionality that makes the library equivalent but faster for people who happen to build on a C++11 compiler. Pretty much anything that fakes variadics is under the constant pressure to disregard compatibility and "just use variadic templates already". Thankfully the authors of those libraries haven't folded. Boost libraries are encouraged to use other Boost libraries to avoid duplicating functionality, so once one library folds, the rest are affected. As a closing statement: I'm not advocating staying on C++03 forever, that would be delusional. I am, however, imploring that we need to sort out a common vision going forward, with the support of the active maintainers, the Steering Committee and the developer community. I don't see any bright future in letting the transition just happen without a common plan, breaking the world as it goes. -- Lars Viklund | zao@acc.umu.se

That depends on what you consider supported by Boost. A lot of the courtesy support for the native compilers for many OSes out there seems to be dying out.

That may well be due to lack of testing resources - Boost authors can only suppport obscure compilers if we have someone running tests for them and/or someone willing to supply patches. For example I notice we don't have any Intel test runnners at present which is a real shame...

...

...

Was this C++11-only requirement part of the original project plan, and why didn't anyone object to it then?

Expecting authors of new libraries to refrain from using features of the current C++ standard seems a bit ridiculous to me. Not everyone will be able to use C++11-only libraries, but why should those users hold everyone else back?

I used to see Boost as an empowering library, enhancing and evening out the playing field among the compilers out there.

Some seem to see it as a playground to gain recognition and fast-track things into the coming standard libraries, instead of producing something usable in the real world.

Ouch. Boost has always been about championing the "next thing" and always been ahead of the compiler curve, if that wasn't the case we'd still be targetting VC6. Yesterdays bleading edge is tomorrows mainstream.

I guess it's losing the goal and aim I perceived, if it ever had it to begin with. To me, it feels like a betrayal from the library I have spent many manhours supporting.

I've been on this rant before on the lists, in the big sprawling discussions about the feasibility of a Boost 2.0, but it seems nothing was learned then, and I don't expect anything to be learned going forward either.

As for limiting Boost authors, for leaf libraries that end users can avoid, sure, there might not be too much harm. It's creeping into the very core libraries as well, which _does_ bother me, as it can render whole swaths of the library utterly unusable.

For example?

In the end, we need a definitive statement from whatever cabal is controlling Boost, so we don't get these kinds of discussion resurrections every few months. All this causes is a lack of faith in the project.

Cabal? Well that would be you then - you have as much say over Boost's future direction as anyone else. I hadn't noticed this discussion cropping up every few months either, but then again I tend to file a lot of stuff in the "lifes too short" folder ;-) John.

...

Ouch. Boost has always been about championing the "next thing" and always been ahead of the compiler curve, if that wasn't the case we'd still be targetting VC6. Yesterdays bleading edge is tomorrows mainstream.

Maybe it is better to ask, what the policy for phasing out support for older compilers and standards is?

I'm not sure we have ever had a policy - except try and listen to demand and then let library authors decide. One part of that is "do we have folks willing to test old compiler X"? As long as the answer to that is yes for X, then there will likely be some support. I notice that currently there's no shortage of C++03 testers. John.

On 6/15/2013 9:35 AM, Jason Roehm wrote:

...

That may well be due to lack of testing resources - Boost authors can only suppport obscure compilers if we have someone running tests for them and/or someone willing to supply patches. For example I notice we don't have any Intel test runnners at present which is a real shame...

What is the process for becoming a test runner? I may be able to provide some testing for Intel.

http://www.boost.org/development/running_regression_tests.html

On 17 June 2013 23:28, Asbjørn wrote:

So, as a Boost user, what I'd like to see is a clear status for each project, concerning

- Compiler support - Maintenance - Inter-depdendencies

[snipped descriptions] I agree that such information would be useful, but the problem is maintaining it. The build information in the library list was often wrong, which IMO is worse than having no information at all. If I can shift the maintenance onto the developers (i.e. putting the meta-data in the module) then perhaps adding more data will be feasible. Also, hopefully, some of that information might fall out of later work on modularization. There is a big dependency graph somewhere, so maybe that information could be automatically generated (although I imagine it would often contain several false dependencies). That said, I recently added a 'status' field to the library list to mark the signals library as deprecated. It's just plain text, so if everyone agrees then was add a 'status' (such as unmaintained). Would need to start a new thread to get feedback, and preferably get confirmation from the maintainer. You can see the status on the signals library in: http://www.boost.org/doc/libs/1_54_0_beta1/