- Boost-users - lists.boost.org

[BGL]: Highest performance graph-type available?
by Greg Link 11 May '06

11 May '06

I'm using BGL for the johnson_all_pairs_shortest_path algorithm, and spending about 98% of my runtime in that algorithm. Breaking it down, the BFS_visit itself is consuming some 85% of my total runtime. Hence, any and every improvement I can get in my BGL performance will make my app much much snappier. Currently, my graph type is a adjacency_list <vecS, vecS, undirectedS, no_property, property <edge_weight_t, double> > and I'm wondering if that's the best choice. My graph has (E=2*V), and all nodes are of constant degree, with 4 edges incident on them. V is usually in the range of 150-500. Would one of the other types (such as listS) perhaps be faster, and still work? I know some BGL algorithms require certain graph storage types, so I'm hesitant to just start poking around and trying random things. That, and other than "listS", I don't know of any other types of graph, as I'm quite new to both the BGL and boost in general. Any thoughts on what might make things faster? Additionally, are there any compiler flags I should consider other than the 'vanilla' ones? (-O3). I'm using GCC 4.0.1 currently, if it matters. Thanks for the great library, and such a friendly list, Greg Link

4 5

Problem with lambda expressions and uint64_t
by Olatunde Adonai 11 May '06

11 May '06

The following code compiles with f as a uint32_t. It does not compile with f as a uint64_t. Why is this? What can be done? #include <iostream> #include <algorithm> #include <boost/lambda/lambda.hpp> using std::cout; using std::for_each; using namespace boost::lambda; int main(int argc, const char* argv[]) { const char s[] = "abcdefghi"; //Problem: uint64_t f = 0xaa; //This compiles as a uint32_t. unsigned int i = 0; for_each(s , &s[sizeof(s) - 1] , cout << _1 << " = " << var(i)++ << " (" << ( ( f >> var(i) ) & 1 ) << ")\n" ); return 0; } __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

boost::iostreams regex_filter crash
by Andrew McDonald 11 May '06

11 May '06

I am using boost_1_33_1, in Microsoft Visual C++ 2005 Express Edition version 8.0.50727.42. Boost has been built with the vc-8_0 toolset. When using a filtering_stream with a regex_filter I get a crash in cases where the filtering_stream is destroyed (i.e. closed) having processed text without any match for the regex. =========================================================== #include <boost/iostreams/filtering_stream.hpp> #include <boost/iostreams/filter/regex.hpp> #include <iostream> using namespace boost; using namespace boost::iostreams; // replaces y with Q const regex_filter Y_FILTER ( regex("y") ,"Q" ); // replaces x with Q const regex_filter X_FILTER ( regex("x") ,"Q" ); // test data has a y but no x const char* Y_BUT_NO_X = "abc y cba"; void test() { // outputs "abc Q cba" as expected { filtering_ostream out( Y_FILTER ); out.push(std::cout); out << Y_BUT_NO_X; } // crashes with null pointer dereference !!! { filtering_ostream out( X_FILTER ); out.push(std::cout); out << Y_BUT_NO_X; } } =========================================================== Please note that the same crash occurs with "real world" regex's and data so the issue is not caused by boundary conditions due to the "artificial" test data. It is generically caused by the condition of not matching the regex. The crash occurs at line 53 of boost/iostreams/filter/regex.hpp in the function void do_filter(const vector_type& src, vector_type& dest) { typedef regex_iterator<const Ch*, Ch, Tr> iterator; if (src.empty()) return; iterator first(&src[0], &src[0] + src.size(), re_, flags_); iterator last; const Ch* suffix = 0; // Prevent GCC 2.95 warning. for (; first != last; ++first) { dest.insert( dest.end(), first->prefix().first, first->prefix().second ); string_type replacement = replace_(*first); dest.insert( dest.end(), replacement.begin(), replacement.end() ); suffix = first->suffix().first; } dest.insert(dest.end(), suffix, &src[0] + src.size()); <<< Crash !! } In cases where no regex match will occur then first == last, the for loop body is never run and consequently suffix remains initialised to 0. Consequently its use in the line succeeding the loop body causes a crash. The intent of this last line is to copy any text remaining after the last match from the src to the dest. This means that an appropriate initialiser for suffix is the start of the src, so that all text is copied to the destination if no match occurs. This can be achieved by altering the line; const Ch* suffix = 0; // Prevent GCC 2.95 warning. to const Ch* suffix = &src[0]; // Prevent GCC 2.95 warning. However a small rewrite avoids several calls to operator[] and size() and makes the code (ever so slightly) more readable; void do_filter(const vector_type& src, vector_type& dest) { typedef regex_iterator<const Ch*, Ch, Tr> iterator; if (src.empty()) return; const Ch* start = &src[0]; const Ch* end = start + src.size(); const Ch* suffix = start; // Prevent GCC 2.95 warning. iterator first(start, end, re_, flags_); iterator last; for (; first != last; ++first) { dest.insert( dest.end(), first->prefix().first, first->prefix().second ); string_type replacement = replace_(*first); dest.insert( dest.end(), replacement.begin(), replacement.end() ); suffix = first->suffix().first; } dest.insert(dest.end(), suffix, end); } I have tested this with both the test() function above and my original data and correct output is produced. regards, Andrew Andrew McDonald System Architect > Norwood Systems Australia Pty Ltd Level 1, 71 Troy Terrace PO Box 1281 Subiaco, WA 6904 > Tel +61 8 9380 7766 > Fax +61 8 9380 7733 andrew.mcdonald(a)norwoodsystems.com > > The information in this email, and any attachments, may contain confidential information and is intended solely for the attention and use of the named addressee (s). It must not be disclosed to any person(s) without authorization. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorized to, and must not, disclose, copy, distribute, or retain this message or any part of it. If you have received this communication in error, please notify the sender immediately. > > > > > > > > > > > > >

