July 2017 - Boost - lists.preview.boost.org

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 199

[yap] Re-announcing Yap
by Zach Laine 23 Feb '18

23 Feb '18

I posted 2-3 months ago about Yap, an expression template library I've written that I intend to propose for Boost. This is just a reminder that the library exists, and where to find it. I'm giving a talk about it at C++Now 2017, and some time after that I intend to submit it to the queue. Louis Dionne has offered to serve as review manager when the time comes. You can find the main repo on GitHub: https://github.com/tzlaine/yap And online docs are here: https://tzlaine.github.io/yap Zach

4 6

[beast] Security
by Phil Endecott 13 Dec '17

13 Dec '17

Dear All, To what extent do we think that Beast should be "secure"? I am thinking mostly about handling malicious input. Has it been reviewed by anyone with specific experience of how HTTP can be attacked? Has it been "fuzzed"? Regards, Phil.

6 10

icl mainainership?
by Avi Kivity 21 Nov '17

21 Nov '17

Hello, I see there are 7 pull requests outstanding against icl (including one of mine), but not activity. Joachim, are you still maintaining the library? If not, perhaps someone can step up.

3 4

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

Hi, all I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods. The project at http://stdex.sourceforge.net A git repository at http://nanapro.codeplex.com A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-lib… Is there any interest in this library? Regards Jinhao

8 8

Asciidoc, an alternative for documentation
by Peter Dimov 12 Oct '17

12 Oct '17

I've been experimenting with Asciidoc-based documentation, using Boost.Assert as my guinea pig. The good thing about Asciidoc is that Github shows a preview and you can edit it directly on github.com. This is how the source looks there: https://github.com/boostorg/assert/blob/feature/asciidoc/doc/index.adoc https://github.com/boostorg/assert/blob/feature/asciidoc/doc/assert.adoc https://github.com/boostorg/assert/blob/feature/asciidoc/doc/current_functi… This is how the generated HTML documentation looks, using the default stylesheet, without any customizations on my part: https://rawgit.com/boostorg/assert/feature/asciidoc/doc/html/assert.html And this is how the generated PDF looks: http://pdimov.com/tmp/assert.pdf The tool that produces these is Asciidoctor, http://asciidoctor.org/ .

13 34

base64?
by Greger 16 Aug '17

16 Aug '17

Hi Is anyone interested in a base64 encode/decode library (for boost)? ty Greger

9 15

Posts not appearing on Boost Mailman
by Raffi Enficiaud 14 Aug '17

14 Aug '17

Hi Boost, I have an issue with MailMan: I never use "emails" for posting on the Boost ML, I use news.gmane.org through thunderbird. I can see my posts on news.gmane.org, but I cannot see any of my posts here for instance: https://lists.boost.org/Archives/boost/2017/07/index.php Is this normal? Thanks, Raffi

5 8

Switch to CMake -- Analysis
by Thomas Heller 12 Aug '17

12 Aug '17

