- Boost-users - lists.boost.org

Numeric parsing of strings
by rlyon＠comgroup.net.au 21 Oct '03

21 Oct '03

Hi, Many applications are required to parse a string/file and extract numeric values. You can use sscanf or alternatively use regexp with numeric casting templates. I suprised that boost doesn't seem to contain conversion templates like: template < typename t_target > t_target decimal_cast( const std::string& arg ){ ... }; template < typename t_target > t_target octal_cast( const std::string& arg ){ ... }; template < typename t_target > t_target hex_cast( const std::string& arg ){ ... }; When you use these type of casts with regexp, you can construct simple robust parsers for reading numeric data from files, etc ..., in just a few lines of code. The lexical_cast and numeric_cast don't seem to cover these conversions. This is much better approach than using parsing framework like spirit/antlr. Shouldn't boost have this capability. Regards

1 0

Boost.threads: can't create static libraries under linux
by Brewer, Christopher 21 Oct '03

21 Oct '03

Hello, all- For some reason bjam doesn't build the 'boost.thread' static libraries for me (the shared libraries _do_ build properly, though). There are no errors, no warnings- they just don't get built. I'm working with boost-1.30.2 on Red Hat 9 using bjam 3.1.7 (the prebuilt binary from sourceforge). I've tried executing ./configure and swapping out 'user.hpp', but this has no effect. I'm mystified. Am I missing something obvious? Regards, Chris Brewer

2 1

[BUG]: Boost MP thread crasher: thread_cleanup key not being initialized
by Bobby Thomale 21 Oct '03

21 Oct '03

