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

Re: [Boost-users] adjacency_list directed to undirected conversion
by Sean Kelly 01 May '06

01 May '06

Doug, thanks -- that worked nicely. cheers Sean -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Douglas Gregor Sent: Wednesday, April 26, 2006 6:43 AM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] adjacency_list directed to undirected conversion On Apr 25, 2006, at 12:16 PM, Sean Kelly wrote: > I have a directed adjacency_list graph for which I would like to > identify connected components (ignoring the directed-ness). After > poking around the BGL docs it seems that my best option is to role my > own algo To do this, you could use the incremental connected components algorithms in the BGL. Those work equally well on directed and undirected graphs. Doug _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

[BGL] Inverting the map from strong_connected
by John Krajewski 01 May '06

01 May '06

Hi all, The function "strong_components" produces a mapping from vertex to component - but what I need is a mapping the other way, from component to vertex! Now of course I could go through the property_map, query each vertex, and create the new map myself, but theres got to be a better way. The map is just a writable_property_map concept, so theoretically I should be able to create my own somehow that will swap the key and value, but I'm not sure how I would do that. Any suggestions? I also want to create a graph of the strongly connected components, but I suppose theres no tricky way to do this - just go through each vertex in the returned map and add its connections to the strong component's connections (though there's probably something tricky I could do with iterators to make this automatic) Thanks for any help, my mind is still adjusting to being warped by this generic programming stuff :)

1 0

[serialization] My archive class + BOOST_CLASS_EXPORT
by Denis Kuznetsov 01 May '06

01 May '06

I have my own archive class (derived from binary_oarchive_impl). And I have a base abstract class and derived classes(non-abstract). I use BOOST_CLASS_EXPORT macro to register my derived classes. But it seems the macro works only for Boost archives, not for user defined archives. Is there any way to register derived classes to get the same functionality that BOOST_CLASS_EXPORT provides?

3 3

filesystem/signals/serialization dlls not linking
by Dave Compton 30 Apr '06

30 Apr '06

When I try to build boost 1_33_1 with mingw ( gcc 3.4.2 ) some libraries don't link properly. At the end of the build process, the following files are missing : boost_filesystem-mgw-1_33_1.dll boost_filesystem-mgw-1_33_1.lib boost_filesystem-mgw-d-1_33_1.dll boost_filesystem-mgw-d-1_33_1.lib boost_filesystem-mgw-d.lib boost_filesystem-mgw-mt-1_33_1.dll boost_filesystem-mgw-mt-1_33_1.lib boost_filesystem-mgw-mt-d-1_33_1.dll boost_filesystem-mgw-mt-d-1_33_1.lib boost_filesystem-mgw-mt-d.lib boost_filesystem-mgw-mt.lib boost_filesystem-mgw.lib boost_serialization-mgw-1_33_1.dll boost_serialization-mgw-1_33_1.lib boost_serialization-mgw-d-1_33_1.dll boost_serialization-mgw-d-1_33_1.lib boost_serialization-mgw-d.lib boost_serialization-mgw-mt-1_33_1.dll boost_serialization-mgw-mt-1_33_1.lib boost_serialization-mgw-mt-d-1_33_1.dll boost_serialization-mgw-mt-d-1_33_1.lib boost_serialization-mgw-mt-d.lib boost_serialization-mgw-mt.lib boost_serialization-mgw.lib boost_signals-mgw-1_33_1.dll boost_signals-mgw-1_33_1.lib boost_signals-mgw-d-1_33_1.dll boost_signals-mgw-d-1_33_1.lib boost_signals-mgw-d.lib boost_signals-mgw-mt-1_33_1.dll boost_signals-mgw-mt-1_33_1.lib boost_signals-mgw-mt-d-1_33_1.dll boost_signals-mgw-mt-d-1_33_1.lib boost_signals-mgw-mt-d.lib boost_signals-mgw-mt.lib boost_signals-mgw.lib I believe that all the other libraries are building successfully. Here are the first few errors that appear in my build log: gcc-Link-action bin\boost\libs\filesystem\build\boost_filesystem.dll\mingw\debug\boost_filesystem-mgw-d-1_33_1.dll bin\boost\libs\filesystem\build\boost_filesystem.dll\mingw\debug\boost_filesystem-mgw-d-1_33_1.lib Creating library file: bin\boost\libs\filesystem\build\boost_filesystem.dll\mingw\debug\boost_filesystem-mgw-d-1_33_1.lib bin\boost\libs\filesystem\build\boost_filesystem.dll\mingw\debug\operations_posix_windows.obj(.text+0x7ac): In function `ZN5boost10filesystem6detail12dir_itr_initERNS_10shared_ptrINS1_11dir_itr_impEEERKNS0_4pathE': c:/cygwin_home/dave/devl/thirdParty/Cygwin/boost/boost_1_33_1x/src/boost_1_33_1/libs/filesystem/build/../src/operations_posix_windows.cpp:308: undefined reference to `boost::filesystem::detail::system_error_code()' bin\boost\libs\filesystem\build\boost_filesystem.dll\mingw\debug\operations_posix_windows.obj(.text+0x81d):c:/cygwin_home/dave/devl/thirdParty/Cygwin/boost/boost_1_33_1x/src/boost_1_33_1/libs/filesystem/build/../src/operations_posix_windows.cpp:308: undefined reference to `boost::filesystem::filesystem_error::filesystem_error(std::string const&, boost::filesystem::path const&, int)' bin\boost\libs\filesystem\build\boost_filesystem.dll\mingw\debug\operations_posix_windows.obj(.text+0x8d7):c:/cygwin_home/dave/devl/thirdParty/Cygwin/boost/boost_1_33_1x/src/boost_1_33_1/libs/filesystem/build/../src/operations_posix_windows.cpp:308: undefined reference to `boost::filesystem::filesystem_error::~filesystem_error()' bin\boost\libs\filesystem\build\boost_filesystem.dll\mingw\debug\operations_posix_windows.obj(.text+0x8f3):c:/cygwin_home/dave/devl/thirdParty/Cygwin/boost/boost_1_33_1x/src/boost_1_33_1/libs/filesystem/build/../src/operations_posix_windows.cpp:308: undefined reference to `boost::filesystem::filesystem_error::~filesystem_error()' So far my work around has been to use 1_33_0 which builds 100% cleanly. Does anyone have any idea either what I might be doing wrong or what is going wrong otherwise. Thanks. - Dave

1 2

[Serialization] Difficulties with export
by Joseph Hosteny 30 Apr '06

30 Apr '06

Thanks for the response. I'd have continued the thread, but I didn't get the original emails from the list to reply to. I tried an explicit registration, with the same results. Also, I did step into the code where the EXPORT macros were being called, and I verified that the pertinent classes were registered in the boost::serialization::detail::ktmap, at least (not sure about the tkmap). It seems like it just doesn't find the class in the oserialization file where the exception is thrown. The serialization is invoked in a const public class method, via "oa << this;" Is there anything tricky you might be aware of that could cause the type comparisons to fail? Could I potentially be missing something in my class? Unfortunately, the project is quite large and it'd fairly difficult to strip out everything and add it back in incrementally.

2 4

[shared_ptr] Problem refeering back to a parent class.
by Eoin 30 Apr '06

30 Apr '06

Hello, I've a question, I don't know if I'm doing something technically wrong or if my whole approach is totally wrong. To explain I have a class (foo) managed by a shared_ptr and it contains a member class (bar) with needs to access some members of foo. So I figure I need some sort of pointer in the bar class back to the foo class. I thought using a weak_ptr was the obvious choice, here is what I came up with it; using namespace boost; class foo; class bar { public: bar(weak_ptr<foo> f) : foo_(f) {} private: weak_ptr<foo> foo_; }; class foo : public boost::enable_shared_from_this<foo> { public: foo() : bar_(shared_from_this()) {} private: bar bar_; }; But I get a boost::bad_weak_ptr error. Now if I use regular pointers instead of weak_ptr's I can get stuff working except that when I use "bar_(this)" in the initialization list for foo MSVC 7.1 gives me a warning, which I don't like. Is there a more appropriate method I should be using to accomplish this. Kind Regards, Eoin.

3 2

String Algorithm: const_cast warning in 1.33.1
by Roman Neuhauser 30 Apr '06

30 Apr '06

The attached patch silences the warnings below in <boost/algorithm/string/split.hpp> (c++ (GCC) 3.4.4 [FreeBSD] 20050518). roman@dagan ~/codex/argv0 1016:0 > cat test.c++ #include <boost/algorithm/string/split.hpp> int main() { return 0; } roman@dagan ~/codex/argv0 1017:0 > c++ -pedantic -Wall -Wextra -Wcast-qual -Wwrite-strings -Wctor-dtor-privacy -Wfloat-equal -Winline -Woverloaded-virtual -Wredundant-decls -Wsign-compare -I/usr/local/include test.c++ /usr/local/include/boost/range/detail/implementation_help.hpp: In function `Char* boost::range_detail::str_end(Char*) [with Char = char]': /usr/local/include/boost/range/end.hpp:98: instantiated from here /usr/local/include/boost/range/detail/implementation_help.hpp:58: warning: cast from `const char*' to `char*' discards qualifiers from pointer target type /usr/local/include/boost/range/detail/implementation_help.hpp: In function `Char* boost::range_detail::str_end(Char*) [with Char = wchar_t]': /usr/local/include/boost/range/end.hpp:103: instantiated from here /usr/local/include/boost/range/detail/implementation_help.hpp:58: warning: cast from `const wchar_t*' to `wchar_t*' discards qualifiers from pointer target type -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991

2 1

Google Summer of Code -- Call for Participation / Schedule
by Jeff Garland 29 Apr '06

29 Apr '06

All - (cross-posted to the user list so the larger Boost community sees this) Readers of the developer list may have seen that Boost has been accepted as a participating organization. See http://code.google.com/soc/boost/about.html for the initial Boost Summer of Code page. Now for the hard part. We have a fairly tight schedule to get organized on project proposals and student applications: May 1, 2006: - Application period opens for student proposals May 8, 2006: -Student proposals due by 17:00 Pacific Daylight Time If you are interested in mentoring or doing a project please let us know as soon as possible. If you have project ideas, please update: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summe… If you want to mentor or are planning a student application please either post to the list or to the moderators list (see http://www.boost.org/more/moderators.html for details). Thx! Jeff

2 1

I/O bug in date_time
by Thomas Lemaire 29 Apr '06

29 Apr '06

** sorry if double posting, but I have not received my first mail, and also no answers... ** Dear list, I encounter a bug while reading a time_duration object, here is a short test case, the results are obtained with boost 1.33.1, gcc4.0.3 using namespace boost::posix_time; time_duration td1(0,0,0); std::stringstream ss1("14:23:11.345678"); ss1 >> td1; std::cout << td1 << std::endl; // 14:23:11.345678 time_duration td2(0,0,0); std::stringstream ss2("18353:23:11.345678"); ss2 >> td2; std::cout << td2 << std::endl; // 18:53:23 time_duration td3(0,0,0); std::stringstream ss3("318353:23:11.345678"); ss3 >> td3; std::cout << td3 << std::endl; // 00:00:00 If I compile with the flag CPPFLAGS += -DUSE_DATE_TIME_PRE_1_33_FACET_IO this works well. I hope this will help to fix it... -- thomas http://www.laas.fr/~tlemaire

2 1

[BGL] Complexity time of algorithms
by Leandro Melo 29 Apr '06

29 Apr '06

Hi. According to the site, most boost graph algorithms guarantee complexity bounds. For instance, DFS and BFS have complexity time O(V + E), Bellman-Ford has complexity O(VE), etc... As fair as I'm concerned (and from the knowledge I have) the complexity time bounds exposed on the graph web pages (like the ones I described above) are usually the 'best' theoretical values for them that can be found in the literature. However, something is still 'dark' for me. Most of this algorithms achieve this time bounds when implemented in a very specialized manner. Boost graph library is NOT like this, since we know it's a very nice generic library. Boost uses Property Maps for a lot of algorithms. My question is whether or not this property maps affect the complexity bounds. For example: In the original implementation of Bellman-Ford (which achieves O(VE)) weights are attached to edges. In boost's implementation, they're in the form of property maps. Right there, there's a change from a constant time operation (edge->get_weight, for example) to a logarithmic time operation (weight_map[edge], for example). I must say that I didn't take carefull look at the algorithms implementations, but it just seems weird to me that the same complexity bounds can still be achieved with those property maps. Can anyone help understand that? Thanks. -- Leandro Terra C. Melo

2 1