Unfortunately, I don't think I have the time right now. On 06/05/2014 4:50 PM, Renato Forti wrote:

Hi Sohail,

Thanks I will check your lib! You have interest in be review manage?

Thanks again!

2014-05-05 16:58 GMT-03:00 Sohail Somani :

...

On 03/05/2014 9:34 AM, Renato Forti wrote:

...

Hi All,

The proposed ‘Boost.Application’, needs a Review Manager. Anyone is interested?

The Docs:

http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html

It's certainly a well-documented library but also contains a lot of different concepts!

Anyway, I don't know about being a review manager but I can make a suggestion:

The application::context type functions as a service locator (i.e., the Big Fat Service Locator Pattern). This is generally considered an anti-pattern because it is difficult to see dependencies for a piece of code without reading the code itself and even then, you can miss it.

What I would suggest the author (is that you?) look into is a way to automate the provision of all the data the application needs, perhaps in the application's constructor or in the function call operator(). The technique is generally known as dependency injection and is usually coupled with an inversion of control container. Something that is quite encouraging is in reading the code for the proposed library, you seem to have most of the pieces anyway.

I have written my own library for this purpose[1] but it is fairly unsuitable for consumption by anyone but me. Feel free to steal ideas if you think they are useful to you.

Sohail

[1] https://bitbucket.org/cheez/dicpp/wiki/Home

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi,

...

I think also you might consider acting a review manager for another library before asking anyone to act as review manager for yours.

