- Boost-users - lists.preview.boost.org

RE: [Boost-Users] Re: [BGL] Best way to abort an algorithm from w ithi n a visitor?
by Mark Storer 19 Sep '02

19 Sep '02

>Using the Boost library as it currently stands, >it appears the best way to abort the algorithm >is to throw an exception. Granted. I'd even go so far as to say "the only way" (based on my vast experience... I've actaully vistor's code once). >Whether or not throwing an exception is >acceptable from a general programming standpoint >is a topic more suited to a general C++ >discussion list Any recommendations? Preffereably something with an archive/FAQ so we don't drag up Holy War #42... --Mark Storer Software Engineer Cardiff Software #include <disclaimer> typedef std::disclaimer<Cardiff> Discard;

1 0

RE: [Boost-Users] Re: [BGL] Best way to abort an algorithm from w ithi n a visitor?
by Jim.Hyslop 19 Sep '02

19 Sep '02

Mark Storer [mailto:mstorer@cardiff.com] wrote: > If Boost's source were a closed book, and the only option was > to throw an > exception, then so be it. But that is not the case. On that note, I'm going to bring this thread back to discussion of how to use the current Boost library. Using the Boost library as it currently stands, it appears the best way to abort the algorithm is to throw an exception. Whether or not throwing an exception is acceptable from a general programming standpoint is a topic more suited to a general C++ discussion list (if anyone decides to take it there, let me know - I'd like to follow it). Whether or not to add a return value to the BGL is a topic more suited to the main Boost mailing list. -- Jim

1 0

RE: [Boost-Users] Re: [BGL] Best way to abort an algorithm from w ithi n a visitor?
by Mark Storer 19 Sep '02

19 Sep '02

In general, I agree that taking personal issue with the use of some language feature is a little silly. In specific, I'm going to disagree with you both for exceptions and the whole do{}while(0) thang. I'm sitting next to my copy of Stroustrup's "The C++ Programming language" (2nd edition). Chapter 9 covers exceptions. This chapter makes it clear that the purpose of exceptions is to handle errors: " The fundamental idea is that a function that finds a problem that it cannot cope with /throws/ an exception, hoping that its (direct or indirect) caller can handle the problem. " Same thing with the do{}while(0) construct. Using a loop as an error handler is quite similar. One could argue that a break is far more efficient than a throw. A counter-argument is that the throw carries a great deal more information about what went wrong. Once the excreta impacts the air-pusher-thingy, speed becomes a secondary concern (far more often than not). If you want to abort a function due to an error then throw an exception. If you want to return a value then do so. And while using a language feature for something other than its original intent is not criminal, there are usually 'proper' ways to do things already built into the language, ways that often work better than subjecting some poor unsuspecting feature to your vile, unnatural manipulations. <Dudly Do-Right>You fiend!</Dudly Do-Right> In the case that brought all this up (returning a value from a graph's visitor to avoid iterating through the whole graph) the proper way to handle it is to alter the algorithm to allow for early termination. If Boost's source were a closed book, and the only option was to throw an exception, then so be it. But that is not the case. So do it right... as Chris Russell (the original poster) has decided to do. --Mark Storer Software Engineer Cardiff Software #include <disclaimer> typedef std::disclaimer<Cardiff> Discard; -----Original Message----- From: Peter Dimov [mailto:pdimov@mmltd.net] Sent: Thursday, September 19, 2002 9:20 AM To: Boost-Users(a)yahoogroups.com Subject: Re: [Boost-Users] Re: [BGL] Best way to abort an algorithm from withi n a visitor? From: "Mark Storer" <mstorer(a)cardiff.com> > Using exceptions in this way just bugs me. Religious reasons I guess. As > the Esteemed Mr. Hylsop ;) mentioned earlier, exceptions are for "oops". > This seems alot like the whole "do{}while(0)" with various 'break' > statements sprinkled in to avoid multiple returns/nested ifs. Useful, but > Just Not Right. A common misconception. Many people try to project their own ideas/expectations on language features, rather than simply using them as tools where appropriate. There is nothing "oops"-y about exceptions. They are a control flow mechanism; one that has interesting properties, but a control flow mechanism nonetheless. If it works and leads to a better code, it's foolish to avoid it without a technical reason. A similar example is when people don't use "struct" for C++ classes because it "doesn't feel right", or when trying to choose between "typename" and "class" for template parameters. The language features simply do not carry this kind of religious/emotional payload. It's all in your mind. Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

