- Boost-users - lists.boost.org

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

Extend boost::adjacency_list
by Jupp Tscheak 03 Oct '11

03 Oct '11

Dear users of boost graph library, I would like to extend boost::adjacency_list like this code: class MyGraph: public boost::adjacency_list<boost::multisetS, boost::vecS, boost::bidirectionalS, boost::property<boost::some_vertex_property, SomeVertexProperty*>, boost::property<boost::some_edge_property, SomeEdgeProperty*> {} This works as expected. Is it possible to extend class "MyGraph" with additional vertex and/or edge properties defined? My first approach was like this code: template <class AdditionalVertexProperty = boost::no_property, class AdditionalEdgeProperty = boost::no_property> class MyGraph: public boost::adjacency_list<boost::multisetS, boost::vecS, boost::bidirectionalS, boost::property<boost::some_vertex_property, SomeVertexProperty*, AdditionalVertexProperty>, boost::property<boost::some_edge_property, SomeEdgeProperty*, AdditionalEdgeProperty> {} class ExtendedMyGraph: public MyGraph<boost::property<boost::some_add_vertex_property, SomeAddVertexProperty*> > {} This, however, led into multiple compiler errors. Does anyone know how to achieve the wanted behavior? Thanks in advance Jupp

2 1

[graph] compile breadth_first_search error.
by gongyiling 03 Oct '11

03 Oct '11

i 'm a newbie to boost graph library, I'm trying to compile a sample code as following: struct demo_visitor : public boost::default_bfs_visitor { template <typename Vertex, typename Graph> void discover_vertex(Vertex v, Graph& g) { //std::cout<<g[v].url<<std::endl; } }; int main(int argc, char* argv[]) { typedef boost::adjacency_list<boost::vecS, boost::listS, //change this to boost::vecS compile ok. boost::directedS> graph_t; typedef boost::graph_traits<graph_t>::vertex_descriptor vertex_descriptor_t; graph_t g; demo_visitor vis; boost::breadth_first_search(g, boost::vertex(0, g), boost::visitor(vis)); return 0; } And it fail to compile will the error in two_bit_color_map.hpp: can't transfer boost::detail::error_property_not_found to size_t. When I change the second type argument(VertexListS) of boost::adjacency_list from boost::listS to boost::vecS, it compile ok. Is there any implicite constraints on breadth_first_search? I also checked that boost::adjacency_list match the VertexListGraph concept both, using boost::vecS and boost::listS as it VertexListS type argument. Any response is appreacited!

3 3

[String Algo] funny warning
by Leo Cacciari 02 Oct '11

02 Oct '11

Hi, I usualy add flag -Wall to gnu g++ compilation while developing. Now, I got a funny warning while compiling the following function (I use the 1.42.0 release of boost) std::vector<std::string> split_payload(const std::string & payload_string) { std::vector<std::string> components; boost::algorithm::split(components,payload_string, boost::algorithm::is_any_of(",")); return components; } The warning I get is /usr/include/c++/4.4/bits/stl_algo.h: In function ‘std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > split_payload(const std::string&)’: /usr/include/c++/4.4/bits/stl_algo.h:2178: warning: array subscript is above array bounds Someone could explain this? By the way, the function does what is supposed to do, so its not a big problem, but I'd really like to understand what the problem is... -- Leo Cacciari Aliae nationes servitutem pati possunt populi romani est propria libertas

1 0

Callback that calls a callback using boost::bind
by Christopher Pisz 02 Oct '11

02 Oct '11

I want to make a callback that also calls back. I cannot get the code to compile. I read on the boost documentation about apply()., but the example is unclear and I am not sure if that is what I am looking for. /// Smart Pointer typedef boost::shared_ptr<TcpServerSideConnection> SmartPtr; /// Callback function pointer type for TcpListener notification that our execution of /// TcpServerSideConnection::OnConnectionAccepted has completed typedef boost::function<void(TcpServerSideConnection::SmartPtr newConnection, const boost::system::error_code & error)> ConnectionAcceptedListenerCallback; /// Callback function pointer type for TcpServerSideConnection notification of /// a TcpListener::Listen IO completion typedef boost::function<void(ConnectionAcceptedListenerCallback listenerCallback, const boost::system::error_code & error)> ConnectionAcceptedCallback; TcpListener::SmartPtr me = boost::dynamic_pointer_cast<TcpListener, TcpBaseSocket>(shared_from_this()); TcpServerSideConnection::ConnectionAcceptedListenerCallback listenerCallback = boost::bind(&TcpListener::OnConnectionAccepted, me, _1, _2); TcpServerSideConnection::ConnectionAcceptedCallback acceptCompleteCallback = boost::bind(&TcpServerSideConnection::OnConnectionAccepted, newConnection, listenerCallback, boost::asio::placeholders::error); acceptor_.async_accept(newConnection->GetSocket(), acceptCompleteCallback); Gives me a compile error in bind.hpp with 100s of pages. What am I doing wrong here? Does anyone have an example of a callback that callsback using boost::bind?

2 1

shared_from_this - derived classes (yes, I googled)
by Christopher Pisz 02 Oct '11

02 Oct '11

Please examine the following: //----------------------------------------------------------------------------- void TcpListener::Listen() { TcpServerSideConnection::SmartPtr newConnection = TcpServerSideConnection::Create(ioService_); TcpBaseSocket::SmartPtr ptr = shared_from_this(); TcpListener::SmartPtr me = boost::dynamic_pointer_cast<TcpListener, TcpBaseSocket>(ptr); /// Asynchronously accept one connection request when it occurs acceptor_.async_accept(newConnection->GetSocket(), boost::bind(&TcpListener::OnConnectionAccepted, me, newConnection, boost::asio::placeholders::error)); } It throws an exception, unwinds my stack and destroys my object on the assignment of shared_from_this. I forced at least one shared pointer to be created, by making factory methods from base on up the class hierarchy. I read on google that you can only use shared_from_this on ONE class type in a class hierarchy. I did not understand the details of why. following a peer's advice, I enabled_shared_from_this on the base class and attempted to cast it in the derived class methods, getting the result that I did. I am trying to use a smart pointer here, following the example code for boost::asio::ip::tcp, assuming that I want to ensure the instance of 'ths' is alive between the time of the async call and the time it completes! I do not see a way to do this when using a class hierarchy. My base classes do similar async calls and try to handle it similarlly, so I cannot enable_shared_from_this only on the most derived. As there is no guarentee that only the most derived will be instantiated. I have more than 3 classes in the inheritance hierarchy, any of which could be instantiated. TcpBase - holds the socket and a smart pointer to the io_service TcpConnection - Adds Write and Read methods TcpClientConnection - Adds Connect method TcpServerConnection - Does not have connect, but can only be instantiated by a TcpListener - Accepts connections and creates TcpServerConnections Any of these, except the very base can be instantiated. How do I work around this problem?

2 5