- Boost - lists.boost.org

asio review
by Scott Harris 31 Dec '05

31 Dec '05

Chris, Sorry for the late response. A delivery and the flu got in the way. --- evaluation of the design --- The design documentation is well written. How should a boost user deal with porting synchronous I/O code between platforms? Should asio be expanded or will a separate library mix well with asio? This has already received a lot of attention. --- evaluation of the implementation --- Looks good. I did not make a thorough investigation. --- evaluation of the documentation --- = tutorial = The tutorial was a good introduction to the library. = examples = It is not straightforward how the Service example eventually calls the log method. Maybe an explanation of this would help the reader bring it all together in their mind. = references = The "Size_IO_Control_Command concept" needs a better description. There are other concepts that have nondescriptive descriptions: IPv4_Address_Socket_Option, Integer_Socket_Option, Boolean_Socket_Option, ... For example, is the user of asio supposed to just know the requirements of the "Stream concept." or should some of the requirements that define the stream concept be stated in its description? Or is the list of types and member functions the requirements of the concept? I do not like to be picking on the documentation like this because it is very well written. I think that the design and tutorial are great at introducing a user to the library. I just think that a few sentences of description (requirements) of a concept will help the reader understand each concept more quickly. --- evaluation of the potential usefulness of the library --- I think that Boost needs a library that addresses the goals stated in asios rationale. The lack of synchronous I/O support makes the library less useful than it might be. --- Did you try to use the library? --- answer: no --- How much effort did you put into your evaluation? Answer: I read all of the documentation. --- Are you knowledgeable about the problem domain? Answer: I have about 10 years of active use of C++ using TCP and UDP on multiple platforms (including Linux, Solaris and Windows). Most of it has been using ACE and its Reactor but I have also implemented using the Proactor (asynch I/O). --- Do you think the library should be accepted as a Boost library? I think that asio should be expanded to support a synchronous/reactive I/O as well as its current asynchronous support. If the intent is to do so then I believe the library should be accepted. Since performance is often a consideration in networking code, I do not think that synchronous support should be built on top of asynchronous capabilities. My experience with asynchronous I/O vs synchronous I/O (ACE_Proactor vs ACE_Reactor on Windows 2000 across 8 machines on a gigabit network in an application of 1000+ simulation objects) was that I needed to have > 200 pending I/Os for the Proactor to out perform the Reactor. This implies that the problem space must include large number of non-dependent asynchronous reads and writes for asynchronous I/O to outperform a reactive approach. My experience is that most applications do not have that many parallel I/O operations. Regards, Scott

2 1

[Test] Many failures on gcc-3_3-darwin
by Douglas Gregor 31 Dec '05

31 Dec '05

There's an example here: http://tinyurl.com/azrrh It's some kind of multiple definition problem. Perhaps a missing "inline" somewhere? ld: multiple definitions of symbol __ZN5boost9unit_test92_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail24auto_ test_unit_registrar13curr_ts_storeEvE4inst13unit_test_logE /Volumes/scratch/dgregor/BoostRegressionTesting/results/bin/boost/ libs/test/build/libboost_test_exec_monitor.a/gcc-3_3-darwin/debug/ libboost_test_exec_monitor-gcc33-d-1_34.a(framework.o) definition of __ZN5boost9unit_test92_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail24auto_ test_unit_registrar13curr_ts_storeEvE4inst13unit_test_logE in section (__DATA,__data) /Volumes/scratch/dgregor/BoostRegressionTesting/results/bin/boost/ libs/test/build/libboost_test_exec_monitor.a/gcc-3_3-darwin/debug/ libboost_test_exec_monitor-gcc33-d-1_34.a(results_collector.o) definition of __ZN5boost9unit_test92_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail24auto_ test_unit_registrar13curr_ts_storeEvE4inst13unit_test_logE in section (__DATA,__data) ld: multiple definitions of symbol __ZN5boost9unit_test92_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail24auto_ test_unit_registrar13curr_ts_storeEvE4inst17results_collectorE /Volumes/scratch/dgregor/BoostRegressionTesting/results/bin/boost/ libs/test/build/libboost_test_exec_monitor.a/gcc-3_3-darwin/debug/ libboost_test_exec_monitor-gcc33-d-1_34.a(framework.o) definition of __ZN5boost9unit_test92_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail24auto_ test_unit_registrar13curr_ts_storeEvE4inst17results_collectorE in section (__DATA,__data) /Volumes/scratch/dgregor/BoostRegressionTesting/results/bin/boost/ libs/test/build/libboost_test_exec_monitor.a/gcc-3_3-darwin/debug/ libboost_test_exec_monitor-gcc33-d-1_34.a(results_collector.o) definition of __ZN5boost9unit_test92_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail24auto_ test_unit_registrar13curr_ts_storeEvE4inst17results_collectorE in section (__DATA,__data) /Volumes/scratch/dgregor/BoostRegressionTesting/results/bin/boost/ libs/test/build/libboost_test_exec_monitor.a/gcc-3_3-darwin/debug/ libboost_test_exec_monitor-gcc33-d-1_34.a(results_reporter.o) definition of __ZN5boost9unit_test92_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail24auto_ test_unit_registrar13curr_ts_storeEvE4inst17results_collectorE in section (__DATA,__data) /Volumes/scratch/dgregor/BoostRegressionTesting/results/bin/boost/ libs/test/build/libboost_test_exec_monitor.a/gcc-3_3-darwin/debug/ libboost_test_exec_monitor-gcc33-d-1_34.a(unit_test_suite.o) definition of __ZN5boost9unit_test92_GLOBAL__N__ZGVZN5boost9unit_test9ut_detail24auto_ test_unit_registrar13curr_ts_storeEvE4inst17results_collectorE in section (__DATA,__data) Doug

