- Boost - lists.boost.org

ASIO certificate help.
by Mohammed Rasmy 16 Mar '09

16 Mar '09

1 0

Boost.Chrono where we are?
by vicente.botet 16 Mar '09

16 Mar '09

Hi, In November 2008, Beman said: "The Chrono library in the sandbox is now more-or-less feature complete." This library is esential to conform some boost libraries implementing standard libraries as Boost.Thread and Boost.Future as much as possible to the standard. It will be used also on the Boost.ThreasPool library and I would like also to use it on my AsynchronousExecutors library. Can we expect to have Boost.Chrono for review soon? Thanks, Vicente

1 1

request for discussion - yet another approach to automated memory management that solves the cycles problem and is very efficient
by Achilleas Margaritis 16 Mar '09

16 Mar '09

Dear boost members, The file 'mm2.zip' (in boost vault/memory) contains yet another solution for automatic memory management. The solution has the following attributes: 1) it solves the problem of cycles. 2) it releases resources deterministically. 3) it does not scan the graph of objects for reachability. It uses simple numeric values (i.e. keys) to determine if an object can be collected or not. The idea is very simple: pointers obtain keys during their construction (a simple global variable that is incremented). The key remains constant throughout the lifetime of a ptr. During pointer release, the pointers that point to an object are scanned: if there is no pointer that points to the object that has a lower key from the key of the releasing pointer, then the object can be deleted. The pointer semantics are normal C pointer semantics, except for the construction: the solution requires that pointers that are lvalues should obtain a key before the heap object that they will be assigned to. i.e. you can't do this: ptr p1 = new object; You have to do this: ptr p1; p1 = new object; All the operations have O(1) complexity, except the release operation, which has O(N) complexity, whereas N is the number of pointers that point to an object. Practically, the complexity is minimal, because it is rare to have that many different pointers to a single object (I think :-)). I have no idea if it works for all cases. The file 'main2.cpp' contains a lot of tests, which all pass. I have also included the benchmark of the Boehm GC modified to use my special ptr classes. In my machine, an Athlon 64 2.2 GHz, the benchmark is executed, using boost pools, at roughly 1900 milliseconds, whereas the Boehm gc benchmark, using the Boehm gc collector, is executed at roughly 1200 milliseconds (and the Java benchmark at roughly 600 milliseconds). The amazing thing is that it looks like it works, but I am not sure. I am sure there is a catch :-).

9 17

Re: [boost] [geometry] robustness approaches
by Simonson, Lucanus J 16 Mar '09

16 Mar '09

Barend Gehrels wrote: > You'll probably found this on the mails and not on the library > itself. It has no circles so it is a bit unfair to compare the > approaches like this. It focusses on integer arithmetic and 45/90 > angled polygons so it is different, more or less complimentary. I'm a little hurt to hear you say this. I keep repeating that I currently handle arbitrary angle polgon set boolean operations and that the implementation is 100% robust for integer coordinates but not so for floating point. There are practically no robustness issues with 90 polygons and only very little with 45 polygons, so why would I discuss it if I didn't need to concern myself with it? When I talk about robustness I'm talking about my arbitrary angle polygon clipping implementation. Allow me to demonstrate this capability more clearly. I have just exercised my arbitrary angle polygons booleans with floating point coordinates. It worked and successfully XOR-ed a hand with a spiral which is a visually appealing but trivially small test case of mine. I can't claim that it is 100% robust for floating point coordinates (yet) but I do have working code. I have attached both sets of outputs the image of the result as well. It is clearly correct. Just because I don't claim floating point robustness doesn't mean the algorithm doesn't work or can't produce correct results. I just haven't designed in and verified 100% robustness for floating point. Regards, Luke

2 3

question regarding g++ 4.3.2 and maybe others
by Robert Ramey 16 Mar '09

16 Mar '09

On my local system I'm trying to build/test with gcc 4.3.2. The library builds with nocomplaint, but when I build/run the tests I get:Info: resolving typeinfo for boost::serialization::detail::extended_type_info_typeid_0 by linking to __imp___ZTIN5boost13serialization6detail27extended_type_info_typeid_0E (auto-import/usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld: warning: auto-importing has been activated without --enable-auto-import specified on the command line. This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.) My site-config.shows gcc : 4.3.2 : g++-4 ;should it show some compile time switch besides this? Or ?Robert Ramey

2 3

[asio] experience with cygwin
by bnv＠nc.rr.com 16 Mar '09

16 Mar '09

I began porting a cygwin application to boost-1.38 asio this past weekend. So far things are working, and I'm pleased with the simplification of the application code, but a few items have come up... 1. The cygwin documentation only states that the __USE_W32_SOCKETS flag must be defined, but the documentation should also mention that the _WIN32_WINNT flag should be defined (0x0501 for XP) to avoid a warning, and that the ws2_32 and mswsock libraries are needed (at least for XP). 2. The documentation for the ip::tcp::socket object specifies that the cancel() member will "cancel all asynchronous operations associated with the socket". However, when called just before closing the socket, I get an exception along the lines of "operation not supported on this object" (I don't have the exact message in front of me right now). By not calling it, my async handlers are invoked with an error on closing the socket. 3. The application has a signal handler (e.g., SIGINT). However, when the process is inside asio::io_service::run(), the signal handler appears to somehow get suspended and I have to do a "kill -9" rather than just hitting ctrl-c. Is this intentional/expected? Is there a work around, perhaps looping on asio::io_service::run_one()? Thanks, Brian

