- Boost - lists.preview.boost.org

[atom]
by Christian Henning 04 Jun '14

04 Jun '14

There two compiler errors ( both x86 and x64 ) when building the current master. c:\boost\boost/atomic/detail/ops_msvc_x86.hpp(860) : error C2065: 'order' : undeclared identifier c:\boost\boost/asio/detail/impl/socket_ops.ipp(534) : error C2065: 'SO_UPDATE_CONNECT_CONTEXT' : undeclared identifier I'm using Visual Studio 2013 on Window. The complete output ( x86 release ) is here: http://pastebin.com/raw.php?i=KgnJgWGQ Regards, Christian

2 2

[Modularization] Levels classification
by Vicente J. Botet Escriba 04 Jun '14

04 Jun '14

Hi, could we add a page listing the modules by levels following this rule * A module is in Level 0 if it doesn't depends on other modules * A module is in Level 1 if it depends only on modules at level 0 * A module is in Level N+1 if it depends only on modules at level N or lower levels We have now the following modules that satisfy the rule Moduler levels Level 0 : Config Predef Preprocessor Level 1 : Assert Static Assert Level 2 : Core Level 3 : Utility (After moving string_ref out (???), moving iterator to Core and generator_iterator to Iterator Peter, could you update the Dependency report? Could your report assign a level following this rule and show the modules with an assigned level? Best, Vicente

2 3

[multiprecision] General/design query about which conversions should be implicit/explicit
by John Maddock 04 Jun '14

04 Jun '14

Folks, I have an open bug report https://svn.boost.org/trac/boost/ticket/10082 that requests that conversions from floating point to rational multiprecision-types be made implicit (currently they're explicit). Now on the one hand the bug report is correct: these are non-lossy conversions, so there's no harm in them being implicit. However, it still sort of feels wrong to me, the only arguments against I can come up with are: 1) An implicit conversion lets you assign values such as 0.1 to a rational (which actually leads to 3602879701896397/36028797018963968 not 1/10), where as making the conversion explicit at least forces you to use a cast (or an explicit construction). 2) Floating point values can result in arbitrarily large integer parts to the rational, effectively running the machine out of memory. Arguably the converting constructor should guard against that, though frankly exactly how is less clear :-( Does anyone else have any strong views or insights into this? Thanks in advance, John.

8 8

[GSoC][MPL11] Post C++Now update
by Louis Dionne 04 Jun '14

04 Jun '14

Dear Boost, A lot happened during the past week in Aspen; the goal of this message is to summarize insights, changes and feedback received wrt MPL11. The slides of the presentation are available at [1]. The second part of the presentation is especially relevant to get an overview of the designs considered so far. Merging the MPL and Fusion -------------------------- After discussing the issue several times during the week, I (and others) think it might be possible to merge Fusion and the MPL into a single library. I am currently trying to write a library that does that. Since this constitutes a large reorientation, I created a new repository which is available at [2]. Those with interest should consider subscribing to the repository to be updated as I make progress. Iterator-free design -------------------- I was a bit anxious that people would complain about this, but the contrary happened. Nobody complained and some people expressed support. This design aspect will stay as-is. Request for guinea pigs ----------------------- I am looking for people with hardcore C++1y metaprogramming needs who will be willing to test the library I come up with (MPL11 or MPL + Fusion merge). I also need to see use cases for the library, so please reply even if you are not willing to test. Roadmap ------- Finish exploring the design space. If it turns out that we can merge the MPL and Fusion, then I'll be working on that for a while. If I find that this is not possible or not a good idea, I'll go back to my initial GSoC planning. In both cases, I hope to have a library in the incubator by the end of the summer. Also, this new roadmap is approved by my mentor. Feel free to reply with questions and/or comments. Regards, Louis [1]: http://ldionne.com/mpl11-cppnow-2014 [2]: http://github.com/ldionne/hana

15 34

[master] Building boost 1.56 - only 4 libs are built
by Christian Henning 04 Jun '14

04 Jun '14

