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

RE: [Boost-users] regular expression searching for Glib::ustring??
by Ben Hutchings 18 Mar '04

18 Mar '04

Paul Elliott <pelliott(a)io.com> wrote: > I am using Gtkmm. I want to do boost regular expression searching on > Glib::ustring. > http://www.gtkmm.org/gtkmm2/docs/reference/html/classGlib_1_1ustring.htm l > > This class represents characters in UTF-8, so each character in the > buffer is represented by a varriable number of bytes. But it does > have a bidirectional iterator. > > How would you set up boost regex to search if both the regular > expression and the string to be searched is a ustring? > > Does one need to override any of the types defiened in regex_traits? The character type should be gunichar. > Thank you. > > BTW. > Quote from:http://www.boost.org/libs/regex/doc/regex_traits.html > > "Under construction. > The current boost.regex traits class design will be migrated to > that specified in the regular expression standardization proposal." > > This is not very useful to someone trying to use the boost_regex > library now! I am using Boost 1.30, in which the traits are documented in <boost/libs/regex/traits_class_ref.htm>. I don't know whether that documentation still applies to 1.31. You don't necessarily need custom traits to use custom iterator types. However, you do need to define custom traits to make character classes, case folding and so on work for all Unicode characters. To create a regex from a ustring I would write something like this: boost::reg_expression<gunichar, unicode_regex_traits> re; re.assign(s.begin(), s.end(), flags); When searching in a ustring I would write code like: my_predicate pred; boost::regex_grep(pred, s.begin(), s.end(), re, flags); boost::match_results<Glib::ustring::const_iterator, std::allocator<gunichar> > results; boost::regex_search<Glib::ustring::const_iterator, std::allocator<gunichar>, gunichar, unicode_regex_traits, std::allocator<gunichar> >( s.begin(), s.end(), results, re, flags); Glib::ustring result; boost::regex_merge( std::back_inserter(result), source.begin(), source.end(), re, std::basic_string<gunichar>(repl.begin(), repl.end())), flags); (The above is untested as we're not actually using Gtkmm but it's based on what we're doing with our own UTF-8 and UTF-16 strings.)

2 1

RE: [Boost-users] regular expression searching for Glib::ustring??
by Yarwood, Martin (UK) 18 Mar '04

18 Mar '04

> "Under construction. > The current boost.regex traits class design will be migrated to > that specified in the regular expression standardization proposal." > > This is not very useful to someone trying to use the boost_regex > library now! > I'm sure they'll give you a full refund ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ********************************************************************

1 0

adjacency_matrix BGL problem
by Gustavo Sánchez 18 Mar '04

18 Mar '04

Hi everybody, Is it posible to resize a graph with this representation?. The idea is start with an empty matrix and add vertex based on the new vertices and edges we read. That is, we read a new edge and if their vertex aren't in the graph we add them and then the edge. Is this posible in an adjacency_matrix representation??? Thanks a lot. --------------------------------- Antivirus Filtros antispam 6 MB gratis ¿Todavía no tienes un correo inteligente?

2 1

problem with vertex properties in BGL
by Gustavo Sánchez 17 Mar '04

17 Mar '04

I have to build a graph from data in a file, some information is strings which are related to vertexes. I want to prove if those vertexes already exist in the graph before the insert operation. Next is the source: typedef adjacency_matrix<undirectedS,VertexProperty,EdgeProperty> UGraph; // an undirected graph UGraph g(0); // start from scratch property_map<UGraph, edge_name_t>::type ename = get(edge_name, g); // not sure if this is right (the graph have no elements at this point) property_map<UGraph, vertex_name_t>::type vname = get(vertex_name, g); typedef property_map<UGraph, vertex_name_t>::type vname_type; typedef boost::property_traits<vname_type>::key_type vktype; typedef boost::property_traits<vname_type>::value_type vvtype; vktype indice_nombre; vvtype valor_nombre; for(i=0;i<datgen.NumHilos;i++){ valor_nombre = hiloNormal[i].viaOrigen; /// here we get the string indice_nombre = vname[valor_nombre]; /// here I try to get the index /// I think this is not posible because there isn't [] operator in this way valor_nombre = vname[1]; /// if I do this the compiler is right but that isn't useful for me because the information I have is the string not the index.I can use vertex iterators and search for the string, but if posible i prefer not to do that. thanks a lot. --------------------------------- Antivirus Filtros antispam 6 MB gratis ¿Todavía no tienes un correo inteligente?

