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

Regex and Unicode
by Fr�d�ric Mayot 20 Sep '02

20 Sep '02

Hi, I'm trying to use Unicode with Regex in an MFC app. The preprocessor variable UNICODE is defined. But I obtain an error on the line : regex_search(sText, oResults, pRegExp); error C2665: none of the 4 overloads can convert parameter 1 from type 'class CString' sText is a CString which has a "const wchar_t*" operator. The problem is why doesn't the regex_search prototype require a "const wchar_t*" when UNICODE is defined ? Thanks. Fred (I read the documentation, but maybe I missed something...)

2 3

BJam output directories on NT
by yg-boost-users＠m.gmane.org 20 Sep '02

20 Sep '02

Building my application using msvc-stlport. I've set ALL_LOCATE_TARGET=d:/src/pegdevbin/build. During processing, the paths get too deep for NT and eventually the mkdir fails and then of course the build stops. Anyway to shorten the deep paths that are automatically created or should I start chopping up allyourbase.jam? I won't be doing any build variants on a per platform basis so I don't need the deep paths that specify the various options in effect. Thanks for the help (and all the great work too...) Rob

1 0

RE: [Boost-Users] Re: Borland C++ Builder 5.5 & scoped_ptr
by Mark Storer 19 Sep '02

19 Sep '02

>>Are you saying that if I switch from >> scoped_ptr to shared_ptr the destructor will get called? Is he saying that the destructor is NOT getting called with scoped_ptr? (!) --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 11:07 AM To: Boost-Users(a)yahoogroups.com Subject: Re: [Boost-Users] Re: Borland C++ Builder 5.5 & scoped_ptr From: "Brian" <bneal(a)zeus.ia.net> > --- In Boost-Users@y..., "Gennadiy E. Rozental" <rogeeff@m...> wrote: > > This was discussed during Boost.Test review. > > Peter some time ago made a changes in boost::shared_ptr that allows > > it to be used with Borland 5.5 namely in the situation you > described. > > > > Gennadiy. > > Hi...could you clarify this? All I noticed was that shared_ptr had > that compile time check for an incomplete type removed, whereas > scoped_ptr still has it. Are you saying that if I switch from > scoped_ptr to shared_ptr the destructor will get called? Yes, shared_ptr will call the destructor. It only requires a complete type at construction time. 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 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