On 5/13/2015 12:37 PM, Stefan Seefeld wrote:

On 13/05/15 12:19 PM, Niall Douglas wrote:

...

Personally speaking, I think the new library authors are overwhelmingly voting for a complete break with Boost 1.x. It makes no sense to bundle these new libraries into a 1.x monolithic distro when they have no dependencies on Boost.

I believe now is the time we start establishing the infrastructure to shape the new Boost 2.0 distro instead of wasting resources on trying to refactor the 1.x distro. APIBind is there for maintainers wanting to be part of both distros. Let's make a clean break.

Allow me to bring up a point I have been trying to make for quite a while: Why does Boost need a single "distro" ? Assuming a full breakup of boost libraries with well documented (and encoded) dependencies among them, I think a much more viable solution for everyone would be to let each boost library become its own project with its own release schedule etc.

So Boost would be merely an umbrella organization, and what you call a distro may be the repository of Boost libraries.

Wouldn't that be something worthwhile to think about and discuss ?

It is definitely worth discussing. The key is "with well documented (and encoded) dependencies among them". How do we do this ? ' It is silly to suppose that new "Boost" libraries will be developed that do not depend on other already existing Boost libraries. If library X depends on library Y we currently know that library X will work with library Y for Boost distro N because we have tested them before we release distro N. If library X goes off with its own release schedule how do we determine with which versions of Y it will work when it is being released ? This is the crux of the matter if we have individual Boost libraries being released on their own.

On 5/13/2015 1:24 PM, Thijs (M.A.) van den Berg wrote:

...

On 13 May 2015, at 19:00, Edward Diener wrote:

...

On 5/13/2015 12:37 PM, Stefan Seefeld wrote:

...

On 13/05/15 12:19 PM, Niall Douglas wrote: Personally speaking, I think the new library authors are overwhelmingly voting for a complete break with Boost 1.x. It makes no sense to bundle these new libraries into a 1.x monolithic distro when they have no dependencies on Boost.

I believe now is the time we start establishing the infrastructure to shape the new Boost 2.0 distro instead of wasting resources on trying to refactor the 1.x distro. APIBind is there for maintainers wanting to be part of both distros. Let's make a clean break.

Allow me to bring up a point I have been trying to make for quite a while: Why does Boost need a single "distro" ? Assuming a full breakup of boost libraries with well documented (and encoded) dependencies among them, I think a much more viable solution for everyone would be to let each boost library become its own project with its own release schedule etc.

So Boost would be merely an umbrella organization, and what you call a distro may be the repository of Boost libraries.

Wouldn't that be something worthwhile to think about and discuss ?

It is definitely worth discussing. The key is "with well documented (and encoded) dependencies among them".

How do we do this ? '

It is silly to suppose that new "Boost" libraries will be developed that do not depend on other already existing Boost libraries. If library X depends on library Y we currently know that library X will work with library Y for Boost distro N because we have tested them before we release distro N. If library X goes off with its own release schedule how do we determine with which versions of Y it will work when it is being released ?

This is the crux of the matter if we have individual Boost libraries being released on their own.

There wouldn't need to be a "we" to determine that. X version 1 (X1) would depend on Y1, when Y upgrades to Y2 then it's up to X to check if X1 works with both Y1 and Y2 or just Y1. If not then it could make a X2 release to support both Y1 and Y2.

So for each library you want the library maintainer to periodically check every past and present version of a library it depends on and document what dependencies it has and what versions of those dependencies works with the library. Forgive me if I find such a task a bit overburdening. This means that if my library X depends on A, B, and C I must test my library first against past versions of A, B, and C, in all possible combinations, and then must susbsequently test my library against any new versions of A. B. and C, in all possible combinations. Furthermore whenever I update library X I must go through the full procedure once again. I cannot conceive that such a manual versioning scheme is workable.

On 5/13/2015 9:34 PM, Niall Douglas wrote:

On 13 May 2015 at 14:12, Edward Diener wrote:

...

So for each library you want the library maintainer to periodically check every past and present version of a library it depends on and document what dependencies it has and what versions of those dependencies works with the library.

Forgive me if I find such a task a bit overburdening. This means that if my library X depends on A, B, and C I must test my library first against past versions of A, B, and C, in all possible combinations, and then must susbsequently test my library against any new versions of A. B. and C, in all possible combinations. Furthermore whenever I update library X I must go through the full procedure once again.

I cannot conceive that such a manual versioning scheme is workable.

Then you are highly unaware of the tooling available to automate this.

Travis can run, per commit, http://ispras.linuxbase.org/index.php/ABI_compliance_checker which ensures that ABI and API have not broken for a given API version of a given library. Each API version lives in its own git branch.

That will only test ABI compatibility at best. Unless you suggest that version 1 and version 2 of a library do not share any source code, it's quite possible that version 2 will break functionality in subtle ways, while retaining API/ABI, and there are not tools to check for that without testing. Thanks, Volodya

On 13 May 2015 at 13:00, Edward Diener wrote:

It is definitely worth discussing. The key is "with well documented (and encoded) dependencies among them".

How do we do this ? '

APIBind provides a formal dependencies implementation system at the C++ namespace level. git submodules are an effective, if brutal, dependency fetching implementation. They work.

It is silly to suppose that new "Boost" libraries will be developed that do not depend on other already existing Boost libraries. If library X depends on library Y we currently know that library X will work with library Y for Boost distro N because we have tested them before we release distro N. If library X goes off with its own release schedule how do we determine with which versions of Y it will work when it is being released ?

This is the crux of the matter if we have individual Boost libraries being released on their own.

APIBind provides a formal API versioning implementation. So library A can depend on library X v1 and library B can depend on library X v2 and both can coexist in the same translation unit. APIBind also allows dependency injection so users of libraries can inject the implementations they choose. API and ABI separation and coexistence also works as expected, including in the same translation unit. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 13 May 2015 at 14:14, Edward Diener wrote:

...

APIBind provides a formal dependencies implementation system at the C++ namespace level.

Where is APIBind ?

Ask Google. Search this mailing list.

Is it documented and tested ?

No. The Best Practices Handbook is the beginning of the docs.

Have you formally submitted it to Boost in any way ?

It will be presented to the community tomorrow morning 11am at C++ Now. The feedback from that should bring it to review soon enough (it's my next task after the conference). Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 13/05/15 01:00 PM, Edward Diener wrote:

On 5/13/2015 12:37 PM, Stefan Seefeld wrote:

...

On 13/05/15 12:19 PM, Niall Douglas wrote:

...

Personally speaking, I think the new library authors are overwhelmingly voting for a complete break with Boost 1.x. It makes no sense to bundle these new libraries into a 1.x monolithic distro when they have no dependencies on Boost.

I believe now is the time we start establishing the infrastructure to shape the new Boost 2.0 distro instead of wasting resources on trying to refactor the 1.x distro. APIBind is there for maintainers wanting to be part of both distros. Let's make a clean break.

Allow me to bring up a point I have been trying to make for quite a while: Why does Boost need a single "distro" ? Assuming a full breakup of boost libraries with well documented (and encoded) dependencies among them, I think a much more viable solution for everyone would be to let each boost library become its own project with its own release schedule etc.

So Boost would be merely an umbrella organization, and what you call a distro may be the repository of Boost libraries.

Wouldn't that be something worthwhile to think about and discuss ?

It is definitely worth discussing. The key is "with well documented (and encoded) dependencies among them".

How do we do this ?

Glad you asked. :-) I think the answer is easy within the context I brought this up in: Niall is suggesting a clean break, with only little concern for any transition (refactoring). So, if we start by assuming that each prerequisite library lives in a separate space, we can code these assumptions right into the build logic (e.g., separate header include and library search paths for each, etc.) Likewise, documenting the prerequisites is easy, if you have to do it upfront. It's only hard if these dependencies are implied, and only after the fact you need to re-discover them.

It is silly to suppose that new "Boost" libraries will be developed that do not depend on other already existing Boost libraries. If library X depends on library Y we currently know that library X will work with library Y for Boost distro N because we have tested them before we release distro N. If library X goes off with its own release schedule how do we determine with which versions of Y it will work when it is being released ?

That's for each library maintainer to determine and to encode. Of course, I would assume boost to provide shareable tools to make it easier to do this, but boost is hardly the only project facing such tasks. In fact, the entire Free Software world had to solve this for many years. (I can think of ways to add support for expressing and checking right into boost.build, for example, but no boost library author should be forced to use any of those. It's merely a convenience to make their life easier, not harder !) Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 13/05/15 02:07 PM, Niall Douglas wrote:

On 13 May 2015 at 13:52, Stefan Seefeld wrote:

...

Likewise, documenting the prerequisites is easy, if you have to do it upfront. It's only hard if these dependencies are implied, and only after the fact you need to re-discover them. git submodules.

That's only useful if you still want to work with the whole boost source tree as a whole, so I see it as a transitional measure. As I said, I really would like to get to a point where I can only check out boost.python, then configure its build by pointing at prerequisite libraries that I have either previously built myself, or got from my Linux (or other OS) distro. So there still is a fair bit of work that needs to go into boost.build. Stefan -- ...ich hab' noch einen Koffer in Berlin...

Niall Douglas wrote:

On 13 May 2015 at 14:19, Stefan Seefeld wrote:

...

...

...

Likewise, documenting the prerequisites is easy, if you have to do it upfront. It's only hard if these dependencies are implied, and only after the fact you need to re-discover them. git submodules.

That's only useful if you still want to work with the whole boost source tree as a whole, so I see it as a transitional measure.

Eh? Each git submodule is a direct dependency. Any git submodules inside those is their direct dependencies.

Haha! Enjoy handling cycles :) Also enjoy explaining to Robert what 'cycles' and 'dependencies' are :). Solve that problem and Boost might not be completely out in the cold as far as C++17/Clang modules are concerned. Thanks, Steve.

On 14 May 2015 at 23:29, Stephen Kelly wrote:

...

Eh? Each git submodule is a direct dependency. Any git submodules inside those is their direct dependencies.

Haha!

Enjoy handling cycles :)

Also enjoy explaining to Robert what 'cycles' and 'dependencies' are :). Solve that problem and Boost might not be completely out in the cold as far as C++17/Clang modules are concerned.

I believe I have a solution based on pinning branches instead of SHAs in submodules, and that APIBind based libraries export what API version they provide.

Is the boost community self-aware enough to be able to make a list of libraries which are maintained and a list of those that are not maintained?

