March 2005 - Boost - lists.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

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

24 Mar '05

Hi Patrick, Thanks for the links. I looked briefly at the Twisted reference, but since I do not speak python, it was a hard going. :) I will put more effort into it soon. Best, Don --- Patrick M�zard <pmezard(a)gmail.com> wrote: > You should take a look at the python Twisted framework > <http://twistedmatrix.com/>. There are performance issues in python > with > threads because of the Global Interpreter Lock (GIL). The framework > is a > workaround, performing every task in an asynchronous way from a > single > thread. The design of the Defer class is interesting and is the key > of > asychronous tasks control flows > (<http://twistedmatrix.com/projects/core/documentation/howto/defer.html>). > > 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. You could read this one and many items from its > bibliography too: > > <http://capriccio.cs.berkeley.edu/pubs/threads-hotos-2003.pdf> > (The Capriccio project was really interesting too, on the paper. I > do > not know where they are now). > > Patrick M�zard __________________________________ Do you Yahoo!? Yahoo! Sports - Sign up for Fantasy Baseball. http://baseball.fantasysports.yahoo.com/

1 0

Why do we build debug variants of our compiled libraries?
by Doug Gregor 24 Mar '05

24 Mar '05

Looking at the Jamfiles for Signals, Python, and the other libraries in Boost that have compiled parts that users link against, I'm wondering why we create so many variants by default. Why would a user want to link against the debug version of Signals, for instance? The only reason I imagine would be to debug Signals, but I should hope that the average user does not need to debug that code. If I dig around /usr/lib and /usr/local/lib on my Mac, I only find optimized libraries: nobody else seems to bother building debug variants, so why should we? Anyway, my recommendation is that we stop building debug variants of compiled libraries by default. It's easy for the user to build them if they are really required. Doug

3 2

[iostreams] gcc failures
by Vladimir Prus 24 Mar '05

24 Mar '05

Jonathan, your iostreams library fails all tests on gcc-3.2.3-linux and gcc-3.3.5-linux. See, for example: http://tinyurl.com/4d8we The failures are not marked as expected so: 1. Do you know about them? 2. Is it possible to fix them? Or mark them as expected? I get the same problem locally, so can test any patches, if you don't have those specific version of compilers. Thanks, Volodya

2 2

FSM review
by Jonathan Turkanis 23 Mar '05

23 Mar '05

I vote to reject the FSM library because I find the rationale for not providing better performance insufficient. Specifically, I am not convinced that the framework could not have been implemented to use static dispatch, constant-time dynamic dispatch or some combination of these and the current approach. Normally, before voting to reject a library I like to study the implementation thoroughly so I can make concrete proposals about how it might be improved. I haven't had time to do this with the FSM library, but I would still like my view to be known. I'll start by going through the relevant portions of rationale.html; then I'll answer the review questions. ------- * Introduction. The nine requirements are well-stated, and I accept them. * Dynamic configurability. I agree with the argument for not making all state machines dynamically-configurable. However, the documentation does not explain why it would not be possible to support both dynamically-configurable and non-dynamically-configurable state machines in the same framework, the way xpressive supports both dynamically and statically specified regular expressions. However, I don't consider dynamically-configurability essential, so I'm satisfied with the library in this respect. * Speed versus scalability tradeoffs. Here there is a big problem. I accept that there must be a speed versus scalability tradeoff; in fact, I'd be slightly surprised if there weren't. However, I would normally expect a slow-down of at most a few percentage points when using a framework; I find it stunning that the difference in performance between hand-written machines and framework-generated machines is so significant (10ns/10ns vs. 130ns/220ns), even in a "somewhat unrealistic" test case. In order to accept this performance gap I would need a very convincing explanation. Instead, the explanation seems to be of this form: "The requirements are X; I tried hard to satisfy X without compromising performance, but I couldn't; therefore, it can't be done." Even if we accept that the author really has tried all known techniques, it is important to document what was tried and why it doesn't work, since many library users are sure to be surprised by the performance difference and wonder whether it represents a flawed design. The explanation of why the performance difference shouldn't matter is also unconvincing. I'm particularly disturbed by the implication that FMSs should not be used for parsing. Why not? I have a candidate application of FMSs which is very similar to parsing. I'm currently modifying the Iostreams library to accommodate non-blocking i/o, and I have come to see that many filters can be thought of as state machines. The fact that a dispatch may involve a linear serach involving an RTTI check at each step immediately rules out use of the FSM framework to implement filters, since this search would have to be performed for each character. So if I want to benefit from the FSM abstraction, I would have to write my own framework. I don't see why this should be necessary. * Double dispatch. This seems like it should be a subsection of "Speed versus scalability tradeoffs" - Acyclic visitor: I accept this explanation. - GOF Visitor: It's natural to ask why a complex state machine can't be broken up into several parts which don't know much about each other, each of which uses a more efficient form of dispatch. Less efficient dispatch would be needed only at junctions between the separate parts. Dave Gomboc raised a similar point, and I don't think it has been adequately addressed. - Two-dimensional array of function pointers. This explanation makes no sense to me, even as supplemented by Andreas's reply to Iain Hanson this morning. It's common for a composite component to make use of several components implemented in different TUs. For instance, the composite commonent may "know about" the other components by derivation, by containment, typelists, etc. When it needs to assemble the array of pointers, it can simply ask each of them for their contribution. If there are order of initialization problems, the arrays can be allocated on first use. ------- In my experience, C++ provides extremely fine-grained control over which parts of a computation are performed at compile time and which at runtime. I have a strong suspicion that a FSM library could be written which satisfies the nine requirements and also provides ruthless efficiencies, at least in many common cases. It may turn out to be necessary to sacrifice performance for some FSMs, but I believe I hybrid approach may be possible which uses fast dispatch in the majority of cases. I'm willing to be convinced that it is impossible, but I haven't seen a satisfying explanation yet. Pavel Vozenilek wrote: > Here are some questions you might want to answer in > your review: > > * What is your evaluation of the documentation? > How easy (or hard) it is to understand library > features? What can be improved? The documentation is quite good, except that the Rationale is insufficient. > * What is your evaluation of the design? > What features are supported better by > alternative FSMs? What could be added > (or removed) from the library? Since I've already discussed my dissatisfaction with performance, I'll just address the library's user interface. Overall, I find the design very good. Others have complained about use of CRTP or having to forward to declare states, but to me it looks pretty easy to use. I only have a few comments: - The documentation warns that executing code after calling simple_state::transit (and several other functions) can lead to undefined behavior. I believe the library should prevent this from occurring. One approach would be to have the function specify a result which is stored until react has finished executing, and then acted upon. Another possibility would be to give result move semantics, so result instances can't be stored in local variables and returned later. - The restriction on event deferral -- one must pass an event pointed to by an instance of intrusive_ptr -- is extremely inelegant: int main() { myMachine.process_event( *boost::intrusive_ptr<Event>( new Event() ) ); } I'm sure there is a good reason for this restriction, but there must be a cleaner way to accomplish the same thing. - The procedure for posting events from inside entry actions looks messy; this is noted in the docs, and it's not nearly as bad as the syntax for event deferral, but I'd like to see it improved. - I don't understand why it is necessary to pass a type as a length-one mpl::list simply because it is a class template instantiation. The docs say it is "due to some template-related implementation details", but this sounds fishy to me. > * The library documentation contains > few not yet solved issues (name, > separating the library into two parts, > exception handling). What is you opinion here? I have no opinion. > * What is your evaluation of the implementation? > Are there parts of code too obscure or > duplicating exiting Boost functionality? > Can something be factored out to standalone > library or among general utilities? Unfortunately, I only had time to glance at the implementation. > * Are there performance bottlenecks? > Does the library design fit requirements > of real-time systems? How is it useable > for embedded systems? > Is the documentation clear on performance > tradeoffs? See above. > * What is your evaluation of the potential > usefulness of the library? Useful, judging by the comments of reviewers who are actually using the library. > Can you compare this FSM to other implementations? No. > * Did you try to use the library? With what > compiler? Did you have any problems? > Do you have tips for better support of older > compilers? What are possible portability problems? I ran the regression tests on seven compilers, with the following results: 1. VC7.1 -- passed all tests 2. VC8.0 -- passed all tests 3. VC7.0 -- ...failed updating 36 targets.. ...skipped 144 targets... ...updated 506 targets... 4. GCC 3.4.1 (Cygwin) -- passed all tests 4. GCC 3.2 (MinGW) -- passed all tests 5. Intel 8.0 ...failed updating 4 targets... ...skipped 4 targets... ...updated 678 targets... 6. CW 8.3 ...failed updating 28 targets... ...skipped 112 targets... ...updated 546 targets... 7. Borland 5.6.4 ...failed updating 36 targets... ...skipped 144 targets... ...updated 506 targets... I'd be happy to send the full error messages. > * How much effort did you put into your > evaluation? A glance? A quick reading? In-depth study? Probably about six or seven hours studying the documentation, reading the review comments and preparing my review. > * Are you knowledgeable about the problem domain? I'm not very familiar with FMSs, but know quite a bit about other formal models of computation such as DFAs and Abstract State Machines. > Pavel Vozenilek > FSM review manager Jonathan

