- Boost - lists.boost.org

Re: [boost] [1.54.0] Beta 1 Available
by Cromwell Enage 11 Jun '13

11 Jun '13

Hi, all. When calling the merge() member function of a boost::heap::d_ary_heap, is the heap passed in not supposed to be emptied? Here's my test program: ['' #include <boost/heap/d_ary_heap.hpp> #include <boost/heap/binomial_heap.hpp> #include <boost/heap/fibonacci_heap.hpp> #include <boost/heap/pairing_heap.hpp> #include <boost/heap/skew_heap.hpp> #include <boost/test/minimal.hpp> template <typename Heap> void test_heap_merge_memfun() { Heap heap_1, heap_2; heap_1.push(3); heap_1.push(5); heap_1.push(1); heap_2.push(2); heap_2.push(4); heap_2.push(0); heap_1.merge(heap_2); std::cout << " heap_2"; if (!heap_2.empty()) { BOOST_CHECK(4 == heap_2.top()); heap_2.pop(); BOOST_CHECK(2 == heap_2.top()); heap_2.pop(); BOOST_CHECK(0 == heap_2.top()); heap_2.pop(); std::cout << " not"; } std::cout << " emptied." << std::endl; BOOST_CHECK(heap_2.empty()); BOOST_CHECK(5 == heap_1.top()); heap_1.pop(); BOOST_CHECK(4 == heap_1.top()); heap_1.pop(); BOOST_CHECK(3 == heap_1.top()); heap_1.pop(); BOOST_CHECK(2 == heap_1.top()); heap_1.pop(); BOOST_CHECK(1 == heap_1.top()); heap_1.pop(); BOOST_CHECK(0 == heap_1.top()); heap_1.pop(); BOOST_CHECK(heap_1.empty()); } int test_main(int argc, char** argv) { test_heap_merge_memfun< boost::heap::d_ary_heap< int , boost::heap::arity<4> , boost::heap::mutable_<true> > >(); test_heap_merge_memfun<boost::heap::binomial_heap<int> >(); test_heap_merge_memfun<boost::heap::fibonacci_heap<int> >(); test_heap_merge_memfun<boost::heap::pairing_heap<int> >(); test_heap_merge_memfun< boost::heap::skew_heap<int,boost::heap::mutable_<true> > >(); return 0; } ''] When I run this program, I see that all the other heap types empty the heap passed in. I use gcc 4.2.1 with Apple clang version 4.0 on MacOSX 10.8 Cromwell D. Enage

2 1

[parameter] BOOST_PARAMETER_CONSTRUCTOR bug
by James Hirschorn 10 Jun '13

10 Jun '13

I've already submitted a bug report, but I'm also posting it here in case anyone has more info. ------------- The following variation on the example from the boost::parameter tutorial, where the required parameter is changed to optional, fails to compile. myclass_impl is being passed an empty argument list. #include <iostream> #include <boost/parameter.hpp> BOOST_PARAMETER_NAME(name) BOOST_PARAMETER_NAME(index) struct myclass_impl { template <class ArgumentPack> myclass_impl(ArgumentPack const& args) { std::cout << "name = " << args[_name] << "; index = " << args[_index] << std::endl; } }; struct myclass : myclass_impl { BOOST_PARAMETER_CONSTRUCTOR( myclass, (myclass_impl), tag , (optional (name, *) (index, *) ) ) // no semicolon }; int main(int argc, char * argv[]) { myclass C(_name="hello", _index=0); }

3 6

[type_erasure] Compilation time
by Felipe Magno de Almeida 10 Jun '13

10 Jun '13

Hello Steven, Is there anyway to not include some definitions in header to delay instantiation for use with explicit template instantiations in specific translation units with type_erasure? I have a CORBA library which uses type_erasure for each interface defined in IDL. The problem is that if I include too many #include's for the precompiled headers which use type_erasure, then the compiler ends up consuming too much memory (>10GB), which makes it unfit for 32bit compilers which can use at most 3GB. Regards, -- Felipe Magno de Almeida

2 2

Re: [boost] [multiprecision] Are these types suitable as numeric types for unit tests?
by Daryle Walker 09 Jun '13

09 Jun '13

