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

problems compiling example files
by MarC 24 Aug '04

24 Aug '04

I suppose, it's a begginer's linux problem but I didn't found the answer neither in the documentation nor in the internet forums... After installing boost on my system (see how at the end of this email), I wanted to compile simple_ls.cpp, the filesystem example. everything works when creating the .o but when linking a lot of undefined references arised. What have I done wrong? g++ -c simple_ls.cpp [marc@localhost ls]$ g++ -c simple_ls.cpp [marc@localhost ls]$ ls ls/ simple_ls.cpp* simple_ls.o [marc@localhost ls]$ g++ simple simple_ls.cpp simple_ls.o [marc@localhost ls]$ g++ simple_ls.cpp -o simple_ls /tmp/ccjMYBxo.o(.text+0x19): In function `main': : undefined reference to `boost::filesystem::initial_path()' /tmp/ccjMYBxo.o(.text+0x44): In function `main': : undefined reference to `boost::filesystem::native(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' /tmp/ccjMYBxo.o(.text+0x55): In function `main': : undefined reference to `boost::filesystem::path::path[in-charge](char const*, bool (*)(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&))' /tmp/ccjMYBxo.o(.text+0x64): In function `main': : undefined reference to `boost::filesystem::system_complete(boost::filesystem::path const&)' /tmp/ccjMYBxo.o(.text+0x119): In function `main': : undefined reference to `boost::filesystem::exists(boost::filesystem::path const&)' /tmp/ccjMYBxo.o(.text+0x13c): In function `main': : undefined reference to `boost::filesystem::path::native_file_string() const' /tmp/ccjMYBxo.o(.text+0x1bf): In function `main': : undefined reference to `boost::filesystem::is_directory(boost::filesystem::path const&)' /tmp/ccjMYBxo.o(.text+0x1e2): In function `main': : undefined reference to `boost::filesystem::path::native_directory_string() const' /tmp/ccjMYBxo.o(.text+0x291): In function `main': : undefined reference to `boost::filesystem::is_directory(boost::filesystem::path const&)' /tmp/ccjMYBxo.o(.text+0x2ca): In function `main': : undefined reference to `boost::filesystem::path::leaf() const' /tmp/ccjMYBxo.o(.text+0x351): In function `main': : undefined reference to `boost::filesystem::path::leaf() const' /tmp/ccjMYBxo.o(.text+0x418): In function `main': : undefined reference to `boost::filesystem::path::leaf() const' /tmp/ccjMYBxo.o(.text+0x586): In function `main': : undefined reference to `boost::filesystem::path::native_file_string() const' /tmp/ccjMYBxo.o(.gnu.linkonce.t._ZN5boost10filesystem18directory_iteratorC1ERKNS0_4pathE+0x2d): In function `boost::filesystem::directory_iterator::directory_iterator[in-charge](boost::filesystem::path const&)': : undefined reference to `boost::filesystem::detail::dir_itr_init(boost::shared_ptr<boost::filesystem::detail::dir_itr_imp>&, boost::filesystem::path const&)' /tmp/ccjMYBxo.o(.gnu.linkonce.t._ZNK5boost10filesystem18directory_iterator11dereferenceEv+0xd): In function `boost::filesystem::directory_iterator::dereference() const': : undefined reference to `boost::filesystem::detail::dir_itr_dereference(boost::shared_ptr<boost::filesystem::detail::dir_itr_imp> const&)' /tmp/ccjMYBxo.o(.gnu.linkonce.t._ZN5boost10filesystem18directory_iterator9incrementEv+0xd): In function `boost::filesystem::directory_iterator::increment()': : undefined reference to `boost::filesystem::detail::dir_itr_increment(boost::shared_ptr<boost::filesystem::detail::dir_itr_imp>&)' collect2: ld returned 1 exit status thank you in advance again. PS: my system is: [marc@localhost html]$ g++ -v Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.2/specs Configured with: ../configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++,ada,f77,objc,java,pascal --host=i586-mandrake-linux-gnu --with-system-zlib Thread model: posix gcc version 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk) And i've installed boost using these packages: Nombre: libboost1 Versión: 1.31.0-5mdk ‎/usr/lib/libboost_date_time.so.1 ‎/usr/lib/libboost_date_time.so.1.31.0 ‎/usr/lib/libboost_filesystem.so.1 ‎/usr/lib/libboost_filesystem.so.1.31.0 ‎/usr/lib/libboost_prg_exec_monitor.so.1 ‎/usr/lib/libboost_prg_exec_monitor.so.1.31.0 ‎/usr/lib/libboost_python.so.1 ‎/usr/lib/libboost_python.so.1.31.0 ‎/usr/lib/libboost_regex.so.1 ‎/usr/lib/libboost_regex.so.1.31.0 ‎/usr/lib/libboost_signals.so.1 ‎/usr/lib/libboost_signals.so.1.31.0 ‎/usr/lib/libboost_test_exec_monitor.so.1 ‎/usr/lib/libboost_test_exec_monitor.so.1.31.0 ‎/usr/lib/libboost_thread.so.1 ‎/usr/lib/libboost_thread.so.1.31.0 ‎/usr/lib/libboost_unit_test_framework.so.1 ‎/usr/lib/libboost_unit_test_framework.so.1.31.0 ‎/usr/share/doc/libboost1-1.31.0 ‎/usr/share/doc/libboost1-1.31.0/LICENSE_1_0.txt Nombre: libboost1-devel Versión: 1.31.0-5mdk Archivos: ‎/usr/include/boost ‎/usr/include/boost/aligned_storage.hpp ‎/usr/include/boost/any.hpp ‎/usr/include/boost/array.hpp ‎/usr/include/boost/assert.hpp ‎/usr/include/boost/bind ‎/usr/include/boost/bind.hpp ‎/usr/include/boost/bind/apply.hpp ‎/usr/include/boost/bind/arg.hpp ‎/usr/include/boost/bind/bind_cc.hpp ‎/usr/include/boost/bind/bind_mf_cc.hpp ‎/usr/include/boost/bind/bind_template.hpp ‎/usr/include/boost/bind/make_adaptable.hpp ‎/usr/include/boost/bind/mem_fn_cc.hpp ‎/usr/include/boost/bind/mem_fn_template.hpp ‎/usr/include/boost/bind/mem_fn_vw.hpp ‎/usr/include/boost/bind/placeholders.hpp ‎/usr/include/boost/bind/protect.hpp ‎/usr/include/boost/blank.hpp ‎/usr/include/boost/blank_fwd.hpp ‎/usr/include/boost/call_traits.hpp ... /usr/lib/libboost_date_time.so ‎/usr/lib/libboost_filesystem.so ‎/usr/lib/libboost_prg_exec_monitor.so ‎/usr/lib/libboost_python.so ‎/usr/lib/libboost_regex.so ‎/usr/lib/libboost_signals.so ‎/usr/lib/libboost_test_exec_monitor.so ‎/usr/lib/libboost_thread.so ‎/usr/lib/libboost_unit_test_framework.so ‎/usr/share/doc/libboost1-devel-1.31.0 ‎/usr/share/doc/libboost1-devel-1.31.0/README ‎/usr/share/doc/libboost1-devel-1.31.0/boost.css ‎/usr/share/doc/libboost1-devel-1.31.0/c++boost.gif Nombre: libboost1-static-devel Versión: 1.31.0-5mdk ‎/usr/lib/libboost_date_time.a ‎/usr/lib/libboost_filesystem.a ‎/usr/lib/libboost_prg_exec_monitor.a ‎/usr/lib/libboost_python.a ‎/usr/lib/libboost_regex.a ‎/usr/lib/libboost_signals.a ‎/usr/lib/libboost_test_exec_monitor.a ‎/usr/lib/libboost_unit_test_framework.a

3 2

boost.graph question concerning edge descriptor details
by Jeff Holle 23 Aug '04

23 Aug '04

I'm using gcc v3.4.1 and boost_CVS captured on Tue Jun 29 05:25:17 EDT 2004. I'm developing a boost.graph application that must deal with multiple graphs. The following typedefs describe how its using boost.graph: typedef boost::adjacency_list<boost::vecS,boost::vecS,boost::bidirectionalS> GraphT; typedef boost::shared_ptr<GraphT> GraphPtr; typedef boost::graph_traits <GraphT>::vertex_descriptor Vertex; typedef boost::graph_traits <GraphT>::edge_descriptor Edge; In addition, I have various maps that must act as a "bridge" between these graphs. I'm using the following typedefs as keys in such maps: typedef std::pair<GraphPtr,Vertex> ExternalVertex; typedef std::pair<GraphPtr,Edge> ExternalEdge; I've used ExternalVertex successfully in two different maps. Now I'm having trouble populating the first map that uses ExternalEdge. The compiler warnings that I'm getting sugguest that Edge does have an "operator<" method. Specifically its: error: no match for 'operator<' in '__x->std::pair<GraphPtr, Edge>::second < __y->std::pair<GraphPtr, Edge>::second' I'm wondering why Edge is different from Vertex. As you can see, as I've defined GraphT, both edge and vertex properties should be no_property. Any guidance that assists me to, at worst case, write a Compare operator for my "map<ExternalEdge,...>" containers would be appreciated.

2 3

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

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

Additional information on linking problems
by Daniel Huber 17 Aug '04

17 Aug '04

Hi, I have done some additional testing on th eproblem that I reported yesterday, and I have found that the problem I was having with static linking under gcc 2.95.3 also occurs on gcc 3.2.2. I get basically the same error message (see below). I guess that the reason I get the message for the static linking but not for the dynamic linking might be that the undefined references in a shared library are ok as long as those functions are not called. Is that correct? I looked at the code, and as far as I can tell, the functions that the compiler is complaining about are in fact defined. Does anyone have any suggestions? Thanks, Daniel g++ -L $HOME/linux/lib/boost/lib -static -lboost_filesystem -gcc -I $HOME/linux/lib/boost/include/boost-1_31 test_boost.cxx /tmp/ccP4gcx3.o(.text+0x19): In function `main': : undefined reference to `boost::filesystem::initial_path()' /tmp/ccP4gcx3.o(.text+0x3e): In function `main': : undefined reference to `boost::filesystem::native(std::basic_string<char, std: :char_traits<char>, std::allocator<char> > const&)' /tmp/ccP4gcx3.o(.text+0x4f): In function `main': : undefined reference to `boost::filesystem::path::path[in-charge](char const*, bool (*)(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&))' /tmp/ccP4gcx3.o(.text+0x5f): In function `main': : undefined reference to `boost::filesystem::system_complete(boost::filesystem:: path const&)' /tmp/ccP4gcx3.o(.text+0x114): In function `main': : undefined reference to `boost::filesystem::exists(boost::filesystem::path cons t&)' /tmp/ccP4gcx3.o(.text+0x137): In function `main': : undefined reference to `boost::filesystem::path::native_file_string() const' /tmp/ccP4gcx3.o(.text+0x1ba): In function `main': : undefined reference to `boost::filesystem::is_directory(boost::filesystem::pat h const&)' /tmp/ccP4gcx3.o(.text+0x1dd): In function `main': : undefined reference to `boost::filesystem::path::native_directory_string() con st' /tmp/ccP4gcx3.o(.text+0x28c): In function `main': : undefined reference to `boost::filesystem::is_directory(boost::filesystem::pat h const&)' /tmp/ccP4gcx3.o(.text+0x2c0): In function `main': : undefined reference to `boost::filesystem::path::leaf() const' /tmp/ccP4gcx3.o(.text+0x342): In function `main': : undefined reference to `boost::filesystem::path::leaf() const' /tmp/ccP4gcx3.o(.text+0x404): In function `main': : undefined reference to `boost::filesystem::path::leaf() const' /tmp/ccP4gcx3.o(.text+0x572): In function `main': : undefined reference to `boost::filesystem::path::native_file_string() const' /tmp/ccP4gcx3.o(.gnu.linkonce.t._ZN5boost10filesystem18directory_iteratorC1ERKNS 0_4pathE+0x1f): In function `boost::filesystem::directory_iterator::directory_it erator[in-charge](boost::filesystem::path const&)': : undefined reference to `boost::filesystem::detail::dir_itr_init(boost::shared_ ptr<boost::filesystem::detail::dir_itr_imp>&, boost::filesystem::path const&)' /tmp/ccP4gcx3.o(.gnu.linkonce.t._ZNK5boost10filesystem18directory_iterator11dere ferenceEv+0xd): In function `boost::filesystem::directory_iterator::dereference( ) const': : undefined reference to `boost::filesystem::detail::dir_itr_dereference(boost:: shared_ptr<boost::filesystem::detail::dir_itr_imp> const&)' /tmp/ccP4gcx3.o(.gnu.linkonce.t._ZN5boost10filesystem18directory_iterator9increm entEv+0xd): In function `boost::filesystem::directory_iterator::increment()': : undefined reference to `boost::filesystem::detail::dir_itr_increment(boost::sh ared_ptr<boost::filesystem::detail::dir_itr_imp>&)' collect2: ld returned 1 exit status