I am a not very active user! But I would like to help community. We have a lot of good libs on schedule for long time that I would like to see in boost. What is needed to become a Review Manager? Other suggestion, I think that proposed libs should be in a place like more prominently on the ‘boost’ site (as a direct link)! Something like: libraries proposals awaiting review. So users can have direct access to these libraries, test them and give feedback to the authors. I think that : Community -> Review -> Schedule ( http://www.boost.org/community/review_schedule.html) don’t promote discussion about the proposed libs. Well this is only a suggestion! Thanks Renato 2014-05-07 6:22 GMT-03:00 Niall Douglas :

On 5 May 2014 at 15:58, Sohail Somani wrote:

...

...

The proposed `Boost.Application´, needs a Review Manager. Anyone is interested?

I think also you might consider acting a review manager for another library before asking anyone to act as review manager for yours. We'll never process the queue if everyone wants but no one wants to give.

Getting your library reviewed is more about crossing off any possible reasons why it shouldn't be reviewed rather than making a case for that it should be reviewed.

Niall

-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Thu, May 8, 2014 at 8:56 AM, Niall Douglas wrote:

I think Boost needs forking into a C++ 14 only edition and a C++ 03 compatible edition, with the C++ 14 only edition exclusively based on the C++ 14 STL where possible (and not Boost). I also think we need a three stage peer review process instead of the present single stage. I also think we need much tougher requirements for entry into Boost.

I'd be worried that this would inhibit improvements to C++14 components that have a Boost equivalent. Consider if this approach was taken with C++11, and we had a Boost version that used C++11 components, like std::shared_ptr, where possible. Two of the improvements we have for fundamentals TS1 and TS2 are based on features that we added to boost::shared_ptr, boost::make_shared, boost::allocate_shared (Peter's change to std::shared_ptr - http://isocpp.org/files/papers/N3920.html - and my forms of std::make_shared and std::allocate_shared - http://isocpp.org/files/papers/N3939.html). Then there is the matter of broken vendor implementations. VC10, VC11, VC12 all have broken (or suboptimal) implementations of many C++ standard library functions. Not everyone upgrades to the latest versions of those compilers, either. I worked at Microsoft until February 2014, and even as late as 2014, there were teams in certain parts (OSD, ASG) that were using VC10 and VC11 (and one that still cared about Boost 1.41). It makes sense to have Boost equivalents that are non-broken, better implemented, etc. Glen

On 8 May 2014 at 9:44, Glen Fernandes wrote:

...

I think Boost needs forking into a C++ 14 only edition and a C++ 03 compatible edition, with the C++ 14 only edition exclusively based on the C++ 14 STL where possible (and not Boost). I also think we need a three stage peer review process instead of the present single stage. I also think we need much tougher requirements for entry into Boost.

I'd be worried that this would inhibit improvements to C++14 components that have a Boost equivalent. Consider if this approach was taken with C++11, and we had a Boost version that used C++11 components, like std::shared_ptr, where possible. Two of the improvements we have for fundamentals TS1 and TS2 are based on features that we added to boost::shared_ptr, boost::make_shared, boost::allocate_shared (Peter's change to std::shared_ptr - http://isocpp.org/files/papers/N3920.html - and my forms of std::make_shared and std::allocate_shared - http://isocpp.org/files/papers/N3939.html).

I would imagine a C++14 only Boost would reimplement parts of the C++ 14 STL which need it badly enough, especially if to be proposed as a replacement. For example, std::valarray<T> was totally replaced with an alternative. There are many other examples.

Then there is the matter of broken vendor implementations. VC10, VC11, VC12 all have broken (or suboptimal) implementations of many C++ standard library functions.

As does libstdc++. I'm thinking especially of std::regex which only was finished very recently.

Not everyone upgrades to the latest versions of those compilers, either.

C++ 14 only Boost would be like Boost of the 1990s, highly demanding on compilers and only guaranteed to work on the latest major revision. The idea would be to regenerate that excitement of the bleeding edge, get people enthusiastic with the possibilities again.

I worked at Microsoft until February 2014, and even as late as 2014, there were teams in certain parts (OSD, ASG) that were using VC10 and VC11 (and one that still cared about Boost 1.41). It makes sense to have Boost equivalents that are non-broken, better implemented, etc.

And for which the compatibility Boost would remain: a very high quality emulation of the C++ 11/14 STL in C++ 03, something which is very valuable to a lot of rich corporations. Me personally, I'd delay open source release by 12 months unless clients pony up a (small) subscription to fund contractors to work on bug fixes and maintenance, as getting people to do that for free is becoming increasingly hard. An alternative is a formal bounty system, with bounty credits earned per unit of monthly subscription. My concern is that we are putting off the C++ 14 fork of Boost until "the time is right". If you look at monthly commits, active contributors, mailing list posts esp. to boost-users, all have dropped dramatically since 2011 and are trending downwards. On some measures Boost is approaching one third of the activity it used to be. It is quite frankly scary. I can supply graphs if you'd like? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Hi Rodrigo,

...

I candidate myself as a review manager for the yet-to-be Boost Application library.

Thanks for your interest on lib and in your time as possible RM. As Rob says, you need be approved by the Review Wizards. I don't know the process to achieve this! Anyone can help us? Again thanks a lot, Renato 2014-05-13 11:56 GMT-03:00 Rodrigo Madera :

(Resending after the mailing list blackout)

Renato et al,

I have written a similar library in the past, for my own needs. So I became interested in this library.

Being the boost user and lover I am for about a decade (plus the dark ages before them), I candidate myself as a review manager for the yet-to-be Boost Application library. I'm a C++ specialist with 15 years experience and, summing them up with the masters and semigods on this list, could help get this item off the queue.

If there is interest, just let me know.

Yours, Rodrigo Madera

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 5/8/2014 11:56 AM, Niall Douglas wrote:

On 8 May 2014 at 8:48, Renato Forti wrote:

...

...

...

I think also you might consider acting a review manager for another library before asking anyone to act as review manager for yours.

I am a not very active user! But I would like to help community. We have a lot of good libs on schedule for long time that I would like to see in boost. What is needed to become a Review Manager?

About 40 hours of time. A good 25-30 hours will go on working with the library author to fix up problems you find before review begins. Another 10-15 hours might go on administrating the review, and writing up the report on people's consensus afterwards.

If the review fails, and it usually does the first time, you'll need to repeat that again for a second review. Usually less hours of work though, maybe another 20 hours.

The whole process takes weeks of effort, months if a second round is needed. This is why there are so few willing review managers.

...

Other suggestion, I think that proposed libs should be in a place like more prominently on the `boost´ site (as a direct link)! Something like: libraries proposals awaiting review.

I think Boost needs forking into a C++ 14 only edition and a C++ 03 compatible edition, with the C++ 14 only edition exclusively based on the C++ 14 STL where possible (and not Boost). I also think we need a three stage peer review process instead of the present single stage. I also think we need much tougher requirements for entry into Boost.

But we all have our opinions. It's up to the steering committee to decide. For sure, Boost has been slowly dying since 2011 now. I'll be talking on that exact subject at C++ Now on Saturday week, which I assume will be as popular as a funeral.

I do not understand why you think Boost has been slowly dying since 2011, but you are entitled to your opinion. My own experience is that with over 125 different libraries Boost has remained vital and grown more vital to a great number of C++ programmers.

On 2014-05-08 19:59, Sohail Somani wrote:

...

For sure, Boost has been slowly dying since 2011 now. I'll be talking on that exact subject at C++ Now on Saturday week, which I assume will be as popular as a funeral. Can you say that? I think that the main Boosters were busy moving to Git. That took a long time and from my perspective, they did a good job given what they were aiming for. I disagree with the whole modular Boost

On 08/05/2014 11:56 AM, Niall Douglas wrote: thing, but it will probably take a couple of years and some releases before we can say that it was worth it. Has there even been a git-only release yet? I don't think so.

Too bad I won't be there to attend this funeral! Would have liked to hear your points.

Sohail

For my own part, I'd be very sad to see Boost die. It has been an invaluable resource of quality code for me thus far and I hope that it'll continue to grow. Clearly there are still people interested in submitting libraries, there are still release/review managers etc, just that the move to GIT seems to have slowed things down a tad. But I'd hope that we are merely seeing a temporary drop in the release schedule rather than the end of the whole project. Kind regards, Philip Bennefall

On 05/08/2014 02:32 PM, Niall Douglas wrote:

On 8 May 2014 at 13:59, Sohail Somani wrote:

...

...

For sure, Boost has been slowly dying since 2011 now. I'll be talking on that exact subject at C++ Now on Saturday week, which I assume will be as popular as a funeral. Can you say that? I think that the main Boosters were busy moving to Git. That took a long time and from my perspective, they did a good job given what they were aiming for. There are also wider trends at work. For example, all open source has seen a drop of about 25% in terms of regular contributors or projects regularly active during this past year 2013-2014. I would assume that is macroeconomic in nature.

[...] While these are all interesting points to consider, I think it would be useful to focus on the boost "micro economy" a bit. I do believe that boost has a scalability issue (or actually, issues!). The modularization effort was (at least in part) meant to deal with that, and the speed of change provides amply evidence of that problem. However, the problem is not only about maintainability. It's also about governance, and about what it takes for a community to feel like one. A few years ago I had suggested to consider moving to a slightly different organizational model, like the Apache Software Foundation (http://www.apache.org/foundation/), to allow projects to be more autonomous. The sheer size of Boost is simply too overwhelming for me to appreciate as a single big entity (both as a user as well as as a contributor), even though I'm still very much interested into individual components / projects, and would like to keep contributing to them.

Some 40 slides and a 20,000 word position white paper should be published as part of the conference proceedings.

I'm very much looking forward to reading that. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...

Sohail Somani wrote:

If this is the case, then the main change I would suggest is that Boost needs to be easier to work with. Currently, the modular thing works kinda OK but it's a giant PITA to fork.

It is a giant PITA, partly because it is not modular. The git migration was a migration to 100 fractured git repos, not modularized git repos. If you want to modularize, then decide that that is a goal for Boost and I will help. http://thread.gmane.org/gmane.comp.lib.boost.devel/245078 I think at least one of the reasons my efforts did not get support from the right people is that modularization is not currently a goal for Boost. Some people in Boost think that modularization is already done. It is not. Thanks, Steve.

Niall Douglas wrote:

On 9 May 2014 at 12:45, Stephen Kelly wrote:

...

...

If this is the case, then the main change I would suggest is that Boost needs to be easier to work with. Currently, the modular thing works kinda OK but it's a giant PITA to fork.

It is a giant PITA, partly because it is not modular. The git migration was a migration to 100 fractured git repos, not modularized git repos.

If you want to modularize, then decide that that is a goal for Boost and I will help.

http://thread.gmane.org/gmane.comp.lib.boost.devel/245078

I think at least one of the reasons my efforts did not get support from the right people is that modularization is not currently a goal for Boost. Some people in Boost think that modularization is already done. It is not.

One of the KEY absolute must have feature of a C++ 14 only Boost refresh would be per-library source distros.

You might be talking about duplication. I'm not sure.

In other words, there is a separate source distro for each Boost14 library which contains just enough of Boost for that library. One can, of course, copy multiple source distros into the same directory tree to combine libraries.

That will forever break the perception that to use one library you need all of Boost. It also brings in proper dependency tracking from the beginning.

Boost14 would also be the right time to start modular and stay modular from the beginning.

This sounds like another 'big bang' (expect explosions). However...

I'd forget about modularising compatibility Boost, it is what it is.

Given that no one else responded on this point, it seems conclusive: Boost doesn't want to make any steps (which I previously showed to be possible) toward a goal of modularizing the code before the big bang described above. Thanks, Steve.

Rob Stewart wrote:

A more reasonable conclusion is that Boost wants to get its head above water, following the Git transition, before taking on more disruptive changes. Nevertheless, it would be easier to accept such a change add part of a new and separate branch.

That's indeed reasonable thing to do, but it's not what Niall suggested (which is what I was responding to). Thanks, Steve.

Hi, Sohail Somani wrote:

Moving to git was a smart decision but my personal experience has shown that the current configuration does not encourage forking in a way that makes it easy to contribute.

Would anyone know what the rate of incoming patches from outside developers has been since the change? That would be an easy way to tell if it's just me being lazy (probably is).

I don't understand all of those negative voices. Especially I don't understand how contributing can be considered difficult or harder than before. I'm a contributor at Boost.Geometry and you can believe me or not but getting involved in the Boost library development was never easier than it is now. In Geometry we already have > 30 pull requests closed. On GitHub you can fork one library with one button click, make a change and create a pull request (with 2 button clicks and writing a message). Reviewing the code is extremely simple, you can discuss about the code or make comments about single lines. And working with GIT is a real pleasure WRT the SVN. But you even don't need to know how to use GIT since the changes can be made directly on GitHub or you can use their app on Windows to handle local repos. We have really great tools at hand so we should use them. Regards, Adam

Hi, Sohail Somani wrote:

On 16/05/2014 7:21 PM, Adam Wulkiewicz wrote:

...

Hi,

Sohail Somani wrote:

...

Moving to git was a smart decision but my personal experience has shown that the current configuration does not encourage forking in a way that makes it easy to contribute.

Would anyone know what the rate of incoming patches from outside developers has been since the change? That would be an easy way to tell if it's just me being lazy (probably is).

I don't understand all of those negative voices. Especially I don't understand how contributing can be considered difficult or harder than before.

I'm a contributor at Boost.Geometry and you can believe me or not but getting involved in the Boost library development was never easier than it is now. In Geometry we already have > 30 pull requests closed. On GitHub you can fork one library with one button click, make a change and create a pull request (with 2 button clicks and writing a message). Reviewing the code is extremely simple, you can discuss about the code or make comments about single lines. And working with GIT is a real pleasure WRT the SVN. But you even don't need to know how to use GIT since the changes can be made directly on GitHub or you can use their app on Windows to handle local repos. We have really great tools at hand so we should use them.

Obviously Git is better to use than SVN for Boost, there is no argument there.

Your 30+ pull requests look like they're mostly from the same guy. That's fine, but not a good enough example of how much easier it has become to contribute.

It's the frequency of contributions that matters. The contribution of a simple patch takes 5 minutes, assuming that there is someone who can review and merge it.

Time will tell. It's interesting that you're suggesting a Github-based workflow that wouldn't even require a local repo. That could be worth a shot next time. How would I maintain my own personal fork for my projects until the pull request was accepted?

You have many options. When you create a fork of some library a clone of the library's repo is created for your profile. You can further clone it to create a local copy and commit changes from you local copy, etc. You could also modify it directly on GitHub but probably only if the changes didn't require running tests. Now here comes the interesting part. When you're done with the changes you can request a pull. Until it's merged you can commit additional changes and all of your commits becomes the part of the same pull request. This way people can review your work, you can make fixes and repeat until your work is accepted. If you work on a several things in the same time you can make branches in your fork, one per each new feature. When you're done request pulls to merge your branches with the original library's develop branch and review/fix until they're accepted and merged. In the meantime you can create more branches or forks of other libraries or comment on other people pull requests. Regards, Adam

On 09/05/2014 7:01 AM, Stephen Kelly wrote:

Sohail Somani writes:

...

If this is the case, then the main change I would suggest is that Boost needs to be easier to work with. Currently, the modular thing works kinda OK but it's a giant PITA to fork.

It is a giant PITA, partly because it is not modular. The git migration was a migration to 100 fractured git repos, not modularized git repos.

If you want to modularize, then decide that that is a goal for Boost and I will help.

http://thread.gmane.org/gmane.comp.lib.boost.devel/245078

I think at least one of the reasons my efforts did not get support from the right people is that modularization is not currently a goal for Boost. Some people in Boost think that modularization is already done. It is not.

A C++14-only fork of Boost could do it. Imagine no more PP for MPL or any of the other libraries! Sohail

...

partly because it is not modular. The git migration was

a migration to 100 fractured git repos, not modularized git repos.

If you want to modularize, then decide that that is a goal for Boost and I will help.

http://thread.gmane.org/gmane.comp.lib.boost.devel/245078

I am not entirely sure that perfect dependency structure would change anything. If you have 123 repos, it's gonna be painful no matter what.

I think the idea is that you then only clone the repository you work on. Thus if you contribute to 5 libraries, only 5 repositories are checked out. Each libraries would be independant in terms of building/testing... and it'd still be possible for scripts/tools to clone all 123 repositories and run tests on all of them. But that'd require quite a change in terms of how people are used to work with boost at the moment. Philippe

Stephen Kelly wrote:

...

http://thread.gmane.org/gmane.comp.lib.boost.devel/245078

This is a good plan in principle, and parts of it are already done. boost/detail/workaround.hpp is already into Config; so is boost/limits.hpp. There's only so much to be gained by moving files around from one existing module to another though. We need to decide what to do with Utility.

Stephen Kelly wrote:

There is clearly not agreement within Boost that anything should be done at all regarding modularization, before a more 'big bang' break forward, from a reading of the mail from Niall.

We don't need a Boost-wide agreement to proceed. To move a file from module A to module B, we only need agreement from A and B's maintainers and lack of objections from the Boost community. This is easier to achieve that Boost-wide agreement, although in some cases B's maintainer may not be thrilled to accept responsibility for something he didn't write or design but will need to maintain. The problem with Utility is that it doesn't have a maintainer.

Niall, I agree with your analysis, and to some degree with your conclusions / proposal. See below. On 05/16/2014 01:10 PM, Niall Douglas wrote:

On 16 May 2014 at 17:46, Stephen Kelly wrote:

...

There is clearly not agreement within Boost that anything should be done at all regarding modularization, before a more 'big bang' break forward, from a reading of the mail from Niall. For the purposes of clarity, I am not a member of Boost. I do not sit on any committees, and have no representation nor standing with the community apart from doing some admin for GSoC. I would say that my opinions on this are so extreme that no one agrees with me, and I expect my presentation at C++ Now tomorrow to not be popular.

I have however been doing a lot of canvassing whilst here at C++ Now. The main problems with Boost which are causing its decline are these:

1. Boost isn't sexy any more. As one very highly respected world famous engineer put it - and I won't say who, and I apologise to him for stealing his words without attribution:

"Boost used to be about all the stuff you really wanted in the standard. Now Boost looks like all the stuff that wasn't good enough to get into the standard"

2. Everyone recognises there are serious problems with process, everything from how you were treated Stephen when you tried cleaning out cruft and only really Dave supported you, right through to the fact that peer review simply doesn't work any more. The Boost community has become quite selfish in recent years, as you would expect from those with a vested interest in the status quo before evolution. And for the record, I have no problem with those vested interests keeping their existing Boost, but I personally want as far away from C++ 03 as soon as is possible.

3. All the interesting new C++ 11 libraries you find around the internet have zero interest in trying to join Boost, with a very few honorable exceptions. That speaks volumes, to me at least.

Which suggests to me a need for a new Boost which attempts to apply the benefits of hindsight to what we learned with Boost v1. Now, it is extremely clear from this conference there is little appetite for that, but I think later on this year we're going to have three C++11 libraries in the queue, and if things have not very significantly progressed in any of the three items above, I think that time will be right time to fork. And here is what I think should be in a fork of Boost:

1. Minimum required compiler feature set will be VS2014's. No use of Boost STL permitted where the C++ 11 STL provides a feature.

2. cmake instead of Boost.Build.

3. Eliminate peer review in favour of a suite of automated libclang based AST analysers. Instead of persuading people to review libraries, persuade them to review and improve the AST analysers.

4. Mandatory cross platform per-commit CI with unit testing exceeding 95% coverage. We don't care what unit test library is used so long as it can output results Jenkins can understand.

5. Mandatory all green thread, memory, UB sanitisers and clean valgrind. All also tested per-commit.

6. Mandatory CI testing for exception safety. I am hoping a clang rewriter can basically patch all exception throws and have them randomly throw for testing.

7. Per-library source distributions instead of a monolithic blob. This implies some dependency management, but cmake makes that much easier. It also means we can eliminate the release cycle because each library does its own release cycle, and the correct (i.e. tested) version of dependencies are included into each per-library source distro. This solves the version lock problem currently plaguing git-ised Boost, at the cost of pushing the version lock problem onto users [1]. BTW I want to see a soak test of the unit tests for 24 hours be all green before a release.

8. Reusable utilities in a submitted library need merging into some common utilities library which follows the STL conventions. Other than that, no source code, naming conventions, namespace or anything else needs converting or changing. We are looking for very high quality C++ libraries, nothing more. Obviously if someone hopes for a library to enter the C++ 17 STL they'll need much more rigour, but that's up to them.

9. There is no longer an "in" or an "out" for distribution. I'm thinking of a scorecard page where member libraries are ranked by how high quality they are according to all the automated review, so when I say "mandatory" above, I simply mean they don't get to appear on the main downloads page without that precondition. All submitted libraries do appear though, just ranked very low if their quality is low. I would hope all this is generated from a database and requires very little human input.

10. BoostBook documentation using the Boost look and feel becomes mandatory. I've had enough with library authors thinking they can improve on BoostBook's output with things like using Comic Sans as the font or weird colour schemes throughout.

So, basically, in some areas requirements are significantly tightened. In other areas requirements are significantly loosened. The aims of the above ten items are as follows:

1. To reduce the amount of human work involved in maintaining Boost. What Dave and Daniel had to do for the git conversion last year was far above what anyone should ever feel they need to do.

2. To decentralise Boost, letting it scale up far better.

3. To provide a gradual process of entering Boost which authors can tip away at slowly with automated scripts slowly improving their rankings instead of the current "lumps" of high intensity output and the review approved/failed scheme currently used.

4. To incentivise authors to maintain their libraries as the quality bar is improved - the automated scripts will start to drop library rankings as the quality is raised, thus dropping that library in the overall rankings. Rather more importantly, it provides a natural "deprecation" mechanism, something sorely lacking in my opinion from present Boost.

Thoughts?

My main point of contention is your emphasis on a mandatory set of rules / policies. I think the level of modularization needs to be pushed much further than to exclusively focus on source code layout (and revision control). The problem isn't really technical, but social: For example, we engineers love to spend countless hours on tools and infrastructure, and as a result each suggestion to improve anything in that area draws a huge amount of attention and energy. Why not let each library have their own choice of build tool, documentation format, etc. ? All dependencies need to be explicitly spelled out, not at the file level, but the package level, so building library X shouldn't need to be concerned at all about how its prerequisite library Y was produced (, documented, etc.). It's of course fine to propose certain tools if they are proven to work well. But trying to come up with a unified development environment (a la RYPPL) just seems an invitation for another stall. In such a world "Boost" merely becomes an umbrella organization with some administrative, legal, etc. assistance. Criteria for acceptance shouldn't be based on what development environment developers choose, so long as certain criteria (license, code quality, etc.) are met and the project's goal / focus fit into Boost. Needless to say, each library would have its own release cycle, and dependencies to other boost libraries should take versions into account, to provide maximum independence and help packagers. No need for a central review or release management. Stefan

[1]: If this model proves popular as we can get a regular donation stream going, we could deploy an automated SHA stamper which through unit test iteration, figures out which SHAs in which combinations of libraries are compatible. Then you could safely mix library A's distro with library B's distro. I'd imagine Debian upstream et al might be coaxed into providing for this as they need one unified set of compatible libraries.

Niall

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- ...ich hab' noch einen Koffer in Berlin...

I am working on a C++ library for small microcontrollers (the thingies that typically have a few kilobytes of RAM). I might one day want to submit my work to boost. I'll respond from that perspective.

1. Boost isn't sexy any more. As one very highly respected world famous engineer put it - and I won't say who, and I apologise to him for stealing his words without attribution:

"Boost used to be about all the stuff you really wanted in the standard. Now Boost looks like all the stuff that wasn't good enough to get into the standard"

I think there is room for a collection of high-quality libraries that are too specialized or too experimental to be in the standard.

2. I personally want as far away from C++ 03 as soon as is possible.

Agreed. I write my code now, for the currently available compiler(s). For me that is the latest GCC, or maybe clang, or a vendor specific compiler (AFAIK VS isn't a cross-compiler for bare-metal targets, so it is not relevant, at least not for the target-dependent parts).

3. All the interesting new C++ 11 libraries you find around the internet have zero interest in trying to join Boost, with a very few honorable exceptions. That speaks volumes, to me at least.

I would be interesested, especially because of the review process.

1. Minimum required compiler feature set will be VS2014's. No use of Boost STL permitted where the C++ 11 STL provides a feature.

I totally agree

2. cmake instead of Boost.Build.

My libraries are headers-only, so I don't think this would matter much to me.

3. Eliminate peer review in favour of a suite of automated libclang based AST analysers. Instead of persuading people to review libraries, persuade them to review and improve the AST analysers.

Testing is of course fine, but it can not evaluate architecture or documentation.

4. Mandatory cross platform per-commit CI with unit testing exceeding 95% coverage. We don't care what unit test library is used so long as it can output results Jenkins can understand.

Agreed in general, but how would you realize that for code that is specific to a particular microcontroller?

5. Mandatory all green thread, memory, UB sanitisers and clean valgrind. All also tested per-commit.

"green thread"?? For the targets and applications I am interested in heap, exceptions, RTTI, and all other things that requires more than a few kB of code (that is nearly all standard libraries!) are out of the question.

6. Mandatory CI testing for exception safety. I am hoping a clang rewriter can basically patch all exception throws and have them randomly throw for testing.

7. Per-library source distributions

Yes!

10. BoostBook documentation using the Boost look and feel becomes mandatory. I've had enough with library authors thinking they can improve on BoostBook's output with things like using Comic Sans as the font or weird colour schemes throughout.

I have tried to make some sense of boostbook but I got nowhere. All documentation about it seems to assume I know how to do thins that I have never heard of. Note that I am mainly a Windows user. Wouter van Ooijen

On 16 May 2014 at 13:03, Nevin Liber wrote:

...

1. Boost isn't sexy any more.

3. All the interesting new C++ 11 libraries you find around the

...

internet have zero interest in trying to join Boost, with a very few honorable exceptions. That speaks volumes, to me at least.

Or, if you really believe this,

I would challenge anyone to find a better fitting explanation of the evidence.

maybe you ought to go and start another separate project for developing C++ libraries that is not affiliated with Boost. Seriously.

The big question mark, technically, is just how powerful clang AST analysers can be made. If I can write one which will port code from Boost to the C++ 11 STL and red flag all remaining use, I see no remaining technical obstacles. For example, those parts of Boost such as expected<> and optional<> one would need in a fork, but equally you want the fork to be live to the source. Meanwhile I continue to build out the automated test infrastructure for AFIO and its extending libraries. As there are many of these, I have made them generic, and there is no reason other libraries could not also work. My next step is a proper Travis CI API based test controller rather than the hack shell script I have right now. All this is six months away, and only if I'm happy testing my own code and the review of the C++11 libraries in the review queue goes badly (by which I include they don't get timely reviews), then we'll see where we are at.

...

3. Eliminate peer review in favour of a suite of automated libclang based AST analysers. Instead of persuading people to review libraries, persuade them to review and improve the AST analysers.

What AST analyser do I use to determine if I have a good interface for my library?

That is an excellent technical question. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On Fri, 16 May 2014 14:07:36 -0400 Sohail Somani wrote:

I say a big fat yes to CMake. I love the elegance of bjam but CMake + Ninja is ridiculous. CMake is elegant in its own way. I'd say big fat no to cmake. It's as silly as autotools if not more so. I'm tired of makefile generators and wouldn't contribute to any project requiring me to using them. I don't care if it's ninja or GNU make.

On Fri, 16 May 2014 14:58:18 -0400 Sohail Somani wrote:

I had the same ideological revulsion to CMake years ago so I can empathize with your position. I had very impolite names for it.

However, having moved more than one project over, productivity is much improved all across. There are definitely quirks but those quirks are usually well documented in my experience. The same can be said of autotools..

The point is I want to contribute to buildsystems themselves, as projects. Yet it's obvious to me that cmake as a whole is a mistake, so I can't contribute to it in good faith. The abundance of people considering it an upgrade compared to autotools and not another makefile hack suggests that there's little place for me in FOSS community.

On Fri, 16 May 2014 18:48:58 -0400 Sohail Somani wrote:

It may just be that CMake is chosen for C++ projects you follow in the future. If so, you might still find room for interesting things in the build system world. For example, there is currently a shake vs ninja benchmark battle [1] going on where someone like you could contribute.

I'm not interested in performance alone. I want to work on generalizing nodes beyond just files and aliases. For example, merging configuration into DAG proper. If makefile generators will be main focus in the future I'll just give up on contributing because configuration/build separation interferes with such generalization of nodes. Originally it resulted from low extensibility of make utility so people extended it with ./configure scripts which aren't integrated into DAG. Removing this historical artifact is what I want to work on.

On Fri, 16 May 2014 17:22:27 -0600 "Niall Douglas" wrote:

It proposes we eliminate build systems by making the entire thing a graph database compiling per-type rather than per-file.

Well, I've read that part and I'm not convinced it's a good idea. Buildsystem handles not only C++ but other toolchains and tasks. Once compiler writers get around to making their compilers cloud based and treat all cpp files as one enormous translation unit this can be integrated into a build tool as single step. Until then build tools can handle C++ dependencies by scanning header files and exchanging information between separate projects using tools like pkg-config. For now it's best to improve on this.

On 05/17/2014 01:05 AM, Sergey Popov wrote:

On Fri, 16 May 2014 18:48:58 -0400 Sohail Somani wrote:

...

It may just be that CMake is chosen for C++ projects you follow in the future. If so, you might still find room for interesting things in the build system world. For example, there is currently a shake vs ninja benchmark battle [1] going on where someone like you could contribute.

I'm not interested in performance alone. I want to work on generalizing nodes beyond just files and aliases. For example, merging configuration into DAG proper.

Are there any projects you know of that are attempting to do this? I would be interested. ClearCase Configuration Records and clearmake comes to my mind, but it is no real option for most developers. I agree that CMake and other build system generators have focus on the the wrong problems. However they follow laws of evolution and survive as developers are unable to smoothly integrate the best build systems into their favorite IDEs. Developers in the same project tends to have varying preferences regarding IDEs, so it is a hard sell for any build systems that don't fill this gap. Build system generators like CMake attempts to do so, while throwing a lot of other worthy build system goals out the window. I think much could be gained if required interfaces between build systems, IDEs and tool configurations could be identified, standardized and supported. But I am not holding my breath. -- Bjørn

On 05/20/2014 02:06 PM, Sergey Popov wrote:

On Sun, 18 May 2014 18:55:57 +0200 Bjørn Roald wrote:

...

Are there any projects you know of that are attempting to do this? I would be interested. ClearCase Configuration Records and clearmake comes to my mind, but it is no real option for most developers.

uhm.. boost.build? :P Also, Shake Sohail mentioned it seems..

Ok, I suspected you would put Boost.Build on the list. Shake looks interesting, worth keeping in mind. -- Bjørn

On 16 May 2014 at 14:07, Sohail Somani wrote:

...

Thoughts?

All of this sounds really good, your statements about "vested interests" aside. I'm not one of them, but if I were, maybe I'd find it a little offensive. I'm sure everyone here wants to do a good job.

I'm sure no one is malicious, definitely. But different people have different priorities. And there are vested interests, go back and examine the past threads on when C++ 11 should enter Boost and what happened when Stephen Kelly tried modernising the code.

Not because of politics or anything, but I would say that you do this independently of the usual Boost repo. Let there be a "C++03 Boost" and a "C++-latest-but-1 Boost". Share as little as possible.

As I mentioned in another thread there are chunks of utilities etc in Boost any fork needs. One just needs them based on the C++ 11 STL instead.

I say a big fat yes to CMake. I love the elegance of bjam but CMake + Ninja is ridiculous. CMake is elegant in its own way. And let's not give compiler vendors a pass by using their compiler as a baseline. Have a policy that says that we drop support for compilers that don't support (say) the penultimate standard. If the C++ standard is becoming more iterative, then the compilers need to be as well. So when C++17 is out, the library would support only C++14 with compiler workarounds only for C++14 and up.

I don't mind workarounds for VS2014, for which many will be needed. I suspect it's going to become the next MSVC6. If the C++ 17 feature set is crazy different to C++ 14 - and currently, it is not - I don't mind chucking away this set of libraries and starting fresh again.

I would not bring over any existing libraries unless the authors wanted to do so themselves and if they are also going to sunset the old C++03 library. For this reason, I'd start with new libraries that are needed just for C++11 code.

Oh sure. This proposal is even more maintainer led than before. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 16 May 2014 at 22:20, Vladimir Prus wrote:

On 05/16/2014 09:10 PM, Niall Douglas wrote:

...

3. All the interesting new C++ 11 libraries you find around the internet have zero interest in trying to join Boost, with a very few honorable exceptions. That speaks volumes, to me at least.

Could you list these libraries? That would be important to refocus the discussion on the value for the user.

Well, let us iterate the libraries which were presented this C++ Now conference which are not in Boost and have no (to my knowledge) intention to enter Boost. Some of these may not be C++11, it was hard to tell from the talk description, but a majority were: * Versor * Turtle Mock * BoundedInteger * Mach7 * Octopus * HPX * Metashell (or rather its underlying libraries) * libcppa (though Boost.Actor which is based on this is expected) * CppComponents * Some sort of C++ idiomatic XML library * Doppl * sfrp Need I say any more? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

John,

...

Well, let us iterate the libraries which were presented this C++ Now conference which are not in Boost and have no (to my knowledge) intention to enter Boost. Some of these may not be C++11, it was hard to tell from the talk description, but a majority were:

...

* Octopus

Unable to find that one.

It's here: https://github.com/STEllAR-GROUP/octopus. However, it's currently not in good shape as it relies on some older version of HPX.

...

* HPX

From a well known Booster, depends on Boost and is Boost-licenced. Let's hope we see it here soon, although it looks like it may still be experimental?

HPX (https://github.com/STEllAR-GROUP/hpx) can be seen as a maturing experiment :-P (HPX gains traction as it now can be used as a backend for Boost.Odeint and Joel Falcou's NT2, using it as the backend RTS for OpenMP, MPI, and OpenCL is in the works, other systems are under consideration to be supported) In order to be usable on real machines out there (administrators of supercomputers are notoriously conservative) HPX is written using C++03 with some C++11 features (mainly rvalue refs and move semantics) as supported by a reasonable set of compilers (gcc >= 4.4.5, VS2012, etc.). It heavily relies on Boost where the implementation is not sufficient or adds its own replacements where needed (movable/serializable tuple, function, bind, any, etc.). However, all of HPX's API is closely aligned with C++11, where possible, which clearly simplifies adoption. In any event, we don't expect HPX as a whole to be considered for Boost any time soon for 2 reasons: a) it is written using C++03 (for the time being, might change as compilers catch up) and more importantly b) it is a library consisting of many sub-libraries itself (threading, networking, algorithms, data structures, serialization, facilities for distributed computing, etc.) and we don't have the manpower to extract pieces which could be submitted to Boost. However, we'd welcome interested developers to extract what looks interesting and submit it as their own.

Well it would be nice of some of those library authors could chime in with their thoughts, otherwise we don't really know one way or another?

HTH Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

As the author of bounded::integer, I do intend to submit my library to Boost at some point, for whatever that is worth. It's just not in a state that is ready to submit yet (but soon it will be). I suspect that, as a C++14 library, it will have an interesting process getting in, but maybe the next Visual Studio preview will be out by then, which looks like it might support all the features I need. On Sat, May 17, 2014 at 4:30 AM, John Maddock wrote:

Well, let us iterate the libraries which were presented this C++ Now

...

conference which are not in Boost and have no (to my knowledge) intention to enter Boost. Some of these may not be C++11, it was hard to tell from the talk description, but a majority were:

* Versor

Interesting, if very domain specific.

* Turtle Mock

...

* BoundedInteger * Mach7

Currently has no docs on the web, so I can't judge.

* Octopus

...

Unable to find that one.

* HPX

...

From a well known Booster, depends on Boost and is Boost-licenced. Let's hope we see it here soon, although it looks like it may still be experimental?

* Metashell (or rather its underlying libraries)

...

* libcppa (though Boost.Actor which is based on this is expected) * CppComponents

Interestingly also Boost-licenced, and from a Boost contributor.

* Some sort of C++ idiomatic XML library

...

* Doppl

Couldn't find it.

* sfrp

...

Need I say any more?

Well it would be nice of some of those library authors could chime in with their thoughts, otherwise we don't really know one way or another?

Regards, John.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

On 19 May 2014 at 18:51, Michael Caisse wrote:

On 05/19/2014 06:47 PM, David Stone wrote:

...

As the author of bounded::integer, I do intend to submit my library to Boost at some point, for whatever that is worth. It's just not in a state that is ready to submit yet (but soon it will be). I suspect that, as a C++14 library, it will have an interesting process getting in, but maybe the next Visual Studio preview will be out by then, which looks like it might support all the features I need.

We welcome C++14 libraries and I see no problem with a submission on that basis alone if it is supported by at least two compilers.

For me personally, I would vote for an instant rejection for any library not compilable to the MSVC ABI irrespective of any other factors. The MSVC ecosystem is too large to ignore to call code portable without compatibility. I'll happily accept a MSVC CTP compiler, or even WinClang if they fix SEH support. It just needs to spit out working MSVC ABI binaries. VS2014 is a serious improvement over VS2013, but the lack of member function constexpr is going to be a problem. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On Wed, May 21, 2014 at 8:11 AM, Michael Caisse wrote:

You are at liberty to do that of course; however, there is no requirement that a library support MSVC.

If I were the review manager it would not pose a barrier to acceptance. The consensus among the Steering Committee is that at least two main-stream compilers are supported. GCC and Clang would represent that requirement.

MSVC's inability to keep up with the standard should not result in library authors performing acrobatic work-arounds if it isn't one of their targets. The compiler vendor will eventually catch up. For wider acceptance/usage of their library, the author may want to work around deficient compilers.

I agree completely. If you're working towards a Boost that can assume C++14 compiler conformance, I don't see why there needs to be restrictions to build against any specific MSVC version. The large VC user base is not an acceptable answer in this case: Every VC user is not going to upgrade to VC14 simply because it is going to be substantially more standards conforming. Too many VC users are not even using VC12, or VC11, yet. There are teams at Microsoft not even using VC12 or VC11 yet (I worked on at least two of them) and the former offers substantially better language feature support over VC10. I can't imagine this magically changing with VC14's release. Glen

On 22/05/2014 02:20, pmenso57@comcast.net wrote:

How about the burden of supplying a conforming compiler be put on MS rather than on everyone else? How is that supposed to help *users* of Boost?

From an outsider's perspective (ie use Boost) the conversation about whether Boost is alive or dead or needs forking is a bit bizarre. Take a read through and look for comment that reflects a concern for what users need to do ordinary day-job coding with C++. Personally, I think the problem is one of governance. Its all very well saying its open source and its up to users to contribute fixes, but look at what happens when they do and its not to the maintainer's taste (or the maintainer is busy or whatever). To me, a butt-ugly bugfix is still better than no bugfix. Take a look at the Poco mailing lists and compare the response to contributions to what you see here. (And take a look at the docs, and the coherency, and the focus on being useful for building real apps rather than some kind of research playground for advanced templating) James

On Thu, May 22, 2014 at 1:28 AM, wrote:

----- Original Message -----

...

From: "james"

...

On 22/05/2014 02:20, pmenso57@comcast.net wrote:

...

How about the burden of supplying a conforming compiler be put on MS rather than on everyone else? How is that supposed to help *users* of Boost? <snip> To me, a butt-ugly bugfix is still better than no bugfix. <snip> (And take a look at the docs, and the coherency, and the focus on being useful for building real apps rather than some kind of research playground for advanced templating)

Long term over short term. Short term is to workaround every compiler bug under the sun--which is what Boost and many other libraries have done. The result is a mess. It provides little incentive for compilers to be fixed, and it causes every "portable" library to be written either in LCD C++ or be hacked up with alternate implementations for the ten different languages (i.e. compiler dialects) that it is targeting.

As I see it, this is the crux of the conflict here. Users: Want a boost that *is* supported on (nearly) the LCD C++. They have an existing compiler (I would guess it is split roughly equally between gcc and msvc, but they majority of those are probably gcc-4.6 and msvc-10.0, not newer versions), that is already being used on their project and they might hope for a couple new features...like json or thread pools or something (probably not deep c++ stuff like type traits), but mostly want bug fixes for issues they find. Developers (of the libraries): Don't want to be held back by having to support LCD C++ because 1) The new (C++11/14/...) features make development of their library faster/cleaner/less painful/possible at all. 2) They want to develop a library/feature that may someday go into the language or standard libraries (a.k.a. the 'research' oriented development)....which has historically been an important part of boost. So..... Currently when we do releases of boost, we have a collection of compilers that everything is tested against and by-and-large if you are using one of those things will work for you. This goes all the way back to msvc-8.0/gcc-4.4/clang-3.0. This is great for the users, they get a ton of stuff and don't have to worry too much about it not working. However, it is also overkill. I've never seen an organization that uses even half of the libraries in boost. (I'd be interested in hearing an example of one that does :-) ) This has actually been a problem for my organization because with its huge size (several GB compiled) it becomes unwieldy to manage across multiple projects. *If* we want to move to a new organizational structure, the only way I could see it working out is if it substantially more modular than what we currently have. Here is an idea as to how this could be possible: ------ Each library would publish a list of what other libraries it depended on and what compilers (and platforms?) it supported. This would go in a file at the root of its git tree. We would then provide a tool to the users (like 'b2 headers'/BCP on steroids) that would take a list of libraries that the user wants and the compilers that they want to use. It would then download (or fail the dependency check) these libraries and their dependencies, and build them (or download binaries). This would also work very well with the various linux package managers as they would follow the same dependency pattern with their own tools. This would allow developers to introduce new libraries without having to worry about supporting older compilers. Users of old compilers would know, up-front, that this library isn't available for them. If the library caught on and there was user demand, support for older versions could be added later, if possible. The bar would be substantially lower for getting a new library into boost, but I wouldn't go as far as the original proposal went with only requiring automated tests to pass. Libraries would still need to go through a review process so that users can be assured that libraries in boost of high quality. We would still require having coordinated releases of all the libraries for a specific version number, however the release would simply be providing a file that lists the git tag for the version of each library that makes up the release. The toughest part of this would be making sure two libraries that both have a dependency on a third library are dependent on the same version of that library. Breaking changes in libraries that have dependencies would have to be communicated to the dependent libraries well in advance of a release. Overall, the biggest problem I see with this proposal is testing. By being modular, individual test times would be greatly reduced. This would hopefully enable CI like testing at each checkin, which isn't currently possible when it takes 8+hrs to run the tests on some platforms. However, as each library would be specifying exactly which compilers it uses, we would need a way to make sure that those are all getting hit. We currently don't have enough tester diversity to completely accomplish this. ------ If this could all be made to work, it would let advanced users have the advanced features that they want, while keeping the features that the normal users use a lot fully supported on the platforms they need. But it is just one idea...I'm sure there are lots of holes in it. Tom Kent

