- Boost - lists.boost.org

[boost::bind] How does it works for overloaded member functions in this example?
by Chaos A.D. 02 Oct '10

02 Oct '10

Hi there! Recently I was extremely surprised by the fact that boost::bind can handle the case of binding overloaded member functions! Here is the simplified testcase, which works fine in gcc 4.4.3. #include <boost/bind.hpp> struct Test { static void Func(int) {}; static void Func(int, const char*) {}; }; int main(int argc, char **argv) { boost::bind(&Test::Func, 5)(); boost::bind(&Test::Func, 5, "WORKS!")(); return 0; } In full testcase i tried to reproduce simplified boost::bind logic, and ensured, that my simplified version is still incorrect: #include <boost/bind.hpp> template <class A1> class Args1 { template <class Fn> void call(Fn fn) { fn(a1); } A1 a1; }; template <class A1, class A2> class Args2 { template <class Fn> void call(Fn fn) { fn(a1, a2); } A1 a1; A2 a2; }; template <class Fn, class Args> struct bind_t { bind_t( Fn fn, Args const& args ) : fn_(fn), args_(args) {} void operator()() { args_.call(fn_); } private : Fn fn_; Args args_; }; template <class Fn, class A1> bind_t< Fn, Args1<A1> > bind(Fn fn, A1 a1) { typedef Args1<A1> args; return bind_t<Fn, args>(args(a1)); } template <class Fn, class A1, class A2> bind_t< Fn, Args2<A1, A2> > bind(Fn fn, A1 a1, A2 a2) { typedef Args2<A1, A2> args; return bind_t<Fn, args>(args(a1, a2)); } struct Test { static void Func(int) {}; static void Func(int, const char*) {}; }; int main(int argc, char **argv) { boost::bind(&Test::Func, 5)(); boost::bind(&Test::Func, 5, "WORKS!")(); bind(&Test::Func, 5)(); bind(&Test::Func, 5, "NOT WORKS!")(); return 0; }

4 3

[btree] Large file support
by Beman Dawes 01 Oct '10

01 Oct '10

The btree library uses low level I/O. On POSIX-like systems that means read/write/lseek. lseek() won't support large files on systems where long is 32 bits. POSIX-like operating systems get around this problem by supply functions with names like llseek or lseek64 that traffic in long long instead of long. So there is a line of code: new_offset = ::lseek(handle(), offset, whence); // offset is a variable of type int64_t That needs to change to something like: #if defined(SOMEOS) new_offset = ::|lseek(handle(), offset, whence); #elif defined(ANOTHEROS) new_offset = ::whatever(handle(), offset, whence); #else new_offset = ::lseek(handle(), offset, whence); #endif Up at the front of the source file there may also have to be special headers included or symbols defined, depending on the operating system. I'd appreciate some help from folks familiar with particular non-Windows operating systems. What is the preferred name for the 64-bit seek function and what is the preferred #if defined(symbol)? Do special headers have to be included or special symbols defined? Thanks, --Beman

4 3

[1.43.0] [variant] Compilation errors when swapping variant type objects
by Adam Badura 01 Oct '10

01 Oct '10