2 1

[Date-time] Fix for testing Jamfile?
by Doug Gregor 31 Dec '05

31 Dec '05

It seems that the Jamfile for the date-time regression tests is making GCC 2.95.x regression testing fail with this: /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:1585: in find-compatible-subvariant *** argument error * rule split-target-subvariant ( target-var properties-var toolset-var variant-var : subvariant ) * called with: ( sv-target sv-properties sv-toolset sv-variant : ) * missing argument subvariant /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:2032:see definition of rule 'split-target-subvariant' being called /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:1654: in link-libraries /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:1857: in generate-dependencies /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:1964: in subvariant-target /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:2057: in main-target /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/boost-base.jam:1369: in declare-local-target /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/testing.jam:64: in boost-test /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/testing.jam:552: in run Jamfile:218: in load-jamfiles /.automount/magrathea/root/home/user3/dgregor/Projects/boost/tools/ build/v1/bootstrap.jam:21: in boost-build /.automount/magrathea/root/home/user3/dgregor/Projects/boost/boost- build.jam:16: in module scope The following patch, which I've already applied, seems to fix the problem. However, that USE_DATE_TIME_PRE_1_33_FACET_IO define seems rather strange to me; is that really what was intended for the serialization tests? Doug Index: Jamfile =================================================================== RCS file: /cvsroot/boost/boost/libs/date_time/test/Jamfile,v retrieving revision 1.34 diff -u -r1.34 Jamfile --- Jamfile 28 Nov 2005 13:20:35 -0000 1.34 +++ Jamfile 29 Dec 2005 19:45:26 -0000 @@ -183,6 +183,8 @@ local DATE_TIME_PROPERTIES = <define>BOOST_DATE_TIME_STATIC_LINK <define>BOOST_ALL_NO_LIB <define>USE_DATE_TIME_PRE_1_33_FACET_IO std::locale-support toolset::require-boost-spirit-support ; + local DATE_TIME_DYNAMIC_PROPERTIES = <define>BOOST_ALL_DYN_LINK <runtime-link>dynamic <define>USE_DATE_TIME_PRE_1_33_FACET_IO <define>BOOST_ALL_NO_LIB + std::locale-support toolset::require-boost-spirit-support ; test-suite date_time_serialization :

2 1

[asio] socket_stream noncopyable
by Felipe Magno de Almeida 31 Dec '05

31 Dec '05

Hello, I have some questions that I'm not getting answers from the documentation: Why is socket_stream noncopyable? Is it an expensive class? If it is, why?? How can I create sockets and accept them without using new on them? I'm not being able to figure it out how. Thanks, -- Felipe Magno de Almeida

2 3

A Re: Filesystem I18n comments
by Seb Martel 30 Dec '05

30 Dec '05

> > > > I would welcome a non-throwing iterator as well. Most of our path > > iterating routines are littered with try catches to handle cases that > > aren't truly exceptional. > > Is the litter just to deal with exceptions coming out of directory_iterator > constructors? Or are there other use cases needing excessive try/catch > blocks? It is pretty much all about handling throwing constructors. > > Also, what should the interface to a non-throwing directory_iterator look > like? > > First try - in addition to the current public members, add: > > directory_iterator( const path & ph, std::nothrow_t ); > // Effects (in addition to normal construction): If error occurs, save > errno, and make iterator == the end iterator. > > system_error_type error(); > // Returns 0 if no constructor error, else errno saved by the > constructor This works well, however, pie in the sky, can we consider making the directory_iterator be no_throw by default ? Our catch implementations either logs the error and/or ignores it (pretty much all our current use cases), or pushes up a message to the user signaling the invalid input (only one occurrence of this behavior in our app): skip and move on is our most common scenario. Such a no-throw interface would at least not kill the iteration process in the advent of an error. The grief comes from a dev forgetting to try/catch the errors and the whole process being aborted prematurely and half completed. This usually gives unsatisfactory results for the user. We catch those problems in the QA cycle, but the fix isn't with a logic error, simply oversight from the developer. I would prefer having a reversed situation where the dev has the responsibility to look for errors if the specifications of the use-case requires to. The status quo is to simply try catch all path iterating routines. On a separate note, I ran into fun times with the MAX_PATH limitation on win32 =) The issue is that GetFileAttributesEx (used through fs::exists for one) fails to process anything bigger than MAX_PATH through the ascii interface. Exists would simply return false. This was causing an infinite loop in a routine that was attempting to create a unique filename through repeated tests. The wide version of GetFileAttributeEx supports a 32,767 character limit, on all but windowsME/98 platforms. Can this situation be improved by considering using the wide interface when MAX_PATH considerations kick in? Possibly introduce some asserts, or *gulp* exceptions? Cheers, -seb

