- Boost-users - lists.boost.org

[program_options] setting defaults
by Liam Routt 15 Mar '05

15 Mar '05

Part one: I spent yesterday trying to use a char * to set the default for a string option: opts.add_option("config", "Set the config file to examine", po::value<string>()->default_value("newconfig")); The result was a segmentation fault or illegal instruction during the destruction of my opts class (a wrapper that has several options_descriptions and a positional_options_description; there are methods like the add_option() above that allow various options to be set, in general they put the value_semantic argument last, but otherwise pass arguments directly through). So today I realized that passing a char * to something expecting a std:string might be asking for trouble. So I tried this: string DefaultConfig("newconfig"); opts.add_option("config", "Set the config file to examine", po::value<string>()->default_value(DefaultConfig)); That didn't work any better. Moving the string to global scope didn't help, nor did making it static. So, how do I set the default for a string option? Part two: I want to set up a boolean option (its existence returns true, and if it is not there it returns false). This is done using bool_switch(), I see. However I end up with a segmentation fault if I use this following line: opts.add_option("bool", "testing boolean", po::bool_switch()); The fault occurs, again, when opts' destructor is running. If I leave out the bool_switch() (ie. don't set a value semantic) I get no such error, although the behaviour is not as I'd like it. So, how do I use bool_switch()? What am I missing here? It is possible I'm having trouble with all occurences of po::value<>, as I haven't used it elsewhere yet (I'm adding stuff gradually)... Take care, Liam -- Liam Routt Ph: (03) 8344-1315 Research Programmer caligari(a)cs.mu.oz.au Computer Science, Melbourne University (or liam(a)routt.net)

2 2

RE: [Boost-users] graph peculiarities
by Arias Brent-P96059 15 Mar '05

15 Mar '05

----------------------- The "install property" approach has some advantages when creating property maps for internal properties. For instance, you can determine if there is an "edge_weight" property and use it, without poking into the user-supplied type for the edges. ------------------------ Ok, I can see that. ---------------------------- I don't know the rationale for the original design, but I will also note that bundled properties don't (and can't) work on Visual C++ 6.0, a compiler that had to be supported when the BGL was released. ---------------------------- Do bundled properties now work with the C++ compiler of Visual Studio.NET (i.e. version 7)? > What were you expecting instead of vertex descriptors? Keep in mind I'm a newbie to the Graph lib, but my answer is that I'd just dispense with the descriptors, and absorb the functionality straight into the iterators. So, for example, a call to source(e, g) ...would have 'e' refer to an edge iterator rather than an edge descripter. I could guess why that approach wasn't taken, but if you happen to know - please do tell. :) ------------------------------- I'm not sure the std::map<string, int> analogy holds up well, because accessing the int for a given string requires logarithmic time, which would not be acceptable for a graph. Using vertex descriptors allows the library to reference vertices without regard to their storage (or storage of their properties). ------------------------------- Ok, my bad analogy aside, isn't it also true that iterators similarly allow reference to vertices / edges without regard to their storage? Keep in mind that, as far as I can tell, you can't retrive a vertex_descripter until you've retrieved a vertex_iterator. So it appears you are dependent on iterators either way. But I suppose I don't fully appreciate the restrictions the designers faced. For example, consider the description of functor "exercise_vertex()" found here: http://boost.org/libs/graph/doc/quick_tour.html ...that makes me wonder if the descripter was simply a syntactic necessity (that an iterator could not fulfill). Thoughts? -Brent

2 1

Using boost in VS .NET 2003
by Gang Wu 15 Mar '05

15 Mar '05

Hi, I am trying to use boost in VS .NET 2003. Could someone give me a simple example showing how to make it compiled. I have run the install: bjam "-sTOOLS=gcc" install I saw it created a folder "c:\boost". But when I , for example, #include <boost/any.hpp> in VC++ .NET project. It always complained that "no such file or directory" no matter how I adjusted include path in settings (Tools->Options->Projects->VC++ Directories). Thank you for any help.

3 3

[FileSystem] Internationalization woes on windows
by Mark Holloway 15 Mar '05

15 Mar '05

I know this has been discussed a fair bit but I'd just like to get confirmation of what I believe to be the case re: boost::filesystem and internationalization on windows. I've been using boost::filesystem::directory_iterator to (amongst other things) recurse across a directory hierarchy, and on each item asking boost::filesystem::is_directory. When a file or directory is encountered containing characters not representable using the ANSI char set (alright the MS ANSI charset) an exception is thrown. For example: "boost::filesystem::is_directory: "Scratch561\ABCDE<internationized chars>MNOP": The filename, directory name, or volume label syntax is incorrect." This is presumably because the windows ANSI API calls are being used (the <API function>A variants). Am I missing something, or is this a pretty severe limitation for windows? (I appreciate unix's don't suffer in this based on their api typically using UTF-8 encoding). Thanks in advance for setting me straight/confirming my fears. Mark

2 1

Creating custom depth first search visitor for Boost graph
by Stephen Torri 15 Mar '05

15 Mar '05

I have a need to have a graph visitor algorithm similar to depth first search. The only difference is that if upon running discover_vertex the intended operation to be done on the vertex is not done I want the graph color value for this position to still be white. The reason is that the graph I am using the depth first search is a directed graph with no loops in it. A vertex might have two or more vertices providing information. If all the information is not there I want the visitor to try again. What do I have to do to gain access to the color map inside the visitor when I am in discover_vertex? Stephen

