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

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

Question about static linking of boost
by Daniel Huber 20 Aug '04

20 Aug '04

Thanks to Stephen for helping me get my boost to link. I feel bad for not thinking of this solution myself. I have one final question/suggestion about the getting started document (which I found to be very well written). I compile and install boost using the following command: tools/build/jam_src/bin.linuxx86/bjam "-sTOOLS=gcc" "-sBUILD=release <runtime-link>static" --prefix=$HOME/linux/lib/boost install My goal was to create a minimal set of boost libraries (basically, I just need the filesystem non-debug static version. I was surprised to find that the above command installs shared libraries for some of the libraries, and it also installs both the -s- version of the static libraries and the -sd- version. It seems to me that this might be a bug, since I specifically requested only the release version. Am I confused about the difference between release version and debug version? Also, I am confused about the meaning of the -s- flag in the runtime section of the filename. Why do we get libraries that are shared but have the -s- flag? That seems like a contradiction. Similarly, if I don't specify static linking using the -sBUILD option (I assume the absence of the -s- flag means dynamic implicitly), I still get static libraries (i.e. .a extension files). These files seem to be unusable more or less (when I try to link against them, the compiler uses the shared libraries instead even if they don't exist). Anyway, all this is not much use to me, since I have it working now, but maybe someone could add a bit of text to the getting started document explaining this. Also, it might be helpful to give an example compile command that shows linking in the boost libraries. Thanks again for all your help. Sincerely, Daniel

2 1

Using boost::date_time for timezones
by Duncan Woods 19 Aug '04

19 Aug '04

Hello All, I'm new to Boost and interested in using it for timezone conversions but I'm not finding it terribly clear. An example, which works fine, uses something of the form: typedef boost::date_time::local_adjustor<ptime, -5, us_dst> us_eastern; 1. My problem is that I wish to use DST settings other than US and found definitions such as eu_dst_trait in local_timezone_defs.hpp but these seem unused and unusable. Would it require implementation of dst_rules.hpp type classes? If so, Boost would not give much advantage. 2. I would also have liked to specify dst & timezone combinations at run-time which dynamic_local_time_adjustor sounds like it might do - but it appears to have no members. 3. Will date_time use the 'tz database' in the future? Thank you in advance, Duncan

2 4

Inter Process Communication lib?
by Fernando Cacciola 19 Aug '04

19 Aug '04

Just a silly question... none of the boost libs provides cross platform IPC right? Txs Fernando Cacciola SciSoft

2 2

File size and attributes
by Surya Kiran Gullapalli 19 Aug '04

19 Aug '04

Hi all, I'm new to Boost library, working with boost-1.31.0. I'm trying to find out the size of the file and its attributes (hidden, readonly etc) using boost filesystem library. I had a go at the documentation, but did not get much help. Thanks in advance, Surya

1 0

mpl::switch question
by Istvan Buki 18 Aug '04

18 Aug '04

Hello, I've just tried to compile a small piece of code using mpl::switch_ starting from an example Aleksey Gurtovoy sent to this list a while ago. I slightly modified the code to use the boost::is_same<T,U> template but I can't make it compile. On the other hand, if I comment out the line in the switch_body containing the is_same template, it compile without any problem. I spent the whole day on this and I'm lost. Any help would be welcome. Thanks, Istvan PS: I'm using boost 1.30.2 and g++ 3.3.3. #include "boost/mpl/vector.hpp" #include "boost/mpl/switch.hpp" #include "boost/mpl/project1st.hpp" #include "boost/mpl/pair.hpp" #include "boost/mpl/always.hpp" #include "boost/mpl/bool.hpp" #include "boost/mpl/assert_is_same.hpp" #include "boost/type_traits/remove_reference.hpp" #include "boost/type_traits/add_const.hpp" #include "boost/type_traits/is_pointer.hpp" #include "boost/type_traits/is_reference.hpp" #include "boost/type_traits/is_same.hpp" using namespace boost::mpl ; using boost::mpl::_ ; struct MyType { typedef int type ; } ; int main() { typedef vector< pair< boost::is_pointer<_1>, _1 > // If the following line is commented out it compile. , pair< boost::is_same<_1, _1 >, boost::add_const<_1> > , pair< boost::is_reference<_1>, boost::remove_reference<_1> > , pair< always<bool_<true > >, boost::add_const<_1> > > switch_body; typedef switch_< switch_body, char& >::type t1; typedef switch_< switch_body, int* >::type t2; typedef switch_< switch_body, int >::type t3; BOOST_MPL_ASSERT_IS_SAME(t1, char); BOOST_MPL_ASSERT_IS_SAME(t2, int*); BOOST_MPL_ASSERT_IS_SAME(t3, int const); }

1 0

RE: [Boost-users] regex: match_results::const_reference is someti messub_match<Bidi Iterator>, sometimes const char?
by Richard Reitmeyer 17 Aug '04

17 Aug '04

Thanks for your help. (And all the effort that went into the regex library.) I'm using 1.31.0 (unpatched). After a more careful examination, my problem was that I was passing the wrong kind of allocator as a template parameter. Richard > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of John Maddock > Sent: Tuesday, August 17, 2004 5:33 AM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] regex: > match_results::const_reference is sometimessub_match<Bidi > Iterator>, sometimes const char? > > > > The regex library is extremely helpful: thanks for all your efforts. > > > > I've got a problem with gcc and stlport and boost: when I try > > to get a submatch on other platforms, I can take my match object, m, > > and do things like > > > > m[n].str(); // works great elsewhere > > > > But with gcc / stlport, with BOOST_NO_STD_ALLOCATOR not defined, > > the const_reference type is defined as Allocator::const_reference > > (which is `const char'), rather than sub_match<BidiIterator>. > > So operator[] gives me a char, and life isn't so good. > > > > Any hints as to where I went astray? > > Works for me (with Boost-1.31.0 + latest patches), what > version are you > using? > > John. > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users >

1 0

BGL-kamada_kawai_spring_layout
by Gordon Smith 17 Aug '04

17 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.

1 0