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

asio review -- number of allowed timers
by Jeff Garland 31 Dec '05

31 Dec '05

Hopefully this issue hasn't already been discussed -- I apologize if it has -- I've only been able to skim much of the last few days discussion... Another issue discussed by the 'Phoenix Group' (see my IPV4 email for explanation) is the specification of the number of portable timers allowed by asio. As many folks on this list are aware, the number of actual timers that can be set varies by operating system. This fact makes writing portable code that scales to a large number of timers difficult. From our reading of the asio docs there is no statement of limits on the number of timers. One might infer from this that the interface will portably support as many timers as users wish. While this might seem to contradict with OS based limits, it actually doesn't -- ACE and other libraries work around OS limitations by using internal timer queues that minimize (typically to one) the number of actual timers set in the OS. I've had a brief look at the implementation, but it's not clear to me that asio is doing this in all cases. So the questions are: 1) Is the intent to support an 'unlimited' number of timers portably? 2) If yes, does the implementation do this for all platforms? Jeff

2 2

Bug list status
by Marshall Clow 31 Dec '05

31 Dec '05

Six weeks ago: 93 open bugs Five weeks ago: 95 open bugs Four weeks ago: 77 open bugs. Three weeks ago: 70 open bugs. Two week ago: 64 open bugs One week ago: 65 open bugs Today: 64 open bugs Now that 1.33.1 has been released, let's get these bugs cleaned up... Thank you for your cooperation! 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 Jonathan Turkanis 4 Joerg Walter 4 Beman Dawes 3 Joel de guzman (djowel) 3 Jeff Garland (az_sw_dude) 3 Gennadiy Rozental (rogeeff) 3 Jeremy Siek 3 John R. Bandela 2 Eric Friedman (ebf) 2 Thorsten Ottosen (nesotto) 2 Vladimir Prus 1 Kevlin Henney 1 Hubert Holin 1 Samuel Kremp 1 Jens Maurer 1 John Maddock 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: 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: rogeeff <http://sourceforge.net/users/rogeeff/> Summary: typo in Boost.Test document Bug #: 629685 <http://sourceforge.net/tracker/index.php?func=detail&aid=629685&group_id=75…> Assignee: rogeeff <http://sourceforge.net/users/rogeeff/> Summary: Don't work multilevel hierarchy of test suites in dll. Bug #: 1076691 <http://sourceforge.net/tracker/index.php?func=detail&aid=1076691&group_id=7…> Assignee: rogeeff <http://sourceforge.net/users/rogeeff/> Summary: header problem in boost::test Bug #: 1365753 <http://sourceforge.net/tracker/index.php?func=detail&aid=1365753&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: no Boolean conversion for boost::rational Bug #: 1239906 <http://sourceforge.net/tracker/index.php?func=detail&aid=1239906&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.

3 4

asio review is closing...but...
by Jeff Garland 31 Dec '05

31 Dec '05

All - Thx all for the great reviews and discussions of asio. I realize the review is ending, but in a few emails I've read over the last couple days (haven't read them all) I've noticed that a few people are close to finishing reviews -- and we have several on-going discussions. Please don't stop! It's going to take me at least a couple weeks to sort thru all the emails/issues and make a decision. I don't want to lose this opportunity to provide the best possible feedback. Thx! Jeff

3 2

[asio] Formal review.
by Dick Bridges 31 Dec '05

31 Dec '05

