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

Boost Python error handling
by cseymour＠interchange.ubc.ca 19 Aug '02

19 Aug '02

Here is a sample program which shows the problem i've been having (posted in earlier messages). When I import the module "sample" and run the function test(), I get the following output: This is a test Raising an error Aborted When I should get a message saying it caught the error, and then a Python error, instead of it Aborting and quitting Python. /* sample.c */ #include "Python.h" #include "boost/python/class_builder.hpp" namespace py = boost::python; void test() { std::cout << "This is a test" << std::endl; std::cout << "Raising an error" << std::endl; PyErr_SetString(PyExc_TypeError, "This is the error"); throw py::argument_error(); } BOOST_PYTHON_MODULE_INIT(sample) { try { py::module_builder this_module("sample"); this_module.def(test, "test"); } catch (...) { std::cout << "Caught an error" << std::endl; py::handle_exception(); } }

1 0

Newbie and shared_ptr
by Ian Mold 19 Aug '02

19 Aug '02

I have been looking at the shared_ptr class, and I have made a change to include an assignment from a standard pointer. I have done this so that I don't have to create a new shared_ptr just to reassign an existing shared_ptr. // Assignment to a 'normal' pointer. shared_ptr & operator=(T * r) { this_type(r).swap(*this); return *this; } I have a few questions. 1) Is this necessary? 2) Does this do the job? 3) Is there any reason this wasn't included in the first place? I welcome any comments. Regards, IanM

3 2

BGL: Loops in undirected graph
by Tarjei Knapstad 19 Aug '02

19 Aug '02

Is there any "standard best way" of detecting loops in an undirected graph? I had a look at chapter 4.2 in the book (which does an implementation for bidirectional graphs), and tried to adapt this implementation, but with no particular luck :) The graph I've set up in my test suite looks like this (I hope my mail prog. doesn't screw up the formatting) H15 | H8 C2 \ / \ H9-C0-C1 C3-O7-H14 / | | H10 C6 C4 / \ / \ H11 C5 H13 | H12 I'm working with molecules, so the letters denote the type of atom, but that's of no importance here. The numbers are the vertex descriptors. What I'm trying to create is an algorithm that will return the set of vertices [1, 2, 3, 4, 5, 6] defining. Now, my first step is (exactly like in the book) to record every back edge in the graph. As my graph is undirected, and there is allways a path from any one vertex to any other vertex, I thought I could just do a DFS from the first vertex in any such graph and record the back edges. In the above example, starting from 'C0', I'd expect the set of back edges obtained from a DFS to be 1-2, 2-3, 3-4, 4-5, 5-6 and 6-1, a total of 6 edges. The actual result obtained however also includes the following edges: 1-0, 11-6, 12-5, 13-4, 7-3, 14-7, 15-2, 8-0, 9-0 and 10-0. Why is this? I'm assuming there's something I missed out on, regarding graph theory and how the basic DFS works, but I cannot see any logic in this. If so, how could I modify my DFS visitor to record the (in my problem domain) "correct" back edges? This problem also gives me further trouble when trying to detect which vertices are part of each cycle. Does any of you have any suggestion for an effective implementation of the "find vertices that are part of each cycle" part of the algorithm? Any help appreciated. Cheers, -- Tarjei Knapstad

2 4

boost::function/bind Usage Again
by Albrecht Fritzsche 19 Aug '02

19 Aug '02