When I execute the following command usually all libs are built: bjam -j8 --toolset=msvc --without-mpi variant=debug link=static runtime-link=shared define=_CRT_NONSTDC_NO_DEPRECATE define=_CRT_SECURE_NO_DEPRECATE define=_SCL_SECURE_NO_DEPRECATE define=BOOST_REGEX_MATCH_EXTRA stage > log_x86_debug.txt But on the current master only three libs are built or copied into my stage folder. libboost_container-vc120-mt-gd-1_56.lib libboost_context-vc120-mt-gd-1_56.lib libboost_exception-vc120-mt-gd-1_56.lib libboost_prg_exec_monitor-vc120-mt-gd-1_56.lib Is my command incorrect? I have been using it for many years. Regards, Christian

4 5

mpl/test/set_c.cpp mystery
by Peter Dimov 04 Jun '14

04 Jun '14

mpl/test/set_c.cpp has been failing for all my toolsets (in both master and develop) with the same error, In file included from ..\..\../boost/mpl/set/aux_/begin_end_impl.hpp:19:0, from ..\..\../boost/mpl/set/set0.hpp:29, from ..\..\../boost/mpl/set/set0_c.hpp:18, from ..\..\../boost/mpl/set/set10_c.hpp:19, from ..\..\../boost/mpl/set/set20_c.hpp:19, from ..\..\../boost/mpl/set_c.hpp:36, from set_c.cpp:14: ..\..\../boost/mpl/set/aux_/iterator.hpp:57:1: error: no type named `base` in `struct boost::mpl::set0_c<bool>` The regression report is all green though, so it was a bit of a mystery. Turned out that I needed to run "b2 headers". So there is an MPL header that b2 misses, although I don't have time at the moment to identify which one. But I decided to report the experience anyway, in case someone runs into the same problem. :-)

1 0

[quickbook] Need some help.
by Andrzej Krzemienski 04 Jun '14

04 Jun '14

Hi, Could someone help me with quickbook format? How can I nest the [section] elements so that this nesting is reflected in the table of contents and html files? I have 2 levels of nesting of element [section]: [section A] [section AA] [endsect] [section AB] [endsect] [endsect] When generatin the html docs , sections AA and AB end up in the same html file. How can I change it? (So that they land in two different files) If it is possible, can I control it by section? Regards, &rzej

3 2

status/expected_results.xml must go!
by Beman Dawes 04 Jun '14

04 Jun '14

In a discussion on the Steering Committee mailing list, Robert Ramey wrote: > I'm still having a problem with a newer library which only supports a more recent version > of C++ such as C++11. Our testing system doesn't permit me to say "don't test this compilers > which don't support C++11". With our current system, anyone who looks at test results will > get failures for compilers which don't support the version his library requires. This is incorrect, > and misleading to potential users of the library, and discourages authors from submitting > libraries which depend on modern C++ features. Also, it wastes a lot of testing time generating > this bogus information. I would ask that the powers that be try to convince the maintainers of > the boost testing setup to address this. The current way we markup expected failures is via boost-root/status/expected_results.xml. That creates two problems: * It is a maintenance nightmare as more and more libraries are added to Boost. This is library-specific information and so should be part of each module, not the super-project. * As Robert points out, we shouldn't even be running tests that are bound to fail anyhow. It would seem that each library needs to be able to tell bjam/b2 to skip certain tests, or even all tests, under certain conditions. As Marshall Clow has been pointing out, we desperately need someone to take over the regression test reporting maintenance, and redesign it to meet our current needs. --Beman

2 2

Unmerged changes in MPL
by Peter Dimov 04 Jun '14

04 Jun '14

The following commits are only in mpl:develop but not in mpl:master: C:\Projects\boost-git\boost\libs\mpl>git log master..develop commit f976861e13f0bb37dd6380c02ccc0d42140daebe Author: Paul <pfultz2(a)yahoo.com> Date: Fri May 16 02:38:50 2014 -0400 Add test for constexpr conversion operator commit ed58434c88ac03816fa0d232c679d551987b42a9 Author: Paul <pfultz2(a)yahoo.com> Date: Sun Dec 29 05:46:32 2013 -0500 Add constexpr to conversion operator for bool integral constants commit 1f482c4fa1d8fc66dc34776b04414f660cc66e76 Author: Paul <pfultz2(a)yahoo.com> Date: Sat Dec 28 23:29:09 2013 -0500 Add constexpr to conversion operator for integral constants What needs to be done with them? Release or revert?