I believe I have found a crashing bug in the boost thread classes on MacOS X, in the MP threads implementation. I looked at the source and I think I have figured out what is wrong and how to fix it. The thread_cleanup function, which on the MP threads implementation is called each time a boost thread exits, assumes that the "cleanup key" has been initialized. If it hasn't been initialized (ie you aren't using any thread specific storage), it still calls MPGetTaskStorageValue with the uninitialized key index. Here are the first few lines of thread_cleanup: void thread_cleanup() { cleanup_handlers* handlers = reinterpret_cast<cleanup_handlers*>( MPGetTaskStorageValue(key)); if(handlers != NULL) { ... If you have not used any thread-specific storage, key is an uninitialized variable when this gets called. Not good. It looks like for the most part, rather than puking, MPGetTaskStorageValue is returning NULL when given an uninitialized key value, at least on 10.2.x. (I am doing some testing on the upcoming 10.3 release of MacOS X and noted that thread_cleanup crashes 100% of the time on this platform - I suspect MPGetTaskStorageValue is no longer returning NULL.) Since "key" is an uninitialized variable, I would think this would have unpredictable results and would crash occasionally even on 10.2.x, whenever "key" happened to start off as a value that was already in use maybe. It seems to me that we should simply make sure that the key is inited when calling thread_cleanup like so: boost::call_once(&init_cleanup_key, once); This makes sure that the key is inited, even if get_handlers is never called. (Adding that line of code to the beginning of thread_cleanup cleared up my crashing problems on 10.3 immediately.) Is that proper use of the call_once mechanism? Anyway, my first thought was to look at the implementations of threads on the other platforms, since they don't have this call_once call in their cleanup function before accessing the key either. It looks to me like, at least in the Windows code, the cleanup function is registered for the thread only during the get_handlers function, after the key is inited. If get_handlers is never called, the cleanup function never gets registered. In the Mac implementation, however, cleanup_thread is called directly by the thread proxy object at the end of thread execution, and it gets called even if get_handlers has never been called and the key has never been initialized. Here is a patch for my proposed fix. (I am sure there are other ways of fixing this too.) Comments, anyone? *** tss.orig.cpp Mon Oct 20 13:19:44 2003 --- tss.cpp Mon Oct 20 13:19:30 2003 *************** *** 126,131 **** --- 126,133 ---- void thread_cleanup() { + boost::call_once(&init_cleanup_key, once); + cleanup_handlers* handlers = reinterpret_cast<cleanup_handlers*>( MPGetTaskStorageValue(key)); if(handlers != NULL) -- Bobby --------------------------------------------------------------------- Bobby Thomale Senior Software Developer Inoveon Corporation http://www.inoveon.com/ ---------------------------------------------------------------------

1 0

[bgl] undirected_dfs to find cut-vertices
by Stephan Höfer 21 Oct '03

21 Oct '03

Hello, I build a visitor for an undirected graph which finds the cut-vertices of a given undireted graph or subgraph. I haven't found an implementation of the algorithm in the bgl. Maybe it would have been possible to use the predecessor_recorder for that. But then all the information which can be found directly while doing the df-search we have to find after having performed that search first. The interface of the undirected_dfs function doesn't take visitors via reference, so it wasn't possible to use that function. I had to call the detail::undir_dfv_impl function instead because that function takes a visitor reference and I had to recreate a function with the behaviour of the undirected_dfs. What reasons lead to the decision to disable passing a visitor by reference directly to undirected_dfs? What reasons lead to the decision to pass a const graph to a visitor function? Some useful things are disabled by that (but maybe also some bad things). Cheers, Stephan

2 1

Inconsistency in graph Example Code, Documentation
by Thomas F. O'Connell 21 Oct '03

21 Oct '03

This is a minor point but one worth correcting for the sake of correctness and ease of following the examples. In the boost-1.30.2 distribution, the file libs/graph/example/kevin-bacon.cpp makes a reference to a "./kevin-bacon.dat" file, but the file in both the distribution and the documentation is actually kevin_bacon.dat. The only difference being '_' vs. '-'. This is easily fixed by an end-user, but it would be nice to have the examples work out of the box. -tfo

3 3

Bug in graph library transitive closure algorithm?
by Watson, Jean-paul 20 Oct '03

20 Oct '03

Is anyone aware of any bugs in the graph library 'transitive_closure' algorithm? I believe I have a concrete example that exhibits an obvious bug (in particular, missing vertices that are reachable from certain source vertices), but (1) wasn't sure if there was a work-around or some well-known avoidance tactic and (2) whether anyone was actively supporting the graph library components. Thanks! Jean-Paul Watson E-mail: jwatson(a)sandia.gov Discrete Math Dept (9215), MS 1110 Phone: (505) 845-8887 P.O. Box 5800, Sandia National Labs FAX: (505) 845-7442 Albuquerque, NM 87185-1110 USA (Old) URL: http://www.cs.colostate.edu/~watsonj <http://www.cs.colostate.edu/~watsonj>

3 2

novice question: LAPACK & uBLAS
by Derek 19 Oct '03

19 Oct '03

Hi, I am a novice to all this. I am looking for a C++ library that would let me interface with BLAS/LAPACK. The immediate problem I have is the diagonalization of a large dense symmetric (possibly hermitian) matrix. (Speed will be a consideration eventually.) I would like to use the eigenproblem solvers in LAPACK. I understand that uBLAS does not have a full interface to LAPACK yet, but it looks like it is possible to use lapack at some level. (Does anyone have an example program excerpt?) I would be grateful for any advice about whether uBLAS is suitable for this. I am also considering other libraries such as MTL and Blitz++. I will be using Intel C++ compiler and/or GNU g++ on a Linux PC. Regards Derek

2 2

Necessity of assert in iterators (as called from graph)?
by Thomas F. O'Connell 18 Oct '03

18 Oct '03

In trying to compile and run the Kevin Bacon example for graph in the 1.30.2 distribution of Boost, I was able to compile, but when I ran the executable, I got: kevin-bacon: /usr/local/boost-1.30.2/boost/token_iterator.hpp:75: void boost::detail::tokenizer_policy<Type, TokenizerFunc>::increment(Iterator&) [with Iterator = boost::iterator_adaptor<boost::detail::token_iterator_base<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, boost::detail::tokenizer_policy<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::char_delimiters_separator<char, std::char_traits<char> > >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, const std::basic_string<char, std::char_traits<char>, std::allocator<char> >*, std::forward_iterator_tag, ptrdiff_t>, Type = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, TokenizerFunc = boost::char_delimiters_separator<char, std::char_traits<char> >]: Assertion `b.base().valid_' failed. Aborted Investigating led me to comment out the asserts on lines 69 and 75 of boost/token_iterator.hpp just to test. When I rebuilt without the asserts, I was able to run my executable with no problem with seemingly correct output. What purpose do the asserts serve, and why would they be failing? -tfo

2 2

RE: [Boost-users] [Q] shared_ptr c'tor
by Tom Matelich 18 Oct '03

18 Oct '03

The shared_ptr constructor from raw pointer is marked explicit (quick explanation: http://www.glenmccl.com/tip_023.htm) This is because once you put a pointer into a shared_pointer, it's lifetime is now managed by the shared_ptr. The authors feel it is very important that this is completely intentional, and rightly so. It can have nasty side effects if you don't. //untested code void foo(boost::shared_ptr<int> p) { (*p)++; } int main() { int* p = new int(5); foo(p); std::cerr << "p is now " << *p << std::endl; //oops, p has been deleted!!! return 0; } > -----Original Message----- > From: Marcel Loose [mailto:loose@astron.nl] > Sent: Friday, October 17, 2003 4:39 AM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] [Q] shared_ptr c'tor > > > Hi, > > I have a question related to the boost::shared_ptr constructor. > I want to be able to store boost::shared_ptr<Base> objects in > a std::vector. However, I don't want to bother my users with > the fact (implementation detail) that I'm using shared_ptrs > instead of raw pointers. > > The simplified sample code below more or less clarifies what > I want. The code in line 27 is the code I would like to be > able to use. Below that line, several attempts to get the > code to compile can be found. I understand that line 32 won't > compile, because it is equivalent to line 27. However, line > 37 left me puzzled. I would expect that the conversion of B* > to shared_ptr<B> would be trivial. Not so. > > Is it really true that the only way to use shared_ptr in the > way I want is as in lines 46, 47? Or am I overlooking > something? And is line 41 equivalent to line 46? > Thanks in advance. > > Regards, > > Marcel Loose. > > P.S.: I noticed that all code will compile if I omit the > "explicit" keyword in the constructor of shared_ptr, but I > don't consider that the proper way to solve the problem. > > > 1:#include <boost/shared_ptr.hpp> > 2:#include <vector> > 3: > 4:using namespace std; > 5:using namespace boost; > 6: > 7:class Base > 8:{ > 9:public: > 10: Base() { /* ... */ } > 11: virtual ~Base() {} > 12:}; > 13: > 14:class Derived : public Base > 15:{ > 16:public: > 17: Derived() { /* ... */ } > 18: virtual ~Derived() {} > 19:}; > 20: > 21: > 22:int main() > 23:{ > 24: vector<shared_ptr<Base> > v; > 25: > 26: { // failes to compile: > 27: v.push_back(new Derived()); // cannot > convert Derived*& > 28: } // to > shared_ptr<Base>. Why? > 29: > 30: { // failes to compile: > 31: Derived* d(new Derived()); // cannot > convert Derived*& > 32: v.push_back(d); // to > shared_ptr<Base>. Why? > 33: } > 34: > 35: { // failes to compile: > 36: Base* b(new Derived()); // cannot convert Base*& > 37: v.push_back(b); // to > shared_ptr<Base>. Huh? > 38: } // Seems a > trivial conversion. > 39: > 40: { // OK, this > compiles, but is > 41: shared_ptr<Derived> d(new Derived()); // it correct? > I.e. is conversion > 42: v.push_back(d); // > shared_ptr<Derived> to > 43: } // > shared_ptr<Base> trivial? > 44: > 45: { // OK, this > compiles, and is > 46: shared_ptr<Base> b(new Derived()); // probably > what I meant. > 47: v.push_back(b); // However, I > dislike the > 48: } // verbosity. > 49: > 50: return 0; > 51:} > > Just to be complete, please find the compiler diagnostics below. > > tBoost.cc: In function `int main()': > tBoost.cc:27: no matching function for call to ` > std::vector<boost::shared_ptr<Base>, > std::allocator<boost::shared_ptr<Base> > > >::push_back(Derived*&)' > /usr/local/gcc-3.2.1/include/c++/3.2.1/bits/stl_vector.h:490: > candidates are: > void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = > boost::shared_ptr<Base>, _Alloc = > std::allocator<boost::shared_ptr<Base> >] > tBoost.cc:32: no matching function for call to ` > std::vector<boost::shared_ptr<Base>, > std::allocator<boost::shared_ptr<Base> > > >::push_back(Derived*&)' > /usr/local/gcc-3.2.1/include/c++/3.2.1/bits/stl_vector.h:490: > candidates are: > void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = > boost::shared_ptr<Base>, _Alloc = > std::allocator<boost::shared_ptr<Base> >] > tBoost.cc:37: no matching function for call to ` > std::vector<boost::shared_ptr<Base>, > std::allocator<boost::shared_ptr<Base> > > >::push_back(Base*&)' > /usr/local/gcc-3.2.1/include/c++/3.2.1/bits/stl_vector.h:490: > candidates are: > void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = > boost::shared_ptr<Base>, _Alloc = > std::allocator<boost::shared_ptr<Base> >] > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users > ----------------------------------------------------------------------- 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

[Q] shared_ptr c'tor
by Marcel Loose 18 Oct '03

18 Oct '03

Hi, I have a question related to the boost::shared_ptr constructor. I want to be able to store boost::shared_ptr<Base> objects in a std::vector. However, I don't want to bother my users with the fact (implementation detail) that I'm using shared_ptrs instead of raw pointers. The simplified sample code below more or less clarifies what I want. The code in line 27 is the code I would like to be able to use. Below that line, several attempts to get the code to compile can be found. I understand that line 32 won't compile, because it is equivalent to line 27. However, line 37 left me puzzled. I would expect that the conversion of B* to shared_ptr<B> would be trivial. Not so. Is it really true that the only way to use shared_ptr in the way I want is as in lines 46, 47? Or am I overlooking something? And is line 41 equivalent to line 46? Thanks in advance. Regards, Marcel Loose. P.S.: I noticed that all code will compile if I omit the "explicit" keyword in the constructor of shared_ptr, but I don't consider that the proper way to solve the problem. 1:#include <boost/shared_ptr.hpp> 2:#include <vector> 3: 4:using namespace std; 5:using namespace boost; 6: 7:class Base 8:{ 9:public: 10: Base() { /* ... */ } 11: virtual ~Base() {} 12:}; 13: 14:class Derived : public Base 15:{ 16:public: 17: Derived() { /* ... */ } 18: virtual ~Derived() {} 19:}; 20: 21: 22:int main() 23:{ 24: vector<shared_ptr<Base> > v; 25: 26: { // failes to compile: 27: v.push_back(new Derived()); // cannot convert Derived*& 28: } // to shared_ptr<Base>. Why? 29: 30: { // failes to compile: 31: Derived* d(new Derived()); // cannot convert Derived*& 32: v.push_back(d); // to shared_ptr<Base>. Why? 33: } 34: 35: { // failes to compile: 36: Base* b(new Derived()); // cannot convert Base*& 37: v.push_back(b); // to shared_ptr<Base>. Huh? 38: } // Seems a trivial conversion. 39: 40: { // OK, this compiles, but is 41: shared_ptr<Derived> d(new Derived()); // it correct? I.e. is conversion 42: v.push_back(d); // shared_ptr<Derived> to 43: } // shared_ptr<Base> trivial? 44: 45: { // OK, this compiles, and is 46: shared_ptr<Base> b(new Derived()); // probably what I meant. 47: v.push_back(b); // However, I dislike the 48: } // verbosity. 49: 50: return 0; 51:} Just to be complete, please find the compiler diagnostics below. tBoost.cc: In function `int main()': tBoost.cc:27: no matching function for call to ` std::vector<boost::shared_ptr<Base>, std::allocator<boost::shared_ptr<Base> > >::push_back(Derived*&)' /usr/local/gcc-3.2.1/include/c++/3.2.1/bits/stl_vector.h:490: candidates are: void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = boost::shared_ptr<Base>, _Alloc = std::allocator<boost::shared_ptr<Base> >] tBoost.cc:32: no matching function for call to ` std::vector<boost::shared_ptr<Base>, std::allocator<boost::shared_ptr<Base> > >::push_back(Derived*&)' /usr/local/gcc-3.2.1/include/c++/3.2.1/bits/stl_vector.h:490: candidates are: void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = boost::shared_ptr<Base>, _Alloc = std::allocator<boost::shared_ptr<Base> >] tBoost.cc:37: no matching function for call to ` std::vector<boost::shared_ptr<Base>, std::allocator<boost::shared_ptr<Base> > >::push_back(Base*&)' /usr/local/gcc-3.2.1/include/c++/3.2.1/bits/stl_vector.h:490: candidates are: void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = boost::shared_ptr<Base>, _Alloc = std::allocator<boost::shared_ptr<Base> >]

1 0