May 2010 - Boost-users - lists.preview.boost.org

Simple serial port demonstration with boost asio asynchronous I/O
by Jeff Gray 26 Jan '11

26 Jan '11

A couple of weeks ago I posted a simple asynchronous demonstration of a telnet client using boost asio TCP network code. I have changed this code to turn it into a simple serial terminal application using the serial port support in the new version of boost asio. It required no changes at all the the read or write code. I just altered the initialization to use a serial port instead of a socket. Note that this is not intended to show how a fully functional application would work. There are plenty of areas that are not handled in this code. But it shows the idea and it's easy to build on this once you've got it working. Hope this helps someone else get started... Jeff

3 2

[units] subtract_typeof_helper<> help!
by Terry Golubiewski 04 Jan '11

04 Jan '11

I'm trying to use boost::geometry and boost::units together. For some reason boost::geometry doesn't represent the difference of two points as vectors. So, I'm making my own Vector class and defining Vector = Point - Point. The sample program below doesn't compile because I need to tell the units library about the special properties of point subtraction (I think). terry #include <boost/geometry/geometry.hpp> #include <boost/units/systems/si.hpp> #include <boost/units/quantity.hpp> #include <boost/units/io.hpp> #include <iostream> #include <iomanip> using namespace std; using namespace boost; using namespace boost::geometry; using namespace boost::units; typedef point<double, 3, cs::cartesian> Point; class Vector { Point _impl; friend Vector operator-(const Point& lhs, const Point& rhs); explicit Vector(Point p) : _impl(p) { } public: Vector() : _impl(0) { } Vector(double dx, double dy, double dz=0) : _impl(dx, dy, dz) { } friend ostream& operator<<(ostream& os, const Vector& v) { return os << dsv(v._impl); } }; // Vector inline Vector operator-(const Point& lhs, const Point& rhs) { Point tmp(lhs); subtract_point(tmp, rhs); return Vector(tmp); } inline ostream& operator<<(ostream& os, const Point& pt) { return os << dsv(pt); } int main() { Point p1(1, 2, 3); Point p2(4, 5, 6); typedef quantity<si::length, Point> Position; typedef quantity<si::length, Vector> Displacement; Position start( p1 * si::meters); Position finish(p2 * si::meters); Displacement disp(finish - start); cout << "disp=" << disp << endl; return EXIT_SUCCESS; } // main

7 16

[Program Options] Positional args in help message
by Lindley M French 10 Nov '10

10 Nov '10

The examples for how to use positional arguments are great and seem to work fine. However, I'm wondering if there's an automatic way to include that information in the help message. In particular, since the tutorial goes to the trouble of telling you how to exclude the positional options from the options help, it would be nice to know what to replace it with. I could manually write a line detailing the usage before outputting the options description, of course, but I was wondering if there was anything in PO to handle this automatically.

3 2

[Asio]What's the behavior of socket.async_write() after socket.close() is called?
by 鑫炜廖 05 Nov '10

05 Nov '10