3 2

[predef] Version 1.1 (Boost 1.56)
by Rene Rivera 04 Jun '14

04 Jun '14

FYI.. I've merged over the develop 1.1 version of Predef to master for general use. This should resolve the request from Beman to get this done ASAP :-) Changes for this release include: * Addition of `BOOST_PLAT_*` platform definitions for MinGW and Windows platform variants. * Detection of ARM architecture for Windows compilers to target mobile devices of WIndows 8. * Improved ARM detection for 64 bit ARM. * Added detection of iOS an an operating system. * Improved detection of endianess on some platforms. * Addition of exclusive plus emulated definitions for platform and compiler detection. The big change for this version is the restructuring of the definitions to avoid duplicate definitions in one category. That is, only one `BOOST_OS_*`, `BOOST_COMP_*`, and `BOOST_PLAT_*` variant will be detected (except for sub-categories). -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

Proposal: Boost.Core
by Peter Dimov 04 Jun '14

04 Jun '14

I propose the creation of a new module, Boost.Core, a repository of Boost core utilities. The criteria for inclusion into this module would be that the utility component is (a) simple, (b) used by other Boost libraries, (c) does not depend on any headers outside of Core and Config (and perhaps Assert). Its primary purpose would be to break dependencies. It will not serve as a repository of "this might be useful". Based on the interest so far, I volunteer myself, Glen Fernandes and Andrey Semashev as maintainers. The following utilities are immediate candidates for migration into the new module: - addressof - enable_if - boost/pointee.hpp - boost/indirect_reference.hpp - boost/type.hpp In addition, the following can be duplicated inside to reduce dependencies: - mpl::if_, if_c, eval_if - detail/is_incrementable.hpp - remove_cv and so on.

10 51

[Modularization] Moving boost/detail/scoped_enum_emulation.hpp out of Detail
by Vicente J. Botet Escriba 04 Jun '14

04 Jun '14

Hi, |<boost/detail/scoped_enum_emulation.hpp> is a workaround for non C++11|. What about moving it to Config or Core? Vicente

2 3

Report on Primary dependencies for
by Vicente J. Botet Escriba 04 Jun '14

04 Jun '14

Hi, Thanks Peter for providing this dependency report. There is an issue on this report http://www.pdimov.com/tmp/report/thread.html Primary dependencies for thread *unknown* <http://www.pdimov.com/tmp/report/*unknown*.html> |<boost/thread/executors/executor_wrapper.hpp>| * from |<boost/thread/executors/scheduled_executor.hpp>| |<boost/thread/queues/sync_timed_queue.hpp>| * from |<boost/thread/executors/scheduled_executor.hpp>| These files are all inside Boost.Thread. I have just remove two direct dependencies Optional and MPL that were not really necessary. Best, Vicente

2 2

Convert library review manager result
by Edward Diener 03 Jun '14

03 Jun '14

