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

Re: Asynchronous I/O
by Hans Malherbe 24 Mar '05

24 Mar '05

Don G skryf: >That makes sense, and I have used that feature before. The hard part >about putting this technique to use in a library is that it makes >requirements on the behavior of main: it must be in an alertable >wait. If I recall correctly, GetMessage/PeekMessage are not >alertable. I like the way the ACE library handles this. You have a choice of two architectural patterns: Reactor and proactor. Reactor makes your service "reactive" by serially demultiplexing events synchronously (Proactor has mutliple threads ready to do work). To start handling events you call "handle_events". You don't really care if the call puts your thread in an alertable wait or not. That would depend on whether the reactor uses the Select_Reactor or WFMO_Reactor implementation. These patterns nicely decouple event demuxing and dispatching from all the other processing. Hugo Duncan's Giallo project uses them also. Groete Hans

2 1

Re: Asynchronous I/O
by Don G 24 Mar '05

24 Mar '05

Hi Scott, > For me there needs to be definition at this level; formalization > of concepts. With that kind of thing in place its possible that > we might one day write (async) code that moves without change > from sockets to files. Its what might keep the tech-talk on track. I agree. All the technical details we tend to focus on should be just implementation detail. Another way to say it: we should look at the interface first. > > Or am I in the wrong thread? No, this is the one. Well, at least if it isn't we're both in the wrong thread! :) That being said, I'm going to start a new thread here because the "I/O" part I think is misleading. Best, Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

[test] linking problems with boost-1.32.0-5.fc3.i386.rpm
by Maxim Yegorushkin 24 Mar '05

24 Mar '05

Hi, I upgraded today to boost-1.32.0-5.fc3.i386.rpm and my projects stoped linking complaining about libboost_unit_test_framework.so: undefined reference to `init_unit_test_suite(int, char**)'. I'm not a linker expert but it seems like libboost_unit_test_framework library does not have a weak symbol init_unit_test_suite anymore. I had to rollback to boost-1.32.0-3.i386.rpm. I'd like to know is that my problem or ...? Here are the details: [max@my text-rpc]$ rpm -qa | grep boost boost-1.32.0-5.fc3 boost-devel-1.32.0-5.fc3 [max@my text-rpc]$ scons -c scons: Reading SConscript files ... scons: done reading SConscript files. scons: Cleaning targets ... ... scons: done cleaning targets. [max@my text-rpc]$ scons scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... ... g++ -o bin/maind obj/debug/text_rpc.o obj/debug/bison_parser.o obj/debug/parser_callback.o obj/debug/pdu.yy.o obj/debug/pdu.ll.o obj/debug/main.o -lboost_unit_test_framework /usr/lib/gcc/i386-redhat-linux/3.4.2/../../../libboost_unit_test_framework.so: undefined reference to `init_unit_test_suite(int, char**)' Collect2: ld returned 1 exit status scons: *** [bin/maind] Error 1 scons: building terminated because of errors. [max@my text-rpc]$ sudo rpm -e $(rpm -qa | grep boost) [max@my text-rpc]$ rpm -qa | grep boost [max@my text-rpc]$ ls ~/downloads/boost-* /home/max/downloads/boost-1.32.0-3.i386.rpm /home/max/downloads/boost-devel-1.32.0-3.i386.rpm [max@my text-rpc]$ sudo rpm -Uvh ~/downloads/boost* warning: /home/max/downloads/boost-1.32.0-3.i386.rpm: V3 DSA signature: NOKEY, key ID 30c9ecf8 Preparing... ########################################### [100%] 1:boost ########################################### [ 50%] 2:boost-devel ########################################### [100%] [max@my text-rpc]$ rpm -qa | grep boost boost-1.32.0-3 boost-devel-1.32.0-3 [max@my text-rpc]$ scons scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... g++ -o bin/maind obj/debug/text_rpc.o obj/debug/bison_parser.o obj/debug/parser_callback.o obj/debug/pdu.yy.o obj/debug/pdu.ll.o obj/debug/main.o -lboost_unit_test_framework g++ -fmessage-length=0 -Wall -Wextra -ggdb -Iinclude -c -o obj/debug/unit_test.o src/unit_test.cpp g++ -o bin/unit_testd obj/debug/text_rpc.o obj/debug/bison_parser.o obj/debug/parser_callback.o obj/debug/pdu.yy.o obj/debug/pdu.ll.o obj/debug/unit_test.o -lboost_unit_test_framework ar r lib/libtext_rpcd.a obj/debug/text_rpc.o obj/debug/bison_parser.o obj/debug/parser_callback.o obj/debug/pdu.yy.o obj/debug/pdu.ll.o ranlib lib/libtext_rpcd.a ar: creating lib/libtext_rpcd.a scons: done building targets. -- Maxim Yegorushkin