We are using Boost 1.43.0 (we tried to move to 1.44.0 but there were some problems which I reported some time ago) in Visual Studio 2010. And there are some compilation problems when variant type objects are swapped. This does not affect all variant types but I didn't figured out what are the exact conditions (however I guess it is likely something with namespaces and templates). Following code demonstrates the issue: ---------------------------------------- #include <cstdlib> #include <list> #include <boost/variant.hpp> int main() { typedef boost::variant< std::list< int >::iterator > variant_type; variant_type v; variant_type().swap( v ); return EXIT_SUCCESS; } ---------------------------------------- compilation fails with following message: ---------------------------------------- 1>d:\libraries\boost_1_43_0\boost\variant\detail\move.hpp(155): error C2668: 'boost::detail::variant::detail::move_swap::swap' : ambiguous call to overloaded function 1> d:\libraries\boost_1_43_0\boost\variant\detail\move.hpp(141): could be 'void boost::detail::variant::detail::move_swap::swap<T>(T &,T &)' 1> with 1> [ 1> T=T0 1> ] 1> c:\program files\microsoft visual studio 10.0\vc\include\utility(100): or 'void std::swap<T>(_Ty &,_Ty &)' [found using argument-dependent lookup] 1> with 1> [ 1> T=T0, 1> _Ty=T0 1> ] 1> while trying to match the argument list '(T0, T0)' 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(698) : see reference to function template instantiation 'void boost::detail::variant::move_swap<T>(T &,T &)' being compiled 1> with 1> [ 1> T=T0 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(825) : see reference to function template instantiation 'void boost::detail::variant::swap_with<Variant>::operator ()<T>(T &) const' being compiled 1> with 1> [ 1> Variant=boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>, 1> T=T0 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\detail\visitation_impl.hpp(141) : see reference to function template instantiation 'void boost::detail::variant::invoke_visitor<Visitor>::internal_visit<T>(T &,int)' being compiled 1> with 1> [ 1> Visitor=boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>>, 1> T=T0 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\detail\visitation_impl.hpp(169) : see reference to function template instantiation 'void boost::detail::variant::visitation_impl_invoke_impl<Visitor,VoidPtrCV,T>(int,Visitor &,VoidPtrCV,T *,boost::mpl::false_)' being compiled 1> with 1> [ 1> Visitor=boost::detail::variant::invoke_visitor<boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>>>, 1> VoidPtrCV=void *, 1> T=T0 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\detail\visitation_impl.hpp(252) : see reference to function template instantiation 'void boost::detail::variant::visitation_impl_invoke<Visitor,VoidPtrCV,T0,NoBackupFlag>(int,Visitor &,VoidPtrCV,T *,NoBackupFlag,int)' being compiled 1> with 1> [ 1> Visitor=boost::detail::variant::invoke_visitor<boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>>>, 1> VoidPtrCV=void *, 1> NoBackupFlag=boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>::has_fallback_type_, 1> T=T0 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(1769) : see reference to function template instantiation 'void boost::detail::variant::visitation_impl<first_which,first_step,Visitor,VoidPtrCV,boost::variant<T0_>::has_fallback_type_>(const int,const int,Visitor &,VoidPtrCV,boost::mpl::false_,NoBackupFlag,Which *,step0 *)' being compiled 1> with 1> [ 1> Visitor=boost::detail::variant::invoke_visitor<boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>>>, 1> VoidPtrCV=void *, 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>>, 1> NoBackupFlag=boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>::has_fallback_type_, 1> Which=first_which, 1> step0=first_step 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(1780) : see reference to function template instantiation 'void boost::variant<T0_>::internal_apply_visitor_impl<Visitor,void*>(int,int,Visitor &,VoidPtrCV)' being compiled 1> with 1> [ 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>>, 1> Visitor=boost::detail::variant::invoke_visitor<boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>>>, 1> VoidPtrCV=void * 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(1803) : see reference to function template instantiation 'void boost::variant<T0_>::internal_apply_visitor<boost::detail::variant::invoke_visitor<Visitor>>(boost::detail::variant::invoke_visitor<Visitor> &)' being compiled 1> with 1> [ 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>>, 1> Visitor=boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>> 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(1637) : see reference to function template instantiation 'void boost::variant<T0_>::apply_visitor<boost::detail::variant::swap_with<Variant>>(Visitor &)' being compiled 1> with 1> [ 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>>, 1> Variant=boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>, 1> Visitor=boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>> 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(1631) : while compiling class template member function 'void boost::variant<T0_>::swap(boost::variant<T0_> &)' 1> with 1> [ 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>> 1> ] 1> d:\test\simple\simple.cpp(10) : see reference to class template instantiation 'boost::variant<T0_>' being compiled 1> with 1> [ 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>> 1> ] ---------------------------------------- Adam Badura

2 2

Potential scoped_ptr improvement
by David Abrahams 30 Sep '10

30 Sep '10

The incantation scoped_ptr<Base> x( new Derived ); will succeed and produce undefined behavior upon x's destruction unless Derived has a trivial or virtual d'tor. It would be pretty easy to prevent something like that from compiling when has_virtual_destructor<Base>::value is false. Thoughts? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 2

[btree] Library working with more compilers and standard libraries
by Beman Dawes 30 Sep '10

30 Sep '10

* VC++ 10 and MinGW/gcc 4.5 are my primary platforms, and the tests continue to pass on those. Some of the tests have been beefed up, too. * The Btree library now passes tests with Cygwin/gcc 4.3. That was a bug in my POSIX implementation code that is now fixed. * VC++ 9 is working OK in release mode. There is a bug in some debug mode code in the standard library <algorithm> header's lower_bound and upper_bound functions. I'm not sure how to deal with that. Maybe supply lower_bound/upper_bound implementations, and switch to them when needed. * I'm about to start a round of tests on Linux. --Beman

3 4

Re: [boost] [guidelines] why template errors suck
by Andrzej Krzemienski 29 Sep '10

29 Sep '10

> > > Well, I believe I got it wrong. It is concept maps where the specializtion > > > is to tke plce. It should read: > > > > > > explicit concept< typename T > IntOrPair > "explicit concepts" were never part of any accepted proposal ;-) > > { > > int sum_ints_impl( T const& ); > > } > > > > concept_map IntOrPair<int> > > { > > int sum_ints_impl( int const& i ) { return i; } > > } > > > > template< IntOrPair type1, IntOrPair type2 > > > concept_map IntOrPair< std::pair<type1, type2> > > > { > > int sum_ints_impl( std::pair<First, Second> const& p ) { > > return sum_ints_impl(p.first) + sum_ints_impl(p.second); > > } > > } > > > > template<IntOrPair T> > > int sum_ints( T const & t ) > > { > > return IntOrPair::sum_ints_impl( t ); > > } > I think what you wrote is equivalent to what I posted in > http://permalink.gmane.org/gmane.comp.lib.boost.devel/209012 > However, as I noted in that message, trying to constrain something to > be either an Int or a Pair is really against the spirit of GP. I understand. On the other hand, even though concepts were designed to support GP, once they are designed it would be interesting to see how they can be used to do other thing, and what other possibilities they enable. Regards, &rzej

