December 2005 - Boost - lists.preview.boost.org

asio formal review
by Eugene Alterman 14 Dec '05

14 Dec '05

At last! A networking library in the true spirit of Boost. I have a few thoughts regarding the design that is basically a follow-up to the discussion started in the asio-users mailing list: http://sourceforge.net/mailarchive/forum.php?thread_id=9196138&forum_id=427… The library documents a Stream conecpt that represent a read/write stream interface over a connection. In addition to this interface classes that implement Stream contain methods for supporting establishment and management of the stream's underlying infrastructure - active and passive connection establishment, accessing socket options, handshakimg etc. I suggest to decouple this functionality from the Stream into a separate concept/interface for all the activities leading to the establishment of a stream as well as accessing connection properties. This IMO would lead to a more flexible and cleaner design. Streams could be layered (eg. SSL/TLS over TCP), and stream layering should be strictly enforced. Once the top level stream has been established there should be no access to lower level streams. When you have an established secure connection you don't want to allow direct read/write on the underlying TCP socket. Take a look at the Stream doc and notice the lowest_layer() public member function that exposes a lower layer stream. Interestinlgly, this method is not related to the documented stream functionality. It is used for connection establishemnt and accessing connection properties. The bottom line of my suggestion is to have 2 distinct interfaces. One is for stream establishment and connection properties management. It provides efficient protocol stack layer navigation and access (but no stream i/o operations). The other one is strictly layered streaming interface for data transfer. Do you think it makes sense? Thank you, Eugene

4 12

[test] Problems with Boost.Test in CVS
by Caleb Epstein 14 Dec '05

14 Dec '05

Something seems to have happened to Boost.Test overnight that causes the following simple test-case to emit an error: --- #include <boost/test/unit_test.hpp> #include <boost/test/included/unit_test_framework.hpp> using boost::unit_test::test_suite; test_suite* init_unit_test_suite (int, char*[]) { test_suite* test = BOOST_TEST_SUITE("something"); return test; } --- Output (using latest CVS): --- Boost.Test framework error: Test is not initialized --- Output (using Boost 1.33.0): --- *** No errors detected --- -- Caleb Epstein caleb dot epstein at gmail dot com

2 1

vc_8 and 1.33.1 - lots of warnings
by Yuval Ronen 14 Dec '05

14 Dec '05

Hi. I downloaded Boost 1.33.1 and tried to compile it under Visual C++ 2005 Express Edition, using 'bjam -sTOOLS=vc-8_0 stage'. It seems that everything compiled, but with *lots* of warnings. Most of the warnings can be devided into 4 categories: 1. option 'Og' has been deprecated and will be removed in a future release 2. You have used a std:: construct that is not safe. See documentation on how to use the Safe Standard C++ Library 3. The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: ... 4. This function or variable may be unsafe. Consider using ... instead. I'm quite sure that they don't indicate any bug (am I right?), but I still don't think they should show up like this and intimidate users... Yuval

9 29

vc8 and boost serialization library
by George M. Garner Jr. 14 Dec '05

14 Dec '05

I built the boost serialization library (Library and LibraryW projects) with VC8 and the /analyze option enabled. The build included http://users.erols.com/gmgarner/boost/WarningState.h with the following lines in visualc.hpp: #if (_MSC_VER >= 1400) #include "warningstate.h" #endif //(_MSC_VER >= 1400) The following errors were generated for Library (http://users.erols.com/gmgarner/boost/BuildLog.txt) and LibraryW (http://users.erols.com/gmgarner/boost/BuildLogW.zip) Regards, George.

2 2

documentation available for forthcoming boost:fsm?
by Oliver.Kowalke＠infineon.com 13 Dec '05

13 Dec '05

Hello, where can I find the documentation fort he forthcoming fsm library? http://boost-sandbox.sf.net/Statechart.zip contains no docu Best Regards, Oliver

2 1

Boost regression notification (2005-12-13 [HEAD])
by Douglas Gregor 13 Dec '05

13 Dec '05