This is my analysis of the 'convert' library review and the result of whether the convert library should be accepted into Boost. Please read the entire analysis to understand my reasoning before reading the result. I would like to thank all of those who took part in the review and made comments. This includes Julian Gonggrip, Rob Stewart, Andrzej Krzemienski, Matus Chochlik, Jeroen Habraken, Erik Nelson, Hartmut Kaiser, Joel De Guzman, Thijs (M.A.) van den Berg, Roland Bock, Gavin Lambert, feverzsj, Paul Bristow, and alex. If I have missed anybody I do apologize. All comments were taken into account and all comments were intelligent and to the point. Naturally I would also like to than Vladimir Batov for patiently answering all comments and explaining and defending his library and his design decisions. For the most part I am going to focus on general issues rather than on the individuals who made them. Documentation issues: The documentation was too focused on explaining the library as it differed from lexical_cast. Vladimir Batov explained why this is so but I also agree that the documentation can be better by simply focusing on what the library provides in terms of functionality. Comments also mentioned that the current converters are not documented as well as the could be, and some commenters reflected that knowledge of how a particular converter works, including possible failures using that converter, is also needed despite the common library interface. The documentation did not provide enough information about the use of locales in the library. The reference section was very limited with not enough explanation. A reference built from doxygen comments in the source files would be better. A better explanation or example in the documentation for writing one's own converter was suggested. Although the Performance section in the documentation was fairly lengthy some commenters wanted to know why some things could not be tested. Others wanted more information about how convert performance compared to other convert-like implementations. In general I think most reviewers found the documentation adequate for understanding how to use the library but lacking in completeness. Vladimir Batov reflected that if the library were accepted into Boost he would then create more complete documentation and the above issues could be addressed. Implementation issues: As in most reviews most commenters did not look very deeply into the actual code but were happy to know how to use the library, and this is understandable for a review. There were a few pertinent comments however and I am just going to enumerate them. All macros should be prefix with BOOST_. My own addition to that is that all macros should be prefixed with BOOST_CONVERT_ to avoid any conflicts with other libraries. There should be a jamfile for running the tests. Also some full-blown examples of using the library in a simple program, along with the appropriate jamfile, would be helpful. Source code should contain spaces, not tabs. This is an easily fixed minor issue. As mentioned before doxygen comments in the public source are the usual Boost way of doing things. The main header file should be convert.hpp instead of api.h. Some includes were missing from the printf converter. Design issues: In the design of the library is where we have the most varying views. The major issue in discussing the design of the library for those who felt it was inadequate were the comments that using the library was too complicated, that the central function for invoking a conversion should be simpler to use. While all suggestions were well-argued I felt that a number of these differences were merely syntactical issues rather than issues that made the functionality easier to use. The main interface for using the library is: convert<output_type>::from(input_value, converter) Vladimir Batov had asserted during the review that this could be simplified further by removing the need for the 'from::' part of the signature which would make the syntax simpler. Some reviewers did not like the name 'convert' and offered substitutions, others wanted the default value, currently specified as '.value_or(default)', to be specified as a direct input parameter, others wanted the converter itself which is an input parameter to be specified via another syntax. All of these are too me syntactical issues and no resolution could possibly please everybody but it is understandable that different reviewers have different syntactical preferences. More to the point were some changes in actual functionality. The three most important involved the return value, type requirements for the output type, and the use of a default converter. Considering each in its turn: 1) The return value is some form of 'optional', with the idea of using boost::optional if it meets all the requirements needed by the 'convert' library. A number of people wanted the actual value returned without having to append .value() to the convert signature to get it. They were also concerned with the performance overhead of having to create an optional value as the immediate return value. It was also suggested that while the current convert syntax might be fine, some alternatives directly returning the value, for those who like maximum simplicity, might be possible. 2) The type requirements for the output type are default constructible and copy constructible. A number of reviewers felt that if a non-const reference were passed to the convert function as an output instance then the type requirements would not have to be met. However the type requirements of some of the underlying converters might be affected by this and the documentation does explain how to work around the default constructible requirement, but I still do understand the reasoning behind this possibility. 3) A number of reviewers wanted a default converter to be used but there was hardly an agreement on what this default converter should be, some favoring lexical_cast, others favoring stringstream, and no doubt others might want something else. Nevertheless providing a default constructor interface, possible with a macro defined a compile time, seems like it might be doable. There was further discussion about the actual callable signature for a plug-in converter. Here there was less contention about the interface, which is currently a callable with a signature of: template<typename TypeOut, typename TypeIn> bool operator()(TypeIn const& value_in, TypeOut& result_out) const; Vladimir Batov did suggest some possible alternatives and there was a discussion with a number of reviewers about alternatives that seem implementable. This also ties into the concern of some reviewers that it should be straightforward to create one's own converters with minimum restrictions on the input and output types, as well as minimum performance overhead. Votes: A number of reviewers made comments but offered no final vote on whether or not the conversion library should be accepted into Boost. Some reviewers offered a Yes vote, but heavily based on changes they want to see. I will attempt to tabulate them here: YES votes: Christopher Kormanyos Paul Bristow Julian Gonggrip ( with some reservations which Vladimir Batove has met or may easily meet ) Andrzej Krzemienski Matus Chochlik YES, conditionally but otherwise NO if conditions are not met, which the current version does not meet] Jeroen Habraken Roland Bock alex NO Rob Stewart Final Decision: Among those who voted YES conditionally but otherwise NO there was a general consensus including Vladimir Batov, the 'convert' library creator, and some of the others that an attempt could be made to satisfy some of the conditions for simplification and/or functionality they desired. My decision, based on the votes as I interpret them, is that the convert library is ACCEPTED into Boost. While a perfect design is impossible I believe that the design of the library is an adequate starting point for a general-purpose conversion framework and that the design could change incrementally enough to satisfy some of the qualms of those who might not find it as initially useful as they have hoped, while still maintaining the central framework which Vladimir Batov has created. Furthermore I believe that others have reflected that a general-purpose conversion library would be very useful if it were flexible enough to support plug-in converters created by programmers, as the 'convert' library does. I realize that what is essentially a 5 to 4 vote in favor of the library is not an overwhelming consensus by any means but I feel that 3 of those 4 NO votes are predicated on wishes for possible changes to the 'convert' library which may yet be met before the library gets officially added to an upcoming Boost release. Since I have accepted the library based on the votes and my interpretation of the issues I would like to encourage those who feel that some alternate designs could be implemented as part of the 'convert' library to work with Vladimir Batov, if he is agreeable, to add those alternatives to the library. Nonetheless it is his library and he would be the final arbiter of any decisions reached. I would like to encourage the view, however, that the current design is what has been voted in by others as the 'convert' library so that any changes made to it as it is added to Boost should be incremental additions which minimally change what others see as an acceptable library.

