- Boost-users - lists.boost.org

TCP boost server, but non-boost client
by G, Benjamin (NSN - IN/Bangalore) 14 Oct '09

14 Oct '09

Hi, I have a server which provides configuration to different clients. This server uses boost's serialization to serialize the C++ configuration objects. Some of my clients don't want to use boost for the (de-)serialization work. Will this cause any issues? Can any client deserialize the data serialized by a boost-using entity? What are the things that I need to take care of? I did read somewhere that boost serialization should be portable (I wonder if it means the same). All help appreciated. Regards, - Ben

2 1

[asio] How to know if the io_service is runing
by Daniele Barzotti 14 Oct '09

14 Oct '09

In my library I have this code (yet used in another project) where pwork is assigned to a shared_ptr: -------------------------------------------------------------- typedef boost::shared_ptr<boost::asio::io_service::work> io_work_ptr; // Main io_service static boost::asio::io_service io_service; static boost::scoped_ptr<boost::thread> io_service_thread; static boost::asio::io_service::work* p_work; static bool thread_started; bool CreateMainThread() { if (!thread_started) { try { // create the work object on the heap p_work = new boost::asio::io_service::work(io_service); // run the IO service as a separate thread: io_service_thread.reset ( new boost::thread ( boost::bind ( &boost::asio::io_service::run, &io_service ) ) ); thread_started = !thread_started; return true; } catch (boost::thread_resource_error e) { // Failed to create the new thread return false; } } } -------------------------------------------------------------- WaveStream::WaveStream() : rx_timer_(io_service) { }; WaveStream::Test() { //Start a new timer or renew it rx_timer_.expires_from_now( boost::posix_time::milliseconds(500) ); // We managed to cancel the timer. Start new asynchronous wait. rx_timer_.async_wait( boost::bind(&WaveStream::handle_timeout, this, _1) ); } void WaveStream::handle_timeout(const boost::system::error_code& error) { .... } -------------------------------------------------------------- The timer callback is never called. Is there a way to know if the io_service is runing? Daniele.

2 2

[statechart] forward_event()
by Commander Pirx 14 Oct '09

14 Oct '09

Hi, I have a state [A] with three orthogonal substates [X,Y,Z]. The states [A] and [X] provide custom reactions for an event [E]. If processing event [E] the state machine calls first the custom reaction in [A]. This method returns with forward_event() ; After this the custom reaction in [A] is called again. And then custom reaction in [X] is called. This is a little cumbersome. Why is the custom reaction in [A] called twice? And why is the outermost state called first? It would be something easier to work vice versa. First the more "specialized" inner states could do there work and then the "generalized" outer states can do the everything else. Pirx!

3 14

problem with enable_if_c and gcc4
by Lewis Hyatt 14 Oct '09

14 Oct '09

Hello Everyone- The following code compiles fine with g++ 4.1.2 but does not compile with 4.4.1, I get an error message saying the prototype does not match any declared in the class. This happens both with Boost 1.40.0 and 1.33.1, on Debian (x86 64-bit). Does anyone know what's up with this, is there some workaround? Thanks very much. #include <boost/utility/enable_if.hpp> #include <boost/type_traits/is_base_of.hpp> #include <boost/type_traits/is_same.hpp> template<typename T> struct A { struct B {}; template<typename U> typename boost::enable_if_c< boost::is_base_of<B, U>::value && !boost::is_same<B,U>::value> ::type f(U&); }; template<typename T> template<typename U> typename boost::enable_if_c< boost::is_base_of<typename A<T>::B, U>::value && !boost::is_same<typename A<T>::B, U>::value> ::type A<T>::f(U&) {} int main() { } t.cpp:20: error: prototype for 'typename boost::enable_if_c<(boost::is_base_of::value && (! boost::is_same::value)), void>::type A<T>::f(U&)' does not match any in class 'A<T>' t.cpp:12: error: candidate is: template<class T> template<class U> typename boost::enable_if_c<(boost::is_base_of::value && (! boost::is_same::value)), void>::type A::f(U&) -Lewis

1 1

[boost][filesystem] re-assign a recursive_directory_iterator
by Sascha Ochsenknecht 14 Oct '09

14 Oct '09