2 1

regex: match_results::const_reference is sometimes sub_match<Bidi Iterator>, sometimes const char?
by Richard Reitmeyer 17 Aug '04

17 Aug '04

Hello, all. 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? Richard

2 1

minimal use of strong_components
by Michael W Daniels 16 Aug '04

16 Aug '04

boost 1.31.0, msvc 7.1 I'm trying to understand how to use the BGL and the strong_components algorithm in particular. From the example in the documentation, it seems like this minimal file should compile: ==test.cpp== #include <boost/graph/adjacency_list.hpp> #include <boost/graph/strong_components.hpp> #include <string> using namespace std; using namespace boost; typedef adjacency_list<setS, setS, bidirectionalS, property<vertex_name_t, string> > Graph; int testcomps() { Graph gramgraph; vector<int> component(num_vertices(gramgraph)); return strong_components(gramgraph, &component[0]); } ==end== Instead, I get the error below. It seems as though it doesn't like the component map type, but I don't know what I should use instead. Any help anyone could provide would be appreciated. ==error== Compiling... test.cpp e:\boost-msvc\include\boost-1_31\boost\property_map.hpp(159) : error C2664: 'const T &get<std::allocator<_Ty>::value_type>(const T *,ptrdiff_t)' : cannot convert parameter 2 from 'Vertex ' to 'ptrdiff_t' with [ T=std::allocator<int>::value_type, _Ty=int ] This conversion requires a reinterpret_cast, a C-style cast or function-style cast e:\boost-msvc\include\boost-1_31\boost\property_map.hpp(156) : while compiling class-template member function 'void boost::ReadablePropertyMapConcept<PMap,Key>::constraints(void)' with [ PMap=int *__w64 , Key=Vertex ] e:\boost-msvc\include\boost-1_31\boost\concept_check.hpp(49) : see reference to class template instantiation 'boost::ReadablePropertyMapConcept<PMap,Key>' being compiled with [ PMap=int *__w64 , Key=Vertex ] e:\boost-msvc\include\boost-1_31\boost\property_map.hpp(215) : see reference to function template instantiation 'void boost::function_requires<boost::ReadablePropertyMapConcept<PMap,Key>>(boost::mpl::identity<T> *)' being compiled with [ PMap=int *__w64 , Key=Vertex , T=boost::ReadablePropertyMapConcept<int *__w64 ,Vertex > ] e:\boost-msvc\include\boost-1_31\boost\property_map.hpp(214) : while compiling class-template member function 'void boost::ReadWritePropertyMapConcept<PMap,Key>::constraints(void)' with [ PMap=int *__w64 , Key=Vertex ] e:\boost-msvc\include\boost-1_31\boost\concept_check.hpp(49) : see reference to class template instantiation 'boost::ReadWritePropertyMapConcept<PMap,Key>' being compiled with [ PMap=int *__w64 , Key=Vertex ] e:\boost-msvc\include\boost-1_31\boost\graph\strong_components.hpp(111) : see reference to function template instantiation 'void boost::function_requires<boost::ReadWritePropertyMapConcept<PMap,Key>>(boost::mpl::identity<T> *)' being compiled with [ PMap=int *__w64 , Key=Vertex, T=boost::ReadWritePropertyMapConcept<int *__w64 ,Vertex> ] e:\boost-msvc\include\boost-1_31\boost\graph\strong_components.hpp(166) : see reference to function template instantiation 'boost::property_traits<PA>::value_type boost::detail::strong_components_impl<Graph,ComponentMap,RootMap,boost::iterator_property_map<RandomAccessIterator,IndexMap,T,R>,int,int,boost::no_property>(const Graph &,ComponentMap,RootMap,DiscoverTime,const boost::bgl_named_params<int,Tag> &)' being compiled with [ PA=std::allocator<int>::value_type *__w64 , Graph=Graph, ComponentMap=std::allocator<int>::value_type *__w64 , RootMap=boost::iterator_property_map<std::vector<Vertex>::iterator,boost::detail::choose_pmap_helper<boost::property_value<boost::bgl_named_params<int,int>,boost::vertex_index_t>::type,Graph,boost::vertex_index_t>::const_result_type,std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>>,boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>,boost::no_property,boost::no_property,boost::listS>::config::vertex_ptr RootMap=boost::iterator_property_map<std::vector<Vertex>::iterator,boost::detail::choose_pmap_helper<boost::property_value<boost::bgl_named_params<int,int>,boost::vertex_index_t>::type,Graph,boost::vertex_index_t>::const_result_type,std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>>,boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>,boost::no_property,boost::no_property,boost::listS>::config::vertex_ptr >::value_type,std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>>,boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>,boost::no_property,boost::no_property,boost::listS>::config::vertex_ptr >::value_type & >, RandomAccessIterator=std::vector<size_type>::iterator, IndexMap=boost::detail::choose_pmap_helper<boost::property_value<boost::bgl_named_params<int,int>,boost::vertex_index_t>::type,Graph,boost::vertex_index_t>::const_result_type, T=std::allocator<size_type>::value_type, R=std::allocator<size_type>::value_type &, DiscoverTime=boost::iterator_property_map<std::vector<size_type>::iterator,boost::detail::choose_pmap_helper<boost::property_value< boost::bgl_named_params<int,int>,boost::vertex_index_t>::type,Graph,boost::vertex_index_t>::const_result_type,std::allocator<size_type>::value_type,std::allocator<size_type>::value_type &>, Tag=int ] e:\boost-msvc\include\boost-1_31\boost\graph\strong_components.hpp(179) : see reference to function template instantiation 'boost::property_traits<PA>::value_type boost::detail::strong_comp_dispatch2<boost::detail::error_property_not_found>::apply<Graph,ComponentMap,RootMap,int,int,boost::no_property>(const Graph &,ComponentMap,RootMap,const boost::bgl_named_params<T,Tag> &,boost::detail::error_property_not_found)' being compiled with [ PA=std::allocator<int>::value_type *__w64 , Graph=Graph, ComponentMap=std::allocator<int>::value_type *__w64 , RootMap=boost::iterator_property_map<std::vector<Vertex>::iterator,boost::detail::choose_pmap_helper<boost::property_value<boost::bgl_named_params<int,int>,boost::vertex_index_t>::type,Graph,boost::vertex_index_t>::const_result_type,std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>>,boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>,boost::no_property,boost::no_property,boost::listS>::config::vertex_ptr RootMap=boost::iterator_property_map<std::vector<Vertex>::iterator,boost::detail::choose_pmap_helper<boost::property_value<boost::bgl_named_params<int,int>,boost::vertex_index_t>::type,Graph,boost::vertex_index_t>::const_result_type,std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>>,boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>,boost::no_property,boost::no_property,boost::listS>::config::vertex_ptr >::value_type,std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>>,boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>,boost::no_property,boost::no_property,boost::listS>::config::vertex_ptr >::value_type & >, T=int, Tag=int ] e:\boost-msvc\include\boost-1_31\boost\graph\strong_components.hpp(216) : see reference to function template instantiation 'boost::property_traits<PA>::value_type boost::detail::scc_helper2<Graph,ComponentMap,boost::iterator_property_map<RandomAccessIterator,IndexMap,T,R>,int,int,boost::no_property,boost::property_value<PropertyList,Tag>::type>(const Graph &,ComponentMap,RootMap,const boost::bgl_named_params<int,int> &,DiscoverTimeMap)' being compiled with [ PA=std::allocator<int>::value_type *__w64 , Graph=Graph, ComponentMap=std::allocator<int>::value_type *__w64 , RandomAccessIterator=std::vector<Vertex>::iterator, IndexMap=boost::detail::choose_pmap_helper<boost::property_value<boost::bgl_named_params<int,int>,boost::vertex_index_t>::type,Graph,boost::vertex_index_t>::const_result_type, T=std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>>,boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>,boost::no_property,boost::no_property,boost::listS>::config::vertex_ptr T=std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>>,boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>,boost::no_property,boost::no_property,boost::listS>::config::vertex_ptr >::value_type, R=std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>>,boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>,boost::no_property,boost::no_property,boost::listS>::config::vertex_ptr R=std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>>,boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>,boost::no_property,boost::no_property,boost::listS>::config::vertex_ptr >::value_type & , PropertyList=boost::bgl_named_params<int,int>, Tag=boost::vertex_discover_time_t, RootMap=boost::iterator_property_map<std::vector<Vertex>::iterator,boost::detail::choose_pmap_helper<boost::property_value<boost::bgl_named_params<int,int>,boost::vertex_index_t>::type,Graph,boost::vertex_index_t>::const_result_type,std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,b oost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>>,boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>,boost::no_property,boost::no_property,boost::listS>::config::vertex_ptr >::value_type,std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>>,boost::setS,boost::setS,boost::bidirectionalS,boost::property<boost::vertex_name_t,std::string>,boost::no_property,boost::no_property,boost::listS>::config::vertex_ptr >::value_type & >, DiscoverTimeMap=boost::property_value<boost::bgl_named_params<int,int>,boost::vertex_discover_time_t>::type ] e:\boost-msvc\include\boost-1_31\boost\graph\strong_components.hpp(229) : see reference to function template instantiation 'boost::property_traits<PA>::value_type boost::detail::strong_comp_dispatch1<boost::detail::error_property_not_found>::apply<Graph,ComponentMap,int,int,boost::no_property>(const Graph &,ComponentMap,const boost::bgl_named_params<T,Tag> &,boost::detail::error_property_not_found)' being compiled with [ PA=std::allocator<int>::value_type *__w64 , Graph=Graph, ComponentMap=std::allocator<int>::value_type *__w64 , T=int, Tag=int ] e:\boost-msvc\include\boost-1_31\boost\graph\strong_components.hpp(243) : see reference to function template instantiation 'boost::property_traits<PA>::value_type boost::detail::scc_helper1<Graph,ComponentMap,boost::property_value<PropertyList,Tag>::type,int,int,boost::no_property>(const Graph &,ComponentMap,const boost::bgl_named_params<T,int> &,RootMap)' being compiled with [ PA=std::allocator<int>::value_type *__w64 , Graph=Graph, ComponentMap=std::allocator<int>::value_type *__w64 , PropertyList=boost::bgl_named_params<int,int>, Tag=boost::vertex_root_t, T=int, RootMap=boost::property_value<boost::bgl_named_params<int,int>,boost::vertex_root_t>::type ] e:\boost-msvc\include\boost-1_31\boost\graph\strong_components.hpp(253) : see reference to function template instantiation 'boost::property_traits<PA>::value_type boost::strong_components<Graph,ComponentMap,int,int,boost::no_property>(const Graph &,ComponentMap,const boost::bgl_named_params<T,Tag> &)' being compiled with [ PA=std::allocator<int>::value_type *__w64 , Graph=Graph, ComponentMap=std::allocator<int>::value_type *__w64 , T=int, Tag=int ] e:\Projects\gidlp\parser\test.cpp(13) : see reference to function template instantiation 'boost::property_traits<PA>::value_type boost::strong_components<Graph,std::allocator<_Ty>::value_type*__w64 >(const Graph &,ComponentMap)' being compiled with [ PA=std::allocator<int>::value_type *__w64 , _Ty=int, Graph=Graph, ComponentMap=std::allocator<int>::value_type *__w64 ] ==end==