4 25

Documentation bug in boost::any
by Michael Goldshteyn 23 Mar '05

23 Mar '05

There is a bug in the sample code which cause me a lot of grief in understanding how boost::any functions, this morning. At: http://www.boost.org/doc/html/any/s02.html The code: --- bool is_string(const boost::any & operand) { return any_cast<std::string>(&operand); } should read: bool is_string(const boost::any & operand) { return any_cast<std::string *>(&operand); } --- Notice the addition of the asterisk. Thanks, Michael Goldshteyn

2 5

RE: [boost] Why do we build debug variants of our compiled libraries?
by Brian Braatz 23 Mar '05

23 Mar '05

Some thoughts below > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Doug Gregor > Sent: Wednesday, March 23, 2005 8:23 AM > To: Boost mailing list > Subject: [boost] Why do we build debug variants of our compiled libraries? > > Looking at the Jamfiles for Signals, Python, and the other libraries in > Boost that have compiled parts that users link against, I'm wondering > why we create so many variants by default. Why would a user want to > link against the debug version of Signals, for instance? The only > reason I imagine would be to debug Signals, but I should hope that the > average user does not need to debug that code. > > If I dig around /usr/lib and /usr/local/lib on my Mac, I only find > optimized libraries: nobody else seems to bother building debug > variants, so why should we? > [Brian Braatz Writes:] At least when I use signals (and other libraries) I always build against the debug for development. While I may not be debugging signals specifically, I may be wanting to see: 1- Signal calls on the call stack in my IDE 2- How my code is using signals - i.e. the focus is on MY code, but being able to step in and out of the signals stuff *=(or any boost lib for that matter) helps me see how my code is working WITH it 3- You may recall I am the same guy who occasionally begs\whines\offers to wash your car FOR: some kind of metadata in signals, I the reason is when you use this lib extensively, you may have a hard time figuring out WHERE something came from. Occasionally, I step into signals and look at the internal data to figure out where the slot came from > Anyway, my recommendation is that we stop building debug variants of > compiled libraries by default. It's easy for the user to build them if > they are really required. > > Doug [Brian Braatz Writes:] Are you just talking about when you do a bjam build of boost (or specific lib)? I use the debug from this mode, but would be happy to change my script to pass in an extra param. The NICE thing about the "build everything" model is it is a catch all for peoples usage.

3 2

Sun C++ regression tests missing?
by Peter Dimov 23 Mar '05

23 Mar '05

Where did our Sun C++ test results go? I wanted to make sure that I haven't introduced any regressions with my latest changes to bind. -- Peter Dimov http://www.pdimov.com

6 17

RE: [boost] Re: boost::iostreams: only with std::cout?
by Dirk Griffioen 23 Mar '05

23 Mar '05

