- Boost - lists.preview.boost.org

[core] Breaking bugfix in scoped enums
by Andrey Semashev 07 Jun '14

07 Jun '14

Hi, While creating tests for scoped enums emulation I've fixed a bug which resulted in the enums being convertible to int. This is a potentially breaking change, the code like this will now not compile: BOOST_SCOPED_ENUM_DECLARE_BEGIN(color) { red, green, blue } BOOST_SCOPED_ENUM_DECLARE_END(color) void foo(boost::native_type<color>::type col); color col = color::blue; foo(col); The call to foo() should be done like this: foo(boost::native_value(col)); Previously, the conversion was implicit.

4 7

[pimpl] Some comments
by Andrzej Krzemienski 07 Jun '14

07 Jun '14

Hi Vladimir, My congratulations on the success of Boost.Convert. But I can see you will not have much time to celebrate it, next library waiting in the queue. I wanted to share some of my thoughts on Boost.Pimpl library. This is by no means a review. I am not sure if I will have time to do a decent one. I only skipped through the documentation so my understanding is superficial, but I noticed some things that raise my immediate objection. Boost.Pimpl has been around for a while now, and I remember I was using it at some point in my work, although it didn't have the nice documentation format at that time. [1] The main point in using pimpl idiom (at least my) is to avoid header inclusion, which may grow compilation time too much (at the expense of certain run-time cost). But in order to use Boost.Pimpl I do need to include a header file, which in turn includes more header files. This is arguably less headers that in normal non-pimpl implementation, but it is more than if I used a raw pointer. And this is what I finally did in my work: switched to raw pointers for implementing piml in order to get the build perform faster. (I didn't measure the improvement though.) [2] Boost.Pimpl is good for everyone: people who like value semantics get the value semantic interface, and people who like shated_ptr's get shared_ptr semantics. Call me selfish or biased, but I believe using shared_ptr's should be banned (at least in 90% of the cases where it is currently being used), and the fact that you advertise it first in the docs makes me uneasy. It looks from the docs that 'pointer_semantics' implements something like a flyweight. This is so against value semantics. One of the expectations of types returned by value is that changing the original does no affect the copy: T a = c; T b = c; zap(a); assert(b==c && a!=b); Although the author of class Book knows that it is implemented with pointer_semantics, the users of the class are likely not to know it, and since Book doesn't look like a pointer, they will be expecting value semantics, and will be severely punished. [3] The docs advertize the definition of operator== as a member function. This is against a typical recommendation that it should be a free function in order to avoid asymmetrical behavior in certain cases. Does your library allow the definition of a non-member operator==? If so, I would encourage you to reflect that in the docs. [4] This page: http://yet-another-user.github.io/boost.pimpl/the_boost_pimpl_library/pimpl… says "The advantage of the 'built-in' *Book::null()* [...] is that it makes possible an implementation of strongly exception-safe constructors, the copy constructor" There seems to be something wrong with this statement. How can a strong (commit-or-rollback) guarantee apply to constructors? If an exception is thrown from constructor the object is never created or accessible, so no-one cares about its state (as long as it doesn't leak). Or did you mean the no-throw guarantee? But the latter looks like an anti pattern. What is the value in concealing the exception (and information it carries) and instead produce null objects, which cannot be used? While I find the value_semantics interface useful, I am strongly against even offering the pointer_semantics interface. I am not sure if I have succeeded in explaining why. Regards, &rzej

8 15

[modularization] Extracting lexical_cast from conversion
by Vicente J. Botet Escriba 07 Jun '14

07 Jun '14

Conversion depends on Math and Range due to lexical_cast. /math/ <http://www.pdimov.com/tmp/report-6d1f271/math.html> |<boost/math/special_functions/fpclassify.hpp>| * from |<boost/lexical_cast.hpp>| |<boost/math/special_functions/sign.hpp>| * from |<boost/lexical_cast.hpp>| /range/ <http://www.pdimov.com/tmp/report-6d1f271/range.html> |<boost/range/iterator_range_core.hpp>| * from |<boost/lexical_cast.hpp>| |Extracting LexicalCast allows to break these cycle|s Conversion -> Math -> Conversion -> Range -> Conversion Best, Vicente P.S. This dependencies have been introduced lately while trying to make the implementation more efficient.

5 4

HTTP SERVER 2 Question!
by zyf01234＠gmail.com 07 Jun '14

07 Jun '14

I'm trying to test the HTTP SERVER 2 of the boost.asio samples. some question comes to my mind,so can anyone give me a hand? Q1. The code acceptor_(io_service_pool_.get_io_service()) means get one io_service from the pool , but to this application only one acceptor is created and one io_service is running? Q2 It takes about 25% of the CPU occupancy rate , this is caused by the Q1? zyf01234(a)gmail.com

2 1

Running Tests with Timeouts
by Axel Ismirlian 07 Jun '14

07 Jun '14

Hello everyone, Is there a way to run all of the tests on all of the test suites with timeouts? Occasionally, I need to run all of the tests on all of the test suites, so I leave them overnight only to find out the next morning that one of them hung forever. Sincerely, -Axel

2 1

Review manager for Boost QVM?
by Emil Dotchevski 06 Jun '14

06 Jun '14

Hello, The QVM library has been in the review queue for a some time waiting for a review manager. I've been receiving occasional support requests from random people, and I remember there was at least some initial interest when I proposed the library years ago, but nobody has volunteered to be the review manager yet. This is a library for working with (Q)uaternions and statically-sized (V)ectors and (M)atrices, it's the kind of high level library that is useful to video game programers working with 3D graphics. It's unique (AFAIK) feature is that it uses a type traits system that allows all library functions to operate on 3rd-party types, making it easy to integrate types from different other math libraries into a single type-safe environment. It also has functions that can map vectors as matrices or matrix rows/columns as vectors, or even present mutable transposed view to any matrix, all without creating temporary objects. The documentation and source code can be found here: http://www.revergestudios.com/boost-qvm/ Anyone takers? :) -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

5 8

[modularization] About sub-sub-module path/names..
by Rene Rivera 06 Jun '14

06 Jun '14

This past week I spent time to update my documentation tools to the latest to get the Predef release done. As part of that I created my own mini-Boost that is both minimal to just getting Quickbook compiled and I can control when updating <https://github.com/grafikrobot/boost-doctools/tree/develop>. One frustrating aspect of building that repo was that I made various accidents in adding submodules because of naming. And a key one was the structure for the numeric submodules <https://github.com/boostorg/boost/tree/develop/libs/numeric>. So I have one basic question: Is there a *good* reason why numeric submodules need to have their own subdirectory? It would seem to me much easier to understand if all submodules where flat and on the libs/* dir. The uniformity would also remove various special cases I saw in build and testing code files. For example some special code in Boost/Jamroot <https://github.com/boostorg/boost/blob/develop/Jamroot#L149>. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

3 2

[core] Detach demangle() from type_info
by Andrey Semashev 06 Jun '14

06 Jun '14

Hi Peter, I can see you already extracted demangle() to boost/core. Great, thanks! However I'd prefer it to be detached from type_info. This tool would be useful with different kinds of symbols, like function and variable names, not just type_info. So it better accept a string as an argument and not type_info. demangled_name() should probably be in core/typeinfo.hpp. And regarding typeinfo.hpp. Aren't we duplicating Boost.TypeIndex here? PS: I was also planning to create pull requests to other libraries to use demangle from Core. These are Exception, Units, TypeIndex and Log, AFAIK. Do you plan to do this? If not, I could.

3 5

[Modularization] unique_ptr (interprocess/smart_ptr) and SmartPtr
by Vicente J. Botet Escriba 06 Jun '14

06 Jun '14

