October 2011 - Boost-users - lists.preview.boost.org

boost::asio::io_service - cancel posted work
by Christopher Pisz 05 Oct '11

05 Oct '11

I posted an async_accept to my io_service. The async_accept gets posted again to listen for incoming connections every time it completes. I was under the impression that calling io_service::stop, would be the way to stop listening. When debugging, I see that a function object was created when I called bind inside my async_accept call. That function object contains a smart pointer to the instance of the object to whom the method to call back belongs. Since the callback never happens, my instance never gets destroyed. How do I effectively cancel any outstanding work the io_service has posted to it, such that the smart pointer in the function object that the bind created will lose its reference count? In debugging, the callback never gets called after stop, not does the reference count in the smart pointer decrement.

1 1

[Boost Asio]Difference between asynchronous (proactor pattern) and synchronous model in web server
by Tu Hoang Do 05 Oct '11

05 Oct '11

I'm learning network programming and boost asio on my own, so there's something I need clarification in my understanding.. In synchronous model, when a client connects to the server, both the client and server have to sync with each other to finish some operations. Meanwhile, the asynchronous model allows client and server to work separated and independently. The client sends a request to establish a connection and do something. While the server is processing the request, the client can do something else. Upon completion of an operation, the completion event is placed onto a queue in an Event Demultiplexer, waiting for a Proactor (such as HTTP Handler) to send the request back and invoke a Completion Handler (on the client). The terms are used as in boost::asio document The Proactor Design Pattern: Concurrency Without Threads<http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/overview/core/asyn…> . By working this way, the asynchronous model can accepts simultaneous connections without having to create a thread per connection, thus improve overall performance. In order to achieve the same effect as asynchronous model, the first model (synchronous) must be multi-threaded. For more detail, refer to: Proactor Pattern<http://www.google.com/url?sa=t&source=web&cd=1&sqi=2&ved=0CBsQFjAA&url=http…>(I actually learn proactor pattern which is used to asynchronous model from that document. In here it has description on a typical synchronous I/O web server). Is my understanding on the subject correct? If so, which means the asynchronous server can accepts request and return results asynchronously (the first connection request the service on web server does not need to be the first to reply to)? In essence, asynchronous model does not use threading (or threading is used in individual components, such as in the Proactor, Asynchronous Event Multiplexer (boost::asio document) component, not by creating an entire client-server application stack, which is describe in the multi-threaded model in Proactor Pattern document, section 2.2 - *Common Traps and Pitfalls of Conventional Concurrency Models*).

1 0

Cross Compilation problem
by Jose 05 Oct '11

05 Oct '11

Hello all, I have been struggling with this problem for 2 days and I cannot really find a solution. I have a c++ application that I want to cross compile under Fedora 15 to use it with Windows. The packages that my app depends on are already pre-compiled in : /usr/i686-mingw32...../ I am using CMake. It compiles okay and I generate the .exe file without problems. When I try to run it under Windows it complains : "The program cant start because boost_filesystem-gcc45-mt-1_46_1.dll ins missing......." I have boost 1.47 installed in the windows machine but the libraries have a different suffix (...vc-xx-mt...) When I cross compile I do it statically ( I am attaching my toolchain-mingw32 file ) My question is, why is the exe program looking for the boost dll with exactly the same name as it has in the linux machine where the cross compiled exe has been built from?? In my fedora mingw32 lib folder the boost libraries look like this : libboost_filesystem-gcc45-mt-1_46_1.dll·a Is there any way to tell cmake to disregard those suffixes while running in Windows? Is there any way to tell cmake to copy the boost libraries needed for my application into a local folder that will be included inside the the windows installer?? Also while cross compiling I had gotten this error : In file included from /usr/i686-pc-mingw32/sys-root/mingw/include/boost/functional/hash/detail/hash_float.hpp:17, from /usr/i686-pc-mingw32/sys-root/mingw/include/boost/functional/hash/hash.hpp:15, from /usr/i686-pc-mingw32/sys-root/mingw/include/boost/functional/hash.hpp:6, from /usr/i686-pc-mingw32/sys-root/mingw/include/boost/unordered/unordered_set.hpp:17, from /usr/i686-pc-mingw32/sys-root/mingw/include/boost/unordered_set.hpp:16, from /mnt/VirtualBoxShare/percolator/src/ProteinProbEstimatorHelper.h:33, from /mnt/VirtualBoxShare/percolator/src/ProteinProbEstimator.cpp:28: /usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:105: error: expected unqualified-id before 'unsigned' /usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:105: error: expected ';' before 'unsigned' /usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:105: error: declaration does not declare anything /usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:114: error: expected unqualified-id before 'unsigned' /usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:114: error: expected ';' before 'unsigned' /usr/i686-pc-mingw32/sys-root/mingw/include/boost/cstdint.hpp:114: error: declaration does not declare anything It seemed boost defines a typedf in cstdint that is already defined in somewhere else, I would guess it is because the windows flag is activated even though it is compiling under linux. I fixed it checking it the definition has been made already but this is not a proper solution. Is it maybe that definition in my code or another cross compiled library? Thank you so much Jose