On 2014-05-22 13:07, Niall Douglas wrote:

On 22 May 2014 at 9:23, Tom Kent wrote:

...

Each library would publish a list of what other libraries it depended on and what compilers (and platforms?) it supported. This would go in a file at the root of its git tree. And here we flog that old and very dead horse of C++ package management yet again.

I don't see it being quite dead yet. At least, despite all the flogging, not much has changed, and everyone (in particular package and distribution maintainers) still face the same issues.

Dave even went off and wrote code to implement a C++ package manager, it's since been abandoned.

I wonder how he thinks of this experience in hindsight, and why he abandoned it. I already proposed my view of the situation: the problem is that a few people try to solve the problem not for a single project, but for the entire boost community. That community not being very easy, especially when it comes to things related to tools, this was a disaster waiting to happen. A more realistic alternative is to let each project come up with their own ways to deal with this, so all users of the project have to care about is precisely the information Tom lists above: what are the (coarse-grained) dependencies, and what are the supported platforms (including compilers) ?

Your comments are well intentioned, but C++ package management is very hard, much harder than it looks.

Yeah, but that is no reason to make it even harder by trying to come up with a universal solution that can be imposed on everyone.

A reasonable compromise is probably C++ Modularisation, even that applied to Boost would be a ton of monotonous work people won't be willing to do for free.

