November 2006 - Boost - lists.preview.boost.org

Boost regression notification (2006-11-16 [RC_1_34_0])
by Douglas Gregor 16 Nov '06

16 Nov '06

Boost Regression test failures Report time: 2006-11-16T12:36:22Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 203 failures in 22 libraries date_time (2) filesystem (1) graph (2) io (1) iostreams (10) iterator (3) lambda (1) math (24) mpl (3) numeric/interval (2) optional (1) parameter (1) python (119) random (1) regex (4) serialization (9) signals (4) spirit (3) statechart (4) test (6) thread (1) utility (1) |date_time| testduration: borland-5.8.2 testgenerators_dll: gcc-4.1.0_linux |filesystem| fstream_test: msvc-6.5 |graph| adj_list_cc: qcc-3.3.5_gpp bfs: intel-linux-9.0 |io| ios_state_test: borland-5.8.2 |iostreams| bzip2_test: msvc-7.1 msvc-8.0 file_descriptor_test: cw-9.4 finite_state_filter_test: cw-9.4 gzip_test: msvc-7.1 msvc-8.0 mapped_file_test: cw-9.4 newline_test: borland-5.8.2 zlib_test: msvc-7.1 msvc-8.0 |iterator| filter_iterator_test: borland-5.8.2 lvalue_concept_fail: borland-5.8.2 msvc-7.1 |lambda| bind_tests_simple: intel-linux-9.0 |math| common_factor_test: borland-5.8.2 cw-9.4 darwin-4.0.1 gcc-3.2.3_linux gcc-3.3.6 gcc-3.3.6_linux gcc-3.4.4 gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc hp_cxx-71_006_tru64 intel-linux-9.0 intel-vc71-win-9.1 intel-vc8-win-9.1 msvc-6.5 msvc-7.0 msvc-7.1 msvc-7.1 msvc-8.0 msvc-8.0 sun-5.8 |mpl| int: borland-5.8.2 integral_c: borland-5.8.2 size_t: borland-5.8.2 |numeric/interval| mul: borland-5.8.2 test_float: borland-5.8.2 |optional| optional_test: borland-5.8.2 |parameter| python_test: msvc-8.0 |python| andreas_beyer: msvc-7.0 msvc-8.0 args: msvc-7.0 msvc-8.0 auto_ptr: msvc-7.0 msvc-8.0 back_reference: msvc-7.0 msvc-8.0 ben_scott1: msvc-7.0 msvc-8.0 bienstman1: msvc-7.0 msvc-8.0 bienstman2: msvc-7.0 msvc-8.0 bienstman3: msvc-7.0 msvc-8.0 builtin_converters: msvc-7.0 msvc-8.0 callbacks: msvc-7.0 msvc-8.0 const_argument: msvc-7.0 msvc-8.0 crossmod_exception: msvc-7.0 msvc-8.0 crossmod_opaque: msvc-7.0 msvc-8.0 data_members: msvc-7.0 msvc-8.0 defaults: msvc-7.0 msvc-8.0 dict: msvc-7.0 msvc-8.0 docstring: msvc-7.0 msvc-8.0 enum: msvc-7.0 msvc-8.0 exception_translator: msvc-7.0 msvc-8.0 extract: msvc-7.0 msvc-8.0 implicit: msvc-7.0 msvc-8.0 injected: msvc-7.0 msvc-8.0 iterator: msvc-7.0 msvc-8.0 keywords: msvc-7.0 msvc-8.0 list: msvc-7.0 msvc-8.0 long: msvc-7.0 msvc-8.0 map_indexing_suite: msvc-7.0 msvc-8.0 minimal: msvc-7.0 msvc-8.0 multi_arg_constructor: msvc-7.0 msvc-8.0 nested: msvc-7.0 msvc-8.0 numpy: msvc-7.0 msvc-8.0 object: msvc-7.0 msvc-8.0 opaque: msvc-7.0 msvc-8.0 operators: msvc-7.0 msvc-8.0 pearu1: msvc-7.0 msvc-8.0 pickle1: msvc-7.0 msvc-8.0 pickle2: msvc-7.0 msvc-8.0 pickle3: msvc-7.0 msvc-8.0 pickle4: msvc-7.0 msvc-8.0 pointer_vector: msvc-7.0 msvc-8.0 polymorphism: msvc-7.0 msvc-8.0 polymorphism2: msvc-7.0 msvc-8.0 polymorphism2_auto_ptr: darwin-4.0.1 intel-vc8-win-9.1 msvc-6.5 msvc-7.0 msvc-8.0 properties: msvc-7.0 msvc-8.0 raw_ctor: msvc-7.0 msvc-8.0 return_arg: msvc-7.0 msvc-8.0 shared_ptr: msvc-7.0 msvc-8.0 slice: msvc-7.0 msvc-8.0 staticmethod: msvc-7.0 msvc-8.0 stl_iterator: msvc-7.0 msvc-8.0 str: msvc-7.0 msvc-8.0 test_pointer_adoption: msvc-7.0 msvc-8.0 try: msvc-7.0 msvc-8.0 tuple: msvc-7.0 msvc-8.0 vector_indexing_suite: msvc-7.0 msvc-8.0 virtual_functions: msvc-7.0 msvc-8.0 voidptr: msvc-7.0 msvc-8.0 wrapper_held_type: msvc-7.0 msvc-8.0 |random| random_test: intel-linux-9.0 |regex| regex_regress: borland-5.8.2 regex_regress_dll: borland-5.8.2 regex_regress_threaded: borland-5.8.2 test_grep: msvc-6.5 |serialization| test_derived_class_binary_archive_dll: msvc-8.0 test_null_ptr_text_warchive_dll: msvc-8.0 test_reset_object_address: msvc-7.0 test_reset_object_address_dll: msvc-7.0 test_utf8_codecvt: borland-5.8.2 test_variant_xml_archive: borland-5.8.2 test_variant_xml_archive_dll: borland-5.8.2 test_variant_xml_warchive: borland-5.8.2 test_variant_xml_warchive_dll: borland-5.8.2 |signals| deletion_test: msvc-6.5 ordering_test: msvc-6.5 signal_n_test: msvc-6.5 trackable_test: msvc-6.5 |spirit| switch_tests_single_debug: intel-linux-9.0 symbols_add_null: msvc-7.1 symbols_add_null_debug: msvc-7.1 |statechart| TransitionTestBoth: qcc-3.3.5_gpp qcc-3.3.5_gpp TransitionTestRelaxed: qcc-3.3.5_gpp qcc-3.3.5_gpp |test| boost_check_equal_str: borland-5.8.2 msvc-7.1 test_case_template_test: borland-5.8.2 test_fp_comparisons: cw-9.4 test_tools_test: borland-5.8.2 msvc-7.1 |thread| test_tss_lib: borland-5.8.2 |utility| operators_test: gcc-3.4.5_linux_x86_64