1 1

excluding tests
by Ovanes Markarian 05 Oct '11

05 Oct '11

Hello *, I currently ran accross an issue, where I need to exclude some particular test cases. I think this can be a useful extension for Boost.Test FW. Would be interesting to hear Gennadiy's opinion and what others think. I also came accross this link, where an extension for Boost Test is implemented to run/exclude platform-dependent tests. Actually I think the idea is great, but don't like the config files as the only options for the test suits. http://www.ncbi.nlm.nih.gov/books/NBK7200/ With Kind Regards, Ovanes

2 3

Problem building Boost on AIX 6.1, xlc 11.1
by Daniel Langr 05 Oct '11

05 Oct '11

Running ./bjam command produces the following error message: /mnt/gpfs.home/langrd/apl/boost/boost_1_40_0/tools/build/v2/build/property.jam:455: in property.translate-paths *** argument error * rule path.root ( path root ) * called with: ( ) * missing argument root /mnt/gpfs.home/langrd/apl/boost/boost_1_40_0/tools/build/v2/util/path.jam:201:see definition of rule 'root' being called /mnt/gpfs.home/langrd/apl/boost/boost_1_40_0/tools/build/v2/build/property-set.jam:386: in property-set.create-from-user-input /mnt/gpfs.home/langrd/apl/boost/boost_1_40_0/tools/build/v2/build/targets.jam:1531: in targets.main-target-usage-requirements /mnt/gpfs.home/langrd/apl/boost/boost_1_40_0/tools/build/v2/build/alias.jam:68: in alias /mnt/gpfs.home/langrd/apl/boost/boost_1_40_0/tools/build/v2/tools/python.jam:964: in configure /mnt/gpfs.home/langrd/apl/boost/boost_1_40_0/tools/build/v2/tools/python.jam:111: in python.init /mnt/gpfs.home/langrd/apl/boost/boost_1_40_0/tools/build/v2/build/toolset.jam:38: in using libs/python/build/Jamfile.v2:14: in modules.load /mnt/gpfs.home/langrd/apl/boost/boost_1_40_0/tools/build/v2/build/project.jam:313: in load-jamfile /mnt/gpfs.home/langrd/apl/boost/boost_1_40_0/tools/build/v2/build/project.jam:62: in project.load /mnt/gpfs.home/langrd/apl/boost/boost_1_40_0/tools/build/v2/build/project.jam:754: in project.use /mnt/gpfs.home/langrd/apl/boost/boost_1_40_0/tools/build/v2/build/project.jam:89: in load-used-projects /mnt/gpfs.home/langrd/apl/boost/boost_1_40_0/tools/build/v2/build/project.jam:73: in load /mnt/gpfs.home/langrd/apl/boost/boost_1_40_0/tools/build/v2/build/project.jam:168: in project.find /mnt/gpfs.home/langrd/apl/boost/boost_1_40_0/tools/build/v2/build-system.jam:553: in load /mnt/gpfs.home/langrd/apl/boost/boost_1_40_0/tools/build/v2/kernel/modules.jam:283: in import /mnt/gpfs.home/langrd/apl/boost/boost_1_40_0/tools/build/v2/kernel/bootstrap.jam:138: in boost-build /mnt/gpfs.home/langrd/apl/boost/boost_1_40_0/boost-build.jam:16: in module scope I have tried Boost versions 1.47 and 1.40 both with/without IBM patch (https://www-304.ibm.com/support/docview.wss?uid=swg27018656). System AIX 6.1, xlc 11.1, bootstrap command: ./bootstrap.sh --with-toolset=vacpp --with-libraries=program_options,system,filesystem Please help, Daniel

1 0

asio error codes
by Christopher Pisz 05 Oct '11

05 Oct '11

I am implementing tcp conections using boost asio. I don't see in the documentation anything that says which error code could result from the various asynchronous calls. Obviously, I would have to identify all connection related error codes and set the state of my process such that a reconnect was the way to handle it. In some cases a retry might be needed. However, I don't see a way to get a list of the possible error codes that need to get checked for aside from hours and hours of debugging trial and error. Does there exist somewhere a list of error codes that could result from async_read? which would I get from async_write?, async_accept? etc..etc. I see it is a sytem::error_code, and I can look at the header, I can even find a doc that lists all of them and see asio has a group, but I can't tell which might occur when.

3 4

How to change the default enums serialization in Boost.Serialization
by Andrés Senac 05 Oct '11

05 Oct '11

Hi, By default in Boost.Serialization, enum types are serialized as a 32-bit integer. But I need to serialize some enum types as different width integer. I've tried to specialize the boost::serialization::serialize method, but it seems it doesn't work for enums. Here is my attempt: #include <iostream> #include <boost/archive/binary_oarchive.hpp> #include <boost/asio.hpp> enum MyEnum_t { HELLO, BYE }; namespace boost { namespace serialization { template< class Archive > void save(Archive & ar, const MyEnum_t & t, unsigned int version) { unsigned char c = (unsigned char) t; ar & c; } template< class Archive > void load(Archive & ar, MyEnum_t & t, unsigned int version) { unsigned char c; ar & c; t = (MyEnum_t) c; } } // namespace serialization } // namespace boost BOOST_SERIALIZATION_SPLIT_FREE(MyEnum_t) int main(int argc, const char *argv[]) { boost::asio::streambuf buf; boost::archive::binary_oarchive pboa(buf); buf.consume(buf.size()); // Ignore headers MyEnum_t me = HELLO; pboa << me; std::cout << buf.size() << std::endl; // buf.size() = 4, but I want 1 return 0; } Thanks in advance, Andrés -- Andrés Senac González andres(a)senac.es, andres.senac(a)um.es +(34) 627550280

2 2

A forward iterator need not be default-constructible
by Krzysztof Żelechowski 04 Oct '11

04 Oct '11

== Problem == The following code fails to compile: #include <vector> #include <boost/iterator/transform_iterator.hpp> #include <boost/range/algorithm.hpp> #include <boost/range/adaptor/transformed.hpp> static inline void trigger (::std:: vector < int > const &p_v) { /* i: p_v [i] + 0 >= 0 */ ::boost:: lower_bound (p_v | ::boost:: adaptors:: transformed (::std:: bind1st (::std:: plus < int > (), 0)), 0); } Details: See [[#Evidence]]. == Workaround == The following definition causes the code to compile successfully, as of GNU C++ 4.6: #define BOOST_RANGE_ENABLE_CONCEPT_ASSERT 0 Disadvantages and risks: * The macro BOOST_RANGE_ENABLE_CONCEPT_ASSERT is undocumented. * It disables concept checking altogether, which may be a good thing or a bad thing, depending on your needs. The official motivation for concept checking is that it makes error messages more readable; in this particular case, I am not convinced. == Background == TL;DR: If all you can say is that such an iterator does not meet the requirements imposed by the standard, I am not interested. If you are willing not to treat the standard as the ultimate and unquestionable oracle, you may read on :-) The standard C++ library defined iterators to serve and additional task to serve as abstract pointers that may be singular, i.e. not corresponding to any object and distinct from any other iterator. To this end, the standard requires that interators may be constructed out of thin air, and that such an iterator is singular. This requirement is only useful iterators that do not correspond to containers like the standard input stream iterator which you can use to find something in it, and even then the end iterator, which is singular, is created explicitly by the calling code and not by library code. Requiring conformance to this particular requirement in Boost is counterproductive, as it causes perfectly valid and obvious code to fail to compile for no reason at all except for respecting the letter of the standard. == Conclusions == 1. The macro BOOST_RANGE_ENABLE_CONCEPT_ASSERT should be documented, as it is necessary to keep the concepts BS at bay. 2. The concept mechanism used by Boost should not require singular iterators to exist; the standard is obnoxious and misguided here and promotes sloppy coding. == Note == I believe that it is possible to design algorithms so that they do not construct singular iterators anywhere; moreover, I believe that doing so would be beneficial to the library implementation, as evidenced in GNU libstdc++ Bug #45488. (My similar report against Plauger’s library was declined by Microsoft, which means I have to use a replacement algorithm fixed by myself.) == Evidence == g++ -g doit.cpp -o doit In file included from doit.cpp:4:0: /usr/include/boost/iterator/transform_iterator.hpp: In constructor ‘boost::transform_iterator<UnaryFunction, Iterator, Reference, Value>::transform_iterator() [with UnaryFunc = std::binder1st<std::plus<int> >, Iterator = __gnu_cxx::__normal_iterator<const int*, std::vector<int> >, Reference = boost::use_default, Value = boost::use_default]’: /usr/include/boost/concept_check.hpp:130:10: instantiated from ‘boost::DefaultConstructible<TT>::~DefaultConstructible() [with TT = boost::transform_iterator<std::binder1st<std::plus<int> >, __gnu_cxx::__normal_iterator<const int*, std::vector<int> >, boost::use_default, boost::use_default>]’ /usr/include/boost/range/concepts.hpp:148:16: instantiated from ‘static void boost::concepts::requirement<boost::concepts::failed************ Model::************>::failed() [with Model = boost::range_detail::ForwardIteratorConcept< boost::transform_iterator<std::binder1st<std::plus<int> >, __gnu_cxx::__normal_iterator<const int*, std::vector<int> >, boost::use_default, boost::use_default> >]’ /usr/include/boost/range/concepts.hpp:264:1: instantiated from ‘boost::ForwardRangeConcept<const boost::range_detail::transform_range<std::binder1st<std::plus<int> >, const std::vector<int> > >’ /usr/include/boost/concept/detail/has_constraints.hpp:42:5: instantiated from ‘const bool boost::concepts::not_satisfied<boost::ForwardRangeConcept<const boost::range_detail::transform_range<std::binder1st<std::plus<int> >, const std::vector<int> > > >::value’ /usr/include/boost/concept/detail/has_constraints.hpp:45:31: instantiated from ‘boost::concepts::not_satisfied<boost::ForwardRangeConcept<const boost::range_detail::transform_range<std::binder1st<std::plus<int> >, const std::vector<int> > > >’ /usr/include/boost/mpl/if.hpp:67:11: instantiated from ‘boost::mpl::if_ <boost::concepts::not_satisfied<boost::ForwardRangeConcept<const boost::range_detail::transform_range<std::binder1st<std::plus<int> >, const std::vector<int> > > >, boost::concepts::constraint<boost::ForwardRangeConcept<const boost::range_detail::transform_range<std::binder1st<std::plus<int> >, const std::vector<int> > > >, boost::concepts::requirement<boost::concepts::failed************ boost::ForwardRangeConcept<const boost::range_detail::transform_range<std::binder1st<std::plus<int> >, const std::vector<int> > >::************> >’ /usr/include/boost/concept/detail/general.hpp:50:8: instantiated from ‘boost::concepts::requirement_<void (*)(boost::ForwardRangeConcept<const boost::range_detail::transform_range<std::binder1st<std::plus<int> >, const std::vector<int> > >)>’ /usr/include/boost/range/algorithm/lower_bound.hpp:45:1: instantiated from ‘typename boost::range_iterator<const ForwardRange>::type boost::range::lower_bound(const ForwardRange&, Value) [with ForwardRange = boost::range_detail::transform_range<std::binder1st<std::plus<int> >, const std::vector<int> >, Value = int, typename boost::range_iterator<const ForwardRange>::type = boost::transform_iterator<std::binder1st<std::plus<int> >, __gnu_cxx::__normal_iterator<const int*, std::vector<int> >, boost::use_default, boost::use_default>]’ doit.cpp:8:114: instantiated from here /usr/include/boost/iterator/transform_iterator.hpp:99:26: error: no matching function for call to ‘std::binder1st<std::plus<int> >::binder1st()’ /usr/include/boost/iterator/transform_iterator.hpp:99:26: note: candidates are: /usr/include/c++/4.6/backward/binders.h:109:7: note: std::binder1st<_Operation>::binder1st(const _Operation&, const typename _Operation::first_argument_type&) [with _Operation = std::plus<int>, typename _Operation::first_argument_type = int] /usr/include/c++/4.6/backward/binders.h:109:7: note: candidate expects 2 arguments, 0 provided /usr/include/c++/4.6/backward/binders.h:100:11: note: std::binder1st<std::plus<int> >::binder1st(const std::binder1st<std::plus<int> >&) /usr/include/c++/4.6/backward/binders.h:100:11: note: candidate expects 1 argument, 0 provided Kompilacja nie powiodła się make: *** [doit] Błąd 1

11 65

[ Interprocess ] Object allocation performance
by Yordan Pavlov 04 Oct '11

04 Oct '11

It looks like this: MyType * pMy = my_segment->construct<MyType>(anonymous_instance)(); my_segment->destroy_ptr(pMy); Where *MyType* is some typical struct and *my_segment* is correctly constructed *boost::interprocess::managed_shared_memory ** is around 10 times slower than the equivalent: MyType * pMy = new MyType(); delete pMy; I did not expect this. I though the two allocation algorithms should be similar in implementation and performance. Is there some good reason for such a huge difference. Edit: The test was conducted over a huge number of iterations.

2 1

Building Boost 4.6 with Intel C++ compiler 12.1
by Frank Kingswood 04 Oct '11

04 Oct '11

Hallo! I'm getting build errors with ICC 12.1.0 that appear to be related to BOOST_STATIC_ASSERT. This is with boost 1.46.1.1 as available in Debian. Before I got this far I had to disable rvalue references in config/compiler/intel.hpp. /usr/include/boost/type_traits/type_with_alignment.hpp(206): error: member "boost::detail::type_with_alignment_imp<Align>::found" is not a type name BOOST_STATIC_ASSERT(found >= Align); ^ /usr/include/boost/type_traits/common_type.hpp(91): error: expected a type specifier BOOST_COMMON_TYPE_STATIC_ASSERT(sizeof(T) > 0, BOOST_COMMON_TYPE_MUST_BE_A_COMPLE_TYPE, (T)); ^ Folloed by several more problems in BOOST_STATIC_ASSERT. Has anyone seen similar problems? Thanks, Frank

2 3