2 2

[mpl] float representation
by Cromwell Enage 24 Mar '05

24 Mar '05

--- Bruce Trask <Bruce.Trask(a)prismtech.com> wrote: > Hi Cromwell, Hello, Bruce. > Got your email from the boost archive list. I just > posted a question regarding representing floats in a > mpl type of way. Aleksey referred me to you and some > of the work you have done in this area. Ah, good. Someone still remembers me :) > I was planning on using float_<9900001, 5> with the > first part being the mantissa and the second being > the exponent. Does it stand for 990000100000 or 990000.1? One of the reasons I held off on tackling boost::mpl::fixed is not knowing what representation is both doable in MPL and most readable to the user. > Have you had success representing floats and doubles > using the boost techniques? Success has been limited. I'm currently representing compile-time floating-point numbers in terms of fractions and mixed numbers. More numbers can be represented in exact form this way. For applications requiring moderate precision, my implementations of boost::mpl::fraction and boost::mpl::rational should suffice (though I'll have to study the recent discussions on rational operations to see if there's room for improvement). For applications requiring extreme precision (e.g. calculating PI at compile time), I've attempted to offer boost::mpl::big_integral, boost::mpl::big_fraction, and boost::mpl::big_rational as arbitrary-precision variants. It is here where I run into trouble; using MinGW 3.4.2 on an "average user"'s computer, I can barely compile a single divide operation on big_integrals, and it usually takes a half-hour to do so. I need to somehow make big_integral more efficient before tackling big_fraction and big_rational. If you weren't able to obtain my work so far, it's still at <http://groups.yahoo.com/group/boost/files/mpl_math.zip>. I'll have to update the documentation's look and feel before moving it to the new File Vault, but feel free to try it out and submit improvements. > Thanks in advance. You're welcome. > Regards, > Bruce Trask Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Testing Farm
by David Abrahams 24 Mar '05

24 Mar '05

I have done some investigation and it may be possible for OSL to provide a testing farm for Boost developers. OSL would like to know what kind of hardware, OS, compilers are most needed. Please post your requests in this thread. -- Dave Abrahams Boost Consulting www.boost-consulting.com

16 35

string_algo / split empty last token
by Stefan Slapeta 24 Mar '05

24 Mar '05

Hi, is it possible to make the split function return the last token even if empty? IMO the current behaviour is a violation of generic concepts: split(..., "\tabc") -> returns 2 tokens split(..., "abc\t") -> returns 1 token What is the rationale for this? Stefan

2 1

[review results] hash functions accepted
by Thorsten Ottosen 24 Mar '05

24 Mar '05

