January 2014 - Boost - lists.preview.boost.org

[git] Near future.. How do we deal with git-native libraries?
by Rene Rivera 05 Apr '14

05 Apr '14

As the owner of the Predef library which exists originally in github and not svn.. I'm wondering about some things for the near future (as in this coming week): 1. Where will the git repo live for a library? Will the repo need to stay in the boostorg organization? Or is it possible/desirable to use the existing repo that's part of my user account? 2. I notice that there's a ".gitattributes" file in the svn imported version of the Predef repo. Will I need to add that file to my actual Predef git repo? And if so, is there a single canonical version of that file I should use? And a followup.. In the future if that file changes, does it need to change for all repos consistently? Rene. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

9 31

[asio] Bug: Handlers execute on the wrong strand.
by Greg Barron 04 Apr '14

04 Apr '14

Hi All, I would like to refer you to this bug report: https://svn.boost.org/trac/boost/ticket/9203 I won't paste the full contents of the bug report into this message. The executive summary is that the allocation algorithm for the implementation of asio::strand can and does allocate the implementation of an existing strand to strands that are subsequently allocated. This can have the effect that handlers wrapped in strand (b) will actually be executed on strand (a). I consider this to be a bug but if there is something that I'm misunderstanding about the operation of strands it would be great if you could help me clear it up. If the consensus is that this is a bug, what are the chances for it to be included in the 1.56 release? It is probably too late to be included in the 1.55 release. I've implemented a work around which could only be described as a hack and would be embarrassed to show it to anybody. But it gets me over my hump :). Thanks! -- Greg

5 4

Post-git forking process
by Sohail Somani 29 Mar '14

29 Mar '14

Hey all, Often, I find bugs in Boost that I need to patch manually before the next release. What I used to do before was keep a copy of Boost in my source tree which made this easier: just patch it directly. This made it easy to modify, but annoying to post patches and honestly, they just got lost most of the time. With Git, it should become easier to contribute said patches as well as pull in whichever particular changes I need. However when I attempted such a fork recently, I was a bit lost. As I understood it, the process should have been: 1. Create a fork of https://github.com/boostorg/boost and use this fork in my project 2. Create a fork of the library/libraries I wanted to patch 3. Update the submodules in my boostorg/boost fork to point to my forked libraries 4. Post a pull request for the respective libraries. Once the changes have been accepted, point back to the official boostorg repo I failed terribly, no doubt due to PEBKAC. Is there a chance that someone could write a tutorial or a how-to guide for the recommended process of forking Boost with Git? The main thing I need is the ability to have a patched version of Boost that I can use while the patches are being reviewed/accepted/rejected. Thanks, Sohail

6 20

[algorithm] Test failure in C++14
by Ben Pope 25 Mar '14

25 Mar '14

