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

[Boost.graph] compilation error for dijkstra_shortest_paths
by Nicolas Ray 29 May '07

29 May '07

Hello all, I have developed an application using the dijkstra_shortest_paths function of the Graph library of version 1.31 of Boost. When upgrading to Boost version 1.34, I have the following compilation error under Borland C++ Builder 6: [C++ Error] relaxed_heap.hpp(52): E2247'relaxed_heap<unsigned int, indirect_cmp<float*,less<float>>,vec_adj_list_vertex_id_map<VertexProperty, unsigned int>>::largest_key' is not accessible If I comment the call to the "dijkstra_shortest_paths" function in my code, there is no compilation error anymore. Is it related to how the default vertex_index is defined? If I add and use a custom vertex_index in the vertex property map, I get the same compilation error. I have tried to compile with version 1.33 and add the same error. I defined my graph as follow: struct vertex_altitude_t {typedef vertex_property_tag kind;}; typedef property<vertex_altitude_t, float> VertexProperty; typedef property<edge_weight_t, float > EdgeProperty; typedef adjacency_list<vecS, vecS, undirectedS, VertexProperty, EdgeProperty> Graph; Any help would be greatly appreciated, thank you very much, nicolas

2 2

Working with 64 bit dynamic bitsets....(uncertain of my method)
by Graham Reitz 29 May '07

29 May '07

Can anyone suggest a more efficient method to break apart a 64 bit dynamic bitset into 32 bit unsigned int chunks? The conversion is needed because eventually a C style system IO call needs to be performed that can't deal with a boost::dynamic_bitset or std::bitset; Thanks for any help/advice, Graham This works, but it feels inefficient: #include <iostream> #include "boost/dynamic_bitset.hpp" using namespace std; using namespace boost; // Create a 64 bit dynamic bitset from two 32 bit words, not 64 bit portable, illustration only dynamic_bitset<> create_64_bitset(unsigned int ms_word, unsigned int ls_word); int main(int argc, char* argv[]) { dynamic_bitset<> bitset_64( create_64_bitset(static_cast<unsigned>(0xaaaaaaaa), static_cast<unsigned>(0xbbbbbbbb))); cout << bitset_64 << endl; // This whole portion, below, seems inefficient. Is it? Is there a better method? // Break 64 bit dynamic bitset into 32 bit words dynamic_bitset<> temp_bitset(bitset_64); // Get least sig. 32 bits unsigned int ls_word = ((bitset_64 <<= 32) >>= 32).to_ulong(); // Get most sig 32 bits unsigned int ms_word = (temp_bitset >>= 32).to_ulong(); cout << ls_word << endl << ms_word << endl; cin >> argc; return 0; } dynamic_bitset<> create_64_bitset(unsigned int ms_word, unsigned int ls_word) { // Create a 64 bitset dynamic_bitset<> most_sig_word(64, ms_word); most_sig_word <<= 32; dynamic_bitset<> least_sig_word(64, ls_word); // Combine the two into one 64 bit bitset most_sig_word |= least_sig_word; return most_sig_word; }

1 0

[filesystem] dirent64* compilation error on PGI
by Server Levent Yilmaz 29 May '07

29 May '07

I am trying to build Boost.Filesystem (release 1.34) on a GNU/Linux x86_64 system with Portland Group compilers (there is no official support for this compiler). Everything else seems to work nice and dandy, except this single error with compiling operations.cpp: "operations.cpp", line 1247: error: a value of type "dirent64 *" cannot be assigned to an entity of type "dirent *" if ( (p = ::readdir( dirp )) == 0 ) ^ If I comment out the following defines in operations.cpp:22 and operations.cpp:25 #define _FILE_OFFSET_BITS 64 #define __USE_FILE_OFFSET64 the error goes away. But I doubt this is the correct way to fix this. Any ideas? thanks Levent -- Server Levent Yilmaz Mechanical Engineering University of Pittsburgh

1 0

[date time] Something leaks in operator<<
by Seweryn Habdank-Wojewódzki 29 May '07

29 May '07