1 0

Re: [Boost-users] Compiling boost on Sol 5.2 compiler
by paul.floyd 11 May '06

11 May '06

> Hi, > > I am trying to use boost with Solaris 5.2 compiler. I am getting a compiler > error as a result of the macor BOOST_AUX_NTTP_DECL not being defined > anywhere. I would appreciate it very much if anyone could point me how I can > get past this stage. You won't get very far with Forte 6 update 1 (it is old, and no longer supported). I would suggest that you get either Studio 10 (available for free via opensolaris.org) or Studio 11 (available for free from Sun). At least, if you can't switch to either of those versions of Sun Studio, I'd consider trying to get Forte 6 update 2. This is a bit less old, and was supported up till about 6 months ago, and it should work OK with the same licence as Forte 6u1. However, it's still too old to compile fairly major chunks of Boost. Next take a look at http://blogs.sun.com/roller/page/sga This should get you much closer to being able to use most of Boost. A+ Paul Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34 /mn) ; tél : 08 92 68 13 50 (0,34/mn)

1 0

boost::iostreams pipelines with ostream causes compilation error
by Andrew McDonald 11 May '06

11 May '06

Hi, I have just recently started using the boost::iostreams library, so apologies if my question is obvious. I have tried checking doco and mailing list to see if this issue is already covered. I am using boost_1_33_1, in Microsoft Visual C++ 2005 Express Edition version 8.0.50727.42. Boost has been built with the vc-8_0 toolset. When attempting to use pipelines with filtering_streams I get an error when attempting to add an ostream as the (terminating) device for the pipeline The following (inline) test program illustrates various combinations that compile with the problem usage as the last example =============================================================== #include <boost/iostreams/filtering_stream.hpp> #include <boost/iostreams/filter/regex.hpp> #include <boost/iostreams/device/file.hpp> #include <iostream> using namespace boost::iostreams; void test(std::ostream& os, regex_filter& f) { // pipeline with no device - ok { filtering_ostream out( f | f ); out.push(os); } // explicitly pushing file sink - ok { filtering_ostream out( f | f ); out.push(file_sink("test.txt")); } // explicitly pushing ostream - ok { filtering_ostream out( f | f ); out.push(os); } // only a file sink - ok { filtering_ostream out(file_sink("test.txt")); } // only an ostream - ok { filtering_ostream out(os); } // pipeline with file sink - ok { filtering_ostream out( f | f | file_sink("test.txt") ); } // pipline with ostream - not ok !! { // compilation error filtering_ostream out( f | f | os ); } } =============================================================== The error generated is: boost/iostreams/pipeline.hpp(107) : error C2664: 'void boost::iostreams::detail::chain_client<Chain>::push<char,std::char_traits<char>>(std::basic_ostream<_Elem,_Traits> &,int,int)' : cannot convert parameter 1 from 'const std::ostream' to 'std::basic_ostream<_Elem,_Traits> &' with [ Chain=boost::iostreams::chain<boost::iostreams::output,char,std::char_traits<char>,std::allocator<char>>, _Elem=char, _Traits=std::char_traits<char> ] and [ _Elem=char, _Traits=std::char_traits<char> ] Conversion loses qualifiers This appears to be caused by the fact that the implementation of the push() method on struct pipeline calls chn.push(component_); where the component_ member is held by const ref. The push() method on Chain is generated with BOOST_IOSTREAMS_DEFINE_PUSH(push, mode, char_type, push_impl) which is commented with a cut-and-paste of the comment for the preceding macro, as // // Macro: BOOST_IOSTREAMS_DEFINE_PUSH_CONSTRUCTOR(mode, name, helper). // Description: Defines constructors which forward to a function // 'helper' which takes a filter or device by const reference. However via BOOST_IOSTREAMS_DEFINE_PUSH_IMPL this appears to generate a method requiring a non-const reference; ::std::basic_streambuf<CharType, TraitsType>& sb Am I missing something here ? I was wondering whether this was intentional and whether the syntactic form filtering_ostream out( f | f | os ) was meant to be supported. Andrew McDonald System Architect > Norwood Systems Australia Pty Ltd Level 1, 71 Troy Terrace PO Box 1281 Subiaco, WA 6904 > Tel +61 8 9380 7766 > Fax +61 8 9380 7733 andrew.mcdonald(a)norwoodsystems.com > > The information in this email, and any attachments, may contain confidential information and is intended solely for the attention and use of the named addressee (s). It must not be disclosed to any person(s) without authorization. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorized to, and must not, disclose, copy, distribute, or retain this message or any part of> it. If you have received this communication in error, please notify the sender immediately. > > > >