Boost regression test failures ------------------------------ Report time: 2005-12-13T14:53:17Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 352 failures in 19 libraries: bind (1) concept_check (19) config (1) date_time (20) foreach (1) graph (4) io (1) mpl (1) multi_array (1) parameter (1) python (1) regex (16) serialization (21) smart_ptr (2) spirit (2) tr1 (182) typeof (31) wave (2) xpressive (45) |bind| bind_dm3_test: msvc |concept_check| stl_concept_covering: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 mingw-3_4_2 msvc vc-7_1 vc-7_1 vc-7_1 |config| math_info: cw-9_5-darwin |date_time| testc_local_adjustor: msvc testclock: msvc testdst_rules: msvc testfiletime_functions: msvc testgreg_duration_operators: msvc testgreg_serialize_dll: cw-9_4 intel-win32-8_1 intel-win32-9_0 vc-7_1 vc-7_1 vc-7_1 testiterator: msvc testlocal_adjustor: msvc testmicrosec_time_clock: msvc testparse_time: msvc testtime: msvc testtime_formatters: msvc testtime_period: msvc testwcustom_time_zone: msvc testwposix_time_zone: msvc |foreach| rvalue_const: intel-win32-9_0 |graph| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |io| ios_state_unit_test: intel-win32-9_0 |mpl| size_t: gcc-4_0-darwin |multi_array| index_bases: cw-9_4 |parameter| sfinae: msvc |python| stl_iterator: msvc |regex| concept_check: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-8_1 intel-win32-9_0 mingw-3_4_2 mingw-3_4_2 vc-7_1 vc-7_1 vc-7_1 regex_regress: cw-9_4 intel-win32-8_1 regex_regress_dll: cw-9_4 intel-win32-8_1 |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-4_0-darwin test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-4_0-darwin test_class_info_load_text_archive: gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-4_0-darwin test_class_info_load_text_warchive: gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-4_0-darwin test_class_info_load_xml_archive: cw-9_5-darwin gcc-4_0-darwin test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-4_0-darwin test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_demo_xml_load: intel-win32-8_1 test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |smart_ptr| pointer_to_other_test: msvc shared_ptr_alloc2_test: msvc |spirit| traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |tr1| run_complex_overloads: cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos gcc-4_0-darwin std_run_complex_overloads: cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos gcc-4_0-darwin std_run_random: cw-9_4 cw-9_5-darwin std_test_array: cw-9_4 cw-9_5-darwin std_test_bind: cw-9_4 cw-9_5-darwin std_test_complex: cw-9_4 cw-9_5-darwin std_test_function: cw-9_4 cw-9_5-darwin std_test_hash: cw-9_4 cw-9_5-darwin std_test_mem_fn: cw-9_4 cw-9_5-darwin std_test_random: cw-9_4 cw-9_5-darwin std_test_regex: cw-9_4 cw-9_5-darwin std_test_result_of: cw-9_4 cw-9_5-darwin std_test_tr1_include: cw-9_4 cw-9_5-darwin std_test_tuple: cw-9_4 cw-9_5-darwin std_test_type_traits: cw-9_4 cw-9_5-darwin test_array: cw-9_4 test_bind: cw-9_4 cw-9_5-darwin test_complex: cw-9_4 cw-9_5-darwin test_function: cw-9_4 cw-9_5-darwin test_hash: cw-9_4 cw-9_5-darwin test_mem_fn: cw-9_4 cw-9_5-darwin test_random: cw-9_4 cw-9_5-darwin test_reference_wrapper: cw-9_4 cw-9_5-darwin test_result_of: cw-9_4 cw-9_5-darwin test_shared_ptr: cw-9_4 cw-9_5-darwin test_tr1_include: cw-9_4 cw-9_5-darwin test_tuple: cw-9_4 cw-9_5-darwin test_tuple_tricky: cw-9_4 cw-9_5-darwin intel-win32-9_0 tr1_add_const_test: cw-9_4 cw-9_5-darwin tr1_add_cv_test: cw-9_4 cw-9_5-darwin tr1_add_pointer_test: cw-9_4 cw-9_5-darwin tr1_add_reference_test: cw-9_4 cw-9_5-darwin tr1_add_volatile_test: cw-9_4 cw-9_5-darwin tr1_aligned_storage_test: cw-9_4 cw-9_5-darwin tr1_alignment_of_test: cw-9_4 cw-9_5-darwin tr1_extent_test: cw-9_4 cw-9_5-darwin tr1_has_nothrow_assign_test: cw-9_4 cw-9_5-darwin tr1_has_nothrow_constr_test: cw-9_4 cw-9_5-darwin tr1_has_nothrow_copy_test: cw-9_4 cw-9_5-darwin tr1_has_tr1_ref_wrap_fail: cw-9_4 cw-9_5-darwin tr1_has_tr1_shared_ptr_fail: cw-9_4 cw-9_5-darwin tr1_has_tr1_tuple_fail: cw-9_4 cw-9_5-darwin tr1_has_trivial_assign_test: cw-9_4 cw-9_5-darwin tr1_has_trivial_constr_test: cw-9_4 cw-9_5-darwin tr1_has_trivial_copy_test: cw-9_4 cw-9_5-darwin tr1_has_trivial_destructor_test: cw-9_4 cw-9_5-darwin tr1_has_virtual_destructor_test: cw-9_4 cw-9_5-darwin tr1_is_arithmetic_test: cw-9_4 cw-9_5-darwin tr1_is_array_test: cw-9_4 cw-9_5-darwin tr1_is_base_of_test: cw-9_4 cw-9_5-darwin tr1_is_class_test: cw-9_4 cw-9_5-darwin tr1_is_compound_test: cw-9_4 cw-9_5-darwin tr1_is_const_test: cw-9_4 cw-9_5-darwin tr1_is_convertible_test: cw-9_4 cw-9_5-darwin tr1_is_empty_test: cw-9_4 cw-9_5-darwin tr1_is_enum_test: cw-9_4 cw-9_5-darwin tr1_is_floating_point_test: cw-9_4 cw-9_5-darwin tr1_is_function_test: cw-9_4 cw-9_5-darwin tr1_is_fundamental_test: cw-9_4 cw-9_5-darwin tr1_is_integral_test: cw-9_4 cw-9_5-darwin tr1_is_member_func_test: cw-9_4 cw-9_5-darwin tr1_is_member_obj_test: cw-9_4 cw-9_5-darwin tr1_is_member_pointer_test: cw-9_4 cw-9_5-darwin tr1_is_object_test: cw-9_4 cw-9_5-darwin tr1_is_pod_test: cw-9_4 cw-9_5-darwin tr1_is_pointer_test: cw-9_4 cw-9_5-darwin tr1_is_polymorphic_test: cw-9_4 cw-9_5-darwin tr1_is_reference_test: cw-9_4 cw-9_5-darwin tr1_is_same_test: cw-9_4 cw-9_5-darwin tr1_is_scalar_test: cw-9_4 cw-9_5-darwin tr1_is_signed_test: cw-9_4 cw-9_5-darwin tr1_is_union_test: cw-9_4 cw-9_5-darwin tr1_is_unsigned_test: cw-9_4 cw-9_5-darwin tr1_is_void_test: cw-9_4 cw-9_5-darwin tr1_is_volatile_test: cw-9_4 cw-9_5-darwin tr1_rank_test: cw-9_4 cw-9_5-darwin tr1_remove_all_extents_test: cw-9_4 cw-9_5-darwin tr1_remove_const_test: cw-9_4 cw-9_5-darwin tr1_remove_cv_test: cw-9_4 cw-9_5-darwin tr1_remove_extent_test: cw-9_4 cw-9_5-darwin tr1_remove_pointer_test: cw-9_4 cw-9_5-darwin tr1_remove_reference_test: cw-9_4 cw-9_5-darwin tr1_remove_volatile_test: cw-9_4 cw-9_5-darwin tr1_tricky_abstract_type_test: cw-9_4 cw-9_5-darwin tr1_tricky_add_pointer_test: cw-9_4 cw-9_5-darwin tr1_tricky_function_type_test: cw-9_4 cw-9_5-darwin tr1_tricky_incomplete_type_test: cw-9_4 cw-9_5-darwin tr1_tricky_is_enum_test: cw-9_4 cw-9_5-darwin tr1_tricky_partial_spec_test: cw-9_4 cw-9_5-darwin |typeof| data_member_native: cw-9_4 function_native: cw-9_4 msvc function_ptr_from_tpl_emulation: vc-7_1 vc-7_1 vc-7_1 function_ptr_from_tpl_native: vc-7_1 vc-7_1 vc-7_1 function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 msvc member_function_native: cw-9_4 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 noncopyable_native: cw-9_4 std_emulation: cw-9_4 cw-9_4 cw-9_5-darwin std_native: cw-9_4 cw-9_4 cw-9_5-darwin template_dependent_native: cw-9_4 template_enum_native: cw-9_4 template_int_native: cw-9_4 template_multiword_native: cw-9_4 template_tpl_native: cw-9_4 msvc template_type_native: cw-9_4 type_native: cw-9_4 |wave| testwave_dll: cw-9_4 cw-9_5-darwin |xpressive| misc1: cw-9_4 cw-9_5-darwin test1: cw-9_4 cw-9_5-darwin test1u: cw-9_4 cw-9_5-darwin test2: cw-9_4 cw-9_5-darwin test2u: cw-9_4 cw-9_5-darwin test3: cw-9_4 cw-9_5-darwin test3u: cw-9_4 cw-9_5-darwin test4: cw-9_4 cw-9_5-darwin test4u: cw-9_4 cw-9_5-darwin test5: cw-9_4 cw-9_5-darwin test5u: cw-9_4 cw-9_5-darwin test6: cw-9_4 cw-9_5-darwin test6u: cw-9_4 cw-9_5-darwin test7: cw-9_4 cw-9_5-darwin test7u: cw-9_4 cw-9_5-darwin test8: cw-9_4 cw-9_5-darwin test8u: cw-9_4 cw-9_5-darwin test9: cw-9_4 cw-9_5-darwin test9u: cw-9_4 cw-9_5-darwin test_cycles: cw-9_4 cw-9_5-darwin test_dynamic: cw-9_4 cw-9_5-darwin test_non_char: cw-9_4 cw-9_5-darwin test_static: cw-9_4

