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

Removing edges/vertices from a boost.graph object
by Jeff Holle 23 Aug '04

23 Aug '04

I'm using boost.graph captured from CVS on Tue Jun 29 05:25:17 EDT 2004. The type of graph that I'm using is: typedef boost::adjacency_list<boost::vecS,boost::vecS,boost::bidirectionalS> GraphT; I need to trim vertex/edges that was moved to other graphs. I can't seem to do this. Calling remove_vertex appears to be a NOOP. The last thing I tried was: clear_vertex(*vi); remove_vertex(*vi); The gerdemann.cpp example gave me this idea. The clear_vertex did the job that I need in that the necessary edges disappeared. However, the remove_vertex still does not remove the vertexs. What do I have to do to get the ability to clear vertices?

2 2

boost::thread
by Raja 23 Aug '04

23 Aug '04

Does using thread classes from boost need additional library files other than header files ? I am getting the following error when I use the thread class: /usr/include/c++/3.2.3/bits/stl_heap.h:188: undefined reference to `boost::thread::thread[in-charge](boost::function0<void, std::allocator<boost::function_base> > const&)' I also see 'libboost_thread-gcc-mt-d-1_31.so.1.3.0' library under boost/bin/... Does this have to be used ? Thanks in advance Raja

2 1

boost::filesystem problems
by Carlo Wood 23 Aug '04

23 Aug '04

A few months ago I started to write my first multi-platform application. In the hope to be shielded from all kinds of filesystem specific issues, I started to use boost - also for the first time - mainly because of of boost::filesystem. However - I have found that it doesn't shield me from a LOT of filesystem specific things. In the meantime I was in the need of writing six additional functions that are filesystem specific: std::string native_file_string(fs::path const&); void copy_file(fs::path const& source_file, fs::path const& target_file); void chmod(fs::path const& filename, bool readonly); bool is_readonly(fs::path const& filename); void rename_file(fs::path const& source_file, fs::path const& target_file); size_t get_file_size(fs::path const& filename); Today I ran into a very serious problem. Hopefully it is just me who is making a stupid mistake (however unlikely that may sound ;) but it sure seems like a huge bug in boost::filesystem of a magnitude that not only amazes me but will also force me to stop using boost::filesystem if this is true. The reason that I didn't find this problem earlier in the pasts months is because so far I've done all development on GNU/Linux - and only recently have started to actually try and get things to work on cygwin. The reason I subscribed to this list is in the hope to find Beman here, is he reading this list? My hope is to start a public discussion about boost::filesystem - problems, improvements, missing features etc. I will sent a separate mail for the 'serious bug' that I just mentioned, because it isn't 100% sure yet that this is actually a bug ;). -- Carlo Wood <carlo(a)alinoe.com>

13 22

Build with BCB6 failed
by Steffen Rauh 21 Aug '04

21 Aug '04

Hello, creating a custom build, I get lots of compiler errors during Boost.Python compilation. Some of these compiler errors are: c:\...\boost_1_31_0\libs\python\build\../src/numeric.cpp: Error E2231 C:\...\boost_1_31_0\boost/python/detail/value_is_shared_ptr.hpp 14: Member value_is_shared_ptr<X_>::value cannot be used without an object. Error E2299 C:\...\boost_1_31_0\boost/python/detail/value_is_shared_ptr.hpp 14: Cannot generate template specialization from 'mpl::bool_<C_>' Error E2040 C:\...\boost_1_31_0\boost/python/detail/value_is_shared_ptr.hpp 14: Declaration syntax error These error messages repeat in a lot of other files. Sometimes the compiler aborts compilation because of too many errors or warnings. The rest of boost seems to compile fine. Does anybody have an idea on how to solve this problem? Is this difficulty already known? I tried to compile with Python 2.3 at first but switched back to Python 2.2 because I read somewhere that there may be some problems with this version. But it did not solve the problem. I already tried to compile the current CVS Snapshot but it did not change a thing. My configuration is: - Python 2.2 - Boost 1.31.0 - bjam 3.1.10 - Windows XP - Borland C++ Builder 6 Personal Building Boost with: c:\...\boost_1_31_0>bjam -sTOOLS=borland -sPYTHON_ROOT=c:\...\python22 install I would appreciate any suggestions. Regards, Steffen Rauh

3 4

boost erreur
by adel.essafi 20 Aug '04

20 Aug '04

hi list I am using boost to build a small tool that generate a (GRAPHICAL) graph showing dependecies between files ;) I donc guess why g++ returns to me this error. any input will be helpful thanks Ps : excuse me. I will copy all the source file and the error. you can find it a long. #include <qapplication.h> #include <qdir.h> #include <qcanvas.h> #include <iostream.h> #include <vector.h> #include <fstream.h> #include <string.h> #include <fstream> #include <string> #include <iostream> #include <algorithm> #include <string> #include <boost/config.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/property_map.hpp> #include <qstring.h> using namespace std; using namespace boost; enum vertex_first_name_t { vertex_first_name }; namespace boost { BOOST_INSTALL_PROPERTY(vertex, first_name); } template <class EdgeIter, class Graph> void who_owes_who(EdgeIter first, EdgeIter last, const Graph& G) { // Access the propety acessor type for this graph typedef typename property_map<Graph, vertex_first_name_t> ::const_type NamePA; NamePA name = get(vertex_first_name, G); typedef typename boost::property_traits<NamePA>::value_type NameType; NameType src_name, targ_name; while (first != last) { src_name = boost::get(name, source(*first,G)); targ_name = boost::get(name, target(*first,G)); cout << src_name << " owes " << targ_name << " some money" << endl; ++first; } } int main(int argc,char **argv) { // Create the graph, and specify that we will use std::string to // store the first name's. typedef adjacency_list<vecS, vecS, directedS,property<vertex_first_name_t, QString> > MyGraphType; MyGraphType G; property_map<MyGraphType, vertex_first_name_t>::type name= get(vertex_first_name, G); QApplication a( argc, argv ); QCanvas c; QDir dir (".") ; int filesnum=0; QStringList lst = dir.entryList( "*.cpp; *.h" ); for ( QStringList::Iterator it = lst.begin(); it != lst.end(); ++it ) { boost::graph_traits<MyGraphType>::vertex_descriptor v; name[v]=*it; add_vertex(v,G); cerr << *it << endl; filesnum++; } return 0; } g++ -o filetree main.cpp -I /usr/lib/qt-3.1/include -L /usr/lib/qt-3.1/lib -lqt Dans le fichier inclus à partir de /usr/include/c++/3.3.2/backward/iostream.h:31, à partir de main.cpp:4: /usr/include/c++/3.3.2/backward/backward_warning.h:32:2: attention : #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <sstream> instead of the deprecated header <strstream.h>. To disable this warning use -Wno-deprecated. main.cpp: Dans function « int main(int, char**) »: main.cpp:67: error: invalid initialization of reference of type 'const boost::property<vertex_first_name_t, QString, boost::no_property>&' from expression of type 'size_t' /usr/include/boost/graph/detail/adjacency_list.hpp:1916: error: in passing argument 1 of `typename Config::vertex_descriptor boost::add_vertex(typename Config::vertex_property_type&, boost::vec_adj_list_impl<G, C, B>&) [with Graph = boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<vertex_first_name_t, QString, boost::no_property>, boost::no_property, boost::no_property, boost::listS>, Config = boost::detail::adj_list_gen<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<vertex_first_name_t, QString, boost::no_property>, boost::no_property, boost::no_property, boost::listS>, boost::vecS, boost::vecS, boost::directedS, boost::property<vertex_first_name_t, QString, boost::no_property>, boost::no_property, boost::no_property, boost::listS>::config, Base = boost::directed_graph_helper<boost::detail::adj_list_gen<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<vertex_first_name_t, QString, boost::no_property>, boost::no_property, boost::no_property, boost::listS>, boost::vecS, boost::vecS, boost::directedS, boost::property<vertex_first_name_t, QString, boost::no_property>, boost::no_property, boost::no_property, boost::listS>::config>]' gmake: *** [filetree] Erreur 1 *** échec *** 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)