"clang++-3.4" -c -x c++ -std=c++1y -stdlib=libc++ -O0 -g -fno-inline -Wall -g -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_DYN_LINK=1 -DBOOST_TEST_NO_AUTO_LINK=1 -I".." -o "/home/ben/development/boost/test/build/results/boost/bin.v2/libs/algorithm/test/is_permutation_test1.test/clang-linux-3.4~c14_libc++/debug/is_permutation_test1.o" "../libs/algorithm/test/is_permutation_test1.cpp" In file included from ../libs/algorithm/test/is_permutation_test1.cpp:13: ../boost/algorithm/cxx11/is_permutation.hpp:178:6: error: declaration conflicts with target of using declaration already in scope bool is_permutation ( ForwardIterator1 first1, ForwardIterator1 last1, ^ /usr/include/c++/v1/algorithm:1374:1: note: target of using declaration is_permutation(_ForwardIterator1 __first1, _ForwardIterator1 __last1, ^ ../boost/algorithm/cxx11/is_permutation.hpp:104:12: note: using declaration using std::is_permutation; // Section 25.2.12 ^ ../boost/algorithm/cxx11/is_permutation.hpp:205:6: error: declaration conflicts with target of using declaration already in scope bool is_permutation ( ForwardIterator1 first1, ForwardIterator1 last1, ^ /usr/include/c++/v1/algorithm:1361:1: note: target of using declaration is_permutation(_ForwardIterator1 __first1, _ForwardIterator1 __last1, ^ ../boost/algorithm/cxx11/is_permutation.hpp:104:12: note: using declaration using std::is_permutation; // Section 25.2.12 ^ 2 errors generated. I haven't looked in detail, but it looks like those two overloads were added in C++14 and need guarding with a suitable #if __cplusplus >= C++1Y_version_here Ben

3 5

[signals2] Test failure in C++11 (trivial fix for incorrect usage of boost::optional)
by Ben Pope 06 Mar '14

06 Mar '14

I have the following errors: "clang++-3.4" -c -x c++ -std=c++11 -stdlib=libc++ -O0 -g -fno-inline -Wall -g -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_NO_AUTO_LINK=1 -I".." -o "/home/ben/development/boost/test/build/results/boost/bin.v2/libs/signals2/test/signal_test.test/clang-linux-3.4~c11_libc++/debug/link-static/signal_test.o" "../libs/signals2/test/signal_test.cpp" ../libs/signals2/test/signal_test.cpp:32:16: error: invalid operands to binary expression ('boost::optional<int>' and 'int') if(max == false) max = *first; ~~~ ^ ~~~~~ "clang++-3.4" -c -x c++ -std=c++11 -stdlib=libc++ -O0 -g -fno-inline -Wall -g -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_NO_AUTO_LINK=1 -I".." -o "/home/ben/development/boost/test/build/results/boost/bin.v2/libs/signals2/test/track_test.test/clang-linux-3.4~c11_libc++/debug/link-static/track_test.o" "../libs/signals2/test/track_test.cpp" ../libs/signals2/test/track_test.cpp:36:14: error: invalid operands to binary expression ('boost::optional<int>' and 'int') if(max == false) Richard smith explains the problem here: http://llvm.org/bugs/show_bug.cgi?id=18180#4 "OK, I see what's happening -- in Clang 3.3 and GCC 4.8, 'false' is being treated as a null pointer constant. boost::optional implicitly converts to an "unspecified-bool-type" that happens to be a pointer-to-member type, and thus can be compared against a null pointer constant via the built-in operator!=(pointer-to-member, pointer-to-member) overload. In C++11 onwards, 'false' isn't a null pointer constant any more, so this comparison is no longer valid. Clang 3.3 and GCC 4.8 don't implement that rule; Clang 3.4 does." The trivial fix is to change the if statements at: ../libs/signals2/test/signal_test.cpp:32:16: ../libs/signals2/test/track_test.cpp:36:14: to if(!max) rather than if(max == false). Ben

7 19

DRYing BOOST_FUSION_ADAPT_STRUCT with decltype/Boost.TypeOf ?
by Damien Buhl 05 Mar '14

05 Mar '14

Hi dear Boost Fusion developers, I was asking myself if there were already plan to improve BOOST_FUSION_ADAPT_STRUCT to benefit from C++11 features like decltype ? This would be interesting to avoid the risk encountered that the types definitions can get out-of-sync. And would avoid typing type declarations twice. Currently there is BOOST_FUSION_DEFINE_STRUCT to avoid repeating the type information for each field. However this is something that makes most developer I know unhappy, as it obliges to modify the readable C++ aggregate types definition (i.e. Could be public headers) with this macro. Then there is the nice choice of BOOST_FUSION_ADAPT_STRUCT which obliges retyping the type and adds the risk that some field type information could get out-of-sync between the struct definition and the BOOST_FUSION_ADAPT_STRUCT listing. I think it would be valuable to add macros that would enable to select the fields that we want to adapt to a Random Access Sequence without requiring to repeat the type information. I would find more comfortable to write the example provided here http://www.boost.org/doc/libs/1_55_0/libs/fusion/doc/html/fusion/adapted/ad… as follow : namespace demo { struct employee { std::string name; int age; }; } // demo::employee is now a Fusion sequence BOOST_FUSION_ADAPT_STRUCT_EXT( demo::employee, (name) (age)) And a naïve implementation of BOOST_FUSION_ADAPT_STRUCT_EXT could be: #include <boost/typeof/typeof.hpp> #include <boost/fusion/include/adapt_struct.hpp> #include <boost/preprocessor/seq/for_each.hpp> #define ATTRIBUTE_DEFINITION(r, data, elem) \ (BOOST_TYPEOF(data::elem), elem) \ #define BOOST_FUSION_ADAPT_STRUCT_EXT(NAME, ATTRIBUTES) \ BOOST_FUSION_ADAPT_STRUCT(NAME, \ BOOST_PP_SEQ_FOR_EACH(ATTRIBUTE_DEFINITION, NAME, ATTRIBUTES)) #endif The same could certainly be achieved for BOOST_FUSION_ADAPT_TPL_STRUCT, while I didn't check. Thanks for the really great job done in Boost.Fusion. Cheers, -- Damien Buhl alias daminetreg

3 7

[Boost.Test] Assertion changes in trunk? [WAS: Call for Review: Boost.Test documentation rewrite]
by Dominique Devienne 19 Feb '14

19 Feb '14

On Wed, Jan 22, 2014 at 11:25 AM, Alexander Lamaison <awl03(a)doc.ic.ac.uk>wrote: > [...] As for as I'm aware, the only change is > to the assertion macros, which move to a more natural syntax: > > BOOST_CHECK_EQUAL(a, b) becomes BOOST_TEST(a == b) > BOOST_CHECK_LT(a, b) becomes BOOST_TEST(a < b) > ... etc. > BOOST_REQUIRE_EQUAL(a, b) becomes BOOST_TEST_REQUIRE(a == b) > ... etc. > BOOST_WARN_EQUAL(a, b) becomes BOOST_TEST_WARN(a == b) > But don't we then miss better messages which actually show the values themselves when the assert fails? I do BOOST_CHECK(a == b) only when a and b lack the op<<, but otherwise greatly prefer BOOST_CHECK_EQUAL(a, b). And what's the point of going from BOOST_REQUIRE(expr) to BOOST_TEST_REQUIRE(expr), i.e. make it longer / more typing? What am I missing? --DD

11 17

Refactoring tools/regression and tools/release into separate sub-modules
by Beman Dawes 14 Feb '14

14 Feb '14

The tools used by regression testers and regression reporting, and the tools used by release managers are currently part of the boost-super project. As we gain experience with Git and submodules, it is becoming clear these need to be decomposed into two separate submodules. Among other advantages, that would speed work on these tools as we could better utilize volunteers without having to hand out excessive super-project write permissions. We would like one or two volunteers to do the refactoring. You don't need to be a library maintainer or release manager, although that's fine if you are. You do need git skills, as we do want to preserve history. Comments? --The release managers

5 22

[git] automated update of superproject master branch
by Peter A. Bigot 14 Feb '14

14 Feb '14

I realize there are several email threads about how the super-project branch should be managed, but most pre-date live experience with boost on git and go deep into other aspects of the issue, so I still want to call this out specially: https://svn.boost.org/trac/boost/wiki/ModBigPicture specifies that the master branch on each module should be stable at all times, which is the right policy. Currently, the master branch on the super-project is automatically updated twice(?) per hour selecting all updates to the master branches of modules. Consequently, super-project master is the exact opposite of stable. This divergence is confusing. I'm unconvinced that waiting a few days will demonstrate a significant decrease in churn on the super-project master branch. Some is due to multiple updates to specific modules, which might decrease as maintainers become more familiar with git and only push once, but interoperability issues will still arise and there will be no way to tell which master branch commits produce a working Boost installation. There is value in having a branch with automated-update semantics, but IMO regardless of what the final policy will be, "master" is not the right choice for this, and automated updates of it should stop ASAP. Perhaps the update script can simply be moved to occur on latest/master and latest/develop. Leave master untouched until whatever gets committed to it has undergone cross-toolchain integration validation, and make develop available for changes to superproject content that are not just submodule updates. Peter

4 4

[Fibers] Performance
by Hartmut Kaiser 10 Feb '14

10 Feb '14

Oliver, Do you have some performance data for your fiber implementation? What is the (amortized) overhead introduced for one fiber (i.e. the average time required to create, schedule, execute, and delete one fiber which runs an empty function, when executing a larger number of those, perhaps 500.000 fibers)? It would be interesting to see this number when giving 1..N cores to the scheduler. Thanks! Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

14 92