Hi Jonathan, Thanks for helping me out!! I've tried your proposition below and it does the trick, even with actual encryption going on: out << "test" << std::endl; //this works //out << "test" << "\n"; //this does not One remark: he code above works on my vc71 debug setup (cl called through bjam v2 build v10), but if I read your earlier mail correctly it should be the other way around and hang as well? One question: is this behaviour intended? I will try some more stuff (with some other containers , the copy/adapt etc) and source/sink - apart from encryption I am in need of a audio source/sink. I'll let you know :) - It's great stuff! Cheers, Dirk (Sorry the code didn't compile, forgot to match the filter names). (And what do you mean by 'red herring' ? :) -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jonathan Turkanis Sent: Tuesday 22 March 2005 22:32 To: boost(a)lists.boost.org Subject: [boost] Re: boost::iostreams: only with std::cout? Dirk Griffioen wrote: > I would love to use the boost::iostreams lib, so I created a filter > (which, in this case, does encryption) > > but instead of passing it std::cout I would like to pass it some other > stream, a stringstream for instance (or any kind of ostream/istream, > depending on the direction). > However, I was very surprised to find the following code taking 100% > cpu and not returning. It probably means I did something wrong, but I > can't seem to find it. Here's a cleaned up example that reproduces the bug (when endl is replaces by "\n"). It seems the filter is a red herring. Jonathan #include <iostream> #include <sstream> #include <boost/iostreams/filtering_stream.hpp> int main() { boost::iostreams::filtering_ostream out; std::ostringstream os; out.push(os); out << "test" << std::endl; //out << "test" << "\n"; std::cout << os.str(); } _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this email in error please notify our system management at postmaster(a)optiver.com and immediately and permanently delete this message and any attachments. ********************************************

4 3

RE: [boost] Why do we build debug variants of our compiled libraries?
by Brian Braatz 23 Mar '05

23 Mar '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of John Maddock > Sent: Wednesday, March 23, 2005 9:13 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Why do we build debug variants of our compiled > libraries? > > > Anyway, my recommendation is that we stop building debug variants of > > compiled libraries by default. It's easy for the user to build them if > > they are really required. > > There is one exception: if you're using VC++ or some other compiler that > ships with multiple runtimes, then you *must* link against a Boost lib > that's built against the same runtime as your application is using > (probably > a debug runtime during development). Of course on Linux (and probably > most > Unix variants) this is a non-issue. > > John. > [Brian Braatz Writes:] thanks John- that is a good point I recall you CAN also accomplish rolling in a "release" version of the std runtime with debug build of an exe, but it is brittle and does not work in all cases for all types of projects- this solution requires you to very carefully tweak all the right compiler settings across all the libraries. In other words, just because you can doesn't mean you should :)

4 3

[Boost-bugs] [ boost-Bugs-1169273 ] dead links in uBLAS page
by SourceForge.net 23 Mar '05

23 Mar '05

Bugs item #1169273, was opened at 2005-03-23 17:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1169273&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scott Otterson (scotto36) Assigned to: Nobody/Anonymous (nobody) Summary: dead links in uBLAS page Initial Comment: At: http://www.boost.org/libs/numeric/ublas/doc/#further_information there are many dead links. For example, none of the links under "uBLAS Concept definitions" work. Sorry, I couldn't figure out where else to post this! Scott ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1169273&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

[Regressions] Question for Mr Caleb Epstein.
by Hubert Holin 23 Mar '05

23 Mar '05

Somewhere in the E.U., le 16/03/2005 Bonjour I am currently investigating some regressions for my quaternion and octonion libraries, which appear in the report of the tests you run under SunOS5. I have the feeling that for "long double" variables, numeric_limits<long double>::epsilon() returns the correct value, but standard transcendental functions (atan at least) behave as if their input were "double" and not "long double". Do you know if this is the case? Merci Hubert Holin

2 2

[wave] tool/lib
by Gennadiy Rozental 23 Mar '05

23 Mar '05

Hi, I would like to reiterate my concern about wave tool/library. I did not want to continue original discussion, cause I did not want to interfere with the review (I actually believe wave is a valuable tool that needed to be accepted). In following items I will try to justify my position that it (wave tool/library) needs to be treated as a tool not a library: I. It doesn't really fit into our library review model 1. Any review period wouldn't be enough for the majority of reviewer to get any (if any) decent look on implementation. Not only because it quite big, but because it require special knowledge 2. To be able to give any opinion on the design, one need essentially detail knowledge of C++ specification in regards to preprocessor. And I couldn't see how reviewer could see how design meet the requirements within review period. 3. Reviewers couldn't run test to check this tool do what it supposed to do. II. It has different target audience then boost libs I believe that in 99.99% of use cases it is going to be used as a tool, not as a library. One could probably need custom C++ preprocessor, but only in academic purposes, and definitely not in production. III. It doesn't really fit a maintenance model I don't see that any tester will ever run regression tests for the wave. And definitely not on regular basic as we do with rest of boost libs. IV. It doesn't really fit distribution model We distribute our libraries in a form of source code. It doesn't seems reasonable for wave. It should be distributed in a binary form. As I said majority of it's target audience will use it as a tool and shouldn't be punished if they use a compiler that couldn't handle spirit for example. On the other hand we are adding meg of source code that nobody (almost) will ever look into (other then spend time to compile a tool). Also documentation for this tool should be really tool-user directed - no need for the implementation to blur the view unless one is interested in it. I believe we need to introduce formal division on tools and libraries within boost. We already have couple useful tools that my have usage outside of boost (we need to document the first), I see several others that could be added. The review procedure for the tools should be different from the libraries. Essentially we need to review only the users guides and run already rebuilt executables. There may be something else I missing, we should discuss it. I believe there is a reason why language working group is separate from library working group in standardization committee. Let's keep clear separation of concepts here also. Regards, Gennadiy

8 26

[Boost-Bugs] [ptr_container]
by Pavel Chikulaev 23 Mar '05

23 Mar '05

Hi all, It's quite strange that I can't write something like that: ptr_vector<int> v; ptr_vector<int>::const_iterator i = v.begin(); //won't compile on VC7.1 ptr_vector<int>::iterator j = v.begin(); //It works ptr_vector<int>::ptr_const_iterator ip = v.ptr_begin(); //won't compile on VC7.1 ptr_vector<int>::ptr_iterator jp = v.ptr_begin(); //it works but const ptr_vector<int> cv; ptr_vector<int>::const_iterator k = cv.begin(); //works as expected ptr_vector<int>::const_iterator kp = cv.ptr_begin(); //works as expected but std::vector<int *> v2; std::vector<int *>::const_iterator = v2.begin(); //works just fine Obviously, this is a bug. -- Pavel Chikulaev

2 1

Regression report for Releases?
by Jeff Garland 23 Mar '05

23 Mar '05

Do we have the results of the 1.32 regression tests somewhere? I'm curious what the actual final release results were, but I can't find them anywhere. I thought at one time we maintained them on the website? Anyway, it be really nice to snapshot the final test web pages and include them in the release package. That way everyone could simply look at the results and get an idea about how their compiler/platform might work with that release -- of course that should be on the website too. Jeff

7 45

[Boost-Bugs] [ptr_container]
by Pavel Chikulaev 23 Mar '05

