- Boost - lists.boost.org

[GIT] What happens to the Trac?
by John Maddock 20 Dec '12

20 Dec '12

Currently the issue tracker is somewhat nicely integrated with SVN, what are we doing for issue tracking short/medium/long term? Apologies if this has been covered already, John.

14 24

[release][thread] Permission to merge.
by Vicente J. Botet Escriba 19 Dec '12

19 Dec '12

Hi, I would like to merge this change [1][82094] It is related to this feature request [2](#7422 Provide a condition variable with zero-overhead performance penality), but we can consider it as a bug, as the performance were degraded since boost.1.45. After the change the performances have been improved consequently as showed in [3] trunk-ni-7422 in green respect to trunk-ni in orange. [1] https://svn.boost.org/trac/boost/changeset/82094 [2] https://svn.boost.org/trac/boost/ticket/7422 [3] https://docs.google.com/spreadsheet/ccc?key=0Ai_v0rSH1AXrdHl2RDN4UkFYNHZ2aX… Please, could I merge it after the regression test cycle? Best, Vicente

2 1

Should I use std::get or boost::get (or both) in Boost.Array
by Marshall Clow 19 Dec '12

19 Dec '12

I've got a feature request for Boost.Array to provide compile-time checked access to the members of an array. In C++11, this is done using std::get<Idx> (std::array). Fine, I can specialize this in Boost.Array - well, for C++11. I can't specialize a nonexistent template in namespace std for C++03 (well, I _can_ but the standard says I must not). But Boost.Tuple has a get<> template. I believe I can specialize that for Boost.Array, w/o stepping on Boost.Tuples code. What do people think? boost::get? std::get? Both? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

2 4

Re: [boost] Heads up - string_ref landing
by Yanchenko Maxim 19 Dec '12

19 Dec '12

Marshall. low <mclow.lists. at> gmail.com> writes: > Please let me know what you think! As probably everyone, we have our own device for this. Here are some points and experience we gathered. 1. This class is essentially just an iterator_ range<char*> (modulo template for const/wchar_t), so it should either inherit from it or have corresponding converting ctors/operators. In this sense Olaf/Gennadiy's remarks are pretty valid. OTOH size is needed very frequently and having it precomputed is a good thing, so conversion approach seems to be better (but then we lose passing by reference as iterator_range, type_traits etc). I'm not sure what's more important. 2. Given the above, the name is misleading as it's not a reference to std::string. We use name char_range. 3. It's worth having a static constructor 'literal' (templated with size) to construct char_ranges from literals - as the compiler knows their size in compile time (minus zero terminator). It can be a constexpr too. Same manner - static function 'from_array', embrasing an array of chars in whole, assuming there is no zero terminator - useful for working with structures representing messages in char-based protocols with fixed-width fields. 4. (hack) We had to add a member function 'assign' (this is just operator=) to make boost::tokenizer return char_ranges. I don't like this part at all as it contradicts the meaning of say std::vector::assign, so I'd prefer another solution, probably in form of a customization point in boost::tokenizer. Thanks, Maxim

20 115

[Git] Boost website changes?
by Beman Dawes 18 Dec '12

18 Dec '12

The www.boost.org web site content needs to be reviewed, and all the Subversion references and instructions changed to Git and modular Boost. What is the best way to handle that? Create a branch similar to beta.boost.org? Who is willing to take on the management of updating web site content and monitor progress? --Beman

3 2

[Container] 'to_pointer' problem since 1.52
by Rich E 18 Dec '12

18 Dec '12

Just wanted to point out that there's an outstanding bug report due to some changes in Boost.Container that seem to have occured somewhere in the 1.52 dev cycle, reported here <https://svn.boost.org/trac/boost/ticket/7650>. In a nutshell, there is a compile time error caused by boost::container::list::const_iterator is trying to use a method called 'to_pointer' that doesn't exist (there is a 'pointer_to' method defined). We're using a modified version of boost/container/list.hpp at the moment, but it would be nice to ditch that come 1.53. The patch is so trivial that I thought it best to leave it up to the maintainer, as I really have no idea how to work with the current svn setup. cheers, Rich

2 1

Another set of macros to deprecate (and then remove)?
by Marshall Clow 18 Dec '12

18 Dec '12

There are a set of macros in Boost.config that describe "features that are not required by the C++ standard" Some of these features have been incorporated into C++11. I propose that we retire these macros, and have people use the shiny C++11 versions. In particular: BOOST_HAS_STATIC_ASSERT should be ! BOOST_NO_CXX11_ASSERT BOOST_HAS_VARIADIC_TMPL should be ! BOOST_NO_CXX11_VARIADIC_TEMPLATES BOOST_HAS_RVALUE_REFS should be ! BOOST_NO_CXX11_RVALUE_REFERENCES BOOST_HAS_CHAR_16_T should be ! BOOST_NO_CXX11_CHAR_16_T BOOST_HAS_CHAR_32_T should be ! BOOST_NO_CXX11_CHAR_32_T I'm using "!" here generically; in code you would replace #ifdef OLD_MACRO with #ifndef NEW_MACRO etc. I don't think this will be very disruptive; very few boost libraries use these macros. Opinions? Other macros that fit into this group? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

8 12

compilation warning on HEAD
by Gaetano Mendola 18 Dec '12

18 Dec '12

The HEAD in trunk have some compilation warnings using gcc 4.7.2 the following will fix some of those. Another warning about unused result is in here: libs/serialization/src/basic_iarchive.cpp line 576, the value is used in a BOOST_ASSERT, I don't know how you manage those cases. Regards Gaetano Mendola Index: libs/serialization/src/basic_serializer_map.cpp =================================================================== --- libs/serialization/src/basic_serializer_map.cpp (revision 81900) +++ libs/serialization/src/basic_serializer_map.cpp (working copy) @@ -43,8 +43,7 @@ BOOST_ARCHIVE_DECL(bool) basic_serializer_map::insert(const basic_serializer * bs){ // attempt to insert serializer into it's map - const std::pair<map_type::iterator, bool> result = - m_map.insert(bs); + m_map.insert(bs); // the following is commented out - rather than being just // deleted as a reminder not to try this. Index: boost/archive/iterators/transform_width.hpp =================================================================== --- boost/archive/iterators/transform_width.hpp (revision 81900) +++ boost/archive/iterators/transform_width.hpp (working copy) @@ -112,6 +112,7 @@ transform_width(BOOST_PFTO_WRAPPER(T) start) : super_t(Base(BOOST_MAKE_PFTO_WRAPPER(static_cast< T >(start)))), m_buffer_out_full(false), + m_buffer_in(), m_remaining_bits(0), m_end_of_sequence(false) {} @@ -119,8 +120,8 @@ transform_width(const transform_width & rhs) : super_t(rhs.base_reference()), m_buffer_out_full(rhs.m_buffer_out_full), + m_buffer_in(rhs.m_buffer_in), m_remaining_bits(rhs.m_remaining_bits), - m_buffer_in(rhs.m_buffer_in), m_end_of_sequence(false) {} }; -- cpp-today.blogspot.it

4 4

[Git] Documentation for Git and Modular Boost conversion
by Beman Dawes 18 Dec '12

18 Dec '12

We are starting to pull together documentation for the Git and Modular Boost conversion. https://svn.boost.org/trac/boost/wiki/WikiStart#GitandModularBoost Comments and corrections welcome! I'm particularly interested in unanswered questions you have after reading these initial docs. --Beman

20 98

static_vector using aligned_storage
by Adam Wulkiewicz 18 Dec '12

18 Dec '12

Hi, I'm developing R-tree container for Boost.Geometry. To keep it short, there are containers of Values in leaf nodes. Those containers must have push_back() functionality. For static-size nodes I'm using a container based on boost::array. Unfortunately this means that default constructors of stored Values are called when the container is created. I'd like not to expect that Values have their default ctor implemented. I've implemented an alternative container using boost::aligned_storage. This is just a proof of concept. The code is available here: https://svn.boost.org/svn/boost/sandbox-branches/geometry/index/tests/stati… I've searched for this kind of container in Boost since I remember that someone proposed it some time ago but didn't find it anywhere. Is it released somewhere? Maby as a part of some library? If not, would you be so kind and see if my solution should work for any/most popular compiler/platform? I've tested it only on clang. To be specific, won't there be any problems with the memory aligmnent if I use this code for storage: boost::aligned_storage<sizeof(Value) * Capacity> m_storage; this for access: *(reinterpret_cast<Value*>(m_storage.address()) + i); and this for construction new (reinterpret_cast<Value*>(m_storage.address()) + i) Value(value); Regards, Adam

8 26