-----Original Message----- From: John Maddock Sent: Saturday, June 08, 2013 4:40 AM >> I'm getting warnings about integer overflow. The problem is at Line >> 59 of boost/test/tools/detail/print_helper.hpp. It sets an output >> stream's precision based on the digits given by std::numeric_limits. > >That's harmless but annoying: it's because std::numeric_limits<cpp_int>::digits is >INT_MAX. The stream precision isn't ever used by integer types anyway... I switched to one of the fixed-sized types (512 bits). >> This time it's an error, at Line 59 of >> boost/test/tools/floating_point_comparison.hpp. There no (close >> enough) matching function for "fpt_abs" from some >> "boost::multiprecision::detail::expression<..." type. (It was >> truncated by the display. I don't know how to get a clean print-out >> of errors from >> Code::Blocks.) I'm guessing the expression template setup is screwing >> things up. > >Yes, it's because Boost.Test can't be used with expression template enabled types. >It's a known issue, and I've added a patch for this: >https://svn.boost.org/trac/boost/ticket/8272, but Genediiy seems to be MIA at present :-( > >Do you particularly want to test with expression-template enabled types (I reaslise >there are cases when you do)? If not then you could use multiprecision types that >have expression templates turned off and that should fix things. I switched to the same type with expression-templates turned off. Daryle W.

1 0

[range] [extensions] Default values for range access adaptors?
by Viktor Sehr 09 Jun '13

09 Jun '13

I'd like to suggest the addition of a default value to the range access adaptors. Either by adding it as an extra, non-necessary parameter for the functions, or by duplicating the functions as "front_or_default(T default value)". For example it would be useful for finding objects which I am not sure exists in a range. std::vector<int> vec = boost::assign::list_of(2)(4)(6); auto first_odd = vec | filtered(is_odd) | front(); // undefined? auto first_odd = vec | filtered(is_odd) | front_or_default(-1); // everything is fine! Another option would be a function which returns the adress, or nullptr if the value does not exist? /Viktor

5 14

boost.range bug in transformed or sliced
by John Reid 09 Jun '13

09 Jun '13

Suppose you wish to transform and slice a random access range. Surprisingly the order in which you apply the operations makes a big difference to performance. I'm guessing this is not desired behaviour, correct me if I'm wrong. AFAICT when transforming happens before slicing the iterators involved in the internals of boost.range are being treated as forward iterators not random access iterators. An advance() operation is made on one of the iterators with a negative number and this advance is O(n) for forward iterators but O(1) for random access. The code below demonstrates (adapted from sliced example code). On an unrelated note the documentation for transformed does not mention that the function is part of the range return type. It is given as: boost::transformed_range<typeof(rng)> Code to demonstrate the transform then slice problem: #include <boost/range/adaptor/transformed.hpp> #include <boost/range/adaptor/sliced.hpp> #include <boost/range/algorithm/copy.hpp> #include <boost/assign.hpp> #include <iterator> #include <iostream> #include <vector> #include <functional> struct identity { typedef int result_type; result_type operator()( int i ) const { return i; } }; int main(int argc, const char* argv[]) { using namespace boost::adaptors; using namespace boost::assign; std::vector< int > input; input += 1,2,3,4,5,6,7,8,9; // slicing then transforming my iterator range std::cout << "Sliced then transformed: "; boost::copy( input | sliced( 2, 8 ) | transformed( identity() ), std::ostream_iterator< int >( std::cout, ",") ); std::cout << "\n"; // transforming then slicing my iterator range - takes a very long time.... std::cout << "Transformed then sliced: "; boost::copy( input | transformed( identity() ) | sliced( 2, 8 ), std::ostream_iterator< int >(std::cout, ",")); std::cout << "\n"; return 0; }

4 5

merge of interface modification?
by Oliver Kowalke 09 Jun '13

09 Jun '13

Do I get permission to merge a change in the interface of boost.coroutine into release?

2 3

[Boost.Test] Error with "putenv" when using (1.53) release branch
by Daryle Walker 07 Jun '13

07 Jun '13

This happened to me a few months ago when trying out a Windows 8 compiling setup with Code::Blocks. I pointed to the release branch of Boost, which should be set to 1.53. I included Boost.Test, I think by #including boost/test/include/unit_test.hpp so everything comes in without linking in the library directly. There was some sort of error involving "putenv," not sure what anymore. I "fixed" it by switching to the trunk branch. Now I'm trying a new setup, with Eclipse. This time I'm adding Boost.Test by adding the files directly to the project list. (I'm experimenting with splitting my tests into 3 files.) I'm referencing the release branch again, which should still be on 1.53. I got "'putenv' was not declared in scope" error. It's at Line 95 of boost/test/utils/runtime/config.hpp. Did a hard error sneak by everyone, or is my setup incomplete? Both IDE setups use G++ on MinGW for the compiler. Is there some #define I'm missing? Should I switch to using the trunk again? Daryle W.

1 0

All talks for Meeting C++ 2013 are online!
by Jens Weller 06 Jun '13

06 Jun '13

Hi boost & C++ Community, to keep this short, all talks are online now, the schedule comes next week: http://meetingcpp.com/index.php/talks.html kind regards, Jens Weller

1 0

merge of bugfixes still possible
by Oliver Kowalke 06 Jun '13

06 Jun '13

Hi, I got a bug-report two days before - I'd like to merge the bugfix into the release. Do I get the permission? Oliver

2 1