23 Mar '05

Hi all, It's quite strange that I can't write something like that: ptr_vector<int> v; ptr_vector<int>::const_iterator i = v.begin(); //won't compile on VC7.1 ptr_vector<int>::iterator j = v.begin(); //It works ptr_vector<int>::ptr_const_iterator ip = v.ptr_begin(); //won't compile on VC7.1 ptr_vector<int>::ptr_iterator jp = v.ptr_begin(); //it works but const ptr_vector<int> cv; ptr_vector<int>::const_iterator k = cv.begin(); //works as expected ptr_vector<int>::const_iterator kp = cv.ptr_begin(); //works as expected but std::vector<int *> v2; std::vector<int *>::const_iterator = v2.begin(); //works just fine Obviously, this is a bug. -- Pavel Chikulaev

1 0

[program_options] Patch to fix 64bit error and warning
by Jonathan Wakely 23 Mar '05

23 Mar '05

The attached patch fixes a 64 bit portability problem where std::string::size_type is assigned to unsigned, which is shorter than size_t on x86-64 and so will be truncated. This means the following comparison to std::string::npos is always false. Patch also prevents a warning with GCC; since the compiler doesn't know that boost::throw_exception never returns it thinks that cmdline::translate_property() can reach the end of the function without returning. The patch simply removes the "else" so that throw_exception is always called if control reaches the end of the function. A better solution might be to mark boost::throw_exception() with __attribute__((unused)) for GCC. The first change is required, the second is optional. jon -- "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity." - W.A. Wulf

2 3

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

23 Mar '05

--- Don G skryf: >Of the mechanisms discussed, I am not sure I understand what you mean >by async I/O with only one thread. I can imagine a nonblocking/select >style approach that has no extra threads, but as soon as the main >thread is not waiting on I/O itself (my interpretation of "async"), >there needs to be threads to do the waiting. 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. Groete Hans Malherbe ______________________________________________ "This information is intended only for the person or entity to which it is addressed and may contain private, confidential, proprietary and/or privileged material and may be subject to confidentiality agreements. Any review, retransmission, dissemination, or any other use of or taking of any action in reliance upon this information, by persons or entities other than the intended recipient, is prohibited. If you received this in error, please contact the sender and delete the material from all storage media. The company is neither liable for proper, complete transmission of the information contained in this communication, any delay in its receipt or that the mail is virus-free"

1 0

Re: Re: FSM review
by Andreas Huber 22 Mar '05

22 Mar '05

Rob Stewart wrote: [snip] > Without digging out the previous messages and confirming the > matter, I think Jonathan's suggestion, quoted above, was simply > that *when* the user wants separate translation units *and* the > features that would typically require tight coupling, you could > introduce a weaker link -- some form of indirection -- that would > slow the resulting FSM or even complicate its specification, but > would at least permit the functionality. I think that's close to what I understood... [snip] > This is right on target. *Since* the current design, with all of > its requirements is so much slower, then the onus is on Andreas > to explain why the requirements his library meets exceed those > met by other FSM libraries and directly lead to the performance > overhead. Clear distinctions regarding the performance > improvements gained by avoiding the performance draining features > in an FSM while still using this library will help to demonstrate > that situation, too. [and] [snip] >> Normally, in designing a framework one considers a small handful >> (say two to six) of alternate designs which view the subject matter >> from completely different perspectives. In your case, what were >> those alternate designs? > > Note that Jonathan is asking that those alternatives be > documented. That way, other developers who wonder why you didn't > try X will see that you did and they'll see why you decided it > was not appropriate. I have agreed to add such documentation in one of my previous answers. >> Let me make one last attempt to explain what should be in the >> rationale. Look at section 16.2 of "The C++ Programming Language", >> 3d ed. Here Stroustrup gives two design criteria for a containers >> library, and then discusses three designs: >> >> "Specialized containers and iterators" - satisfies the first >> criterion "Based Containers" - satisfies the second criterion >> "STL" - satifies both criteria >> >> I'm not suggesting that you give such a detailed treatement as >> Stroustrup. However, if you were to give a similar overview of the >> landscape of possible FSM frameworks, and thoughtfully discuss the >> tradeoffs in flexibility and performace which each involves, >> reviewers might have some confidence that you are aware of the >> techniques which might be used to construct a fast, flexible FSM >> framework, and have carefully considered the design. >> >> This type of overview would probably be a useful component of any >> library's documentation; in your case it is made absolutely >> essential by the performance figures you cite. > > I don't think I can add any more to that. I think it is > reasonable and clear. It is but I'm not sure how this is relevant (I already agreed to add such documentation). -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

implicit_cast has been removed, but this is sad
by Jens Theisen 22 Mar '05

22 Mar '05

implicit_cast was once in cast.hpp, but as the comments says, it has been removed due to uncertain purpose. I have to purposes of which I am wondering how to do them otherwise: 1. take the address of the conversion 2. initialise a std::vector< int > with a boost::assign::list_of in a constructor initialiser The latter is a bit subtle. list_of uses a templated conversion operator to containers (but technically everything) and std::vector's ctor are then all tried with taking converted arguments, which leads into an ambiguity. Using implicit_cast solves the problem, since then the constructor call to std::vector and the call to the conversion operator in list_of are both taken as user defined conversions, and there can only be one of them. vector< int > v = list_of(1)(2); // works vector< int > v(list_of(1)(2)); // ambiguous ctor() : v(implicit_cast< vector< int > >(list_of(1)(2))) { } // ambiguous ctor() : v(list_of(1)(2)) { } // ambiguous Any thoughts on this? Regards, Jens

4 12

Re: [boost] Re: [review] hash functions
by brangdon＠cix.compulink.co.uk 22 Mar '05

22 Mar '05

In-Reply-To: <d1on4o$ijr$1(a)sea.gmane.org> daniel(a)calamity.org.uk (Daniel James) wrote (abridged): > > Admittedly hash_combine is also (nearly) redundant, being definable > > as: > > > > void hash_combine( size_t &hash, const T &t ) { > > hash_range( hash, &t, &t+1 ); > > } > > > > if T does not overload address-of. Note this is currently true because hash_range is defined as having the effect of: void hash_range( size_t &hash, It first, It last ) { for (; first != last; ++first) hash_combine( hash, *first ); } so calling hash_range on a range of 1 element returns the same result as calling hash_combine with that element. > Since nested vectors give different hash values to their flattened > form, I don't think a single element vector should have the same hash > values as it's element. It doesn't. One is: return hash_value( t ); the other is: size_t hash = 0; hash_combine( hash, t ); return hash; All the proposed definitions of hash_combine make these different. There is at least an xor, and possible a constant added. -- Dave Harris, Nottingham, UK