2 1

Bug in Boost Graph Library?
by Heiko Bauke 17 Mar '04

17 Mar '04

Dear all, today I was engaged in searching for a bug in my program. After a while I figured out that boost::num_egdes behaves not as I expected. If G is an undirected adjacency matrix graph boost::num_egdes(G) returns the number of edges in the graph G plus the number of edges in G that are no self edges. That means almost all edges are counted twice in undirected adjacency matrix graphs. In my oppinion this behaviour is a bug. At least it makes the BGL-user's live unnecessary difficult. Let's considder the following program: #include <cstdlib> #include <iostream> #include <boost/tuple/tuple.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/adjacency_matrix.hpp> template <typename Graph> void add_edges(const char * const c) { std::cout << c; Graph G(6); boost::graph_traits<Graph>::vertex_iterator v, vbegin, vend; boost::tie(vbegin, vend)=boost::vertices(G); for (v=vbegin; v!=vend; ++v) { boost::add_edge(*vbegin, *v, G); std::cout << ' ' << boost::num_edges(G); } std::cout << std::endl; } int main() { typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS> adjacency_list; typedef boost::adjacency_matrix<boost::undirectedS> adjacency_matrix; add_edges<adjacency_list>("adjacency list graph :"); add_edges<adjacency_matrix>("adjacency matrix graph :"); return EXIT_SUCCESS; } It prints to stdout: adjacency list graph : 1 2 3 4 5 6 adjacency matrix graph : 1 3 5 7 9 11 So the result of the template function add_edges in the program above depends of the graph container that the function add_edges is applied to. I think this is verry unintuitive and boost::num_edges should be changed, so that alls edges in undirected adjacency matrix graphs are counted only once. Or is there a special reason that boost::num_edges is implemented in this way? with regards, Heiko -- -- Gute Sitten haben für die Gesellschaft mehr Wert als alle -- Berechnungen Newtons. (Friedrich II., der Große, 1712-1786) -- Supercomputing in Magdeburg @ http://tina.nat.uni-magdeburg.de -- Heiko Bauke @ http://www.uni-magdeburg.de/bauke

2 1

RE: [Boost-users] boost::thread problem
by Ben Hutchings 17 Mar '04

17 Mar '04

Pete <petehug(a)paradise.net.nz> wrote: > I'm having a problem with my boost multithreaded application. > My app runs fine as a Windows Service, but as a Unix daemon it > stops responding after some time. I noticed that the fewer > threads I have available, the quicker the application stops > responding: HP-UX(64) after 20mins, RH8(256) after >1hr, Linux > RH9(1024) >5hrs. This led me to assume that perhaps the threads > are not cleaned up properly. That could well be right. Perhaps there is some kind of deadlock at thread exit? > Therefore, I wrote a little test app which ought to demonstrate > the problem. To my surprise, the test application showed an > entirely different problem, but again, only under Unix (it > works as expected under Windows). I'm totally lost what the > reason is and appreciate any help. > > Expected: Actual: > --------------- --------------- > Start running Start running > Start swimming Finish running > Start cycling Start swimming > Finish swimming Finish swimming > Finish cycling Start cycling > Finish running Finish cycling > > In windows I get the actual output but under Linux RH9, I get > the Actual output. Under RH9, the first five lines of the > actual output appear immediately, but the last one takes > approx. 4secs. In other words, only the last threads don't > sleep the number of secs specified. According to the manual page: "sleep() makes the current process sleep until seconds sec- onds have elapsed or a signal arrives which is not ignored." (Note that each POSIX thread is/was implemented as a process in Linux.) If thread creation involves receiving a signal then that would explain the above behaviour. I would expect it under RH8 because that has the old LinuxThreads implementation of pthreads that uses signals heavily, but not in RH9 which has NPTL. Still, you would be better off using boost::thread::sleep() instead.