1 0

Re: [boost] I think using spinlocks to simulate an atomicshared_ptr...
by Talbot, George 16 Nov '06

16 Nov '06

Thanks for looking at that. I was also thinking--does enable_shared_from_this need to have an "enable_atomic_from_this" version? That would also imply an atomic_weak type. -- George T. Talbot <gtalbot(a)locuspharma.com> > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Peter Dimov > Sent: Wednesday, November 15, 2006 11:42 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] I think using spinlocks to simulate an > atomicshared_ptr... > > Sorry for the brief response, no time... > > Talbot, George wrote: > > > 2) Without any sort of 2-pointer-wide atomic assignment in hardware, > > operator= really looks like this: > > > > lock the source pointer > > make a local copy of it > > release the source pointer > > > > lock the destination > > set the value of the destination from the copy > > unlock the destination > > > > This won't deadlock, but has to make an extra copy of the pointer > > locally. > > There's no extra copy. shared_ptr::operator= does: > > shared_ptr( r ).swap( *this ); > > and the above does: > > lock source > shared_ptr tmp( src ); > unlock > > lock dest > dest.swap( tmp ); > unlock > > so the two are equivalent (modulo spinlock order). > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Asio multithreaded server
by berserker_r 16 Nov '06

16 Nov '06

Christopher Kohlhoff wrote: > Anyway, I have just committed a fix to CVS head for this. If you > want to patch your own copy with a temporary fix, make the > following change to asio/detail/win_iocp_io_service.hpp: > // Constructor. > win_iocp_io_service(asio::io_service& io_service) > : asio::io_service::service(io_service), > - iocp_(::CreateIoCompletionPort(INVALID_HANDLE_VALUE, 0, 0, 0)), > + iocp_(::CreateIoCompletionPort(INVALID_HANDLE_VALUE, 0, 0, ~0)), > outstanding_work_(0), > interrupted_(0), > shutdown_(0) I have tried the patch but with no success...do I need any change to server.cpp file in order to make it works? Do I need a per session io_service? Thanks again

1 0