2 1

Re: [boost] Re: [review] hash functions
by brangdon＠cix.compulink.co.uk 22 Mar '05

22 Mar '05

In-Reply-To: <003501c52a54$a28c4b90$6601a8c0@pdimov> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > > size_t hash_value( int v ) { > > return size_t(v) + default_seed; > > } > > I wonder what do we gain from this. As you pointed out when I first suggested adding the constant in hash_combine: This would mean N fixes for a sequence of length N, when one simple fix is enough. The initial value of the seed is arbitrary so we can vary it at will. hash_combine, on the other hand, is based on research and has apparently been selected as one of the best amongst the shift+xor family. This doesn't mean that it's sacred, just that if we change it we'll no longer be able to just point at a PDF as a rationale but will need to do our own research (which might be a good idea anyway, though.) :-) > From the point of view of hash_combine the effect is the same The difference shows when you have something like: struct A { int x, y; }; struct B { A a, b, c; }; size_t hash_value( const A &a ) { size_t hash = 0xbead1; hash_combine( hash, a.x ); hash_combine( hash, a.y ); return hash; } size_t hash_value( const B &b ) { size_t hash = 0xbead2; hash_combine( hash, b.a ); hash_combine( hash, b.b ); hash_combine( hash, b.c ); return hash; } Here hash_combine is called 9 times, but hash_value(int) is only called 6 times, so we get different results depending on where the constant is added. > and we now rely on the user overloads of hash_value to not produce > a zero. That's surely reasonable. The hash_value of any user-defined class should be defined in terms of the hash_values of primitives, and boost provides all of those. > This reflects their intended use. The two argument overload is used > when one has a whole range and wants its hash value, as in the > hash_value overload for std::vector, for example. I actually think this is going to be fairly rare. This is mainly because there will usually be a constant thrown in to represent the type of the object. (I appreciate you won't do that for std containers, but I maintain its a good idea for user-defined types.) The 2-argument version is strictly redundant as it must be defined in terms of the 3-argument version. It's just a convenience function, used mainly by the std containers. Admittedly hash_combine is also (nearly) redundant, being definable as: void hash_combine( size_t &hash, const T &t ) { hash_range( hash, &t, &t+1 ); } if T does not overload address-of. Incidently, do you agree we will sometimes want to pass a hash value as the second argument to hash_combine? Like: hash_combine( hash, hash_range( first, last ) ); hash_combine( hash, obj.get_hash( some_arg ) ); If not, then maybe we should have a hash_combine that just combines hashes. At the moment the combining is mixed in with the getting; it's not a very orthogonal API. -- Dave Harris, Nottingham, UK

3 3

Re: [boost] Re: [review results] hash functions accepted
by brangdon＠cix.compulink.co.uk 22 Mar '05

22 Mar '05

In-Reply-To: <d1p2mg$mfk$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > There is a small utility in the Pointer Container library which is more > general that hash_ptr ect. You can simply say > > unordered_set< MyType*, indirect_fun< boost::hash<MyType> >, > > indirect_fun< std::equal<MyType set; > > for the rare cases where the index is a pointer. OK. It might be worth mentioning in the documentation. -- Dave Harris, Nottingham, UK

1 0

Re: [boost] Re: [review] hash functions
by brangdon＠cix.compulink.co.uk 22 Mar '05

22 Mar '05

In-Reply-To: <007b01c52ede$3ceefd80$6501a8c0@pdimov2> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > So, in my opinion, your original suggestion is still the best one, even > though I did not seem to agree at first. ;-) OK. > > If not, then maybe we should have a hash_combine that just combines > > hashes. At the moment the combining is mixed in with the getting; > > it's not a very orthogonal API. > > ... yes, hash_value( size_t ) is the identity function partly for this > reason. Cool. (And this is another argument for adding the non-zero fix in hash_combine rather than hash_value.) -- Dave Harris, Nottingham, UK

1 0

Re: [boost] Re: [review results] hash functions accepted
by brangdon＠cix.compulink.co.uk 22 Mar '05

22 Mar '05

In-Reply-To: <004c01c52edb$d07ee5e0$6501a8c0@pdimov2> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > > Is it worth considering using x + x / sizeof(*p) instead? > > This will not work for incomplete types, including void. Good point :-) > I'd prefer equal hash_values for an incomplete T*, complete T*, > and void* with the same value. Indeed. Presumably this means casting to void* eg for the case where sizeof(void*) != sizeof(char *). > We'll lose one potential bit of enthropy when alignof(x) == 16, but > this seems sufficiently rare in practice. I was a bit concerned about cases where the heap produces a de facto alignment. Especially if there is a different pool for each size of object, or a user-defined X::operator new() that allocates from a huge array of X. I guess it can't be helped. -- Dave Harris, Nottingham, UK

1 0

[Boost-bugs] [ boost-Bugs-1168431 ] LEDA graph adaptors do not handle hidden nodes properly
by SourceForge.net 22 Mar '05

22 Mar '05

Bugs item #1168431, was opened at 2005-03-22 10:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1168431&group_… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: LEDA graph adaptors do not handle hidden nodes properly Initial Comment: Hidden nodes are completely ignored by the LEDA graph adaptors. This may cause problems when, for instance, there are hidden nodes but the equivalent of vertex_index is used to construct a (BGL) property map. The LEDA adaptors should probably take the same approach as filtered_graph: let num_vertices() return the number of the nodes in the graph plus the number of hidden nodes, but vertices() filters out the hidden nodes. Similarly for edges. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1168431&group_… ------------------------------------------------------- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1168424 ] LEDA adaptors for node_array, edge_array
by SourceForge.net 22 Mar '05

22 Mar '05

Bugs item #1168424, was opened at 2005-03-22 10:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1168424&group_… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: LEDA adaptors for node_array, edge_array Initial Comment: LEDA has constructs similar to property maps, called node_array and edge_array, that allow the user to create external mappings from vertices or edges to user-defined data. Both classes are templated over the data type T. The BGL LEDA adaptors should provide a wrapper for these data structures to make them into property maps, so that LEDA graphs and LEDA's form of external property maps can be used with BGL algorithms. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1168424&group_… ------------------------------------------------------- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1168420 ] LEDA graph adaptors for undirected graphs
by SourceForge.net 22 Mar '05

