- Boost - lists.boost.org

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

asio review extended till Dec 30th
by Jeff Garland 30 Dec '05

30 Dec '05

Thanks to everyone for the excellent reviews and discussions of asio! Some folks want additional time for the asio review, so the review will be extended until Dec 30th. Note that Chrisopher may not be able to respond to posts during a significant part of this time due to holiday commitments, but the feedback will eventually be addressed and discussed. In the way of reminder, here's the library details again: Today (Dec 22nd) is the first continuation of the formal review of the Asynchronous I/O library (asio) library by Christopher Kohlhoff. The review will run be extended until Friday December 30th. I will be serving as review manager. From the library synopsis: Boost.Asio is a cross-platform C++ library for network programming that provides developers with a consistent asynchronous I/O model using a modern C++ approach. Downloads of the library as well as online documentation can be found at: http://asio.sourceforge.net/ http://asio.sourceforge.net/boost-asio-proposal-0.3.6/libs/asio/doc/ As usual, please state in review comments how you reviewed the library and whether the you think the library should be accepted into Boost. Further guidelines for writing reviews can be found on the website at: http://www.boost.org/more/formal_review_process.htm#Comments Please review early and often! Thanks, Jeff ******************************************************* A Few Library Details: ******************************************************* Supported Platforms The following platforms and compilers have been tested: * Win32 using Visual C++ 7.1 and Visual C++ 8.0. * Win32 using Borland C++Builder 6 patch 4. * Win32 using MinGW. * Linux (2.4 or 2.6 kernels) using g++ 3.3 or later. * Solaris using g++ 3.3 or later. * Mac OS X 10.4 using g++ 3.3 or later. Rationale The Boost.Asio library is intended for programmers using C++ for systems programming, where access to operating system functionality such as networking is often required. In particular, Boost.Asio attempts to address the following goals: * Portability. The library should support, and provide consistent behaviour across, a range of commonly used operating systems. * Scalability. The library should allow, and indeed encourage, the development of network applications that scale to hundreds or thousands of concurrent connections. The library implementation for each operating system should use the mechanism that best enables this scalability. * Efficiency. The library should support techniques such as scatter-gather I/O, and allow protocol implementations that minimise data copying. * Model Berkeley sockets. The Berkeley sockets API is widely implemented and understood, as well as being covered in much literature. Other programming languages often use a similar interface for networking APIs. * Ease of use. Lower the entry barrier for new users by taking a toolkit, rather than framework, approach. That is, try to minimise the up-front investment in time to just learning a few basic rules and guidelines. After that, a library user should only need to understand the specific functions that are being used. * Basis for further abstraction. The library should permit the development of other libraries that provide higher levels of abstraction. For example, implementations of commonly used protocols such as HTTP. Although the current incarnation of Boost.Asio focuses primarily on networking, its concepts of asynchronous I/O can be extended to include other operating system resources such as files.

6 19

Signals Thread-Safety
by David A. Greene 29 Dec '05

29 Dec '05

I'm starting a project in which I'd hoped to use Boost.Signals but I see that it is not thread-safe. Is there a timeline for making it thread-safe? Thanks. -Dave

4 4

Bug list status
by Marshall Clow 29 Dec '05

29 Dec '05