1 0

RTTI for VC 6
by Samuel 16 Aug '04

16 Aug '04

VC 6 has an option for Run-Time Type Information (RTTI) that is normally off. I was able to compile and execute a sample program that had a problem. I noticed that Boost uses RTTI (such as the dynamic_cast operator), so I checked to see if the option was on; it was not. I turned the option on and the program worked. That problem is probably a known problem, but something such as the following can be added somewhere to not allow a VC 6 program to even compile if the RTTI option is off. I think it could make things a little easier for some beginners. # if !defined(_CPPRTTI) # error "Boost requires use of RTTI" # endif

6 22

Re: [Boost-users] Re: RTTI for VC 6
by Samuel 16 Aug '04

16 Aug '04

[The message I am replying to was sent from a newsgroup and I am sending my reply (this) as a message to the list.] "Edward Diener" <eddielee(a)tropicsoft.com> wrote in message news:cfmhi0$4fd$1@sea.gmane.org... > > What Mr. Dimov is saying is that it is impossible to place the code you > would like to use above in Boost because it would affect other Boost > libraries which do not need RTTI to work. That's no problem. The Boost headers already have more than 400 (including comment) lines that test for the "BOOST_MSVC" preprocessor symbol. In other words, there is already an abundance of code that is relevant only to MS VC. > Furthermore if it were placed in > the header file of a library which did need RTTI to work, just including > that header file, without actually using code in it that needed RTTI such as > dynamic_cast, would cause an immediate compile time error. Perhaps. I hope, though, that the possibility that it might not be useful won't prevent someone from communicating the idea to someone familiar with the relevant headers, since there is a possibility that it might be useful. I have more confidence in the developers that a solution is possible. I might have missed something, but I don't understand why it is relevant to say that it won't work. It might not work, but it might work. Yet you are saying it definitely won't work. That seems innapropriate to me.

2 2

RE: [Boost-users] RTTI for VC 6
by Bjorn.Karlsson＠readsoft.com 16 Aug '04

16 Aug '04

Enough of this. There will be no more insults, and no more blame, in this thread. Please try again, in a more productive manner. Thanks, Bjorn Karlsson Moderator [Everything snipped]

1 0