...

We would then provide a tool to the users (like 'b2 headers'/BCP on steroids) that would take a list of libraries that the user wants and the compilers that they want to use. It would then download (or fail the dependency check) these libraries and their dependencies, and build them (or download binaries). This would also work very well with the various linux package managers as they would follow the same dependency pattern with their own tools.

The underlying problem is not a technical one, and I wouldn't expect the solution to be yet another tool.

We can all wish for dream solutions, but in the end what we must adopt is what is reasonable given people work on this for free during family time.

In that line of thought: I think it's important to reconsider what the value (and thus focus) of Boost is. It's not the tools that are used to build the libraries, it's not the clever hacks that are used to work around compiler deficiencies, it's the new C++ APIs that are developed and made available to the larger C++ development community. And thus, if someone has great skills in writing (and implementing) such APIs, why should he be forced to learn particular tools to build, test, document, package, etc. his contribution ? Why can't he just pick whatever he is already familiar with, as long as the quality of the outcome meets the expectation ? Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 05/22/2014 05:27 PM, Niall Douglas wrote:

On 22 May 2014 at 13:44, Stefan Seefeld wrote:

...

...

And here we flog that old and very dead horse of C++ package management yet again. I don't see it being quite dead yet. At least, despite all the flogging, not much has changed, and everyone (in particular package and distribution maintainers) still face the same issues. There is an argument for making everything, absolutely everything header only in the long run. Modules makes it tractable.