Hi, should it be possible to re-assign a filesystem::recursive_directory_iterator? I tried something like the following (could strip out my code and build a small test case if needed but this would take some time): fs::path aPath = ...; // assign to some valid path const fs::recursive_directory_iterator initial(path); const fs::recursive_directory_iterator end(); fs::recursive_directory_iterator current(path); // now increment current and do something with it (traverse directories etc). // ... // Later I want to go back to initial position with: current = initial; // but this causes a crash later when traversing again, seems that the (current == end) check gives wrong results and I dereference invalid current // I tried also the following: current = fs::recursive_directory_iterator(path); // this doesn't crash but (current == end) seems to give also wrong results I don't want to create 'current' as a temporary, so constructing a new 'current' when needed. In my case it is a class member. Anyhow, I can implement a workaround for me. Is it a bug or is it not wanted to re-assign the iterator? If it is not wanted to re-assign, maybe the assignment operator should be disabled? Thanks in advance, Sascha

2 1

[log] Status & getting started?
by Allen Cronce 13 Oct '09

13 Oct '09

Hi all, Currently we're using the John Torjo boost log implementation. Nothing seems to be happening with that library, so I'm exploring moving to a different logging solution. The Andrey Semashev log candidate seems to have some steam behind it. It got reviewed in February, an "RC3" version was deposited in the vault in August, and it looks like there's recent activity in its svn repository. But it's hard to get a clear picture as to its status. Can someone (Andrey?) give me some idea as to where this library is in the acceptance process? Assuming that this library is moving forward, what's the best way to get started with it? One advantage of the Torjo library was that it was header only. Looks like the Semashev version requires building. I have some reluctant experience with building boost as a whole (because I seem to end up doing it once a year or so). But I have no experience with building individual pieces like this. We're still using boost 1.36. I can see a post from Boris Schaeling indicating that the log library from February seems to work with this version. That's good news. But we're moving to 1.40 shortly. Does it make sense to take the 1.40 sources, graft in the log candidate sources in the expected places, then turn a build of the whole shebang? If not, can someone provide pointers regarding building individual libraries? Thanks in advance for information regarding the logging library's status, and any suggestions getting started with it. Best, -- Allen Cronce

1 0

New library for RPC-calls using only boost and C++0x
by Siegfried Kettlitz 13 Oct '09

13 Oct '09