Marshall have several lists. The strictest lists about 60 undermaintained libraries.

Do you even want to know? I wonder what would even be done with that information? Would you document unmaintained libraries as such, or be ashamed of doing so? Would you consider whether to keep releasing the unmaintained ones?

I believe a change in how inactive maintainers are removed has been agreed, plus measures to improve finding new maintainers for unmaintained libraries. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 5/13/2015 1:52 PM, Stefan Seefeld wrote:

On 13/05/15 01:00 PM, Edward Diener wrote:

...

On 5/13/2015 12:37 PM, Stefan Seefeld wrote:

...

On 13/05/15 12:19 PM, Niall Douglas wrote:

...

Personally speaking, I think the new library authors are overwhelmingly voting for a complete break with Boost 1.x. It makes no sense to bundle these new libraries into a 1.x monolithic distro when they have no dependencies on Boost.

I believe now is the time we start establishing the infrastructure to shape the new Boost 2.0 distro instead of wasting resources on trying to refactor the 1.x distro. APIBind is there for maintainers wanting to be part of both distros. Let's make a clean break.

Allow me to bring up a point I have been trying to make for quite a while: Why does Boost need a single "distro" ? Assuming a full breakup of boost libraries with well documented (and encoded) dependencies among them, I think a much more viable solution for everyone would be to let each boost library become its own project with its own release schedule etc.

So Boost would be merely an umbrella organization, and what you call a distro may be the repository of Boost libraries.

Wouldn't that be something worthwhile to think about and discuss ?

It is definitely worth discussing. The key is "with well documented (and encoded) dependencies among them".

How do we do this ?

Glad you asked. :-)

I think the answer is easy within the context I brought this up in: Niall is suggesting a clean break, with only little concern for any transition (refactoring).

I don't know what this means. No one can be serious that Boost libraries must be designed with no dependencies on other Boost libraries.

So, if we start by assuming that each prerequisite library lives in a separate space, we can code these assumptions right into the build logic (e.g., separate header include and library search paths for each, etc.)

Likewise, documenting the prerequisites is easy, if you have to do it upfront. It's only hard if these dependencies are implied, and only after the fact you need to re-discover them.

It's not documenting the prerequisites ( by which I assume you also mean library dependencies ), it is determining what versions of which dependence library a given library will need.

...

It is silly to suppose that new "Boost" libraries will be developed that do not depend on other already existing Boost libraries. If library X depends on library Y we currently know that library X will work with library Y for Boost distro N because we have tested them before we release distro N. If library X goes off with its own release schedule how do we determine with which versions of Y it will work when it is being released ?

That's for each library maintainer to determine and to encode. Of course, I would assume boost to provide shareable tools to make it easier to do this, but boost is hardly the only project facing such tasks. In fact, the entire Free Software world had to solve this for many years.

Sorry but that is just skipping over a real problem. If there are solutions that solve the problem then Boost needs to adopt one of those solutions. Having the solution be that each library developer specify in its documentation which library dependencies and which versions of those library dependencies the particular library works with is not solving the problem IMO.