Same problem again: wanting to apply a single policy to every project under the sun universally. That's adding to the problems, not solving them. Downscale the scope of the problem you want to solve, and you might have better chances of succeeding.

...

...

Dave even went off and wrote code to implement a C++ package manager, it's since been abandoned. I wonder how he thinks of this experience in hindsight, and why he abandoned it. Around the same time he declared enough of the git migration tool. Enough said.

Right, that's the same issue as the above: attempting to solve everyone's problems at the same time, with a single silver bullet. That has never worked yet, and I'm trying to learn from all those failures when proposing a different approach.

...

A more realistic alternative is to let each project come up with their own ways to deal with this, so all users of the project have to care about is precisely the information Tom lists above: what are the (coarse-grained) dependencies, and what are the supported platforms (including compilers) ? Thing is, BlackBerry initially let each team use whatever tooling it liked for BB10. The result was a disaster, and a huge amount of later work to unify the disparate build systems under a single meta build framework.

Others have succeeded. Consider yocto/openembedded and its "meta build framework". Here is a very good discussion of the underlying architecture: http://aosabook.org/en/yocto.html. The crux of the matter is to fully encapsulate the package-specific build systems. The result is a very flexible tool that allows to generate all sorts of Linux distributions with minimum effort. Consider what it would have taken if all those projects had to first agree on a single build system...

I think letting people choose their own tooling is disasterous, unless that choice plays nice with any arbitrary other build system. cmake integrates well with any arbitrary build system, it's why I suggested it.

(At the risk of diverting into a tool-specific discussion: I very much dislike the cmake approach the same way I dislike the automake tool: both generate Makefiles from templates, but those Makefiles are impossible to manage directly, so in the end it doesn't actually matter that you relay to (GNU) make for the final build, as you take away all advantages that tool itself offers. You could just as well have added the 'build' step to cmake itself. But, I don't really want to argue about cmake or any other specific tool here. That's against the very premise of the points I'm trying to make. :-) )

bjam isn't terrible, but I have had problems getting it to play nice with surrounding build systems in the past e.g. forcing certain custom compiler toolsets from a surrounding cmake.

...

...

Your comments are well intentioned, but C++ package management is very hard, much harder than it looks. Yeah, but that is no reason to make it even harder by trying to come up with a universal solution that can be imposed on everyone. Without conformance and imposition there would be no point in joining into the Boost libraries.

Consider this in the context of my "focus" remark further below. It's what Boost's focus ("added value" in marketing slang) is where conformity and imposition matters (i.e., good and modern APIs, rigorous design review and testing, thorough API documentation, etc.), not in the choice of tools and what font the documentation uses.

...

...

We can all wish for dream solutions, but in the end what we must adopt is what is reasonable given people work on this for free during family time. In that line of thought: I think it's important to reconsider what the value (and thus focus) of Boost is. It's not the tools that are used to build the libraries, it's not the clever hacks that are used to work around compiler deficiencies, it's the new C++ APIs that are developed and made available to the larger C++ development community. +10

...

And thus, if someone has great skills in writing (and implementing) such APIs, why should he be forced to learn particular tools to build, test, document, package, etc. his contribution ? Why can't he just pick whatever he is already familiar with, as long as the quality of the outcome meets the expectation ? +1 in some areas not others, as per my OP.

Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 22 May 2014 12:07, Niall Douglas wrote:

I also proposed in my OP that we skip package management as it's too costly to implement correctly, and go for per-library source distros instead which pushes the version lock problem onto users to solve.

How does significantly increasing the barrier to entry for current and new Boost users help your premise of saving Boost? Besides not agreeing with the premise, I just don't understand how it would do anything but hasten its demise. -- Nevin ":-)" Liber mailto:nevin@eviloverlord.com (847) 691-1404

On 22 May 2014 at 6:48, james wrote:

From an outsider's perspective (ie use Boost) the conversation about whether Boost is alive or dead or needs forking is a bit bizarre.

I can see that. One of the big reasons I've been agitating - and I suspect why my agitations haven't been instantly dismissed - is that the stats are trending negative on almost every metric. There have also been some internal shocks to the org this past year such as Dave leaving, to which different people naturally have reacted differently. After all, Dave for many people including myself *is* Boost, he is why I was ever here at all, and I mourn his loss. There are much wider issues too though. Activity in open source has been trending downwards on every metric for two years now. Statistically that is the biggest explantory variable for Boost's decline - it's actually a decline in all open source. Nevertheless, we are still declining relative to all open source, and I think that is a surprise to people given the recent relative strength of C++. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

[Please do not mail me a copy of your followup] "Niall Douglas" spake the secret code <5376952E.24618.31413788@s_sourceforge.nedprod.com> thusly:

On 16 May 2014 at 22:20, Vladimir Prus wrote:

...

On 05/16/2014 09:10 PM, Niall Douglas wrote:

...

3. All the interesting new C++ 11 libraries you find around the internet have zero interest in trying to join Boost, with a very few honorable exceptions. That speaks volumes, to me at least.

Could you list these libraries? That would be important to refocus the discussion on the value for the user.

Well, let us iterate the libraries which were presented this C++ Now conference which are not in Boost and have no (to my knowledge) intention to enter Boost. [...]

* Turtle Mock

The key phrase here is "(to my knowledge)". I don't know if you were in my presentation or not, but had you or anyone else asked me if Turtle was attempting to get into boost I would have said yes. The author and I have been working together on exactly this goal for some time. To that end, the author Mathieu Champlon has put it on the boost library incubator site: http://rrsd.com/blincubator.com/bi_library/mock/?gform_post_id=778 -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com

Niall Douglas wrote:

On 16 May 2014 at 17:46, Stephen Kelly wrote:

...

There is clearly not agreement within Boost that anything should be done at all regarding modularization, before a more 'big bang' break forward, from a reading of the mail from Niall.

For the purposes of clarity, I am not a member of Boost. I do not sit on any committees, and have no representation nor standing with the community apart from doing some admin for GSoC. I would say that my opinions on this are so extreme that no one agrees with me, and I expect my presentation at C++ Now tomorrow to not be popular.