3 2

RE: [Boost-users] New design proposal for boost::filesystem
by Rozental, Gennadiy 20 Aug '04

20 Aug '04

> I propose the following design. The aim of boost::filesystem > should be to support the following coding idiom: I don't think this is a proper forum for this. Try development mailing list Gennadiy.

2 1

RE: [Boost-users] New design proposal for boost::filesystem
by Ben Hutchings 20 Aug '04

20 Aug '04

Carlo Wood <carlo(a)alinoe.com> wrote: > I propose the following design. The aim of boost::filesystem should > be to support the following coding idiom: > > * The programmer should take care to only handle two types of paths > in his application: > > 1) Complete paths > 2) Relative paths Are there any other types? > * The programmer will have to specifically tell the libary when a > constructed path is 'native' and when not. <snip> Sounds reasonable. > I propose two design changes: > > 1) 'native' is now not only a representation, but an *internal > state* of fs::path. (this has no effect on the representation > as returned by fs::path::string()). > 2) All 'complete' paths are automatically marked as 'native'. > > Examples, the following code is legal: > > fs::path p1("C:\foo\a.exe", native); // Fails on linux, > // success on windows. You have that backwards. "\f" and "\a" are not valid in a filename in Win32. Now if those backslashes are changed to "\\" this will work on Win32. Either version of the name will work on Linux because all characters except "\0" are valid in a Unix filename. > fs::path p2("/usr/src/a.out, native); // Fails on windows, > // success on linux. That should work on Windows too because "/" is supported as an alternative to "\\". <snip> > But in case more than one 'working' directory seems needed > then we can add support for that too by allowing to > construct paths with a reference to the (complete/native) > working directory. Ie, > > fs::path home_base(...); > // ... > > fs::path runtime_rcfile(home_base); > // ... > > runtime_rcfile = "myapplication/config/runtime/rc"; > > which is then relative to `home_base' instead of > a single, global 'working directory' (as now returned > by fs::current_path()). <snip> That doesn't seem right to me. Assignment should overwrite the old value rather than combining with it.