Hi, what about moving|boost/interprocess/smart_ptr/* to module SmartPtr?| || |||| |||Vicente| ||

3 3

Re: [boost] [pimpl] No documentation for pointer semant
by Dave Gomboc 06 Jun '14

06 Jun '14

[Paul A Bristow]: > I unhappy with a review rigid policy that nothing can be changed during a > review. It isn't always helpful. > > We never accept anything without requiring some changes? > > Can we instead now use git's easy branches to specify a fixed 'master' branch, > but allow the author to update a 'develop' branch as the review develops? [Edward Diener]: > I believe that changes can be made to a reviewed library during a review > as long as the 'master' branch does not change. After all we want all > reviewers to be looking at the same 'master' branch as the code to be > reviewed. But if the developer wants to make changes to other branches > during the review I think this should be allowed. May I suggest that either the library author or the review manager ought to, near the commencement of the review, identify a specific version to be reviewed? This is quite distinct from identifying a branch name for a conventional branch such as master that is expected to change frequently even over a two-week period. A specific checkout is typically identified by a SHA: a branch name such as 'master' is primarily just an alias to the SHA to which it currently resolves. Then again, Boost is relatively new to using git, so perhaps a new branch name can be introduced to refer specifically to the review version. The review manager could, at the commencement of the review, specify the checkout instructions using a specific SHA. For example, for Boost.Pimpl, the manager would provide Source: https://github.com/yet-another-user/boost.pimpl, SHA 59a5c0d or, in command-line-ese, git clone https://github.com/yet-another-user/boost.pimpl git reset --hard 59a5c0d As I mentioned, not everybody may be comfortable working directly with SHAs immediately, so the library author and/or the review manager may wish to introduce a specific label for the purpose of easing identifying the review version. If one of them (or somebody else with write access to the repository) continues from the above two commands with the further git checkout -b boost_review git push origin boost_review then it still becomes possible for the contents of the master branch to change (which, generally speaking, is highly desirable) without disrupting the review process. In this case, the instructions provided by the manager could be: Source: https://github.com/yet-another-user/boost.pimpl, branch boost_review or, in command-line-ese, git clone https://github.com/yet-another-user/boost.pimpl git checkout boost_review which should be more palatable to the large group of people migrating from Subversion. Naturally, in this case it is imperative that boost_review not itself be pushed to further during the review. However, there is no reason the library author from continuing with these commands: git checkout -b boost_review_fixes git push -u origin boost_review_fixes at which point, fixes to items that come up in the review can be pushed onto that branch, and those people who specifically want to take a look at the fixes can easily do so. The above said, the long-term simplicity of specifying a SHA directly instead of a branch at all is not only that one doesn't have to go and make a bunch of new branch names in order to continue development, but even more importantly, one can't push to a SHA to change its contents --because modifying a commit after the fact modifies its SHA also -- so everyone is sure to get the same version of the content being reviewed. Dave

3 2

[optional] Is detail/none_t.hpp needed?
by Andrey Semashev 06 Jun '14

06 Jun '14

Hi, I've noticed there's boost/detail/none_t.hpp header, which basically reflects boost/none_t.hpp. Worse even, it would cause a conflict if both these headers are included. A search didn't reveal any users of this header. Since it's a detail, could this header be removed?

2 5

cstdint.hpp dependency not working?
by John Maddock 06 Jun '14

06 Jun '14

With the recent changes, when building any file that depends on cstdint.hpp I see: link.hardlink ..\..\..\boost\cstdint.hpp Hardlink created for ..\..\..\boost\cstdint.hpp <<===>> ..\include\boost\cstdint.hpp link.hardlink ..\..\..\boost\cstdint.hpp Hardlink created for ..\..\..\boost\cstdint.hpp <<===>> ..\..\integer\include\boost\cstdint.hpp And this happens for every build - even though everything is up to date. Any ideas? Thanks, John.

4 5

A few more critical dependencies
by Peter Dimov 06 Jun '14

06 Jun '14

At present, we have three dependencies that we can easily cut and doing so will be very beneficial: 1. type_traits now depends on utility only because utility: <boost/utility/declval.hpp> from <boost/type_traits/common_type.hpp> from <boost/type_traits/detail/common_type_imp.hpp> from <boost/type_traits/is_copy_constructible.hpp> from <boost/type_traits/is_nothrow_move_assignable.hpp> from <boost/type_traits/is_nothrow_move_constructible.hpp> Since declval.hpp itself depends on type_traits (add_rvalue_reference), it can't go to core and the most logical place for it is type_traits itself. 2. utility depends on iterator because iterator: <boost/iterator.hpp> from <boost/operators.hpp> <boost/iterator/iterator_facade.hpp> from <boost/generator_iterator.hpp> boost/iterator.hpp can be moved to core in all its former glory (and probably replaced by a one-liner, using std::iterator.) generator_iterator.hpp perhaps needs to be moved to iterator. 3. mpl depends on detail because detail: <boost/detail/endian.hpp> from <boost/mpl/string.hpp> <boost/detail/lightweight_test.hpp> from <boost/mpl/aux_/test.hpp> That last one is just because lightweight_test.hpp hasn't been removed from Detail yet; let me know if I should do that. boost/detail/endian.hpp is just a forwarding header that includes <boost/predef/detail/endian_compat.h>. We should move it to Predef. Comments? Objections?

6 20

[core] scoped enum authoring
by Vicente J. Botet Escriba 06 Jun '14

06 Jun '14

Hi Andrey. In the Boost.Core documentation I see: "Thanks to Andrey Semashev for pointing out that emulation through a namespace could not be used within classes. Helpful comments and suggestions were also made by Kjell Elster, Phil Endecott, Joel Falcou, Mathias Gaunard, Felipe Magno de Almeida, Matt Calabrese, Vicente Botet, and Daniel James." The authors of this file are Beman (for the class based version) and me (for the namespace based). As the documentation has been mainly extracted from the file I would appreciate if both Beman and I are added as authors. BTW, there is no deprecation for the Beman version, there are just different advantages and liabilities. I suspect that the same is applied to the other component of the Boost.Core module Thanks for working on this. Vicente

5 6

[admin][thread] Request for write access fro Niall
by Vicente J. Botet Escriba 06 Jun '14

06 Jun '14

Hi, I would like to give write access to Niall Douglas for Boost.Thread. He has some new features to add and also he could help me to fix some obscure bugs and to maintain the windows port. Can some of the administrators add him as member of the Boost.Thread maintainers team? Thanks, Vicente

2 1

[Config] Announce: New Build time configuration feature
by John Maddock 06 Jun '14

06 Jun '14

In develop only is a new feature to make configuring targets at build time easier, from the docs: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There are times when you want to control whether a build target gets built or not, based on what features the compiler supports. For example, suppose you have a test file "test_constexpr_128.cpp" which requires three key features in order to build: * The constexpr keyword as detected by BOOST_NO_CXX11_CONSTEXPR. * User defined literals, as detected by BOOST_NO_CXX11_USER_DEFINED_LITERALS. * The __int128 data type, as detected by BOOST_HAS_INT128. Clearly we know that if these features are not supported by the compiler, then there's simply no point in even trying to build the test program. The main advantages being: * Faster compile times - build configuration uses lightweight tests the results of which are also cached. * Less noise in build output - there's no reason to be faced with pages of template instantiation backtrace if we know the file can never compile anyway. * Less noise in the online test results - the test will show up as blank, rather than as a fail in the online test matrix. * A better experience for end users building all of Boost, if those libraries which can not be built for the current target compiler are simply skipped, rather than generating pages of error output. Returning to our example, the test case is probably executed in it's Jamfile via the "run" rule: run test_constexpr_128.cpp ; We now need to make this target conditional on the necessary features. We can do that by first importing the necessary rule at the start of the Jamfile: import path-to-config-lib/checks/config : requires ; Assuming that the test case is in the usual directory: libs/yourlib/test then the import rule will actually be: import ../../config/checks/config : requires ; Then add a "requires" rule invocation to the requirements section of the target: run test_constexpr_128.cpp : : : #requirements: [ requires cxx11_constexpr cxx11_user_defined_literals int128 ] ; Notice that multiple arguments can be added to the requires rule, and that these are always the same as the Boost.Config macro name, but in lower case and with the boost_no_ or boost_has_ prefix removed. When building the above example, you will see at the start of the build process the results of the configuration, for example GCC in C++11 mode gives: - Boost.Config Feature Check: int128 : yes - Boost.Config Feature Check: cxx11_constexpr : yes - Boost.Config Feature Check: cxx11_user_defined_literals : yes That's all there is to this handy feature, should at any time you be unsure of the feature-test names you can pass to the "requires" rule, then search for the Boost.Config macro of interest in libs/config/checks/Jamfiles.v2, and the name of the feature check will follow it. And finally, this feature is built around the Boost.Build built in rule check-target-builds which can be used to perform more generalized build-time feature testing. The checks in this library are provided as a convenient shorthand without the need for you to write the test cases yourself. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Let me know what you think, and enjoy :-) John.

4 6

[Modularization] Breaking dependecy Range -> Algorithm
by Vicente J. Botet Escriba 06 Jun '14

06 Jun '14

Range depends on Algorithm due to these files /algorithm/ <http://www.pdimov.com/tmp/report-6d1f271/algorithm.html> |<boost/algorithm/string/config.hpp>| * from |<boost/range/detail/collection_traits.hpp>| * from |<boost/range/detail/collection_traits_detail.hpp>| |<boost/algorithm/string/yes_no_type.hpp>| * from |<boost/range/detail/collection_traits_detail.hpp>| * | boost/algorithm/string/yes_no_type.hpp could be moved to TypeTraits|| boost/algorithm/string/config.hpp| could be moved to Config Best, Vicente

1 0

GitHub is slow
by Andrey Semashev 05 Jun '14

05 Jun '14

For the couple past days I'm seeing problems working with GitHub. I can't complete the full update of Boost repository multiple times in a row: ... Fetching submodule libs/regex ssh: connect to host github.com port 22: Connection timed out fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Fetching submodule libs/scope_exit Fetching submodule libs/serialization ssh: connect to host github.com port 22: Connection timed out fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Fetching submodule libs/signals Fetching submodule libs/signals2 Fetching submodule libs/smart_ptr Fetching submodule libs/spirit Fetching submodule libs/statechart Fetching submodule libs/static_assert Fetching submodule libs/sync Fetching submodule libs/system Fetching submodule libs/test Fetching submodule libs/thread Fetching submodule libs/throw_exception Fetching submodule libs/timer ssh: connect to host github.com port 22: Connection timed out fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Fetching submodule libs/tokenizer Fetching submodule libs/tr1 Fetching submodule libs/tti ssh: connect to host github.com port 22: Connection timed out fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Fetching submodule libs/tuple ... Don't mind the particular libraries, they are different every time. I'm also seeing occasional timeouts in web interface. I've seen these problems from two different places, so it's not my local connection. Is anyone seeing this too?

1 0

Boost.Pimpl upcoming formal review (June 15 - June 24)
by Glen Fernandes 05 Jun '14

05 Jun '14

The formal review period of Boost.Pimpl by Vladimir Batov is scheduled to begin later this month, on June 15th, and will conclude on June 24th, and we welcome your participation. Vladimir's library provides a mechanism for implementing this popular, and still very relevant, idiom. To borrow his words from the documentation: [quote] In the domain of commercial large-scale software development the following design principles come to the fore: - component-based, modular and API-centered design, - separation of concerns, - implementation hiding, - minimization of compilation and component dependencies, - consistent and recognizable deployment and implementation patterns, multi-platform support. The Pimpl idiom can help great deal achieving those goals. It is a simple yet robust programming technique to minimize coupling via the separation of public interface and private implementation and then implementation hiding. [/quote] Please feel encouraged to browse the source code, documentation, and tests, before the review commences. Any feedback you have prior to the review period is also very appreciated. Source: https://github.com/yet-another-user/boost.pimpl/ Documentation: http://yet-another-user.github.io/boost.pimpl/ Download: https://github.com/yet-another-user/boost.pimpl/archive/master.zip If you would like to submit a review earlier, please provide your thoughts on the following topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? As well as information on the following questions: - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? Best, Glen

1 0

[quickbook] Thank you Daniel James
by Rene Rivera 05 Jun '14

05 Jun '14

After being very surprised that I could build Predef documentation without errors by onyl updating to the latest develop version of Quickbook I had to thank Daniel James. Thank Daniel for the continued work on Quickbook. It's made my life much, much, easier! -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

8 12

Moving utility/declval.hpp to type_traits
by Peter Dimov 05 Jun '14

05 Jun '14

I was going to move utility/declval.hpp to type_traits, but type_traits has many unmerged changes. Since the contents of declval.hpp are currently the same in master and develop, replaying its history on top of type_traits:master and type_traits:develop should not affect any later merges, but still, I always prefer to do this when master and develop are identical, so thought I'd ask first. John?

2 2

[config] intel-linux with -fno-rtti doesn't set BOOST_NO_RTTI...
by Peter Dimov 05 Jun '14

05 Jun '14

... and BOOST_NO_TYPEID. I can see in the config_info output that __RTTI (without the option) is 1, so maybe the check belongs in common_edg.hpp.

1 0

[core] Move underlying_type to type_traits?
by Andrey Semashev 04 Jun '14

04 Jun '14

While documenting and cleaning up scoped_enum.hpp I factored out the underlying_type trait to a separate header. Mostly, because I didn't want to #include <type_traits> in scoped_enum.hpp. boost::underlying_type should be equivalent to std::underlying_type, except that it also supports emulated scoped enums. Perhaps boost/core/underlying_type.hpp should be moved to Boost.TypeTraits?

4 4

Looking for git help for Boost releases
by Marshall Clow 04 Jun '14

04 Jun '14

I’m trying to figure out tooling for making boost releases. One of the missing pieces that we had in SVN was “svn export”, which let you check out a particular branch/revision to a local folder, w/o any of the SVN infrastructure (such as .svn folders). It also let you set the line endings of the files, so I could make a release with Windows line endings on a non-windows computer. The command that I used was: svn export --non-interactive --native-eol XXX -r YYY, https://svn.boost.org/svn/boost/branches/release ZZZ where: XXX was line ending that I wanted (either CRLF for windows or LF for unix) YYY was the revision that I was interested in (usually HEAD) ZZZ was the destination for the export How can I do something like this for git? I’ve looked at “git archive”, and that’s something like what I want, but it doesn’t handle sub-projects. There are a few scripts around that claim to do “git archive over sub-projects”, but I haven’t found one that works with our set up, and none of them let you modify the line endings for (some of) the files as part of the process. Any ideas? Suggestions? Pointers? Thanks in advance. — Marshall

5 10

[Predef] Splitting a version number into components
by Arindam Mukherjee 04 Jun '14

04 Jun '14

Given some vendor version number, is there any macro in Predef to split it into major, minor and patch components? I noticed the macros BOOST_PREDEF_MAKE_* macros. What do these macros help achieve which BOOST_VERSION cannot? Thanks, Arindam

2 3

[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

Standalone boost::ignore_unused_variable_warning()
by Adam Wulkiewicz 31 May '14

31 May '14

Hi, The ignore_unused_variable_warning() tool is used in many libraries. Its "main" definition (probably the first one) is in concept_check.hpp in the namespace boost but functions of the same name and purpose are also defined in the internals of some libraries (GIL, Interval, Test, uBlas, Unordered), probably to not include the whole concept_check.hpp. So I propose to move this useful tool out of the concept_check.hpp to somewhere else. Since it was already defined in the namespace boost, not boost::detail, the right place would probably be: boost/utility/ignore.hpp or boost/utility/ignore_warning.hpp Furthermore I propose to add a few overloads becasue it's common that the compiler warns about a few variables in the same function, so instead of using N calls: boost::ignore_unused_variable_warning(x) boost::ignore_unused_variable_warning(y) boost::ignore_unused_variable_warning(z) we could use only one: boost::ignore_unused_variable_warning(x, y, z) which would be more convenient to use and read. If you were ok with the change, I'd be glad to hear some tips how to make it in one commit, i.e. to modify two modules at once - modify a file in ConceptCheck and add a file to Utility? And finally I'm considering adding similar tool for unused typedefs because some compilers (GCC4.8) warns about them and there are cases, e.g. when some part of code is shielded with some #ifdef, where they can't be commented out or removed. E.g. something like this would work, though I'm not sure if there is no better way, so I'm open to suggestion. struct empty_type {}; template <typename T1, typename T2 = empty_type, typename T3 = empty_type> struct ignore_unused_typedef_warning {}; int main() { typedef int T1; typedef int T2; ignore_unused_typedef_warning<T1, T2>(); } Regards, Adam

7 19

Re: [boost] [modularization] proposal and poll
by Peter Dimov 30 May '14

30 May '14

It didn't make it through. Please use http://www.pdimov.com/tmp/report.zip to download the report and http://www.pdimov.com/tmp/report/smart_ptr.html (say) to browse it. The version of boostdep I used to generate the report is attached and the generation procedure was as follows: mkdir ..\numeric boostdep.exe --list-modules > ..\modules.txt for /f %i in (..\modules.txt) do boostdep.exe --secondary --html %i > ..\%i.html The links in ..\numeric\*.html are broken because of the subdirectory, but I had no time to fix that. -----Original Message----- From: Peter Dimov Sent: Friday, May 30, 2014 23:37 To: boost(a)lists.boost.org Subject: Re: [boost] [modularization] proposal and poll Clickable HTML report for all modules, attached (if it makes it through).

1 0

Adding detection of [u]intptr_t to Boost.Config (moving it from cstdint.hpp)
by Glen Fernandes 30 May '14

30 May '14

Any objection to me doing this? It would, of course, be non-breaking to anyone currently consuming it from Boost.Integer's cstdint.hpp. Glen

5 12

Is this a MSVC bug?
by Andrzej Krzemienski 30 May '14

30 May '14

Hi, While tracking test failures in Boost.Optional library I discovered that the following program fires an assert in MS VC++ compiler (v. 10.0, 11.0, 12.0): #include <cassert> const int global_i = 0; struct TestingReferenceBinding { void operator=(const int& ii) { assert(&ii == &global_i); } void operator=(int&&) { } }; int main() { TestingReferenceBinding ttt; ttt = global_i; } Do you know if this a bug in VC++, or if that is supposed to be valid? Regards, &rzej

7 10

Anyone is interested in being review manager of ‘Application’?
by Renato Forti 30 May '14

30 May '14

Hi All, The proposed ‘Boost.Application’, needs a Review Manager. Anyone is interested? The Docs: http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html The Project: https://github.com/retf/Boost.Application

40 124

[utility][detail] Moving binary_search_test from utility to detail.
by Daniel James 30 May '14

30 May '14

Hi, I've created a couple of pull requests to move this test from utility to detail, as the header it's testing is in detail. I guess it's in utility because there weren't any detail unit tests when it was created. If there are no objections I'll merge them this weekend. https://github.com/boostorg/utility/pull/9 https://github.com/boostorg/detail/pull/2 Daniel

1 0

How do you read this list?
by Gennadiy Rozental 30 May '14

30 May '14

Hi, I am having real problem following boost list nowdays. The second time this year gmane stopped posting RSS feed updates (last time it did not post any updates for like two month) and it was not even updating web interface for like a week recently. Is there any other browser based alternative for reading and posting? Gennadiy

4 4

[smart_ptr][intrusive] boost::unique_ptr<>
by Adam Wulkiewicz 30 May '14

30 May '14

Hi, I remember that there was plans to release an "official" STD-conformant implementation of boost::unique_ptr<>. I found: http://boost.2283326.n4.nabble.com/unique-ptr-for-C-03-td4650231.html http://boost.2283326.n4.nabble.com/C-03-unique-ptr-emulation-td2658449.html Do someone know what's the outcome of this initiative? Regards, Adam

4 6

[test] Looking for co-developer/maintainer
by Gennadiy Rozental 29 May '14

29 May '14

Hi, I think this is somewhat overdue. It's obvious various forces pulling me in different direction won't allow me to continue to do this all by my own. I am still plan to contribute and maintain the library, but I do believe it can be served better if someone can volunteer to share the load with me. There are both maintenance and development tasks in pipe. I have in mind quite a few very interesting features we can extend Boost.Test with (aside from those already requested by users and waiting to be implemented). These include: MT testing support performance testing support Mocking library GUI/DE integration and more Short term though I need help pushing to the release features which are already implemented in trunk and waiting to be released. Major showstopper is absence of proper documentation for these. So one of the first things we'll need to do is to write one. We also need to improve unit testing and finally push this release though some form of boost review. I do not have any specific requirements for the applicant, aside from interest in the library and willingness to work with me. I do not mind several people helping out with documentation, but longer term I'd prefer not very large group of maintainers for the library. If you are interested please shoot me email off list to rogeeff at gmail. Regards, Gennadiy

14 49

[config][predef] Is it OK for boost.config to depend on boost.predef?
by Beman Dawes 29 May '14

29 May '14

There is a config pull request outstanding that includes <boost/predef.h>. If it was almost any library other than config, I'd apply this without a second thought. But Boost config is special in that if it breaks, virtually the whole of boost breaks. So it makes sense to be cautious about dependencies. Has there been any discussion about the relationship between Boost.config and Boost.predef? Even if we accept the patch, is <boost/predef.h> the right header? It just forwards: #include <boost/predef/language.h> #include <boost/predef/architecture.h> #include <boost/predef/compiler.h> #include <boost/predef/library.h> #include <boost/predef/os.h> #include <boost/predef/other.h> #include <boost/predef/platform.h> The rationale for the pull request is a need in other Boost libraries to detect Windows platform variants like BOOST_PLAT_WINDOWS_DESKTOP andBOOST_PLAT_WINDOWS_RUNTIME. Boost.Predef does a nice job of that. But the only header strictly needed is <boost/predef/platform.h>. So the desired effect can be achieved several ways: 1) #include <boost/predef.h> in the include/boost/config/platform/ headers. 2) #include <boost/predef/platform.h> in the include/boost/config/platform/ headers. 3) #include <boost/predef.h> in the files that actually use the desired macros. 4) #include <boost/predef/platform.h> in the files that actually use the desired macros. If I had been writing the code myself, I probably would have selected option (4). What do others think? --Beman

5 11

[utility][optional] boost::equal_pointees -- move it?
by Andrzej Krzemienski 29 May '14

29 May '14

Hi, I recently noticed that there is a plan to move everything out of Boost.Utility. Is that right? There is a small feature in there: http://www.boost.org/doc/libs/1_55_0/libs/utility/OptionalPointee.html (header <boost/utility/compare_pointees.hpp>, added along Boost.Optional. Should it be moved out of Utility to Boost.Optional also? If so, any hints on how I should preserve the backwards compatibility for its users? Regards, &rzej

1 0

Re: [boost] [config][predef] Is it OK for boost.config to depend on boost.predef?
by Rene Rivera 29 May '14

29 May '14

On Wed, May 28, 2014 at 12:45 PM, Robert Ramey < robertmacleranramey(a)gmail.com> wrote: > > The whole existence of boost predef was a huge surprise to me. > It was reviewed and accepted ;-) > Looking at the dates it seems its been in boost for a while. I perused > the documentation. I'm still not getting how this doesn't overlap with > config..hpp. I thought that config.hpp was designed to address the issue > of portability between platforms. > Boost Config is indeed designed to address portability between platforms. As a requirement of that design it also has to deal with detecting the different platforms it's trying to define feature/defect macros for. Detecting the platform is not a requirement for Config to work. And you can run the Config configure program to generate a set of portability feature/defect definitions without knowing about the platform. > So I would expect that a facility such as > > #include <boost/predef/platform/windows_desktop.h> > #include <boost/predef/platform/windows_runtime.h> > > would depend upon config.hpp rather than the other way around. > > And since config.hpp is designed to determine the platform automatically, > I'm very surpassed to see predef at all. > "config.hpp" has to partially determine the "platform" by need not by design. > Any additional information you want to submit would be interesting to see. > Predef's design is to *not* detect or define feature/defect macros. All it does is the detection of the platform (compiler, libraries, etc). With enough fine grained platform information one can use it to define know feature/defect macros. Predef defines a much larger superset of the Config platform defs <http://tinyurl.com/o68ovjz> in a consistent (and consistent to check) manner. Or more succinctly: * Predef detects the environment you are compiling in. * Config defines what is or isn't broken with that environment relative to the ideal/standard -conforming environment. HTH -- -- 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

[config] any macro to detect "Rvalue references for *this"?
by Andrzej Krzemienski 29 May '14

29 May '14

Hi, Is there a macro in Boost.Config that would help me test if a compiler supports a C++11 feature "Rvalue references for *this" ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm)? Regards, &rzej

3 11

Adding spirit::is_container to boost::traits
by Rodrigo Madera 28 May '14

28 May '14

Is there any intention of including is_container [1] into boost::traits? I find myself using that particular Spirit header, which could be useful if isolated into traits. Cheers, Madera [1] http://www.boost.org/doc/libs/1_55_0/libs/spirit/doc/html/spirit/advanced/c…

4 9

[interprocess] Is message_queue experiencing problems in 1.55?
by Joseph Van Riper 28 May '14

28 May '14

I'm embarrassed to ask this, but I don't see documentation to help me through a problem like this. I assume I'm doing something wrongly, since I assume someone would have seen something like this earlier. Note that I've boiled this down to the simplest reproducible problem... originally, I tried to simply make use of the message queue using the example code in the documentation, but I can't get past the compile error. I started removing code to find the problem, only to strip ... well ... all of it away. I also tried looking through trac to see if someone already reported this, but I didn't see anything (which doesn't necessarily mean anything, as I may have failed to properly search the thing). Steps to reproduce: 1. On VC++ 2013, create an empty command-line project. 2. At the top of the main .cpp file, add "#include <boost/interprocess/ipc/message_queue.hpp>" 3. Ensure the project can find the boost headers. 4. Compile. Expected result: A completely pointless, but compiled .exe is created. Actual result: Compile error: 1>------ Build started: Project: msgqueue_test, Configuration: Debug Win32 ------ 1> stdafx.cpp 1> msgqueue_test.cpp 1>c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\intrusive\detail\has_member_function_callable_with.hpp(200): error C2228: left of '.select_on_container_copy_construction' must have class/struct/union 1> type is 'boost::move_detail::add_rvalue_reference<U>::type' 1> c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\intrusive\detail\has_member_function_callable_with.hpp(276) : see reference to class template instantiation 'boost::container::container_detail::has_member_function_callable_with_select_on_container_copy_construction_impl<Fun,true,>' being compiled 1> with 1> [ 1> Fun=std::allocator<std::pair<const boost::interprocess::ipcdetail::sync_id *const ,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>>>> 1> ] 1> c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\container\allocator_traits.hpp(262) : see reference to class template instantiation 'boost::container::container_detail::has_member_function_callable_with_select_on_container_copy_construction<const Alloc,>' being compiled 1> with 1> [ 1> Alloc=std::allocator<std::pair<const boost::interprocess::ipcdetail::sync_id *const ,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>>>> 1> ] 1> c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\container\detail\tree.hpp(217) : see reference to class template instantiation 'boost::container::allocator_traits<A>' being compiled 1> with 1> [ 1> A=std::allocator<std::pair<const boost::interprocess::ipcdetail::sync_id *const ,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>>>> 1> ] 1> c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\container\detail\tree.hpp(246) : see reference to class template instantiation 'boost::container::container_detail::intrusive_rbtree_type<A,boost::container::container_detail::tree_value_compare<Key,std::pair<const Key,T>,Compare,boost::container::container_detail::select1st<std::pair<const Key,T>>>>' being compiled 1> with 1> [ 1> A=std::allocator<std::pair<const boost::interprocess::ipcdetail::sync_id *const ,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>>>> 1> , Key=const boost::interprocess::ipcdetail::sync_id * 1> , T=boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>> 1> , Compare=boost::interprocess::ipcdetail::sync_handles::address_less 1> ] 1> c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\container\map.hpp(83) : see reference to class template instantiation 'boost::container::container_detail::rbtree<Key,std::pair<const Key,T>,boost::container::container_detail::select1st<std::pair<const Key,T>>,Compare,Allocator>' being compiled 1> with 1> [ 1> Key=const boost::interprocess::ipcdetail::sync_id * 1> , T=boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>> 1> , Compare=boost::interprocess::ipcdetail::sync_handles::address_less 1> , Allocator=std::allocator<std::pair<const boost::interprocess::ipcdetail::sync_id *const ,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>>>> 1> ] 1> c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\interprocess\sync\windows\sync_utils.hpp(226) : see reference to class template instantiation 'boost::container::map<const boost::interprocess::ipcdetail::sync_id *,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<T>>,boost::interprocess::ipcdetail::sync_handles::address_less,std::allocator<std::pair<const Key,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<T>>>>>' being compiled 1> with 1> [ 1> T=std::pair<const boost::interprocess::ipcdetail::sync_id,void *> 1> , Key=const boost::interprocess::ipcdetail::sync_id * 1> ] ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

2 2

Is there any interest in a library for actor programming?
by Charousset, Dominik 28 May '14

28 May '14

Hi, is there any interest in a library for actor programming? The library we've developed is a C++11 open source library named "libcppa". It is currently released under LGPL2, but re-releasing the library under the boost license is not an issue. You'll find all important links and ressources either under http://libcppa.org or on the GitHub project page: https://github.com/Neverlord/libcppa, including a user manual as HTML or PDF. We've also submitted a paper to the C++Now conference. What is actor programming? For those of you who aren't yet familiar with the actor model: actors basically represent tasks or services that communicate via message passing. In libcppa, actors are very lightweight (you can spawn literally millions of them) and scheduled cooperatively using a thread pool (although actors are allowed to opt-out of the cooperative scheduling). Some of the main strengths of this programming paradigm are: (1) network transparency, (2) race conditions are avoided by design, (3) a strong failure model that enables developers to build reliable distributed systems, and (4) the actor model addresses both concurrency (multiple actors on one host) and distribution (any number of actors on any number of hosts). Here's the classical hello world example: ---------------------------------------------------------------------------------- #include <string> #include <iostream> #include "cppa/cppa.hpp" using namespace std; using namespace cppa; void mirror() { // wait for messages become ( // invoke this lambda expression if we receive a string on_arg_match >> [](const string& what) { // prints "Hello World!" via aout (thread-safe cout wrapper) aout << what << endl; // replies "!dlroW olleH" reply(string(what.rbegin(), what.rend())); // terminates this actor ('become' otherwise loops forever) self->quit(); } ); } void hello_world(const actor_ptr& buddy) { // send "Hello World!" to our buddy ... sync_send(buddy, "Hello World!").then( // ... and wait for a response on_arg_match >> [](const string& what) { // prints "!dlroW olleH" aout << what << endl; } ); } int main() { // create a new actor that calls 'mirror()' auto mirror_actor = spawn(mirror); // create another actor that calls 'hello_world(mirror_actor)' spawn(hello_world, mirror_actor); // wait until all other actors we have spawned are done await_all_others_done(); // run cleanup code before exiting main shutdown(); } ---------------------------------------------------------------------------------- A message is simply a tuple of values that is pattern matched at the receiver. For example, " on_arg_match >> [](const string& what) {...}" defines a message handler that is called whenever a tuple with one single string element arrives. "on_arg_match" simply defines a pattern that matches the signature of the given lambda. Please have a look at the examples folder on GitHub (https://github.com/Neverlord/libcppa/tree/master/examples) or at the user manual (http://neverlord.github.io/libcppa/manual/) if you want to see more examples. Best regards, Dominik Charousset

17 62

[foreach] Can should_copy_impl return type be simplified?
by Mostafa 28 May '14

28 May '14

I'm studying the implementation of foreach and I had a question about should_copy_impl. For reference, here's the overload that's vexing me: // If the collection is an array or is noncopyable, it must be an lvalue. // If the collection is a lightweight proxy, treat it as an rvalue // BUGBUG what about a noncopyable proxy? template<typename LValue, typename IsProxy> inline BOOST_DEDUCED_TYPENAME boost::enable_if<boost::mpl::or_<LValue, IsProxy>, IsProxy>::type * should_copy_impl(LValue *, IsProxy *, bool *) { return 0; } Why is enable_if needed? Can't the return type just be "IsProxy *"?

2 1

[Math] Rationale Behind Epsilon Values
by Axel Ismirlian 28 May '14

28 May '14

Hello, I am new to this mailing list, so its possible the format of my question may be off by a little. My team has been working on getting boost to run on PPC 64-LE. There are many tests in boost that rely on the machine epsilon value. Why was this value chosen to determine success or failure of a particular test knowing that it is hardware specific? More specifically, the Long Double type is very different on both platforms. However, by forcing the x86 Long Double epsilon value on the PPC machine we were able to get many of the previously failing tests to pass. This change was inspired by the fact that a similar fix was already in the code for Darwin platform, but the value that it returns for the Darwin platform is not the x86 value. Also the LDBL_MANT_DIG on both the Darwin platform and our platform (PPC 64-LE) are the same, and are equal to 106. How was the Long Double value on the Darwin platform determined? For reference, the actual code lies in boost/math/tools/precision.hpp. We were also wondering whether or not this was a valid solution to fixing the problem? Part of us feel this doesn't address the underlaying problem. Sincerely. -Axel

3 3

[convert] An approach that might actually work. :-)
by Vladimir Batov 28 May '14

28 May '14

To move forward in a coordinated way how about we create a working group (say, >= 5 people). Then we'd address convert-related issues in the order of importance. Public API first, converter API then, etc. (Or maybe some other design altogether). We'd focus on one thing at a time. Discuss it and then vote. The solution accepted by the majority wins, we document it and move forward to the next item of importance... without running in circles about the previous issues... unless we realize down the track that our solution is flawed somehow. That won't require any more of the time of the participants than it is now. I am happy to coordinate (whatever that might be), do implementation (to the best of my abilities), etc. Still, if anyone feels strongly about doing that "coordination" thing, step forward, no drama. Such collaborative approach would take subjectivity out and might bring new unexpected ideas, etc. That I think might actually work. Any one willing to sign up? Jeroen, Roland, Rob? What people think? Let me know if you feel like participating, contributing... If there is no appetite for that, it's still OK. -- View this message in context: http://boost.2283326.n4.nabble.com/convert-An-approach-that-might-actually-… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 3

Compiling without Long Double Support
by Axel Ismirlian 28 May '14

28 May '14

Hello, My team and I are working to make boost compatible with PPC 64-LE and we were wondering how to compile boost without long double support, so that in the mean time we can isolate other problems not related to floating point problems. Sincerely, -Axel

2 1

Top posting
by Brian Wood 27 May '14

27 May '14

Sorry to nag, but have noticed some top-posting here lately. Also some don't trim posts they are replying to when it would be possible. A few years ago I suggested trimming trailing white space from the source files. I don't know if anyone has done so, but I still recommend it. Boost is often cumbersome. Trimming this trailing stuff would be a step in the right direction. grep " $" * -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0

Boost review of the Convert library is ongoing
by Edward Diener 27 May '14

27 May '14

The review of the Convert library started Monday, May 12 and goes through Wednesday May 21. Many people may have missed the first announcement since the mailing lists were held back when the review started so I am announcing this again. The Convert library builds on the boost::lexical_cast original design and experience and takes those conversion/transformation-related ideas further. * to be applicable to a wider range of conversion-related use-cases, * to provide a more flexible, extendible and configurable type-conversion framework. The Convert library can be cloned from GitHub at https://github.com/yet-another-user/boost.convert. The library follows the modular-boost format. Just clone it to modular-boost/libs in the 'convert' subdirectory and run 'b2 headers' in order to create a link to its header file directory in the modular-boost/boost subdirectory. The library comes with documentation in its top-level index.html or doc/html/index.html file. You can also view the documentation online at http://yet-another-user.github.io/boost.convert/doc/html/index.html. The library is by Vladimir Batov and is a second reiteration with a greater focus of his library that was reviewed in the past. I am Edward Diener and I am again serving as the review manager of the library. If you have used lexical_cast or, like many C++ programmers, have used stringstream to do string-to-type, type-to-string conversions please look at this library. We need reviews of whatever point of view before a library can even be considered a Boost library. Comments, questions, and reviews will all be welcome for the library. Please try to sum up your review by answering these questions: What is your evaluation of the design? What is your evaluation of the implementation? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library? Did you try to use the library? With what compiler? Did you have any problems? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? And finally: Do you think the library should be accepted as a Boost library? As always whether you do or do not feel that the library should be accepted into Boost please specify any changes you would like to see for the library to be better in your estimation.

11 36

Convert library review period has ended
by Edward Diener 26 May '14

26 May '14

The review period for the Convert library of Vladimir Batov has ended. There is one more potential review, from Rob Stewart, by the end of today, as well as any response from Vladimir Batov, I am willing to consider as the review manager. I would like to thank all those who have participated in the review, as well as Vladimir Batov for patiently answering reviews and following up in discussions. I will be working on summing up the discussion and votes on whether or not Convert should be accepted into Boost, and will issue my final decision sometime by the end of this week ( by the end of Sunday June 1 US Eastern time at the latest ). Again thanks to all of those who participated in the review and its discussions. Edward Diener

1 0

Pushing a "Pull Request"
by Christian Henning 26 May '14

26 May '14

Hi all, I'm trying to push a pull request to github but I'm getting an error. I believe I'm the maintainer of the gil library so I should have the permissions. This is the pull request I'm trying to commit to gil's develop branch: git pull https://github.com/gallafent/gil tiff-cmyk After that I'm simply trying to git push but I get the following error: ERROR: Permission to boostorg/gil.git denied to chhenning. fatal: Could not read from remote repository. Could someone please help out? Thanks, Christian

4 4

Boost review of the 'convert' library starts tomorrow May 21.
by Edward Diener 26 May '14

26 May '14

The review of the Convert library starts tomorrow Monday, May 12 and goes through Wednesday May 21. The Convert library builds on the boost::lexical_cast original design and experience and takes those conversion/transformation-related ideas further. * to be applicable to a wider range of conversion-related use-cases, * to provide a more flexible, extendible and configurable type-conversion framework. The Convert library can be cloned from GitHub at https://github.com/yet-another-user/boost.convert. The library follows the modular-boost format. Just clone it to modular-boost/libs in the 'convert' subdirectory and run 'b2 headers' in order to create a link to its header file directory in the modular-boost/boost subdirectory. The library comes with documentation in its top-level index.html or doc/html/index.html file. The library is by Vladimir Batov and is a second reiteration with a greater focus of his library that was reviewed in the past. I am Edward Diener and I am again serving as the review manager of the library. Comments, questions, and reviews will all be welcome for the library. Please try to sum up your review by answering these questions: What is your evaluation of the design? What is your evaluation of the implementation? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library? Did you try to use the library? With what compiler? Did you have any problems? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? And finally: Do you think the library should be accepted as a Boost library? As always whether you do or do not feel that the library should be accepted into Boost please specify any changes you would like to see for the library to be better in your estimation.

4 10

Last weekend for review of the Convert library
by Edward Diener 25 May '14

25 May '14

This is the last weekend of the the review of the Convert library, which started Monday May 12 and goes through Sunday May 25. For those who have been to C++ Now please take a look at the library and review it. I am looking for at least a half dozen reviews before I can decide, based on the reviews, whether or not the library should be accepted into Boost. The Convert library builds on the boost::lexical_cast original design and experience and takes those conversion/transformation-related ideas further. * to be applicable to a wider range of conversion-related use-cases, * to provide a more flexible, extendible and configurable type-conversion framework. The Convert library can be cloned from GitHub at https://github.com/yet-another-user/boost.convert. The library follows the modular-boost format. Just clone it to modular-boost/libs in the 'convert' subdirectory and run 'b2 headers' in order to create a link to its header file directory in the modular-boost/boost subdirectory. The library comes with documentation in its top-level index.html or doc/html/index.html file. You can also view the documentation online at http://yet-another-user.github.io/boost.convert/doc/html/index.html. The library is by Vladimir Batov and is a second reiteration with a greater focus of his library that was reviewed in the past. I am Edward Diener and I am again serving as the review manager of the library. If you have used lexical_cast or, like many C++ programmers, have used stringstream to do string-to-type, type-to-string conversions please look at this library. We need reviews of whatever point of view before a library can even be considered a Boost library. Comments, questions, and reviews will all be welcome for the library. Please try to sum up your review by answering these questions: What is your evaluation of the design? What is your evaluation of the implementation? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library? Did you try to use the library? With what compiler? Did you have any problems? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? And finally: Do you think the library should be accepted as a Boost library? As always whether you do or do not feel that the library should be accepted into Boost please specify any changes you would like to see for the library to be better in your estimation.

2 1

Boost.Rational: improve operator+= and operator-= for param_type
by Morwenn Ed 25 May '14

25 May '14

It is possible to provide an implementation of operator+=(param_type) and operator-=(param_type) for the rational class that could be more efficient than the current one: template <typename IntType> inline rational<IntType>& rational<IntType>::operator+= (param_type i) { num += i * den; return *this; }The operation should never denormalize the fraction. Actually, the same optimization is already used in operator++ and operator--. It allows not to convert the param_type into a rational before adding it. Morwenn.

1 0

[review] convert
by Matus Chochlik 25 May '14

25 May '14

Hi, Here follows my review of the convert library: - What is your evaluation of the design? ---------------------------------------------------------- The design of the interface with the post-review changes (the one returning optional<T>) is sound and flexible even if little too verbose for certain cases. The reason why I still write my own converters in applications is that I don't like the interface of lexical cast that does not provide a nothrow option. If Convert is accepted to Boost this would make my life easier. In regard to the verbosity, I understand that it is so for the sake of flexibility, but if possible I would like if one of the available converters was labelled as default (the stringstream-based one?) and a new variant of convert accepting only the input value and internally constructing and using the default converter was added. This is however not a condition for accepting the library. - What is your evaluation of the implementation? >From the quick glance I've had at the sources it looks acceptable. [nitpicking] Some of the code is indented using 4 spaces and the rest using tabs. This looks awkward and is difficult to read on editors with tab width other than 4. [/nitpicking] - What is your evaluation of the documentation? ---------------------------------------------------------- Why is the motivation section placed towards the back? This section IMHO belongs to the front. Otherwise acceptable. - What is your evaluation of the potential usefulness of the library? ---------------------------------------------------------- Very useful, even to the point that I'd like to have it in the standard (one day soon). - Did you try to use the library? With what compiler? Did you have any problems? Yes, with gcc 4.8.1. I've built and run the `test_convert.cpp` test case. It build without problems, but I had to change the hardcoded locale for it to run without errors. Also, the makefile in `test/` references files outside of the library source tree. I've also tried it on some of my own very simple applications which all ultimately built and ran without errors. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? In total somewhere between 2 and 3 hours. I've read the docs and some of the reviews here, I've at least scrolled through all source files, and had a look at some parts that I was interested in. - Are you knowledgeable about the problem domain? As knowledgeable as anyone who had to write his own converters for argument values or text input many times. - Do you think the library should be accepted as a Boost library? Yes, if the new interface returning `optional<T>` is used. Best regards, Matus Chochlik

1 0

Re: [boost] Using Program Options styles to format options_description output
by Arindam Mukherjee 24 May '14

24 May '14

Including boost(a)lists.boost.org. On Fri, May 23, 2014 at 11:08 AM, Arindam Mukherjee <arindam.mukerjee(a)gmail.com> wrote: > One of the things I want to do when I use Program Options is to print > the help according to the styles I am enforcing. For example, on > Windows if I use allows_slash_for_short, it will make sense for me to > reflect that when I print the actual help string. I can't find a way > to do this. Any pointers? > I noticed that the option_description::format_name() method, which is called to format each option while streaming the help message, hard codes the leading characters of the long and short options and as a result there is no way to print the description based on the style I am enforcing. This seems like a serious bug to me. If I am using a style in which options are introduced with a leading forward slash (which is supported) or long options are introduced with a single rather than double hyphen (which too is supported), then I'll end up printing misleading description. I'll try to patch this in my private build without breaking existing interfaces. Would be keen to know if there would be any general interest in such a patch. Regards, Arindam

1 0

[Filesystem] Proposal: make filesystem generic-programming friendly
by Alexander Lamaison 23 May '14

23 May '14

Dear all, I'm increasingly finding that I need to write programs that can operate over multiple kinds of filesystem, including the local filesystem, network filesystems such as (S)FTP, filesystems in archives such as zip files, and mock filesystems that exist only in memory for unit testing. This is not as easy as it could be. The difficulty is that the Boost.Filesystem API makes it difficult to write generic code that uses the local filesystem as just one of several API-compatible filesystems. Therefore, I've written a proposal for making a backward-compatible addition to the Boost.Filesystem API that would make it much more friendly to generic programming. It is a first draft and I welcome your comments, criticism and suggestions for improvement. The proposal is available here: http://alamaison.github.io/2014/01/09/proposal-generic-filesystem/ and I've included a text-only version below. Alex Proposal: Generic filesystem API ================================ [FIRST DRAFT] C++ streams provide a common interface to operate on file-like data, regardless of how that data it is actually stored. However, programs often need to operate not just on data from different file sources, but also on entirely separate filesystems. The problem ----------- There is, currently, no way to operate on different filesystems generically, if Boost.Filesystem is to be one of those filesystems. The local-filesystem operations in the Boost.Filesystem API make it difficult to call them generically because they, inadvertently, defeat ADL, so generic code cannot resolve them to specific implementations. For example, how do you write code that calls `path temp_directory_path();` and can operate on both the local filesystem, via Boost.Filesystem, and on a filesystem over FTP, via an FTP library? If both libraries declare the function, how do you resolve the correct implementation? You can't use a namespace as a type. Normally, ADL is the solution to the problem; it resolves the correct namespace based on the namespace of the operation's argument(s). But `temp_directory_path()` doesn't take an argument. The source of the problem is a misconception that the free-functions performing FS operations are part of the `class path` API, when really they are part of the API of an implicit local-filesystem object. The Boost.Filesystem FAQ asks: > **Why are paths sometimes manipulated by member functions and > sometimes by non-member functions?** > > The design rule is that purely lexical operations are supplied as > class path member functions, while operations performed by the > operating system are provided as free functions. This is wrong because the majority of the non-member operations don't manipulate paths at all. They are functions that manipulate the filesystem, some of which use a path, and, therefore, are really part of the API of an implicit local filesystem object. The proposed solution (later) just makes this explicit, in a backward-compatible way. Is modifying Boost.Filesystem necessary? ---------------------------------------- Before we discuss our proposal, let us explore how much can be achieved without any changes to Boost.Filesystem, using the typical ADL approach to generic programming. ### Limited solution: ADL on filesystem-specific path If each filesystem were to declare a `path` class conforming to the `boost::filesystem::path` interface, ADL could resolve a *subset* of the filesystem operations. The example below implements a simple generic algorithm, `remove_if_temporary` over both Boost.Filesystem and an imaginary `ftp_filesystem`. #include <iostream> #include <boost/filesystem.hpp> namespace ftp_filesystem { class path { public: path(const std::string& server, const std::string& location) : server_(server), location_(location) {} std::string string() const { return location_; } /* ... */ private: std::string server_; std::string location_; }; void remove(const path& target) { std::cout << "Removing " << target.string() << " over FTP" << std::endl; }; } template<typename Path> void remove_if_temporary(const Path& file_path) { if (file_path.string()[file_path.string().size() - 1] == '~') { remove(file_path); } } int main() { remove_if_temporary(boost::filesystem::path("/tmp/bob")); remove_if_temporary(boost::filesystem::path("/home/bob~")); remove_if_temporary( ftp_filesystem::path("ftp.example.com", "/tmp/bob")); remove_if_temporary( ftp_filesystem::path("ftp.example.com", "/home/bob~")); } The key to this solution is that each filesystem's namespace maintains a separate `path` type. The algorithm is instantiated with different path types, allowing ADL to resolve the necessary implementations. However, this is not a good solution because it is continues the pretence that operations are part of `class path`, but this pretence only stretches so far. The result is that: 1. Operations that don't take a `path` argument can't be used in generic algorithms. Some operations, such as `temp_directory_path()` just *return* a `path`. ADL won't resolve those. 2. `path` becomes coupled to a particular filesystem. `boost::filesystem::path` is a currently a good abstraction of many filesystem's path representation, but making it as the ADL key that resolves operations to their implementation means that other filesystems can't use it as their path representation (would `BOOST_STRONG_TYPEDEF` solve this?). 3. `path` must carry filesystem instance data. The local filesystem is a singleton so its path only needs the location-on-disk string. But other types of filesystem may be instantiated with host names, authentication information, running network sessions, etc. The path instances have to carry this extra baggage. In addition, important parts of the API, namely file opening/creation and directory iteration, can still not be used generically, without changes to Boost.Filesystem, because they are *classes* constructed with a `path`, rather than free functions taking a `path` argument. Solving this will need additional factory functions for each class so that ADL can resolve them. **In summary**: generic filesystem programming is possible with no changes to Boost.Filesystem if generic algorithms don't open files, create files, iterate directories or use any nullary filesystem operations. Even accepting these limitations, the API is not ideal because of undesirable coupling between `path` and the specifics of a filesystem. ### Proposed solution: Add local filesystem object to Boost.Filesystem The main problem with the above solution is that nullary operations cannot be resolved by ADL. In effect, these operations take a hidden local filesystem argument, but, as the argument is implicit, ADL cannot use it to resolve them The suggestion in this proposal is to make the filesystem object explicit so that: - ADL can resolve all the operations using the namespace of this object; or - the operations can be resolved as methods of this object. Either change is backward-compatible. The existing functions remain in place, and code that only uses the local filesystem need never refer to the local filesystem object explicitly. The example below demonstrates the second option. This is my preferred option because all filesystems, except the local one, are likely to implement their operations in terms of private data in the filesystem object. Passing this object to free functions, instead of calling a method, means this private data must be exposed. The example below demonstrates a partial implementation of the additional new `class filesystem`, and shows how to use it generically. #include <boost/filesystem.hpp> namespace ftp_filesystem { class filesystem { public: typedef boost::filesystem::path path; filesystem(const std::string& server) : server_(server) {} path temp_directory_path() const { std::cout << "Querying " << server_ << " for $TMPDIR\n"; return "/tmp"; } void remove(const path& target) { std::cout << "Removing " << target.string() << " on " << server_ << " over FTP" << std::endl; }; private: std::string server_; }; } /* Added to existing Boost.Filesystem API */ namespace boost { namespace filesystem { class filesystem { public: typedef boost::filesystem::path path; path temp_directory_path() const { return temp_directory_path(); } void remove(const path& target) { remove(target); }; private: filesystem() {} friend boost::filesystem::filesystem& local_filesystem(); }; /* Local filesystem is singleton */ inline boost::filesystem::filesystem& local_filesystem() { static filesystem instance; return instance; } }} template<typename Filesystem> void remove_if_temporary( Filesystem& fs, const typename Filesystem::path& file_path) { std::string name = file_path.filename().string(); if (name[name.size() - 1] == '~' || file_path.parent_path() == fs.temp_directory_path()) { fs.remove(file_path); } } int main() { ftp_filesystem::filesystem ftp_fs("ftp.example.com"); boost::filesystem::filesystem& local_fs = boost::filesystem::local_filesystem(); boost::filesystem::path in_temp_dir("/tmp/bob"); boost::filesystem::path temp_by_name("/home/bob~"); remove_if_temporary(ftp_fs, in_temp_dir); remove_if_temporary(ftp_fs, temp_by_name); remove_if_temporary(local_fs, in_temp_dir); remove_if_temporary(local_fs, temp_by_name); } As well as the technical reasons for introducing this change, I believe it better reflects the division of responsibilities between `class path` and the filesystem. Paths are not coupled to the filesystem and can be shared between supporting filesystems. If a particular filesystem needs a different path implementation, that is supported too and it is up to the generic algorithm whether it works with all path implementations or just `boost::filesystem::path` instances. Filesystem details are encapsulated in the filesystem object alone and it performs all the operations using those internal details. The example above implements <code>class filesystem</code> in terms of the existing operations functions so that it will compile with no further changes. A better idea may be to implement the existing operations in terms of the new filesystem object's methods because that better reflects their meaning. Impact on Boost.Filesystem -------------------------- The impact on existing users of Boost.Filesystem should be minimal. The only change they may notice is extra documentation for generic use of the API. ### Backward compatibility No existing code using Boost.Filesystem will need any changes. The existing free functions remain in place as a sensible convenience for the common case where only the local filesystem is needed. ### Additions A new object `boost::filesystem::filesystem` is introduced, along with its singleton accessor function, `local_filesystem`. Depending which of the two API options is chosen: - the operation free-functions are overloaded to take an instance of `boost::filesystem::filesystem`; or - `class boost::filesystem::filesystem` is given methods that perform each of the operations currently in free functions. Even functions `absolute()` and `canonical()`, which may seem to be part of the path API, are really part of the filesystem object's API: they can be implemented solely in terms on `class path`'s public API but not solely in terms of `class filesystem`'s API. Finally, the classes in the API that perform operations on the filesystem, e.g. `fstream`, `directory_iterator` require one of the following changes: - Add factory functions for each class to `namespace boost::filesystem`. Allows them to be resolved by ADL. Generic callers use auto as return type. - Add static factory functions for each class to the `path` class. Allows them to be resolved by ADL. Generic callers use auto as return type. - Add typedefs for each class to `path` class. Callers construct classes directly. Factory functions for streams will require a workaround in C++03 because the standard streams are not movable. TODO ---- - Define filesystem-path concept - Define filesystem concept -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