Six weeks ago: 95 open bugs Five weeks ago: 77 open bugs Four weeks ago: 70 open bugs. Three weeks ago: 64 open bugs. Two week ago: 65 open bugs One week ago: 64 open bugs Today: 61 open bugs Now that 1.33.1 has been released, let's get these bugs cleaned up... Thank you for your cooperation! As Jeff has pointed out, Mike Glassford (threads) and Stephen Cleary (pool) have been MIA for quite a while. If anyone wants to contribute fixes for their libraries, let me (or Jeff) know! If you think that a bug has been assigned incorrectly, please let me know. Bug counts per assignee: Mike Glassford 13 Doug Gregor 8 Stephen Cleary (shammah) 6 Joerg Walter 4 Beman Dawes 3 Joel de guzman (djowel) 3 Jeff Garland (az_sw_dude) 3 Jeremy Siek 3 Jonathan Turkanis 3 John R. Bandela 2 Eric Friedman (ebf) 2 John Maddock 2 Thorsten Ottosen (nesotto) 2 Vladimir Prus 1 Kevlin Henney 1 Hubert Holin 1 Samuel Kremp 1 Jens Maurer 1 Rene Rivera (grafik) 1 Daniel Wallin 1 Here are the currently opened bugs, sorted by assignee. Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: wrong usage of ios_base::narrow Bug #: 989487 <http://sourceforge.net/tracker/index.php?func=detail&aid=989487&group_id=75…> Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: date_time type conversion warning Bug #: 1069225 <http://sourceforge.net/tracker/index.php?func=detail&aid=1069225&group_id=7…> Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: local_adjustor::utc_to_local throws 'Time label invalid' Bug #: 1220011 <http://sourceforge.net/tracker/index.php?func=detail&aid=1220011&group_id=7…> Assignee: beman_dawes <http://sourceforge.net/users/beman_dawes/> Summary: clock is not portable Bug #: 788762 <http://sourceforge.net/tracker/index.php?func=detail&aid=788762&group_id=75…> Assignee: beman_dawes <http://sourceforge.net/users/beman_dawes/> Summary: boost::filesystem::exists has bugs with UNC paths Bug #: 1164057 <http://sourceforge.net/tracker/index.php?func=detail&aid=1164057&group_id=7…> Assignee: beman_dawes <http://sourceforge.net/users/beman_dawes/> Summary: Problems with native_file_string() on windows Bug #: 1378631 <http://sourceforge.net/tracker/index.php?func=detail&aid=1378631&group_id=7…> Assignee: daniel_wallin <http://sourceforge.net/users/daniel_wallin/> Summary: [Parameter] Docco error section 2.7.2 Bug #: 1378446 <http://sourceforge.net/tracker/index.php?func=detail&aid=1378446&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: EdgeListS = setS for adjacency_list does not work Bug #: 1163077 <http://sourceforge.net/tracker/index.php?func=detail&aid=1163077&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: LEDA graph adaptors do not handle hidden nodes properly Bug #: 1168431 <http://sourceforge.net/tracker/index.php?func=detail&aid=1168431&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: random_vertex/random_edge are unnecessarily inefficient Bug #: 1204684 <http://sourceforge.net/tracker/index.php?func=detail&aid=1204684&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: Document copy_component Bug #: 1204688 <http://sourceforge.net/tracker/index.php?func=detail&aid=1204688&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: reverse_graph and constness of property maps Bug #: 1246336 <http://sourceforge.net/tracker/index.php?func=detail&aid=1246336&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: html docs frequently missing key words Bug #: 1294420 <http://sourceforge.net/tracker/index.php?func=detail&aid=1294420&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: EdgeListS = has_setS for adjacency_list does not work Bug #: 1352049 <http://sourceforge.net/tracker/index.php?func=detail&aid=1352049&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: predicates without default constructor fail to compile (2) Bug #: 1353875 <http://sourceforge.net/tracker/index.php?func=detail&aid=1353875&group_id=7…> Assignee: djowel <http://sourceforge.net/users/djowel/> Summary: Miss ' = ParserT()' Bug #: 907299 <http://sourceforge.net/tracker/index.php?func=detail&aid=907299&group_id=75…> Assignee: djowel <http://sourceforge.net/users/djowel/> Summary: spirit insert_key_actor.hpp Bug #: 1059936 <http://sourceforge.net/tracker/index.php?func=detail&aid=1059936&group_id=7…> Assignee: djowel <http://sourceforge.net/users/djowel/> Summary: Another config correction for Sun C++ Bug #: 1220782 <http://sourceforge.net/tracker/index.php?func=detail&aid=1220782&group_id=7…> Assignee: ebf <http://sourceforge.net/users/ebf/> Summary: boost::blank - missing operators Bug #: 1191356 <http://sourceforge.net/tracker/index.php?func=detail&aid=1191356&group_id=7…> Assignee: ebf <http://sourceforge.net/users/ebf/> Summary: [variant] Bug in recursive_wrapper_fwd.hpp Bug #: 1359257 <http://sourceforge.net/tracker/index.php?func=detail&aid=1359257&group_id=7…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: timeconv.inl to_duration() nsec error Bug #: 548104 <http://sourceforge.net/tracker/index.php?func=detail&aid=548104&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: Solaris - once.cpp compile error Bug #: 549162 <http://sourceforge.net/tracker/index.php?func=detail&aid=549162&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: AIX 4.3 SIGSEGV at thread termination Bug #: 551577 <http://sourceforge.net/tracker/index.php?func=detail&aid=551577&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: boost::threads uses msvc only function? Bug #: 568951 <http://sourceforge.net/tracker/index.php?func=detail&aid=568951&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: BCB6 throw EExternelException Bug #: 596149 <http://sourceforge.net/tracker/index.php?func=detail&aid=596149&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: thread_cleanup problems Bug #: 649291 <http://sourceforge.net/tracker/index.php?func=detail&aid=649291&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: Mac implementation of threads is CPU hog Bug #: 885045 <http://sourceforge.net/tracker/index.php?func=detail&aid=885045&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: xtime_cmp: use comparison not subtraction Bug #: 993272 <http://sourceforge.net/tracker/index.php?func=detail&aid=993272&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: condition variables and recursive_mutex Bug #: 1072605 <http://sourceforge.net/tracker/index.php?func=detail&aid=1072605&group_id=7…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: compiler error on Mac implementation of threads Bug #: 1201779 <http://sourceforge.net/tracker/index.php?func=detail&aid=1201779&group_id=7…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: timeconv.inl line 116 copy/paste error Bug #: 1239052 <http://sourceforge.net/tracker/index.php?func=detail&aid=1239052&group_id=7…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: Exception safety in class 'thread' Bug #: 1305885 <http://sourceforge.net/tracker/index.php?func=detail&aid=1305885&group_id=7…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: mistake in documentation of condition Bug #: 1364416 <http://sourceforge.net/tracker/index.php?func=detail&aid=1364416&group_id=7…> Assignee: grafik <http://sourceforge.net/users/grafik/> Summary: boost jam problem with parallel builds Bug #: 1234224 <http://sourceforge.net/tracker/index.php?func=detail&aid=1234224&group_id=7…> Assignee: hubert_holin <http://sourceforge.net/users/hubert_holin/> Summary: Cannot compile octonion_test.cpp because of bug in sinc.hpp Bug #: 751289 <http://sourceforge.net/tracker/index.php?func=detail&aid=751289&group_id=75…> Assignee: jbandela <http://sourceforge.net/users/jbandela/> Summary: Compiler error for tokenizer on Solaris Bug #: 976241 <http://sourceforge.net/tracker/index.php?func=detail&aid=976241&group_id=75…> Assignee: jbandela <http://sourceforge.net/users/jbandela/> Summary: token_iterator::at_end() result is inversed Bug #: 1338326 <http://sourceforge.net/tracker/index.php?func=detail&aid=1338326&group_id=7…> Assignee: jmaurer <http://sourceforge.net/users/jmaurer/> Summary: Diff in state of mersenne_twister gen between GCC3.41 & CW9 Bug #: 1115124 <http://sourceforge.net/tracker/index.php?func=detail&aid=1115124&group_id=7…> Assignee: joerg_walter <http://sourceforge.net/users/joerg_walter/> Summary: bug in ublas/storage.hpp Bug #: 1095697 <http://sourceforge.net/tracker/index.php?func=detail&aid=1095697&group_id=7…> Assignee: joerg_walter <http://sourceforge.net/users/joerg_walter/> Summary: dead links in uBLAS page Bug #: 1169273 <http://sourceforge.net/tracker/index.php?func=detail&aid=1169273&group_id=7…> Assignee: joerg_walter <http://sourceforge.net/users/joerg_walter/> Summary: Documentation not available on web site: Bug #: 1228242 <http://sourceforge.net/tracker/index.php?func=detail&aid=1228242&group_id=7…> Assignee: joerg_walter <http://sourceforge.net/users/joerg_walter/> Summary: uBLAS::subslice doesn't work Bug #: 1292635 <http://sourceforge.net/tracker/index.php?func=detail&aid=1292635&group_id=7…> Assignee: johnmaddock <http://sourceforge.net/users/johnmaddock/> Summary: Adding boost::is_complex to type_traits.hpp Bug #: 1315712 <http://sourceforge.net/tracker/index.php?func=detail&aid=1315712&group_id=7…> Assignee: johnmaddock <http://sourceforge.net/users/johnmaddock/> Summary: _GLIBCXX_DEBUG fails on 1.33.1 - bug or design? Bug #: 1391875 <http://sourceforge.net/tracker/index.php?func=detail&aid=1391875&group_id=7…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: invalid result for File Dependency Examp Bug #: 551110 <http://sourceforge.net/tracker/index.php?func=detail&aid=551110&group_id=75…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: Spelling of Edmonds-Karp-Algorithm Bug #: 1226292 <http://sourceforge.net/tracker/index.php?func=detail&aid=1226292&group_id=7…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: g++ v3.2.3 inker error for read_graphviz ih boost v1.33.1 Bug #: 1378907 <http://sourceforge.net/tracker/index.php?func=detail&aid=1378907&group_id=7…> Assignee: kevlin <http://sourceforge.net/users/kevlin/> Summary: lexical_cast & pure virtual functions & VC 8 STL Bug #: 1358600 <http://sourceforge.net/tracker/index.php?func=detail&aid=1358600&group_id=7…> Assignee: nesotto <http://sourceforge.net/users/nesotto/> Summary: boost.range and 'const char[]'. Bug #: 1272315 <http://sourceforge.net/tracker/index.php?func=detail&aid=1272315&group_id=7…> Assignee: nesotto <http://sourceforge.net/users/nesotto/> Summary: [Boost.Range]boost::const_begin calls non-qualified 'begin' Bug #: 1361686 <http://sourceforge.net/tracker/index.php?func=detail&aid=1361686&group_id=7…> Assignee: samuel_k <http://sourceforge.net/users/samuel_k/> Summary: format: assert when parsing invalid pattern Bug #: 1326132 <http://sourceforge.net/tracker/index.php?func=detail&aid=1326132&group_id=7…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: ct_gcd_lcm.hpp compilation error Bug #: 558174 <http://sourceforge.net/tracker/index.php?func=detail&aid=558174&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: test_pool_alloc.cpp not compile CW8.1 Bug #: 586779 <http://sourceforge.net/tracker/index.php?func=detail&aid=586779&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: pool::purge_memory() does not reset next_size Bug #: 984124 <http://sourceforge.net/tracker/index.php?func=detail&aid=984124&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: Borland compiler error with Pool, boost::pool_allocator Bug #: 988124 <http://sourceforge.net/tracker/index.php?func=detail&aid=988124&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: perfomance: memory cleanup for pool takes too long Bug #: 995270 <http://sourceforge.net/tracker/index.php?func=detail&aid=995270&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: boost::pool_allocator breaks with vector of vectors Bug #: 1179641 <http://sourceforge.net/tracker/index.php?func=detail&aid=1179641&group_id=7…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: rational operator&lt; can overflow Bug #: 798357 <http://sourceforge.net/tracker/index.php?func=detail&aid=798357&group_id=75…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: boost::rational documentation typos(?) Bug #: 1043616 <http://sourceforge.net/tracker/index.php?func=detail&aid=1043616&group_id=7…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: problem with boost::iostreams when compiled with Visual C++ Bug #: 1365752 <http://sourceforge.net/tracker/index.php?func=detail&aid=1365752&group_id=7…> Assignee: vladimir_prus <http://sourceforge.net/users/vladimir_prus/> Summary: multitoken broken in program_options 1.33 Bug #: 1266877 <http://sourceforge.net/tracker/index.php?func=detail&aid=1266877&group_id=7…> -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