2 1

RE: [Boost-Users] Re: [BGL] Best way to abort an algorithm from w ithi n a visitor?
by Garriss, Michael 19 Sep '02

19 Sep '02

I agree. I hate to see the return -1 (for example) on some "exceptional" case in a function when an exception makes more sense. It's not necessarily an "oops" case, it's an "exception." Either way the caller has to check the special case. There is a good reason that exceptions are named exceptions and not errors. Mike Garriss -----Original Message----- From: Peter Dimov [mailto:pdimov@mmltd.net] Sent: Thursday, September 19, 2002 10:20 AM To: Boost-Users(a)yahoogroups.com Subject: Re: [Boost-Users] Re: [BGL] Best way to abort an algorithm from withi n a visitor? From: "Mark Storer" <mstorer(a)cardiff.com> > Using exceptions in this way just bugs me. Religious reasons I guess. As > the Esteemed Mr. Hylsop ;) mentioned earlier, exceptions are for "oops". > This seems alot like the whole "do{}while(0)" with various 'break' > statements sprinkled in to avoid multiple returns/nested ifs. Useful, but > Just Not Right. A common misconception. Many people try to project their own ideas/expectations on language features, rather than simply using them as tools where appropriate. There is nothing "oops"-y about exceptions. They are a control flow mechanism; one that has interesting properties, but a control flow mechanism nonetheless. If it works and leads to a better code, it's foolish to avoid it without a technical reason. A similar example is when people don't use "struct" for C++ classes because it "doesn't feel right", or when trying to choose between "typename" and "class" for template parameters. The language features simply do not carry this kind of religious/emotional payload. It's all in your mind. Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=234081.2377872.3808768.2225242/D=egroupweb/S=17050067 88:HM/A=1225247/R=0/*http://ad.doubleclick.net/clk;4547223;7007303;y?http:// www.ameriquestmortgage.com/welcome.html?ad=Yahoo01> <http://us.adserver.yahoo.com/l?M=234081.2377872.3808768.2225242/D=egroupmai l/S=:HM/A=1225247/rand=147617524> Info: < http://www.boost.org <http://www.boost.org> > Wiki: < http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> > Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . [Non-text portions of this message have been removed]

1 0

lambda lib & mingw gcc 2.95.2?
by Mynhard Rudolph 19 Sep '02

19 Sep '02