3 6

graph peculiarities
by Arias Brent-P96059 14 Mar '05

14 Mar '05

I've been looking over the graph library, and have found it curiously designed. I was hoping someone could provide a brief comment on the rationale of the design (something I didn't spot in the documentation). For example, consider the adjacency_list: adjacency_list<OutEdgeList, VertexList, Directed, VertexProperties, EdgeProperties, GraphProperties, EdgeList> I would have thought that the "VertexList" would be templated to permit me to add whatever kind of node I'd like, something like this: adjacency_list<listS, vecS<myType>, bidirectionalS> But instead, there is a rather elaborate process of creating a user defined "property" and installing that property. What was the rationale for that "install property" approach, rather than just a templated parameter approach (as I suggested above)? Even with the improvement with the new "bundled properties" approach of 1.32.0, I find myself still asking the same or similar questions. For example, after an adjacency list is created, why do I need to access the properties of the nodes (bundled or not), with vertex_descriptors? I mean, for example, the "std::map<string, int>" type doesn't require that I make a seperate "vertex_descriptor" or "definition_descriptor" to access an entry in the map. Certainly there was some rationale behind this "vertex descriptor" approach - does anyone know what it was? Thanks, -Brent

2 1

C++ Template Metaprogramming - Exercise 3-6
by Bruno Martínez Aguerre 14 Mar '05

14 Mar '05

Hi, I'm stuck at exercise 3-6 of the book. I have to write twice (see below) as a lambda expression. I don't understand why the same transformation that works for quasi fails for twice. Any help, please? #include <boost/type_traits/add_pointer.hpp> #include <boost/type_traits/is_same.hpp> #include <boost/mpl/assert.hpp> #include <boost/mpl/plus.hpp> #include <boost/mpl/int.hpp> #include <boost/mpl/placeholders.hpp> #include <boost/mpl/apply.hpp> #include <boost/mpl/lambda.hpp> #include <boost/mpl/equal_to.hpp> using namespace boost; using namespace boost::mpl; using namespace boost::mpl::placeholders; template <class F, class A> struct twice : apply<F, typename apply<F, A>::type > {}; BOOST_MPL_ASSERT(( is_same<twice<add_pointer<_1>,int>::type, int**> )); template <class F, class A> struct quasi : plus<F, typename plus<F, A>::type > {}; BOOST_MPL_ASSERT(( equal_to<quasi<int_<2>,int_<3> >, int_<7> > )); template <class F, class A> struct quasi2 : apply<plus<_1, plus<_1,_2> >, F, A >::type {}; BOOST_MPL_ASSERT(( equal_to<quasi2<int_<2>,int_<3> >, int_<7> > )); template <class F, class A> struct twice2 : apply<apply<_1, apply<_1,_2> >, F, A >::type {}; BOOST_MPL_ASSERT(( is_same<twice2<add_pointer<_1>,int>::type, int**> )); - Bruno

7 12

Bug in boost/graph/transitive_closure.hpp
by Todd A. Gibson 14 Mar '05

14 Mar '05

Bug: The header file boost/graph/transitive_closure.hpp contains an unscoped call to not1(). This function is defined in both the std namespace and the boost namespace (via boost/functional.hpp). If boost/functional.hpp is included either directly or indirectly (e.g., via boost/multi_array.hpp) Then any attempted use of transitive_closure() will not compile due to the ambiguity. Solution: Scope the call to not1 in boost/graph/transitive_closure.hpp: std::not1 Note: This bug can be easily be reproduced by including boost/functional.hpp (or boost/multi_array.hpp) To the example program transitive_closure.cpp . Thanks, -TAG Todd A. Gibson

3 3

boost::serialization within libraries
by Carsten Tham 14 Mar '05

14 Mar '05

Hi, i've run into a problem with serialization in combination with static-libraries: In my first try i defined BOOST_CLASS_EXPORT in the header-file of my exported classes. It worked for the libraries but gave me linker-errors in my applications (multiple defines). I think the link-problems are due to some static functions, defined by BOOST_CLASS_EXPORT, therefore i moved the macro-instantiations to my application, which fixed my problem. If this is the correct way to handle the issue i would suggest to include this situation in the docs. BTW: I want to thank Robert Ramey for this great library! It serialized my deeply nested object-structure with lots of shared smart-ptr's without any problem in all 3 formats and with very little work on my side. Thanks for such a great contribution to boost! Regards - Carsten -- SMS bei wichtigen e-mails und Ihre Gedanken sind frei ... Alle Infos zur SMS-Benachrichtigung: http://www.gmx.net/de/go/sms

2 1

BGL: EdgeList template parameter specification for undirected graphs
by Anatoly Petkevich 14 Mar '05

14 Mar '05

Hi! I am trying to use the BGL to create sparse undirected graph using boost::setS as template argument for EdgeList parameter: typedef adjacency_list<vecS, vecS, undirectedS, no_property, no_property, no_property, setS> GraphType; Impementation of boost::add_edge() for undirected graphs calls g.m_edges.push_back(e), and we get compilation error here since push_back() is not a member of associative container std::set. There is no such a problem for directed graphs (directedS). According to the BGL documentation there are no restrictions on EdgeList parameter for undirected graphs. Is this an undocumented feature or inconsistent implementation or library misuse? Regards, A.Petkevich

3 3