4 5

boost::python support for python 3.4 enums
by Erik H 03 Jun '14

03 Jun '14

Hi all, Is anyone else interested in boost::python support for Python 3.4 style enums <https://docs.python.org/3/library/enum.html>? Python 3.4 enums have been backported to every Python version you could want, so I use them a lot in my Python code these days. I have many boost::python enum_ instances that have always been problematic due to the complete won't-fix brokenness of boost::python enum nesting (you can nest a boost::python enum in a class's scope, but the type() of the enum is ***WRONG*** because it somehow manages to forget its proper scope, which causes immense and unending pain when something needs to make a new enum_ instance in Python from code that I don't control). So, I am implementing a boost::python::intenum along the lines of boost::python::enum_, but with proper scope nesting provided that I can figure out how to do it. I'll be back with code soon. Best, Erik

1 0

Boost 1.56 timeframe
by Jonathan Jones 03 Jun '14

03 Jun '14

Hi folks, Is there a timeframe for the release of Boost 1.56? The current 1.56 page simply states that it's at an early stage in its release cycle (but it has said this for months). http://www.boost.org/users/history/version_1_56_0.html I'm asking in the context of Visual Studio 2013. Boost 1.55 is known to have issues with VS2013, which I'm hoping the 1.56 release would address. Sincerely, Jonathan Jones

7 10

Pervasive dependency upon mpl::bool_
by Peter Dimov 03 Jun '14

03 Jun '14