[asio] Library Review
by Ronald Garcia 29 Dec '05

29 Dec '05

I have reviewed ASIO by browsing some of the documentation and working through the tutorial. What follows are my comments on the library. Regarding the Tutorial: Some of the tutorial material seems too low-level with respect to the facilities available from the C++ Standard Library. Why the use of char arrays, strdup, and strlen? Furthermore, is strdup a standard C++ function? I do not think it is standard C. I would like to see an interface for reading/writing that supports iterators if that makes sense. It would also be nice to be able to read from a socket into an std::string. If that is possible, then it is not obvious from the tutorial. Based on the daytime tutorial, I am concerned that not enough high-level functionality has been added to the library. The daytime examples still have the flavor of using unix sockets. I think that this low-level functionality is critical to flexibility (and perhaps performance), but I would like to be able to quickly construct simple network applications as well. Just for some perspective, here's a tcp daytime server written in the TCL scripting language: -----<snip>----- #!/bin/sh # Standard Trick \ exec tclsh $0 ${1+"$@"} proc serveMe {handle addr port} { puts $handle [clock format [clock seconds]] close $handle } set sk [socket -server serveMe 13] vwait forever -----<snip>----- and here's a tcp datetime client: -----<snip>----- #!/bin/sh # Standard Trick \ exec tclsh $0 ${1+"$@"} if { $argc != 1} { puts stderr "client <host>" exit 1 } set sk [socket [lindex $argv 0] 13] puts -nonewline [read $sk] -----<snip>----- I would like to see an interface at this coarse-grain a level of functionality as well (using the analogous Modern C++ idioms of course). I did not find the Timer 5 example (Using boost threads) to be very compelling. Granted the examples are meant to give a flavor of the library interface, but it may be more compelling to defer multi-threading to the daytime server, perhaps forking a new thread on each connection. This would probably more closely resemble a real use of the facility. I suspect that something more would need to be done to demonstrate synchronization. I am also curious if the library could provide synchronous networking (which asio supports contrary to the library's name) through an iostreams-like interface as well. Demuxer: It appears that any application that uses asio must have one and only one demuxer object floating around. If that is the case, then perhaps it would be wise to model demuxer after std::cout: a global object that is implicitly constructed and destructed and available to any translation unit that includes the relevant header. Demuxer appears to have a more general use than merely i/o. In fact it appears that demuxer could be generally applicable to other asynchronous event handling that might occur in a C++ application (Graphical User Interface come immediately to mind). Existing libraries for GUI's have their own event loop systems. Two issues to consider are: 1) Might future libraries that require asynchrony piggyback off of ASIO's demultiplexing facilitites (For example a C++ GUI library, etc). 2) How can one interleave asio's demultiplexing facilities with other existing event-based libraries. I'm afraid I have not had time to investigate whether and how this can be done in asio currently. But some applications will require mixing asio into some other master event loop. Something of like demuxer::run_one_event() would be a good start. Documentation: The reference documentation seems to be quite good. I do not see documentation for the default class types (such as demuxer) written without reference to the underlying policies involved. It would be very helpful to basic users of the library to have higher-level documentation available in addition to the detailed lower-level documentation. There appear to be some gaps in the documentation on first view (No documentation of the Demuxer_Service concept (modeled by demuxer_service). Code Comments: It was necessary for me to make the following changes to the library in order to prevent warnings and to compile under OS X (Panther/10.3): OS X 10.3 does not define EV_OOBAND. To compile the programs, I had to supply a definition to kqueue_reactor.hpp: #define EV_OOBAND EV_FLAG1 It is not clear to me that this is the proper fix. Furthermore, it was necessary for me to supply some casts in socket_ops.hpp to prevent warnings: recv_bufs[i].iov_len = static_cast<int>(b[i].size); recv_bufs[i].iov_base = static_cast<caddr_t>(b[i].data); ... send_bufs[i].iov_len = static_cast<int>(b[i].size); send_bufs[i].iov_base = static_cast<caddr_t>(b[i].data); Cheers, ron