22 Mar '05

Bugs item #1168420, was opened at 2005-03-22 10:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1168420&group_… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: LEDA graph adaptors for undirected graphs Initial Comment: The LEDA graph adaptors in the BGL seem to work properly for directed graphs (the LEDA type GRAPH<...>), but there are no corresponding adaptors for the undirected LEDA graph type (UGRAPH<...>). Undirected LEDA graphs follow a very different model than the undirected graphs in the BGL, which will require some special machinery. The LEDA type UGRAPH<...> is actually just a class derived from GRAPH<...> that applies the "make_undirected()" member function upon initialization. make_undirected() moves all of the in-edges of each vertex to the out-edges list. This has several unfortunate consequences: 1) The in-degree of an undirected LEDA graph is always zero, even when the out-degree is greater than zero. The in_edges list is therefore empty. 2) When traversing the list of out-edges for a vertex u, the edges returned may have u as their target but not their source. This breaks an important invariant in the BGL, which mandates that source(e, g)==u if e came from out_edges(u, g). Similarly for in-edges. Thus, an undirected LEDA graph adaptor will need to introduce special adaptors for the out_edge_iterator and in_edge_iterator types, which return a new edge_descriptor type for LEDA that can swap the source and target of a LEDA edge as needed. Additionally, graph-mutating operations (such as add_edge) may need to ensure that the graph remains undirected, as if make_undirected() had been called. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1168420&group_… ------------------------------------------------------- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1168411 ] adjacency_matrix should model BidirectionalGraph
by SourceForge.net 22 Mar '05

22 Mar '05

Bugs item #1168411, was opened at 2005-03-22 10:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1168411&group_… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: adjacency_matrix should model BidirectionalGraph Initial Comment: Class template adjacency_matrix should model the BidirectionalGraph concept. This will require the introduction of an in_edge_iterator that strides across the rows of the adjacency matrix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1168411&group_… ------------------------------------------------------- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] Re: [review results] hash functions accepted
by brangdon＠cix.compulink.co.uk 22 Mar '05

22 Mar '05

In-Reply-To: <d1na66$6p2$1(a)sea.gmane.org> daniel(a)calamity.org.uk (Daniel James) wrote (abridged): > > 5. change implementation of hash values for pointers so undefined > > behavior is gone (and consider adding x + (x >> 3) ) > > I'm going to do that. Is it worth considering using x + x / sizeof(*p) instead? -- Dave Harris, Nottingham, UK

2 1

Re: [boost] [review results] hash functions accepted
by brangdon＠cix.compulink.co.uk 22 Mar '05

22 Mar '05

In-Reply-To: <d1mq8d$b5q$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > 7. the hash_ptr<> suggestion is better done with general indirected > function Did I miss where this was discussed? To recap, we were talking about adding something like: template<typename T> struct hash_ptr { size_t operator()(const T *p) const { return hash_value( *p ); } }; template<typename T> struct equal_ptr { bool operator()( const T *a, const T *b ) const { return *a == *b; } }; to the hash library for use as, eg: unordered_set< MyType *, hash_ptr<MyType>, equal_ptr<MyType> > What do you mean by using a "general indirected function" instead? -- Dave Harris, Nottingham, UK

2 1

[filesystem] symbolic_link_exists naming AND is_file
by Jeff Garland 22 Mar '05

22 Mar '05

I'm writing a small program with filesystem and I needed to check for symbolic links so I can avoid processing them. I noticed the symbolic_link_exists method and, like all good programmers, didn't read the docs b/c I was sure it didn't do what I needed. So I set about writing a function that would and when I looked at the filesystem implementation I realized I was wrong. I was thinking that symbolic_link_exits would check that a symbolic link points to a valid file -- essentially following the symlink. Any reason why this funtion isn't called is_symlink to match the is_directory call? Also, in the code I'm writing I need to only process regular files. So it would be nice to write: if (is_file(my_path)) { //do stuff } where is_file is defined as follows: // equivalent of if (-d path) in perl // returns !is_directory(p) && !is_symlink(p); bool is_file(fs::path p); Or maybe it could be is_regular_file or is_plain_file if we want to be verbose. Seems like this would be handy to have in the filesystem lib. I can probably be talked into supplying patches ;-) Thoughts? Jeff

2 5

BOOST_CHECK_EQUAL again
by Stefan Slapeta 21 Mar '05

21 Mar '05

Hi, attached are the test cases for BOOST_CHECK_EQUAL on strings. I don't know which of the combinations are actually supported, but as you can see in the comments, it's quite mixed at the moment what does work and what not for Intel and VC. (the comments show failing test cases) Gennadiy, shall I add these test cases or are there some we definitely don't support? BTW, the (commented) results are for 1.32 as the code still doesn't work for Intel at all because of the numeric_limits problem! I tested with VC 7.1 and Intel 8.1. Cheers, Stefan #include <boost/test/test_tools.hpp> int test_main( int, char *[] ) { char const *buf_ptr_cch = "abc"; char const buf_array_cch[] = "abc"; char *buf_ptr_ch = "abc"; char buf_array_ch[] = "abc"; std::string buf_str("abc"); BOOST_CHECK_EQUAL(buf_ptr_cch, buf_ptr_cch); BOOST_CHECK_EQUAL(buf_ptr_cch, buf_array_cch); BOOST_CHECK_EQUAL(buf_ptr_cch, buf_ptr_ch); // VC BOOST_CHECK_EQUAL(buf_ptr_cch, buf_array_ch); BOOST_CHECK_EQUAL(buf_ptr_cch, buf_str); BOOST_CHECK_EQUAL(buf_array_cch, buf_ptr_cch); BOOST_CHECK_EQUAL(buf_array_cch, buf_array_cch); BOOST_CHECK_EQUAL(buf_array_cch, buf_ptr_ch); // VC+Intel BOOST_CHECK_EQUAL(buf_array_cch, buf_array_ch); // Intel BOOST_CHECK_EQUAL(buf_array_cch, buf_str); BOOST_CHECK_EQUAL(buf_ptr_ch, buf_ptr_cch); // VC BOOST_CHECK_EQUAL(buf_ptr_ch, buf_array_cch); // VC+Intel BOOST_CHECK_EQUAL(buf_ptr_ch, buf_ptr_ch); BOOST_CHECK_EQUAL(buf_ptr_ch, buf_array_ch); // VC+Intel BOOST_CHECK_EQUAL(buf_ptr_ch, buf_str); BOOST_CHECK_EQUAL(buf_array_ch, buf_ptr_cch); // Intel BOOST_CHECK_EQUAL(buf_array_ch, buf_array_cch); // Intel BOOST_CHECK_EQUAL(buf_array_ch, buf_ptr_ch); // VC+Intel BOOST_CHECK_EQUAL(buf_array_ch, buf_array_ch); BOOST_CHECK_EQUAL(buf_array_ch, buf_str); BOOST_CHECK_EQUAL(buf_str, buf_ptr_cch); BOOST_CHECK_EQUAL(buf_str, buf_array_cch); BOOST_CHECK_EQUAL(buf_str, buf_ptr_ch); BOOST_CHECK_EQUAL(buf_str, buf_array_ch); BOOST_CHECK_EQUAL(buf_str, buf_str); return 0; }