Hi I do not know if date time leaks or not, but I want to clarify that before I will send information to libstdc++ bugzilla. Regards. The code: #include <iostream> #include <boost/date_time/gregorian/gregorian.hpp> int main() { using namespace boost::gregorian; using namespace std; date b1 (2007,2,3); date b2 (2007,2,7); cout << b1 << '\n'; // line 12 cout << b2 << '\n'; // line 13 date_period p1 (b1, b2); cout << p1 << '\n'; // line 15 } And the result of: valgrind --leak-check=full --show-reachable=yes ./main ==2382== Memcheck, a memory error detector. ==2382== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==2382== Using LibVEX rev 1732, a library for dynamic binary translation. ==2382== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==2382== Using valgrind-3.2.3, a dynamic binary instrumentation framework. ==2382== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==2382== For more details, rerun with: -v ==2382== 2007-Feb-03 2007-Feb-07 [2007-Feb-03/2007-Feb-06] ==2382== ==2382== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 1) ==2382== malloc/free: in use at exit: 856 bytes in 26 blocks. ==2382== malloc/free: 58 allocs, 32 frees, 2,772 bytes allocated. ==2382== For counts of detected errors, rerun with: -v ==2382== searching for pointers to 26 not-freed blocks. ==2382== checked 107,996 bytes. ==2382== ==2382== 20 bytes in 1 blocks are still reachable in loss record 1 of 7 ==2382== at 0x4021FB4: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==2382== by 0x8049CDD: std::locale::locale<boost::date_time::date_facet<boost::gregorian::date, char, std::ostreambuf_iterator<char, std::char_traits<char> > > >(std::locale const&, boost::date_time::date_facet<boost::gregorian::date, char, std::ostreambuf_iterator<char, std::char_traits<char> > >*) (locale_classes.h:568) ==2382== by 0x804F4E2: std::basic_ostream<char, std::char_traits<char> >& boost::gregorian::operator<< <char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, boost::gregorian::date const&) (gregorian_io.hpp:57) ==2382== by 0x8049B01: main (main.cpp:12) ==2382== ==2382== ==2382== 48 bytes in 1 blocks are still reachable in loss record 2 of 7 ==2382== at 0x4021C34: operator new[](unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==2382== by 0x40AE6B5: std::locale::_Impl::_Impl(std::locale::_Impl const&, unsigned) (in /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6.0.8) ==2382== by 0x8049CF9: std::locale::locale<boost::date_time::date_facet<boost::gregorian::date, char, std::ostreambuf_iterator<char, std::char_traits<char> > > >(std::locale const&, boost::date_time::date_facet<boost::gregorian::date, char, std::ostreambuf_iterator<char, std::char_traits<char> > >*) (locale_classes.h:568) ==2382== by 0x804F4E2: std::basic_ostream<char, std::char_traits<char> >& boost::gregorian::operator<< <char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, boost::gregorian::date const&) (gregorian_io.hpp:57) ==2382== by 0x8049B01: main (main.cpp:12) ==2382== ==2382== ==2382== 80 bytes in 2 blocks are still reachable in loss record 3 of 7 ==2382== at 0x4021FB4: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==2382== by 0x804C497: std::vector<std::string, std::allocator<std::string> >::_M_insert_aux(__gnu_cxx::__normal_iterator<std::string*, std::vector<std::string, std::allocator<std::string> > >, std::string const&) (new_allocator.h:90) ==2382== by 0x804CB25: boost::date_time::date_generator_formatter<boost::gregorian::date, char, std::ostreambuf_iterator<char, std::char_traits<char> > >::date_generator_formatter() (stl_vector.h:610) ==2382== by 0x804ED2E: boost::date_time::date_facet<boost::gregorian::date, char, std::ostreambuf_iterator<char, std::char_traits<char> > >::date_facet(unsigned) (date_facet.hpp:86) ==2382== by 0x804F4B5: std::basic_ostream<char, std::char_traits<char> >& boost::gregorian::operator<< <char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, boost::gregorian::date const&) (gregorian_io.hpp:56) ==2382== by 0x8049B01: main (main.cpp:12) ==2382== ==2382== ==2382== 112 bytes in 1 blocks are still reachable in loss record 4 of 7 ==2382== at 0x4021FB4: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==2382== by 0x804F4A5: std::basic_ostream<char, std::char_traits<char> >& boost::gregorian::operator<< <char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, boost::gregorian::date const&) (gregorian_io.hpp:56) ==2382== by 0x8049B01: main (main.cpp:12) ==2382== ==2382== ==2382== 128 bytes in 1 blocks are still reachable in loss record 5 of 7 ==2382== at 0x4021C34: operator new[](unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==2382== by 0x40AE262: std::locale::_Impl::_M_install_facet(std::locale::id const*, std::locale::facet const*) (in /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6.0.8) ==2382== by 0x8049D13: std::locale::locale<boost::date_time::date_facet<boost::gregorian::date, char, std::ostreambuf_iterator<char, std::char_traits<char> > > >(std::locale const&, boost::date_time::date_facet<boost::gregorian::date, char, std::ostreambuf_iterator<char, std::char_traits<char> > >*) (locale_classes.h:571) ==2382== by 0x804F4E2: std::basic_ostream<char, std::char_traits<char> >& boost::gregorian::operator<< <char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, boost::gregorian::date const&) (gregorian_io.hpp:57) ==2382== by 0x8049B01: main (main.cpp:12) ==2382== ==2382== ==2382== 128 bytes in 1 blocks are still reachable in loss record 6 of 7 ==2382== at 0x4021C34: operator new[](unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==2382== by 0x40AE1EF: std::locale::_Impl::_M_install_facet(std::locale::id const*, std::locale::facet const*) (in /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6.0.8) ==2382== by 0x8049D13: std::locale::locale<boost::date_time::date_facet<boost::gregorian::date, char, std::ostreambuf_iterator<char, std::char_traits<char> > > >(std::locale const&, boost::date_time::date_facet<boost::gregorian::date, char, std::ostreambuf_iterator<char, std::char_traits<char> > >*) (locale_classes.h:571) ==2382== by 0x804F4E2: std::basic_ostream<char, std::char_traits<char> >& boost::gregorian::operator<< <char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, boost::gregorian::date const&) (gregorian_io.hpp:57) ==2382== by 0x8049B01: main (main.cpp:12) ==2382== ==2382== ==2382== 340 bytes in 19 blocks are possibly lost in loss record 7 of 7 ==2382== at 0x4021FB4: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==2382== by 0x40F08F3: std::string::_Rep::_S_create(unsigned, unsigned, std::allocator<char> const&) (in /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6.0.8) ==2382== by 0x40F1A94: (within /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6.0.8) ==2382== by 0x40F1C48: std::string::string(char const*, std::allocator<char> const&) (in /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6.0.8) ==2382== by 0x804EC4B: boost::date_time::date_facet<boost::gregorian::date, char, std::ostreambuf_iterator<char, std::char_traits<char> > >::date_facet(unsigned) (date_facet.hpp:86) ==2382== by 0x804F4B5: std::basic_ostream<char, std::char_traits<char> >& boost::gregorian::operator<< <char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, boost::gregorian::date const&) (gregorian_io.hpp:56) ==2382== by 0x8049B01: main (main.cpp:12) ==2382== ==2382== LEAK SUMMARY: ==2382== definitely lost: 0 bytes in 0 blocks. ==2382== possibly lost: 340 bytes in 19 blocks. ==2382== still reachable: 516 bytes in 7 blocks. ==2382== suppressed: 0 bytes in 0 blocks. -- |\/\/| Seweryn Habdank-Wojewódzki \/\/