We have lots of headers that depend on mpl::bool_ in order to define traits classes as deriving from mpl::true_ or mpl::false_. I don't think that this dependency is necessary even for MPL interoperability. The normal way of template<class T> struct trait { BOOST_STATIC_CONSTANT( bool, value = false ); }; should work just as well. I think. As one example, there's detail/blank.hpp, which starts with #include "boost/mpl/bool.hpp" #include "boost/type_traits/is_empty.hpp" #include "boost/type_traits/is_pod.hpp" #include "boost/type_traits/is_stateless.hpp" It doesn't really need these includes. namespace boost { struct blank { }; // type traits specializations // template <> struct is_pod< blank > : mpl::true_ { }; This can be written as template<class T> struct is_pod; template<> struct is_pod< blank > { BOOST_STATIC_CONSTANT( bool, value = true ); }; which requires no includes. The problem is, though, that all type traits do derive from mpl::true_ or mpl::false_, and I'm not sure if rewriting blank.hpp in the above manner is actually correct. Should type trait specializations always derive from mpl::true_ or mpl::false_? Will I break something if I specialize a type trait to not derive from mpl::bool_? Or is a nested ::value enough? Who knows. :-) But really, if a header, whose entire purpose is to define an empty struct, can't get by without including type traits and mpl, we've lost the dependency game before it's even started.

7 22

[atomic] Help understanding consume order
by Andrey Semashev 03 Jun '14

03 Jun '14

Hi, I'm reviewing (again) Boost.Atomic code and struggling to understand the consume order and in particular what should it mean on architectures other than DEC Alpha. I read the explanation here: http://en.cppreference.com/w/cpp/atomic/memory_order but the point eludes me. Take ARM for example and the explanation in the "Release-Consume ordering" section. The producer thread allocates the string and stores the pointer with a release operation, so that the pointer, the string contents and the 'data' integer are visible to other threads. Now the consumer thread reads the pointer with a consume operation. According to the explanation in the article, on ARM the consume operation need not issue any specific fences to be able to use the pointer and the string body. In that case, the consume operation becomes equivalent to relaxed (plus prohibiting compiler optimizations). But is there a guarantee that the string body will be visible to the consumer? Shouldn't the consume operation be promoted to acquire instead? I guess, that's the ultimate question: how should consume ordering be handled on conventional architectures?

3 6

[iterator][range] Old breaking change in develop.
by Daniel James 02 Jun '14

02 Jun '14

Hi, There's an old breaking change to iterator_facade in iterator's develop branch, which is apparently needed for iterator_range (although it seems to have got by without it): https://github.com/boostorg/iterator/commit/512298cb5cf4b7ca5e8000f41bb39bd… Please can someone who cares about it decide if that's something that should be released, and if they think it is, take responsibility for it (documentation, release notes, support, etc.). If not, I think it should be reverted. Daniel

3 3

github issue
by Christian Henning 02 Jun '14

02 Jun '14

Hi all, I'm cloning boost but something went wrong when trying to get the python submodule. I'm not sure if the problem is related to boost, github, my git setup, or maybe my internet connectivity. Here is a snippet from the console output: ... Cloning into 'libs/proto'... remote: Reusing existing pack: 4233, done. remote: Total 4233 (delta 0), reused 0 (delta 0) Receiving objects: 100% (4233/4233), 1.89 MiB | 893.00 KiB/s, done. Resolving deltas: 100% (2062/2062), done. Checking connectivity... done. Cloning into 'libs/ptr_container'... remote: Reusing existing pack: 2887, done. remote: Total 2887 (delta 0), reused 0 (delta 0)Receiving objects: 98% (2830/28 87), 2.36 MiB | 924.00 KiB/s Receiving objects: 100% (2887/2887), 2.78 MiB | 924.00 KiB/s, done. Resolving deltas: 100% (1839/1839), done. Checking connectivity... done. Cloning into 'libs/python'... ssh: github.com: no address associated with name fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Clone of 'git@github.com:boostorg/python.git' into submodule path 'libs/python' failed I'm using git version 1.9.0.msysgit.0 on Windows 7. Anyone know what's going? Thanks, Christian

2 2

Re: [boost] [modularization] proposal and poll
by Niall Douglas 01 Jun '14

01 Jun '14