Dear all, I'm pleased to announce that Daniel James' hash-functions library is accepted into boost. The review comments were generally positive, a few bugs were fixed and in general we had a solid discussion in favor of the current design. Congratulations to James! I would like to thank all who partcipated: Dave Harris Peter Dimov John Maddock Joaquin M. Chris Jefferson Caleb Epstein Topher Cooper David Abrahams Alberto Barbati Tobias Swinger Jaap Suter Rob Stewart Bronek Kozicki Below is a list of issue that was resolved; let us have a discussion about any of them if I have misunderstood something. Also, feel free to mention something if it was forgotten by me. Issues and solutions: --------------------- 1. for those who don't want to include the whole std-lib, individual headers can be put in hash/std/XX.hpp (but see 3) 2. update docs to reflect that ADL is used. 3. consider if the primary template should not take 1 range parameter and call hash_range; unordered containers can then be explicitly overloaded when they become available. this would also have the great effect that subranges like sub_range<string> "just works" by default 4. avoid too many zero hash values by defaulting to something other than 0 5. change implementation of hash values for pointers so undefined behavior is gone (and consider adding x + (x >> 3) ) 6. the design aim was predictibility and to minimize collision; for the latter part, I would like to know if similar values hash to similar buckets or not. If very different objects end up in the same buskets, wouldn't equality be much faster rejected? Should this be a concern? 7. the hash_ptr<> suggestion is better done with general indirected function 8. hash_range should be overloaded to take an initial seed best regards Thorsten, review manager -- Thorsten Ottosen ---------------------------- www.dezide.com www.cs.aau.dk/index2.php?content=Research/bss www.boost.org www.open-std.org/JTC1/SC22/WG21/

7 23

[Boost-bugs] [ boost-Patches-1169756 ] Threads add additional assert to aid in debugging join()
by SourceForge.net 24 Mar '05

24 Mar '05

Patches item #1169756, was opened at 2005-03-24 09:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1169756&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: hxpro (hxpro) Assigned to: Nobody/Anonymous (nobody) Summary: Threads add additional assert to aid in debugging join() Initial Comment: see discussion at http://article.gmane.org/gmane.comp.lib.boost.user/10093 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1169756&group_… ------------------------------------------------------- This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: Asynchronous I/O
by Don G 24 Mar '05

24 Mar '05

Hi Hans, Robert and Patrick, My comments are below. Hans Malherbe wrote: > The main thread does the waiting. > > In Windows NT you will either wait on the event flag > in the OVERLAPPED structure or specify a completion > routine and wait in an alertable state with the > SleepEx or one of the *WaitFor*ObjectsEx functions. That makes sense, and I have used that feature before. The hard part about putting this technique to use in a library is that it makes requirements on the behavior of main: it must be in an alertable wait. If I recall correctly, GetMessage/PeekMessage are not alertable. Robert Ramey wrote: > Windows has the concept of "Overlapped I/O" which > permits dispatch of an i/o request that invokes a > callback when done. > > Posix has aio which functions (I believe) in a > similar way. > > So one has the concept of asyncronous i/o without > any explicit reference to threads at least at the > application level. Yes, you are correct; this is a terminology challenged area for me<g>! In this case as well as the above, the application has to wait for completion in the correct manner - not so good for a library IMHO. Patrick M�zard wrote: > By the way, there were and will be lengthy > discussions about which approach is the "best" to > build scalable concurrent programs. I think that > multithreading and event-driven programming were > proven to be equivalent from a theorical point of > view, but there real differences in implementation. It's so hard to find the "best" isn't it? :) Of course, there is seldom a consistent "best" even when an objective measure can be produced (which is almost never) because the result depends so greatly on the scenario or use case. Perhaps the key ingrediant to "best" is "widely used" or "commonly accepted". If you pause to think about it, a standard technique (that wasn't gratuitously inefficient) that everyone could just use would be better (IMHO) than a more optimized, but niche/non-portable technique. Thanks all! Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

3 2

[typeof] submission updated
by Arkadiy Vertleyb 24 Mar '05

24 Mar '05

Hi all, The typeof submission in the Boost sandbox file vault has been updated to include a fix allowing faster compiles with GCC (in emulation mode), as well as a workaround for what seems to be remains of ETI bug in VC71. Please take it at: http://boost-sandbox.sourceforge.net/vault/, typeof.zip. Regards, Arkadiy

1 0