1 0

Re: [Boost-users] [multi_index] thread safety
by Conway Allen 11 May '06

11 May '06

Regarding thread safety, if threads are concurrently reading, inserting, and erasing entries in a multi-index container do you have to lockguard all of these operations or can you get away with just lockguarding the inserts and the deletes? Thanks, Allen. -----Message d'origine----- De : boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] De la part de JOAQUIN LOPEZ MU?Z Envoyé : mercredi 10 mai 2006 23:36 À : boost-users(a)lists.boost.org Objet : Re: [Boost-users] [multi_index] Core dump in multi-index library !! Oh, oh. multi_index_container is *not* thread safe, so this smells like the problem --and it is not, it certainly has the potential to crash your app sooner or later. Please take into account thread unsafety extends to every member function of multi_index_container, so you'd better lockguard *every* public method of Procedure_Pool. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [Boost-users] Template instantiation problem
by Gottlob Frege 11 May '06

11 May '06

Date: Wed, 10 May 2006 15:30:08 -0700 > From: Rush Manbert <rush(a)manbert.com> > Subject: [Boost-users] Template instantiation problem > To: boost-users(a)lists.boost.org > Message-ID: <44626970.4070704(a)manbert.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I have a template class that is designed to contain built in types or > std::string types. I always need to be able to cast an instance of the > class as a std::string, and I also need to be able to cast it as the > parameter type with which it was instantiated. > > In my class definition, I have defined two cast operators, like so: > (Extraneous stuff omitted) > > template<typename T> > class MyDataObject : public MyDataObjectBase > { > > // Cast as std::string > inline operator const std::string & () > { > ...some code here > } > > // Cast as T > inline operator const T & () > { > ...some code here > } > } > > The original code was written on a Mac and compiled with Gnu, which did > not complain. even when I did this: > > class MyStringObjectClass : public MyDataObject<std::string> > { > } > > Now, however, I have moved the code to Windows, and the Visual Studio > compiler complains about the second cast operator when I define > MyStringObjectClass. > > I thought that if I could conditionally define the cast as T operator > (or the cast as std::string) I would be okay, but that means testing > against the value of T with the preprocessor. I don't see how to do > that, but I know that some of you folks are really good at bending the > preprocessor to your will. > > Can anyone show me a way out of this predicament? > > Thanks, > Rush Take a look at enable_if. ie boost::mpl::enable_if I think. Also is_same. With those you can check if your T is_same as std::string, and enable (or disable) your operators accordingly. Tony.

1 0

Template instantiation problem
by Rush Manbert 11 May '06

11 May '06

I have a template class that is designed to contain built in types or std::string types. I always need to be able to cast an instance of the class as a std::string, and I also need to be able to cast it as the parameter type with which it was instantiated. In my class definition, I have defined two cast operators, like so: (Extraneous stuff omitted) template<typename T> class MyDataObject : public MyDataObjectBase { // Cast as std::string inline operator const std::string & () { ...some code here } // Cast as T inline operator const T & () { ...some code here } } The original code was written on a Mac and compiled with Gnu, which did not complain. even when I did this: class MyStringObjectClass : public MyDataObject<std::string> { } Now, however, I have moved the code to Windows, and the Visual Studio compiler complains about the second cast operator when I define MyStringObjectClass. I thought that if I could conditionally define the cast as T operator (or the cast as std::string) I would be okay, but that means testing against the value of T with the preprocessor. I don't see how to do that, but I know that some of you folks are really good at bending the preprocessor to your will. Can anyone show me a way out of this predicament? Thanks, Rush

3 2

Compiling boost on Sol 5.2 compiler
by Vadivelu Rahuraman 11 May '06

11 May '06

Hi, I am trying to use boost with Solaris 5.2 compiler. I am getting a compiler error as a result of the macor BOOST_AUX_NTTP_DECL not being defined anywhere. I would appreciate it very much if anyone could point me how I can get past this stage. Thanks, Rahu

1 0

[Wave] effect of allocation of data structures on copying data structures
by Andreas Sæbjørnsen 10 May '06

10 May '06

I need some advice regarding how I should copy the boost data structures I get from 'advanced_preprocessing_hooks.h'. The task at hand is to copy some of the data structures from Wave and store it separate form the memory Wave allocates so that after the Wave preprocessing step has finished all it's memory can be freed. Example: e.g making a copy of the 'std::vector<std::list<PreprocessingInfo::token_type,boost::fast_pool_allocator<PreprocessingInfo::token_type> > >' representing the arguments in the expansion of a macro in the function 'expanding_function_like_macro'. Syntactically it would be gre at to be able to make a copy using the operator=, but as far as I can see this is only possible if I am also using the fast_pool_allocator. If I use the fast_pool_allocator I am afraid that my copies will be put into the memory pool allocated by Wave and therefore that memory cannot be safely freed. Is this corect? .

2 1