6 12

Re: [boost] Boost review of the Convert library is ongoing
by Arpit 23 May '14

23 May '14

alex <alexhighviz(a)hotmail.com> wrote: >>>> >>> The benefit is that it defers initialization and thus passes that >>> responsibility from the generic function to the specific converters. >>> >> Let's try staying with mainstream usage examples meaningful for the >majority of users. I'll >>unlikely be persuaded by an esoteric academic (even a real but >>corner-case) example that will have negative impact on the real users. >>Thoughts?.. > >The convert contract you are proposing is quite abstract, so I think >academic arguments are relevant. But your question can be translated to: are >there real examples of classes that are expensive to construct but cheap to >move? Moreover, these classes need to be potential candidates for being >converted to. > >The example you have been using is encryption. Consider the following class >for an encrypted password: > >struct encrypted_password >{ > encrypted_password(const std::string& password) > { > // connect to random number device > // do all kinds of arithmetic to encrypt > // send email to NSA > // m_encrypted will have a minimum size of 128. > } > encrypted_password (password_encryption&& rhs) : m_encrypted >(std::move(rhs.m_encrypted)) > { } > > bool check_password(const std::string& password){} > >private: > std::string m_encrypted; >}; > >Now I can write a converter: > >struct password_converter >{ > void operator()(const std::string& in, >boost::optional<password_encryption>& out) > { > try { > out = password_encryption(in); > } catch(...) { > out = boost::none; > } > } >}; > > > >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Boost review of the Convert library is ongoing
by Arpit 23 May '14

23 May '14

alex <alexhighviz(a)hotmail.com> wrote: >>>> >>> The benefit is that it defers initialization and thus passes that >>> responsibility from the generic function to the specific converters. >>> >> Let's try staying with mainstream usage examples meaningful for the >majority of users. I'll >>unlikely be persuaded by an esoteric academic (even a real but >>corner-case) example that will have negative impact on the real users. >>Thoughts?.. > >The convert contract you are proposing is quite abstract, so I think >academic arguments are relevant. But your question can be translated to: are >there real examples of classes that are expensive to construct but cheap to >move? Moreover, these classes need to be potential candidates for being >converted to. > >The example you have been using is encryption. Consider the following class >for an encrypted password: > >struct encrypted_password >{ > encrypted_password(const std::string& password) > { > // connect to random number device > // do all kinds of arithmetic to encrypt > // send email to NSA > // m_encrypted will have a minimum size of 128. > } > encrypted_password (password_encryption&& rhs) : m_encrypted >(std::move(rhs.m_encrypted)) > { } > > bool check_password(const std::string& password){} > >private: > std::string m_encrypted; >}; > >Now I can write a converter: > >struct password_converter >{ > void operator()(const std::string& in, >boost::optional<password_encryption>& out) > { > try { > out = password_encryption(in); > } catch(...) { > out = boost::none; > } > } >}; > > > >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Can I get access to Trac
by Andrzej Krzemienski 23 May '14

23 May '14

Hi All, How can I get access to Trac to be able to close tickets related to Boost.Optional? Regards, &rzej

2 1

Gmane web interface is definitely in trouble as it does not show any messages from 21st forward.
by Vladimir Batov 23 May '14

23 May '14

http://blog.gmane.org/gmane.comp.lib.boost.devel It is clear when one tries the unthreaded view. The activity calendar on the left shows no activity/messages in this list from 21st. Something happened midway through 20th May.

3 2

Convert library -- Andrzej's review
by Andrzej Krzemienski 23 May '14

23 May '14

Hi, This is the review of the Convert library. My vote is a CONDITIONAL YES: this library should be accepted into Boost subject to conditions described at the end of this message. This is a good and useful library. This is what I needed for a long while: a tool that allows me to convert a string to an int or float, but that would not treat the failure to convert as something unusual, and that would be locale-aware. Convert library offers this. It also offers other things that I fail to appreciate, but I accept that it is supposed to satisfy more expectations than just mine. Your choice of the generic type converter: bool operator()(TypeIn const&, TypeOut&); I think it is the right choice: this is the signature that does not impose any run-time overhead. Unlike boost::convert<TypeOut>::result, which does impose some run-time overhead of copying (or at least moving) the TypeOut. But that's acceptable. If the conversion needs to be super fast, one can fall back to using the converter directly. I appreciate the stringstream-based converter most. About the ability to plug other converters, I am just not convinced. Why would I use other converters? I know, lexical_cast is supposed to be faster in some cases, but if I was interested in this performance I would have used lexical_cast directly. The alleged ability to use this library to change the encoding of the strings or to convert between "related" types like ptime and time_t and Time -- I am not convinced: do you expect such conversions to fail and to report such failure the same way as you report the impossibility of interpreting a string as a float? I personally do not like this trick to force me to type this "from" in "convert<int>::from". If I was only passing my string as an argument, this would be fine, but when I am also passing the converter object, it reads that I am converting from both the converter and the string. But I do not intend to argue over it. You wrote the (good) library, so you have the privilege to pick the name. I am also not convinced about the potential of the 'facade' part. I can see that you can see the potential in it. But to me separating the library into the facade and the stringstream converter adds no practical value. But the stringstream converter itself is enough to stand for the usefulness of library. My condition on the acceptance of the library is that its performance should be improved as indicated by others, in particular, provide move semantics for boost::convert<TypeOut>::result (on compilers with rvalue references). It is enough that you commit to doing it in the future. Regards, &rzej

5 18

[ptr_container] pull request: test values were swapped
by Ben Pope 22 May '14

22 May '14

https://github.com/boostorg/ptr_container/pull/1 Ben

3 12

[container] templated find / [lower/upper]_bound would be really useful
by Sebastian Karlsson 22 May '14

22 May '14

In my case I have map such as: flat_map< pair< TypeInfo, TypeInfo >, ... >, TypeInfo being a wrapper around std::type_info. From this map I want to find lower & upper bound of some TypeInfo in comparison to the first TypeInfo of the pair. Since I can't know the maximum & minimum TypeInfo I can't construct a key_type to search with. In this case it would be great to be able to use find with a templated argument ( in my case I'd overload the comparison for pair and smack in a TypeInfo for comparing against first ). templated find / lower / upper would also have the benefit of being faster if key_type is expensive to create. Overall I can't think of any major downfalls, and the changes would seem to be rather easy to make. Kind regards, Sebastian Karlsson

2 1

Re: [boost] Thoughts on Boost v2
by Michael Caisse 22 May '14

22 May '14

[Robert's input didn't come through. Replying so it shows up in the thread.] On 05/20/2014 08:47 AM, Robert Ramey wrote: > On Monday, May 19, 2014 6:51:51 PM UTC-7, Michael Caisse wrote: > > On 05/19/2014 06:47 PM, David Stone wrote: > > As the author of bounded::integer, I do intend to submit my > library to > > Boost at some point, for whatever that is worth. It's just not in > a state > > that is ready to submit yet (but soon it will be). I suspect that, > as a > > C++14 library, it will have an interesting process getting in, but > maybe > > the next Visual Studio preview will be out by then, which looks > like it > > might support all the features I need. > > > > > > We welcome C++14 libraries and I see no problem with a submission on > that basis alone if it is supported by at least two compilers. > > I look forward to your submission David. > > > There is one issue that should be addressed. The Current test matrix > doesn't distinguish between C++ versions. If I make a library > which requires C++11 and start testing it, it will fail on all test > platforms which don't support C++11. This creates pressure > to support earlier versions of C++ when we don't there to be. Currently > there is no way to tag a library "test for version >= C++11 only". > We need to tweak the test setup only run tests configurations which > match the C++ version supported by the library. > > Note that this currently cannot be done with the current test markup for > a few reasons: > a) it's extremely tedious > b) now some compilers have switches like -std=c++11 or such so the > markup can't be kept in sync with the actual version > being tested. > > Things that are necessary are: > > a) Each library needs to be marked/tagged as to what it's minimum > version is. > b) Each toolset needs to communicate what version of C++ it corresponds to > c) Only compatible toolsets are actually tested. > > This would show all green results for libraries for which a minimal > version is required - unlike that which happens now. > It would also skip useless testing for unsupported configurations > thereby saving time. > > It would also resolve the whole question of Boost version v2. Each > library can support the version of C++ > without conflict. Older, core components like Config would support > everything while newer more specific > libraries like spirit3 would only support C++14/17 etc.. > >

2 1

[graph] [graph_parallel] Named parameters in non_distributed_brandes_betweenness_centrality
by Javier Dehesa 22 May '14

22 May '14

Hi. I'm trying to add an optional named parameter to non_distributed_brandes_betweenness_centrality. I've managed before to do it in the brandes_betweenness_centrality function of the sequential BGL, but here the named parameters seem to be managed a little differently. Currently there is only one optional named parameter, weight_map, but I've seen that here, unlike the sequential version, it is not actually optional, as I cannot compile a call to the named parameter version of the function without providing that parameter. I'm attaching a piece of code as an example of what does and what does not compile. Is this behavior wrong? I suppose it is, but named parameters are kinda obscure for me, so any insight about it would be welcome. My intention is to copy the named parameter collection code from the sequential version, but I wanted to know any advice or comments anyone could provide. Thanks. -- Javier Dehesa

1 0

[typeof] unqualified enable_if in msvc-8.0 code is confused with Boost.Test boost::unit_test::decorator::enable_if
by Menelaos Karavelas 22 May '14

22 May '14

Dear typeof maintainers. I have encountered a problem with typeof on msvc-8.0. boost::enable_if is used in the code (unqualified), and it is confused by msvc-8.0 with Boost.Test boost::unit_test::decorator::enable_if (this happens with the included version of unit test). I have created a pull request for this issue: https://github.com/boostorg/typeof/pull/1 Could you please see to it. Best regards, - m.

2 4

Convert library to use Boost.Optional?
by Andrzej Krzemienski 22 May '14

22 May '14

Hi Vladimir, I have just made one observation regarding the return type. Now, that you are using your custom boost::convert<TypeOut>::result, you can choose what exception type you want to throw from function value(). Your current choice is probably not the best one because you cannot distinguish with a type alone between the failure to convert form string to T from any other std:: invalid_argument thrown in a big program. I recommend that you invent your own type that can derive from std::invalid_argument. This will work fine, but the problem will reappear when you switch to boost::optional, because the latter is a general purpose library and it does not know the history behind the failure. It will throw a generic "empty optional" error rather than something speciffic to conversions. So, there is one disadvantage of using boost::optional. I do not know how important you consider it to be. If it is a deal, and you do not want to invent your own return type. Perhas you could use 'Expected': http://www.hyc.io/boost/expected-proposal.pdf. It is proposed for Standard C++, And I think some work is being done to include it into Boost too. It is similar to Boost.Optional, but conveys more information about the reason of failure. Might be worth considering. Regards, &rzej

2 2

[ANN] libstudxml - modern XML API for C++
by Boris Kolpackov 22 May '14

22 May '14

Hi, libstudxml is an XML library for modern, standard C++. It has an API that I believe should have already been in Boost or even in the C++ standard library. The API was first presented at the C++Now 2014 conference. Based on the positive feedback and encouragement I received during the talk, I've decided to make the implementation generally available. As an example, we can parse this XML: <person id="123"> <name>John Doe</name> <age>23</age> <gender>male</gender> </person> With the following C++ code, which performs all the validation necessary for this XML vocabulary: enum class gender {...}; ifstream ifs (argv[1]); parser p (ifs, argv[1]); p.next_expect (parser::start_element, "person", content::complex); long id = p.attribute<long> ("id"); string n = p.element ("name"); short a = p.element<short> ("age"); gender g = p.element<gender> ("gender"); p.next_expect (parser::end_element); // person The API has the following interesting features: * Streaming pull parser and streaming serializer * Two-level API: minimum overhead low-level & more convenient high-level * Content model-aware (empty, simple, complex, mixed) * Whitespace processing based on content model * Validation based on content model * Validation of missing/extra attributes * Validation of unexpected events (elements, etc) * Data extraction to value types * Attribute map with extended lifetime (high-level API) libstudxml is compact, external dependency-free, and reasonably efficient. The XML parser is a conforming, non-validating XML 1.0 implementation that is based on tested and proven code. The library is released under the MIT license. More information, documentation, and source code are available from: http://www.codesynthesis.com/projects/libstudxml/ Or, you can jump directly to the API description with examples: http://www.codesynthesis.com/projects/libstudxml/doc/intro.xhtml#2 Enjoy, Boris

6 11

Re: [boost] Foundational vs non-foundational libraries
by Loïc Joly 21 May '14

21 May '14

Le 21/05/2014 22:26, Peter Dimov a écrit : > Loic Joly wrote: > >> Internally, some boost classes depend on boost::shared_ptr, not on >> std::shared_ptr. I remember making a suggestion that on platform >> supporting std::shared_ptr, boost::shared_ptr should be a simple >> typedef to std::shared_ptr. It was rejected. As a consequence, it's >> very hard not to indirectly include <boost/shared_ptr> when you >> include any part of boost. Which create issues for people who only >> want to use std::shared_ptr in their code. > > I understand why such a setup would be better for some (most) users. > It would however preclude any further improvements to boost::shared_ptr. > > boost::shared_ptr now supports arrays, for example, and no current > std::shared_ptr does that yet. Agreed, but I have never in my life wanted a shared_ptr to an array... Types such as shared_ptr are IMO crucial, because they are basic vocabulary types, that are part of library interfaces, and allow communication between different parts of the code. To me, the fact that std::shared_ptr is in std, and therefore might be used as a common vocabulary type by anyone anywhere has more value than any bells and whistles that might be added to anywhere::shared_ptr. I agree that we are not here yet. Many concurrent implementations of shared pointers (some of them buggy) exist in many libraries. But I also believe that if boost switched by default to std::shared_ptr, it would give this class enough momentum to make it not only an ISO standard, but also a de facto standard. And it would be a great boon to library compatibility. The possibility to work with an alternative shared_pointer is interresting, mostly to make it evolve in the future, but I think this is an experimental feature. It should not be enabled by default, just like compiler experimental feature are useful, but are best disabled by default and explicitly enabled by people who really want to experiment with them. > >> If I proposed [a library / a patch for an existing library] for boost >> that returned a std::shared_ptr, would it be accepted? I sincerly >> don't know. > > I concede that you'll probably be asked to return a boost::shared_ptr > instead. --- Loïc

1 0

Second week of review for the Convert library
by Edward Diener 21 May '14

21 May '14

This is the second week of the the review of the Convert library, which started Monday May 12 and goes through Sunday May 25. For those who have been to C++ Now please take a look at the library and review it. I am looking for at least a half dozen reviews before I can decide, based on the reviews, whether or not the library should be accepted into Boost. The Convert library builds on the boost::lexical_cast original design and experience and takes those conversion/transformation-related ideas further. * to be applicable to a wider range of conversion-related use-cases, * to provide a more flexible, extendible and configurable type-conversion framework. The Convert library can be cloned from GitHub at https://github.com/yet-another-user/boost.convert. The library follows the modular-boost format. Just clone it to modular-boost/libs in the 'convert' subdirectory and run 'b2 headers' in order to create a link to its header file directory in the modular-boost/boost subdirectory. The library comes with documentation in its top-level index.html or doc/html/index.html file. You can also view the documentation online at http://yet-another-user.github.io/boost.convert/doc/html/index.html. The library is by Vladimir Batov and is a second reiteration with a greater focus of his library that was reviewed in the past. I am Edward Diener and I am again serving as the review manager of the library. If you have used lexical_cast or, like many C++ programmers, have used stringstream to do string-to-type, type-to-string conversions please look at this library. We need reviews of whatever point of view before a library can even be considered a Boost library. Comments, questions, and reviews will all be welcome for the library. Please try to sum up your review by answering these questions: What is your evaluation of the design? What is your evaluation of the implementation? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library? Did you try to use the library? With what compiler? Did you have any problems? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? And finally: Do you think the library should be accepted as a Boost library? As always whether you do or do not feel that the library should be accepted into Boost please specify any changes you would like to see for the library to be better in your estimation.

1 0

[GSoC] HTTP library traits
by Vinícius dos Santos Oliveira 21 May '14

21 May '14

Hi, I've been working on the HTTP library that will later be proposed to inclusion on Boost. I still don't have a working example to show and some uncommited and incomplete changes to documentation generation (still learning QuickBook) and changes to the acceptor (don't bother to ask) are laying around on my system. I can hunt all these on my all and I'll ask for design ideas later. The reason for this email is to ask for help from template meta programming ninjas to rate the skel of my traits implementation. It took me a whole day (first time I had the opportunity to play with SFINAE) to write this and I don't know if I'm following good practices or so on: - https://github.com/BoostGSoC14/boost.http/blob/b9c596249e39eea26fe1b59377cc… - https://github.com/BoostGSoC14/boost.http/blob/b9c596249e39eea26fe1b59377cc… -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

2 3

(Fwd) Re: Thoughts on Boost v2 (was: Re: Is Boost dead? [Re: Anyone is interested in being review manager of ‘Applic
by Niall Douglas 21 May '14

21 May '14

And the other one, probably the one people actually wanted .. N ------- Forwarded message follows ------- Date sent: Mon, 19 May 2014 10:04:22 -0700 (PDT) From: Robert Ramey <robertmacleranramey(a)gmail.com> To: boost-devel-archive(a)googlegroups.com Copies to: boost(a)lists.boost.org, boost(a)lists.boost.org, s_sourceforge(a)nedprod.com Subject: Re: [boost] Thoughts on Boost v2 (was: Re: Is Boost dead? [Re: Anyone is interested in being re view manager of `Application´?]) Ahhhh - not only provocative but actually concrete enough to comment on: Here goes On Friday, May 16, 2014 10:10:51 AM UTC-7, Niall Douglas wrote: > > > 2. Everyone recognises there are serious problems with process, > everything from how you were treated Stephen when you tried cleaning > out cruft and only really Dave supported you, This effort may have been well intended - but is ill conceived and had major flaws in approach and execution. I don't want to re-debate this here so let's just agree to not use this as an example of anything. right through to the > fact that peer review simply doesn't work any more. There is wide agreement that there are problems here. The boost library incubator (www.blincubator.com) is a major effort to address this. We'll see if this helps. The Boost > community has become quite selfish in recent years, as you would > expect from those with a vested interest in the status quo before > evolution. And for the record, I have no problem with those vested > interests keeping their existing Boost, It's hard to attribute motives to a person - much less than an organization. > but I personally want as far away from C++ 03 as soon as is possible. > Not everyone has that luxury. 3. All the interesting new C++ 11 libraries you find around the > internet have zero interest in trying to join Boost, with a very few > honorable exceptions. That speaks volumes, to me at least. > Without seeing a list of these, it's hard to comment. Which suggests to me a need for a new Boost which attempts to apply > the benefits of hindsight to what we learned with Boost v1. Hmmm - not to me. Note that the problem of various C++ versions has existed since the beginning of boost. Not differing standards but no compiler implement the whole standard and all had bugs. This was addressed by a couple of things. a) Boost.Config which abstracted all the platforms to a common interface. b) An explicit policy that no library be required to be backward compatible or be compilable by any buggy or out of date platform. Many authors have made their libraries backward/buggy compatible in the interests of getting wider usage - but that has not been a boost requirement. c) Though it has not been explicitly stated, (maybe it should be) all libraries should be (and I believe they are) build able and testable with any compiler which meets the latest standard. Now, it > is extremely clear from this conference there is little appetite for > that, but I think later on this year we're going to have three C++11 > libraries in the queue, no problem. And here is what I think should be in a fork of Boost: > A fork of boost would be a spectacularly bad idea - it would mean the end of boost as we know it. > 1. Minimum required compiler feature set will be VS2014's. Hmm - I'm not sure what this means. I believe that all libraries current build and test under the latest C++ compilers. > No use of Boost STL permitted where the C++ 11 STL provides a feature. > This is for the library review process to determine. 2. cmake instead of Boost.Build. There is mixed history regarding boost tools. In some cases things have worked well other cases less so. A big problem is that boost has imposed which tools must be used. It seems you're comfortable with this - but just thing the tool choices need to be updated. I think this is the wrong approach has has contributed to our recent difficulties in evolving to the current software development landscape. I believe we will eventually want to pull back from tool selection specifics and move toward specifying tool requirements. More less like the boost documentation toolset situation. There is no specific requirement as far as toolset but it's wide agreed that documentation is required and that meet some sort of standard. (though that standard hasn't really been explicitly defined - we all think we know what it is). > 3. Eliminate peer review in favour of a suite of automated libclang > based AST analysers. Instead of persuading people to review > libraries, persuade them to review and improve the AST analysers. > I'm trying to restrain myself, but this idea is so naive as to be ridiculous. 4. Mandatory cross platform per-commit CI with unit testing exceeding > 95% coverage. We don't care what unit test library is used so long as > it can output results Jenkins can understand. > These kinds of mandates are a bad idea. No one can predict the future with the precision necessary to make them. > > 5. Mandatory all green thread, memory, UB sanitisers and clean > valgrind. All also tested per-commit. > lol - see above. > 6. Mandatory CI testing for exception safety. I am hoping a clang > rewriter can basically patch all exception throws and have them > randomly throw for testing. > again - not realistic given our variety of environments. > 7. Per-library source distributions instead of a monolithic blob. > This implies some dependency management, I agree with this. Though the scale of the effort seems way under estimated - as usual > but cmake makes that much easier. CMake is not nearly up to this job. In fact, I haven't seen any tool that can actually work for dependency management in our context. Actually, other than John Maddocs post on the problem), I haven't seen any posts which demonstrate an understanding of the problems with this. > It also means we can eliminate the release cycle because each > library does its own release cycle, OK - we've got that now with modular boost whenever anyone merges their develop branch to master. We do need to agree on per library versioning scheme though. and the correct (i.e. tested) > version of dependencies are included into each per-library source > distro. This is never going to be all that reliable. This solves the version lock problem currently plaguing > git-ised Boost, at the cost of pushing the version lock problem onto > users [1]. I don't know what this means. > BTW I want to see a soak test of the unit tests for 24 > hours be all green before a release. > For now I would say that a Boost Release would be: a) All master branches would be tagged with Boost.1.xx b) All tests are run on this branch - if everything passes that Boost 1.xx become the release and git export is used to create the tar, zip, et This purpose of this is catch errors where some library has changed it's interface and broken any dependent libraries. I think (though I'm not sure) that this is inline with your idea above > > 8. Reusable utilities in a submitted library need merging into some > common utilities library which follows the STL conventions. Other > than that, no source code, naming conventions, namespace or anything > else needs converting or changing. We are looking for very high > quality C++ libraries, nothing more. Obviously if someone hopes for a > library to enter the C++ 17 STL they'll need much more rigour, but > that's up to them. > I don't understand what you're getting at here. But .. I think we will evolve a classification scheme which distinguishes levels of dependency a) std b) boost::core e.g. config, mpl c) boost::application e.g. odint, seriaiization? Basically to be able keep out circular dependencies and depency explosion. 9. There is no longer an "in" or an "out" for distribution. I'm > thinking of a scorecard page where member libraries are ranked by how > high quality they are according to all the automated review, so when > I say "mandatory" above, I simply mean they don't get to appear on > the main downloads page without that precondition. All submitted > libraries do appear though, just ranked very low if their quality is > low. I would hope all this is generated from a database and requires > very little human input. > This has merit but the explanation isn't concrete enough. Here's my take on this. Boost has a number of aspects a) lists and communication and community b) library certification via reviews and acceptance c) creation of a monolithic "product" c) testing d) deployment. In the future I would expect to see something different a) community - same as above b) library certification via reviews and acceptance - same as above. c) deployment of closed subset. subsets would be selected either by users when they download (e.g. cygwin) or by third parties (e.g. some embedded systems vendor includes a subset with his IDE). Hopefully boost could then better focus on what only boost can do - certify some specific level of quality. 10. BoostBook documentation using the Boost look and feel becomes > mandatory. I've had enough with library authors thinking they can > improve on BoostBook's output with things like using Comic Sans as > the font or weird colour schemes throughout. > LOL - i hear you. But it's not a great idea to make a big deal about this stuff. We can't really do a good job and we would spend huge amounts of time on trying agree on stuff which is less important. To grow boost has to narrow it's focus - not expand it. > So, basically, in some areas requirements are significantly > tightened. In other areas requirements are significantly loosened. > The aims of the above ten items are as follows: > > 1. To reduce the amount of human work involved in maintaining Boost. I think your specific suggestions would expand the amount of work required to maintain a working boost by a very large amount. Actually just agreeing on what to do would be huge. And it would result in bad decisions being taken since only a few could have the time to participate. What Dave and Daniel had to do for the git conversion last year was > far above what anyone should ever feel they need to do. > lol - right - should we have not made the conversion? > > 2. To decentralise Boost, letting it scale up far better. > Correct. 3. To provide a gradual process of entering Boost which authors can > tip away at slowly with automated scripts slowly improving their > rankings instead of the current "lumps" of high intensity output and > the review approved/failed scheme currently used. > Not clear what you mean - But If you look at the Boost Library Incubator it has exactly that idea. Reviews can accumulate until it becomes clear that a library should be accepted or rejected. It doesn't replace the final review. Maybe someday it might, but I doubt it. 4. To incentivise authors to maintain their libraries as the quality > bar is improved - the automated scripts will start to drop library > rankings as the quality is raised, thus dropping that library in the > overall rankings. Rather more importantly, it provides a natural > "deprecation" mechanism, something sorely lacking in my opinion from > present Boost. > This is also on the right track. I think the idea of a "deployment subset" as stated above will address this. Eventually I expect that some libraries (e.g. those which have std equivalents) would be dropped from standard deployments. They would still be approved boost libraries though. I would deprecate the word "deprecate" as it has a perjorative flavor. But rather characterize these libraries as "not part of standard (or minimal or core, or...) deployment. That, the set of deployed libraries would not be the same as the set of "boost certified" libraries as it is now. In fact, I'd like to see boost get out of the deployment business all together eventually. Robert Ramey > > Thoughts? > > [1]: If this model proves popular as we can get a regular donation > stream going, we could deploy an automated SHA stamper which through > unit test iteration, figures out which SHAs in which combinations of > libraries are compatible. Then you could safely mix library A's > distro with library B's distro. I'd imagine Debian upstream et al > might be coaxed into providing for this as they need one unified set > of compatible libraries. > > Niall > > -- > ned Productions Limited Consulting > http://www.nedproductions.biz/ > http://ie.linkedin.com/in/nialldouglas/ > > > ------- End of forwarded message ------- -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

(Fwd) Re: Thoughts on Boost v2
by Niall Douglas 21 May '14

21 May '14

Seeing as the original did not reach the mailing list. N ------- Forwarded message follows ------- Date sent: Wed, 21 May 2014 07:02:20 -0700 (PDT) From: Robert Ramey <robertmacleranramey(a)gmail.com> To: boost-devel-archive(a)googlegroups.com Copies to: boost(a)lists.boost.org, boost(a)lists.boost.org, s_sourceforge(a)nedprod.com Subject: Re: [boost] Thoughts on Boost v2 On Wednesday, May 21, 2014 4:49:37 AM UTC-7, Niall Douglas wrote: > > > > We welcome C++14 libraries and I see no problem with a submission on > > that basis alone if it is supported by at least two compilers. > > For me personally, I would vote for an instant rejection for any > library not compilable to the MSVC ABI irrespective of any other > factors. FYI a review is not a vote. Acceptance/Rejection is not a democratic process. The review manager has the authority to accept/reject based on his assessment of the quality of the library independent of the number of "votes" it receives. Long standing boost policy is that there is no explicit requirement that any code conform to any specific compiler as long as it complies with the current standard. There is no requirement that it use specific features (e.g. from more recent standards) to the exclusion of more traditional (albeit still conforming) features. Indeed, a number of libraries have been submitted and accepted that don't compile on multiple compilers. Robert Ramey ------- End of forwarded message ------- -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Boost contributing tutorial (GitHub)
by Adam Wulkiewicz 21 May '14

21 May '14

Hi, I prepared a tutorial about the contributing at GitHub/Boost describing how to create a Fork of a library, use it inside modular Boost and create a pull request. The tutorial presents examples for Boost.Geometry but could be extended to the other libraries. It has a form of a README of this repository: https://github.com/awulkiew/temp-contributing Would you be so kind and see if everything is ok wth it? In praticular I'd like to hear if this model is good for modular Boost in general? Regards, Adam

3 5

[smart_ptr] Proposal to add new memory order constants
by Andrey Semashev 21 May '14

21 May '14

Hi, I have a proposal to add new constants to the memory_order enum: memory_order_hle = 16, memory_order_hle_acquire = memory_order_hle | memory_order_acquire, memory_order_hle_release = memory_order_hle | memory_order_release These constants can be used to support Intel HLE (Hardware Lock Elision) [1] in Boost.Atomic and then reused by Boost.Sync. The meaning of these constants is Intel-specific (for now): the memory_order_hle_acquire operation has memory_order_acquire ordering and also starts a transaction; memory_order_hle_release operation has memory_order_release ordering and also commits the transaction. On other targets memory_order_hle flag is ignored and memory_order_hle_acquire and memory_order_hle_release are equivalent to memory_order_acquire and memory_order_release, respectively. The support for these constants can be implemented in the following Boost.Atomic backends: - all x86 assembler-based backends. - gcc __atomic* builtins support __ATOMIC_HLE_ACQUIRE and __ATOMIC_HLE_RELEASE flags (at least, gcc 4.8 and Intel compiler 14.0.3 for Linux). - MSVC x86_64 supports Interlocked intrinsics with _HLEAcquire and _HLERelease suffixes. There are also _Store_HLERelease, _Store64_HLERelease and _StorePointer_HLERelease. Unfortunately, these only cover 32 and 64-bit types, for other types regular atomics will be used (i.e. HLE won't be used). For 32-bit x86 asm blocks are also a possibility; all types can have HLE support. BTW, maybe Boost.Atomic is a better place for memory_order.hpp? What do you think? [1] https://software.intel.com/sites/products/documentation/doclib/stdxe/2013/c…

2 7

[filesystem] Request for comments on proposed relative() function
by Beman Dawes 20 May '14

20 May '14

There are two open tickets requesting a relative() function, and also a National Body (I.E official) comment against the Filesystem TS (which is due to finalize at the June C++ committee meeting). The committee's Library Working Group has indicated they would like to add such a function. With help from Jamie Allsop, I've put together a proposal. See attached for docs. See https://github.com/boostorg/filesystem/tree/feature/relative for a branch of filesystem with the implementation and some relative() tests added. Comments appreciated. --Beman

9 37

Viewing the group via http://post.gmane.org misbehaving again.
by Vladimir Batov 20 May '14

20 May '14

For example, Edward's thread (started May 12th) [boost] Boost review of the 'convert' library starts tomorrow May 21 shows only 2 messages in post.gmane.org. Google https://groups.google.com/forum/#!topic/boost-developers-archive/40it9qkZUhA show all 6 messages. I see the same problem -- missing messages -- in other convert-related threads that I follow.

3 2

Re: [boost] Is there any interest in a library for actor programming? serialization + uniform names
by Charousset, Dominik 20 May '14

20 May '14

The serialization and uniform name really boils down to the uniform_type_info class: Uniform names are simply a necessity if you need to identify a type based on its name. The goal is to send any kind of value to a remote machine and being able to deserialize it. If you have platofrm-independent names, you can simply prefix the binary serialized value with its type name and then get the RTTI (uniform_type_info) from the type name and deserialize the rest of the data. Boost.Actor is a bit more cleverer than that and maintains a list of type ids for each node it's connected to. Whenever you send a message with a type you didn't use beforehand, you send the type name along with its newly generated, unique ID and only use that ID going forward. But that's just an optimization. When talking about stateless communication (e.g. UDP), you can't do this and have to generate self-consistent messages. The fact that we even have to do this, is because std::type_info::name() is utterly useless. It returns a mangled name on GCC/Clang and a more sophisticated version of the type name on MSVC. The uniform name is the type name as it appears in code. So the first part of generating the uniform name is to demangle the platform-dependent name (https://github.com/Neverlord/boost.actor/blob/master/src/demangle.cpp) After that, we need to decompose the whole thing and make sure that qualifiers are always in the same order etc (https://github.com/Neverlord/boost.actor/blob/master/src/to_uniform_name.cpp) All this really is only aiming at having at type_info that is actually useful, i.e., name() returns *the exact same string* on each platform and it provides you with an interface for (1) generating values, (2) serializing and deserializing values, and (3) compare values. When generating a value through an uniform_type_info, you'll get a uniform_value, which is bascially a wrapper keeping {uniform_type_info*, void*}. Since we need a way to pass a serializer to a uniform_type_info instance, we can't use a templated approach as the archives in boost.serialization. The serialization classes in use (https://github.com/Neverlord/boost.actor/blob/master/boost/actor/serializer…) operate on sequences and primitive types. With the begin_object member function you also have a way of define serialization recursively, but I don't know if it's really needed to be honest. The write_tuple member function is probably not needed either, since you can simply just write the values one by one. However, it does give you a way of grouping values representing a single member together, which can be quite helpful when serializing to strings for instance. By the way, each announced type in Boost.Actor implicitly has a to_string(), which simply passes the value to a string serializer. There's also a from_string() that passes the input to a string deserializer, which gives you a simple way of injecting messages to the system. But the whole string serialization is not really fleshed out and the format not well defined. ________________________________________ From: Boost [boost-bounces(a)lists.boost.org] on behalf of Hartmut Kaiser [hartmut.kaiser(a)gmail.com] Sent: Tuesday, May 13, 2014 20:46 To: boost(a)lists.boost.org Subject: Re: [boost] Is there any interest in a library for actor programming? serialization + uniform names I'd be interested in hearing more details about this. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu > -----Original Message----- > From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrzej > Horoszczak > Sent: Tuesday, May 13, 2014 8:16 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Is there any interest in a library for actor > programming? serialization + uniform names > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

4 5

Call for Review: Boost.Test documentation rewrite
by legalize+jeeves＠mail.xmission.com 19 May '14

19 May '14

[Please do not mail me a copy of your followup] Boost.Test documentation rewrite: <http://user.xmission.com/~legalize/tmp/boost.test/libs/test/doc/html/> Please post all comments to this list. I've been working on this as time permits for a number of months and I think now things are "finished" enough to warrant wider review. It is a true rewrite using quickbook; I generally used the implementation source code as the answer to my questions about things while writing the documentation. Early snapshots were reviewed by Tom Kent, Alexander Lamaison, Paul A. Bristow and Julian Gonggrijp. A special thanks to them for providing me with useful feedback and suggestions. The main thing that still remains to be added is a detailed explanation of the floating-point comparison algorithms used by BOOST_REQUIRE_CLOSE, BOOST_REQUIRE_CLOSE_FRACTION and BOOST_REQUIRE_SMALL. The corresponding examples also need to be updated. The existing online documentation has had all the math symbols stripped out of it, so it is pretty useless. I'm probably just going to typeset the formulas with LaTeX and then capture them as images that are included in the documentation. (See <https://svn.boost.org/trac/boost/ticket/9539>) I'm guessing that modular boost should allow me to clone libs/test, make all my changes there and then issue a pull request, but I'm not sure how far along things are with the git transition? -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

14 48

Trac request states - suggestion
by Neil Groves 19 May '14

19 May '14

Dear Boost Developers, While working with Trac to maintain Boost.Range I find that I frequently have solved issues but they are not ready to be merged to master due to the release schedule. I haven’t noticed a way in Trac to denote that the issue is fixed and waiting to be merged. This means that I frequently look up tickets that I have forgotten I have fixed. It also means that I have a sub-optimal process for merging to master. I wondered if we might be able to squeeze in a “fixed in branch” field. It would help me considerably. Do other developers think this would help? Do you solve this in another, perhaps better way? I’m happy to lend development time to get this done if there is consensus and we can risk me having write access to Trac code! Thanks, Neil Groves

5 5

Re: [boost] [algorithm] Review Request: edit_distance
by Ahmed Charles 19 May '14

19 May '14

Marshall will probably be busy for the next few weeks. Have you asked Ron about review manager approval? ________________________________ From: Erik Erlandson Sent: 4/14/2014 7:20 PM To: boost(a)lists.boost.org Subject: Re: [boost] [algorithm] Review Request: edit_distance ----- Original Message ----- > > > > - Have you looked at the supposedly better algorithm "An O(NP) > > > > Sequence Comparison Algorithm" by Sun Wu, Udi Manber, and Gene > > > > Myers ? > > > > > I've been doing more cross-testing and benchmarking against the current > > O(ND) > > version. The latest O(NP) prototype is passing randomized cross-testing > > and is now about 25% faster than the O(ND) baseline. My latest prototype code based on O(NP) is now running about 35% faster than O(ND) in my benchmarking: https://github.com/erikerlandson/algorithm/blob/order_np_alg/include/boost/… > > I wrote up a blog post that describes the various ideas I applied to get this > result: > > http://erikerlandson.github.io/blog/2014/02/20/a-bi-directional-variation-o… _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

think-cell is using boost
by Volker Schöch 19 May '14

19 May '14

Hi, We would like to be listed in the Shrink Wrapped Boost section on the boost.org website: http://www.boost.org/users/uses_shrink.html · The name of the Application/Product/Service. think-cell · The name of the company (where appropriate). think-cell · A paragraph describing the Application/Product/Service. think-cell was founded in 2002 in Berlin and is today the leading vendor of productivity software for professional PowerPoint users. Its product suite covers the complete process of presentation creation - from analysis and preparation of business data to the graphical rendering of qualitative and quantitative results. Most international business consulting firms, as well as a large number of the well-known industrial global leaders, are among think-cell's customers. · Any information you can provide about which parts of Boost you used, along with any comments you may have on how Boost helped your product development. C++ is a great and versatile programming language, but only with boost it is a powerful development tool that facilitates really efficient programming. Our code is beautiful, concise and easily maintainable thanks to the following boost libraries: Algorithm, Assign, Config, Conversion, CRC, Date Time, Format, Fusion, Geometry, Integer, Interprocess, Intrusive, Iostreams, Iterator, Math Common Factor, Math/Special Functions, MPL, Multi-Array, Multi-Index, Numeric Conversion, Operators, Optional, Phoenix, Preprocessor, Proto, Range, Smart Ptr, Spirit, String Algo, Swap, Tribool, Tuple, Variant If you are looking for more information on what development problems we are facing every day go to our C++ Developer job posting<http://www.think-cell.com/career/jobs/development.shtml>. · URLs to your company's home page, and the home page of the Application/Product/Service if there is one. http://www.think-cell.com/ Thanks! Volker -- Volker Schöch | vschoech(a)think-cell.com<mailto:vschoech@think-cell.com> Senior Software Engineer We are looking for C++ Developers: http://www.think-cell.com/career ________________________________ think-cell Software GmbH http://www.think-cell.com<http://www.think-cell.com/> Chausseestr. 8/E phone / fax +49 30 666473-10 / -19 10115 Berlin, Germany US phone / fax +1 800 891 8091 / +1 212 504 3039 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schödl

1 0

Crisis, What Crisis ?
by Francisco José Tapia 18 May '14

18 May '14

When , in previous days, I had read messages about the dead of Boost, I stopped to think about it. I think Boost is not dead, even , it have an excellent health, but have problems related with the growth , in the same way than when a young, pass to be adult. Many things must be done in a different way. Every day I see new developers proposing new ideas. If one day, you don't see new ideas and new developers you can certificate the death of Boost. The value of Boost compared with other libraries is that the code is tested, and a company trust in Boost and use their libraries in their internal process and applications, this is not true with many others libraries. I think we must separate the interest of the Boost users and the Boost developers. The developers, usually, are people with great level of knowledge and experience , and the users usually don't have that level. Due this , many times times, the interest of the developers and the users don't agree. Many of the new libraries proposed, in absence of a detailed explanation, are incomprehensible by the majority of the users. If you don't improve the design of the opponent, copy it. Perhaps we must learn about others web as stack overflow , and extract ideas for our web system. I think we must extend the mechanism used for the errors, to the consults of the users. Must be easy and don't need to inscribe. The actual mechanism of the list , I think is appropriate for the developers. Many of the Boost libraries are included in the C++ standards, this show the quality of the library. But I don't think that the people use a boost library, being included in the standard and provided by the compiler. I think we must design an ordered close of that libraries, and locate in a part for to provide utility to the users of old compilers. This reduce the number of libraries and help to improve the clarity and simplicity of the library. Boost had become a very big structure, and perhaps , the actual procedures for to take decisions are not appropriate, in the same way that there are people with a great knowledge and experience and other just arrived, and their opinions can have the same value. I think it is a good idea to create an executive board, elected between the Boost members, in order to take the important decisions. One of the first decisions is what to do with the libraries pending of revision, and the acceptance of new libraries without reviewer. As commented before, we can have libraries very interesting for the developers, and uninteresting for the users, and the opposite. My library COUNTERTREE,( parallel algorithms over Red-Black trees, with random access iterators) is waiting since near two years ago. It's something new, don't exist nothing similar. I had showed to companies (Intel , Google, Valve ...), universities (Stanford, Texas A&M, Carlos III , Stony Brook...) and people of the C++ environment ( Scott Meyers, P.J.Plauger , ) , with a great acceptation. But in their home, Boost, is waiting since near two years, and a good idea stopped is a dead idea. I would like to know if it is interesting in Boost, in order to continue with the development ( there are many algorithms and functionality for to do ), or if it is not interesting, spend my time in others questions, leaving frozen the code. These are only my opinions, open to discuss and new ideas. I am sorry , because the English is not my native language, and it's hard for me to express the details of my ideas. Anyway, I offer my work and my collaboration, for to improve OUR Library. If I can be useful, please, say me and I will try. Yours Francisco Tapia fjtapia(a)gmail.com You can find the code and the documentation in my web pages in dropbox https://dl.dropboxusercontent.com/u/8437476/works/countertree_2.0/index.html or if you prefer in a git format https://github.com/fjtapia/countertree_2.0

1 0

Re: [boost] [Boost-users] Stability of serialization across boost versions
by Brian Wood 18 May '14

18 May '14

Sohail Somani > On 18/05/2014 4:34 AM, John Maddock wrote: >>> Any feedback or suggestions other than not using boost for serialization? >> >> It was my understanding that stuff like that should be supported, if you >> have a test case then filing a bug report would seem to be in order? > > Based on the error, it seems like what is happening is that a newer > version of Boost is attempting to communicate with an older version of > Boost. The actual exception is from the archive itself, IIUC. The > library has explicitly said this is not supported, unfortunately. > > To the OP, I'd suggest not upgrading Boost serialization or requiring > upgrading in lockstep. Upgrading multiple hosts in random order means > new communicating with old. This is an unsupported use case. I have a serialization option. It isn't a Boost library, but it has support for some Boost types and we're willing to add support for other Boost types. -- Brian Ebenezer Enterprises - "He who *refreshes* *others* will *himself* be refreshed." Proverbs 11:25 http://webEbenezer.net

1 0

Re: [boost] Community Maintenance Team and neglected libraries
by Ahmed Charles 18 May '14

18 May '14

I'll be sure to take a look at the outdated pull requests when you send them to the cmt list. ________________________________ From: Beman Dawes Sent: 5/15/2014 3:35 PM To: Boost Developers List Subject: Re: [boost] Community Maintenance Team and neglected libraries On Tue, Apr 22, 2014 at 11:36 AM, Daniela Engert <dani(a)ngrt.de> wrote: > Am 22.04.2014 18:29 schrieb Ben Pope: > > There are quite a few places where the library code is probably fine, > > but the failure is in the test itself, the fix is often simple and > > uncontroversial. > > ... > > The responses have been frustrating to say the least, we really need a > > way to move forward on this. > > > You're so true with your observation. I'm a bit disappointed too. > > I'm sitting on a pile of simple patches to cleanup the existing tests > such that I don't have to wade through a morass of level-4 msvc compiler > warnings when running the test suite. This requires both fixes to some > of the libraries themselves (thereby finding real bugs on the way) and > fixes to the test code to get the tests compiled in the first place. > It's those sanitized libraries that I supply to my colleagues for > production code because it's our policy to be absolutely clean on > level-4 warnings. Some months ago, I've prepared some of those patches > (more yet to come) for inclusion into boost mainline, and some of them > were picked up. The rest of my pull requests seems to be neglected. I > prefer to refrain from spamming the mailing lists with reminders, but is > there a better way to get the message through? Dealing with > quality-of-implementation issues and acting like a janitor might not be > the most sexy job in the universe, but I'm happy to do it (rather than > just sitting on the fence) as long as it has an effect, eventually. > This is one of the specific examples we have been discussing at C++Now in Aspen this week. * You did the right thing when you submitted pull requests. * Your should get some form of response within a reasonable period of time. It will take the CMT awhile to put a specific time on "reasonable" but certainly a month with no response is not reasonable. * Please post a message on the CMT mailing list, with links to the pull requests that you haven't heard anything about. It is their responsibility to decide how to proceed. * If you have questions about global maintenance changes touching many libraries, the CMT list is the best place to ask for guidance. The CMT folks care about maintenance so it is not spamming the list to ask them maintenance related questions. HTH, --Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Boost iterators are not SFINAE-friendly
by pfultz2 17 May '14

17 May '14

Boost iterators aren't SFINAE-friendly. This is a problem when building traits that detect certain behavior. Heres a simple example: #include <vector> #include <type_traits> #include <boost/iterator/filter_iterator.hpp> template<class> struct holder { typedef void type; }; template<class Iterator, class=void> struct is_advanceable : std::false_type {}; template<class Iterator> struct is_advanceable<Iterator, typename holder< decltype(std::declval<Iterator>() += std::declval<int>()) >::type> : std::true_type {}; static_assert(is_advanceable<std::vector<int>::iterator>::value, "This will pass"); struct predicate { template<class T> bool operator()(T&&) const; }; static_assert(not is_advanceable<boost::filter_iterator<predicate, std::vector<int>::iterator>>::value, "This won't pass"); Although, it doesn't always lead to a compile error(rather than subtitution failure), it does lead some very erroneous errors. Thanks, Paul -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-iterators-are-not-SFINAE-friendly-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[utility] Moving addressof out of Boost.Utility
by Glen Fernandes 17 May '14

17 May '14

I was informed the eventual plan is to get rid of Utility as a sub-module, and I observed that Assert was moved out already. If there's any interest in (and no objection to) moving boost::addressof out of it, I don't mind making that change. What would be the most appropriate home for it? A Boost.AddressOf sub-module similar to Boost.Assert? Glen

4 6

wiki/Git/GitHome should list the repo address
by Josh Juran 17 May '14

17 May '14

Hi, I websearched 'boost git', and the top result was the GitHome wiki page. It would be helpful if this page included the address of Boost's Git repository near the top. <https://svn.boost.org/trac/boost/wiki/Git/GitHome> Josh

2 1

Application need a Review Manager. Anyone is interested?
by Renato Forti 17 May '14

17 May '14

Hi All, The proposed Boost.Application, needs a Review Manager. Anyone is interested? The project: https://github.com/retf/Boost.Application Thanks

4 3

[optional] new version in master
by Andrzej Krzemienski 16 May '14

16 May '14

Hi Everyone, This might have been too hasty, but I have put a new version of Boost.Optional on branch master. Tests in 'develop' and 'master' branches pass fine, but I am not sure what it says about overall stability of the library. The changes include: - Move semantics, interoperable with std::move_if_noexcept() -- i.e., move operations are conditionally noexcept; - Using explicit operator bool() rather than custom 'safe-bool idiom' --on applicable platforms; this will break code that exploited the security hole in safe-bool idiom. - Now, you cannot bind optional<T const&> to a temporary (the constructor and assignment taking T&& is deleted);this also break some usages that are likely buggy, but there is a macro to put it back. - Comparison with boost::none does not require that T be EqualityComparable: we just forward the call to operator bool() od operator!(). - optional<T&&> is explicitly prohibited. - some operations are marked noexcept (on platforms that support the keyword). - Rewritten some portions of documentation. I encourage everyone with spare time and available resources to test the version and give us feedback. Please remember that this is supposed to be an incremental improvement over the previous version (for Boost 1.56.0), and next upgrades are planned in the future. Regards, &rzej

2 1

[context] Using Boost.Context on the BlueGene/Q
by Thomas Heller 16 May '14

16 May '14

Hi list, I was very happy to see that Boost.Context has been fixed for PPC64. Thanks a lot for that. I was able to verify that the fix worked on the BlueGene/Q. Both on the Head node, which is a POWER7 and the compute nodes which are a PowerPC A2. However, in order to build the library, I needed to manually call the assembler as the predefined commands did not work. For example, the BG/Q provided assembler doesn't know the "--64" switch and the assembler i want to use is called bgclang-as instead of plain as. For the compute nodes, I additionally want to use the -ma2 flag to have the proper assembly generated. Is there a way to have that configurable by the user? Right now, the only way i could find to fix that is to manually edit the Jamfile.v2 in the context build directory. Any advice or hints to fix it properly are highly appreciated. Thanks, Thomas -- Thomas Heller Friedrich-Alexander-Universität Erlangen-Nürnberg Department Informatik - Lehrstuhl Rechnerarchitektur Martensstr. 3 91058 Erlangen Tel.: 09131/85-27018 Fax: 09131/85-27912 Email: thomas.heller(a)cs.fau.de

2 2

Re: [boost] Community Maintenance Team and neglected libraries
by Edward Diener 16 May '14

16 May '14

On 4/22/2014 12:29 PM, Ben Pope wrote: > In case you haven't heard of the CMT: > https://svn.boost.org/trac/boost/wiki/CommunityMaintenance > > I'm also interested in getting the test results less yellow and more > green, I don't have a lot of time, I'm sure I'm not alone. > > There are quite a few places where the library code is probably fine, > but the failure is in the test itself, the fix is often simple and > uncontroversial. > > Without picking on any particular library or author, here are some > examples: > > * Link the tests with boost::system > http://thread.gmane.org/gmane.comp.lib.boost.maint/92 > * Merge existing fixes in develop to master > http://thread.gmane.org/gmane.comp.lib.boost.devel/250129 > * Fight with casts > http://thread.gmane.org/gmane.comp.lib.boost.devel/250143 > * Disambiguate a type > https://svn.boost.org/trac/boost/ticket/9540 These refer to system, MPI, utility, and assign. None of these are in the list of libraries which the community maintenance team has write acces to apply fixes. Hopefully the developers who do have write access to these libraries will look at the issues involved.

5 7

Re: [boost] Community Maintenance Team and neglected libraries
by Daniela Engert 15 May '14

15 May '14

Am 22.04.2014 18:29 schrieb Ben Pope: > There are quite a few places where the library code is probably fine, > but the failure is in the test itself, the fix is often simple and > uncontroversial. > ... > The responses have been frustrating to say the least, we really need a > way to move forward on this. > You're so true with your observation. I'm a bit disappointed too. I'm sitting on a pile of simple patches to cleanup the existing tests such that I don't have to wade through a morass of level-4 msvc compiler warnings when running the test suite. This requires both fixes to some of the libraries themselves (thereby finding real bugs on the way) and fixes to the test code to get the tests compiled in the first place. It's those sanitized libraries that I supply to my colleagues for production code because it's our policy to be absolutely clean on level-4 warnings. Some months ago, I've prepared some of those patches (more yet to come) for inclusion into boost mainline, and some of them were picked up. The rest of my pull requests seems to be neglected. I prefer to refrain from spamming the mailing lists with reminders, but is there a better way to get the message through? Dealing with quality-of-implementation issues and acting like a janitor might not be the most sexy job in the universe, but I'm happy to do it (rather than just sitting on the fence) as long as it has an effect, eventually. Ciao Dani

3 2

[GitHub] List open pull requests for all libraries? [resend]
by Beman Dawes 15 May '14

15 May '14

We need to be able to monitor the open pull requests for all Boost libraries, not just a individual library. I'm not seeing any canned way of doing that via the GitHub web site. Am I missing something? It does seem possible to access the required information via the GitHub API. Is that the best approach to take? Does anyone know how to do this? Thanks, --Beman

8 14

[test] Regression tests and boost.test merge questions
by Antony Polukhin 15 May '14

15 May '14

Hi, I'm just curious about the situation with Boost.Test. When will be the latest changes merged to master? Regression tests for master branch use develop or master version of Boost.Test? This is vital for me because TypeIndex library must be tested with RTTI off, but master version of Test fail to compile in that way. Compilation of Boost.Test in RTTI-off mode was fixed in develop branch. -- Best regards, Antony Polukhin

1 0

required toolsets
by Steven Watanabe 15 May '14

15 May '14

AMDG The list of required toolsets in explicit-failures-markup.xml is out-dated. Therefore, if no one objects, I propose setting it to the following: msvc-10.0, msvc-11.0, gcc-4.6, gcc-4.7, clang-darwin-11, clang-darwin-4.2.1, clang-linux-3.1, clang-linux-3.2, gcc-mingw-4.7, gcc-mingw-4.6 (two releases of each major compiler that appears in both the trunk and release regression tests) The sole effect of this is to determine which toolsets appear in the issues list: http://www.boost.org/development/tests/trunk/developer/issues.html In Christ, Steven Watanabe

10 32

[atomic] Support for specialized instructions
by Andrey Semashev 14 May '14

14 May '14

Hi, I've been contemplating the idea of adding support for some specialized atomic instructions to Boost.Atomic. Since I'm only familiar with x86 architecture, my current candidates are: * Increment/decrement with a check for zero result (lock inc/dec). The decrement is the most essential of the two because it would be useful for reference counters of various kinds. The increment is mostly beneficial in terms of code size, and it probably doesn't need the check for zero in most cases. * In-place logical operations (lock and/or/xor). These are useful in cases when the code needs to operate on flags or bit sets but doesn't need the result of the operation. Optional variants can be provided with a test for zero result. * Bit set/reset operations (lock bts/btr). The use cases are similar to the logical operations but the advantage is that the previous value of the altered bit can be returned. BTW, these operations are needed in Boost.Sync to implement mutexes on Windows. All these operations can be implemented through the standard atomic<> interface, and that's what would be done on platforms without support for the specialized instructions. For now the idea is to add special member functions to atomic<>, when used with arithmetic types. I was thinking about providing free functions as well, although I think that the complete set of the standard atomic functions would be required for that. Comments? Opinions?

4 6

[atomic] Major rewrite landed in develop
by Andrey Semashev 14 May '14

14 May '14

Hi, I've merged a major rewrite of Boost.Atomic into develop. The changes are quite massive to describe in a few words, but the most significant ones are: - The interface of atomic<> template and atomic_flag are now completely decoupled from the atomic operations implementation (the backends). It is now more consistent across all platforms and not duplicated everywhere. - atomic_flag and fences are now available through separate headers atomic_flag.hpp and fences.hpp. These headers are still included by atomic.hpp for backward compatibility. - The definition of configuration macros BOOST_ATOMIC_XXX_LOCK_FREE is now available through a separate header capabilities.hpp. Users are able to include it and test these macros before including the rest of Boost.Atomic. Most macros are now defined more correctly based on the sizes of the types (i.e. BOOST_ATOMIC_LONG_LOCK_FREE now actually depends on the size of long and is equivalent to BOOST_ATOMIC_INT32_LOCK_FREE or BOOST_ATOMIC_INT64_LOCK_FREE). - Added support for 128-bit atomic ops with MSVC. The support is always enabled for x86_64. There are some ancient AMD chips that don't support cmpxchg16b, users can define BOOST_ATOMIC_NO_CMPXCHG16B if they want to target those. - Added support for BOOST_ATOMIC_FLAG_INIT, although it is optional and atomic_flag is still zero initialized by default. I did not find a way to implement it and keep compatibility with C++03. - Improved ARM backend with gcc (tested for compilation). Now it supports 64- bit atomics. All operations are written in ll/sc manner instead of a CAS loop. - Added a separate ARM backend for MSVC (tested for compilation). Some support for ARM was added to develop earlier but the new implementation is better optimized (it uses appropriate intinsics wrt memory ordering). - Added support for 64-bit atomic ops for SPARCv9 with gcc (completely untested). - Added support for DEC Alpha backend with gcc (completely untested). It is based on the dead and incomplete code that was present in Boost.Atomic before. - Removed support for IA64 on Windows. Not sure if it is needed, but it can be added relatively easily. There are many more changes. Lots of code duplication removed, bugs with arithmetic overflow fixed and things I don't remember. This new version is the foundation for further improvements that are needed for Boost.Sync. In particular, I plan to add new operations (btr/bts, inplace logical operations) and maybe free atomic functions. You can see in the above list that much of the code is not properly tested, and I have little-to-none experience with some of the platforms. To my knowledge, there are no non-x86 regular testers. Therefore I'd appreciate if people reviewed and tried the code. Please, report any feedback, good or bad. Thank you.

1 0

[graph] Fix for directed_graph::swap
by Ben Pope 14 May '14

14 May '14

https://github.com/boostorg/graph/pull/5 Ben

1 1

compressed_pair breaks with multiple instances of empty types
by Hite, Christopher 14 May '14

14 May '14

I've been abusing compressed_pair to build a compressed_tuple. I'm pretty sure this bug can be fixed using intermediate types on the hierarchy. struct Empty1{}; struct Empty2{}; int i=sizeof( boost::compressed_pair<Empty1, boost::compressed_pair<Empty1, Empty2> >); //boom int j=sizeof( boost::compressed_pair<Empty1, Empty2>); //ok int k=sizeof( boost::compressed_pair<Empty1, Empty1>); //ok int h=sizeof( boost::compressed_pair<std::string, boost::compressed_pair<std::string, Empty2> >); //ok cc1plus: warnings being treated as errors In file included from ..../boost/boost_1_50_0/include/boost/compressed_pair.hpp:21, from /home/w461845/src/edgamm/src/lib/libLogger/include/libLogger/LogChain.hpp:4, from OLogTest.cpp:1: ..../boost/boost_1_50_0/include/boost/detail/compressed_pair.hpp: In instantiation of "boost::details::compressed_pair_imp<Empty1, boost::compressed_pair<Empty1, Empty2>, 3>": ..../boost/boost_1_50_0/include/boost/detail/compressed_pair.hpp:348: instantiated from "boost::compressed_pair<Empty1, boost::compressed_pair<Empty1, Empty2> >" OLogTest.cpp:112: instantiated from here ..../boost/boost_1_50_0/include/boost/detail/compressed_pair.hpp:73: error: direct base "Empty1" inaccessible in "boost::details::compressed_pair_imp<Empty1, boost::compressed_pair<Empty1, Empty2>, 3>" due to ambiguity g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4) Chris Hite This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.

1 0

Re: [boost] Is there any interest in a library for actor programming? [preliminary submission]
by Charousset, Dominik 14 May '14

14 May '14

Lets hope the mail arrives this time ... boost(a)lists.boost.org [129.79.39.203] #<[129.79.39.203] #5.0.0 smtp; 5.4.7 - Delivery expired (message too old) [Default] 451-'4.3.5 Server configuration problem' (delivery attempts: 76)> #SMTP# ________________________________________ From: Dominik Charousset [dominik.charousset(a)haw-hamburg.de] Sent: Friday, May 09, 2014 14:18 To: boost(a)lists.boost.org Subject: Re: [boost] Is there any interest in a library for actor programming? [preliminary submission] On 09.05.2014, at 10:52, Jan Herrmann <jherrmann79(a)gmx.de> wrote: On 08.05.2014 19:30, Dominik Charousset wrote: >> Hi all, >> >> >> attached you'll find the first preliminary submission for Boost.Actor as ZIP file along with the Manual in PDF version. You currently still need CMake, a Boost.Jam build file will follow. The project is hosted at GitHub:https://github.com/Neverlord/boost.actor > > As far as I understand a library with LGPL can not be part of boost (see www.boost.org/development/requirements.html ). So the it should be changed. Yes, we would switch the license to the Boost License should it become accepted. >> To state the obvious: we [1] took our time, but not because we are not taking the boost submission serious. In fact, the opposite is true. We did refine libcppa (which is the base for Boost.Actor) over the last months based on community feedback - feedback from this mailing list, last year's C++Now, GitHub, and libcppa's mailing list. However, we are not just trying to lift our library into Boost. We want Boost.Actor to fit into Boost as good as possible - and we did significant changes to the API (see below), which also took time. Furthermore, we think performance is key when providing a native actor system. Boost.Actor/libcppa has now reached a level of performance with the latest version that lives up to our expectations - and hopefully to the expectations of (future) users as well. A brief performance evaluation [2] is attached. The graphs still mention 'libcppa' instead of Boost.Actor. >> >> I hope the lack of Boost.Jam support is not too much of an issue - I thought it would be a good idea to post the preliminary submission before the C++Now (you can meet me there!), to get people time to play with Boost.Actor beforehand. >> >> >> *Differences between Boost.Actor and libcppa* >> >> If you don't have any experience with libcppa, you can simply skip this. The most visible change is the removal of any_tuple and cow_tuple. The COW tuple implementation of libcppa is in our opinion not general enough and is too intermeshed with the type system. Instead, Boost.Actor provides the class `message` that is an opaque container from a user's point of view. Also, the pattern matching has been reduced to a minimal DSL for defining message handlers. The separate DSL for guard expressions is gone completely (a similar functionality still exists though). Since our pattern matching only worked with messages/any_tuples, we don't see too much use of it outside of Boost.Actor. We are still hoping for native pattern matching in C++ (N3449 proposed this a while ago) in which case our DSL would become unnecessary anyways. As a side-effect of removing all these parts, Boost.Actor has become a streamlined version of libcppa that is easier to grasp and that will be easier to mai > ntain i > n the long run as well. >> >> >> *Boost.Actor depends on...* >> >> variant, optional, none, string_algorithms, intrusive_ptr, thread (currently as header-only dependency), context/coroutine (for cooperatively scheduled blocking actors). Some examples also require program_options. >> >> >> *Boost.Actor does NOT use...* >> >> (1) MPL. Boost.Actor uses a ludicrous amount of metaprogramming based on boost::actor::detail::type_list. I've tried to port it to MPL and wasted almost two days doing so. MPL is a great C++ library. Unfortunately, C++98, not C++11. Even after adding variadic helpers to reduce the amount of template instantiations, it would still explode and fail to compile. I've stopped after writing half the size of the current type_list utility functions and still wasn't able to reduce the amount of template instantiations significantly enough. That being said, I am looking forward to the GSoC project for MPL11. >> >> (2) Serialization. The first and most obvious problem I have with this library is the lack of a portable binary archive. String serialization is sufficient for a lot of applications, but the performance hit for both networking overhead and the string serialization itself is not acceptable in an actor system. Furthermore, simply adding such a binary archive would not be enough. The library does not give you a platform-independent representation of the type names, which is crucial. Also, one cannot create an instance of a type given only its type name and then deserialize its values from a network stream (I was thinking of ETI::key_register using the uniform names and ETI::find, but it only solves a part of the problem). Adding all of these capabilities on top of boost.serialization plus writing a portable binary archive (or maybe use something like EOS - http://epa.codeplex.com/) would probably result in more code and most likely in a more complicated design, i.e., would be > harder to maintain. Maybe I miss the forest for the trees here and some experienced boost.serialization user knows a straightforward way I don't see. However, maybe there is interest in extending boost.serialization. I'd be happy to work on patches for adding uniform names, etc. >> >> (3) Boost.Asio. There is definitely potential to port the low-level parts of the middleman to Asio, I think. These changes would be transparent to the user, though, since users really only use the broker and can forget about the rest. >> >> >> *Separating parts of Boost.Actor?* >> >> Vicente J. Botet Escriba suggested to separate some parts of library. Namely the constexpr atom() [the other parts he suggested were removed, btw]. Aside from that, there are some C++11 utility functions that I think would be useful for other developers as well. Namely int_list [3] which can be used to create indices for variadic types such as tuples to allow users to apply the values of a tuple to a functor with apply_args [4]. type_list [5] is a powerful tool too, but I think this functionality goes to MPL11 anyways. Something that might be worth lifting to the boost namespace is unit [6], which makes metaprogramming (for me) a lot easier by providing an easy way of lifting void to something useful and don't need to worry whether or not it might end up in a tuple or variant. MPL already has void_t, but it doesn't seem to be indented to be used the way I use unit. For binary serialization of floats, there is IEEE 754 packing/unpacking [6] that is based on http://beej.us/gu > ide/bgn > et/examples/pack2.c > > What is the difference from your int_list and std::integer_sequence (http://en.cppreference.com/w/cpp/utility/integer_sequence) ? The difference is: integer_sequence didn't exist when I wrote int_list. But it's good to know that there's a standard way to do it in C++14. Thanks for the hint. By the way, is there any policy regarding C++11 in Boost? Should we just skip it and directly aim for C++14? The code base is currently C++11 compliant. Switching to C++14 would make a thing or two easier (i.e. I could remove some code). >> Sorry for the wall of text, the Mail got longer and longer somehow ... >> >> >> >> [1] "We" are a working group at the University of Applied Sciences Hamburg: http://inet.cpt.haw-hamburg.de/ >> >> [2] The sources for all benchmark programs can be found here: https://github.com/Neverlord/cppa-benchmarks, please keep in mind that the evaluation uses libcppa, so the API used in the benchmarks is different. >> >> [3] https://github.com/Neverlord/boost.actor/blob/a0cab41e2946df7d751c59dfead0c… >> >> [4] https://github.com/Neverlord/boost.actor/blob/ea53a515e09a98baa173ad379127c… >> >> [5] https://github.com/Neverlord/boost.actor/blob/58d6177837788b2e54b8547531bda… >> >> [6] https://github.com/Neverlord/boost.actor/blob/644a47760d6b55eef438a81d7bcdc… >> >> [7] https://github.com/Neverlord/boost.actor/blob/ea53a515e09a98baa173ad379127c…

1 0

Re: [boost] Is there any interest in a library for actor programming? [preliminary submission]
by Dominik Charousset 14 May '14

14 May '14

> On 11 May 2014, at 09:36 pm, Larry Evans wrote > > Hi Dominik, > > On 05/08/14 12:30, Dominik Charousset wrote post > http://article.gmane.org/gmane.comp.lib.boost.devel/250747 > including: > [snip] >> >> [3] https://github.com/Neverlord/boost.actor/blob/a0cab41e2946df7d751c59dfead0c… > > However, I have a question about the implementation. > > https://github.com/Neverlord/boost.actor/blob/a0cab41e2946df7d751c59dfead0c… > > uses a recursive call using a List<typename ...Ts> which is 1 shorter > than the argument list, List<T0, Ts...>. > Why not just pass sizeof...(T0, Ts...): > > http://en.cppreference.com/w/cpp/language/sizeof... > > and keep adding indices while decreasing this sizeof value, > as done here: > > http://svn.boost.org/svn/boost/sandbox/variadic_templates/boost/mpl/package… > > in the package_range_c template class where: > > Start value would be 0 > and Finish value would be sizeof...(T0, Ts...) > > It achieves the same result, but without producing unneeded > instantiations. For example: > > package_range_c<std::size_t,0,sizeof...(mpl::vector<T0,T2,T3>>::type > package_range_c<std::size_t,0,sizeof...(mpl::vector<S0,S2,S3>>::type > > would produce 1 instantiation of: > > package_range_c<std::size_t,0,3> > > whereas the int_list.hpp code would, IIUC, produce the same > number of instantiations for the T's and S's. > > Wouldn't using the sizeof... method be easier to understand > as well as produce few instantions? Reviewing the code again, I think there's really no good reason to recurse over Ts. Doing the unrolling in il_indices recursively with only two specializations is a simple design, but the instantiations of type_list are indeed unnecessary. Also, the dependency to type_list could be dropped when unrolling based on sizeof.... > -regards, > Larry > > NOTE: I tried to post to the newsgroup; however, apparently my > post got lost :( Let's hope the list is working again...

1 0

Boosr review of the 'convert' library starts tomorrow May 21.
by Edward Diener 13 May '14

13 May '14

The review of the Convert library starts tomorrow Monday, May 12 and goes through Wednesday May 21. The Convert library builds on the boost::lexical_cast original design and experience and takes those conversion/transformation-related ideas further. * to be applicable to a wider range of conversion-related use-cases, * to provide a more flexible, extendible and configurable type-conversion framework. The Convert library can be cloned from GitHub at https://github.com/yet-another-user/boost.convert. The library follows the modular-boost format. Just clone it to modular-boost/libs in the 'convert' subdirectory and run 'b2 headers' in order to create a link to its header file directory in the modular-boost/boost subdirectory. The library comes with documentation in its top-level index.html or doc/html/index.html file. The library is by Vladimir Batov and is a second reiteration with a greater focus of his library that was reviewed in the past. I am Edward Diener and I am again serving as the review manager of the library. Comments, questions, and reviews will all be welcome for the library. Please try to sum up your review by answering these questions: What is your evaluation of the design? What is your evaluation of the implementation? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library? Did you try to use the library? With what compiler? Did you have any problems? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? And finally: Do you think the library should be accepted as a Boost library? As always whether you do or do not feel that the library should be accepted into Boost please specify any changes you would like to see for the library to be better in your estimation.

4 3

[RFC] Modern CORBA C++ IDL Mapping and implementation
by Felipe Magno de Almeida 13 May '14

13 May '14

Hello Boosters, Where I work we are implementing an open source, modern, CORBA implementation and IDL mapping. We want it to support C++ and C++11 IDL mapping, but we also want to create another IDL mapping. This new IDL mapping is being experimentated in the following url https://github.com/expertisesolutions/mORBid/tree/concepts It still has some very problematic issues (like compilation-time of generated code) and of course it is still far from completion. But, we would like to hear suggestions about this approach. What we did was that an IDL interface is mapped to a typedef for boost::type_erasure (I found the idea quite cool for the reasons that I'll mention below) with the requirements defined in the IDL, e.g. its operations. The IDL also emits a model for this type_erasure which is the actual stub class and is called remote_reference. It also emits a proxy_reference model for the same type_erasure typedef which receives a std::reference_wrapper and proxies the calls, this is needed because type_erasure can't switch between by-reference and by-value in runtime. Why I believe this approach is better than current IDL to C++11 mapping: Because the IDL to C++11 mapping is too intrusive. You can't really use normal classes you have written for use as servants in CORBA because you have to inherit from Skeletons classes *and* you have to use the *exact* same signature as defined in the mapping. This is *way too restricted*. This is also inerent to the OO paradigm that CORBA uses. But, we can mimic the same features using type-erasure instead of directly using dynamic polymorphism. This gives a much greater freedom to users. It might be that Boost.type_erasure is not the best tool here because of compile-time and compiler memory usage, but the idea surely is. We still haven't seriously profiled boost.type_erasure yet, but we will do so as soon as possible. I think it might be very interesting to experiment with lite concepts and Boost.concept_check as well. Also, we created a EDSL for GIOP and IIOP mapping based on the boost.spirit infrastructure. We use that to treat alignment and endianness automatically and to use the same grammar for generation and parsing of IIOP messages. The message header grammar is defined like this: start = "GIOP" & octet('\1') /* GIOP major version */ & octet('\0') /* GIOP minor version */ & endianness [ octet(MessageType) /* message_type */ & raw_size(ulong_)[body] ] ; Which is compiled to IIOP parser or generator through boost.spirit infrastructure of make_terminal, make_directive and etc. This works splendid well and is really easy to use, extend, is statically checked and has great performance. Whoever feel interested, please take a look and comments are highly appreciated. Regards, -- Felipe Magno de Almeida

5 5

Re: [boost] Is there any interest in a library for actor programming? serialization + uniform names
by Andrzej Horoszczak 13 May '14

13 May '14

2 1

Lack of response to pull requests [resend]
by Beman Dawes 13 May '14

13 May '14

IMO it should be a Boost policy that anyone who submits a pull request deserves a response within a reasonable period of time. *What is a "response"?* GitHub pull requests have a "Comment" mechanism, so that's the best mechanism as it ensures reaching the submitter even they don't read the developer list. We also need to delineate some common responses, but that can wait until the overall policy is agreed upon. *What is a "reasonable period of time"?* This may be a bit of a bike shed discussion since whatever we start with may need adjustment based on experience. Would two weeks be a good starting point? *Who should step in if there is no response from the library maintainer?* The Community Maintenance Team IMO is the logical choice. A pull request that does not receive a timely response may be an early warning sign that the library involved does not have an active maintainer. The CMT folks are interested maintenance and already have processes to review pull requests. This would be an expansion of their mandate, and details need to be worked out such as what happens if the library maintainer is just busy at the moment. *What should the pull submitter do if there is no response within the reasonable period of time?* Send an email to the CMT pointing to the open pull request. (It would be nice if the submitter didn't have to do anything, but that implies the ability to monitor open pull requests. See "[GitHub] List open pull requests for all libraries?") Comments? --Beman

3 2

Lack of response to pull requests [resend]
by Beman Dawes 13 May '14

13 May '14

IMO it should be a Boost policy that anyone who submits a pull request deserves a response within a reasonable period of time. *What is a "response"?* GitHub pull requests have a "Comment" mechanism, so that's the best mechanism as it ensures reaching the submitter even they don't read the developer list. We also need to delineate some common responses, but that can wait until the overall policy is agreed upon. *What is a "reasonable period of time"?* This may be a bit of a bike shed discussion since whatever we start with may need adjustment based on experience. Would two weeks be a good starting point? *Who should step in if there is no response from the library maintainer?* The Community Maintenance Team IMO is the logical choice. A pull request that does not receive a timely response may be an early warning sign that the library involved does not have an active maintainer. The CMT folks are interested maintenance and already have processes to review pull requests. This would be an expansion of their mandate, and details need to be worked out such as what happens if the library maintainer is just busy at the moment. *What should the pull submitter do if there is no response within the reasonable period of time?* Send an email to the CMT pointing to the open pull request. (It would be nice if the submitter didn't have to do anything, but that implies the ability to monitor open pull requests. See "[GitHub] List open pull requests for all libraries?") Comments? --Beman

2 1

Boost lists back up but messages since May 9 probably lost
by Beman Dawes 13 May '14

13 May '14

Here are the details: ---------- Forwarded message ---------- From: DongInn Kim Date: Tue, May 13, 2014 at 6:48 AM Subject: Re: Boost lists are down To: Beman Dawes <bdawes(a)acm.org> Hi Beman, I am so sorry that there was a problem that I could not notice. The boost mail server and mailing list server were working OK but the spam filter server that the boost mail server use disabled our access, which I did not do and I can not do. I talked to the guy who manages the spam filter and make sure that they take care of the boost mails as well. It seems that it starts to flow but I am afraid that the mails that wowbagger had not delivered since May 9 are missing. :-( I will talk to the guy to see if there is a way to push the valid mails (i.e., non-spam mails) in the spam filter. I suspect that they are all already gone. Regards, -- - DongInn

1 0

A problem in the boost mailing list
by Kim, DongInn 13 May '14

13 May '14

Dear Boost mailing list users, My name is DongInn Kim, sysadmin of the boost mailing list. I am so sorry that there was a problem that I could not notice until this morning. The boost mail server and mailing list server have been working OK but the spam filter server that the boost mail server uses disabled our access, which I did not do and I can not do. I talked to the guy who manages the spam filter and make sure that they take care of the boost mails as well. It seems that it starts to flow but I am afraid that the mails that wowbagger had not delivered since May 9 are missing. :-( I will talk to the guy to see if there is a way to push the valid boost mails (i.e., non-spam mails) in the spam filter but I am afraid that they are all already gone. Again, I am sorry for the missing emails. Regards, -- - DongInn

1 0

Re: [boost] boost] [asio] intergrate with message loop how to
by microcai 13 May '14

13 May '14

2014-05-09 20:08 GMT+08:00 Nat Goodspeed <nat(a)lindenlab.com>: > On May 9, 2014, at 6:18 AM, microcai <microcai(a)fedoraproject.org> wrote: > >> 2014-05-05 21:57 GMT+08:00 Nat Goodspeed <nat(a)lindenlab.com>: >>> >> >>> Perhaps you might propose a cross-platform asio API extension that could give you control at the times you want, using the completion-handler mechanism? >> >> then there will be endless ways of loops that you need to integrated >> into asio. glib, qt, WIN32 message loop ... etc. > > Understood. I am not proposing that specific message-loop code be absorbed into Asio. I am asking whether you (or any interested reader) might be able to define an extension API that permits / facilitates a consuming Asio application to integrate with any required message loop. some thing like io_service::wait_events(); but , does not dispatch the event. I can run seperated thread to call this, then post message to gui thread, let gui thread run io_service::poll() to dispatch the handlers; if the hander is executed in gui thread, we can avoid lots of synchronization code between gui thread and asio thread( if io_service::run() has to be run in seperated thread. ).

1 0

test msg, please ignore
by Joaquín Mª López Muñoz 13 May '14

13 May '14

________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx

1 0

Boost Python Xcode Example
by Jared McIntyre 12 May '14

12 May '14

I have been trying to get the Boost Python example working when compiling in Xcode. Everything compiles at the moment, but the module fails to load in python. It fails to find the module if it has an extension of either .pyd or .dylib, and .so has the error "ImportError: dynamic module does not define init function” even though the function should be there. I’m sure that I have something setup incorrectly and was wondering is anyone has a working Xcode project example that I could take a look at to see where I’ve gone wrong. Thank you, Jared McIntyre

1 1

[GitHub] List open pull requests for all libraries? [resend]
by Beman Dawes 12 May '14

12 May '14

We need to be able to monitor the open pull requests for all Boost libraries, not just a individual library. I'm not seeing any canned way of doing that via the GitHub web site. Am I missing something? It does seem possible to access the required information via the GitHub API. Is that the best approach to take? Does anyone know how to do this? Thanks, --Beman

1 0

[asio] Windows 2000 no longer supported?
by Andrey Semashev 11 May '14

11 May '14

Hi, I've been reported this ticket: https://svn.boost.org/trac/boost/ticket/10016 that says that Boost.ASIO requires SO_UPDATE_CONNECT_CONTEXT now, which is only implemented since Windows XP. Is Windows 2000 support officially dropped in Boost.ASIO?

1 1

[GitHub] List open pull requests for all libraries?
by Beman Dawes 10 May '14

10 May '14

We need to be able to monitor the open pull requests for all Boost libraries, not just a individual library. I'm not seeing any canned way of doing that via the GitHub web site. Am I missing something? It does seem possible to access the required information via the GitHub API. Is that the best approach to take? Does anyone know how to do this? Thanks, --Beman

1 0

Lack of response to pull requests
by Beman Dawes 10 May '14

10 May '14

IMO it should be a Boost policy that anyone who submits a pull request deserves a response within a reasonable period of time. *What is a "response"?* GitHub pull requests have a "Comment" mechanism, so that's the best mechanism as it ensures reaching the submitter even they don't read the developer list. We also need to delineate some common responses, but that can wait until the overall policy is agreed upon. *What is a "reasonable period of time"?* This may be a bit of a bike shed discussion since whatever we start with may need adjustment based on experience. Would two weeks be a good starting point? *Who should step in if there is no response from the library maintainer?* The Community Maintenance Team IMO is the logical choice. A pull request that does not receive a timely response may be an early warning sign that the library involved does not have an active maintainer. The CMT folks are interested maintenance and already have processes to review pull requests. This would be an expansion of their mandate, and details need to be worked out such as what happens if the library maintainer is just busy at the moment. *What should the pull submitter do if there is no response within the reasonable period of time?* Send an email to the CMT pointing to the open pull request. (It would be nice if the submitter didn't have to do anything, but that implies the ability to monitor open pull requests. See "[GitHub] List open pull requests for all libraries?") Comments? --Beman

1 0

Re: [boost] [GSoC, MPL11] Community probe
by Louis Dionne 09 May '14

09 May '14

Gonzalo Brito Gadeschi <g.brito <at> aia.rwth-aachen.de> writes: > I have a question: the proposal and library are called MPL11. That is true, but I'm starting to realize that it's a very bad name. The project started about two years ago, when C++14 was still out of my sight. Be reassured that I always consider the latest version of the language, not only C++11. > In my experience, relaxed constexpr allows for beautiful metaprogramming > with respect to C++11, in particular when combined with Boost.Fusion, and I > think that it is really a game changer with respect to C++11 constexpr, > since it allows not only "functional" metaprogramming but also "imperative" > metaprogramming, significantly lowering the learning curve of > metaprogramming for C++ programmers. Could you please expand on the nature of metaprogramming you have been doing with constexpr? Are you talking about manipulating values of a literal type, or about "pure type" computations? See below for more on that. > Have you consider the influence of relaxed constexpr (C++14) in your > library? > > Could it simplify the design/implementation/usage of the MPL? I did consider the impact of C++14 on the design of the library, and I still am. At this point, my conclusion is that we must define what we mean by a "template metaprogramming library". I differentiate between two main kinds of computations that can be done at compile-time. The first is manipulating "pure types" with metafunctions (e.g. type traits): using void_pointer = std::add_pointer_t<void>; using pointers = mpl::transform< mpl::list<int, char, void, my_own_type>, mpl::quote<std::add_pointer> >::type; The above example is completely artificial but you get the point. The second kind of computation is manipulating values of a literal type at compile-time. using three = mpl::plus<mpl::int_<1>, mpl::int_<2>>::type; The MPL wraps these values into types so it can treat computations on those as computations of the first kind, but another library could perhaps handle them differently (probably using constexpr). constexpr int three = plus(1, 2); It is easy to see how constexpr (and relaxed constexpr) can make the second kind of computation easier to express, since that is exactly its purpose. However, it is much less clear how constexpr helps us with computations of the first kind. And by that I really mean that using constexpr in some way to perform those computations might be more cumbersome and less efficient than good old metafunctions. As for using constexpr to express computations on literal values, another question arises. Should there be a general library for handling those at compile-time, or should it be the responsibility of a well written domain- specific library to provide means to perform domain-specific computations at compile-time whenever possible? For example, should the MPL11 provide constexpr math functions, or should the std:: math functions be constexpr whenever possible? Another example is std::array. While the MPL11 could provide a constexpr container for homogeneous values of a literal type, simply changing the `begin` and `end` of `std::array` to be constexpr would make it possible to iterate on the array at compile-time. template <typename T, std::size_t n> constexpr T sum(std::array<T, n> array) { T s{0}; for (T i: array) // awesome s += i; return s; } constexpr std::array<int, 5> array{{1, 2, 3, 4, 5}}; static_assert(sum(array) == 15, ""); Unfortunately, I don't think this is happening in C++14, but I could be mistaken. Still, you certainly understand the implications. So a valid question that must be answered before I/we can come up with a "final" version of the library that can be proposed to Boost (or for standardization) is: "What is the purpose of a TMP library?" Once that is well defined, we won't be shooting at a moving target anymore. Right now, I have avoided these questions as much as possible by focusing on computations of the first kind. For those computations, my research so far shows that constexpr is unlikely to be of any help. If someone can come up with counter-examples or ideas that seem to refute this, _please_ let me know and I'll even buy you a beer in Aspen. This is _very_ important; it's central to my current work. > Would a rewrite of MPL11 be necessary afterwards (MPL14)? If constexpr turns out to be a game changer for computations of the first kind, then I suspect a large part of the current MPL11 would have to be rewritten. Of course, I tried to prevent this from happening by going slowly and looking at all the possibilities, but these things happen and it's part of the game. As for computations of the second kind, not _much_ work (comparatively) has been done on them because I knew it was a can of worms. So even drastic changes would not kill the library as it stands. Finally, if any of this does not make sense to someone, please let me know (on this list or privately) so I can explain further and correct any fallacious reasoning on my part. I hope this answers your questions; sorry for the long-winded answer but I think it can be informative for others too. Regards, Louis

5 13

Re: [boost] Is Boost dead? [Re: Anyone is interested in being
by Sebastian Theophil 09 May '14

09 May '14

> The dev list is down about 30% 2011 onwards as against before 2011. > > Monthly commits to Boost are about 500 per month since 2011 as > compared to about 1000 per month before 2011. > Niall, don't forget that the marginal usefulness of every new contribution might be shrinking. Many Boost libraries were essential for C++03 users but become less useful once you've migrated to C++11. They were testing grounds for new standard features. The better the standard library, and the better the programming language itself, the less need there will be for an extensive library as boost. Seen through that lens, a dying boost library might be a good sign. Though I don't actually believe the dying part yet. There are still many useful libraries in boost that haven't made it into the standard. There are even more libraries I'd like to be included in boost, thus becoming default choices, even if they can never make it into the standard. Regards Sebastian -- Dr. Sebastian Theophil | stheophil(a)think-cell.com Senior Software Engineer We are looking for C++ Developers: http://www.think-cell.com/career think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Sch?dl

2 1

[config] Should BOOST_NO_CXX11_ALLOCATOR be undefined for libcpp without std=c++11
by Glen Fernandes 09 May '14

09 May '14

I observed the absence of BOOST_NO_CXX11_ALLOCATOR with clang and libc++ without -std=c++11. Is this intended? Right now BOOST_NO_CXX11_ALLOCATOR's absence is (in my view) an indication of whether C++11 allocators, including class template std::allocator_traits, are supported - and without -std=c++11 neither could be. Glen

2 3

[Align] and [smart_ptr] local copy of modular boost not updating correctly.
by Fletcher, John P 08 May '14

08 May '14

Boost smart_ptr has changed to use the new library boost align which has just passed its review. Unfortunately this change does not automatically carry forward into my local copy of modular boost. I have a directory libs/align but it is empty. What do I need to do to get this new library (and any other new submodules) into my local copy? Thanks John

3 2

JSON Archives for Boost.Serialization
by Matt Calabrese 08 May '14

08 May '14

I'm looking into implementing JSON archives to be used with Boost.Serialization in a manner similar to the xml archives. After a quick search I see that others have worked on this (2008 GSOC project?), though there is nothing currently in Boost that I see. Is there any existing work on this that is up somewhere before I implement my own from scratch? -- -Matt Calabrese

3 3

[thread] Request review of new synchronisation object, boost::permit<>
by Niall Douglas 07 May '14

07 May '14

Dear Boost, Review and commentary upon a proposed new Boost object, boost::permit<> is invited. A quick description of their purpose: "Permits come in two variants, consuming and non-consuming. There is always a one-to-one relationship between the granting of a permit and the receiving of that permit, the only difference with the non-consuming variant is that the permit is automatically regranted as soon as it is consumed. This leads to the only API difference to condition variables: permit<consuming=true> provides notify_one() but not notify_all(), whilst permit<consuming=false> provides neither and you will have to use grant() and revoke() instead. When deciding to substitute permits for condition variables, you will need to decide carefully which kind of permit is the correct substitute." "Permit objects are actually very similar to a void promise/future i.e. they act as a reusable promise/future pair but without transporting any value or exception state, just the permission to proceed. This is due to their original design intention, which was as a promise/future equivalent for C11 (see below for their history, and note that the original C API is available in the boost::c_permit namespace and documentation can be found at https://ci.nedprod.com/job/Boost.Thread%20Build%20Documentation/lastSu ccessfulBuild/artifact/boost-trunk/boost/thread/permit/latex/pthread_p ermit_reference.pdf). As such, they can be very useful for situations where a promise/future is too heavy (permits can spin instead of sleep, plus they need not be repeatedly constructed and destructed)." There is lots more detail at their documentation page: https://ci.nedprod.com/job/Boost.Thread%20Build%20Documentation/Boost. Thread_Documentation/libs/thread/doc/html/thread/synchronization/permi t_ref.html Source code of Permit containing fork of Boost.Thread: https://github.com/ned14/thread/tree/permit_object They come with a functional and load soak test suite. They work on Windows, Linux, FreeBSD and I believe OS X. Any other questions do ask. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

8 27

[TTI] macro to "box" types for subsequent traits extraction?
by Rein Halbersma 07 May '14

07 May '14

Hi everyone, this is my first post to this mailinglist, so I hope I follow the proper conventions around here (yes, I did read the Discussion Policy). I have a small feature request for the Type Traits Introspection library: a macro BOOST_TTI_BOX_TYPE(U) that defines a class template box_type<T> with a nested typedef named "type" that equals T::U. Rationale: because box_type<T> is a metafunction that can be supplied to mpl::eval_if, this facilitates user-defined traits that extract a nested type U, but can fall back to a (user-defined) default type. This mimics the C++11 allocator_traits that also provide defaults for allocators that lack certain nested typedefs or other properties. Small self-contained example: http://coliru.stacked-crooked.com/a/76b9abf4aaf00350 One could probably also define similar "boxing" macros to go along with the has_template and other introspection tools in TTI. Would this be considered a useful feature? Rein

3 4

[locale] Who owns/has commit access to review/merge a pull request?
by Chris Stylianou 07 May '14

07 May '14

I have a pull request on boost::locale (on the develop branch), but it appears there has no activity in this repository since the SVN -> Git migration occurred. Who actually maintains boost::locale? I would really like to have this pull request review and then hopefully merge, so that it makes the 1.56 release :) -- View this message in context: http://boost.2283326.n4.nabble.com/locale-Who-owns-has-commit-access-to-rev… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 5

Constant iterator of Single Pass Range
by Jan Hudec 07 May '14

07 May '14

Hello All, The documentation of [Single Pass Range][1] in Boost.Range says that there should be both `iterator` and `const_iterator` associated types and both const and non-const overloads for `begin` and `end`. However if it is really a single-pass range, I don't see a way to implement a `const_iterator` that would work on `const` reference to the range, because the `operator++` of the iterator involves calling a non-const method of the range. For example the `std::istream_iterator::operator++` calls `std::istream::operator>>`, which is non-const and so there is no `const_istream_iterator`. The `istream_range` cheats around this a little, because the range is a wrapper around the stream, not the stream itself. But when I have similarly behaving class that I can make itself be a range, do I really have to work around this using a wrapper, or can the requirement be relaxed in practice? [1]: http://www.boost.org/libs/range/doc/html/range/concepts/single_pass_range.h… -- Jan Hudec <bulb(a)ucw.cz>

4 8

[1.56] Release status?
by Joaquin M Lopez Munoz 06 May '14

06 May '14

Hi, Seems like Boost 1.56 release schedule has been postponed sine die. Is there any blocking issue with the SVN->Github transition that the release depends upon? Thank you, Joaquin M López Muñoz Telefónica

3 2

Help transfer type_index library to the boostorg
by Antony Polukhin 06 May '14

06 May '14

Hi, TypeIndex library was accepted into the Boost. Only a few minor issues remain unfixed so it's time to transfer the library to the boostorg. Unfortunately I have no permissions to do so. Could someone help? -- Best regards, Antony Polukhin

2 2

marking regression test failures as expected
by Andrzej Krzemienski 06 May '14

06 May '14

Hi, I noticed in the regression tests results taht some failing tests are marked as "fail*" in greyish color indicating that the failure is expected along with the explanation why. E.g., http://www.boost.org/development/tests/develop/developer/output/teeks99-03a… Question: how can I indicate that the new failure is expected in the same manner? Regards, &rzej

3 3

Anyone driving from/to Denver?
by Sebastian Redl 06 May '14

06 May '14

Hi, I could only get my bonus miles flights to Denver, not Aspen, so I'm wondering whether anyone else is only flying from/to Denver and driving the rest of the way. I would be interested in sharing that car. Please let me know. Sebastian

3 3

[atomic] Constraints on failure_order?
by Bjorn Reese 05 May '14

05 May '14

According to [1]: "The compare_exchange_weak/compare_exchange_strong variants taking four parameters differ from the three parameter variants in that they allow a different memory ordering constraint to be specified in case the operation fails." According to std::atomic there are some constaints on failure_order. Is this also the case for boost::atomic? [1] http://www.boost.org/doc/html/atomic/interface.html

2 1

[asio] intergrate with message loop how to
by microcai 05 May '14

05 May '14

on platform windows, asio is using IOCP. and IOCP handel got signaled when there is pending events thus we can use MsgWaitForMultipleObjectsEx to wait on both the message queue and the IOCP. when we get a message, call PeekMessage and then DispatchMessage just like the mornal message loop. when we get IOCP singaled, call boost::asio::io_service::pull_one() and we processed the IO events ! by this way, we can have a thread that does both GUI and IO. that's very handy for non-performance critical applications. but, we can't access to the IOCP HANDLE used by asio. that's said. very said. on platform Linux, asio is using epoll. we can get X11 socket, and use asio to monitor that socket, and again calls X11 functions when the socket gets ready. thus, we can intergrate X11 message loop with asio, that's fine. if we are using gtk, it is more convinent to have epoll fd monitored by glib first, and then goes to run asio::io_service::pull_one(). again, that required access to epoll fd used by asio. if asio can expose these internal HANDLE or fd , that'll going to be more powefull !

2 1

[TypeIndex 3.0] Review Manager's Report
by Niall Douglas 04 May '14

04 May '14

Dear Boost, The second round of peer review of proposed Boost.TypeIndex finished on Wed 30th, and here is the review manager's report. My thanks to the five reviewers who took the time and trouble to submit full reviews, plus to everyone else who commented. Votes regarding acceptance: 4 voted to accept TypeIndex into Boost immediately. 1 voted to accept into Boost with conditions. Overall: I recommend immediate acceptance into Boost. Conditions: 1. No one liked the present boost::typeind namespace, almost anything else would be better. I see the namespace has already changed in the develop branch to boost::typeindex, so I think this is already solved. Other common comments: * More than one reviewer mentioned how they liked the docs. * More than one reviewer expressed a desire for an ability to programmatically parse through type specifier strings. I agree with Antony that that is another library which isn't TypeIndex (something Boost.Spirit based which works directly with mangled symbol string representations, representing them as a partial AST - preferably also with a libclang compatible backend - would be great, but that is a totally different library and TypeIndex 3.x provides extensibility for such an additional function). * More than one reviewer sought some method of preventing link if you mix up incompatible uses of TypeIndex and/or with RTTI. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

1 0

when can a trac ticket be considered closed
by Andrzej Krzemienski 04 May '14

04 May '14

Hi Everyone, Sorry for the silly question; at which point in Modular Boost Library workflow should I close a Trac ticket? Is it when I commit the relevant changes to branch master? Regards, &rzej

4 6

[GSoC, MPL11] Community probe
by Louis Dionne 04 May '14

04 May '14

Dear Boost, As a follow-up to [1], I am probing the community to help clarify what are your needs/expectations with respect to a new TMP library. Your involvement is important as it will help direct my work on an eventual successor to the MPL (in consultation with my mentor, Joel Falcou). I expect this to be the first of a series of probes to the community. This one focuses on backward compatibility with the MPL. COMMUNITY PROBE --------------- Please comment on how you would like to see the following points addressed by a new TMP library: (1) Backward compatibility with the MPL. Should it be a swap-in replacement? Is it enough to have an easy way to interoperate between both libraries (think Fusion/MPL interoperation)?. (2) Learning curve for users coming from the MPL. How important is it for you to be able to reuse your knowledge of the MPL (not of TMP, but of the MPL itself)?. Please get involved by posting constructive material. Regards, Louis Dionne PS: As I expect this to be the first of a couple of community-wide probes, is there a preferred way to do these (on the ML or elsewhere)? PPS: If the thread gets very active, I might be slow to answer. I'm spread between this and my finals. [1]: http://article.gmane.org/gmane.comp.lib.boost.devel/250424

8 21

[thread] shared_spinlock_t idea or faster shared_lock
by Antony Polukhin 02 May '14

02 May '14

Hi, This is just a refining of idea that was once implemented and worked well. The idea was to make shared spin lock. Here is some pseudo-code: class shared_spin_lock { atomic_max_uint_t state_; lock_shared() { do { // CAS loop auto snapshot = state_.load(); if (snapshot.has_writer_bit_set()) { reader_wait(); // waiting for writer to finish continue; } auto new_state = snapshot + 1; } while(!CAS(state, new_state)); } unlock_shared() { --state; } lock() { do { // CAS loop auto snapshot = state_.load(); if (snapshot.has_writer_bit_set()) { writer_wait(); // waiting for other writer to finish continue; } auto new_state = snapshot.set_writer_bit(); } while(!CAS(state, new_state)); // we have set the writer bit, now waiting for readers to finish while (state_.readers_count) ; // busy loop, can we do better? writer_started(); } unlock() { auto snapshot = state_.reset_writer_bit(); writer_finished(); ASSERT (snapshot.has_writer_bit_set()); } }; When all the *_wait() and writer_*() functions do nothing we get a shared spinlock. Now if we add helper mutex and make all the *_wait() functions to lock and unlock mutex; writer_start() - lock the mutex; writer finished() - unlock the mutex... we get a simplified shared_mutex that is faster (in theory) than current implementation. Is there an interest in such shared_spinlock_t? Any comments, suggestions? -- Best regards, Antony Polukhin

6 6

Misuse of warnings-as-errors?
by Chris Cooper 02 May '14

02 May '14

I’m pretty new to boost, but I’m sensing a desire to have cake and eat it too … correct me if I’m wrong of course! I see several places in the bug tracking system where people complain about compiler warnings and are told that fixing that sort of thing is completely ridiculous and the bugs are closed as “won't fix”. But then warnings-as-errors is enabled in several places – libs/pool/test, libs/type_traits/test, libs/units/test, etc. Shouldn’t boost have one or the other? Either warnings are important enough to treat them as errors in the unit tests (in which case they should get fixed) or else they’re not that important and warnings-as-errors shouldn’t be enabled by default anywhere? Thanks, Chris

7 6

[typeindex v3.0] Peer review begins Mon 21st ends Wed 30th
by Niall Douglas 02 May '14

02 May '14

Dear Boost, A second round of community review begins for proposed Boost.TypeIndex on Mon 21st, lasting ten days. I should apologise as it's my fault for starting another peer review straight after Boost.Align ends, however I was busy as Google Summer of Code admin until today, and I will be preparing to talk at C++ Now straight after this review ends. I hope that this doesn't affect the community's willingness to contribute to the review. Reminder of the report from the last TypeIndex v2.1 review: https://groups.google.com/forum/#!topic/boost-list/TeiSdkRkUF0 Reminder of the original peer review announcement: http://boost.2283326.n4.nabble.com/TypeIndex-Peer-review-period-for-li brary-acceptance-begins-ending-Thurs-21st-Nov-td4654788.html Source code: https://github.com/apolukhin/type_index/zipball/master Github: https://github.com/apolukhin/type_index Documentation: http://apolukhin.github.com/type_index/index.html Changes in TypeIndex v3.0 since v2.1 (from my own review of it): 1. Documentation is hugely improved over v2.1, lots of side by side examples illustrating the differences and similarities. 2. You can now create your own custom type indices using an extensible framework. 3. boost::typeind::type_info now exports raw_name() and pretty_name() to maximise MSVC-GCC compatibility, and to solve point 1 but not point 2 in the v2.1 report. 4. The undefined behaviour trick used in v2.1 has been replaced with a cast via the placeholder type boost::typeind::detail::ctti_data which can be viewed in https://github.com/apolukhin/type_index/blob/master/include/boost/type _index/ctti_type_index.hpp. There is an explanation in the comments there about this technique's compatibility with the C++ standard. 5. TypeIndex now defines everything in the boost::typeind namespace instead of the boost namespace. So: 1. What is your evaluation of the design? 2. What is your evaluation of the implementation? 3. What is your evaluation of the documentation? 4. What is your evaluation of the potential usefulness of the library? 5. Did you try to use the library? With what compiler? Did you have any problems? 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 7. Are you knowledgeable about the problem domain? And finally, every review should answer this question: 8. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Thanks, Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

7 29

Spam in tickets
by Antony Polukhin 02 May '14

02 May '14

Hi, Could some one see what can be done with this spam https://svn.boost.org/trac/boost/ticket/9963<https://svn.boost.org/trac/boost/ticket/7108> ? -- Best regards, Antony Polukhin

4 3

[graph] dijkstra algorithm object
by alex 30 Apr '14

30 Apr '14

Dear Jeremiah and Boost list, I'd like to suggest for inclusion in Boost Graph Library an algorithm object version of dijkstra shortest path algorithm. The following is an example how it can be used, assuming some graph, source node(s) and threshold distance: auto dijkstra make_dijkstra_object(graph, source_range); while(dijkstra()) { auto v = dijkstra.get_vertex(); auto distance_map = dijkstra.get<vertex_distance_t>(); if(get(distance_map, v) > threshold) break; } It is very close to what Jeremiah suggested 2 years ago: http://lists.boost.org/Archives/boost/2012/07/195300.php The main advantage for me is the possibility to interweave several shortest path searches. The algorithm object makes use of the stackless coroutine in Boost ASIO, which means it is relatively lightweight. However, on a large graph the algorithm object still takes about 20% more time than the normal dijkstra_shortest_path. The operator() progresses the algorithm to the next control point. Control points can correspond to all places where breadth_first_search invokes its visitor, but it is specified in compile time at which potential control points the algorithm actually yields. The default is to halt at the finish_vertex control point only. The make_dijkstra_object function can take all parameters through bgl_named_parameters, including the priority queue and the color map, which the existing dijkstra_shortest_path does not support. The code is part of the following project: http://code.google.com/p/resumable-dijkstra The algorithm object is defined here: http://code.google.com/p/resumable-dijkstra/source/browse/trunk/resumable-di jkstra/blink/graph/dijkstra_object.hpp I look forward to hear if there are any takers this time. Best wishes, Alex

1 0

[MPI] Fix can be merge to master
by Ben Pope 30 Apr '14

30 Apr '14

Please merge https://github.com/boostorg/mpi/commit/a7a2501242e78c65df9ff82c67dcad1f016b… to master. Should fix mpi and graph_parallel Ben

1 2

Request for comments on break up ‘Application’ into 2 libraries.
by Renato Forti 30 Apr '14

30 Apr '14

Hi All, Following suggestion of Niall Douglas, I am thinking in split the ‘Boost.Application’ in 2 libraries: - - Boost.Application - Boost.Shared_Library Thus, the ‘plug-in systems’ will be detached of ‘Boost.Application’ core and will become one new library, and ‘Application’ stay only providing abstraction of an application (no more plugin system) I will detach this part: http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applic… Anyone have any comment/advises about it? Any suggestion? Anyone disagrees? I await your comments, thanks! -- ReTF

4 3

Why no non-null smart pointers?
by Ross MacGregor 29 Apr '14

29 Apr '14

I just created a very small smart pointer libary for our project. It will contain two types of shared pointers: SharedHandle and NullableSharedHandle. SharedHandle will be a shared pointer that cannot be null by ensuring a non-null construction while NullableSharedHandle will basically be a typedef for boost::shared_ptr. I firmly believe that code can be made more reliable by minimizing the use of nullable pointers. To this end, I think it is important that we start using non-null pointer types. Ideally the compiler would be able to understand a non-null pointer and catch bugs at compile time, but I think we can still improve things with a few runtime checks. If we make sure that a shared pointer is constructed with a non-null pointer and ban any reset() type methods, we guarentee that it points to something. This can be beneficial for the following reasons: 1. Any function that uses this type will no longer be burdened with precondition checks to make sure variables of this type are not null. 2. It's type is simply more explicit and better explains its function. 3. Moving the non-null check to the creation phase will reduce the possibility of encountering null pointer exceptions at runtime (assuming there are many more pointer references than constructor calls). So my little pointer library seems to make a lot of sense, but if so why hasn't this simple smart pointer variation made it into boost yet? Has this been discussed somewhere already? My search on non-null smart pointers is not revealing much discussion on the topic. Regards, Ross

9 16

Linker error, Windows 7, one specific function from one specific library
by Chris Cooper 28 Apr '14

28 Apr '14

I’m trying to get the boost 1.55 regression tests to build on my Windows machine (msvc-10.0), and nearly all of them build fine but a few of them: pool.pool_msvc_compiler_bug_test pool.test_bug_1252 pool.test_bug_2696 pool.test_bug_3349 pool.test_bug_4960 pool.test_bug_5526 pool.test_msvc_mem_leak_detect pool.test_pool_alloc pool.test_simple_seg_storage pool.time_pool_alloc Give this error : pool_msvc_compiler_bug_test.obj : error LNK2019: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (?generic_category@system@boost@@YAAEBVerror_category@12@XZ) referenced in function "void __cdecl boost::system::`dynamic initializer for 'posix_category''(void)" (??__Eposix_category@system@boost@@YAXXZ) pool_msvc_compiler_bug_test.obj : error LNK2019: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?system_category@system@boost@@YAAEBVerror_category@12@XZ) referenced in function "void __cdecl boost::system::`dynamic initializer for 'native_ecat''(void)" (??__Enative_ecat@system@boost@@YAXXZ) If my libraries were completely wrong, I would expect everything to fail, and many more unresolved symbols, but it’s just this one symbol that is confusing the linker. The command line I’m using to build these tests is: b2 toolset=msvc-10.0 --without-mpi --build-dir=C:\temp address-model=64 variant=release link=static threading=multi --dump-tests test_bug_1252 Which compares favorably with the command lines I’m using to build the libraries: b2 -j4 --without-mpi --stagedir=C:\temp\boost\build\stage --build-dir=C:\temp\boost\build toolset=msvc-10.0 address-model=64 variant=release link=static threading=multi b2 -j4 --without-mpi --prefix=C:\temp\boost\install --stagedir=C:\temp\boost\build\stage --libdir=C:\temp\boost\install\lib --build-dir=C:\temp\boost\build --build-type=complete toolset=msvc-10.0 address-model=64 variant=release link=static threading=multi install b2 -j4 --with-math --stagedir=C:\temp\boost\build\stage --build-dir=C:\temp\boost\build --build-type=complete toolset=msvc-10.0 address-model=64 variant=release link=static threading=multi b2 -j4 --with-math --prefix=C:\temp\boost\install --stagedir=C:\temp\boost\build\stage --libdir=C:\temp\boost\install\lib --build-dir=C:\temp\boost\build --build-type=complete toolset=msvc-10.0 address-model=64 variant=release link=static threading=multi install I inherited the build scripts, so I’m not sure why b2 is being called 4 times, is that a problem? Should I merge the “--without-mpi” into calls 3 and 4, and get rid of calls 1 and 2? Why is it having trouble with just this one symbol? Thanks, Chris

2 1

Announcing the student program for Meeting C++ 2014
by Jens Weller 28 Apr '14

28 Apr '14

Hello C++ and Boost Community, today I have the honor to announce the student program for Meeting C++ 2014: > The Meeting C++ Student program will enable 50 students to attend Meeting C++ 2014 plus 3 exclusive workshops organized by think-cell one day before the conference on December 4th. So, for students this will be a 3 day conference! After the workshops you will be invited to the student dinner by think-cell. Further details at http://meetingcpp.com/index.php/newsreader/items/meeting-cpp-2014-the-stude… kind regards, Jens Weller

1 0

[graph] Undocumented function bron_kerbosch_all_cliques
by Javier Dehesa 28 Apr '14

28 Apr '14

Looking for clique search algorithms in BGL, I've found out that there exists the function bron_kerbosch_all_cliques, but that there is not documentation for it. The implementation fo the algorithm can be found here http://www.boost.org/doc/libs/1_55_0/boost/graph/bron_kerbosch_all_cliques.… and there is even an example program using it http://www.boost.org/doc/libs/1_55_0/libs/graph/example/bron_kerbosch_print… Also, it seems to define a "clique visitor" concept that is not documented either. Is there any reason for it? Maybe there is some problem with the implementation? Or is it just missing documentation? I've run some toy examples and it seems to work, but I can't tell if there would be a problem with large graphs. -- Javier Dehesa

2 1

Re: [boost] [Boost-users] [typeindex v3.0] Peer review begins Mon 21st ends Wed 30th
by Niall Douglas 27 Apr '14

27 Apr '14

On 23 Apr 2014 at 14:33, Paul A. Bristow wrote: > > 2. What is your evaluation of the implementation? > OK. > > Though I'm not enthusiastic about the name of namespace boost::typeind:: but I > don't have any much better ideas. Perhaps someone else has? To clarify the issue to everyone else, TypeIndex is in a rather unusual bind with regard to what namespace to use. Ideally I think we'd all agree that boost::type_index would be best, but then one of the issues raised last peer review was that there shouldn't be a boost::type_index type as could conflict with std::type_index, and if we hold that to be wise, then surely the same rationale applies for a boost::type_index namespace as well. So we end up with boost::typeind, which I don't think makes anyone happy, but it is safe. > IMO, the frequency of use of the namespace bti is probably so low that spelling > it out is clearer, for example: > > boost::typeind::type_id<T>().pretty_name() // human readable Noted. > > 8. Do you think the library should be accepted as a Boost library? > > Yes. Thanks Paul for the vote and quick turnaround. I was worried that the review announcement had got lost. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

7 7

[testing] gcc 4.9 test failures
by Andrey Semashev 27 Apr '14

27 Apr '14

Hi, I'm seeing lots of test failures on BP x86_64 C++11 gcc-4.9.0~c11. http://www.boost.org/development/tests/develop/developer/log.html The test logs don't show any errors. Is it possible to see the complete build log?

2 1

any macro for silencing unused variable warnings?
by Andrzej Krzemienski 26 Apr '14

26 Apr '14

Hi, Is there in Boost a macro for disabling warnings about unused variables? (In case I intend my variable never to be used). Regards, &rzej

3 2

noexcept BOOST_EXPLICIT_OPERATOR_BOOL
by Andrzej Krzemienski 26 Apr '14

26 Apr '14

Hi, Although I am not entirely convinced that any not throwing function (except for moves) should be marked as noexcept, I can see that noexcept starts to get into Boost. explicit operator bool appears to be a good candidate, but macro BOOST_EXPLICIT_OPERATOR_BOOL does not offer it. So I have to choose: use the macro or noexcept. Perhaps the macro could be expanded to give an option to add noexcept, but that would spawn two macros (BOOST_EXPLICIT_OPERATOR_BOOL and BOOST_CONSTEXPR_EXPLICIT_OPERATOR_BOOL) into four. Are four macros for almost the same purpose acceptable? Or do I have to abandon the idea of making the operator noeaxcept. Are there any recommendations? Regards, &rzej

2 6

[config] Documentation oversight?
by Mostafa 26 Apr '14

26 Apr '14

Here: http://tinyurl.com/lm2u35f it says that BOOST_NO_NOEXCEPT is deprecated in favor of BOOST_NO_CXX11_NOEXCEPT, yet here: http://tinyurl.com/lggeqcp the reference is defined in terms of the deprecated macros. For consistency and to prevent accidental misuse shouldn't the documentation be referencing the new macros throughout?

1 0

[ublas] FYI: msvc12 compilation errors and some questions
by Adam Wulkiewicz 25 Apr '14

25 Apr '14

Hi, FYI, ublas is broken for MSVC 12 due to the use of constexpr which is not suported by this compiler. I might fix it however I assume there are people who would like to do it. Btw, would you be so kind and answer for some questions? I'm curious about the design. Why BOOST_UBLAS_CPP_GE_2011 library-wide #define is usedto enable fixed_vector<>? This makes it available only on some compilers which allows the users to write non-portable code. Shouldn't Boost libraries use language featureswhen they're available or emulate them rather than enable/disable some functionalities? Especially when it could be easily done, like in this case. Variadic templates may be emulated with Boost.Preprocessor, e.g. see how emplace_back() is implemented in boost::container::vector<> : https://github.com/boostorg/container/blob/develop/include/boost/container/… lines 1309-1380. constexpr may be conditionally used e.g. like this: #ifndefBOOST_NO_CXX11_CONSTEXPR #define CONSTEXPR_OR_STATIC constexpr #else #define CONSTEXPR_OR_STATIC static #endif So I'm wondering was the decision about the design made to push the library towards "pure" C++11? If yes, does this mean that all new features will require C++11? Regards, Adam

2 2

the Boost policy for protecting against "too perfect forwarding"
by Andrzej Krzemienski 25 Apr '14

25 Apr '14

Hi, By "too perfect forwarding" I mean the issue described in either of the following articles: http://akrzemi1.wordpress.com/2013/10/10/too-perfect-forwarding/ http://flamingdangerzone.com/cxx11/2012/06/05/is_related.html http://ericniebler.com/2013/08/07/universal-references-and-the-copy-constru… In short, a perfect-forwarding constructor can inadvertently become a better match than a copy constructor when we want to make a copy. There are two ways for protecting against it: 1. enable_if -- to disable the unwanted overloads 2. Add additional constructor overloads. (1) appears cleaner, but some compilers might not support SFINAE. My question is if there is a consensus in Boost how to approach this problem. Is Boost supposed to support compilers w/o SFINAE? (It looks so, because we have macro BOOST_NO_SFINAE. I can see Boost.Any just uses SFINAE for this purpose without any check. Are there any compilers supported by Boost that have rvalue references but no SFINAE? Regards, &rzej

3 2

[Graph] Pull request for multiplicities support in brandes_betweenness_centrality
by Javier Dehesa 25 Apr '14

25 Apr '14

I've put a pull request for ticket #9935 https://svn.boost.org/trac/boost/ticket/9935 https://github.com/boostorg/graph/pull/6 Explanations included in the ticket and the pull request. I can try to make the implementation for graph_parallel if this get accepted. -- Javier Dehesa

1 0

lazy_enable_if is not sfinae friendly?
by Hui Li 24 Apr '14

24 Apr '14

I was surprised to find that the following code doesn't compile with boost 1.55, where boost::result_of is itself sfinae friendly. template < typename T > typename boost::lazy_enable_if_c< boost::is_class<T>::value, boost::result_of<T(int)> >::type test(int){} template < typename > void test(...) {} struct A{}; // boost::result_of<A(int)> is a valid type that doesn't have a member called "type" int main(int argc, const char * argv[]) { test<A>(0); // test<A>(int) meant to be a substitution failure return 0; } For example, on clang++-3.4 with -std=c++11, I got: clang++-mp-3.4 -std=c++11 -I /opt/local/include/ main.cpp In file included from main.cpp:1: In file included from /opt/local/include/boost/type_traits.hpp:65: In file included from /opt/local/include/boost/type_traits/is_nothrow_move_assignable.hpp:22: /opt/local/include/boost/utility/enable_if.hpp:40:25: error: no type named 'type' in 'boost::result_of<A (int)>' typedef typename T::type type; ~~~~~~~~~~~~^~~~ main.cpp:12:1: note: in instantiation of template class 'boost::lazy_enable_if_c<true, boost::result_of<A (int)> >' requested here typename boost::lazy_enable_if_c< ^ main.cpp:16:1: note: while substituting explicitly-specified template arguments into function template 'test' test(int){} ^ 1 error generated. But if lazy_enable_if_c had been implemented as template <bool B, class T> struct lazy_enable_if_c : T {}; // inherits from T template <class T> struct lazy_enable_if_c<false, T> {}; The above test code would compile fine. However, the current implementation template <bool B, class T> struct lazy_enable_if_c { typedef typename T::type type; // this is what caused the compile error }; template <class T> struct lazy_enable_if_c<false, T> {}; seems to evaluate T::type too soon, and results in a compile error rather than a substitution failure. I wonder if the current implementation is chosen deliberately to disallow use cases like the test code? But I imagine allowing lazy_enable_if etc to be (more) sfinae friendly could be very useful. I was able to find a workaround for the test code: template < typename T > typename boost::enable_if_c< boost::is_class<T>::value, boost::result_of<T(int)> >::type::type // when T = A, this is a substitution failure test(int){} Hui

1 0

[assign] Merge request for type disambiguation with C++11
by Ben Pope 24 Apr '14

24 Apr '14

https://github.com/boostorg/assign/pull/3 The merge base was somehow ignored, not sure what happened there, but the set of changes is in the last commit. Ben

5 8

[Bug Report] macro definition has \ followed by spaces
by Walter Bright 24 Apr '14

24 Apr '14

In order for line splicing to work, \ has to be followed by a newline. boost/1.51.0/gcc-4.8.1-glibc-2.17-fb/42097cf/include/boost/spirit/home/classic/utility/rule_parser.hpp line 422 ::BOOST_SPIRIT_CLASSIC_NS::type_of::depend_on_type<__Dummy>(x) ) \

2 2

boost::aligned_storage broken on VC12 for alignment values of 8
by Glen Fernandes 24 Apr '14

24 Apr '14

Very surprising, but easily reproducible with VC12 (2013), Release or Debug configuration, Win32 platform: the following program will often* throw: #include <boost/type_traits/aligned_storage.hpp> #include <cstdint> int main() { boost::aligned_storage<8, 8>::type a; if (((std::uintptr_t)&a % 8) != 0) { throw 1; } } * Four of every five times it failed because the storage was only 4-byte aligned, not 8-byte aligned. Does not reproduce for x64 builds, just x86 builds. Does not reproduce with alignment values other than 8. Glen

4 7

Regression test relying on undefined compiler behavior (c++11)
by Chris Cooper 24 Apr '14

24 Apr '14

libs/utility/numeric_traits_test.cpp generates values complement_traits<Number>::min using a clever recursive template, but that template relies on left-shifting a negative value, and according to the C++11 standard that’s a no-no (“the behavior is undefined”) which means it’s not a constant expression, which means it can’t be calculated at compile time, which means the BOOST_STATIC_ASSERT in line 332 won’t compile, saying “static_assert expression is not an integral constant expression” (I’m using clang++). See discussion here: http://stackoverflow.com/questions/23250651/strange-behavior-with-c-recursi… In addition, it looks like the existing code also relies on the compiler filling the vacated bits with one’s, which I don’t think is what actually happens. The solution I’ve come up with, is to do the shifting using unsigned values, thus avoiding the compiler no-no, and then putting the result back in the specified type. In other words, replacing line 73 BOOST_STATIC_CONSTANT(Number, min = Number(Number(prev::min) << CHAR_BIT)); With BOOST_STATIC_CONSTANT(Number, min = boost::detail::is_signed<Number>::value ? (Number)(((unsigned long)(prev::min) << 8) | 0x00FF) : Number(Number(prev::min) << CHAR_BIT) ); I’m using constants ‘8’ and ‘0x00FF’ rather than CHAR_BIT since the code would get really ugly if CHAR_BIT != 8. Thoughts? Thanks, Chris

3 5

Fwd: [Boost-users] [typeindex v3.0] Peer review begins Mon 21st ends Wed 30th
by Antony Polukhin 24 Apr '14

24 Apr '14

2014-04-23 17:33 GMT+04:00 Paul A. Bristow <pbristow(a)hetp.u-net.com>: <...> > > 2. What is your evaluation of the implementation? > OK. > > Though I'm not enthusiastic about the name of namespace boost::typeind:: > but I > don't have any much better ideas. Perhaps someone else has? > > Nor am I clear that this namespace bti helps the reader. > > "Through all the examples, we'll assume that the following namespace alias > is in > effect: > > namespace bti = boost::typeind; > > " > > IMO, the frequency of use of the namespace bti is probably so low that > spelling > it out is clearer, for example: > > boost::typeind::type_id<T>().pretty_name() // human readable > Agreed: boost::typeindex would be more user friendly. It suggests to the reader which library to look for. Other notes will be also addressed. Thanks for the review! -- Best regards, Antony Polukhin

1 0

Re: [boost] Application need a Review Manager. Anyone is interested?
by Brian Wood 24 Apr '14

24 Apr '14

Niall Douglas: > Yeah, I'd definitely redouble my advice to break up Application into > smaller, standalone, reusable bits. The problem with any overarching > framework is that it's a vision (i.e. your vision), and other > people's visions never peer review well, whether in academia, here in > Boost, or anywhere. Also, unless you're a member of Boost's steering > committee and/or on the C++ standards committee, any vision you > propose probably won't be given any benefit of the doubt > unfortunately. Some might think: If you can't beat 'em, join 'em. My motto though is: If you can't join 'em, beat 'em. -- Brian Ebenezer Enterprises - "A fool with a plan can beat a genius with no plan." T. Boone Pickens http://webEbenezer.net

1 0

Can't compile valarray.cpp - any ideas why?
by Chris Cooper 23 Apr '14

23 Apr '14

On my Mac (OSX 10.9.2, running clang++ "Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)”), I can’t get the libs/accumulators/test/valarray.cpp regression test to compile. The error it gives is of course lengthy, but goes something like this: In file included from valarray.cpp:18: ../../../boost/accumulators/statistics/weighted_mean.hpp:73:13: error: no matching constructor for initialization of 'result_type' (aka 'valarray<typename divides<left_value_type, const double>::result_type>') : mean( ../../../boost/accumulators/framework/depends_on.hpp:319:17: note: in instantiation of function template specialization 'boost::accumulators::impl::immediate_weighted_mean_impl<SNIP>' requested here : Accumulator(args) ../../../boost/accumulators/framework/depends_on.hpp:252:29: note: in instantiation of function template specialization 'boost::accumulators::detail::accumulator_wrapper<SNIP>' requested here return type(args, next_build_acc_list::call(args, fusion::next(f), l)); ../../../boost/accumulators/framework/depends_on.hpp:252:56: note: in instantiation of function template specialization 'boost::accumulators::detail::build_acc_list<SNIP>' requested here return type(args, next_build_acc_list::call(args, fusion::next(f), l)); ../../../boost/accumulators/framework/depends_on.hpp:271:51: note: in instantiation of function template specialization 'boost::accumulators::detail::build_acc_list<SNIP>' requested here return meta::make_acc_list<Sequence>::call(args, fusion::begin(seq), fusion::end(seq)); ../../../boost/accumulators/framework/accumulator_set.hpp:159:21: note: in instantiation of function template specialization 'boost::accumulators::detail::make_acc_list<SNIP>' requested here detail::make_acc_list( valarray.cpp:150:78: note: in instantiation of function template specialization 'boost::accumulators::accumulator_set<SNIP>' requested here /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/valarray:806:5: note: candidate constructor not viable: no known conversion from 'typename result<SNIP>' to 'const std::__1::valarray<double>' for 1st argument valarray(const valarray& __v); That last little bit makes it look like “result_type mean” is of type valarray<double> and boost is trying to pass a valarray<int> into its copy constructor and not succeeding. I’ve narrowed down the offending code (in valarray.cpp) and this is the code that won’t compile: typedef std::valarray<int> sample_t; typedef boost::accumulators::stats<boost::accumulators::tag::weighted_mean(boost::accumulators::immediate)> mystats; boost::accumulators::accumulator_set<sample_t, mystats, int> acc2; Which is basically the same as: sample_t s; typedef boost::numeric::functional::multiplies<sample_t, int>::result_type weighted_sample; typedef boost::numeric::functional::fdiv<weighted_sample, int>::result_type result_type; result_type mean(s); which also doesn’t compile and gives a pretty-much-identical error message. I’m completely unfamiliar with the boost accumulators code, any suggestions on why this is failing, and what I can do to patch valarray.cpp so the regression test will compile? Thanks, Chris

1 0

[Git] Are past releases tagged somehow?
by John Maddock 23 Apr '14

23 Apr '14

Is there a way to identify and checkout past releases from Git? I couldn't find anything on the Wiki? Thanks, John.

4 3

[container] pull request for fixing propagate_on_container_move_assignment (add ::value)
by Ben Pope 23 Apr '14

23 Apr '14

I noticed that this was only just changed, but hey ho. https://github.com/boostorg/container/pull/1 Ben

1 0

[GSoC] A C++11 enabled TMP library (accepted)
by Louis Dionne 23 Apr '14

23 Apr '14

Dear community, I am pleased to announce that my proposal named "A C++11 template metaprogramming library"[1] was accepted for GSoC 2014. I want to thank the community for putting trust in the proposal, and I am committed to do everything I can to make this project succeed. As explained in my proposal, the goal of the project is to build a high quality template metaprogramming library using modern techniques to achieve both higher expressiveness and lower compilation times. Since the ultimate goal is to make such a library part of the Boost distribution, I will try to involve the community and maintain a tight feedback loop. With your support, I am confident that we can achieve a lot in the direction of better template metaprogramming. This is also a good time to mention (advertise?) that I will be presenting the project at the upcoming C++Now conference. :-) I am knee-deep in my finals right now, but updates should come shortly. Stay tuned! Louis Dionne [1]: http://goo.gl/ZlYeFi

4 5

[assign] [tokenizer] Please pull two trivial patches
by Gregor Jasny 23 Apr '14

23 Apr '14

Hello, since four months two trivial patches to replace a plain throw with BOOST_THROW_EXCEPTION sit in the trac and github (as pull requests). Could anyone please review and submit them? I'd like to see them in the next release or the one after. #9504 - https://github.com/boostorg/assign/pull/1 #9505 - https://github.com/boostorg/tokenizer/pull/1 Thanks, Gregor

1 0

[utility] Pull request: Use an unsigned type as an intermediate result instead of left shifting a negative integral constant
by Ben Pope 22 Apr '14

22 Apr '14

https://github.com/boostorg/utility/pull/4 No maintainer listed in maintainers.txt so cross posting this one. Ben

4 5

[gsoc2014] This year's students announced
by Niall Douglas 22 Apr '14

22 Apr '14

Dear Boost, We are pleased to announce that the following eight students will be this year's Google Summer of Code for 2014: 1. Anton Bikineev Mentor: Christopher Kormanyos Topic:Boost.Math Generalized Hypergeometric Functions 2. Ian Forbes Mentor: Tim Blechmann Topic: Boost.Thread Scheduled Executors 3. Louis Dionne Mentor: Joel Falcou Topic: A C++11 template metaprogramming library 4. Mark Lingle Mentor: David Bellot Topic: Boost.uBlas: Optimization via Smart Templating and a Tree Optimizer class 5. Roshan Mentor: Kyle Lutz Topic: Expand and Improve Boost.Compute 6. Saksham Maheshwari Mentor: Stefan Seefeld Topic: Boost.XML - A Standard XML Library 7. Thaler Benedek Mentor: Vicente J. Botet Escriba Topic: Boost.Pipeline 8. Vinícius dos Santos Oliveira Mentor: Bjorn Reese Topic: HTTP server on Boost At US$5,000 funding per student, this represents an investment of US$40,000 into Boost by Google this year, for which we are extremely grateful. Our thanks to everyone in Google who makes this happen every year. With so few slots available from Google some very good candidates and proposals could not be selected, so if you were not selected this year, better luck next year (remember to come early!). Congratulations to the students who did make it, and our collective thanks go to the primary mentors above for taking the time this summer, as well to the secondary mentors not listed above as well as everyone who helped out with the proposal review and the ranking and voting this year. Niall & Boris --- Boost C++ Libraries Google Summer of Code 2014 admin https://svn.boost.org/trac/boost/wiki/SoC2014

8 7

Strange use of random values in regression test ...
by Chris Cooper 21 Apr '14

21 Apr '14

The test_main() of libs/utility/operators_test.cpp loops 1000 times, running a variety of tests on random values. However, since the randomizer (boost::minstd_rand) is instantiated inside the loop, it appears that the randomizer is re-seeded for each loop, meaning it runs the test 1000x with the exact same values each time. I’m not 100% familiar with the boost random value generators, am I missing something? Or should the boost::minstd_rand be instantiated outside the loop? I’m happy to add this as a boost bug if my understanding is correct … Thanks, Chris

2 1

[type traits] has_complement, enum class, and gcc 4.9
by Nevin Liber 21 Apr '14

21 Apr '14

We are seeing build problems with gcc 4.9 RC1 and Boost 1.55. Given the following test program: #include <boost/type_traits.hpp> #include <iostream> enum class E {}; int main() { std::cout << boost::has_complement<E>() << std::endl; } Using g++ -std=c++11, we get: In file included from */opt/local/include/boost/config.hpp:57:0*, from */opt/local/include/boost/type_traits/add_const.hpp:13*, from */opt/local/include/boost/type_traits.hpp:13*, from *a.cpp:1*: /opt/local/include/boost/type_traits/detail/has_prefix_operator.hpp: In instantiation of '*const bool boost::detail::has_complement_impl::operator_exists<E>::value*': */opt/local/include/boost/type_traits/detail/has_prefix_operator.hpp:173:4:* required from '*const bool boost::detail::has_complement_impl::trait_impl1<E, boost::detail::has_complement_impl::dont_care, false>::value*' */opt/local/include/boost/type_traits/detail/has_prefix_operator.hpp:195:4:* required from '*const bool boost::detail::has_complement_impl::trait_impl<E, boost::detail::has_complement_impl::dont_care>::value*' */opt/local/include/boost/type_traits/detail/has_prefix_operator.hpp:202:1:* required from '*struct boost::has_complement<E>*' *a.cpp:7:41:* required from here */opt/local/include/boost/type_traits/detail/has_prefix_operator.hpp:152:56:* *error: *no match for '*operator~*' (operand type is '*E*') BOOST_STATIC_CONSTANT(bool, value = (sizeof(check(((BOOST_TT_TRAIT_OP make<Rhs>()),make<has_operator>())))==sizeof(::boost::type_traits::yes_type))); * ^* /opt/local/include/boost/type_traits/detail/has_prefix_operator.hpp: In instantiation of '*const bool boost::detail::has_complement_impl::operator_returns_void<E>::value*': */opt/local/include/boost/type_traits/detail/has_prefix_operator.hpp:173:4:* required from '*const bool boost::detail::has_complement_impl::trait_impl1<E, boost::detail::has_complement_impl::dont_care, false>::value*' */opt/local/include/boost/type_traits/detail/has_prefix_operator.hpp:195:4:* required from '*const bool boost::detail::has_complement_impl::trait_impl<E, boost::detail::has_complement_impl::dont_care>::value*' */opt/local/include/boost/type_traits/detail/has_prefix_operator.hpp:202:1:* required from '*struct boost::has_complement<E>*' *a.cpp:7:41:* required from here */opt/local/include/boost/type_traits/detail/has_prefix_operator.hpp:89:102:* *error: *no match for '*operator~*' (operand type is '*E*') BOOST_STATIC_CONSTANT(bool, value = (sizeof(::boost::type_traits::yes_type)==sizeof(returns_void((BOOST_TT_TRAIT_OP make<Rhs>(),returns_void_t()))))); * ^* *a.cpp:* In function '*int main()*': *a.cpp:7:41:* *error: *cannot bind '*std::ostream {aka std::basic_ostream<char>}*' lvalue to '*std::basic_ostream<char>&&*' { std::cout << boost::has_complement<E>() << std::endl; } * ^* In file included from */opt/local/include/gcc49/c++/istream:39:0*, from */opt/local/include/gcc49/c++/sstream:38*, from */opt/local/include/gcc49/c++/complex:45*, from */opt/local/include/boost/type_traits/is_complex.hpp:12*, from */opt/local/include/boost/type_traits.hpp:49*, from *a.cpp:1*: */opt/local/include/gcc49/c++/ostream:602:5:* *note: *initializing argument 1 of '*std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&&, const _Tp&) [with _CharT = char; _Traits = std::char_traits<char>; _Tp = boost::has_complement<E>]*' operator<<(basic_ostream<_CharT, _Traits>&& __os, const _Tp& __x) * ^* It compiles fine under gcc 4.7.2 and clang 3.4. It also compiles fine for plain enums. Any ideas? -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404

2 2

Corruption in container::string when used with boost::interprocess
by Lars Hagström 21 Apr '14

21 Apr '14

Found this bug recently, but since theres been no activity on it on Trac I'm double-posting here. https://svn.boost.org/trac/boost/ticket/9855 Cheers Lars

2 1

Boost.Align review begins today
by Ahmed Charles 21 Apr '14

21 Apr '14

Hi all, The review of Boost.Align by Glen Fernandes commences today, Friday, 11 April, and concludes Sunday, 20 April. Boost.Align provides: 1. Function align() to align a pointer, for implementations which do not provide C++11's std::align(). 2. Functions aligned_alloc() and aligned_free() for dynamic allocation with specified alignment. { For use in place of ::operator new() and ::operator delete(). } 3. Class template aligned_allocator as an alignment-aware allocator that also allows specifying a minimum alignment. { For use in place of std::allocator. } 4. Class template aligned_allocator_adaptor to turn any existing allocator into an alignment-aware allocator that also allows specifying a minimum alignment. { For use in place of any existing allocator type. } 5. Function is_aligned() to test the alignment of a pointer. Rationale: C++11 added the ability to specify increased alignment (over-alignment) for class types. Unfortunately, ::operator new allocation functions, new expressions, and the default allocator, std::allocator, do not support dynamic memory allocation of over-aligned data. Notes: This library also meets needs in existing Boost libraries. - Boost.Smart_Ptr has its own implementation of align(). - Boost.Interprocess and Boost.Log each have their own implementation of aligned_alloc() and aligned_free(). Source: doc: http://glenfe.github.io/align git: http://github.com/glenfe/align zip: http://github.com/glenfe/align/archive/master.zip Please always state in your review whether you think the library should be accepted as a Boost library. Additionally, please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Ahmed Charles Review Manager

10 26

Boost.Align review results
by Ahmed Charles 21 Apr '14

21 Apr '14

The review of the proposed Boost.Align library ended on April 20, 2014. The result is: Accepted with conditions. Glen and I would like to thank everyone for contributing to the review for Boost.Align. either with a review or comments in the discussions. The summary of formal votes is as follows (alphabetical order): Andrey Semashev - Yes (conditional) Antony Polukhin - Yes (conditional) Bjorn Reese - Yes Lars Viklund - Yes Michael Spencer - Yes For a total of 5 votes for acceptance and 0 votes for rejection. The conditional acceptance is based on the quality of documentation, as the feedback given on code and design has already been addressed. The conditions below are agreeable to the author: 1. QuickBook documentation should be used, following typical Boost documentation structure. 2. Additional examples should be used to make the understanding/use of the library easier. 3. Additional minor comments from the reviews should be addressed. I would like to thank Glen for making this an easy first review manager experience and I look forward to reviewing other libraries in the future.

2 1

Application need a Review Manager. Anyone is interested?
by Renato Forti 21 Apr '14

21 Apr '14

>> So do a ton of other libraries waiting in the review queue. >> One trend I've noticed in recent reviews is that the libraries which find review managers are small, sometimes very small. It might be worth breaking up Application into smaller libraries if you want a faster review. I think that I can split it. >> Equally, AFIO has 1000 active lines of code, and I very much doubt it'll see a review manager any time soon. I'm thinking maybe next year it might >> (I will speak at C++ Now introducing the session on the Future of Boost, which will mention AFIO :) ). Nice! I will check! >> FYI, I'd just love if Application's design rationale told me why and how it's similar or different to Boost.Process. Process is one of the most popular non-official Boost libraries out there. Well, I think that are totally different. Quick, Boost.Process is used to start a new process, Boost.Application is the process in fact. Boost.Application provides a model/environment to build any application, not start an application. Some features are: With it you can deploy your application as server (service on windows, and daemon on unix). It provides a plug-in system tool and other facilities (like aspects) that will help developer on application development. It provides a way to create other applications modes, e.g. Apache http server module. Some references: http://www.codeproject.com/Articles/756866/Build-a-Server-Application-using… http://www.codeproject.com/Articles/695937/Creating-a-New-Application-Mode Thanks alot for your comments.

4 4

GSoC 2014 - Functional - Monad
by Ding Xiangfei 19 Apr '14

19 Apr '14

Hello, Boost. This is Xiangfei, a first year CS student from National University of Sinagpore. I am familiar with C++ template programming and have learnt a little functional programming language by myself. Therefore I find the monad project in boost will be very interesting and useful. This is my first time applying for GSoC. I have past boost use experience, but it is my first time also to contribute in Boost library. I have a question for the implementation of monad. What is the degree of integration of this module with other Boost utilities other than sequences and containers? Thank you. Regards, Xiangfei

2 10

Re: [boost] [serialization] proposed improvements: forward-compatibility of serialization
by Brian Wood 18 Apr '14

18 Apr '14

On Fri, Apr 18, 2014 at 10:52 AM, Robert Ramey < robertmacleranramey(a)gmail.com> wrote: > > > On Friday, April 18, 2014 6:40:32 AM UTC-7, Brian Wood wrote: >> >> niXman writes: >> >> > Hi, >> > >> > YAS(https://github.com/niXman/yas) ? >> >> The test results on your page are impressive, but there's >> not much info on what or how you tested. Please give >> some more info on that. >> > > Looks like the YAS version uses a special mem_ostream/mem_istream classes > rather than std::strstream. Since the largest part of any of these > benchmarks is spent on the i/o part this would account for a huge > difference. > > >> >> Also it looks to me like the results you list for text >> serialization are off by a factor of ten. >> > > This is common when the benchmark is compiled in debug mode. The boost > serialization library has a huge amount of extra checking in debug mode > which generally slows things down by a factor of 10. I don't know if > that's the case here though. > > He has this table: | boost | YAS | +------+---------+---------+---------+ | save | 8090 ms | 277 ms | +28000% | +------+---------+---------+---------+ | load | 8794 ms | 265 ms | +33000% | +------------------------------------+ I think the last column is off. It should be +2800% and +3300%. Personally I wouldn't use the percents and would use 28 and 33. -- Brian Ebenezer Enterprises - Heavenly code. http://webEbenezer.net

1 0

Re: [boost] [serialization] proposed improvements: forward-compatibility of serialization
by Brian Wood 18 Apr '14

18 Apr '14

niXman writes: > Hi, > > YAS(https://github.com/niXman/yas) ? The test results on your page are impressive, but there's not much info on what or how you tested. Please give some more info on that. Also it looks to me like the results you list for text serialization are off by a factor of ten. -- Brian Ebenezer Enterprises - So far G-d has helped us. http://webEbenezer.net

1 0