Hello boost users and developers, i'm currently writing a library for making remote procedure calls to C++ objects. The library is based on the variadic templates extension coming with C++0x (already present in GCC 4.3) in conjunction with the boost library (threads, serialization, asio). The aim is to have a library, that is easy to integrate and doesn't require additional tools. Writing it, so far, has thaught me a lot about C++, templates, variadic templates, threading, networking etc.. I post this message, because i think that this library is quite handy in situations, where a developer already uses boost libraries and wants to add some networking functionality to his/her project and the usage of variadic templates instead of additional tools is quite new. One example would be remote monitoring an application by adding a "std::string get_status()"-function to some object. Implemented as example is a chat-system with a server and clients interacting by remote calls. This example is tested with a x64-linux and win32 using the portable boost-text-serialization. Multiple clients can connect to the server via the TCP/IP-acceptor (and disconnect without crashing the system). Implemented is a console-client for text input and display and a morse client, that interacts via a digital output device (relais card), which is connected via a serial port. The serial port and the digital output driver are both also connected via the rpc-system and can be physically located on separate computers. At this point, i have the basic bits together and a working rpc-library, that needs to be cleaned, refined and extended to match the practical needs. This means, that some programs and libraries have to be written, which use the rpc-library and show its bugs and limitations. The downside of it is, that the interface of the rpc-library may change one more time until it can be considered stable. Therefore it would not be good to test it widely in libraries posing similar requirements, but to test it with a variety of possible applications and provide the implementations as examples and (regression-/unit-)tests. - One library for Measurement/Automation is already in development. - The chat-server/client exists. - A transaction based game server is under consideration. - Some distributed parallel computing application with dynamic joining/leaving of clients. Can you give me some more ideas of different applications, which are easy to implement but yet useful? What would you like to have implemented and accessible by an rpc-library? One speed measurement using local (shared memory) channels resulted in 20000 calls/s and 60000 messages/s on a 1.8GHz Opteron. Do you know how this compares to other implementations on similar hardware? The TCP/IP-channel implementation using ASIO resulted in only about 100 synchronous calls/second regardless of the payload and almost no CPU load, which suggests that ASIO somewhere "sleeps" on linux systems for a few milliseconds. This would be fixed in some future implementation. Using asynchronous calls (1000 open calls) again leads to about 10000 calls/s. I'll have a closer look on what can be merged with "channels" from the boost vault[1], but from the first look it seems that "channels" targets a much more general approach. After the first tries, i realized, that my implemention has to be very specific (e.g. templates only where necessary). So, the design approaches might be too different. After the refinement, cleanup, some testing and documenting, i'd like to publish the rpc-library (and libraries based on it) under GPL- or boost-license. Then you'll hear from me again. In future i'll probably work 2-8 hours per week on the library and use it in some projects, but there's plenty of work left to do in various regions. This will leave space for other developers who might want to use and modify it to fit their needs. Some of the harder parts that would need implementation are redundant parallel connections and advanced routing, authentication of nodes, signing of messages, encryption of payload, access restriction to objects. Please let me know if * you are interested in this library in some way * have comments * know very similar libraries or * are interested in serialization using variadic function templates. Regards, Siegfried Kettlitz --- A short introduction on the library: * "nodes" are the central parts. They contain a factory for objects, store objects and forward "messages" to objects or other nodes in the network and contain a "scheduler" for executing function calls. The nodes are connected by "channels", which forward messages between the two connected nodes. Currently there is a TCP/IPv4 implementation using ASIO and direct forwarding. * Nodes connected by channels form a network, create and monitor virtual connections between each other. The network map is used to route messages between connected nodes. * An object has to supply a template for a class name (only if it can be constructed by the factory) and a template for registering the callable functions (also for abstract base classes which can't be constructed). * A function call is executed asynchronously (wrapper for synchronous call exists). The call to node.call(...) returns a "link_caller"-object. The function to be executed itself can optionally have "link_callee" as the first argument (which is invisible for the caller). The "link_caller"/"link_callee" is used for synchronization (wait for call to begin/finish execution), message forwarding (push/pop strings at caller/callee) and transfer/extraction of the return value. * Objects of class hierarchies with abstract base classes are possible and handled transparently. * Objects can be constructed by the factory of a node or an existing (externally constructed) object can be registered by the node. * Objects don't necessarily need to know (be modified, inherit something etc.) that they are part of the RPC-system and some of their functions are called remotely. * Objects can be aware that they are constructed by the factory and can, on construction be informed about their identity and get a reference to the node to make remote calls themselves. * An object is identified by a "reference" consisting of the "node_id" and the "object_id". * Parameters are passed (serialized, deserialized) by value. All function parameters must have the possibility to be serialized. Modifying referenced parameters won't affect the parameter at the caller. Pointers obviously won't work between nodes not sharing the same memory-address-space. * Called functions can use "link_callee" to make remote calls themselves, regardless of the object. * Priorities are assigned to calls and affect message forwarding and scheduling. * Calls to objects can be transformed into a boost::function using node.bind(...). * If a called function throws, the exception is forwarded as rpc::exception or a more specialized exception class. The exception is thrown at the caller, when waiting for interaction with the callee (e.g. wait for return value). * Template functions as targets are possible when specifying the template parameters of the function pointer when registering the function. * There is no need to use macros at all, although macros could be used to simplify some things. ---------- // Example for creating and calling an object. // Create a service. boost::asio::io_service node_io_service; // Create a node. rpc::node node_s(node_io_service, config); // Register the builder in order to build the server object later. node_s.register_builder<devicelib::chat_server_impl>(); // Register the interface of the client to be able to make calls to it. node_s.register_interface<devicelib::chat_client>(); // Create the server object. rpc::reference cs( node_s.get_id(), node_s.allocate_object_template<devicelib::chat_server_impl>() ); // Store the server in name server. // rpc::reference( node_s.get_id(), rpc::oid_simple_object_name_server ) -> A reference to the object_name_server. // rpc::sched_default() -> Default scheduling parameters. // &rpc::simple_object_name_server::store, cs -> function to call. // cs, "chat_server_object" -> function parameters. node_s.wrap_call( rpc::reference( node_s.get_id(), rpc::oid_simple_object_name_server ), rpc::sched_default(), &rpc::simple_object_name_server::store, cs, "chat_server_object" ); ---------- // Example for abstract base class. namespace devicelib { class chat_server : public chat_types { public: virtual void receive( std::string xml_message ) = 0; virtual user_id_t connect_user( rpc::reference a_client, std::string xml_user_info ) = 0; virtual std::string query_user( user_id_t id ) = 0; virtual void disconnect_user( user_id_t user ) = 0; virtual void join_room( user_id_t user, room_id_t room ) = 0; virtual std::list<user_id_t> list_users( ) = 0; virtual std::list<room_id_t> list_rooms( ) = 0; }; } --------------- // Example for registering the interface of the server object. // The template is declared in namespace rpc, therefore we need to define it there. namespace rpc { // For the base object. template<> void register_proxy_functions<devicelib::chat_server>( function_call_proxy<devicelib::chat_server>& ar_proxy ) { // Register the functions of the abstract base object using unique strings. ar_proxy.register_interface( &devicelib::chat_server::connect_user, "&chat_server::connect_user" ); ar_proxy.register_interface( &devicelib::chat_server::query_user, "&chat_server::query_user" ); ar_proxy.register_interface( &devicelib::chat_server::disconnect_user, "&chat_server::disconnect_user" ); ar_proxy.register_interface( &devicelib::chat_server::join_room, "&chat_server::join_room" ); ar_proxy.register_interface( &devicelib::chat_server::list_users, "&chat_server::list_users" ); ar_proxy.register_interface( &devicelib::chat_server::list_rooms, "&chat_server::list_rooms" ); } // For each implementation. template<> void register_proxy_functions<devicelib::chat_server_impl>( function_call_proxy<devicelib::chat_server_impl>& ar_proxy ) { // Register the functions of the base object. register_proxy_functions<devicelib::chat_server>( (function_call_proxy<devicelib::chat_server>&) ar_proxy ); // Make the functions of this object available. ar_proxy.register_interface( &devicelib::chat_server_impl::connect_user, &devicelib::chat_server::connect_user ); ar_proxy.register_interface( &devicelib::chat_server_impl::disconnect_user, &devicelib::chat_server::disconnect_user ); ar_proxy.register_interface( &devicelib::chat_server_impl::join_room, &devicelib::chat_server::join_room ); ar_proxy.register_interface( &devicelib::chat_server_impl::list_users, &devicelib::chat_server::list_users ); ar_proxy.register_interface( &devicelib::chat_server_impl::list_rooms, &devicelib::chat_server::list_rooms ); } // The implementation can be built, the base object not. template<> std::string class_builder_name<devicelib::chat_server_impl>() { // Give it an unique name here. return "chat_server_impl"; } } ----------------- 1: http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Distr…