I'll top post my reply as Robert's valuable post didn't make it onto the list again. Please do read his reply below, it's worth reading as Robert is one of the lead thinkers on the steering committee about this. Robert, I think you are under a misapprehension about what I mean by "fork". By a fork, I mean forking just a very small part of existing Boost, namely whatever minimal support is necessary to start from scratch with a new *empty* set of C++ 14 only Boost libraries. I don't propose to port *any* of the legacy Boost libraries whatsoever, they stay where there are. If their maintainers - or a sponsor - are willing to do: 1. Make their library entirely C++ 11/14 STL based, porting only the absolute minimum of old Boost. 2. C++ Modules ready i.e. restructured and reorganised to properly fit C++ Modules. 3. Contribute any general utility code to the core utilities library, not duplicating any functionality there, and in a form suitable for entering the C++ 17 STL. 4. Meet the raised unit test and CI soak test and sanitiser/valgrind requirements. Then they have a good chance of their library appearing highly ranked in the list of C++ 14 Boost libraries, where that ranking is generated by a set of clang AST analysers. Does this make sense? I am specifically advocating a structural break, a clean start. I think working on a fresh, empty Boost will get people to volunteer to give up family time to write Boost code again. Right now with the present situation there are few incentives to sacrifice family time. That needs to change for Boost to survive, else the continuing slow decline will continue. Niall On 29 May 2014 at 17:52, Robert Ramey wrote: > > > On Thursday, May 29, 2014 2:17:11 PM UTC-7, Niall Douglas wrote: > > > > On 29 May 2014 at 22:22, Julian Gonggrijp wrote: > > > > If a fork of Boost becomes necessary later this year, > > > LOL - this is not going to be necessary. > > > > The hard part isn't what to do. > > > LOL - not for you! > > > > The hard part is gaining community > > buy in when "their" code gets broken by the necessary changes. I have > > concluded it isn't possible, > > > LOL - you've underestimated the amount of work to convert > everything to C++11 by a factor of .... 1000 ? Basically it's > a whole rewrite of 100 modules. And the gain is ....? > > hence me proposing a fork where such > > "radical" changes won't upset anyone. > > > Your free to do this. And you should if you really believe that > it would benefit anyone or anything. > > > I think it may be easier for the steering committee to justify any > > > decision on this proposal, > > > The steering committee doesn't have anything to decide here. The > "Proposal" is: > > 1. Reduction of dependencies between Boost libraries. > > It's not clear what action is being proposed - but I'm pretty sure > the steering committee won't be doing it. > > 2. Simple but effective automation of dependency handling. > > I'm pretty sure the steering committee won't be doing this either. > If anyone believes that they can implement "simple and > effective" automation of dependency handling - just go ahead > and do it and let us see it. > > > > Decisive and immediate action on this is vital if Boost is to > > survive. I vote yes to both, ASAP. > > > > LOL - There is wide agreement that boost has growing pains and > will have to evolve. But I haven't seen any proposals for > "Decisive and Immediate" which would do anything but make > things worse. > > And since you've got me started - Here is what boost needs go to the next > step. > > a) Make the review process more effective and efficient - we're taking real > practical action to address this now. The jury is still out regarding the > effectiveness of our efforts - but we ARE actually doing something. > > b) Recognize that we now have 4 variants of C++ - C++98, C++03, C++11 > and C++14. Our infrastructure doesn't explicitly address this. The > following > needs to change > 1) for each library we need to explicitly state somewhere what > version(s) of C++ the > library is meant to support. > 2) support running of tests and builds for only those platforms. > > I've suggested that we enhance B2 to address this. So far > no one has responded to this suggestion > > Note that this would have he effect of encouraging libraries to evolve > to later versions of C++ with minimal disruption to both library > authors and users. > > c) Decouple Deployment of Boost Libraries from the Certification > of boost libraries. Beman has noted that what he would like to > see is something like CYGWIN whereby one specifies what one > want's and somehow automagically you get that plush what you > need. I realize that this is more or less what is being suggested here. > But no one has presented credible proposal for making it it happen. > > This would also address the issue of "old" libraries. As they > fall into disuse are become superseded by newer ones, the can > still be in boost even though their frequency of deployment drops off. > > The above constitutes a real path forward. This is what Boost > needs for the next 15 years. > > Robert Ramey > -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

4 4

throw or boost::throw_exception?
by Andrzej Krzemienski 01 Jun '14