1 0

[Boost-bugs] [ boost-Bugs-1379594 ] boost::filesystem::exists and permission problem
by SourceForge.net 13 Dec '05

13 Dec '05

Bugs item #1379594, was opened at 2005-12-13 07:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1379594&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost::filesystem::exists and permission problem Initial Comment: If /a/b/c has 444 permissions and you call exists on /a/b/c/d/e.txt it will return true, even if this file does not exist. I think that if permissions prevent proper calculation a filesystem_error should be thrown. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1379594&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[asio] my review
by Cory Nelson 13 Dec '05

13 Dec '05

Let me start off by saying I'm primarily a Windows developer, and don't have any experience with the high perf apis available on *nix. So many of my issues may be related to that. I have extensively used I/O Completion Ports in C/C++ and have used the async methods in .NET. I have also used ASIO on and off for the last few months. My immediate thoughts on asio. Generally it provides a very good interface for scalable i/o. But I think there is some room for improvement, both in API and implementation. I would *not* recommend asio for inclusion in boost until at least the IPv6 issue is taken care of. For the API, one thing that struck me is the almost C-style error handling. I believe the .NET way is better. It provides a point that the developer must call to get the result of the operation, and that the sockets can throw any exceptions that would normally be thrown in sync operations. ie, void MyHandler(IAsyncResult res) { int len; try { len=sock.EndRecv(res); } } I was disappointed to not see IPv6 there. Yes, it hasn't reached critical mass yet, but it is coming fast and should be mandatory for any socket libraries. With Windows Vista having a dual stack I believe IPv6 is something everyone should be preparing for. This is the only showstopper for me. I don't want to see a ton of IPv4-centric applications made as they can be a pain to make version agnostic. Talking about IPv6, I would love to see some utility functions for resolving+opening+connecting via host/port and host/service in a single operation. This would encourage a future-proof coding style and is something almost all client applications would use. I dislike how it forces manual thread management - I would be much happier if the demuxer held threads internally. Because threading is important to get maximum performance and scalability on many platforms, the user is now forced to handle pooling if he wants that. On Windows 2000+ it is common to use the built-in thread pool which will increase/decrease the amount of threads being used to get maximum cpu usage with IO Completion Ports. Which brings me to the next thing: the timers should be using the lightweight timer queues which come with win2k. These timer queues also have the advantage of using the built-in thread pool. Async connecting does not use ConnectEx on platforms which support it. This isn't such a big issue, but it's still a disappointment. ASIO lacks one important feature, async disconnects. I don't have experience in *nix, but in Windows creating sockets is expensive and a high perf app can get a significant benefit by recycling them. A minor issue, but I'm not liking the names of the _some methods. It would be better to just document the fact that it might not read/write everything you give it instead of forcing it down the user's throat every time they want to use it. As for documentation, it is fair. It is a bit loopy at times because of the basic_* templates. I don't expect normal usage will care very much about implementation, so perhaps these can be seperated from the main documentation. I see no problems beyond that. -- Cory Nelson http://www.int64.org