That's probably not fun, so good on you for that. Rá beag ach rá é go maith :).

Here is what I think should be in a fork of Boost:

I either agree with or am indifferent toward a lot of what you wrote. I'll let others discuss 'what makes Boost Boost' and shouldn't be changed.

8. Reusable utilities in a submitted library need merging into some common utilities library which follows the STL conventions. Other than that, no source code, naming conventions, namespace or anything else needs converting or changing.

I do think there is a lot to be said for consistency in naming and API (and documentation, as you wrote :) ).

Thoughts?

Part of the value of Boost v1 currently is branding. Any group of developers could create 'a set of modern-idiomatic c++ libraries', with some equivalence to some Boost libraries (or as a fork of them), appealing to the modern needs that arise when you already have C++11/14 as a base. However, Boost has a greater chance than any other group of creating something credible and that the rest of the C++ community can get behind, partly because of expertise, but also partly because of branding. So, make sure such a v2 fork is called 'Boost' or is definitively 'the son of Boost' to keep that. I'm still not certain about how the Boost community operates and makes decisions (partly consensus, partly not), but I suspect there's some work to do there to get people on-board with something like this. Thanks, Steve.

On 16 May 2014 18:10, Niall Douglas wrote:

I would say that my opinions on this are so extreme that no one agrees with me, and I expect my presentation at C++ Now tomorrow to not be popular.

I really don't understand you. You wish to influence the direction boost takes, and yet you try your hardest to persuade everyone to reject your ideas.

1. To reduce the amount of human work involved in maintaining Boost. What Dave and Daniel had to do for the git conversion last year was far above what anyone should ever feel they need to do.

That was their decision, my preference was a simpler conversion. http://lists.boost.org/Archives/boost/2012/03/190885.php And I still ended up picking up some of the pieces when they abandoned it. I don't understand myself either.

AMDG On 05/16/2014 05:18 PM, Niall Douglas wrote:

<snip> I was trying to state as accurately as possible that no one I've talked to here agrees with me. If you remember the OP seemed to think I have some official position in Boost.

You're subscribed to boost-devel, aren't you? That's about as official as most of us. In Christ, Steven Watanabe

The main problems with Boost which are causing its decline are these:

1. Boost isn't sexy any more.

Niall, this is a very rich topic. I came late to C++ and even later to boost. My experience has been that boost is a trusted and established library with extremely high quality and a huge user base in the community. Making a boost 2 would be a massive endeavor. I shudder to think of refactoring the lines of code, carefully crafted for their purposes --- yet non-trivially intertwined with each other amidst massive header-dependencies that somehow keep boost up and running. It is simultaneously a wonder, an old work-horse, and some might even venture to say outdated. I would like to see some kind of new boost, or a face-lifted boost, especially with * a standard build system (if there even is such a thing) * a dedicated configuration for bare-metal OS-less programming. But to replicate and improve on boost would be an endeavor of huge development power. I could go for it, but it would be massive work.

3. All the interesting new C++ 11 libraries you find around the internet have zero interest in trying to join Boost, with a very few honorable exceptions. That speaks volumes, to me at least.

I once wrote an interesing library, and boost contacted me. We went on from there and have enjoyed a productive development for almost 3 years now. Let's get back to the "boost isn't sexy any more" part. I believe that *neither* boost nor C++ are sexy any more. I do not say this with sarcasm or cynicism. Rather, I say this with wonder and marvel at how boost and C++ have catapulted our ability to program to a level of abstraction that we previously only dreamed of. I do not know if any kind of boost 2 could re-vitalize C++ or if any kind of C++11 or 14 or 17 could re-vitalize boost. And I don't know if any re-vitalization is actually needed. C++ is one of the top three languages for development in the world! C++ is here to stay for a while. It might simply be that both boost as well as C++ are maturing. The C++ language is 30 years old. Maybe boost and C++ are reaching more of an institutionalized status, and less of a sexy status. Well, those are my ramblings. I guess I am satisfied with boost as it is. But I could also work on a new version. But by the time a new one might be done, I might be close to retirement. Either way, I really appreciate your energy --- positive, provocative, thought-provoking. Keep going! Cheers, Chris. P.S. If you would like to turn a whole generation of new programmers onto C++, look at the embedded-systems community. Those OS-less developers (predominantly electronics freaks) are cutting code in plain C and assembler --- 50 year old methods. We could bump them up 40 years with a turn-on to C++11 (which I did in my recent book on Real-Time C++).

For the purposes of clarity, I am not a member of Boost. I do not sit on any committees, and have no representation nor standing with the community apart from doing some admin for GSoC. I would say that my opinions on this are so extreme that no one agrees with me, and I expect my presentation at C++ Now tomorrow to not be popular.

I have however been doing a lot of canvassing whilst here at C++ Now. The main problems with Boost which are causing its decline are these:

1. Boost isn't sexy any more. As one very highly respected world famous engineer put it - and I won't say who, and I apologise to him for stealing his words without attribution:

"Boost used to be about all the stuff you really wanted in the standard. Now Boost looks like all the stuff that wasn't good enough to get into the standard"

Ouch.

2. Everyone recognises there are serious problems with process, everything from how you were treated Stephen when you tried cleaning out cruft and only really Dave supported you, right through to the fact that peer review simply doesn't work any more. The Boost community has become quite selfish in recent years, as you would expect from those with a vested interest in the status quo before evolution. And for the record, I have no problem with those vested interests keeping their existing Boost, but I personally want as far away from C++ 03 as soon as is possible.

There have always been problems with the process - in short nobody ever wants to do the dirty work - writing reviews, rewriting old code etc etc. It has always been thus.

3. All the interesting new C++ 11 libraries you find around the internet have zero interest in trying to join Boost, with a very few honorable exceptions. That speaks volumes, to me at least.

If that's true it would be interesting to know why. However the entry bar to Boost has always been a difficult one to negotiate. Mostly that's a good thing, but clearly putting folks off from even getting to the starting line is the negative side effect. It is and has always been a difficult balancing act.

Which suggests to me a need for a new Boost which attempts to apply the benefits of hindsight to what we learned with Boost v1. Now, it is extremely clear from this conference there is little appetite for that, but I think later on this year we're going to have three C++11 libraries in the queue, and if things have not very significantly progressed in any of the three items above, I think that time will be right time to fork. And here is what I think should be in a fork of Boost:

1. Minimum required compiler feature set will be VS2014's. No use of Boost STL permitted where the C++ 11 STL provides a feature.

Sigh. So workarounds, even totally trivial ones are banned? I don't see that as a good balance. But don't misunderstand me: Boost was founded to provide a haven for bleeding edge, experimental coding. We should still be that, and I hope we can look favourably on C++1y library submissions. There is a caveat however: we have only tended to accept bleeding edge compiler requiring libraries where that genuinely adds something to the library.

2. cmake instead of Boost.Build.

Another sigh. We've had one very large transition (SVN to git) in the last year that has already delayed the next release by many months. I would be strongly against another large transition anytime soon. I have nothing in particular for or against CMake - though I can certainly see the attraction of an externally-supported build tool. I suspect we lost the best part of a year transitioning from cvs to svn, I expect neither a change from svn to git, nor Boost.Build to something else to be any less painful. Nobodies fault, it's just the way that it is. Plus I'm not sure that this is the most important change we need - the time would probably be better spent improving the testing infrastructure, making Boost (and testing) more modular etc etc.

3. Eliminate peer review in favour of a suite of automated libclang based AST analysers. Instead of persuading people to review libraries, persuade them to review and improve the AST analysers.

I'm sorry but that's rubbish: peer review is much less about code quality, than the interface design, documentation, testing, and the "is this useful" litmus test.

4. Mandatory cross platform per-commit CI with unit testing exceeding 95% coverage. We don't care what unit test library is used so long as it can output results Jenkins can understand.

A much more worthy goal than changing the build system.

5. Mandatory all green thread, memory, UB sanitisers and clean valgrind. All also tested per-commit.

Also a worthy goal. Although I would just note that valgrind has it's own bugs: no long double support is a killer for the Math lib. I also note that an interested test-runner could do this right now this minute, by running their tests under Valgrind - I forget the magic incantation but Boost.Build supports this. In fact if you look at the Jamfile I wrote for the Pool lib, that has built in valgrind testing support. Of course the tests would take a *very* long time to run.

6. Mandatory CI testing for exception safety. I am hoping a clang rewriter can basically patch all exception throws and have them randomly throw for testing.

Which exceptions? Many are not random at all, they are thrown in a completely deterministic manner. The Math lib tests rely on: function(a, b); // should never throw, if it does it's a bug function(a, c); // should always throw. And yes, these are tested.

7. Per-library source distributions instead of a monolithic blob. This implies some dependency management, but cmake makes that much easier. It also means we can eliminate the release cycle because each library does its own release cycle, and the correct (i.e. tested) version of dependencies are included into each per-library source distro. This solves the version lock problem currently plaguing git-ised Boost, at the cost of pushing the version lock problem onto users [1]. BTW I want to see a soak test of the unit tests for 24 hours be all green before a release.

OK, also a worthy goal, I'm not sure how much CMake really helps though.

4. To incentivise authors to maintain their libraries as the quality bar is improved - the automated scripts will start to drop library rankings as the quality is raised, thus dropping that library in the overall rankings. Rather more importantly, it provides a natural "deprecation" mechanism, something sorely lacking in my opinion from present Boost.

For sure we need a better way to deprecate old, no-long-maintained libraries. I'll throw in 2 of my old things: TR1 and call_traits which should both be deprecated. Pool should probably go as well, but I'm sure there are others. In the short term, clearly marking their documentation as deprecated, and/or no longer listing/linking to them in the documentation index would be a good start. In fact I see no great impediment to implementing that for the next release? Regards, John.

On 2014-05-16 19:10, Niall Douglas wrote:

On 16 May 2014 at 17:46, Stephen Kelly wrote:

...

There is clearly not agreement within Boost that anything should be done at all regarding modularization, before a more 'big bang' break forward, from a reading of the mail from Niall. For the purposes of clarity, I am not a member of Boost. I do not sit on any committees, and have no representation nor standing with the community apart from doing some admin for GSoC. I would say that my opinions on this are so extreme that no one agrees with me, and I expect my presentation at C++ Now tomorrow to not be popular. If /really/ you think that, why do you do that presentation?