2 1

Advice sought on memory allocation latency reduction C++ standard proposal
by Niall Douglas 29 Sep '10

29 Sep '10

Dear Boost Devs, I am hoping to gain feedback on an ISO C++ standard library proposal I hope to submit. It consists of a rationale (http://mallocv2.wordpress.com/) which shows how growth in RAM capacity is exponentially outgrowing the growth in RAM access speed. The consequences are profound: computer software which has always been written under the assumption of scarcity of RAM capacity will need to be retargeted to assume the scarcity of RAM access speed instead. I appreciate that Boost is not the C++ standard library, however I have asked this on comp.std.c++ and received no reply at all. The proposal comes in two parts: (i) The C proposal (http://mallocv2.wordpress.com/the-c-proposal-text/) which extends the classic 1979 malloc API to enable realloc() to speculatively attempt in-place allocation resizing and (ii) the C++ proposal (http://mallocv2.wordpress.com/the-cpp-proposal-text/) which extends std::allocator<> with batch allocation and deallocation member functions along with a reallocate() member function. These work much as expected and are intended for STL implementations - I have given a sample std::vector<>::reserve() implementation for the Dinkumware STL which attempts an in-place extension before performing a move construction of the vector contents. I am going to guess that these member functions will be fairly uncontroversial - reallocate() in particular has been in the SGI STL for a while, though in an unhelpful form which is basically a realloc() wrapper. What I think will likely be much more controversial are the new std namespace functions: template<class T, class allocator=allocator<T>, class... Args> typename allocator<T>::pointer New(Args&&... args); template<class T, class allocator=allocator<T>, class... Args> typename allocator<T>::pointer NewA(size_t n, Args&&... args); template<class T, class allocator=allocator<T> > void Delete(typename allocator<T>::const_pointer p); template<class T, class allocator=allocator<T> > void DeleteA(typename allocator<T>::const_pointer p); These parallel global operators new and delete except of course that they are standard functions and take a std::allocator<> type with which they perform the allocation and deallocation. The biggest danger here obviously enough is the chance of collision with any New() or Delete() defined by application code as the overloading and type specialisation problems (thanks to the unhelpful syntax) of operators new and delete are well known. The second biggest danger is the perhaps confusing duplication of functionality, though of course std::New() and std::Delete() are intended as a superset of global operators new and delete. I would appreciate any feedback, and in case you don't think discussion of this topic is appropriate here I will cross post this email to comp.std.c++. You can reply there instead if you wish. My thanks in advance for your time and consideration. Niall Douglas -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909.

3 2

Floating point truncation bug in qi::float_
by Henry Tan 29 Sep '10

29 Sep '10

Hi I am using boost 1.4.1 Spirit::Qi. I think we have a floating point truncation bug in the qi::float_ parser. I attached a simple program to repro the bug. Below are some examples of an input floating point gets truncated (=>) by the qi::float_: 12312321421421 => 12312321720320.000000 123123214 => 123123216.000000 123233.4124 => 123233.406250 I don't see the same issue with the qi::double_. Wondering if this is a known issue? Regards, HTan

5 4

How to cast _1 ?
by Henry Tan 29 Sep '10

29 Sep '10

I want to cast a value of _1 to a _val of a different type. How do I do that? I tried using static_cast_, it does not compile for me. rule<UInt8Iterator, UInt32()> MyRule; ... MyRule = (long_ | float_) [_val = static_cast_<UInt32>(_1)] Any help is appreciated Regards, Henry

2 1

Re: [boost] [asio] Question regarding io_service.post() and pool of threads
by Tan, Tom (Shanghai) 29 Sep '10

29 Sep '10

-----Original Message----- Date: Tue, 28 Sep 2010 11:18:22 +0800 From: Romain CHANU <romainchanu(a)gmail.com> To: boost(a)lists.boost.org Subject: [boost] [asio] Question regarding io_service.post() and pool of threads > >Extracted from Boost Asio reference: "The >io_service<http://www.boost.org/doc/libs/1_44_0/doc/html/boost_asio/ref >erence/io_service.html> >guarantees >that the handler will only be called in a thread in which the run(), >run_one (), poll() or poll_one() member functions is currently being invoked." > >For my understanding, since there is a pool of threads, a handler can >run concurrently in different threads, even though we are using >io_service.post(). > >Is that correct? My concern here is about the need or not to lock the >data accessed by the handler. > My understanding is that, it's another way to say that those calls won't create an additional thread while calling the completion handler having been registered by io_service.post(). Therefore, if io_service.run() itself is running in n threads, it's guaranteed all the registered completion handler will be invoked in at most n threads at random order, since there are only n threads in total . -Tom

2 1