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

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

[IdentityType] Const omission undocumented.
by Mostafa 03 Dec '13

03 Dec '13

#include <boost/utility/identity_type.hpp> #include <utility> int main() { BOOST_IDENTITY_TYPE(( std::pair<int,int> const )) x; // This compiles, so the const qualification in the // above macro parameter is ignored. x = std::make_pair(0,1); return 0; } The omission of const qualification in BOOST_IDENTITY_TYPE types is undocumented. This omission maybe deduced from the documented implementation, but, as noted, that is not part of the library api and is subject to change. I therefore propose that this behaviour be documented as part of the library's public api. Mostafa

4 5

[swap] std::swap should be pulled in from <utility> in C++11
by Joaquin M Lopez Munoz 03 Dec '13

03 Dec '13

Hi, boost/utility/swap.hpp #includes <algorithm> to bring std::swap in, which is OK for C++03 but not so in C++11: std::swap has been moved to <utility> as explained in [diff.cpp03.library]. Should I create a ticket? Best regards, Joaquín M López Muñoz Telefónica Digital

2 1

[git] Write (i.e. push) permission
by Beman Dawes 03 Dec '13

03 Dec '13

Boost library maintainers, please remember you need to apply for write permission for your library. See https://svn.boost.org/trac/boost/wiki/ModAdmin As of a couple of minutes ago, all pending requests for write permission have been completed. --Beman

1 0