Hi, If I call socket.close() but I still have some data in my buffer, can I call async_write() later? When I call socket.close(), maybe an async_write operation is running, when it's complete I want to send data in another buffer(data written while previous async_write() is running, before socket.close() was called), but the socket is closed.Does it work in this situation?If not, what's the alternative way? The code looks like this: char front_buffer[kBufferSize]; char back_buffer[kBufferSize]; void HandleWrite(...) { //socket is closed. Does this work? socket.async_write(back_buffer, ...); } socket.async_write(front_buffer, HandleWrite); // write data to back_buffer socket.close();

5 10

Polymorphic serialization with polymorphic archives problems... [part 2]
by Bogdan 03 Nov '10

03 Nov '10

First I would like to confirm I tested Robert Ramey's fix (@60273) for multiple registrations and it looks good in my runs. Thank you Robert! On the other hand, I am under the impression there is a bug in void_caster::recursive_unregister(), although I am not 100% certain about the reason: that function member is called in the destructors of the void caster template classes and makes use of the void_caster_registry singleton (more specifically the type_set). I believe it searches the set for all the void caster entries that are descendants of the current one (i.e., the one being destroyed) and performs the following ops: - delete the shortcuts. - remove the corresponding entries from the set. However, void_caster::recursive_unregister() DOESN'T REMOVE FROM THE REGISTRAR the entry corresponding to the current void_caster(). This creates the problem below: consider a scenario where a dll containing some serialization functionality is loaded explicitly at runtime (i.e., using LoadLibrary() on Windows or dlopen on Unix). There are no parent-child relationships among the serialized classes registered by that DLL: all serialized classes are derived from one abstract base. While unloading the library, its void_caster singletons are destroyed but there are no shortcuts to remove from the global registrar since there are no parent-child relationships. All entries corresponding to those are still in the global registrar and POINT TO THE void_caster SINGLETONS ALREADY DESTROYED AND DISCARDED. When the main process exits, the registrar traversal repeats for whatever process-bound void_caster singletons are about to be destroyed. During these subsequent traversals, void_caster::recursive_unregister() visits the entries left after the previous explicit dll download and tries to identify the parent-child relationship. In doing so, it accesses the dangling vc pointers generating access violations: void_cast.cpp(Line 286): const void_caster * vc = *it; void_cast.cpp(Line 287): if(vc->m_parent == this){ //<--------------------- here is the access violation I can reproduce the crash systematically, but I am not sure about the reason or whether a simple unregistration is enough. I believe this is (again) a question for Robert, but I thank for any feedback I might get. Bogdan

2 1

upgrade_to_unique_lock doesn't compile with vc2010
by Braden McDaniel 16 Sep '10

16 Sep '10

Using Boost 1.43, this program: # include <boost/thread.hpp> int main() { boost::shared_mutex mutex; boost::upgrade_lock<boost::shared_mutex> lock(mutex); boost::upgrade_to_unique_lock<boost::shared_mutex> write_lock(lock); } ... produces this error when compiled with Visual C++ 2010: C:\Users\braden>cl /I include/boost-1_43 /MD /EHsc upgrade_to_unique_lock_test.cpp Microsoft (R) C/C++ Optimizing Compiler Version 16.00.30319.01 for x64 Copyright (C) Microsoft Corporation. All rights reserved. upgrade_to_unique_lock_test.cpp include/boost-1_43\boost/thread/locks.hpp(823) : error C2679: binary '=' : no operator found which takes a right-hand operand of type 'boost::unique_lock<Mutex>' (or there is no acceptable conversion) with [ Mutex=boost::shared_mutex ] include/boost-1_43\boost/thread/locks.hpp(659): could be 'boost::upgrade_lock<Mutex> &boost::upgrade_lock<Mutex>::operator =(boost::upgrade_lock<Mutex>&)' with [ Mutex=boost::shared_mutex ] include/boost-1_43\boost/thread/locks.hpp(710): or 'boost::upgrade_lock<Mutex> &boost::upgrade_lock<Mutex>::operator =(boost::detail::thread_move_t<T>)' with [ Mutex=boost::shared_mutex, T=boost::upgrade_lock<boost::shared_mutex> ] include/boost-1_43\boost/thread/locks.hpp(717): or 'boost::upgrade_lock<Mutex> &boost::upgrade_lock<Mutex>::operator =(boost::detail::thread_move_t<T>)' with [ Mutex=boost::shared_mutex, T=boost::unique_lock<boost::shared_mutex> ] while trying to match the argument list '(boost::upgrade_lock<Mutex>, boost::unique_lock<Mutex>)' with [ Mutex=boost::shared_mutex ] include/boost-1_43\boost/thread/locks.hpp(820) : while compiling class template member function 'boost::upgrade_to_unique_lock<Mutex>::~upgrade_to_unique_lock(void)' with [ Mutex=boost::shared_mutex ] upgrade_to_unique_lock_test.cpp(7) : see reference to class template instantiation 'boost::upgrade_to_unique_lock<Mutex>' being compiled with [ Mutex=boost::shared_mutex ] I've searched a bit for previous reports of this sort of thing and I haven't found any. Hopefully that means I'm just doing something wrong. -- Braden McDaniel <braden(a)endoframe.com>

7 15

Help with shared_ptr and template
by Mario Chacon 10 Sep '10

10 Sep '10

Hello: I have this problem and I do not how to fix it, I know I cannot write template typedefs, its a limitiation of the C++ syntax, right? or I'm wrong? I saw that the best way is to wrap your typedefs in a struct, which can be templated, but I'm still stack with problems. The best way to explain it's with an example: #include <cstdlib> #include <iostream> #include <boost/shared_ptr.hpp> template< typename tvalue > class CValue { public: CValue( tvalue value ) : value_(value) {}; private: tvalue value_; }; template< typename tvalue > struct Type{ typedef boost::shared_ptr< CValue< tvalue > > pValue; }; int main(int argc, char *argv[]) { Type<bool>::pValue a; return EXIT_SUCCESS; } How can I create a shared_ptr for the template class "CVALUE"?? Please I do not know what else I can prove... :( Thank you.. Mario.. Salu2...

6 8

[1.43.0] Release notice
by Beman Dawes 19 Aug '10

19 Aug '10

Release 1.43.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains two new libraries (functional/factory, functional/forward), a major range library upgrade, plus numerous enhancements and bug fixes for other libraries. For details, including download links, see http://www.boost.org/users/news/version_1_43_0 The release can also be downloaded directly from SourceForge. See http://sourceforge.net/projects/boost/files/ To install this release on your system, see http://www.boost.org/doc/libs/1_43_0/more/getting_started/index.html Thanks to all who contributed, --The Boost release team

4 5

[array] range check (at compile time)
by alfC 23 Jun '10

23 Jun '10

Hi, Lately I find myself using boost::array intesively, specially in small demo programs. Sometimes, when "manually" accessing the elements I type a index out of range. The library can detect these errors once the program is running but I found this a waste, also I was surprised not to see this kind of static check not implemented in the library. So I wanted to see if I could enforce range checking at compile time, and I come out with this solution. namespace boost{ //sorry about the namespace name template<size_t IDX, typename T, size_t N> const T& get(boost::array<T, N> const& arr){ BOOST_STATIC_ASSERT(IDX<N); return arr[IDX]; } template<size_t IDX, typename T, size_t N> T& get(boost::array<T, N>& arr){ BOOST_STATIC_ASSERT(IDX<N); return arr[IDX]; } } #include<iostream> void main(){ boost::array<double, 3> a = {1,2,3}; std::clog<<boost::get<2>(a)<<std::endl; // ok, (namespace specification needed, why?) std::clog<<boost::get<5>(a)<<std::endl; //does not compile return 0; } (I though about using enable_if instead of BOOST_STATIC_ASSERT but that would be too much overengineering.) Is this implemented already in some other way? Alfredo

6 8

BOOST_FOREACH infinite loop issue
by yabcok 11 Jun '10

11 Jun '10

Hi, I have a problem with BOOST_FOREACH never ending under specific conditions described here: http://stackoverflow.com/questions/2881491/need-help-with-boost-foreach-com… Could anyone help me understand what's going on? Best regards, Jacek Ławrynowicz

3 6