Re: [boost] Asio multithreaded server
by Christopher Kohlhoff 16 Nov '06

16 Nov '06

berserker_r <berserker_r(a)hotmail.com> wrote: > Christopher Kohlhoff wrote: > > What OS are you using? Is the session's work CPU bound? > > I'm on Windows XP, Great, that confirmed what I suspected was the cause of the problem. > sry but I can't understand what you mean with the second > question... "CPU bound" means that the thing that the code doesn't perform any blocking I/O or other operation that might cause the thread to sleep for a time. Anyway, I have just committed a fix to CVS head for this. If you want to patch your own copy with a temporary fix, make the following change to asio/detail/win_iocp_io_service.hpp: // Constructor. win_iocp_io_service(asio::io_service& io_service) : asio::io_service::service(io_service), - iocp_(::CreateIoCompletionPort(INVALID_HANDLE_VALUE, 0, 0, 0)), + iocp_(::CreateIoCompletionPort(INVALID_HANDLE_VALUE, 0, 0, ~0)), outstanding_work_(0), interrupted_(0), shutdown_(0) Cheers, Chris

2 1

Re: [boost] [system] Was: Re: [asio] Breaking changescommittedtocvs HEAD
by Christopher Kohlhoff 16 Nov '06

16 Nov '06

Hi Johan, Johan Nilsson <r.johan.nilsson(a)gmail.com> wrote: > I'd be happy enough if such wrappers would be documented and > existed in <boost/system/convenience.hpp> or similar. Here's the sort of convenience wrapper that I would be happy to see (just a 4-argument Windows version that I hacked up): template < typename R, typename A1, typename A2, typename A3, typename A4> R system_call(R (__stdcall *f)(A1, A2, A3, A4), typename boost::mpl::identity<A1>::type a1, typename boost::mpl::identity<A2>::type a2, typename boost::mpl::identity<A3>::type a3, typename boost::mpl::identity<A4>::type a4, boost::system::error_code& ec, typename boost::mpl::identity<R>::type failure_retval = R()) { R r = f(a1, a2, a3, a4); if (r == failure_retval) { DWORD last_error = ::GetLastError(); ec = boost::system::error_code( last_error, boost::system::native_ecat); } else { ec = boost::system::error_code(); } return r; } template < typename R, typename A1, typename A2, typename A3, typename A4> R system_call(R (__stdcall *f)(A1, A2, A3, A4), typename boost::mpl::identity<A1>::type a1, typename boost::mpl::identity<A2>::type a2, typename boost::mpl::identity<A3>::type a3, typename boost::mpl::identity<A4>::type a4, typename boost::mpl::identity<R>::type failure_retval = R()) { boost::system::error_code ec; R r = system_call(f, a1, a2, a3, a4, ec, failure_retval); if (ec) throw boost::system::system_error(ec); return r; } And you can use it like this: system_call(::MessageBox, hwnd, "A", "B", MB_OK); or: boost::system::error_code ec; system_call(::MessageBox, hwnd, "A", "B", MB_OK, ec); It seems pretty convenient to use, does not have the issues with thread-specific error codes that I am concerned about, and provides a portable interface over the top of platform-specific error handling APIs. It'll even save people from making the error of forgetting to set the error_code out parameter 'ec'. Cheers, Chris

1 0

Re: [boost] Asio multithreaded server
by berserker_r 16 Nov '06

16 Nov '06

Christopher Kohlhoff wrote: > What OS are you using? Is the session's work CPU bound? I'm on Windows XP, sry but I can't understand what you mean with the second question... Just take your sample in "server.cpp": I need to be able to change the code (in the session or server object, dunno where...) so that the server is always free to accept (and process) a new connections even if there are one or more active sessions taking a very long time to generate and send theirs response. For example: void Session::handle_read(const asio::error_code& err, size_t length) { --op_count_; if (!err) { read_data_length_ = length; ++unsent_count_; if (unsent_count_ == 1) { very_very_long_operation(); // Process the client request op_count_ += 2; std::swap(read_data_, write_data_); async_write(socket_, buffer(write_data_, read_data_length_), strand_.wrap( boost::bind(&session::handle_write, this, placeholders::error))); socket_.async_read_some(buffer(read_data_, block_size_), strand_.wrap( boost::bind(&session::handle_read, this, placeholders::error, placeholders::bytes_transferred))); } } if (op_count_ == 0) io_service_.post(boost::bind(&session::destroy, this)); } Session::very_very_long_operation() takes a lot of time I need in the meanwhile to be able in the server to accept new connections, how can I do that? I tried calling ios.run() from multiple threads as the documentation said but the server is always locked until the session's operation is completed... P.S.: be patient plz my english is not very good