8 12

[iterators] advance and distance with custom random-access iterators
by Sebastian Weber 13 Oct '09

13 Oct '09

Hi! Is there any progress in the bug #2539 ?? It seems that the patch published there which is against a rather antiquated boost version is the only solution to the problem of iterator_adaptor/facade constructs which are random_access-tagged in order to make use of true random access operations in distance/advance operations. This is critical in performance relevant code... So is there any progress in incorporating some fixes in the public trunk? I understand that the problem is a misconception of the stl there, but an official solution would be great here... Sebastian

1 0

[BGL] saving all-pair shortest paths
by Shyamendra Solanki 13 Oct '09

13 Oct '09

Hi, I understand that both the floyd-warshall and johnson algorithms populate the DistanceMatrix for shortest distances between any pair of vertices. Could you give some hint how to get the actual shortest paths? Thanks, Shyam

2 5

Multi Index with BOOST_AUTO question.
by Surya Kiran Gullapalli 13 Oct '09

13 Oct '09

Hello all,I'm a newbie to multi-index. I ran into a strange problem with VS2008. When using BOOST_AUTO with multi-index I'm getting compilation errors (C2248) . Please see the following code. *<snip>* * * #include <iostream> #include <string> using namespace std ; #include <boost/multi_index_container.hpp> #include <boost/multi_index/mem_fun.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/identity.hpp> #include <boost/multi_index/member.hpp> #include <boost/foreach.hpp> #include <boost/typeof/typeof.hpp> using namespace boost ; using namespace boost::multi_index ; class Test { friend bool operator< (const Test& p_lhs, const Test& p_rhs) { return p_lhs._i < p_rhs._i ; } friend ostream& operator << (ostream& os, const Test& p_test) { os << "Integer: " << p_test._i << "\tString: " << p_test._s ; return os ; } private: int _i ; string _s ; public: Test (int i, string s): _i(i), _s(s) { } string getString (void) const { return _s ; } } ; struct byNumber { } ; struct byString { } ; int main (void) { typedef multi_index_container <Test, indexed_by < ordered_unique<tag<byNumber>, identity <Test> > , ordered_non_unique < tag<byString>, BOOST_MULTI_INDEX_CONST_MEM_FUN(Test, string, getString) > > > Container ; typedef Container::index<byNumber>::type TestByNumber ; typedef Container::index<byString>::type TestByString ; Container c ; c.insert (Test(5, "Surya")) ; c.insert (Test(15, "Kiran")) ; //TestByNumber& tests = c.get<byNumber>() ; BOOST_AUTO(tests, c.get<byNumber>()) ; BOOST_FOREACH (Test t, tests) cout << t << endl ; return 0 ; } *</snip>* * * Compilation for this case fails with C2248. If I replace the BOOST_AUTO with the previous line's statement, compilation goes well. This happens with VS2008 only. with VS2005, there's no issue with BOOST_AUTO. Am I missing something here? Thanks, Surya

2 6