1 0

boost::thread_group design flaw
by Pete 17 Mar '04

17 Mar '04

I'm pretty convinced that there is a serious design flaw in boost::thread_group or at the very minimum, the documentation should better address the issue. Let's take a look at the thread_group.cpp example provided with boost::thread: #include <boost/thread/thread.hpp> #include <iostream> int count = 0; boost::mutex mutex; void increment_count() { boost::mutex::scoped_lock lock(mutex); std::cout << "count = " << ++count << std::endl; } int main(int argc, char* argv[]) { boost::thread_group threads; for (int i = 0; i < 10; ++i) threads.create_thread(&increment_count); threads.join_all(); } This example works fine until I make the following small change to main() which breaks it: int main(int argc, char* argv[]) { boost::thread_group threads; for (int j = 0; j < 2; ++i) { for (int i = 0; i < 10; ++i) threads.create_thread(&increment_count); threads.join_all(); } } The above code will break the second time threads.join_all() is called. The problem is that all boost::thread objects created in the first iteration survive the join_all() call. Worse still, the 2nd join_all() call sends another join() message to each thread it created but boost::thread::join() does not check the m_joinable flag and simply tries to free the system resources it previously freed again causing a system fault. To correct the problem above, I can change the code as follows: int main(int argc, char* argv[]) { boost::thread* pt[10]; boost::thread_group threads; for (int j = 0; j < 2; ++i) { for (int i = 0; i < 10; ++i) pt[i] = threads.create_thread(&increment_count); threads.join_all(); for (int i = 0; i < 10; ++i) threads.remove_thread(pt[i]); } } While this code no longer causes a GPF, I do not believe that the boost::thread objects created by boost::thread_group::create_thread() actually ever get destroyed. I have set a break point in boost::thread::~thread() but this breakpoint is never reached. If I physically delete each pt[i] after removing it from the thread_group I'm getting an assertion error telling me that the pointer I'm trying to delete is not a valid debug-heap pointer, but this error will most likely disappear if I stop using the debug heap (I haven't tried yet). As a boost::thread_group user, I made the following assumptions: - a boost::thread created through boost::thread_group::create_thread will be removed and cleaned up properly when a) the thread terminates or b) the thread_group is deleted - after returning from a call to join_all() the boost::thread_group has no boost::thread object members - I need not specifically keep track of boost::thread objects created by boost::thread_group and destruction of these objects is encapsulated within boost::thread_group I now find that none of these assumptions is quite correct. Perhaps I good immediate remedy would be to implement a boost::thread_group::clear() method which would throw an error if any of the threads where still in a running state and else would clear its threads collection and destroy the objects? How about thread objects "remembering" their membership in a thread_group so that the thread group can be informed when a thread terminates?

3 3

boost::thread problem
by Pete 17 Mar '04

17 Mar '04