2 1

Problems using custom iterator with std::partial_sort_copy
by Martin Magnusson 20 Aug '04

20 Aug '04

I have written a custom iterator based on boost::iterator_facade, and I'm trying to use this with the std::partial_sort_copy algorithm. However, when compiling with g++ I get an error message saying that there is no matching function for a call to counting_iterator(Vertex<3>&). The way I interpret this is that my code is trying to construct a Vertex_Iterator from a Vertex object, but that was not my intenton. Is there something obvious that I have missed in my definition of Vertex_Iterator, which should be a bidirectional iterator? A Vertex_Iterator iterates over the vertices of a mesh, and therefore it needs a pointer to the mesh in question. Does an iterator which returns a Vertex<3>& when dereferenced need a constructor which takes only a Vertex<3>& argument? If so, how can I supply it with the pointer to its parent mesh? I hope that some of this makes sense. ////////////////////////////////////////////// // Some typedefs from the parent class 'Mesh': ////////////////////////////////////////////// class Mesh { public: class Vertex_Iterator; //... private: friend class Vertex_Iterator; typedef boost::property< boost::vertex_root_t, Vertex<3> > Vertex_Property; typedef boost::adjacency_list < boost::vecS, boost::vecS, boost::undirectedS, Vertex_Property > Vertex_Graph; typedef boost::property_map<Vertex_Graph, boost::vertex_root_t>::type Vertex_Data_Map; Vertex_Data_Map its_vertex_data; //... }; ////////////////////////////////////////////// // Definition of my custom iterator: ////////////////////////////////////////////// class Mesh::Vertex_Iterator: public boost::iterator_facade <Vertex_Iterator, Vertex_Graph::vertex_iterator, boost::bidirectional_traversal_tag, Vertex<3>& > { public: Vertex_Iterator() {} explicit Vertex_Iterator( const Mesh* const mesh, Vertex_Graph::vertex_iterator p ) : its_parent( mesh ), its_vertex( p ) {} private: friend class boost::iterator_core_access; Vertex<3>& dereference() const { return its_parent->its_vertex_data[*its_vertex]; } void increment() { ++its_vertex; } void decrement() { --its_vertex; } bool equal( Vertex_Iterator const& other) const { return this->its_vertex == other.its_vertex; } const Mesh* const its_parent; Vertex_Graph::vertex_iterator its_vertex; }; ////////////////////////////////////////////// // The call with an error looks like this: ////////////////////////////////////////////// void Mesh::subset() { //... Compare_Normals compare( its_mean_normal ); Vertex<3> temp_holder[size]; Vertex_Iterator first_vertex( this, boost::vertices( its_vertices ).first ); Vertex_Iterator last_vertex( this, boost::vertices( its_vertices ).second ); std::partial_sort_copy( first_vertex, last_vertex, temp_holder, temp_holder + size, compare ); //... } ////////////////////////////////////////////// // This is gcc's error message: ////////////////////////////////////////////// Building object file Mesh.o... /usr/include/c++/3.3.1/bits/stl_algo.h: In function `_RandomAccessIter std::partial_sort_copy(_InputIter, _InputIter, _RandomAccessIter, _RandomAccessIter, _Compare) [with _InputIter = Mesh::Vertex_Iterator, _RandomAccessIter = Vertex<3>*, _Compare = Mesh::Compare_Normals]': /home/martin/source/scan-match/Mesh.cpp:532: instantiated from here /usr/include/c++/3.3.1/bits/stl_algo.h:2661: error: no matching function for call to `boost::counting_iterator<size_t, boost::use_default, boost::use_default>::counting_iterator(Vertex<3>&)' /usr/local/include/boost/iterator/counting_iterator.hpp:169: error: candidates are: boost::counting_iterator<Incrementable, CategoryOrTraversal, Difference>::counting_iterator(Incrementable) [with Incrementable = size_t, CategoryOrTraversal = boost::use_default, Difference = boost::use_default] /usr/local/include/boost/iterator/counting_iterator.hpp:166: error: boost::counting_iterator<Incrementable, CategoryOrTraversal, Difference>::counting_iterator(const boost::counting_iterator<Incrementable, CategoryOrTraversal, Difference>&) [with Incrementable = size_t, CategoryOrTraversal = boost::use_default, Difference = boost::use_default] /usr/local/include/boost/iterator/counting_iterator.hpp:164: error: boost::counting_iterator<Incrementable, CategoryOrTraversal, Difference>::counting_iterator() [with Incrementable = size_t, CategoryOrTraversal = boost::use_default, Difference = boost::use_default] make[1]: *** [Mesh.o] Error 1 make: *** [default_target] Error 2 Thanks / martin