Hi list, After there has been a heated debated over the last three days over the switch to CMake, I'd like to share my observations... First of all, a general observation: In this discussion, there generally seems to two camps: Those who know Boost.Build and those who know CMake. Unfortunately, there doesn't seem to be any overlap between those groups, which generally made the discussions about a potential switch to CMake unfruitful, often leading to misunderstandings due to a lack of knowledge about the other tool. There is no doubt, that the group of people knowing CMake is larger and that projects using CMake far outnumber the ones using Boost.Build. A thousand flies can't be wrong, right? Is the popularity of CMake really the only benefit? Here is the thing, from my point of view: Apart from the different philosophy (Build System vs. Build System generator), in the end, you get a executable/library out of the system. From a pragmatic point of view, the only thing that changes to develop/build/test/use a library is the work flow. Leaving aside the disruptive and its effects of such. Now, on to the motivation for switching, as presented in the announcement: On 7/18/2017 9:12 AM, Jon Kalb via Boost wrote: > [...] our build system has become an impediment for many developers > and users, existing and prospective. Let's look at users first. Yes, FindBoost.cmake has its problems, but it works in 90% of the cases (from my own experience). This can, and should certainly be improved. Providing the necessary XXX-config.cmake files is what fixes this. There has been movement in that direction, with code, which could be just improved upon. This will fix those cases. The other group of library consumers, expressed the urge to build boost directly as part of their build process. That hasn't been done yet, but I am pretty certain, there are no road blocks to actually write such a CMake Module, which invokes b2 instead of the compiler directly inside of the superproject. Together with the generated XXX-config.cmake files, this use case is covered. From my recollection of the various discussions, this approach was not contentious at all, it wouldn't even require interaction with all library maintainers, and all CMake users (existing or prospective) would immediately benefit. Now on to developers. There is obviously a lot of resistance from existing developers (for various reasons, which are not really relevant for the discussion at hand). In my opinion, maintaining two build systems is a no-go. Either make a clear cut, or don't. Please don't waste resources on maintaining and supporting both. With this line of thought as the background, this will create massive disruption. Switching the whole of boost (including infrastructure, documentation etc.) to be built and tested with CMake is not easy and take a lot of time, leaving a void for both maintainers and prospective boost library authors. Now, the argument that has been brought up very often in favor for the switch is that it will attract more contributors, but will it really? I am reluctant to the idea that people don't contribute new libraries to boost just because of the build system. Despite a switch to cmake, you'd still have to conform to Boost.CMake guidelines and somehow make your library buildable and testable within and outside of the Boost Tree (there might be a straight forward solution to this). Furthermore, I often hear something like "in the presence of GitHub and CMake people don't think about submitting to boost anymore". This is exactly the point. But it has nothing to do with the "and CMake" suffix. It's is just far more easier and convenient to drop you library to GitHub, advertise it on various channels and call it a day. I hear you say: "Sure, but libraries will only be adopted if they come with CMake." That might very well be true, but what has this to do with Boost? Compare the lengthy and exhausting review process you have to go through with the click of a few buttons and hammering something onto a keyboard. And no, Robert, while the incubator was a nice idea, it doesn't compensate that either ;) All in all, I am pretty confident that a disruptive switch will hurt Boost more than it brings benefit. This already happened. To come to an end and summarize: Provide proper CMake integration, such that Boost is consumable by those (while you are at it, don't forget meson, bazel and pkg-config). While your add it, improve Boost.Build, maybe it can rise again from its ashes (why did it "fail" in the first place?). Regards, Thomas

27 78

Reminder: Boost Master branch will close for the 1.65.0 release on Wednesday
by Marshall Clow 02 Aug '17

02 Aug '17

Get your bug fixes and documentation updates in now! -- Mashall Upcoming release schedule: 2-Aug: Release closed for all changes, except by permission of a release manager. 5-Aug: Boost 1.65.0 closed for all changes 9-Aug: Boost 1.65.0 release

7 20

[outcome] Outcome v2 has reached stability, WG21 paper will be P0762R0
by Niall Douglas 31 Jul '17

31 Jul '17

For boost-dev's information: https://www.reddit.com/r/cpp/comments/6qo1m3/outcome_v2_has_reached_stabili… --- cut -- I am pleased to announce that Outcome v2, rewritten to fulfil the Boost peer review feedback from May and only reaching feature completeness three weeks ago, has been successfully deployed into two complex libraries which were heavily using Outcome v1. Lots of bug fixes and maturity has resulted, and if you were holding off on deploying Outcome into your own code until now, now is the time! The code itself is now ready for a second Boost peer review, it has all the same testing that v1 had, and I am highly confident as to its quality. What solely remains before Outcome v2 can reenter the Boost peer review queue for a second review is the documentation which remains parlous (and any help with it is greatly appreciated!), and the "Boostification" cronjob script as the peer review wants a "pure Boost" submission. I am also going to have to fix a number of bugs in Standardese the documentation tool first, it currently segfaults when fed the Outcome headers :). @foonathan's tool shows lots of promise, it does far better with C++ 17 than doxygen, just need to shave off some rough edges in the tool. What comes before that though is writing a WG21 paper P0762R0 summarising the Boost peer review which led to the stripped down, barebones v2 `result<T, E>` design and the rationale for the design deviations from `expected<T, E>` as according to the Boost peer review feedback. If WG21 feel warm feelings about a `std::result<T, E>` after reading P0762R0, then I will prepare a formal standardisation proposal for the Library Evolution Working Group (LEWG) and get the ball rolling for standardisation by attending meetings from 2018 onwards until it's through. I'll announce any draft D0762R0 here when it's ready for people to comment and give feedback on soon. My thanks to everyone here on Reddit, on boost-dev, on SG14 low latency, and privately who have helped out with testing, documentation, and so much more in making this library happen. I know those coming from Rust-land feel amazement how long it has taken C++ to replicate Rust's `Result<T, E>`, but I'm very sure ours is enormously superior to theirs already simply by doing so much less because it doesn't need to. Taking time to get design **right** is one of the big things which continues to separate C++ from the upstart systems programming languages. Long may it continue! --- context --- Outcome provides a C++ 14 STL-quality `result<T, EC>` and an `outcome<T, EC, E>` implementation of success|failure value transports, and is expected to pass a second Boost peer review and be submitted for C++ standardisation as the lowest level of an overall framework as proposed by: - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0650r0.pdf C++ Monadic interface - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0323r2.pdf A proposal to add a utility class to represent expected object (Revision 4) The idea is that result/outcome are the extremely lightweight struct-like success|failure value transports suitable for usage in public APIs, whereas expected is the much richer variant-like monadic success|failure value transports, and everything participates together under P0650R0. Outcome is a pure header only library with no dependencies. It works best with C++ 17 and Concepts enabled, but can work with C++ 14 on these compilers or better: - clang 4.0 (5.0 required for Windows) - GCC 7 (VS2017 Update 3 RTM is supposed to work too according to Microsoft, my thanks to them for swiftly fixing the several ICEs I reported) Github: https://github.com/ned14/outcome Docs (highly incomplete): https://ned14.github.io/outcome/ Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 4

Boost 1.65.0 Beta 1
by Marshall Clow 31 Jul '17

31 Jul '17

Boost release 1.65.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/> The SHA256 checksums are as follows: d54d29568c4e4933cbfe40a292b6cb84a7f68121e34f6a83f7d0f7c652b6b2d8 boost_1_65_0_beta1.7z 092676557513e992347d30dd0cd058fb8af2a401e5da4f4413f5b577852d726b boost_1_65_0_beta1.tar.bz2 31fa3c807e2205e18f7d5c74f77f540677f7b0937af1e37f595c137e1e87bf84 boost_1_65_0_beta1.tar.gz 83c8d8b76fa9591572226a1a49fd191d76db3011b52b907cbbc8d37d46213bd2 boost_1_65_0_beta1.zip Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

6 8

[Boost] file transfer
by vikram.smvdu 31 Jul '17

31 Jul '17

I recently started learning asio. Documentation is very awesome. I am planing to make a server where there is a file base. And client can login or connect and access the file.. is this possible. I am unable to send data from client to server.. server can sent but vise versa is not implemented by me.. i am trying.. if any body can point me a direction.. it will be much helpful Thank you Regards V Sent from Samsung Mobile

2 1

[BB++] 5 minutes long documentary
by Phil Bouchard 31 Jul '17

31 Jul '17

Like I promised, here's a 5 minutes long documentary on BB++: https://youtu.be/vXmddU_FS30 Regards, -Phil

2 3

CMake and Boost Build tests
by Edward Diener 31 Jul '17

31 Jul '17

Following John Maddock's appeal for practical solutions related to the move to CMake, I would like to know what the CMake equivalent is to the Boost Build unit test functionality. In other words what do I write for CMake in order to do a Boost Build compile, compile-fail, link, link-fail, run, and run-fail unit tests ? Does CMake have an equivalent to the Boost Build alias rule ? or the Boost Build project rule ? The great majority of the Boost libraries are header-only libraries where Boost Build is used to run the unit tests and, optionally, Boost Build is used to build the documentation using a quickbook, boostbook, doxygen toolset to generate html and pdf files. While I realize that building a Boost library, and making that built library available to end-users via CMake, has been the focus of most of the discussion so far regarding CMake and Boost, I am assuming the move to CMake also means that running unit tests and building docs where applicable must also be done through CMake. If I am wrong about this then I personally will be only too happy to continue using Boost Build to do these things.

14 47

[GitHub] Can boostorg/do-not-use be safely deleted?
by Louis Dionne 31 Jul '17

31 Jul '17

We have this repository: https://github.com/boostorg/do-not-use. The description says Permissions experiments; will disappear without notice. I'd like to confirm that this can safely be removed before I go do it. Louis -- View this message in context: http://boost.2283326.n4.nabble.com/GitHub-Can-boostorg-do-not-use-be-safely… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 4

Dependency report
by Peter Dimov 31 Jul '17

31 Jul '17

I haven't run one of these in a while, so here it is. http://pdimov.com/tmp/report-develop-6db78a0a6/module-overview.html http://pdimov.com/tmp/report-develop-6db78a0a6/module-levels.html http://pdimov.com/tmp/report-develop-6db78a0a6/module-weights.html We have one "supermodule" at level 5 and another at level 13.

7 33

Boost tests with cmake
by paul 30 Jul '17

30 Jul '17

Hi, So, I have made a small demo setting up the tests with cmake, here: https://github.com/pfultz2/boost-cmake-demo/tree/bcm-test-demo This builds and tests the libraries for Boost.System, so it includes: * assert * config * core * predef * static_assert * system * winapi There are no tests for winapi right now, because I don't have a windows machine to test on(but I suppose I could've tested with mingw). This uses the BCM modules to provide common functionality for building and tests. All the tests are setup to run through CTest, and some targets are provided for building the tests. A `tests` target will build(but not run) all the tests. The `check` target will build and run all tests. Since we do want to filter tests by library, all tests are added with the label of the project name(which can be filtered with `ctest -L <label>`). Furthermore there are targets `tests-<project-name>` and `check-<project- name>` that will build and test a single project respectively. So if we are only interested in the tests for `boost_assert` we can run: cmake --build . --target check-boost_assert And this will build and test `boost_assert`. Any feedback will be useful as we move forward on adding the rest of the tests to cmake. Paul

7 20

boost::asio::async_read loops infinite with zero byte of received data
by Shailendra kumar 30 Jul '17

30 Jul '17

Hi, I am new to this community, hope I am not breaking any rule by this mail. I am facing some issue using asio async_read . Please help. I am sharing the link of the question shared at stackoverflow. https://stackoverflow.com/q/45358908/5649379 Please help Thanks Shailendra kumar

2 1

How to resolve connection via route in proxy server?
by jupiter 30 Jul '17

30 Jul '17

Hi, I can use boost to query and to resolve TCP connection from a remote server which has a public IP address: boost::asio::ip::tcp::resolver::query query(host, port); resolver.async_resolve(query, boost::bind(&ConnectionClient::handleResolve, this, boost::asio::placeholders::error, boost::asio::placeholders::iterator)); But how can I connect to the remote server which does not have a public IP address, I have to connect it via route from a proxy server public IP address? Thank you. Kind regards.

1 0

Re: [boost] Boost tests with cmake
by Rene Rivera 29 Jul '17

29 Jul '17

Accidentally replied to the wrong target.. Putting it back on dev list.. On Fri, Jul 28, 2017 at 11:27 PM, P F <pfultz2(a)yahoo.com> wrote: > > On Jul 28, 2017, at 11:22 PM, Rene Rivera <grafikrobot(a)gmail.com> wrote: > > On Fri, Jul 28, 2017 at 11:01 PM, P F <pfultz2(a)yahoo.com> wrote: > >> >> > On Jul 28, 2017, at 7:25 PM, Rene Rivera via Boost < >> boost(a)lists.boost.org> wrote: >> > >> > The predef script is incorrect. This < >> > https://github.com/pfultz2/boost-cmake-demo/blob/bcm-test- >> demo/libs/predef/test/CMakeLists.txt#L25> >> > is not equivalent to the original < >> > https://github.com/pfultz2/boost-cmake-demo/blob/bcm-test- >> demo/libs/predef/test/build.jam#L60>. >> > As the "-DCHECK_VALUE=true" is not passed to compiler in response to the >> > evaluation of '"BOOST_COMP_CLANG > 0.0.0" "BOOST_OS_LINUX == 0"'. It >> needs >> > to try to compile and run one of the programs from here < >> > https://github.com/pfultz2/boost-cmake-demo/tree/bcm-test- >> demo/libs/predef/tools/check>. >> > The test is verifying that both this < >> > https://github.com/pfultz2/boost-cmake-demo/blob/bcm-test- >> demo/libs/predef/tools/check/predef.jam> >> > and this < >> > https://github.com/pfultz2/boost-cmake-demo/blob/bcm-test- >> demo/libs/predef/tools/check/predef_check.h> >> > work as expected. For cmake you would need still need to test the >> latter, >> > still. >> >> Yes, I need to add a custom function `predef_check` in cmake to support >> this, > > > Right. > > >> although it would be best to do the detection directly in cmake rather >> than through the running the tool > > > Not sure what you mean by that. > > > Because when cross compiling you can’t always run the executable, and > using a host compiler seems it would be give different results than the > target compiler. However, a preprocessor expression can be evaluated > through cmake’s try compile, which will safely work with cross compiling. > Perhaps this is what bjam’s rule does already. > Sorry.. I misspoke. They are compile checks, not run checks. If the compile succeeds (of one of the "predef_check_cc_as_*.*") it needs to add the "-DCHECK_VALUE=true" to the compile and run of "check_value.cpp". But the test data in this case would also need to change if you are going to use a try-compile target. As the b2 code parses out those strings and reformulates them as a -DCHECK=.. compile option. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[concurrent] Fast, lock-based queue implementation
by David Stone 29 Jul '17

29 Jul '17

I have written a new concurrent queue that has a focus on high throughput. You can check it out here: https://github.com/davidstone/concurrent-queue Some highlights of this queue: * The bulk interface is faster than other queues for many common load patterns * Almost any element type is supported with very few requirements * Supports any number of producers * Supports any number of consumers (although it works best with only one) * Can dynamically grow and shrink in memory as needed * The interface allows for very little undefined behavior: for the most part, as long as your special member functions like move constructors do not reference the queue you are inserting into, you are fine * Interface based on the pattern of moving values in and returning values via return, rather than other queues which use reference output parameters * Header-only * Design should be fairly straightforward to verify for correctness * Compiles warning free with a very high warning level on gcc and clang * Does not have any errors under ubsan, asan, or tsan I would like to submit this for inclusion in Boost if people find it interesting and useful, but first I would like to get some feedback on the design, implementation, documentation, tests, etc. I have tested this exact version on Gentoo Linux under clang 4.0 and gcc 6.3.0. I will be testing out Visual Studio 2015 and 2017 in the near future to ensure there have not been any regressions. I have run fundamentally the same queue on Visual Studio 2012 (no longer supported due to C++14 features), Visual Studio 2015 (Windows Server 2008 R2, Windows Server 2012), gcc 4.9.1 (Red Hat 6 under developer toolset 3), gcc 4.9.2 (Red Hat 7), and clang 3.9.0 (Red Hat 7) for several years now with no issues, so it is a fairly mature design.

2 4

Documentation snapshot not cycling
by Joaquin M López Muñoz 28 Jul '17

28 Jul '17

Hi, Looks like the documentation snapshot for develop http://www.boost.org/doc/libs/develop/ was last updated five days ago. Any chance this can be given a rebuild? Thank you, Joaquín M López Muñoz

3 3

[optional] Suggestion for adding an optional_number class
by Viktor Sehr 28 Jul '17

28 Jul '17

I'd like to make a suggestion for adding an optional class for number types, called optional_number, where the max value of the number type is utilized as the uninitalized value. Differences compared to std::optional<int, float, enum etc>: *- No size overhead from the wrapped type* - Theoretically faster (althrough in practice probably negilble) - Can be assigned to any value except the max value - Operator-> is removed as it does not make sense for an integer Notes: - Throws if assigned the numeric_limits<T>::max - Also works with enums, using the underlying_type - The operator bool conversion is missing in the prototype implementation Attaching a prototype implementation (currently for C++14). /Viktor

5 8

Proposal for moving Boost to CMake
by David Sankel 27 Jul '17

27 Jul '17

Howdy all, This is a request for comments on a possible path for migrating Boost's build system to CMake. I am not speaking for the Boost Program Committee here, but I plan on bringing this up with them after getting feedback. The motivation is simple. CMake is currently the dominant player in the area of open-source, cross-platform, C++ build-systems. I make this claim based on Google trends graphs and discussions with others at the conferences I attend (CppCon, C++Now, and ISO C++ meetings). If we make Boost buildable and usable out-of-the-box with CMake, we would significantly lower the barriers to entry for both Boost users and new Boost developers. Boost serves the greater C++ community and making Boost more accessible would be of great utility. * To ease the migration path, both Boost.Build (the current jam-based build system) and CMake will be supported for a time. * Boost sources would provide a compatible, drop-in replacement for the 'FindBoost' module that is distributed with CMake. A CMake-based application could point to it and, instead of using the system Boost libraries, Boost targets would be built from source as part of the user build. * The built Boost **binaries** would also provide a compatible, drop-in replacement for the 'FindBoost' module distributed with CMake. The behavior is similar to the previous bullet, except the built binaries would be used instead of the source code. * The style of the 'CMakeLists.txt' files would follow current best practice. We'd resist the temptation to write macros which replace the core CMake functions. There would be repetition in the files, to be sure, but I think we should avoid attempting to innovate CMake. I've seen this fail on many occasions and would like to keep our goal focused, at this point, on migrating Boost to CMake. In the future we could revisit this. * There would be a list of CMake guidelines that we'd use. * Boost libraries should be buildable in isolation and use 'find_package(Boost...)' to discover their Boost dependencies. * We would work with CMake towards eventually taking over maintenance of the FindBoost module distributed with CMake. I see this progressing with several milestones. 1. Release of a CMake-buildable Boost and the CMake conventions. In this stage each Boost library can be built in isolation or with the entire distribution and all the 'FindBoost' functionality mentioned above would be incorporated. 2. The unit tests for all Boost libraries are incorporated into CTest (the CMake unit test orchestration tools). 3. The Boost infrastructure is modified to use CTest for unit testing. 4. Unit testing functionality is removed from Boost.Build. 5. Boost.Build is removed. Although there are many other great ideas floating around (e.g. modularization of Boost, Boost-Classic, and Boost2), I'd like to keep this focused on CMakification of Boost because I think it is something that would have big impact and is small enough to be doable. One question that is going to come up is "who is going to do all this work?". Once we decide on a direction, I don't foresee a problem making this happen. Between volunteers, the importance this project has for companies, and the Steering Committee reserves, we should have the resources necessary. Another concern is that some authors may resist. Authors have a lot of leeway when it comes to how they maintain their libraries, what conventions they use, and backwards compatibility concerns. However, there are some things that authors need to conform to, such as our current Boost.Build build and testing infrastructure. I liken this to the development of a city: building developers can make their buildings however they want, but the streets, which control transit between buildings, are centrally regulated. Thanks for your consideration. -- David Sankel

29 140