3 5

[asio] timer questions
by Andrew Schweitzer 29 Dec '05

29 Dec '05

*Maybe there should be a "run_forever" version of demuxer::run? If I read the docs correctly, demuxer::run will exit if it has nothing left to do. So if the last timer expires, run will exit. The next time a timer is started demuxer::reset and demuxer::run must be called again or nothing will happen. Is this correct? Could this happen for sockets as well, if user never called a function like read or accept that will sit there forever until something happens? For example, if a client problem calls run, does an async connect, sends some data, but doesn't do a read, then would run stop after the send completed? Or would run wait for socket to be closed? *It looks like deadline_timer objects need to be dynamically allocated, right? It looks to me that when they destruct they stop themselves. I think this means that there are two dynamic allocations per timer started, one for the implementation and one for the "handle". Could this be avoided? Not sure avoiding it is worth the trouble. In any case, this probably needs to be documented. *Since user must allocate each deadline_timer (assuming above correct), then user must remember to toss them when timer completes. It might be nice if this could be handled automatically. *There aren't really unique IDs for timers, right? The address of the timer object must be unique as long as the timer is running, but after the timer completes it could be re-used for another timer, so that doesn't seem like a great idea. Does anyone else think unique timer IDs belong in the library? I'm not sure it's requirement, but most timer code I've worked on has used a unique ID. It's not hard for the application to provide this, but it is a bit more work.