I vote to accept asio into boost. <design> I'm very impressed by the design philosophy. This is the only network library I've encountered that let me implement application-level framing (RTP development) *and* simple TCP-based message-passing within the same framework using the same API. I think the threading model chosen will scale very well to the new generation of multiple-CPU architectures that are beginning to appear on, for example, the (Intel) desktop *and* in the "ARM-rest". ;) <aside> Although I can understand some of the objections to requiring explicit assignment of the demuxer for "synchronous" applications, the meaning of "synchronous" seems [to me] to become a little vague in the presence of multiple CPUs each providing multiple execution units. I hope we don't loose the existing ability to allocate 'blocked' and non-blocking threads among demuxers to minimize thread synchronization operations. </aside> demuxer -> io_service[S] seems to be a beneficial change. No preference on singular vs. plural. </design> <implementation> I did not spend a great deal of time evaluating the implementation except to verify that it seemed to implement the design. Based on my reading of the other reviews, the details are best left to those much more familiar with c++ than I. One argument in favor of the implementation might be made on the basis of the number of changes that were made during the review itself. The initial implementation had to have been pretty well thought out to be able to make that many changes "on the fly". </implementation> <documentation> The documentation is adequate. (I am not a fan of Doxygen.) The tutorials provide a nice exposition of the basic concepts and, along with a few short "trips" into the reference documents, allowed me to easily replace an existing networking library with asio (and simplify the code in the process). I would like to see "handwritten" reference documentation. I have no evidence but I believe it tends to be clearer and more complete than comments from the code - even when written by the same person. </documentation> <potential_usefulness> Extremely useful for IP networks and other asynchronous block devices. (IMHO questions regarding *how* iostream-like support could be supported should be proceeded by justifying *why* iostream-like support should be supported.) Suggestion1: a little syntactic sugar that provides the ability to reset() an un-expired deadline_timer "atomically" without going through the cancel()/expires_from_now() sequence. Suggestion2: SCTP support? It's about to appear in both Windows and Linux and VoIP and/or streaming multimedia will probably make it fairly important in the next couple of years. </potential_usefulness> <library_use> I substituted asio for existing networking libraries in two production projects currently being developed and tested for embedded targets. I had a couple of problems but the author promptly straightened me out. The answers were, in fact, in the documentation. Compilers: arm-softfloat-linux-gnu-g++ (GCC) 3.3.3 g++ (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2) </library_use> <problem_domain_knowledge> Fairly knowledgeable. Mostly "handwritten" network programming in Windows 3.x through XP (I was a MCSE/MCSD); UNIX SVR4; Solaris 7, 8 9; and now Linux. A copy of "Stevens" is never very far away. </problem_domain_knowledge> Regards, Dick Bridges

2 1

asio review
by marcoh77＠freenet.de 31 Dec '05

31 Dec '05

- What is your evaluation of the design? The design looks quite good. There are some points I don't realy like, e.g. that there are no high level classes. The use for _simple_ network workings is too complex. It seems as if the instance user needs too much knowledge to start with asio. - What is your evaluation of the documentation? For a first release in boost it's good. But for the future there should be some more informations for network beginners like me. The first five tutorials shows how complex the library is because the examples have nothing to do with networking. It's realy strange and discourage for a beginner to use asio if he want to start with it. Although the tutorials are understandable. - What is your evaluation of the potential usefulness of the library? The asio library is very usefull and mainly _necessary_ for the C++ community. boost is the right organisation to push a network lib and to improve asio. For the future it's important to make asio more interesting for network beginners and simple network working. I think asio is a realy good base. - Did you try to use the library? With what compiler? Did you have any problems? I tried asio with the tutorial examples. I used it with VC++7.1 and everyting worked well. It looks like there is a mistake in the asio introduction, that said that you need only the headers of boost. But with the asio tutorials with the timers you need to build the boost.date_time library. I don't know if it's only for the VC++ users, but I needed in the first example the date_time library and not only the headers. But this is not a technical mistake. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have worked with the tutorial for one or to hours. - Are you knowledgeable about the problem domain? I'm a beginner in networking and used to this day only high level networking library like for webservice calls and like this. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes it should be accepted! Best regards Amin Kharchi PS: Sorry for my bad english. "Jetzt Handykosten senken mit klarmobil - 14 Ct./Min.! Hier klicken" www.klarmobil.de/index.html?pid=73025

2 1

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