2 3

RE: [boost] Re: google going open source
by Brian Braatz 21 Mar '05

21 Mar '05

Just quickly- I am making good progress on app integration and adding to the Profiler library by Chris Diggins. I will be mailing out more info in the next few weeks. Additionally- a quick look at below looks like it would be something that would add value to profiler lib. I plan on taking a deeper look at that and will report back what I see. I want to REALLY spend some time with below to understand it better\ see how it could fit in with current profiler being worked on. THANK YOU for sending this out, very interesting.... > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Martin Wille > Sent: Friday, March 18, 2005 12:50 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: google going open source > > Thorsten Ottosen wrote: > > "Bronek Kozicki" <brok(a)rubikon.pl> wrote in message > > news:4239ED44.5090508@rubikon.pl... > > | under BSD 2.0 license > > | http://code.google.com/ > > | > > > > Hm...would anyone volenteer to boostify > > https://sourceforge.net/projects/goog-perftools/, > > Can't be done, due to the license. > > Regards, > m > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Mersenne Twister seed fix
by Daniel van der Zee 21 Mar '05

21 Mar '05

I was wondering if the fix to mersenne twister as suggested in http://lists.boost.org/MailArchives/boost/msg78304.php made it into the random number library for the next release. Thanks, Daniel

1 0

RE: [boost] Re: google going open source
by Brian Braatz 21 Mar '05

21 Mar '05

I would also like to request anyone who looks at this or spends time with it share on the list what they have learned. So far, it looks like it is gcc only as shipped, so porting is one area that needs analysis > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Brian Braatz > Sent: Monday, March 21, 2005 9:22 AM > To: boost(a)lists.boost.org > Subject: RE: [boost] Re: google going open source > > Just quickly- I am making good progress on app integration and adding to > the Profiler library by Chris Diggins. > > I will be mailing out more info in the next few weeks. > > Additionally- a quick look at below looks like it would be something > that would add value to profiler lib. I plan on taking a deeper look at > that and will report back what I see. I want to REALLY spend some time > with below to understand it better\ see how it could fit in with current > profiler being worked on. > > THANK YOU for sending this out, very interesting.... > > > > -----Original Message----- > > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] > > On Behalf Of Martin Wille > > Sent: Friday, March 18, 2005 12:50 AM > > To: boost(a)lists.boost.org > > Subject: Re: [boost] Re: google going open source > > > > Thorsten Ottosen wrote: > > > "Bronek Kozicki" <brok(a)rubikon.pl> wrote in message > > > news:4239ED44.5090508@rubikon.pl... > > > | under BSD 2.0 license > > > | http://code.google.com/ > > > | > > > > > > Hm...would anyone volenteer to boostify > > > https://sourceforge.net/projects/goog-perftools/, > > > > Can't be done, due to the license. > >

1 0

[filesystem] include_pathes?
by David Abrahams 21 Mar '05

21 Mar '05

Seems to me that this should be "include_paths," no?? -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 5

How much should I care about allocators?
by Dan Rosen 21 Mar '05

21 Mar '05