Here I want to extend simple callbacks so that these callbacks take an argument void fun(int i) { std::cout << "Hi fun " << i << std::endl; } struct Foo { void bar(int i) { std::cout << "Hi bar " << i << std::endl; } }; template <class Value> struct CallFunction { CallFunction(const Value& v) : mValue(value) {} // defined outside void operator()(const boost::function<void, Value>& fun) { if (fun) fun(mValue); } const Value& mValue; }; int main() { std::vector< boost::function<void, int> > funs; Foo foo; funs.push_back(&fun); funs.push_back(boost::bind(&Foo::bar, &foo, _1)); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ int value = 7; std::for_each(funs.begin(), funs.end(), CallFunction<int>(value)); return 0; } Is this the right usage of the /_1/ here? This code runs (at least on my machine:-), but I'm quite unsure about this place holder. And since the online docu... Ah, now I see - in the online doc there are some links missing. In the files section not only the bind_template.hpp link refers to that very file but also the arg.hpp and placeholders.hpp links and many more. Having checked now the sources makes not everything clear, but at least clearer. So, I would be happy if anyone could let me know if my usage includes some misuse etc... Thanks Ali

3 2

Using gcc's typeof and boost.lambda together.
by Matthew Dempsky 19 Aug '02

19 Aug '02

I was just playing around with the boost.lambda library and thought of playing a bit with it using gcc's typeof extension... this is the code I used (just slightly modified documentation code): typedef typeof(_1 = 1) assign_one; list<int> v(10); for_each(v.begin(), v.end(), assign_one()); I was hoping it would work the same as the documentation's code, but instead it generates a few big errors about lambda_functor_base<...>::lambda_functor_base() not existing. I know typeof is a gnu extension and it's not really portable to use it in code, but does anyone have any ideas of how to get something like this to work correctly? -jivera

2 1

bug in regex 3.31 (boost 1.28)?
by emarkp 19 Aug '02

19 Aug '02

I sent this originally to James Maddock, but realized this is probably a better place to post it. At work we've been testing out regex (nice work BTW) in some of our code, and appear to have found a bug. We ran into it parsing HTML, and I've written a test C++ app to reproduce it. In the program below, the output should be the same for both searches as far as I can tell, but it's not. I don't know if it's some interaction with the quote character or something like that. We attempted to use other quantifiers (after '?', we tried '*', '{0,1}', ["]?) to no avail. I'm confident this is not user error. The extra grouping is annoying (in "goodPatternStr"), but is an acceptable workaround. The strange thing is that a non-capturing group doesn't fix it. Ideas? --Mark Ping -------------------------------------------------------------------------------------- output: input: <input type="hidden" name="MfcISAPICommand" value="SellYourItem" badOut :<input type="hidden" name="MfcISAPICommand" value="SellYourItem badOutName : badOutValue:SellYourItem goodOut :<input type="hidden" name="MfcISAPICommand" value="SellYourItem goodOutName :MfcISAPICommand goodOutValue:SellYourItem Press any key to continue -------------------------------------------------------------------------------------- #include <iostream> #include <string> #include <boost/regex.hpp> using namespace boost; using namespace std; int main() { const char* badPatternStr = "<input[^>]*name=\"?([^> \"]*)[^>]*value=\"?([^> \"]*)"; const char* goodPatternStr = "<input[^>]*name=(\"?)([^> \"]*)[^>]*value=\"?([^> \"]*)"; // ^^^^^ //note that the only difference between bad and good is that "good" //has grouping around the optional " after 'name=' // //In both versions of the matches, the second group is matched. //Only the first group has this problem. boost::match_results<std::string::const_iterator> what; std::string in = "<input type=\"hidden\" name=\"MfcISAPICommand\" value=\"SellYourItem\""; std::string::const_iterator start, end; start = in.begin(); end = in.end(); unsigned int flags = boost::match_default; std::string badOut, badOutName, badOutValue; if(regex_search(start, end, what, regex(badPatternStr), flags)) { badOut = what[0]; int numGroups = what.size(); // name badOutName = what[1]; badOutValue = what[2]; } std::string goodOut, goodOutName, goodOutValue; if(regex_search(start, end, what, regex(goodPatternStr), flags)) { goodOut = what[0]; int numGroups = what.size(); // name goodOutName = what[2]; goodOutValue = what[3]; } cout << "input: "; cout << in << endl << endl; cout << "badOut :" << badOut << endl; cout << "badOutName :" << badOutName << endl; cout << "badOutValue:" << badOutValue << endl; cout << endl; cout << "goodOut :" << goodOut << endl; cout << "goodOutName :" << goodOutName << endl; cout << "goodOutValue:" << goodOutValue << endl; return 0; }

2 5

RE: [Boost-Users] detail/lightweight_mutex.hpp
by Tom Matelich 17 Aug '02

17 Aug '02

> From: Tom Matelich [mailto:tmatelich@zetec.com] > > From: Peter Dimov [mailto:pdimov@mmltd.net] > > From: "Tom Matelich" <tmatelich(a)zetec.com> > > > I'm attempting to go to Boost 1.28 on our HPUX 10.20 boxes. > > I've run into > > a > > > problem with an assumption about the type of pthread_mutexattr_t. > > > detail\lwm_pthreads.hpp calls: > > > > > > pthread_mutex_init(&m_, 0); > > > > > > HP's pthread.h (10.20 uses DCE) has that defined as: > > > > > > int pthread_mutex_init (pthread_mutex_t *,pthread_mutexattr_t); > > > > I don't know what to do about it. My POSIX draft says > > > > int pthread_mutex_init(pthread_mutex_t *restrict mutex, const > > pthread_mutexattr_t *restrict attr); > > > > and goes on to specify that 0/NULL for the second argument > > causes default > > attributes to be used. > > > > I know little - if anything - about HPUX 10.20; if you find a > > solution let > > me know, and I'll incorporate it into lwm_pthreads.hpp. Sorry. > > > > The dce documentation I see says to use pthread_mutexattr_default. > http://www.transarc.ibm.com/Library/documentation/dce/1.1/pthread_mutex_init .html > >So, it looks like I need to find a version to if or ifdef off of. I found a define in dce/cma.h (appended to my original email) which seems to fit the bill: /* * Define a symbol which client code can test to determine whether the * underlying threads package is DECthreads or not. This is especially * important to clients of the Pthreads interface who may want to use * certain DECthreads extensions, such as the global lock and non-real-time * scheduling policies, on the DECthreads platform while maintaining * portability to a "vanilla" pthreads implementation. */ #define _DECTHREADS_ 1 Although, I'm not sure how to find out if this should be used generally, or only on HP. ----------------------------------------------------------------------- DISCLAIMER: Information contained in this message and/or attachment(s) may contain confidential information of Zetec, Inc. If you have received this transmission in error, please notify the sender by return email. -----------------------------------------------------------------------

2 1

regex performance
by Paul Dubuc 17 Aug '02

17 Aug '02

I'm doing some performance comparisons between Rogue Wave's Regexp class (http://www.roguewave.com/support/docs/tlsref/rwcregexp.cfm) and boost::regex using simple expressions like "^metal.*" and "[0-9]+" with regex_search(). regex is slower by a factor of 6, measuring cpu time (on a SunBlade 100 runing Solaris 8). Is there anything I can do to speed it up? I tried using different values of boost::regbase::flag_type_ to adjust how the regular expressions are interpreted, but with little effect. Any other ideas? (I'm using boost_1_27_0.) Thanks, -- Paul M. Dubuc

7 12

request for comment on possible submission to library
by DrXenos 17 Aug '02

17 Aug '02

I was wondering if anyone would be interested in a Set Library, similar to Pascal's set type for ordinal types. I want to make sure someone would fine it useful (and not trivial, done-to-death, etc.) before I take the time to "Boostify" it and get a release from my employer. A while ago I needed a set type that was compact, fast, and avoided heap allocation. The number of elements was constant for a particular set type, and the element type could be any integral type (primarily enums). Similar types from STL are set, vector<bool>, and bitset, but none quite suited the application. My set type (Set) stores elements at the bit level, like vector<bool> and bitset, but it allows the creation of compile-time set constants. Also, with a good optimizing compiler, operations on constant sets will be done at compile-time, though as of yet, there is no direct support for guaranteeing this in the code. The class provides the usual set operations. For efficiency, set operations are done in parallel groups of the machine's word size. So, set types whose max. number of elements is less than or equal to the machine's word size, will have most of its operations done in constant time (usually one machine instruction per operation). Sets whose max. number of elements is greater than the machine's word size will be done in linear time, usually in E / Wb cycles, where E is the max. number of elements and Wb is the machine's word size in bits. Though, with a good compile (through inlining and loop unrolling), this linear time would only be E / Wb instructions. On an average 32-bit processor, that's just 8 instructions to perform the union or intersection of a set of 256 elements. Originally, I avoided loops and used metatemplates to inline the operations, but this resulted in very long compile-times without any gains in performance! And sometimes it resulted in worse performance. That will teach me not to try and second guess today's optimizing compilers! As I stated above, the class template may be instantiated with any integral type, but it was primarily meant for enumerations with will give you the added bonuses of type-safely and symbolic names for the elements. The class assumes that the range given is not disjoint (i.e., 0-63 and not 0 - 16, 19, 63). You may use disjoint ranges, but your sets will contain wasted space. The only requirement is that the range of values is greater than or equal to zero, and that the element type has a representation for -1 (used as a (hidden) sentinel in argument lists of elements). You could even conceivably use a class that was "castable" to int. For example: // element type enum Color {red, orange, yellow, green, blue, violet, NumColors, NilColor = -1}; // type for set of colors typedef Set<Color, NumColors> ColorSet; // set constant const ColorSet rgb = ColorSet::SetOf<red, green, blue>::value(); // this is done at compile-time void foo() { // construction ColorSet s = ColorSet::SetOf<orange, yellow, violet>::value(); // this is done at compile-time ColorSet s1 = ColorSet(a); // this *may* be at compile-time ColorSet s2 = ColorSet(orange, yellow, violet); // this is NOT done at compile-time // (but allows non-constant elements) // operations, some of which *may* be done at compile-time by a smart compiler ColorSet a = s; // assignment ColorSet b = s + rgb; // union ColorSet c = s * rgb; // intersection ColorSet d = s - rgb; // difference ColorSet e = s / rgb; // symmetric difference bool b1 = s == rgb; // equality bool b1 = s != rgb; // unequality bool b3 = s >= rgb; // superset bool b4 = s > rgb; // proper superset bool b5 = s < rgb; // subset bool b6 = s > rgb; // proper subset if (b.contains(red)) // test for set membership std::cout << "b contains the element red" << std::endl; if (red == b) // same as above. can anyone suggest a better operator? // maybe use red -> b and use NULL for false? // or maybe remove and just use b.contains(red)? std::cout << "b contains the element red" << std::endl; } What do you think? Thanks, Rich (spamjunk(a)stny.rr.com)

1 0

RE: [Boost-Users] detail/lightweight_mutex.hpp
by Tom Matelich 16 Aug '02

16 Aug '02

> From: Peter Dimov [mailto:pdimov@mmltd.net] > > From: "Tom Matelich" <tmatelich(a)zetec.com> > > I'm attempting to go to Boost 1.28 on our HPUX 10.20 boxes. > I've run into > a > > problem with an assumption about the type of pthread_mutexattr_t. > > detail\lwm_pthreads.hpp calls: > > > > pthread_mutex_init(&m_, 0); > > > > HP's pthread.h (10.20 uses DCE) has that defined as: > > > > int pthread_mutex_init (pthread_mutex_t *,pthread_mutexattr_t); > > I don't know what to do about it. My POSIX draft says > > int pthread_mutex_init(pthread_mutex_t *restrict mutex, const > pthread_mutexattr_t *restrict attr); > > and goes on to specify that 0/NULL for the second argument > causes default > attributes to be used. > > I know little - if anything - about HPUX 10.20; if you find a > solution let > me know, and I'll incorporate it into lwm_pthreads.hpp. Sorry. > The dce documentation I see says to use pthread_mutexattr_default. http://www.transarc.ibm.com/Library/documentation/dce/1.1/pthread_mutex_init .html So, it looks like I need to find a version to if or ifdef off of. ----------------------------------------------------------------------- DISCLAIMER: Information contained in this message and/or attachment(s) may contain confidential information of Zetec, Inc. If you have received this transmission in error, please notify the sender by return email. -----------------------------------------------------------------------

1 0