Hi all Does the lambda library compile under mingw with gcc 2.95.2? I'm a newbie and I can't figure out what's wrong with the following test example: #include <boost/lambda/bind.hpp> #include <boost/lambda/lambda.hpp> using namespace boost; using namespace boost::lambda; struct A { int d; }; int main (int argc, int argv[]) { A* a = new A(); int b = (a ->* &A::d); int c = (_1 ->* &A::d)(a); return c - b; } g++ test.cpp -Wall -Ix:/boost_1_28_0/ -D__PROCESSOR_X86__ -D__WIN32__ -D__GCC__ -o test.o test.cpp: In function `int main(int, int *)': test.cpp:12: no match for `const boost::lambda::lambda_functor<boost::lambda::pl aceholder<1> > & ->* int A::*' make: *** [test.exe] Error 1 Would appreciate any clues. ;-) Mynhard

2 3

RE: [Boost-Users] [BGL] Best way to abort an algorithm from withi n a visitor?
by Mark Storer 18 Sep '02

18 Sep '02

If efficiency is your goal, exceptions are not the answer. Just enabling exceptions at compile time makes a noticable performance hit. Actually throwing an exception can gobble up a 1000 cycles, give or take. That's per throw. If you catch and throw again, you'll pay again. Now if you've got more than a hundred or so entries left to go, exceptions really are the greener grass. What's wrong with 'return', perhaps along-side some sort of 'done' status variable? I'm only vaguely familiar with the vistor pattern, but these would seem to be the obvious choice. --Mark Storer Software Engineer Cardiff Software #include <disclaimer> typedef std::disclaimer<Cardiff> Discard;

2 1

[BGL] Best way to abort an algorithm from within a visitor?
by Chris Russell 18 Sep '02

18 Sep '02

Is there a way to abort an algorithm while it's processing? Can I throw an exception out of a visitor method? I have a case where I need the algorithm to crunch on a large graph until some condition dependent on property data is reached. If and when the condition is met, I would like to skip the processing of the remaining vertices/edges and save the cycles. Does using exceptions sound like a reasonable approach? - Thanks Chris P.S. Thanks for the help with properties and property maps the other day. I cleaned up my code and eventually tracked the source of my considerable confusion to a bug in an operator= defined on the object that I'm using as an internal property. This bug manifested itself by re-initializing previously set data seemingly at random >8|-~ Arg... My bad.

2 2

RE: [Boost-Users] [BGL] Best way to abort an algorithm from withi n a visitor?
by Jim.Hyslop 18 Sep '02

18 Sep '02

Steve M. Robbins [mailto:steven.robbins@videotron.ca] wrote: > I use that technique to abort the Dijkstra shortest path > search when I find my > goal node. It works fine, as far as I can tell, but I'd be > interested to > learn if there is a better way. It seems anti-idiomatic to me. Exceptions are intended to signify exceptional circumstances that you would not normally expect to encounter (at least according to one school of thought). An exception tells me "Oops, something went wrong here" not "we succeeded, here's the answer". Many of the exceptions I catch are called "oops": try { /* ... */ } catch (std::exception &oops) { /* ... */ } One possible snag might be if your code interacts with someone else's code, which will catch the exception and not pass it on to you. In the context we're talking about, though, I don't see that as a significant problem. An exception is certainly an easy way to abort the search, and since I don't have an alternative to offer, I'll shut up now ;=) -- Jim

2 1

Levenshtein Distance algorithm
by Philippe Lalande 18 Sep '02

18 Sep '02

Hi, I was wondering if anyone could tell me if Boost contains a function that could perform a 'Levenshtein distance' calculation on a sequence. The Levenshtein distance is a measure of the similarity between two strings calculated as the number of deletions, insertions, or substitutions required to transforms the source string to the target string. IMO, it is an interesting algorithm that could apply to any kind of sequence. I'd be happy to discuss interface and implementation on the dev list if such algorithm does not exist yet. Thank you Philippe

2 1

RE: [Boost-Users] Re: Newbie needs help w/VC6 & filesystem (take 2)
by Jim.Hyslop 18 Sep '02

18 Sep '02

John B. Williston [mailto:yg-boost-users@gmane.org] wrote: > On Tue, 17 Sep 2002 12:40:53 -0400, Douglas Gregor <gregod(a)cs.rpi.edu> > wrote: > > >Could you copy 'n' paste some of the link errors you are > getting? It seems > >like you did the right thing (at least, I don't know of a > better way), but > >perhaps knowing what symbols are being redefined would help > isolate the > >problem. > > I sure can. The following is the compile output: > > --------------------Configuration: TestFs - Win32 > Debug-------------------- > Compiling... > Main.cpp > Linking... > LINK : warning LNK4075: ignoring /INCREMENTAL due to /FORCE > specification > msvcprtd.lib(MSVCP60D.dll) : warning LNK4006: "public: __thiscall > [...] already > defined in Main.obj; second definition ignored I've typically found these errors when you have mixed the run-time library usage, or MFC usage. One part of your project wants to link in the C run-time library as a DLL, but another part of your project wants to link it in as a static library. Make sure that all the projects, including the ones that build any libraries you're linking with, use the same "Use runtime library" option (Project | Settings, "C/C++" tab, "Code Generation" category), and also that all projects use the same "Microsoft Foundation Class" option (on the General tab). -- Jim

2 1