- Boost - lists.boost.org

[Git] Extracting libraries from the svn sandbox
by Beman Dawes 20 Dec '12

20 Dec '12

One of the issues that came up in the documentation discussion was the desire to extract still useful sub-trees from the old svn sandbox, and to move them to GitHub. I've been able to extract my proposed endian library from the sandbox, history and all. Here was the process: 1) Created a empty repository named "endian" in my GitHub account via the usual web interface. 2) From the command line, in a temporary directory: git svn clone https://svn.boost.org/svn/boost/sandbox/endian (Got a "Error validating server certificate...", and gave "p" as a response to the "(R)eject, accept (t)emporarily or accept (p)ermanently?" query. The process ran for perhaps 10 minutes, but that was fine because it was successful at recovering history. And it is a one-time process.) cd endian git branch -d git-svn git push --mirror git@github.com:Beman/endian.git That's it! The git branch command deletes the git-svn branch, which is an artifact of the conversion process. Finish off by cloning the library in its permanent local location: cd permanent-local-location git clone git@github.com:Beman/endian.git Comments? Is there a better way to do this? Once comments have come in, I'll create a doc page for doing this, with a link from the FAQ. --Beman

7 15

[intrusive] boost/intrusive/detail/has_member_function_callable_with.hpp: inheriting from a const class
by Krzysztof Czainski 20 Dec '12

20 Dec '12

Hello, I tried to use a boost::container::vector with a Texas Instruments compiler, and I got an error pointing to line 88 of <boost/intrusive/detail/has_member_function_callable_with.hpp> "Invalid base class", with Type=const std::allocator<something>" Here's the context: template <typename Type> class BOOST_PP_CAT(has_member_function_named_, BOOST_INTRUSIVE_HAS_MEMBER_FUNCTION_CALLABLE_WITH_FUNCNAME) { struct BaseMixin { void BOOST_INTRUSIVE_HAS_MEMBER_FUNCTION_CALLABLE_WITH_FUNCNAME(); }; struct Base : public Type, public BaseMixin { Base(); }; // <-- line 88 The problem seems to be the constness of Type. Here's a simplified example: struct X {}; template < class T > struct Y : T { Y() {} }; int main() { Y<const X> y; } The above example compiles fine with Linux gcc version 4.5.4, and MinGW 4.5.0, but fails with my TI compiler. My question is: is this a bug of the TI compiler, or is that compiler actually right about this, and should we fix this in Boost? For now, my workaround is: struct Base : public ::boost::remove_cv<Type>::type, public BaseMixin { Base(); }; // <-- line 88 Regards, Kris

3 4

[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