1 0

lvalues and rvalues
by Arkadiy Vertleyb 30 Dec '05

30 Dec '05

Hi, What is current state of the art on l-value/r-value detection? (I know Eric made some progress in the past by using the "?" operator). What we have in typeof is quite primitive :-( I think it might be a good idea to eventially factor it out into a separate header file, and reuse, to avoid contradictions between different libs, and provide the single point of maintenance... Regards, Arkadiy

11 22

yet another asio review
by Jose 30 Dec '05

30 Dec '05

I vote YES to accept asio into boost. Below are some general comments, mostly on what I think should be added. Many thanks to Chris for sharing his expertise and continuing to work on this much needed library ! I have an FC4 x86_64 box and have spent several hours using the library and writing basic examples. I have spent many more hours surveying networking libraries and ensuring I wanted to use asio - documentation and examples It would be nice to add some client/server protocol guidelines that help in designing protocols. Something along the lines on what Chris wrote to compare using the reactor pattern vs using the proactor pattern in asio but geared to different protocols characteristics like fixed header vs variable header, line-oriented, .. The documentation could also include some tips on how to handle special cases raised in the list, like throttling .. An HTTP GET client example would be nice. Not a complete example but maybe an skeleton that can be compiled and shows how asio should be used. No doubt this would be the most used example ! - design This is the main reason I became interested in asio. The design is not only sound but also reflects the practical and wide networking experience of the author - implementation I think the library should use Boost.Threads maybe in addition to the current approach. By using Boost.Threads with asio we'll ensure continued feedback/improvements for two libraries that in many cases will be used together - performance While it has been raised that a synch iostreams interface is nice for basic usage, the major value of C++ asio is performance. I think it would be useful to keep some focus on this, maybe by providing a basic client framework to measure server performance. A basic usage for this would be to compare/benchmark different asio server implementations (latency and throughput). Look forward to the new releases !!

1 0

BCCL : Serialization Concept
by nitin motgi 30 Dec '05

30 Dec '05

Hi, Is there something in the pipeline for BCCL to validate the serialization concept. Thank you, Nitin Motgi NITIN . DOT. MOTGI .AT. GMAIL .DOT. COM

4 7

iterative type registration with typeof
by Arkadiy Vertleyb 30 Dec '05

30 Dec '05

An alternative approach to ones discussed earlier would be to use file iteration, such as: main.cpp----------------------------------- #define BOOST_TYPEOF_COMPLIANT #include <boost/typeof/typeof.hpp> #include <boost/mpl/vector.hpp> #include <boost/preprocessor/iteration/iterate.hpp> #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() BOOST_TYPEOF_REGISTER_TYPE(boost::mpl::vector<>) BOOST_TYPEOF_REGISTER_TYPE(boost::mpl::vector0<>) # define BOOST_PP_ITERATION_LIMITS (1, 10) # define BOOST_PP_FILENAME_1 "register_mpl.hpp" # include BOOST_PP_ITERATE() int main() { boost::mpl::vector1<boost::mpl::vector<int, boost::mpl::vector0<> > > v; typedef BOOST_TYPEOF(v) v_type; return 0; } register_mpl.hpp-------------------------------------------- #include <boost/typeof/typeof.hpp> #define n BOOST_PP_ITERATION() #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() BOOST_TYPEOF_REGISTER_TEMPLATE(boost::mpl::vector, n) BOOST_TYPEOF_REGISTER_TEMPLATE(BOOST_PP_CAT(boost::mpl::vector, n), n) #undef n -------------- This approach can be also applied to sequences. It would work with the current typeof. Regards, Arkadiy

1 0

Re: [boost] Filesystem I18n comments
by Seb Martel 30 Dec '05

30 Dec '05

> > > 2. Any chance of having a non-throwing version of directory_iterator > > (similar > > to status). Since such a common error like not having access to a > > directory > > throws an exception, every directory_iterator construction needs a > > try/catch. > > The recursive_directory_iterator is kind of useless since it will stop as > > soon > > as you get an "access denied". > > (Maybe a portable can_be_iterated function can be added) > > Hum. Worth considering. > I would welcome a non-throwing iterator as well. Most of our path iterating routines are littered with try catches to handle cases that aren't truly exceptional. -Seb

2 1