1 0

Boost.Test feature request
by John Maddock 16 Nov '06

16 Nov '06

I have a couple of annoying issues with Boost.Test's output on failed tests: 1) The printing code doesn't restore the iostream's original precision after it's changed it for formatted output. It's a minor issue but very annoying at times :-) Looks trivial to patch in print_log_value as well? 2) If the type has no numeric_limits support, say if it's a composite type, like std::complex<double> then you don't get enough digits to tell what the problem is. Could the code default to whatever digits long-double has? Again a minor change to print_log_value (in my experience std lib's ignore requests for more digits than a type really has anyway, so it should be harmless?). 3) If a BOOST_CHECK_CLOSE fails, you get the two values, but not what the % difference between them was. And it's the % difference that matters :-) I know this has come up before, but it's still bugging me. Here's the problem: if the type is say a 128-bit long double then you get two very long 35-digit numbers printed out: which have two many digits for the average calculator, so you can't even calculate the % difference manually to see how far off you were! Many thanks, John.

10 19

[fusion] comparing iterators with is_same?
by Steven Watanabe 16 Nov '06

16 Nov '06

AMDG In accumulate and fold I see is_same< typename result_of::begin<Sequence const>::type , typename result_of::end<Sequence const>::type>() shouldn't this be result_of::equal_to<...>()? In Christ, Steven Watanabe

1 0

Re: [boost] [BLL] Nesting STL algorithms and mutable iterators
by Steven Watanabe 16 Nov '06

16 Nov '06

AMDG MuTPu4 wrote: > While using standart algorithm wrappers (::boost::lambda::ll) I find out > that > there is no way to call non-constant versions of begin/end without defining > new > helper functors in the user code. In other words, algorithms like ll::sort > as- > is are unusable. > I think it would be nice to add a pair of non-const helper functors, i.e. > call_mutable_begin and call_mutable_end to the library. > Perhaps deducing the iterator type from the constness of the parameter would be even better? template<class T> struct get_iterator { typedef typename T::iterator type; }; template<class T> struct get_const_iterator { typedef typename T::const_iterator type; }; struct call_begin { template<class Args> struct sig { typedef typename boost::tuples::element<1, Args>::type arg_type; typedef typename boost::mpl::eval_if<boost::is_const<arg_type>, get_const_iterator<arg_type>, get_iterator<arg_type> >::type type; }; template<class T> typename T::iterator operator()(T& t) const { return(t.begin()); } template<class T> typename T::const_iterator operator()(const T& t) const { return(t.begin()); } }; In Christ, Steven Watanabe

1 0

Re: [boost] Review Request: Boost Exception
by Matthew Herrmann 15 Nov '06

15 Nov '06

> > Message: 9 > Date: Tue, 14 Nov 2006 18:06:03 -0800 > From: "Emil Dotchevski" <emildotchevski(a)hotmail.com> > Subject: Re: [boost] Review Request: Boost Exception > To: <boost(a)lists.boost.org> > Message-ID: <BAY125-DAV966A5057842FC29C1782BD4EA0(a)phx.gbl> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=original > >> > >> > No, that's not quite what I meant. >> > >> > void tag_exception(boost::exception& x) >> > { >> > // do something to x >> > } >> > >> > void read_file() >> > { >> > boost::adorn_exception e( boost::bind( tag_exception, _1 ) ); >> > ... >> > } >> > > Could you provide more detail on the "do something to x" part? It seems to > me that it would require something similar to the boost::exception::pimpl > class, in that it must be able to store arbitrary values, but unlike > boost::exception::pimpl it would have to keep some kind of proxy for each > stored object, to be evaluated later if something throws. > > Wouldn't that amount to executing a lot of code and using a lot of storage, > even if nothing throws? Here's how it would work: > void tag_exception(boost::exception& x, std::string* filename) > { > // append filename tag to exception here > } > > void read_file(const std::string& filename) > { > boost::adorn_exception e( boost::bind( tag_exception, _1, &filename) ); > ... > } There is a (small) fixed cost of creating the functor for boost::bind and copying the pointer. By using pointers (or references, though the syntax is heavier), you avoid hidden copy-construction costs. Since boost::adorn_exception has to be declared after the variables it refers to, the pointers will still be valid when it is destroyed. Regards, Matthew Herrmann

1 0