3 4

BOOST: interprocess library
by dhruva 29 May '07

29 May '07

Hi, I would like to know if the "interprocess" library can work with STL packaged with Visual Studio. My current understanding is that "interprocess" uses a modified STL to use shared memory and this is packaged with "interprocess". Since a lot of code we have uses STL from VS (MS Visual Studio), mixing might not be an option. Is there a clean workaround path or is it a known limitation? with best regards, dhruva -- Dhruva Krishnamurthy Contents reflect my personal views only!

2 1

Bellman-Ford Example
by Cigdem Gueler 29 May '07

29 May '07

Hallo,I have sent one more email previously. I 've got my little example for which Bellman-Ford fails to detect an existing negative cycle. This occurs after I modify the graph!I would be glad if you could help me. Bellman-Fors shortest paths is a very important routine for my code, which I have to call several times. And it has to work reliably so that the rest of the code also does...Thank you.cheers,Cigdem _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx…

2 1

Bellman-Ford shortest paths
by Cigdem Gueler 29 May '07

29 May '07

Hi,I have a little problem about Bellman Ford shortest paths algorithm. When I call this algorithm for the graphs with parallel edges, sometimes it fails to recognize the negative cycles. Doesn't it work for graphs with parallel edges? Or am I doing a mistake in my code? Well, the code is huge to send it to the mailing list. I am trying to find a little example for which this phenomenon occurs!But I still would like to be confirmed that Bellman Ford should have actually worked for graphs with parallel edges. It is not really mentioned in the documentation if it works or not!!Thank you,Cigdem _________________________________________________________________ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx

2 1

Re: [Boost-users] [date time] Something leaks in operator<<
by Seweryn Habdank-Wojewódzki 29 May '07

29 May '07

Hi > If you want to try to confirm it as a leak - change your cout references > to a [non-static] stream you declare directly in your program scope (not > cout, cerr, clog). You should then either see the "possible" move to > "leaked" or go away entirely. OK. thanks for suggestion to day I will check it, and put here results :-). Regards. -- |\/\/| Seweryn Habdank-Wojewódzki \/\/

1 0

Suppress generation of unversioned .lib
by Braden McDaniel 29 May '07

29 May '07

Is it possible to suppress generation of the unversioned .lib file when building on Windows? Braden

6 12

[iostreams] access to specialized stream attributes?
by Christopher Lux 28 May '07

28 May '07

Hi, i am trying to get access to specialized stream attributes in my own filters. I created a specialized stringstream class which holds some kind of log level, which i want to use in my input filters. Therefore i wrote a input device which handles my specialized class. With debug outputs i see that this device is used to read my stream. Now i want to create a filter which is able to access the log level attribute from the specialized stream. I tried to specialize the template function for reading from the source for my stream device and for the specialized stream but none of these functions are getting used. Is there a way to be able to access either the device or the source stream in the filters? The example code below gives a short example of the mentioned problem. #include <iostream> #include <sstream> #include <string> #include <boost/iostreams/concepts.hpp> #include <boost/iostreams/operations.hpp> #include <boost/iostreams/filtering_stream.hpp> #include <boost/iostreams/char_traits.hpp> #include <boost/iostreams/stream.hpp> // specialized stream class class console_out_stream : public std::stringstream { public: console_out_stream() : std::stringstream() {} virtual ~console_out_stream() {} int get_log_level() const { return (_log_level); } void set_log_level(int l) { _log_level = l; } private: int _log_level; }; // ability to set log level using the << operator on the new stream class class log_level { public: log_level(int l) : _log_level(l) {} int _log_level; }; console_out_stream& operator << (console_out_stream& con_str, const log_level& log) { con_str.set_log_level(log._log_level); return (con_str); } // source device class my_console_source : public boost::iostreams::source { public: my_console_source(console_out_stream& con) : _console(con) {} std::streamsize read(char* s, std::streamsize n) { std::cout << "ran through the source" << std::endl; return (boost::iostreams::read(_console, s, n)); } const console_out_stream& get_console() const {return _console; } protected: console_out_stream& _console; }; // input filter // just filters out the character s class test_in_filter_m : public boost::iostreams::multichar_input_filter { public: explicit test_in_filter_m() {} template<typename Source> std::streamsize read(Source& src, char* s, std::streamsize n) { for (std::streamsize z = 0; z < n; ++z) { int c; while (true) { if ((c = boost::iostreams::get(src)) == EOF) return z != 0 ? z : -1; else if (c == boost::iostreams::WOULD_BLOCK) return z; if (c != 's') break; } s[z] = c; } return n; } template<> std::streamsize read<my_console_source>(my_console_source& src, char* s, std::streamsize n) { std::cout << "ran through the source filter: my_console_source" << std::endl; return (n); } template<> std::streamsize read<console_out_stream>(console_out_stream& src, char* s, std::streamsize n) { std::cout << "ran through the source filter: console_out_stream" << std::endl; return (n); } }; int main(int argc, char **argv) { console_out_stream console; console << log_level(20) << "sick, sad world!"; console << log_level(5) << "from mtv daria" << std::endl; boost::iostreams::stream<my_console_source> in_stream_buf(console); boost::iostreams::filtering_istream out_stream; out_stream.push(test_in_filter_m()); out_stream.push(in_stream_buf); std::string line; while (std::getline(out_stream, line)) { std::cout << line << std::endl; } return (0); } -chris -- Christopher Lux | | Bauhaus University Weimar | Faculty of Media - Virtual Reality Systems Group

1 0