2 1

[bgl] kamada_kawai_spring_layout
by Gordon Smith 20 Aug '04

20 Aug '04

Just playing with the kamada_kawai_spring_layout , so far for any non trivial graph (more then 4 nodes) - it seems to just go into an infinite loop. The graph is undirected but would contain "circular" paths - thoughts? Gordon.

2 12

New design proposal for boost::filesystem
by Carlo Wood 20 Aug '04

20 Aug '04

I propose the following design. The aim of boost::filesystem should be to support the following coding idiom: * The programmer should take care to only handle two types of paths in his application: 1) Complete paths 2) Relative paths * The programmer will have to specifically tell the libary when a constructed path is 'native' and when not. A native path is accepted according to native rules and never gives any problem (exceptions) further on. A non-native path is checked according to the existing rules, which basically means that the programmer can set a default check routine that will in effect determine how portable the application will be. I propose two design changes: 1) 'native' is now not only a representation, but an *internal state* of fs::path. (this has no effect on the representation as returned by fs::path::string()). 2) All 'complete' paths are automatically marked as 'native'. Examples, the following code is legal: fs::path p1("C:\foo\a.exe", native); // Fails on linux, success on windows. fs::path p2("/usr/src/a.out, native); // Fails on windows, success on linux. std::cout << p1.native_file_string(); // ok, p1 is native. fs::path p3("foo/bar"); // Relative path, always succeeds. std::cout << p.string(); // ok std::cout << p.native_directory_string(); // Useless, but ok. fs::path p4(complete(p3)); // p4 is now "native", because now it is complete. std::cout << p4.native_directory_string(); // ok And the following will throw: std::cout << p4.string() // Not allowed because p4 is native (complete). Since there would be a default way defined of how a relative path is completed, all operation functions will accept both, relative and complete paths. For example: fs::path p1("C:\cygwin\usr/bin/ls", native); // Legal path on Cygwin. if (fs::exists(p1)) // Ok, access complete path. // For clarification fs::path p2("C:\cygwin\usr"); // Just an example fs::default_working_directory(p2); // fictuous function. fs::path p3("bin/ls"); // Portable representation (refers in fact to "C:\cygwin\usr\bin\ls.exe"). if (fs::exists(p3)) // Ok : exists() will make the path complete before testing. And this throws: fs::path p4("/bin/ls"); // Not allowed: this path has a root but is not marked 'native'. Setting the default_working_directory shall allways need to be done for each supported OS seperately. Of course you can set it to "/" on single root machines, and set it to "E:/" after extracting the 'E:' from the current path at application start up, in effect simulating a 'single root': int main() { fs::default_working_directory(fs::current_path().root_path()); // ... simulate single root machine below. fs::path p("bin/ls"); } The average application will work with relative paths, relative to some (native) base directory and next to that have some arbitrary, complete and thus native directories (ie, read from environment variables). But in case more than one 'working' directory seems needed then we can add support for that too by allowing to construct paths with a reference to the (complete/native) working directory. Ie, fs::path home_base(...); // ... fs::path runtime_rcfile(home_base); // ... runtime_rcfile = "myapplication/config/runtime/rc"; which is then relative to `home_base' instead of a single, global 'working directory' (as now returned by fs::current_path()). Most of the current boost::filesystem API can be preserved with this design. -- Carlo Wood <carlo(a)alinoe.com>

1 0