(I can think of ways to add support for expressing and checking right into boost.build, for example, but no boost library author should be forced to use any of those. It's merely a convenience to make their life easier, not harder !)

On 13 May 2015 at 13:29, Nevin Liber wrote:

...

I don't know what this means. No one can be serious that Boost libraries must be designed with no dependencies on other Boost libraries.

+1.

*No one* wants to manage dependencies. I treat monolithic Boost as one dependency in my projects for that very reason.

I don't anybody at any stage has proposed this. This is a pure strawman by Edward. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 13 May 2015 at 15:20, Edward Diener wrote:

...

...

...

I don't know what this means. No one can be serious that Boost libraries must be designed with no dependencies on other Boost libraries.

I don't anybody at any stage has proposed this. This is a pure strawman by Edward.

What is a "pure strawman" mentioned by me ?

We were discussing a full fat, hard versioned dependency management system with external dependency injection facility. This achieves modular Boost. You claimed we were discussing removing all Boost dependencies from Boost libraries, and then made a stink about your claim which if true you would be right to do. Your claim is however complete make believe, and you are complaining about your interpretation of the proposal, not what is actually happening. I appreciate some actual documentation would be very useful. You may find the slides I'll presenting tomorrow of use: https://goo.gl/VHrXrj Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 13 May 2015 at 17:32, Edward Diener wrote:

I did say "I don't know what this means". My further remark about "No one can be serious that Boost libraries must be designed with no dependencies on other Boost libraries" was not directed at you personally, as if you were suggesting that. I was commenting in general that whatever "a clean break" meant it could not entail having Boost libraries with no dependencies on other Boost libraries, so the issues I was discussing about some sort of automated dependency management system versus manual documentation of dependencies were still relevant in the discussion of the post.

I see now the problem. You interpreted "clean break" as a brand new reboot of Boost, as if starting from scratch. That used to be my former position, however I got enough of APIBind working on C++ 98 that a "dual use" solution is now possible - Boost libraries which can function within Boost 1.x as a C++ 98 library, and also - with no code changes needed - as a C++ 11 library in Boost 2.x. My mistake was that I thought namespace aliasing was a C++ 11 feature, but it's a 98 feature and that makes APIBind work just enough on 98 that it's feasible. That's a migration path for existing Boost libraries, in other words.

I am sorry if you saw this as a personal attack on your proposal.

No, I got confused what you were talking about. Apologies for getting annoyed. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 13/05/15 06:43 PM, Michael Ainsworth wrote:

As previously mentioned, git submodules can help track dependencies, and this could be used advantageously.

git submodules only address a tiny part of the dependency tracking problem. In fact, the entire modularization effort has been very narrow-minded until now, focusing exclusively on reducing dependencies between source code, neither projects nor (binary) packages.

For example, say there is Boost.ProjectA located at git@github.com mailto:git@github.com:Person_A/Boost.ProjectA.git which depends on Boost.ProjectB located at git@github.com mailto:git@github.com:Person_B/Boost.ProjectB.git. If ProjectA 1.2 requires ProjectB 3.4, then ProjectA can simply specify that as a submodule.

What problem does that solve ? ProjectA is still tightly coupled to ProjectB. Both are still built together.

That part is simple. The complicated part is configuring all the dependencies of all the components within Boost.

So is it possible that an umbrella project located at git@github.com mailto:git@github.com:Admin/Boost could reference both submodules?

Again, what problem would that solve ? You would likely have to reference specific versions of those submodules (such as HEAD, or specific branches / tags), which is exactly what I think we should move away from.

In such a case, the release process would have to undergo changes, such as follows:

The (example) Umbrella Boost project is at 2.0 and 2.1 in the works. Person B informs Admin that there are significant improvements in Project B version 3.5, and he wants them included in the upcoming Umbrella 2.1 release. Admin knows that Project A depends on Project B, and so informs Person A that they are required to ensure Project A is compatible with Project B version 3.5 in order to be included in the Umbrella 2.1 release before date X.

Right, which is a good argument not even to attempt such a centralized project synchronization.

If Project A is not compatible by date X, one of several options could occur:

[...] Instead, let ProjectA express its dependency on ProjectB (including any version range) both, in the docs, as well as in the build tools (so the proper checks can be done. Again, it would certainly be helpful to provide tools (part of boost.build) to make it convenient for library authors to encode such dependencies as build checks. But there should be no requirement for anyone to use those tools. Again, all of this has already been solved many times, so there is no need to reinvent any of those wheels within Boost. It's just a distraction on many levels. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 13/05/15 07:41 PM, Peter Dimov wrote:

Stefan Seefeld wrote:

...

In fact, the entire modularization effort has been very narrow-minded until now, focusing exclusively on reducing dependencies between source code, neither projects nor (binary) packages.

I'm fairly sure that you're wrong, but for full confidence I'll first need to understand what you're saying. :-)

I want to be able to * fetch the sources of a specific boost library from the repository (that's now possible) * only build that library, using pre-built and pre-installed versions of all prerequisites (that's not yet possible) * make a new release of a boost library without having to synchronize with the release(s) of all other boost libraries (not yet possible) Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 13/05/15 08:00 PM, Niall Douglas wrote:

On 13 May 2015 at 19:50, Stefan Seefeld wrote:

...

* fetch the sources of a specific boost library from the repository (that's now possible)

* only build that library, using pre-built and pre-installed versions of all prerequisites (that's not yet possible) I assume you explicitly don't want to pull dependencies not strictly needed by your specific boost library.

I'm not sure what you have in mind. Are you talking about optional dependencies, i.e. dependencies that are required only when particular features are enabled ? Otherwise I don't see what "not strictly needed" means.

Right now for most boost libraries the strictly needed dependencies are all other Boost libraries. Therefore your prerequisites are "all of Boost".

Again, I'm not sure how you define "strictly needed". It may be hard to figure out which other files / libraries from Boost may be required to build boost.python, but I'd simply define "strictly needed" as "whatever files need to be present for the build not to fail with a "file not found" error.

I have no problem with that for the 1.x Boost. For a 2.x Boost I think we should take measures now such that we never again don't explicitly detail and encode the exact dependencies between libraries.

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

On 14 May 2015 at 3:13, Peter Dimov wrote:

...

Right now for most boost libraries the strictly needed dependencies are all other Boost libraries.

That's not quite true. See the report at

http://www.pdimov.com/tmp/report-develop-08112c5/module-weights.html

Fascinating Peter. I agree I was more wrong than right. Thanks for the correction. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Stefan Seefeld wrote:

I want to be able to

* fetch the sources of a specific boost library from the repository (that's now possible)

* only build that library, using pre-built and pre-installed versions of all prerequisites (that's not yet possible)

That's possible in principle, but not very practical. Suppose the library L uses X and Y, with Y using X. You have X and Y installed as binary packages in /usr/include and /usr/lib. But the library requires a newer version of X than what you've installed. So you fetch the source of X as well and build it. Now L builds, but Y is built against the preinstalled older X, whereas L is built against the newer X. ODR violation. We could... in theory... put every revision of every library into inline namespace d875a68ceb10081e30529e65ddef47297844e9f8 { but... well.

Stefan Seefeld wrote:

...

Stefan Seefeld wrote:

...

* only build that library, using pre-built and pre-installed versions of all prerequisites (that's not yet possible)

That's possible in principle, but not very practical. ... But back to the point: you say it's possible. How ? (And no, "in

On 13/05/15 08:05 PM, Peter Dimov wrote: principle" is not good enough.)

I have a vague idea that it's possible today. You just build the sources of the library, it picks up the preinstalled headers from your /usr/include. As long as the library doesn't require newer versions, it should work. I've never tried that though. And I'm not quite sure what's the point.

On 13/05/15 02:23 PM, Edward Diener wrote:

On 5/13/2015 1:52 PM, Stefan Seefeld wrote:

...

On 13/05/15 01:00 PM, Edward Diener wrote:

...

On 5/13/2015 12:37 PM, Stefan Seefeld wrote:

...

On 13/05/15 12:19 PM, Niall Douglas wrote:

...

Personally speaking, I think the new library authors are overwhelmingly voting for a complete break with Boost 1.x. It makes no sense to bundle these new libraries into a 1.x monolithic distro when they have no dependencies on Boost.

I believe now is the time we start establishing the infrastructure to shape the new Boost 2.0 distro instead of wasting resources on trying to refactor the 1.x distro. APIBind is there for maintainers wanting to be part of both distros. Let's make a clean break.

Allow me to bring up a point I have been trying to make for quite a while: Why does Boost need a single "distro" ? Assuming a full breakup of boost libraries with well documented (and encoded) dependencies among them, I think a much more viable solution for everyone would be to let each boost library become its own project with its own release schedule etc.

So Boost would be merely an umbrella organization, and what you call a distro may be the repository of Boost libraries.

Wouldn't that be something worthwhile to think about and discuss ?

It is definitely worth discussing. The key is "with well documented (and encoded) dependencies among them".

How do we do this ?

Glad you asked. :-)

I think the answer is easy within the context I brought this up in: Niall is suggesting a clean break, with only little concern for any transition (refactoring).

I don't know what this means. No one can be serious that Boost libraries must be designed with no dependencies on other Boost libraries.

At least I never suggested no dependencies.

...

So, if we start by assuming that each prerequisite library lives in a separate space, we can code these assumptions right into the build logic (e.g., separate header include and library search paths for each, etc.)

Likewise, documenting the prerequisites is easy, if you have to do it upfront. It's only hard if these dependencies are implied, and only after the fact you need to re-discover them.

It's not documenting the prerequisites ( by which I assume you also mean library dependencies ), it is determining what versions of which dependence library a given library will need.

Yes. That's a solved problem (if you look outside boost), with many solutions available, so I don't want to get into a discussion of which tool is best. Boost has been suffering from way too many of those discussions already.

...

...

It is silly to suppose that new "Boost" libraries will be developed that do not depend on other already existing Boost libraries. If library X depends on library Y we currently know that library X will work with library Y for Boost distro N because we have tested them before we release distro N. If library X goes off with its own release schedule how do we determine with which versions of Y it will work when it is being released ?

That's for each library maintainer to determine and to encode. Of course, I would assume boost to provide shareable tools to make it easier to do this, but boost is hardly the only project facing such tasks. In fact, the entire Free Software world had to solve this for many years.

Sorry but that is just skipping over a real problem. If there are solutions that solve the problem then Boost needs to adopt one of those solutions.

I strongly disagree. "Boost needs to adopt" already sounds very wrong to me, in the context of my proposal where Boost is little more than an umbrella org.

Having the solution be that each library developer specify in its documentation which library dependencies and which versions of those library dependencies the particular library works with is not solving the problem IMO.

It's not merely a question of documenting it (though that's certainly part of it). It's also a matter of encoding those dependencies in the build system, for example by using some validation checks that make sure the actual version V of prerequisite library L meets the version requirement. But again, all I'm hoping for is to find tools that make my life (as a library author) easier. Being forced to adopt a specific solution just because some Boost admins have decided that that's in my own best interest is heading in a very wrong direction. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 13/05/15 05:24 PM, Andrey Semashev wrote:

...

On 13/05/15 02:23 PM, Edward Diener wrote:

...

...

That's for each library maintainer to determine and to encode. Of course, I would assume boost to provide shareable tools to make it easier to do this, but boost is hardly the only project facing such tasks. In fact, the entire Free Software world had to solve this for many years. Sorry but that is just skipping over a real problem. If there are solutions that solve the problem then Boost needs to adopt one of

On 5/13/2015 1:52 PM, Stefan Seefeld wrote: those solutions. I strongly disagree. "Boost needs to adopt" already sounds very wrong to me, in the context of my proposal where Boost is little more than an umbrella org. I think you will have to make a choice ultimately. You can't realistically have a zoo of tools used by different libraries and expect them all work together nicely. If library A uses a dependency tracking tool X and depends on

On Wednesday 13 May 2015 14:42:43 Stefan Seefeld wrote: library B then X should be able to handle dependencies of B as well and so on to the leaf dependencies. I'm pretty sure the same would be desired for other tools, like build systems. If it doesn't work that way then you can pretty much drop the whole idea of modularity and follow the path of copy/pasting the code, something Google likes to do.

Just look at a typical Linux-based software stack. There are lots of applications with lots of dependencies, with lots of different choices of choices for tools to build and package, as well as version-control the code. Sure, life would be easier of the whole world would agree on a single set of such tools. But that isn't realistic. And experience with Boost has shown that the community easily gets distracted by bikeshed discussions about which tools to pick, which policies to adopt, etc. That problem can easily go away if there is no single choice to be made. In other words, "modularity" needs to be applied not just the code but the organization, too ! Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 13/05/15 06:00 PM, Edward Diener wrote:

On 5/13/2015 5:30 PM, Stefan Seefeld wrote:

...

On 13/05/15 05:24 PM, Andrey Semashev wrote:

...

...

On 13/05/15 02:23 PM, Edward Diener wrote:

...

...

That's for each library maintainer to determine and to encode. Of course, I would assume boost to provide shareable tools to make it easier to do this, but boost is hardly the only project facing such tasks. In fact, the entire Free Software world had to solve this for many years. Sorry but that is just skipping over a real problem. If there are solutions that solve the problem then Boost needs to adopt one of

On 5/13/2015 1:52 PM, Stefan Seefeld wrote: those solutions. I strongly disagree. "Boost needs to adopt" already sounds very wrong to me, in the context of my proposal where Boost is little more than an umbrella org. I think you will have to make a choice ultimately. You can't realistically have a zoo of tools used by different libraries and expect them all work together nicely. If library A uses a dependency tracking tool X and depends on

On Wednesday 13 May 2015 14:42:43 Stefan Seefeld wrote: library B then X should be able to handle dependencies of B as well and so on to the leaf dependencies. I'm pretty sure the same would be desired for other tools, like build systems. If it doesn't work that way then you can pretty much drop the whole idea of modularity and follow the path of copy/pasting the code, something Google likes to do.

Just look at a typical Linux-based software stack. There are lots of applications with lots of dependencies, with lots of different choices of choices for tools to build and package, as well as version-control the code. Sure, life would be easier of the whole world would agree on a single set of such tools. But that isn't realistic. And experience with Boost has shown that the community easily gets distracted by bikeshed discussions about which tools to pick, which policies to adopt, etc. That problem can easily go away if there is no single choice to be made.

In other words, "modularity" needs to be applied not just the code but the organization, too !

On Linux systems there is always dependency management software which specifies that if package X of a particular version is installed all dependent packages of the correct version are also installed. These systems do not depend on some documentation which tells the end-user what has to be done manually to install a package.

Of course most packages can be built from source manually, but the most Linux users probably use the automated package management systems instead.

Right. What's your point ?

If Boost goes the way where individual libraries can be released separately on their own development cycles, as you suggested, I think some sort of agreed upon automated dependency management system needs to be in place, at least for dependencies between Boost libraries/versions.

It surely would be convenient for developers to be able to handle dependencies, which is why I suggested that something like boost.build adds ways to express (and validate) them. But I'm still not sure why you would want to mandate that. It really is the same question as with all the other tools. Just look at the never-ending discussion about using bjam vs. cmake. I just don't have any hope that the entire (growing) boost community will ever agree. Letting each project decide for itself which tools work best seems to me to make most sense. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 13 May 2015 at 12:37, Stefan Seefeld wrote:

On 13/05/15 12:19 PM, Niall Douglas wrote:

...

Personally speaking, I think the new library authors are overwhelmingly voting for a complete break with Boost 1.x. It makes no sense to bundle these new libraries into a 1.x monolithic distro when they have no dependencies on Boost.

I believe now is the time we start establishing the infrastructure to shape the new Boost 2.0 distro instead of wasting resources on trying to refactor the 1.x distro. APIBind is there for maintainers wanting to be part of both distros. Let's make a clean break.

Allow me to bring up a point I have been trying to make for quite a while: Why does Boost need a single "distro" ?

Under my scheme, a Boost 2.0 distro is merely when one presses "Download All" and it downloads each of the individual standalone distros for each Boost 2.0 library.

Assuming a full breakup of boost libraries with well documented (and encoded) dependencies among them, I think a much more viable solution for everyone would be to let each boost library become its own project with its own release schedule etc.

Already there. APIBind makes it easier to iterate versions of a library without breaking dependent libraries who can remain bound to earlier versions. All in the same translation unit.

So Boost would be merely an umbrella organization, and what you call a distro may be the repository of Boost libraries.

Wouldn't that be something worthwhile to think about and discuss ?

Already there. The web service dashboard I mentioned would let users select what ordering criteria to rank the dashboard. You then press download to download whichever libraries you want. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 13 May 2015 at 14:06, Stefan Seefeld wrote:

...

...

Assuming a full breakup of boost libraries with well documented (and encoded) dependencies among them, I think a much more viable solution for everyone would be to let each boost library become its own project with its own release schedule etc. Already there. APIBind makes it easier to iterate versions of a library without breaking dependent libraries who can remain bound to earlier versions. All in the same translation unit.

Sounds useful. But "Already there" surely is somewhat of an overstatement. :-)

Already there in that the proposal already has that.

For once, each of those stand-alone library projects needs a way to be built stand-alone, against already installed prerequisite libraries.

APIBind currently requires header only dependencies. That removes the build system problem. If Boost decides on a future build system solution, we can do better than that. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 13 May 2015 at 14:36, Stefan Seefeld wrote:

On 13/05/15 02:10 PM, Niall Douglas wrote:

...

If Boost decides on a future build system solution, we can do better than that.

Right. But again, much as you said earlier, this needs to be a help to boost library authors, not liability. In other words, boost library authors should have the freedom to pick the tools of their choice to develop (including build and package) their respective libraries.

And thus, in that new world, "if boost decides" wouldn't be valid, because each boot library project has to decide for itself.

I can only deliver the parts which I can deliver. I can deliver true modularity, version specific dependencies, and dependency injection. I currently must demand header only everything because it avoids the build system problem. It is up to the community to decide that. I have delivered on viable first step on that path. The community can decide if that is worthwhile too, or if a better solution is preferable. I certainly think that deciding everything now is unfeasible. Decide what there is consensus on, build on that, reconsider the remaining problems later. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

...

...

Tomorrow at 11am after Eric's talk I'll be presenting at C++ Now a review of the upcoming C++ 11/14 mandatory Boost libraries.

Sorry for asking, but what is a C++11/14 mandatory library?

Libraries which cannot compile without -std=c++11 or -std=c++14. Some (not many) can work with VS2015 or even VS2013 too.

What's the point of introducing this distinction? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

...

...

...

...

Tomorrow at 11am after Eric's talk I'll be presenting at C++ Now a review of the upcoming C++ 11/14 mandatory Boost libraries.

Sorry for asking, but what is a C++11/14 mandatory library?

Libraries which cannot compile without -std=c++11 or -std=c++14. Some (not many) can work with VS2015 or even VS2013 too.

What's the point of introducing this distinction?

There are libraries which require -std=c++11 or -std=c++14. After studying ten of these libraries, I answer these questions:

1. Why do these libraries require C++ 11 or 14? From a user perspective

From my perspective, this is mostly relevant for the library writer, not the user.

2. Is there a common theme of the most popular C++ 11/14 features used?

Perhaps generally interesting but totally unrelated and insignificant to C++11/14, IMHO.

3. Is there a common theme in choice of library design and use of third party libraries?

What would this information give you? Finding new 'design patterns'? This is the only question I'd support going after as it would help other library authors to take advantage from 'best practices' and 'lessons learnt'.

4. Do these new libraries take notice of one another and integrate themselves well with other libraries, or are they ivory towers?

Again, what's so special about using C++11/14 in relation to this analysis? There are good libraries and bad libraries, open ones and closed ones. I don't see a relation to any language whatsoever.

5. How many of these forthcoming libraries explicitly seek to contribute to future C++ standardization?

Ok. As far as I remember, all of the Boost libraries which made it into the standard so far were written in plain old C++03. So my question again - what is the relation to C++11/14? You're asking a question pertaining to the author's willingness to contribute to the Standard. Nothing specific to C++11/14 here. And, FWIW, you can contribute to the Standard without being a Boost author of a 'C++11/14 mandatory library'.

6. Are there techniques used in one library which would make a lot of sense to be used in another library, but for some reason are not?

Sure, great question, but unrelated to C++11/14 as well! One More question: You connect this analysis of 'C++11/14 mandatory libraries' (a classification I find to be deeply troubling, btw) with 'rebooting Boost'. Is that intended or just a coincidence? Regardless, my impression deepens, that all of this is an attempt to take over Boost for your own (commercial) interests and to force your own library onto everybody else. An attempt which I will not support. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

On 5/13/2015 11:32 PM, Niall Douglas wrote:

On 13 May 2015 at 19:21, Hartmut Kaiser wrote:

...

...

3. Is there a common theme in choice of library design and use of third party libraries?

What would this information give you? Finding new 'design patterns'? This is the only question I'd support going after as it would help other library authors to take advantage from 'best practices' and 'lessons learnt'.

You mean https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook?

...

You connect this analysis of 'C++11/14 mandatory libraries' (a classification I find to be deeply troubling, btw) with 'rebooting Boost'. Is that intended or just a coincidence?

Two years ago I felt Boost should be rebooted for reasons.

Now I know Boost is being rebooted by the new library authors.

"Rebooted" meaning what ?

I had suspected it before, but now I know. I think it'll be a lot more obvious next year when the new authors have seen community review.

In the end it doesn't matter what you or I or anyone else thinks what should be the case.

Of course it matters, because 'we' are part of the "collective vote" of those developing libraries.

What matters is the collective vote by those writing libraries: their design choices, their preferences, and their code. I'd like to think I persuaded everyone to adopt my arguments, but in truth I think it was always going that way no matter anything I said.

I am actually laughing because you are so over the top in your assurance that everyone sees things in your own way, as if it were a fait accompli.

...

Regardless, my impression deepens, that all of this is an attempt to take over Boost for your own (commercial) interests and to force your own library onto everybody else. An attempt which I will not support.

Heh. I would just *love* to know what interests, especially commercial, those might be.

The truth is this Hartmut:

1. I wanted AFIO standalone. The only Boost library I knew of capable of standalone is ASIO. ASIO achieves standalone though a fairly laborious macro based dependency injection method which either injects the STL11 or Boost into the asio namespace.

2. I didn't want all that brittle manually written machinery ASIO uses. I felt using C++ 11 and a bit of libclang AST programming I could largely automate it and save myself a ton of work.

3. As I implemented it, I realised the same mechanism could do version binding too. And that it would likely be extremely useful to any other Boost author wanting both standalone and Boost options and to let them evolve their library without worrying about dependency breakage as much.

4. APIBind is *ridiculously* simple. People seem to think it some big complex thing. All it is is a set of conventions for naming really. C++ 11 and programmer discipline takes care of the rest.

Hence we are where we are. I don't claim APIBind is finished. I do claim it's good enough for my purposes, and with a bit of extra work it probably would be good enough for other people too.

Please document APIBind as fully as you can and I, and probably many others, will be happy to look at it and see what it is about.

It's up to each library maintainer if they wish to use APIBind, or do as Chris did with ASIO and do it all by hand. Or ignore dependency injection, and use no Boost at all.

How about the choice of not wishing to have a standalone library and use whatever of Boost or anything else one wants ?

Whatever happens, it is extremely clear to me a C++ 11/14 only Boost distro is coming simply through the authors in question continuing to support standalone modular use. Even if I were to vanish tomorrow.

Let it come then. I doubt that current Boost will go away. Boost currently consists of some 125+ libraries. Perhaps I am misinterpreting your attitude, but you seem to think that new C++ library developers have no use for any of those libraries and will find all they need to create their libraries in C++11/C++14 and its standard libraries. I do not find that to be true at all and I see nothing which supports those facts in libraries proposed for inclusion into Boost. I have nothing against those who want to create libraries that require C++11/C++14 implementations and still be part of Boost. If their design means that they do not need to depend on any current Boost libraries that's fine also. But to limit C++ library developers to only what is in the C++ standard library, and to place all of the usefulness of Boost libraries off limits to their development efforts, seems a foolishly willful effort for no gain at all and a great loss of potential functionality. I do not know if that is what you are proposing, or whether it is called Boost 2.0 or whatever. But if it is, it is not a goal of software development which I would ever pursue. I have already worked in enough programming jobs as a computer consultant where some boss, sometimes knowing next to nothing about software development, decides that useful software libraries should not be used. Inevitably inferior technologies are chosen which are written from scratch, wasting time, programming effort, leading to a poorer design, and a buggier product. Software dependencies are always a problem which must be solved by an intelligent system to deal with them. But they are far better than having to rewrite code which already exists, has been tested, and found useful, just become someone might fear that a dependency on some useful library will create unnamed and unimagined problems in the future.

On 13 May 2015 at 21:27, Thomas Trummer wrote:

Is there somewhere a rational about the problem this is trying to solve? If it's in the talk and you're allowed, maybe can you link to the PDF after the talk?

You can see a live copy at https://goo.gl/VHrXrj. Note it will change before tomorrow. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

One more point: There isn’t such a thing as a “C++11/14 mandatory library”. There are libraries that require compilers having certain versions or higher. This has always been the case and is not new. Just because a library requires/supports newer language features doesn’t mean that there is a fundamental shift all of the sudden.

On 14 May 2015 at 10:57, Thomas Trummer wrote:

* The talk isn’t really about future C++ libraries but to prove a point. This isn’t an issue per se but I wish people would be upfront instead of using bait and switch tactics.

Bait and switch is a classic feature of C++ Now talks. It is a conference of experts presenting to experts. We're not here to attend tutorials. We're here to see something different to the other big C++ conferences around the world, and that's why all the experts keep coming back to Aspen. I submitted almost the same topic for CppCon, but it's totally different content. For CppCon it's just a set of taster code examples using the libraries, almost a workshop.

* Two out of the five libraries used as evidence are from the same author as the talk. That leaves only three.

Actually I looked at 15 libraries, 10 in detail. Indeed two are mine, and about five have code or ideas from me in them.

...

Everybody avoids Boost.Test Are they really avoiding it or this is just a result of starting outside of Boost and not being part of Boost yet. Using asserts is more of a poor engineering practice than saying anything about Boost.Test.

Yes they are avoiding Boost.Test. The authors themselves may chime in here to confirm.

...

Most avoid Boost.Build Again. Are they really avoiding it or this is just a result of starting outside of Boost and not being part of Boost yet. Getting into Boost will result in using Boost.Build to be part of the whole regression infrastructure. I’m pretty sure no library author would object to that.

Actually they do. They want to use cmake. Not Boost.Build. Again, the authors may chime in here to confirm.

...

Everybody tries to use as little Boost as possible Are they really avoiding other Boost libraries because of some problem or don’t they just require other libraries? From the descriptions of the libraries that actually seems quit plausible.

Boost 1.x is obsolete. It is obsolete because enough of Boost 1.x is now in the STL that you no longer need to use Boost 1.x. It's also monolithic, and has a long list of structural problems. About half its libraries are undermaintained or not maintained. Many of the new authors wish their code as far away from it as possible because of the code smell. Quite frankly, as STL implementations get ever better, they are now better maintained and are of higher quality than Boost. In the end, STLs have a ton of full time engineers tending to them, Boost does not. Again, authors may wish to chime in or not themselves about their views on the matter.

...

All the libraries reviewed are ivory towers This is just repeating the same point. Boost libraries cover a lot of different areas so some of them are self-contained others have lots of dependencies. Though, everybody would probably agree that it’s better to have Boost.Atomic than five libraries implementing it itself.

I've actually changed my talk in response to this.

* The “Best C++ 11/14 Practices Handbook” has nothing to do with C++ (except one or two points). That doesn’t mean it’s wrong or bad but it’s just software engineering in general.

You might want to read it in detail instead of just the headings. It's very C++ specific, and fairly Boost specific. I give links of use examples throughout, all of which are to C++ projects or C++ code. Many of the tools proposed are C++ specific too.

...

Clear design and philosophical division between C++ 11 libs and 03 libs No evidence was presented for this. Arguing that future Boost libraries, even if they are C++ 11 only, are not going to depend on existing libraries is quite silly. I don’t see anyone object to use Boost.Build when getting accepted into Boost. If libraries use Boost.Test or not isn’t really an issue as long as the tests work with the testing infrastructure.

...

Obvious natural split for a C++11 only Boost 2.0 Obvious to whom? There will be libraries in the future that require C++11. This doesn’t create a problem for anyone. Neither does it require a split away from Boost.

I have adjusted my presentation to clarify what I meant here. Thanks for the feedback. It was useful. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On Thu, May 14, 2015 at 7:10 PM, Niall Douglas wrote:

Boost 1.x is obsolete.

It is obsolete because enough of Boost 1.x is now in the STL that you no longer need to use Boost 1.x.

It feels like either of us is living in a parallel universe, really.

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev Sent: 14 May 2015 17:54 To: boost@lists.boost.org Subject: Re: [boost] Some statistics about the C++ 11/14 mandatory Boost libraries

On Thu, May 14, 2015 at 7:10 PM, Niall Douglas wrote:

...

Boost 1.x is obsolete.

It is obsolete because enough of Boost 1.x is now in the STL that you no longer need to use Boost 1.x.

It feels like either of us is living in a parallel universe, really.

+1 - and I'm not in the Douglas one either :-( Compiler and language changes are continuous, not strictly quantizable, and so Boost must continue to track changes as is has from the start. C++ 11/14 will be followed by C++17 and C++2z ... I'm entirely unconvinced that the concept of a step change to Boost 2.x is any help at all. Sorry. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

On Monday 18 May 2015 20:36:55 Peter Dimov wrote:

Paul A. Bristow wrote:

...

...

It feels like either of us is living in a parallel universe, really.

+1 - and I'm not in the Douglas one either :-(

Compiler and language changes are continuous, not strictly quantizable, and so Boost must continue to track changes as is has from the start. C++ 11/14 will be followed by C++17 and C++2z ...

The defining characteristic of the Douglas universe is that the standard library now contains the many essential components (tuple, shared_ptr, function, bind, type traits, threads, atomics, and so on) that were previously only supplied by Boost.

In the pre-Douglas universe, you (the library author) had to rely on their Boost implementation, which coupled you to other Boost components, sometimes to their specific versions.

In the Douglas universe, you can use the standard library for all that, allowing your library to be independent of the rest of Boost.

Even if you use, say, boost::shared_ptr on C++03 compilers, since your library uses the interface of std::shared_ptr on C++11, this is a certain guarantee that it does not depend on anything specific to a particular version of boost::shared_ptr. As long as boost::shared_ptr is standard conforming, any version ought to do and upgrading boost::shared_ptr ought to not break things.

Hence the idea that libraries can follow their own release schedules.

All that doesn't make Boost obsolete, which is how Niall phrased it. Even for components that are in STL11, I'm still cautious about porting my code from Boost to STL11 because different implementations have different quality and because of that the code breaks or performance suffers. Of course, most of the time the transition goes smoothly and most issues can be worked around, but nevertheless in portable code Boost is still preferable. It reminds me of the days when STLport was active - I would often use it instead of the compiler-supplied STL on all platforms for the same reasons.

On Thu, May 21, 2015 at 3:53 PM, Niall Douglas wrote:

On 18 May 2015 at 21:12, Andrey Semashev wrote:

...

...

The defining characteristic of the Douglas universe is that the standard library now contains the many essential components (tuple, shared_ptr, function, bind, type traits, threads, atomics, and so on) that were previously only supplied by Boost.

All that doesn't make Boost obsolete, which is how Niall phrased it.

I think a majority of Boost users, rather than developers, will disagree. I worked recently on a C++ 11 code base which had mixed boost::future and std::future due to no better choice available. It was a royal pain in the ass to deal with (lots of std::async usage to work around the incommensurability).

Having a mixture of similar STL and Boost components certainly complicates life. However when it comes to a choice between STL and Boost the choice it not quite clear. And much more often than not there simply isn't a choice because STL doesn't have an equivalent.

...

Even for components that are in STL11, I'm still cautious about porting my code from Boost to STL11 because different implementations have different quality and because of that the code breaks or performance suffers.

This is *exactly* the point. It tests your code's assumptions about how a STL implementation works and forces you to refactor those assumptions.

No, I was more talking about bugs and inefficiency. For example, I had some code which crashed the compiler when I used std::bind but compiled well with boost::bind or phoenix::bind. Also, a while ago I tested performance of different regex implementations (IIRC, libc++, Dinkumware, Boost.Regex, Boost.Xpressive) and Boost.Regex turned out to be significantly faster than the rest on my patterns. There are most probably counter examples too, the point is that you should not expect porting to STL to be always beneficial - it may very well be the opposite.

...

Of course, most of the time the transition goes smoothly and most issues can be worked around, but nevertheless in portable code Boost is still preferable.

You are arguing in favour of a monoculture.

I'm just saying there are practical reasons to choose Boost over STL.

Niall Douglas wrote:

In AFIO I was not surprised by shared_ptr, but I was quite surprised by my use of boost::bind => std::bind which did not convert over identically. The fix was trivial, but I still learned I had been sloppy.

There are enough subtle (and pretty much intentional) differences between boost::bind and std::bind that the two aren't interchangeable. In the past, when C++11 was the future, I've sometimes said that in a C++11 Boost boost/bind.hpp will just contain namespace boost { using std::bind; }, but it can't. This will break a ton of code. For instance, given these two functions: void f( int x ) { std::cout << "f(" << x << ")\n"; } void f( int x, int y ) { std::cout << "f(" << x << ", " << y << ")\n"; } then boost::bind( f, 1 )(); works, and std::bind( f, 1 )(); doesn't. Conversely, for most std::bind implementations, this std::bind( f, 1 )(); works (saving you a cast), but the Boost equivalent boost::bind( f, 1 )(); doesn't. In addition, boost::bind supports a few operators, and std::bind doesn't (although one might argue that it ought to, as it already contains the necessary plumbing, but given that C++11 has lambdas, nobody decided to bother.) Even boost::mem_fn is not completely superseded by std::mem_fn. boost::mem_fn does get_pointer(sp)->f(...) for smart pointers, whereas std::mem_fn does (*sp).f(...). For most people this doesn't make much difference, but there are tricks you could play with get_pointer that would be broken.

On 14 May 2015 at 13:34, Tom Kent wrote:

...

Boost 1.x is obsolete.

It is obsolete because enough of Boost 1.x is now in the STL that you no longer need to use Boost 1.x.

I don't think this is even close to accurate. It is true that a bunch of the C++11 stuff boost had first, and is now redundant...and even more of the C++11 stuff was built into boost. However, all that isn't more than about 15% of what boost does.

This isn't the claim. The claim is that so long as the libraries in Boost which depend on STL11 equivalents cannot use the STL11 equivalent, they are suffering from at least these problems: 1. An inability to easily interoperate with code which uses the STL11 primitives e.g. std::future. 2. A compile time and binary bloat deficiency, sometimes very substantial. 3. A lack of sufficient maintenance, else the maintainer would have made use of STL11 available already just as Chris did with ASIO. 4. A potential deficiency in reliability and quality, as the STL11 Boost equivalents are probably not as well tested, audited, and maintained as the STL11 editions simply due to resources invested. This is why I claim that Boost 1.x is obsolete. I do not claim ASIO is obsolete. I do not claim any Boost library which uses or can use STL11 is obsolete, even if the code itself internally is ancient.

...

It's also monolithic, and has a long list of structural problems. About half its libraries are undermaintained or not maintained. Many of the new authors wish their code as far away from it as possible because of the code smell. Quite frankly, as STL implementations get ever better, they are now better maintained and are of higher quality than Boost. In the end, STLs have a ton of full time engineers tending to them, Boost does not.

I agree that the monolithic nature is a big pain and the lack of maintenance is a bigger one, but I'm not sure that your solution is one that the majority of the current boost would ever make it into, if we even attempt to make a move like that.

If so, that's a good thing. Me personally I'd have a "quality Boost" distro where the libraries supplied are only those with active maintainers OR no outstanding major defects are known on its bug tracker. I'd then supply a "legacy Boost" distro which is as the current distro is. If a library gets chopped from the quality distro, that is a big red flag that a new maintainer is needed. We don't have such a big red flag mechanism right now. I don't doubt more maintainers would volunteer if the need for them were more obvious (BTW changes on this from the CMT are coming soon, so watch that space).

I think we would be better served getting the more useful libraries outfitted with CI type testing (I really like the test matrix that is available on the AFIO page: https://github.com/BoostGSoC13/boost.afio) than trying to make a separate, modularized version of boost.

I'll be submitting a grant request to the SC to fund adding Travis and Appveyor support to all Boost libraries such that every commit and pull request gets instant notification if it compiles on OS X, Linux and Windows. If it doesn't compile, pull requests would be rejected until it does. It's still a long way from the AFIO test dashboard, but it's an excellent first step. And I'm going to attempt a web service dashboard in new portable .NET in the next few months, but no promises.

However, if the group does decide to make a new version where the libraries are modularized, then I would like to suggest that we come up with a new name instead of Boost 2.0, still under the Boost organization umbrella. I think the changes suggested go far beyond a simple version revision.

By Boost 2.0 I mean it like Web 2.0. I am currently unsure if any such Boost 2.0 would even have regular releases with version numbers, especially if a CI test solver simply spits out a known working across all libraries latest version with a date. That said, one might stick with version numbers anyway to help downstream distros. That's a future decision I think not important now. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 5/14/2015 5:29 PM, Stephen Kelly wrote:

Niall Douglas wrote:

...

Me personally I'd have a "quality Boost" distro where the libraries supplied are only those with active maintainers

I would love to see and scrutinize the list of Boost libraries whose metadata files are claimed to have correct maintainer information. Follow here for an incomplete list of libraries which have false maintainer information:

http://thread.gmane.org/gmane.comp.lib.boost.devel/259399/focus=259448

It's incomplete because at least MPL has a metadata file with false information, which was not merged by the person listed as its maintainer, and as we all know very well, MPL does not have a maintainer.

Is the boost community self-aware enough to be able to make a list of libraries which are maintained and a list of those that are not maintained?

Do you even want to know? I wonder what would even be done with that information? Would you document unmaintained libraries as such, or be ashamed of doing so? Would you consider whether to keep releasing the unmaintained ones?

Maybe you need to have the lists before you know the answer to those questions, which is what leads me to ask whether you want to know at all. Maybe not knowing is useful?

Your sarcasm is not appreciated. Instead you could make an intelligent suggestion about what you think Boost should do regarding a library which has no active maintainer. That might start a discussion which would solve that problem.

Stephen Kelly wrote:

I was not being sarcastic.

I haven't seen people on this list face the issue of which libraries have maintainers and which do not, although it has been raised repeatedly.

As Niall wrote elsewhere in this thread, addressing the collection of that information is apparently in progress. Thanks, Steve.

Peter Dimov wrote:

Stephen Kelly wrote:

...

I'd be interested in knowing how you would find out which libraries have/need maintainers, and whether you want to 'make a start' at getting that information.

This is actually not that hard to obtain by looking at what repositories have someone with a write access assigned to them.

Can I see that from here somehow? https://github.com/boostorg/mpl Or where is it available?

There's not much interest in this information not because people are actively avoiding it, but because it's only useful if we're going to do something with it.

Ok. Not gathering it in the first place is a great way to ensure nothing can be done with it :). Not knowing what the information is is a great way to have no ideas what to do with it :). To me, the claim that 'about half (60) of boost libraries have no maintainer' together with the fact that, in general, the boost maintenance model does not like 'community maintained libraries' and the fact only 11 libraries are listed in https://svn.boost.org/trac/boost/wiki/CommunityMaintenance points to a self-awareness issue. It also points to the question 'should Boost move more-consciously toward a community maintenance model?', even if only for some libraries. It appears to be what is happening *anyway* without intervention. Anyway, apparently the information *is* being collected. Presumably that will lead to publication in some form. Once the information is available, I'll make some new dependency graphs containing the information. Thanks, Steve.

Steven Watanabe wrote:

On 05/14/2015 05:49 PM, Stephen Kelly wrote:

...

It also points to the question 'should Boost move more-consciously toward a community maintenance model?', even if only for some libraries. It appears to be what is happening *anyway* without intervention.

It would be utterly pointless to intentionally try to move to such a model, when the CMT is understaffed to handle the libraries we already own. It's better to have a library owned by the CMT than by no-one, but it's definitely not ideal.

I didn't say it's ideal - I said it's happening *anyway* without intervention. If you want something 'ideal', then * awareness of what the current state actually is, and * awareness of what is happening anyway can only help. Your claim that what is happening *anyway* without intervention is 'not good' is a very important claim. Now that you know that something 'not good' is happening, do you think it's important to know that fact? Thanks, Steve.

On 5/14/2015 8:11 PM, Peter Dimov wrote:

Stephen Kelly wrote:

...

Peter Dimov wrote:

...

This is actually not that hard to obtain by looking at what repositories > have someone with a write access assigned to them.

Can I see that from here somehow?

https://github.com/boostorg/mpl

It's at

https://github.com/boostorg/mpl/settings/collaboration

but you probably won't be able to see it. The CMT and the mpl teams have write access, with the latter consisting of Joel Falcou and Edward Diener.

I do have write access to MPL but I do not have access to the settings of the project.

One might make a case for this information to be made available somewhere, as the current maintainers.txt is not very accurate. Github probably has an API for retrieving it.

...

To me, the claim that 'about half (60) of boost libraries have no maintainer' together with the fact that, in general, the boost maintenance model does not like 'community maintained libraries' and the fact only 11 libraries are listed in

https://svn.boost.org/trac/boost/wiki/CommunityMaintenance

points to a self-awareness issue.

The CMT team has write access to 15 libraries at the moment: concept_check, date_time, disjoint_sets, dynamic_bitset, format, function, interval, logic, mpl, pool, property_map, rational, signals, tokenizer, uuid.

...

It also points to the question 'should Boost move more-consciously toward a community maintenance model?', even if only for some libraries. It appears to be what is happening *anyway* without intervention.

The "community maintenance model" is already in full force. We could easily assign all unmaintained libraries to the CMT, but whether that will have any appreciable effects is another story. It's not like there are tons of people who are both qualified and willing to maintain and we're stopping them.

On 5/17/2015 2:53 PM, Ahmed Charles wrote:

...

Stephen Kelly wrote:

...

Peter Dimov wrote:

...

This is actually not that hard to obtain by looking at what repositories > have someone with a write access assigned to them.

Can I see that from here somehow?

https://github.com/boostorg/mpl

It's at

https://github.com/boostorg/mpl/settings/collaboration

but you probably won't be able to see it. The CMT and the mpl teams have write access, with the latter consisting of Joel Falcou and Edward Diener.

One might make a case for this information to be made available somewhere, as the current maintainers.txt is not very accurate. Github probably has an API for retrieving it.

...

To me, the claim that 'about half (60) of boost libraries have no maintainer' together with the fact that, in general, the boost maintenance model does not like 'community maintained libraries' and the fact only 11 libraries are listed in

https://svn.boost.org/trac/boost/wiki/CommunityMaintenance

points to a self-awareness issue.

The CMT team has write access to 15 libraries at the moment: concept_check, date_time, disjoint_sets, dynamic_bitset, format, function, interval, logic, mpl, pool, property_map, rational, signals, tokenizer, uuid.

...

It also points to the question 'should Boost move more-consciously toward a community maintenance model?', even if only for some libraries. It appears to be what is happening *anyway* without intervention.

The "community maintenance model" is already in full force. We could easily assign all unmaintained libraries to the CMT, but whether that will have any appreciable effects is another story. It's not like there are tons of people who are both qualified and willing to maintain and we're stopping them.

So, let's say I want to be the maintainer for dynamic_bitset, what's the process for doing that? Who do I ask?

You go to Boostorg / admin on Github ( https://github.com/boostorg/admin ) and you create a new issue asking to have admin ( or write ) access to the boostorg / dynamic_bitset repository. Unfortunately whoever usually deals with admin "issues" does not seem to be responding to them lately.

Slightly related question, I'm on the CMT, but it's not obvious who is in charge of adding new people who have access or who is in charge of moving libraries under The CMT when they have no active maintainers?

On 17 May 2015 at 12:50, Ahmed Charles wrote:

This is my overall point, it seems. The administration of boost seems to be understaffed or overwhelmed or both.

Until that is fixed, I think Peter's assertion that people aren't being stopped, isn't true, since they can't effectively become part of the process.

I noticed at this year's C++ Now many more people were talking about employing a full time permanent dedicated Boost infrastructure engineer than previous years. I have no idea how that might work, let alone who would have the "right" kind of personality to make it work. Still, the cashflow is now there to achieve this, and that was always historically the main showstopper. One idea I think the SC should consider is a half time employment with irregular grant based top ups, so 18 guaranteed hours per week with extra hours paid per approved project specific grant. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 5/14/2015 7:23 PM, Stephen Kelly wrote:

Edward Diener wrote:

...

...

Maybe you need to have the lists before you know the answer to those questions, which is what leads me to ask whether you want to know at all. Maybe not knowing is useful?

Your sarcasm is not appreciated.

I was not being sarcastic.

I haven't seen people on this list face the issue of which libraries have maintainers and which do not, although it has been raised repeatedly.

I can imagine some would think it would be 'useful' not to know in a 'head in the sand' way. I don't know if that is the way anyone here sees it though. That's why I asked.

The way you phrase it clearly implies that you are making fun of the idea that someone would purposefully not want to know if a library has a maintainer or not.

If anyone *does* want to know, I'd be interested in that even more. I'd be interested in knowing how you would find out which libraries have/need maintainers, and whether you want to 'make a start' at getting that information.

If 'making a start' or even seeing the audit to the end sounds like 'too much work' I'd also be very interested in that.

So far, there is no reliable information about which libraries are maintained, and there is much misinformation in the form of the metadata files. What I'm looking for from Boost is honesty and the self-awareness to find answers to questions such as 'which of the libraries that we release do we actually maintain?'.

With that in mind, I would encourage you or anyone else to write a different response to my email if you are sufficiently interested.

I would be sufficiently interested in finding out what libraries have no maintainers only if there was some plan about what to do with such a situation so at least bug reports and pull requests were taken care of for such a library.

...

Instead you could make an intelligent suggestion about what you think Boost should do regarding a library which has no active maintainer. That might start a discussion which would solve that problem.

What problem?

Even if you knew of a Boost library that does not have anyone as an active maintainer, what would you do to remedy that problem ?

Again, not sarcastic. If there is a problem of library maintenance, then what actually is the problem? Which list of libraries do not have a maintainer but need one? How can you ask for solutions to a problem you can not state?

The problem *I* am referring to is that you don't know what is maintained and what is not maintained. What problem are you referring to?

On 14 May 2015 at 18:52, Edward Diener wrote:

...

This isn't the claim. The claim is that so long as the libraries in Boost which depend on STL11 equivalents cannot use the STL11 equivalent, they are suffering from at least these problems:

What do you mean by "STL11 equivalents" ?

I just covered this in my talk today. A full list of exactly which APIs are exactly equivalent can be found at https://github.com/ned14/Boost.APIBind/tree/master/bind. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

This isn't the claim.

Well that's certainly how it read to me, in fact it seemed to me that you were originally advocating "lets throw everything away and start again".

The claim is that so long as the libraries in Boost which depend on STL11 equivalents cannot use the STL11 equivalent, they are suffering from at least these problems:

1. An inability to easily interoperate with code which uses the STL11 primitives e.g. std::future. Yes that can be an issue, but it's easily addressed via Boost.Config #ifdef's.

Some time back I changed Math to use std::tuple internally when available, now we're starting the process of exposing that to end users so they can use *any* suitable tuple type (including the 2 different versions in Boost, plus tr1 and std versions). The code doesn't care which, that's what generic code is for ;) For sure adding C++ support to older libraries may sometimes seem slow - but it's demand driven - unless there's a really good case for changing things lib authors are understandably cautious (and don't even get me started on noexcept specifiers!!) Basically if it's working perfectly well now, there has to be a good reason for major architectural changes, and those have to be handled on a case by case basis.

2. A compile time and binary bloat deficiency, sometimes very substantial. Really? Why would the Boost versions be so much larger than the std versions? Can you give an example? 3. A lack of sufficient maintenance, else the maintainer would have made use of STL11 available already just as Chris did with ASIO.

4. A potential deficiency in reliability and quality, as the STL11 Boost equivalents are probably not as well tested, audited, and maintained as the STL11 editions simply due to resources invested. I disagree strongly, often the Boost versions are mature, portable, heavily tested and in widespread use. IMO we haven't even begun to shake out all the bugs in the some of the std versions yet.

Do you realise that GCC completed it's C++11 support only in the most recent 5.1 release? Or that <regex> was a non-functioning stub until 4.9? And I haven't even even mentioned Boost-specific extensions - if you need full Perl compatibility then it's pcre or Boost.Regex, std::regex doesn't get there for example. John.

On 15 May 2015 at 8:59, John Maddock wrote:

...

This isn't the claim.

Well that's certainly how it read to me, in fact it seemed to me that you were originally advocating "lets throw everything away and start again".

That's where I was two years ago, even a year ago. I now have a viable migration path from 03 to modular 14 for existing Boost libraries. For those library maintainers which invest the effort to make their code base support both, I see no reason their library won't continue into the long term. If they remain wedded to 03 and refuse to support any 11 or any modularity, well I believe the users will vote with their feet on that over time.

...

The claim is that so long as the libraries in Boost which depend on STL11 equivalents cannot use the STL11 equivalent, they are suffering from at least these problems:

1. An inability to easily interoperate with code which uses the STL11 primitives e.g. std::future. Yes that can be an issue, but it's easily addressed via Boost.Config #ifdef's.

Some time back I changed Math to use std::tuple internally when available, now we're starting the process of exposing that to end users so they can use *any* suitable tuple type (including the 2 different versions in Boost, plus tr1 and std versions). The code doesn't care which, that's what generic code is for ;)

For sure adding C++ support to older libraries may sometimes seem slow - but it's demand driven - unless there's a really good case for changing things lib authors are understandably cautious (and don't even get me started on noexcept specifiers!!)

Basically if it's working perfectly well now, there has to be a good reason for major architectural changes, and those have to be handled on a case by case basis.

That's just about the worst way to add C++ 11 support. You get problems with ABI conflicts, violation of ODR, and additional bloat. As an absolute minimum, you need to combine such macros switching std::tuple usage into custom namespace. This prevents collision, violation of ODR, though does little for bloat. APIBind does exactly the above - custom namespace generation via macro programming, using inline namespaces to make this underlying solution hidden to code using your library.

...

2. A compile time and binary bloat deficiency, sometimes very substantial. Really? Why would the Boost versions be so much larger than the std versions? Can you give an example?

It's mostly a case of duplication of functionality, but as a single example I can see that a move capturing c++ 14 lambda is going to be ton more efficient than a std::function built using std::bind. C++ 11 is also much better at eliding unnecessary code.

...

4. A potential deficiency in reliability and quality, as the STL11 Boost equivalents are probably not as well tested, audited, and maintained as the STL11 editions simply due to resources invested. I disagree strongly, often the Boost versions are mature, portable, heavily tested and in widespread use. IMO we haven't even begun to shake out all the bugs in the some of the std versions yet.

Mature yes. The rest utterly no. The STL maintainers on this list may chime in here, I'll leave it to them.

Do you realise that GCC completed it's C++11 support only in the most recent 5.1 release? Or that <regex> was a non-functioning stub until 4.9?

I probably have a better idea than you. I am at C++ Now right now after all, and these issues have come up in *detail* ... :)

And I haven't even even mentioned Boost-specific extensions - if you need full Perl compatibility then it's pcre or Boost.Regex, std::regex doesn't get there for example.

Sure. If you really need the Boost edition, you're going to need it no matter what. I'm talking about the 80-90% of use cases not using any of the extended functionality, or able to not use the extended functionality. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Tom Kent wrote:

As and end user, I'd love to have a modular install, where just the libraries I need and their dependencies are installed. However, the more I think about it, it doesn't seem like that would be simple...

This is, if I might say so myself, a solved problem. tools/bpm does it.

On Thu, May 14, 2015 at 2:38 PM, Peter Dimov wrote:

Even though many compilers are now sufficiently C++11 capable, not all of them are, so Boost "1.x" still does have an audience and is, I'd posit, far from obsolete yet.

+1 It's easy for someone exposed only to the major development platforms to think that all that old stuff is obsolete. Last year I thought it was getting obsolete and then I developed a game for Nintendo 3DS. That platform has a good quality compiler but no standard shared_ptr or function or bind. We're not there yet. :) Emil

On 15 May 2015 at 0:38, Peter Dimov wrote:

...

Boost 1.x is obsolete.

I have to admit that for a long time I hadn't the faintest idea what you were talking about.

I think I get it now. You're saying that most of Boost's internal dependencies are to libraries that are now part of the C++11 standard library, and can therefore be eliminated, so that a newer, cleaner, Boost can have no internal dependencies, and its libraries can therefore be deployed independently of each other.

I don't want the dependencies eliminated. I want them loosened such they can be substituted by users for with STL11 alternatives. I think that a maintainer, when implementing that, would probably also take some measures to reduce dependencies. For many Boost libraries there is a minimal set of course.

You view this as an obvious good thing, because in your opinion, monolithic Boost releases are a pure cost and offer no benefits.

Totally wrong. Monolithic releases are very convenient. I keep one at https://github.com/ned14/boost-release for git submoduling.

All this is questionable. You have access to the dependency report and can - given enough motivation - evaluate, on its basis, whether Boost libraries can feasibly be expected to not depend on other Boost libraries, under the assumption that a C++11 standard library is available. Some of them can, others cannot. You haven't done this research.

No, I'm saying it's up to the maintainer to maintain their library. I believe that means making it able to use as much STL11 as possible if they want to keep it fresh and relevant. Or else they completely rewrite it in C++ 11/14. I don't mind which.

Even though many compilers are now sufficiently C++11 capable, not all of them are, so Boost "1.x" still does have an audience and is, I'd posit, far from obsolete yet.

I don't see why people keep thinking this is an either-or. You don't just convert your library exclusively to STL11. You make it give users the choice to externally select what your library uses. They can still choose Boost as the STL11, and be 98 compatible.

Plus, monolithic Boost releases are a delivery mechanism that puts libraries into the hands of users who could otherwise not have heard of them, or not have had the opportunity to use them due to company policy that requires vetting each dependency. "Boost 1.x" is seen as one entity and this has its downsides but it also has its benefits.

TL;DR: It's not that simple.

I'm not underestimating the effort involved. It cost me 60 hours to port a 18k line library to APIBind. Porting a 50k line library would be considerably longer. But I still claim that if a maintainer is maintaining their library to the ideal level, full STL11 usage is something they have done, are doing, or are planning to do soon, or alternatively are making a C++ 11/14 total rewrite of their library. As a corollary, those maintainers not fully embracing STL11 usage are not maintaining their libraries as well as they should. I could name libraries and maintainers right now who are reaching this ideal and which are not, but I'll leave them volunteer themselves if they choose. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 14 May 2015 at 16:23, Emil Dotchevski wrote:

...

No, I'm saying it's up to the maintainer to maintain their library. I believe that means making it able to use as much STL11 as possible if they want to keep it fresh and relevant. Or else they completely rewrite it in C++ 11/14. I don't mind which.

Are you saying that if a Boost library uses boost::function, it's up to that library's author to make it able to use std::function instead?

Yes. Maybe with a macro set by the user such as BOOST_XXX_USE_BOOST_FUNCTION=1.

I think that if the option is available at all it should be up to boost::function to map to std::function, but other Boost libraries would still #include "boost/function.hpp" and refer to it as boost::function.

The problem with that is almost certainly some libraries will need refactoring to support std::function. It's not always a clean swap, especially if boost::function extensions are used (even if not necessary). APIBind enables you to bind a copy of function<> into your library's namespace e.g. namespace boost { namespace foo { template using function = std::function; } } You obviously wouldn't define that except when building under C++ 11 with std function enabled. function<> then resolves to either std function or boost function as configured. Your library code is unchanged, and doesn't care what the implementation is. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On May 14, 2015 9:01:15 PM MDT, Emil Dotchevski wrote:

I also wonder to what degree does anyone care that they have a mixture of e.g. std::function and boost::function in their code base.

Having duplicate functionally means larger binaries and more cache misses. Therefore, having both is undesirable. ___ Rob (Sent from my portable computation engine)

Niall Douglas wrote:

...

...

APIBind enables you to bind a copy of function<> into your library's namespace e.g.

namespace boost { namespace foo { template using function = std::function; } }

...

Indeed, APIBind is there to ensure that your library X built against boost::function doesn't collide with your library X build against std::function in the same translation unit.

Does this actually work? Because I've trouble visualizing it based on this description. OK, X built against boost::function has namespace boost { namespace foo { template using function = boost::function; } } and X built against std::function has namespace boost { namespace foo { template using function = std::function; } } Why do those two not clash? I'm not seeing it. Perhaps the two 'foo' namespaces are actually different? But if so, does this not lead to a combinatorial explosion when more than one component can use either its Boost or standard version? function, bind, shared_ptr, regex... that's 16 combinations so far.

AMDG On 05/14/2015 05:00 PM, Niall Douglas wrote:

But I still claim that if a maintainer is maintaining their library to the ideal level, full STL11 usage is something they have done, are doing, or are planning to do soon, or alternatively are making a C++ 11/14 total rewrite of their library. As a corollary, those maintainers not fully embracing STL11 usage are not maintaining their libraries as well as they should.

As a library maintainer, I have no intention of doing anything of the kind. I do use C++11 in some places, but it's controlled by #ifdefs. I don't plan to remove the C++03 branches for a few more years at least. There are some places where C++14 will allow me to make the code significantly better, but I'm certainly not about to go out of my way to use new language features just for the heck of it. In Christ, Steven Watanabe

On 14 May 2015 at 19:27, Edward Diener wrote:

If C++11/C++14 does not offer anything to a library developer of an existing library than what they already have with C++03 and Boost, what is the impetus to add C++11/C++14 support to a library ?

I gave four reasons earlier in the thread.

I'll try again, even not knowing what you mean by "STL11 equivalents". Why would libraries in Boost which depend on STL11 equivalents not be able to use the STL11 equivalent ?

Slight API differences. Legacy API usage. Most STL11 implementations are much less forgiving than Boost with usage. Most of it is very small stuff, but requires human intervention to fix. I certainly found a small truck load of minor breakages in AFIO due to poor understanding of the STL. I learned a lot actually. My code rigour improved enormously. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 14 May 2015 at 22:06, Edward Diener wrote:

...

Most of it is very small stuff, but requires human intervention to fix. I certainly found a small truck load of minor breakages in AFIO due to poor understanding of the STL. I learned a lot actually. My code rigour improved enormously.

It is then not a matter of not being able to use an STL11 equivalent but only of the work involved to do so. If there is a reason to use functionality provided by C++11/C++14 a Boost library may still decide to do so. There is nothing technically holding back that library from doing so.

There are good ways and bad ways of supporting C++ 11/14 in an 03 library. Macros which swap boost for std equivalents and doing nothing extra are just about the worst way of doing it (ABI collision, bloat).

I do understand your point of view about new libraries using C++11/C++14 in order to cut down on dependencies of the equivalent functionality in Boost. I do not think your point of view is lost on anyone following this thread and your arguments. But that is a decision which each library developer will make.

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

2015-05-14 13:10 GMT-03:00 Niall Douglas :

...

...

Most avoid Boost.Build Again. Are they really avoiding it or this is just a result of starting outside of Boost and not being part of Boost yet. Getting into Boost will result in using Boost.Build to be part of the whole regression infrastructure. I’m pretty sure no library author would object to that.

Actually they do. They want to use cmake. Not Boost.Build. Again, the authors may chime in here to confirm.

Boost.Build is a pain. Boost QuickBook and DocBook are nice, but the tools are also a pain. I shouldn't have to download and maintain a Boost tree to make these tools work. It's like all or nothing. I'd like to see tools that are more modular, standalone and with no assumption that I'm building a Boost project. Of course, I'll migrate from CMake to Boost Build, as I want to see my ASIO-based HTTP library within Boost.

...

Everybody tries to use as little Boost as possible Are they really avoiding other Boost libraries because of some problem or don’t they just require other libraries? From the descriptions of the libraries that actually seems quit plausible.

Boost 1.x is obsolete.

It is obsolete because enough of Boost 1.x is now in the STL that you no longer need to use Boost 1.x.

[...]

Again, authors may wish to chime in or not themselves about their views on the matter.

In the case of Boost.Http, there are some Boost libraries that are not used because they have C++11 counterparts, like: - shared_ptr - cstdint - lambdas/bind/... - array - type traits - regex - ... Still, many Boost libs are used, like date_time, string algo, string_ref and a few others. I'd like to provide support for C++11 system error code too, but Boost's integration isn't so transparent yet. Actually, most of Boost.Http interface could be implemented in C++03 and the only trouble would be a migration path from C++03 enums to C++11 strongly typed enums. -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

On 14 May 2015 at 18:58, Vinícius dos Santos Oliveira wrote:

Still, many Boost libs are used, like date_time, string algo, string_ref and a few others.

When I reviewed your code I felt most of those uses were easily replaced, and moreover doing so would improve the quality of your code. I hope you don't mind me saying, but I felt some of your choices were you experimenting with fun new tools rather than what was the best solution (which is often the easiest and simplest solution). I'll wait to your community review to go into more detail. I didn't examine Http in too much depth yet.

I'd like to provide support for C++11 system error code too, but Boost's integration isn't so transparent yet.

As I have mentioned to you before, you can ask ASIO to tell you which error code system it uses, moreover ASIO itself can be configured with more than one error code implementation, so you need to pick up whatever it's been configured with. I'd also support standalone ASIO if I were you, and then you'll be ready for the Networking TS. You might consider replicating what AFIO does to use ASIO via APIBind, then you can support Boost.ASIO and the Networking TS with no extra work.

Actually, most of Boost.Http interface could be implemented in C++03 and the only trouble would be a migration path from C++03 enums to C++11 strongly typed enums.

Boost has an excellent C++ 11 enum emulation based on macros. And yes, I agree Http doesn't use a ton of 11 yet. ASIO in many ways forces you to use idioms which are very fast on 03, so the need for 11 isn't as acute. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 13 May 2015 at 19:58, Louis Dionne wrote:

...

* Just 3 libraries use valgrind as part of their unit testing (two are mine!).

Niall, I'd just like to point out that Hana does use Valgrind on Travis.

Wow, that's great news Louis. I've updated my graph and presentation slides. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 14 May 2015 at 6:58, Vladimir Prus wrote:

Looking at this list, I have a few questions:

- Why is that future directions of Boost must be determined by only C++ 11/14 libraries?

It isn't, solely. But I think that over time it will be just as the first libraries using partial template specialisation set the pattern for what followed. And the earliest libraries will, inevitably, have the greatest effect over subsequent libraries.

- 5 of the libraries are not in the review queue. Why is that future direction of Boost must be determined by libraries that are not actually proposed?

Also five are. But to answer, it depends on how important you think the review queue is vs simply peer review. If you agree with me that it isn't a necessary precondition to usefulness and adoption by users, then peer review queue status isn't so important. It's valuable, but not a precondition to being "Boost ready" in the quality sense. Peer review made more sense ten years ago when consensus was easier to obtain. Today's new libraries are too niche and specialist to get many peer reviews.

- Many of them are marked as not supporting MSVC. Not even 2015. That sounds a rather unpractical attitude, and makes me wonder, again, why would we use data from these libraries to decide on any future plans?

I think most of that is a lack of realisation how complete VS2015 support is. Some libraries really do need things VS2015 doesn't provide however. I think by next year a lot more libraries will support VS2015. If not, then VS2016.

...

Those libraries not ported to APIBind remain in the 1.x distro, which I would assume will gradually fade into obsolescence over time. This makes sense, as if a maintainer is not motivated to do the port then it seems proper that library should gracefully deprecate.

I am not sure exactly what you mean by 'ported'. If you propose that maintainers need to invest time in make a perfectly working library be part of your "Boost 2.0", then it's a bad idea, sort of fire-and-motion strategy (http://www.joelonsoftware.com/articles/fog0000000339.html)

Up to the maintainer. APIBind is merely a time saving layer which does some stuff for you. You can do it manually, of course, like ASIO.

...

Personally speaking, I think the new library authors are overwhelmingly voting for a complete break with Boost 1.x. It makes no sense to bundle these new libraries into a 1.x monolithic distro when they have no dependencies on Boost.

I think this statement is unfounded. Rather, it's correct to say that there exist 10 libraries with "Boost" in name, hand-picked by you, 9 of them not official Boost libraries, and 5 of them not formally proposed and 3 of them not even ready source-code-wise, and:

I actually considered 15 libraries. I believe, at least from when I asked on boost-dev a few months ago, that this is the total. The ones I didn't examine in detail are not too different incidentally. Most choose the STL11 over Boost.

...

I believe now is the time we start establishing the infrastructure to shape the new Boost 2.0 distro instead of wasting resources on trying to refactor the 1.x distro. APIBind is there for maintainers wanting to be part of both distros. Let's make a clean break.

While the above are interesting findings, I don't think they logically mean that authors of these libraries are voting for your infrastructure? Nor does that mean other libraries should make any changes.

Again, up to each maintainer. The authors of the libraries I reviewed appear very favourable to adopting APIBind as it saves them hassle, especially with supporting Boost.Test without the Boost.Test dependency. The Boost.Config emulation is handy too. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 15 May 2015 at 6:28, Vladimir Prus wrote:

...

APIBind is merely a time saving layer which does some stuff for you. You can do it manually, of course, like ASIO.

Well, other parts of your post suggest that perfectly useful libraries will be 'deprecated' or something unless they are somehow migrated to this new world. Did I misunderstand?

My statement is equivalent to this: libraries not maintained (with complete C++ 11/14 support) will stop being used over a finite time.

...

The authors of the libraries I reviewed appear very favourable to adopting APIBind as it saves them hassle, especially with supporting Boost.Test without the Boost.Test dependency. The Boost.Config emulation is handy too.

That might be good, but it does not explain how this tables supports your proposal for Boost 2.0? You've hand-picked a few libraries, ignoring half of libraries in review queue and created a table that shows no real convergence on anything. It hardly supports your proposal.

There is a ton of convergence in the C++ 11/14 libraries. Strikingly so. And away from the 03 libraries. I didn't examine the 03 libraries because they must adhere to Boost 1.x design requirements implicitly, and therefore have their hands tied in 03.

Now, the proposal *might* be good, it's just your statistics seems not a good argument for it.

Lack of data points so far. This time next year the future should be clearer to more people. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Michael Ainsworth spaketh:

<snip>, On a related topic, there are a number of libraries that haven't been accepted into Boost which have Boost in their name, (perhaps unintentionally) implying that they have been accepted. It'd be good if the Boost community made a ruling that future library submissions include in their name (and C++ namespaces) "Booster"/"Boostable"/some-other-variant, so as to indicate it's "not yet official" status. Once accepted, a simple find and replace would be required to reflect the status change.

I think this is a very good idea -- reserving the "Boost" name for libraries actually accepted to Boost. Perhaps we could establish a convention. For example, the Qt community labels "playground/speculative" projects with a "Qt" prefix (such as "QtSomeLib"), and after acceptance into Qt, they drop the "t" (and the fully accepted-and-supported library becomes "QSomeLib").

On May 16, 2015 2:46:29 AM MDT, Michael Ainsworth wrote:

...

On 16 May 2015, at 1:21 pm, "charleyb123 ." wrote:

Michael Ainsworth spaketh:

...

<snip>, On a related topic, there are a number of libraries that haven't been accepted into Boost which have Boost in their name, (perhaps unintentionally) implying that they have been accepted. It'd be good if the Boost community made a ruling that future library submissions include in their name (and C++ namespaces) "Booster"/"Boostable"/some-other-variant, so as to indicate it's "not yet official" status. Once accepted, a simple find and replace would be required to reflect the status change.

Authors of proposed libraries are supposed to add disclaimers that the libraries haven't been accepted and use a special logo in their documentation. References to them should always be just the library name, without "Boost", or the "proposed Boost library X". We do not require a special namespace, but that's not a bad idea.

...

I think this is a very good idea -- reserving the "Boost" name for libraries actually accepted to Boost.

How enforceable is this?

We will check with the Software Freedom Conservancy on that. ___ Rob (Sent from my portable computation engine)