2 8

Asio formal review
by Matthew Vogt 29 Dec '05

29 Dec '05

Firstly, I think the library should be accepted into Boost. I can't see any particular blocking issues that would prevent it being acceptable, and it is high time that some network library is available in boost, to serve as a basis for more abstract facilities. - What is your evaluation of the design? Fine, based on well understood models. - What is your evaluation of the implementation? I haven't looked. - What is your evaluation of the documentation? The documentation is quite good. I would prefer a slightly more discursive style, but the reference information is all there, and the tutorials are a good introduction. I think the examples each need a description, explaining what they exemplify. Also, many of the examples contain some code repetition, where a handler repeats task initiation code also found outside the handler; I think these should be refactored. - What is your evaluation of the potential usefulness of the library? Enormous. - Did you try to use the library? With what compiler? Did you have any problems? No. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Based on reading the documentation only. - Are you knowledgeable about the problem domain? Sockets programming, yes; asynch frameworks, no. I have a number of questions regarding the current proposal (I don't think any of these require changes before acceptance, but I am curious.) Please excuse the lack of structure to these questions :) I don't really follow the intent of the locking dispatcher. It appear to me that it simply achieves the same effect as adding a scoped lock to each dispatched method (each using the same mutex). This gives a small reduction in code, but doesn't immediately strike me as giving the code greater clarity. Also, the shared mutex that would otherwise be used in each method would be available for protecting other related code, while the locking_dispatcher hides the mutex, so that all protected code must be invoked via the demultiplexer. Perhaps a better example than that in the tutorial would make the benefit of the dispatcher clearer? The locking_dispatcher's 'wrap' method seems to be its primary purpose. Since the terminology is a little unnatural, perhaps it could be operator() ? I would like to see a user-supplied handler option for handling genuine errors, not per-call but at a higher level (maybe per-demuxer?) Typically, the response to an error is to close the socket, once open; it would be handy to supply a callback which received enough context to close down a socket, and in all other code to ignore error-handling completely. I do not think EOF should constitute an error, and I would expect that try-again and would-block errors could be safely ignored by the user. Perhaps EOF should be a testable state of the socket, rather than a potential error resulting from 'receive'. Can the proactor be made to work with multiple event sources, with the current interface? For example, wrapping simultaneous network IO and aio-based file IO on POSIX? I wonder how the demuxer would be incoporated into a GUI event-loop-based program, particularly in toolkits which mandate that GUI updates can occur from a single thread only? Perhaps the 'run' member function could be called in a non-blocking fashion? Or perhaps the demuxer could queue ready handler callbacks for later execution, rather than invoking them directly? Then the GUI thread could execute all pending handler functions on idle. I believe there should be an automatically managed buffer-list class, to provide simple heap-based, garbage-collected buffer management, excluding the possibility of buffer overruns and memory leaks. Perhaps the one in the Giallo library could be used without significant modification, and supported by the asio buffer primitives. Also, this abstraction should be used in tutorials; although it is useful and practical to support automatically allocated buffer storage, it shouldn't be needlessly encouraged. I also would like to request some commentary (in the library documentation) on future developments that are out of scope for the current proposal. Given the late juncture at which we're looking at bringing network programming into boost, I think it's important to consider desirable extensions, and how the current proposal will support them. Much of this will be discussed in the review, of course. One thing I would like to see (even in Asio itself) is a simplest-possible layer over the bare sockets layer, which took care of resource management and the intricacies of sockets programming. Ideally, this would leave an interface comparable to asynch IO programming in python and the like, suitable for the smallest networking tasks. Other, more complicated layers, such as socketstreams and compile-time filter-chaining as in Giallo, could be provided as libraries built on Asio. Matt

5 24

[review] Asio formal review.
by Rene Rivera 28 Dec '05

28 Dec '05

I vote to *not* accept Asio as a Boost library. This is based on some specific deficiencies in design/implementation and documentation. Hence if those are remedied I would be willing to change my vote. What is your evaluation of the design? Fair -- The overall separation of responsibilities is good and provides for considerable reuse. And possibly independent use of many of the facilities. Unfortunately many of the interactions and dependencies between the parts are not clear. In many situation I had to resort to reading through the implementation to figure out the various connections. Even though I can see how I would use the library in some tasks there are others I just don't see how something could be implement in an efficient manner. (More below on my specific use case) What is your evaluation of the implementation? Good -- For the given design the implementation is clear and easy to follow. But because of some particular design choice(s) there are some serious performance deficiencies which I would think prevent its use in the one area where the library was ostensibly design to be used, high performance servers. What is your evaluation of the documentation? Insufficient -- Even though I'm a proponent of Dox style automated documentation in this case the Dox reference documentation is insufficient in describing how the various operations work. The supporting design, tutorials, and examples I don't feel provide sufficient background to understand how the pieces connect and react with each other. Specifically the example code should at minimum explain why calls are done. In summary, either the reference docs need to improve significantly, or the non-reference docs need to take up the slack. What is your evaluation of the potential usefulness of the library? Good -- Even with my concerns about efficiency I can see the use in the wider connection based client/server domain where response efficiency is a minor concern. Did you try to use the library? No. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? In-depth -- I read a good portion of the documentation, and various parts of the implementation with a particular use case in mind. Are you knowledgeable about the problem domain? Yes. I have done some form of networking programming for the past 10 years. In the form of HTTP handlers, Game multiplayer games, and most recently client/server version control system. Now some details about my use case and my performance concern... I am looking at Asio to provide the socket handling for one of my current projects, the version control system. I'm in the middle of rewriting the networking aspect of it from the classic thread per client model to an async endpoints and routers star to star virtual LAN topology with a custom reliable message protocol based on UDP. This means that since I'm writing my own router I need the best performance I can get. But to give some minimal concrete numbers... Given a single gigabit line, a minimal example as a server is likely going to have multiple lines, and the most favorable situation of handling full 64K UDP packets one would need to handle about 1500 messages a second (or 2/3 of a millisecond per message). But in practice it would have to be faster than that. This means minimizing the most expensive steps, i.e. memory allocations. Currently AFAICT in order to use the async operations asio requires a model which allocates a new handler for each message received. This might be fine for many situations where those handlers will change from message to message. But for my use case I have only one handler that needs to get called for *any* message that comes in. In the asio case it means that for each message I received it would: remove the handler from the demuxer map, call the handler, which would do my custom parsing and routing, and push a new async_receive of myself (which creates a new handler object and inserts it again into the demux map). This is clearly suboptimal, and will result in considerable performance degradation. To refer to some concrete code, one can look at the Daytime.6 tutorial which does basically that procedure. Of course it would be awesome if Christopher would come out and tell me I'm stoned and point out how to achieve the optimum I need. Barring that for me to use Asio for my project I would end up creating patched versions of epoll_reactor, kqueue_reactor, reactor_op_queue, reactive_sokect_service, and win_iocp_socket_service (maybe more). Such hacking of implementation classes to me means a serious design failure. Here's to hoping I'm wrong ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

14 58

[foreach] cheap_copy crisis?
by MB 28 Dec '05

28 Dec '05

Hi, Under VC++7.1, I was surprised that a class derived from 'boost::iterator_range' was almost copied by BOOST_FOREACH. ('boost::noncopyable' works!) I think such a range that is noncopyable but derived from iterator_range is valid, isn't it ...? I think it could be dangerous if users can't find cheap_copy-customization. Regards, MB http://p-stade.sourceforge.net/

4 15