8 17

Re: [boost] asio formal review begins
by Oliver.Kowalke＠infineon.com 13 Dec '05

13 Dec '05

>> sig::action sa; >> sa.set_handler( SIG_IGN); >> sig::action old_sa( sa.run( SIGPIPE) ); >> boost::shared_ptr< void > guard( >> static_cast< void * >( 0), >> boost::bind( >> & sig::action::run, >> old_sa, >> SIGPIPE) ); > >> ::write(...) >As I mentioned in another message, at least on Linux, sendmsg can be >used as replacement for writev that allows specification of >MSG_NOSIGNAL. Yes. >Your code might potentially be useful on Solaris and >other platforms that do not support disabling the signal through >mechanism like MSG_NOSIGNAL, although your code seems to introduce quite >a lot of overhead per write call. The code could be expanded to: struct sigaction sa, old_sa; if ( ::sigemptyset( & sa.sa_mask) < 0) throw std::runtime_error( ::strerror( errno) ); sa.sa_flags = ZERO; sa.sa_handler = SIG_IGN; if ( ::sigaction( SIGPIPE, & sa, & old_sa) < 0) throw std::runtime_error( ::strerror( errno) ); // shared_ptr has to call ::sigaction( SIGPIPE, & old_sa, 0) in order to // reset original signal handler So it seams to be only 3 clib-function calls for each write operation. Oliver

3 2

Re: [boost] boost::defer - generalised execution deferral
by Oliver.Kowalke＠infineon.com 13 Dec '05

13 Dec '05

Hello Simon, I've made some modifications because defer_pool::stop was not waiting for finishing all work items if thread_sleep was removed in your examples. - defer_pool : work items are queued into a thread pool; if defer_pool::stop returns, all work items have been processed - defer_thread : each work item is processed in a new thread; threads are never joined (call and forget) - defer_null : work item is processed in main thread -defer_point : interface I believe that only defer_pool needs a list of work items. defer_pool with one thread in the pool should be mimic your implementation of defer_thread. So I would use defer_thread in a create-and-forget manner. Oliver >Your suggestion about adding timed enqueue/dequeue >and a limitation on the amount of queued work items >raises an interesting point about how this kind of library >could be structured. I'd see those features not as part of >the defer_point, but as classes built on top and >parameterised with an instance of a defer_point. > >A thread_queue parameterised with a defer_point >would still keep all the logic about high/low water marks >and simply use the defer_point as a means of getting a >callback in order to service the request (i.e. by calling >into the queue consumer code). > >A bit cheeky i know, but would you be willing to write >an implementation of thread_queue along the above lines >as a test of defer_point?

2 1