This is one of the most intense threads for long. Some thoughts of yours are provocative, sure, but hey, that might lead to a lively discussion at the conference (I'd love to be there). Anyway, have good luck in finding the right words and stirring a discussion!

I have however been doing a lot of canvassing whilst here at C++ Now. The main problems with Boost which are causing its decline are these:

1. Boost isn't sexy any more. As one very highly respected world famous engineer put it - and I won't say who, and I apologise to him for stealing his words without attribution:

"Boost used to be about all the stuff you really wanted in the standard. Now Boost looks like all the stuff that wasn't good enough to get into the standard"

I disagree. The libraries which made it into the standard are the ones which were most in demand like range based for, smart pointers, thread and regex. And sure, there are some libraries which will probably never make it into the standard, and sure, not all are of the same quality, but there are quite a few extraordinary ones, too! Metrics for code and documentation quality as well as responsiveness of the author would certainly help to filter out the sub-par ones over time.

2. Everyone recognises there are serious problems with process, everything from how you were treated Stephen when you tried cleaning out cruft and only really Dave supported you, right through to the fact that peer review simply doesn't work any more. The Boost community has become quite selfish in recent years, as you would

Selfish? That's the wrong word, I'd say. But there are quite a few people involved. It takes some time to make them move into a new direction.

expect from those with a vested interest in the status quo before evolution. And for the record, I have no problem with those vested interests keeping their existing Boost, but I personally want as far away from C++ 03 as soon as is possible. Throwing support for C++03 overboard is a huge change in direction. I would really love to see that change, but it will take some time.

And there is movement in that direction. Louis Dionne is working hard on mpl11, Eric Niebler has ported (or is porting?) proto to C++11. These are important steps towards a C++11 version of boost 2.0.

3. All the interesting new C++ 11 libraries you find around the internet have zero interest in trying to join Boost, with a very few honorable exceptions. That speaks volumes, to me at least.

There were always many more C++ libraries outside of boost than inside.

Which suggests to me a need for a new Boost which attempts to apply the benefits of hindsight to what we learned with Boost v1. Now, it is extremely clear from this conference there is little appetite for that, but I think later on this year we're going to have three C++11 libraries in the queue, and if things have not very significantly progressed in any of the three items above, I think that time will be right time to fork. And here is what I think should be in a fork of Boost:

1. Minimum required compiler feature set will be VS2014's. No use of Boost STL permitted where the C++ 11 STL provides a feature.

Personally I would say C++14 with Concepts Lite should be the platform to use. Starting with C++11 is going to be outdated in the near future, I guess. Otherwise: +1

2. cmake instead of Boost.Build.

+1

3. Eliminate peer review in favour of a suite of automated libclang based AST analysers. Instead of persuading people to review libraries, persuade them to review and improve the AST analysers.

That sounds pretty weird. How could such an analysis say if (for instance) Boost.Spirit is well written and worthy of Boost??

4. Mandatory cross platform per-commit CI with unit testing exceeding 95% coverage. We don't care what unit test library is used so long as it can output results Jenkins can understand.

+1

5. Mandatory all green thread, memory, UB sanitisers and clean valgrind. All also tested per-commit.

?

6. Mandatory CI testing for exception safety. I am hoping a clang rewriter can basically patch all exception throws and have them randomly throw for testing.

Nice idea!

9. There is no longer an "in" or an "out" for distribution. I'm thinking of a scorecard page where member libraries are ranked by how high quality they are according to all the automated review, so when I say "mandatory" above, I simply mean they don't get to appear on the main downloads page without that precondition. All submitted libraries do appear though, just ranked very low if their quality is low. I would hope all this is generated from a database and requires very little human input. +1 for the general idea

10. BoostBook documentation using the Boost look and feel becomes mandatory. I've had enough with library authors thinking they can improve on BoostBook's output with things like using Comic Sans as the font or weird colour schemes throughout. +1 Thoughts? Keep on stirring. Personally, I believe that you will receive more support for that idea than you seem to expect.

Cheers, Roland

On 17 May 2014 11:45, Andrey Semashev wrote:

On Friday 16 May 2014 11:10:51 Niall Douglas wrote:

...

1. Boost isn't sexy any more. As one very highly respected world famous engineer put it - and I won't say who, and I apologise to him for stealing his words without attribution:

"Boost used to be about all the stuff you really wanted in the standard. Now Boost looks like all the stuff that wasn't good enough to get into the standard"

I disagree with it completely and fighting the urge to use the word "ridiculous". There are no tools like Boost.Intrusive, Boost.Spirit, Boost.Interprocess or Boost.ASIO, not to mention things like XML, advanced networking (HTTP, FTP, SSL, etc.), encryption, the holy grail of GUI and many other domains not covered by Boost. You got threading, regex and a couple new containers and think you're covered? I think the previously hopelessly lacking STL got a little less hopelessly lacking.

I didn't read that quote as saying that the standard library has everything you want, only that the things you want aren't in Boost either. Maybe XML, advanced networking, encryption and GUI libraries are "the stuff you really want in the standard" but you won't find them in Boost.

On 20 May 2014 at 1:17, Jonathan Wakely wrote:

...

...

"Boost used to be about all the stuff you really wanted in the standard. Now Boost looks like all the stuff that wasn't good enough to get into the standard"

I disagree with it completely and fighting the urge to use the word "ridiculous". There are no tools like Boost.Intrusive, Boost.Spirit, Boost.Interprocess or Boost.ASIO, not to mention things like XML, advanced networking (HTTP, FTP, SSL, etc.), encryption, the holy grail of GUI and many other domains not covered by Boost. You got threading, regex and a couple new containers and think you're covered? I think the previously hopelessly lacking STL got a little less hopelessly lacking.

I didn't read that quote as saying that the standard library has everything you want, only that the things you want aren't in Boost either.

I think that was exactly the sentiment of the original speaker. For example, everyone recognises that something ASIO-like ought to enter the standard, it just isn't present ASIO.

Maybe XML, advanced networking, encryption and GUI libraries are "the stuff you really want in the standard" but you won't find them in Boost.

Which neatly brings me onto reporting on the discussions at C++ Now after I made the OP on Friday. In thinking through on why Boost may be dying in a C++ 11 world, someone raised a very interesting point on foundational vs non-foundational libraries. If you look at all the stuff which made it from Boost into the C++ 11 standard (and excluding anything also entering C11), as a rule of thumb it was all foundational e.g. shared_ptr exception_ptr regex ... and so on. What is very obviously missing is frameworks except where those were also duplicated in C11, so for example if C11 gained threads which it did, C++ 11 gained Boost's thread implementation rather than say a more C11 like thread implementation. I personally found this pattern to be highly useful. It suggests to us what added to recent Boost will enter C++ 17 or TR3, so taking a guess: boost::optional boost::expected ... are very highly likely candidates, as are any of the single-purpose Boost libraries such as Boost.TypeIndex. What is of course very interesting here is that by their nature, foundational libraries have a strong low hanging fruit nature, so the number of new additions is going to exponentially decrease over time. For example, I can see a very conservative C++11/14 based MPL having some chance for a TR3, but a Boost.Hana as presently proposed would probably be deferred till the next major release after TR3 as it is too experimental. Rather harder is to predict what might happen to a conservative generic monadic continuations framework based on expected<> et al. If done right, that would provide a base framework for all async in C++, thus allowing futures to mix seamlessly with ASIO and therefore async i/o with async anything else. That *could* become Boost's primary contribution to TR3, and finally provide a valid path for getting something ASIO-like into the standard (I am not hopeful than ASIO will be approved for TR2 personally, ASIO isn't stable enough, plus ASIO's current design does not seamlessly interop with other async in a generic way). Bringing this back to the point of a Boost v2, if Boost defines itself as the staging ground for additions to the C++ standard - a highly valuable enterprise IMHO - then a C++ 11 only reboot of Boost into a new fresh collection of libraries is paramount (and once again, I stress that the 03 Boost isn't going anywhere, think of it like the Python 2.x vs 3.x split), especially as one can fix many problems like CI testing, build, distribution, dependencies and even directory layout (a big thing we really also need is formal organisation around C++ Modules, present Boost would need substantial refactoring, even more than the git translation). I also still think that we can do a lot better with libraries in the review queue seeing as that list is likely to keep growing. Someone suggested that my earlier metric scoring proposal could be applied to those libraries in the queue with the top ranked in quality appearing in a separate category of "unreviewed" source distro, I think that a reasonable idea. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 21 May 2014 at 13:30, Jonathan Wakely wrote:

Did exception_ptr come from Boost?

It first appeared in Boost 1.36, nearly two years after Beman's first WG21 proposal for exception propagation and 18 months after Peter's exception_ptr proposal that was closer.

I did not know that.

I'm not sure the absence/presence of anything in C11 had much influence on C++11, remember C++0x was feature-complete many years ago, but it took a long time to bake the final standard (even /losing/ features along the way).

Ok, I'll put it the other way round then: it's hard to imagine C standardising a feature without C++ improving/"improving" on it.

...

I personally found this pattern to be highly useful. It suggests to us what added to recent Boost will enter C++ 17 or TR3, so taking a guess:

There isn't going to be a TR2, let alone a TR3, instead there are going to be several mostly-independent Technical Specification documents.

I'm a victim of Wikipedia on this! I thought I remembered that TRs were the way of the dodo, but https://en.wikipedia.org/wiki/C%2B%2B_Technical_Report_1#Technical_Rep ort_2 seemed to indicate TR2 was still happening. If someone more familiar with the committee's current plans could update that section correctly, that would be great.

...

... are very highly likely candidates, as are any of the single-purpose Boost libraries such as Boost.TypeIndex.

Unlikely given we already have std::type_index.

TypeIndex was specifically designed to supersede std::type_index.

The whole point of a TS is to be experimental, the contents are even in namespace std::experimental (that said, what Boost considers experimental and what WG21 considers experimental is not the same thing :-)

Eh, okay, this is actually news to me that a std::experimental is planned. Do we know what will enter it yet? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 21 May 2014 13:42, Niall Douglas wrote:

On 21 May 2014 at 13:30, Jonathan Wakely wrote:

...

Did exception_ptr come from Boost?

It first appeared in Boost 1.36, nearly two years after Beman's first WG21 proposal for exception propagation and 18 months after Peter's exception_ptr proposal that was closer.

I did not know that.

...

I'm not sure the absence/presence of anything in C11 had much influence on C++11, remember C++0x was feature-complete many years ago, but it took a long time to bake the final standard (even /losing/ features along the way).

Ok, I'll put it the other way round then: it's hard to imagine C standardising a feature without C++ improving/"improving" on it.

Thankfully C++ doesn't seem to be incorporating the optional Annex K from C11, with the bounds-checking interfaces such as tmpnam_s. I still think the comparisons with C11 aren't relevant and don't help make your point.

...

...

I personally found this pattern to be highly useful. It suggests to us what added to recent Boost will enter C++ 17 or TR3, so taking a guess:

There isn't going to be a TR2, let alone a TR3, instead there are going to be several mostly-independent Technical Specification documents.

I'm a victim of Wikipedia on this! I thought I remembered that TRs were the way of the dodo, but https://en.wikipedia.org/wiki/C%2B%2B_Technical_Report_1#Technical_Rep ort_2 seemed to indicate TR2 was still happening.

If someone more familiar with the committee's current plans could update that section correctly, that would be great.

Will do.

Eh, okay, this is actually news to me that a std::experimental is planned. Do we know what will enter it yet?

https://isocpp.org/std/status has some details, see the individual TS drafts for full contents.

On 21 May 2014 14:51, Niall Douglas wrote:

On 21 May 2014 at 13:53, Jonathan Wakely wrote:

...

I still think the comparisons with C11 aren't relevant and don't help make your point.

Yeah, I should explain that.

One of the central tenets of my presentation at C++ Now and its accompanying position paper is that C++ 11/14 does not deliver much useful to its use case as THE systems programming language over C11. I posited that if you looked at the new features in C++ 11/14 which C11 does not have from the perspective of a Python runtime engineer, you saw almost zero improvements.

Fair enough, that engineer doesn't care in the slightest that C++0x drafts had threads and atomics and a memory model definition earlier ... the end result is that both C11 and C++11 have those features.

I followed that claim with a further claim that stopping deliberately ignoring C++ ABI management would be a major tick in favour of C++ as the future systems programming language,

Agreed.

and for that we need to reawaken the type export feature,

Some form of module support is probably necessary, and I *really* hope we'll get it in C++17.

Hence the constant comparison with C11. Does that make sense now?

It does, thanks!

Jonathan Wakely wrote:

Those who want Boost to provide a bridge between C++03 and C++11 because they can't use C+11 should stick to "Legacy Boost" (whether that's v1.x or some fork that goes into maintenance mode) and not hold back interesting new development.

I don't understand. Who are those hypothetical people holding back interesting new development?

On 21 May 2014 13:49, Niall Douglas wrote:

On 21 May 2014 at 15:45, Peter Dimov wrote:

...

Jonathan Wakely wrote:

...

Those who want Boost to provide a bridge between C++03 and C++11 because they can't use C+11 should stick to "Legacy Boost" (whether that's v1.x or some fork that goes into maintenance mode) and not hold back interesting new development.