2 1

Re: [boost] [Math] boost::math::signbit returns false for -NAN
by Hartmut Kaiser 16 Mar '09

16 Mar '09

Ping? Regards Hartmut > -----Original Message----- > From: Hartmut Kaiser [mailto:hartmut.kaiser@gmail.com] > Sent: Wednesday, March 11, 2009 8:35 AM > To: 'boost(a)lists.boost.org' > Cc: 'John Maddock' > Subject: [Math] boost::math::signbit returns false for -NAN > > Hi all, > > the boost::math::signbit function in trunk fails for an argument of - > NAN. > > #include <boost/math/special_functions/sign.hpp> > > int main() > { > using boost::math::signbit; > BOOST_ASSERT(signbit(-std::numeric_limits<double>::quiet_NaN())); > return 0; > } > > I'd expect to get a '1' back, but the function returns zero and the > assertion fails. I know it worked while using Jon Rade's floating point > utilities library from the vault. Does this have been integrated? > > Regards Hartmut >

1 0

[math] Please give me some advice.
by Kasra 15 Mar '09

15 Mar '09

Hi Dongfei, I have downloaded the code and took a good look at it. It is pretty cool. I think the best we could do is to work more on the optimisations (opt.h) to improve the performance. -- Kasra

1 0

[asio and thread] don't play well together under cygwin?
by Brian and Victoria 15 Mar '09

15 Mar '09

Greetings, I have a header file that includes both <boost/thread> and <boost/asio>, which results in the compilation errors below under cygwin. If I take out <boost/thread> then things are fine, except that I need it for my application :) I have "-D__USE_W32_SOCKETS -D_WIN32_WINNT=0x0501" in my compile flags, per the asio documentation. Taking them out appears to resolve the errors below, but causes other errors for asio. Has anyone else run into this problem and found a solution? -Brian In file included from /usr/include/cygwin/sys_time.h:13, from /usr/include/sys/time.h:27, from /usr/local/include/boost-1_38/boost/date_time/c_time.hpp:31, from /usr/local/include/boost-1_38/boost/date_time/microsec_time_clock.hpp:21, from /usr/local/include/boost-1_38/boost/thread/thread_time.hpp:9, from /usr/local/include/boost-1_38/boost/thread/locks.hpp:12, from /usr/local/include/boost-1_38/boost/thread/pthread/mutex.hpp:11, from /usr/local/include/boost-1_38/boost/thread/mutex.hpp:16, from /usr/local/include/boost-1_38/boost/thread/pthread/thread_data.hpp:12, from /usr/local/include/boost-1_38/boost/thread/thread.hpp:17, from /usr/local/include/boost-1_38/boost/thread.hpp:13, from chat.cpp:23: /usr/include/sys/select.h:31: error: `fd_set' has not been declared /usr/include/sys/select.h:31: error: `fd_set' has not been declared /usr/include/sys/select.h:31: error: `fd_set' has not been declared /usr/include/sys/select.h:33: error: `fd_set' has not been declared /usr/include/sys/select.h:33: error: `fd_set' has not been declared /usr/include/sys/select.h:33: error: `fd_set' has not been declared In file included from /usr/local/include/boost-1_38/boost/asio/detail/socket_types.hpp:79, from /usr/local/include/boost-1_38/boost/asio/detail/win_iocp_io_service_fwd.hpp:24, from /usr/local/include/boost-1_38/boost/asio/io_service.hpp:37, from /usr/local/include/boost-1_38/boost/asio/basic_io_object.hpp:20, from /usr/local/include/boost-1_38/boost/asio/basic_socket.hpp:24, from /usr/local/include/boost-1_38/boost/asio/basic_datagram_socket.hpp:25, from /usr/local/include/boost-1_38/boost/asio.hpp:20, from chat.cpp:30: /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:109: error: redefinition of `struct timeval' /usr/include/sys/time.h:16: error: previous definition of `struct timeval' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:632: error: declaration of C function `int select(int, fd_set*, fd_set*, fd_set*, const timeval*)' conflicts with /usr/include/sys/select.h:31: error: previous declaration `int select(int, int*, int*, int*, timeval*)' here

3 4

[array] remove static qualifier for size(), empty() and max_size() member function
by herve martin 15 Mar '09

15 Mar '09

Hi, I guess that the static qualifier for size(), empty() and max_size() makes the boost::array template class unsuitable for the STL sequence container interface. I recommend to remove the static qualifier. Anyone agrees with me ? best regards, herve

3 3