01 Jun '14

Hi, I am not sure where, but I am convinced that I have read that it is recommended for Boost libraries that they not use naked throw expressions but instead call boost::throw_exception. Is that true? If so, it enforces a dependency of more than half Boost libraries on Boost.Exception. Am I right? If so, is this the right recommendation in the context of the discussion about reducing dependencies between the libraries? Regards, &rzej

8 22

[next_generation][modularization] Is the community interested in creating a smooth path to a modularized Boost
by Vicente J. Botet Escriba 31 May '14

31 May '14

Hi, I've started a new thread in response to Julian Gonggrijp post [modularization] proposal and poll, as I would not answer directly to his questions. I'm sure that almost all of us want a modularized Boost. What does this means? It is up to us to define it: * what the user can request as a delivered package for its own needs? * what the authors must state explicitly? * what must be tested/checked? The main problem is how to achieve it ensuring backward compatibility . I'm persuaded that we need a new Boost repository (or whatever we want to name it) that would include libraries that respect the modularization constraints we could define. My question is who would be interested in starting the next generation of a modularized Boost that starts from a repository of ZERO modularized libraries. The idea is to add to the current Boost libraries new ones that respect the modular rules and adapt the current ones to be defined on top of the modularized ones. At the end we could deprecate the old ones. In order to do that we need of course to add new interfaces (a new namespace mod_boost or whatever is preferred) and so the user would need to move to these interfaces smoothly. Before starting we need to * Define the constraints of a modularized system - no cyclic dependencies, .... * Define the tools that can be used to support the modular system - which build system(s), - which test system(s), - which regression system(s), - which doc system(s), ... * Define the rules - who could be able allowed to do the refactoring? - Should the refactoring be reviewed to ensure a improvement on the quality of Boost? - who maintains what?, ... * Setup the infrastructure ( build system, test system, regression system, doc system, ... ) Only then we could * Start from libraries that don't depend on any other library (with possible refactoring) and adaptation of the refactored libraries from which these modular libraries have been extracted. * Deliver them * Build a second layer of libraries that depend only on first layer * Deliver them * ... Of course, in order to check that the rules and tools are the appropriated ones we will need to experiment with some examples. I recognize that this would mean a lot of work, however I hope that the final result would satisfy better the community expectations and the quality of Boost libraries. Best, Vicente

2 2

[gil] Status of gil:: extension:: io
by William Gallafent 31 May '14

31 May '14

Hi all, I noticed that a major update to gil's io extension was accepted into boost in 2011[1]. It disappeared from its own development repository in 2013[2]. It isn't present in boost 1.55[3]. It is present in boost's subversion trunk[4]. There's currently no mention of it in the release notice for boost 1.56[5]. Am I right to say that its presence in boost trunk means that it /will/ be included in boost 1.56, it just needs to be added to the documentation? If so, then great! Is there anything which needs to be fixed before it's ready to ship? I didn't see anything obvious when I searched this list's archives for “[gil]”. Thanks in particular to Christian, everybody else that worked on the io_new extension, and those that reviewed it! It's very useful to me, and I'm looking forward to its integration into boost so I don't have to add it myself from boost trunk :) [1] http://lists.boost.org/boost-announce/2011/01/0281.php [2] https://code.google.com/p/gil-contributions/source/detail?r=795 [3] http://svn.boost.org/svn/boost/tags/release/Boost_1_55_0/boost/gil/extensio… (this is the “old” io extension) [4] http://svn.boost.org/svn/boost/trunk/boost/gil/extension/io/ (and this is the “new” one) [5] http://www.boost.org/users/history/version_1_56_0.html -- Bill Gallafent.

3 6

[optional] Top level bad_optional_access.hpp
by Andrey Semashev 31 May '14

31 May '14

Hi, I've noticed a new top-level header boost/bad_optional_access.hpp. It wasn't present in 1.55, so it is a recent development. AFAIK, top level headers are discouraged, all library specific headers, except the "include all" header, should be inside the library directory. Am I correct? If so, could this header be moved inside boost/optional?

2 2