I don't understand. Who are those hypothetical people holding back interesting new development?

Start reading at:

http://boost.2283326.n4.nabble.com/c-11-td4648532.html

Thanks, that's exactly the thread I was trying to remember. "I used to see Boost as an empowering library, enhancing and evening out the playing field among the compilers out there." Evening out the playing field between compilers is what I meant by a bridge between C++03 and C++11. Maybe I should more accurately have said a crutch for legacy compilers. "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." Those are the kind of statements I disagree with. But then I'm just one voice, and haven't even contributed test results to Boost in many years, so my opinion shouldn't count for much :-)

On 21 May 2014 14:05, Peter Dimov wrote:

Niall Douglas wrote:

...

On 21 May 2014 at 15:45, Peter Dimov wrote:

...

I don't understand. Who are those hypothetical people holding back > interesting new development?

Start reading at:

http://boost.2283326.n4.nabble.com/c-11-td4648532.html

That was a year ago, and it's just words. If I decide to write a new C++11-only library, archived messages in a year-old mailing list thread will not stop me.

But, you'll say, the library will not pass review due to being C++11. Will it not? On what do we base this prediction?

I said people *should not* hold back development, I didn't say people *are* holding back development. Of course it's up to the people actually writing the libraries to decide what features they want to use. I hope those people continue to push Boost in new and interesting directions.

On 05/21/2014 06:59 AM, Niall Douglas wrote:

On 21 May 2014 at 16:05, Peter Dimov wrote:

<snip>

...

But, you'll say, the library will not pass review due to being C++11. Will it not? On what do we base this prediction?

I look forward to the day when the first C++ 11 library enters Boost. But I also recognise that before that can happen, a consensus on how we're going to handle that will have to be reached. Right now the consensus appears to be to use #ifdef and bundle it in with the 03 libraries.

I'm not certain which population you are using for consensus. The barriers of getting a C++11 only library into Boost are currently the difficulties raised by Robert Ramey in the "Thoughts of Boost v2" branch of this thread. Another barrier is the submission of a C++11 only library. As announced in the annual Future of Boost session at C++Now, Sebastian Redl will be drafting how-to suggestions for integrating C++11/14 only libraries into Boost. While Robert's concerns must all be addressed, this isn't a problem that is entirely unique and one that we haven't dealt with before. michael -- Michael Caisse ciere consulting ciere.com

On 05/21/2014 09:05 AM, Bjorn Reese wrote:

On 05/21/2014 05:39 PM, Michael Caisse wrote:

...

I'm not certain which population you are using for consensus. The barriers of getting a C++11 only library into Boost are currently the difficulties raised by Robert Ramey in the "Thoughts of Boost v2" branch of this thread. Another barrier is the submission of a C++11 only library.

Robert's mails do not appear on the mailing-list (I suspect that you have read them via a gateway for the mailing-list rather than the mailing-list itself.) Can somebody please forward or summarize them here?

Hi Bjorn - I read via the ML with an old fashioned email client. It appears I got a copy of it because Robert sent it directly to me (o; I'll reply to the message so it is in the thread. Hi Robert - I checked the nabble archive and your messages are not coming through. http://boost.2283326.n4.nabble.com/Anyone-is-interested-in-being-review-mana... I'll forward the header to you. It looks like your messages are going to googlegroups and a copy to lists.boost.org. michael -- Michael Caisse ciere consulting ciere.com

On 21 May 2014 18:09, John Maddock wrote:

Life would be much easier if GCC was C++11 by default.

Once we've got our C++11 ABI nailed down it might be worth switching the default, but definitely not before then.

On 21 May 2014 at 18:06, John Maddock wrote:

...

...

On 21 May 2014 at 15:45, Peter Dimov wrote:

...

I don't understand. Who are those hypothetical people holding back > interesting new development?

Start reading at:

http://boost.2283326.n4.nabble.com/c-11-td4648532.html

That was a year ago, and it's just words. If I decide to write a new C++11-only library, archived messages in a year-old mailing list thread will not stop me.

I agree, it seems to me there is a great deal of hyperbole here: is Boost really dead and/or being held back? Frankly I don't see it.

The statements were not made without evidence. See the slides at https://github.com/boostcon/cppnow_presentations_2014/blob/master/file s/change_ripple.pdf?raw=true See the position paper at https://github.com/boostcon/cppnow_presentations_2014/blob/master/file s/large_code_base_change_ripple_in_cpp.pdf?raw=true As Robert Ramey pointed out in the talk, the values for boost-users could be a chimera. We need some figures for the popularity of boost related questions on stackoverflow. I may do this for C++ Now 2015. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Em 08/05/2014, às 20:33, "Niall Douglas" escreveu:

For example, boost-users has a posting rate nearly a third that of before 2011.

Regarding this, my personal (weakly substantiated) perception is that people are migrating to sexier forums such as stackoverflow to get the same help. For instance, 5-6 years back I could get about 1 question a week about Boost.MultiIndex on the users list. Now it's like 1 question every 3 months here, but 1-2 a week in stackoverflow instead. Blame the crude interface a mailing list provides, registration entry barriers etc. As for the decline in the dev list, it looks more serious and there's no migration theory that could mitigate it. Also, I feel like the maturity level of discussions has fallen :-( Joaquín M López Muñoz Telefónica ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Em 08/05/2014, às 22:07, "Niall Douglas" escreveu:

On 8 May 2014 at 19:16, JOAQUIN M. LOPEZ MUÑOZ wrote:

...

...

For example, boost-users has a posting rate nearly a third that of before 2011.

Regarding this, my personal (weakly substantiated) perception is that people are migrating to sexier forums such as stackoverflow to get the same help. For instance, 5-6 years back I could get about 1 question a week about Boost.MultiIndex on the users list. Now it's like 1 question every 3 months here, but 1-2 a week in stackoverflow instead. Blame the crude interface a mailing list provides, registration entry barriers etc.

A very solid point. I'll include that in my talk actually.

Have you measured the level of Boost *usage* (even if via some proxy like lib downloads, unreliable as this is)? It could be the case that usage remains strong and it is only contribution that has dropped. Joaquín M López Muñoz Telefónica ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx

...

For example, boost-users has a posting rate nearly a third that of before 2011.

Regarding this, my personal (weakly substantiated) perception is that people are migrating to sexier forums such as stackoverflow to get the same help. For instance, 5-6 years back I could get about 1 question a week about Boost.MultiIndex on the users list. Now it's like 1 question every 3 months here, but 1-2 a week in stackoverflow instead. Blame the crude interface a mailing list provides, registration entry barriers etc.

As for the decline in the dev list, it looks more serious and there's no migration theory that could mitigate it. Also, I feel like the maturity level of discussions has fallen :-(

Joaquín M López Muñoz Telefónica

Frankly I don't see this that negative, at least not yet. Maybe the decrease of volume is caused by the fact that libraries most people were using are now part of the STL? I consider this might change as soon as the mental barrier we're having about writing C++11/14 only libraries goes and new cool libraries are written using the new language features. I'll try to do just this next week at CppNow. Maybe we also need new people to shake the tree and take an active part to replace those who are now less active. Cheers, Christophe

On 2014-05-08 22:24, Christophe Henry wrote:

...

...

For example, boost-users has a posting rate nearly a third that of before 2011.

...

Regarding this, my personal (weakly substantiated) perception is that people are migrating to sexier forums such as stackoverflow to get the same help. For instance, 5-6 years back I could get about 1 question a week about Boost.MultiIndex on the users list. Now it's like 1 question every 3 months here, but 1-2 a week in stackoverflow instead. Blame the crude interface a mailing list provides, registration entry barriers etc.

...

As for the decline in the dev list, it looks more serious and there's no migration theory that could mitigate it. Also, I feel like the maturity level of discussions has fallen :-(

Joaquín M López Muñoz Telefónica

Frankly I don't see this that negative, at least not yet. Maybe the decrease of volume is caused by the fact that libraries most people were using are now part of the STL? I know that's true for me, at least.. I consider this might change as soon as the mental barrier we're having about writing C++11/14 only libraries goes and new cool libraries are written using the new language features. I'll try to do just this next week at CppNow. Best of luck!

With boost 1.x based on and improving C++98/03, maybe it is time for boost 2.x, based on C++11/14 (I would prefer C++14 incl Concepts Lite)? This would allow for two things: * boost-1.x could carry on maintaining support for C++98/03, old compilers etc, which was and is awesome * boost-2.x could regain the truly pioneering spirit of boost, aiming for the next big changes in the language

Maybe we also need new people to shake the tree and take an active part to replace those who are now less active.

If some core libraries were dropping C++03 support in boost 2.x, I think this replacement process could be sped up a lot. Regards, Roland