December 2013 - Boost - lists.preview.boost.org

[git] regression tests?
by Oliver Kowalke 05 Dec '13

05 Dec '13

Hi, do the regression tests (trunk/release -> develop/master) source the git-repo boostorg? Oliver

2 1

[git] regression testing
by Joaquin M Lopez Munoz 05 Dec '13

05 Dec '13

Hi, Congrats on the recent Git switchover. Two questions: * Are regression test scripts yet adapted to the new repository? * For SVN, test columns mark the latest commit the tests are done against. How will we do with Git? Looks like commits are identified by 40-digit numbers, which are considerably harder to visually track than nice consecutive SVN changeset numbers. Joaquín M López Muñoz Telefónica Digital

3 3

Git hardlinks, and developing
by John Maddock 05 Dec '13

05 Dec '13

OK so I've just been hit by my first Git SNAFU. 1) I checked out modular Boost as per https://svn.boost.org/trac/boost/wiki/TryModBoost 2) Changed libs/multiprecision to the develop branch also as per https://svn.boost.org/trac/boost/wiki/TryModBoost 3) Added some pending changes from the old SVN Trunk that I didn't commit before the changeover. 4) Ran the tests and everything failed, even though it was passing on SVN :-( The issue was that the headers under boost/ were now *copies* of the last release and no longer pointers to the new "develop" code. Interestingly some of the hard links were updated when I ran bjam, but apparently not all :-( Running bjam -a fixes the issue, but it's a very easy trap for the unwary.... John. PS, one other very annoying issue for VC++ users: 1) Open a test file. 2) Select a #included boost file, right click and select "Open document". 3) Document opens, but gives you a copy under boost/ not the "real" header under libs/mylib/. 4) Run away screaming after you've spent an XXX hours editing the wrong file....

8 13

Possible issue with Boost.Atomic (and consequently Boost.Thread)
by Peter Dimov 04 Dec '13

04 Dec '13

In https://svn.boost.org/trac/boost/ticket/9466 it is reported that using Boost.Thread on AIX without defining BOOST_THREAD_DONT_USE_ATOMIC causes an assertion failure in boost/smart_ptr/detail/lwm_pthreads.hpp (pthread_mutex_lock failing with EINVAL.) As I explain in the ticket, what I think happens is that Boost.Atomic falls back to its generic lock pool implementation, which uses a static array of 41 boost::lightweight_mutex objects. However, since lightweight_mutex has a constructor calling pthread_mutex_init and a destructor calling pthread_mutex_destroy, using call_once, directly or indirectly, outside main can lead to accessing a mutex object before it's constructed or after it's destroyed, depending on static initialization order. If I'm correct in this assumption, then lockpool.hpp/.cpp need to be fixed to either use boost/smart_ptr/detail/spinlock_pool.hpp*, or use statically initialized pthread mutexes directly. *) Which is basically what it was designed for, see the comment: // spinlock_pool<0> is reserved for atomic<>, when/if it arrives

2 4

[util] Any interest in address_of_first_nonarray_elem ?
by Mostafa 04 Dec '13

04 Dec '13

Working with built-in array objects I find myself repeatedly needing to get the address of the first non-array element. This is so I can do generic array comparisons and copies without resorting to multiple loops. For example: template <typename T, std::size_t N> bool generic_array_equal(T (&lhs)[N], T const (&rhs)[N]) { return std::equal( address_of_first_nonarray_elem(lhs), address_of_first_nonarray_elem(lhs) + total_extent<T[N]>::size, address_of_first_nonarray_elem(rhs)); } Any interest in adding such a function to the util library? Mostafa

5 8

Gitflow (was Git: maintaining super-project)
by Mateusz Loskot 04 Dec '13

04 Dec '13

On 4 December 2013 12:03, Jeremy Ong <jeremycong(a)gmail.com> wrote: > Maybe I should have said "github" world. Many organizations and open source > projects choose to make it the lowest branch in the hierarchy specifically > because it *is* the default. I wasn't aware that boost uses nvie's gitflow. > There are many that feel it's a bit overengineered, but if it's specified > somewhere that that is what we're using then eschewing the defaults is fine. Use of GitHub is orthogonal to development workflow. Somewhat 'traditionally', GitHub is perceived as an incubator of fast yet agile Ruby/... web shops which don't rely on a typical release model, but they constantly roll releases. Boost is not a rolling release based project! I will conclude with Scott Chacon's blog (http://scottchacon.com/2011/08/31/github-flow.html) """ For teams that have to do formal releases on a longer term interval (a few weeks to a few months between releases), and be able to do hot-fixes and maintenance branches and other things that arise from shipping so infrequently, git-flow makes sense and I would highly advocate it’s use. For teams that have set up a culture of shipping, who push to production every day, who are constantly testing and deploying, I would advocate picking something simpler like GitHub Flow. """ Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net

1 0

BOOST_NO_CXX11_ATOMIC?
by Peter Dimov 04 Dec '13

04 Dec '13

Now is perhaps not a very appropriate time to ask, but why don't we seem to have a macro for the <atomic> C++11 header?

6 13

[container] Doc regressions in 1.54 and 1.55
by Jared Grubb 04 Dec '13

04 Dec '13

I went to look up the API on "flat_set" and found that the header documentation after 1.53 is not helpful. I think this is unintentional, so I thought I'd point it out: http://www.boost.org/doc/libs/1_53_0/doc/html/boost_container_header_refere… 1.53 docs: "class flat_set" is shown in the <flat_set.hpp> section; the link takes you to the API reference -- perfect! http://www.boost.org/doc/libs/1_54_0/doc/html/boost_container_header_refere… 1.54 docs: "class flat_set" only appears in <container_fwd.hpp> section; the link takes you to the forward decl only and not a reference header. However, other references to "flat_set" (for example, in the free functions like operator==) are hyperlinked and do take you to the right header reference file.. http://www.boost.org/doc/libs/1_55_0/doc/html/boost_container_header_refere… 1.55 docs: "class flat_set" is not listed at all. The API header reference does not exist and none of the references to flat_set are hyperlinked. Jared

2 1

[GitHub] README policy?
by Mateusz Loskot 04 Dec '13

04 Dec '13

Hi, A little trivia, apparently GitHub wishes every repository has a readme: "We recommend adding a README to this repository to help give people an overview of your project." Is there any policy about if such README is required and what it should contain? Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net

1 0

[modular boost] non-linked headers
by Edward Diener 04 Dec '13

04 Dec '13

On Windows after the .\b2 headers step, there are these directories under the modular-boost/boost diectory which are not symbolic links: detail graph numeric pending I can understand 'detail' but should not the others have been created as symbolic links to their appropriate libraries header files ?

6 36