Hi all, I'm in the process of putting together my own submission for a boost::tree<>, which has been discussed here on occasion before. Without getting into much detail about the tree itself, I have two nuts-and-bolts questions about conventions using allocators in containers. First: The standard allocator concept has several distinct typedefs: "value_type", "pointer", "reference", etc. My understanding is that the main motivation for allocators was the necessity to abstract out differences in pointer types on different platforms. So I assume this implies that to use an allocator properly, one can't necessarily expect that "pointer" is identical to "value_type*". I hope this assumption is correct so far. What I take this to further imply is that in my container, I need to write code of this nature: template <typename T, typename A = std::allocator<T> > class tree { public: typedef A allocator_type; typedef typename A::value_type value_type; typedef typename A::pointer pointer; typedef typename A::reference reference; // etc. private: class node_t; typedef typename A::template rebind<node_t>::other node_allocator; typedef typename node_allocator::value_type node; typedef typename node_allocator::pointer node_pointer; class node_t { pointer t_; node_pointer parent_; // etc. }; // etc. }; In other words, to respect the allocator I've been given, I need to make sure my internal node structure uses the rebound node allocator's pointer and value types, and so forth. So my first question is, is this assumption correct? The reason I ask is that looking over the standard library implementation that comes with gcc 4.0, I noticed that their implementation of std::list<> has nodes which contain straight pointers, rather than the allocator typedef equivalents. To me that seems to contradict my assumption, assuming the gcc implementation is correct. My second question is about allocator's construct() method. The implementation of std::allocator has construct() invoking the copy ctor using placement new(). That much is self-explanatory. It also seems reasonable to me that allocator does not have construct() methods taking arbitrary parameters. But I'm not sure I understand the reason why it does not have a construct() method to invoke an object's default ctor. What that implies to me, and seems to be supported by gcc's list implementation, is that the nodes in my tree mustn't have a default ctor that actually does anything, because the only way to properly initialize objects using an allocator is through copying. Is that correct? What this boils down to is, using allocators seems to dictate some aspects of how I design and implement this tree (or any container). So how much should I strive to operate within their limitations, and am I understanding these limitations correctly? I hope this is an appropriate forum for these questions. Thanks very much, dr

1 0

[Post review] Pointer Container
by Thorsten Ottosen 20 Mar '05

20 Mar '05

Dear all, The Pointer Container library is very almost finished. Since the review, the following major changes has been made - improved docs with new tutorial and improved browsing - new indirect functions - new Cloneable and Clone Allocator concepts - support for null values - refactored template interface off all classes - implementation guarantees to only instantiate std::container<void*> - rewritten iterators - improved tests The new docs, and code can be downloaded from the files section: http://groups.yahoo.com/group/boost/files/pointer%20container/ptr_container… The test runs with vc7.1 and gcc.3.3.3. Comments, suggestions and portability fixes are welcome. There are one major issue and one minor I need to have resolved during the post-review. Minor issue: allocation in map:operator[] ---------------------------------------- should a default allocated object use operator new or heap_clone_allocator::allocate_default(); ? This happens in ptr_map<string,int> m; m["foo"] = 5; // will allocate an int with new Normally the use can control all allocations because he always add objects manually or via cloninin (which he also controls). But the default object is just allocated with operator new inside ptr_map::operator[]. Should some hook be provided in a new allocator concept, map_heap_allocator? Major issue: ptr_iterator implementation. ----------------------------------------- So what is the problem? Well, since void* is used internally, the iterators must cast to the proper type in operator*; that is no problem for the default indireted iterators; the problem is with the iterators from ptr_iterator ptr_begin(); ptr_iterator ptr_end(); One way to define would be to say typedef internal_container::iterator ptr_iterator; Then the reference type would be void*& and not T*& as we would like. So if the user wanted to sort the container, he would do std::sort( cont.begin(), cont.end(), void_ptr_indirect_fun< std::less<T>, T>() ); This give us a rather insecure interface where you have to cast manually to T* inside the functor. So I wish we could get a T*& reference type. I think, from discussion with David Abrahams, that the current implementation is non-portable even though my test works: typedef T*& reference; reference dereference() const { // void_type is void* or const void* // I'm not sure why this is needed, but it seems to be return reinterpret_cast<reference>( const_cast<void_type&>( *iter_ ) ); } Does anybody knows how to rewrite this crappy code propoerly? I think we're faced with three options 1. keep the current behavior and describe in the docs that it is non-portable 2. go back to making ptr_iterator the default iterator with void*& reference type; 3. add a small subset of algorithms to the classes themselves; I'm thinking that the subset from std::list is appropriate: - sort - remove_if - remove - unique - reverse - merge Let me hear what you think best regards -- Thorsten Ottosen ---------------------------- www.dezide.com www.cs.aau.dk/index2.php?content=Research/bss www.boost.org www.open-std.org/JTC1/SC22/WG21/

2 4

[FSM library] review result: accepted with few conditions
by Pavel Vozenilek 20 Mar '05

20 Mar '05

FSM library written by Andreas Huber has been accepted into Boost, with few conditions and few recomendations. Thanks, Andreas, for your work and stamina to get thus far! Also thanks to all courageous reviewers. Short overview: =============== Opinions of reviewers were mixed. Large group liked the library, some even used it in production code. Other large group had objections Most questioned were performance and API. At the end my opinion is: no single perfect fit exists so it makes little sense to dismiss this library waiting for a hypothetical everyone-is-happy solution. Other variant was to ask for changes and for second review later. FSM is mature, has been developed for years and will be maintained in the future: its not likely such solution would make much of good for end result. Conditions: 1. Name of the library should be changed: - not to suggest that only one FSM implementation may exists in Boost - not to give wrong impression to people who look for tool with maximal runtime efficiency. - to stress the "high-level" nature of the library Names suggested during review were Statechart (by Alexander Nasonov) and umlfsm. 2. Information about performance overhead should be separated into page of its own and made clearly visible. Recomendations: 3. API of the library should be simplified as much as possible. Quirks and dangerous situations should be eliminated as much as possible. 4. The documentation should be improved as much as possible. 5. Runtime overhead should be decreased as much as feasible but without sacrifying currently available features of the library. Detailed information: ===================== 1. Name of the library should include change of namespace as well. 2. The information about runtime overhead. Separate page should be created and made visible on front page. It should contain examples of applications where FSM may not be the best solution (e.g. parsers). 3. API of the library, quirks and features. People asked many ways to simplify the API and increase orthogonality of its features: - the danger in using transit<> should be eliminated (Jonathan Turkanis suggested way how to do it) - the syntax to add deferred event should be cleaned up, even it it adds overhead - similarly posting events from inside FSM: if there's chance to make its syntax easier it should be done (no matter what IMHO) - reducing # of template parameters for state, possibly putting reactions as typedef inside state - it was suggested (by Daryl Green) to deduce reaction-list by examination of class interface - polymorphic events may be added for completeness (Peter Petrov found workaround but it may be better to do it right) - add handling of unknown events - custom allocator for FSM used for all states constructed in it. Perhaps it is possible to detect presence of overloaded operator new in state and it if doesn't exist then use state_machine allocator - not using containers keeping historical data when history feature is not used - possibility to use flyweight classes for states or class factories to create states - eliminate need for mpl::list for history parameter - description of transition guards in header was requested (perhaps it may be optional feature) Whether the library should separate its asynchronous part out was not discussed much. I guess it is better to keep it in and possibly submit it as standalone library. 4. Documentation. Among suggested improvements were: - better indentation in code snippets, inlined comments, syntax highlighting - adding complete examples to code snippets so users can try immediatelly - more information for error handling and asynchronous FSMs - reduce the radius of big black dots for initial states - external documents describing UML mapping should be more visible - avoiding forward declarations of events in code snippets - more examples (e.g. half-adder used twice to create a full-adder, suggested by Dave Gomboc, combination of synchronous and asynchronous machines) The documentation is now very dense, splitting it into smaller parts may help. More hyperlinking would also help a lot. The documentation may contain page "How to" with tricks, workarounds and non-obvious examples of use. For example how to use nested state to keep data related to inner states. I think adding UML and/or FSM tutorial in documentation is not task if this library. 5. Runtime overhead. Best effort should be made but only after stabilizing features and API. Reducing executable code size (per state/transition) may be the first direction here. ------------------------------- I hope that alternative FSM implementations (like the one currently developed by Alexander Nasonov) or dynamic FSM will appear and will be submitted to Boost as well. /Pavel

3 3

[fsm] Outstanding answers to review questions
by Andreas Huber 20 Mar '05

20 Mar '05

It seems I have finally managed to answer all the questions. In case someone is still waiting for answer, please let me know. Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0