I'm having a problem with my boost multithreaded application. My app runs fine as a Windows Service, but as a Unix daemon it stops responding after some time. I noticed that the fewer threads I have available, the quicker the application stops responding: HP-UX(64) after 20mins, RH8(256) after >1hr, Linux RH9(1024) >5hrs. This led me to assume that perhaps the threads are not cleaned up properly. Therefore, I wrote a little test app which ought to demonstrate the problem. To my surprise, the test application showed an entirely different problem, but again, only under Unix (it works as expected under Windows). I'm totally lost what the reason is and appreciate any help. Expected: Actual: --------------- --------------- Start running Start running Start swimming Finish running Start cycling Start swimming Finish swimming Finish swimming Finish cycling Start cycling Finish running Finish cycling In windows I get the actual output but under Linux RH9, I get the Actual output. Under RH9, the first five lines of the actual output appear immediately, but the last one takes approx. 4secs. In other words, only the last threads don't sleep the number of secs specified. #include <string> #include <list> #include <iostream> #include <unistd.h> #include <boost/thread/thread.hpp> class MyThread { protected: std::string m_strName; int m_iDuration; public: MyThread(const std::string & s, int i) : m_strName(s), m_iDuration(i) {} void operator()() { std::cout << "Start " << m_strName << std::endl; sleep(m_iDuration); std::cout << "Finish " << m_strName << std::endl; } }; int main(int argc, char *argv[]) { std::list<MyThread*> lst; std::list<MyThread*>::iterator itr; MyThread* pT; boost::thread_group tg; lst.push_back(new MyThread("running", 6)); lst.push_back(new MyThread("swimming", 2)); lst.push_back(new MyThread("cycling", 4)); for (itr = lst.begin(); itr != lst.end(); itr++) { pT = *itr; tg.create_thread(boost::ref(*pT)); } tg.join_all(); while (!lst.empty()) { delete lst.front(); lst.pop_front(); } return 1; }

2 1

Trouble building libbgl-viz.a
by Steve Juranich 16 Mar '04

16 Mar '04

Here's my system specs (let me know if I'm leaving something out): SuSE Linux 8.2 gcc v. 3.3 barbet (juranich)$ g++ -v Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.3/specs Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --enable-languages=c,c++,f77,objc,java,ada --disable-checking --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit i486-suse-linux Thread model: posix gcc version 3.3 20030226 (prerelease) (SuSE Linux) flex v. 2.5.4 bison v. 1.75 Description of problem: When I cd into $BOOST/libs/graph/src and type 'make', I get the following errors: barbet:/local/src/boost_1_31_0/libs/graph/src # make flex -Pbgl_undir_ -ographviz_graph_lex.cpp graphviz_lex.ll bison -p bgl_undir_ -d -v -o graphviz_graph_parser.cpp graphviz_parser.yy graphviz_parser.yy: warning: 1 shift/reduce conflict g++ -ftemplate-depth-50 -DGRAPHVIZ_DIRECTED=0 -I../../.. -g -c graphviz_graph_lex.cpp graphviz_lex.ll: In function `int bgl_undir_lex(yystype*)': graphviz_lex.ll:85: error: request for member `ptr' in `*lvalp', which is of non-class type `int' graphviz_lex.ll:87: error: request for member `ptr' in `*lvalp', which is of non-class type `int' make: *** [graphviz_graph_lex.o] Error 1 So, line 85 in graphviz_lex.ll looks like this: I've looked at the source with a friend who (unlike myself) actually has some experience with lex and yacc, but he couldn't spot the problem either. I know that the caveat at the top of the file says that the makefile probably won't work on my system, so are there any suggestions on what I could do to make it work? Thanks a lot. -- Stephen W. Juranich Science Applications Intl. Corp. (SAIC) (520) 570-7706

2 4

RE: [Boost-users] VC 7.1 & boost.thread
by Ben Hutchings 16 Mar '04

16 Mar '04

raja <raja(a)genesyslab.com> wrote: > Hi, > I am getting the following error. I see that it is trying to link to > the static library, but I still get this error. It's not trying to link to the static library - you are. > Would appreciate if someone can correct my usage. > Linking to lib file: lib"boost_thread"-vc71-mt-sgd-1_31.lib > > c:\Boost\include\boost-1_31\boost\config\auto_link.hpp(269) : > fatal error > C1189: #error : "Mixing a dll boost library with a static runtime is a > really bad idea..." <snip> In your project's properties, under C/C++ > Code Generation, set the Runtime Library to be "Multi-threaded DLL" in the release configuration and "Multi-threaded Debug DLL" in the debug configuration. If you are not using the Visual Studio IDE then use the /MD and /MDd compiler switches respectively.

1 0