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

Bind regression from 1.30 to 1.32
by Thomas Matelich 15 Mar '05

15 Mar '05

This may be a reasonable regression, but I thought I'd bring it up in case its a regression that should be fixed. My sample code and some error outputs are attached. Oh, and in case you're wondering why I would do this, its basically because I really like the find_if/bind/equal_to thing, and I need the char[64] for easy fwrite/fread'ing. Thanks

2 2

boost regexp
by Groleo Marius 15 Mar '05

15 Mar '05

Hi! I have a question about regexp: How can i write a regex , to match this string: +OK user -- Regards, Groleo! .''`. # touch universe : :' : # chmod +rwx universe `. `'` # ./universe `- Debian - when you have better things to do than fix a system

2 2

wregex undefined workaround
by pps 15 Mar '05

15 Mar '05

Hello, I use freebsd 4.11 & gcc3.3.6 and gcc 3.4.4 with both I don't have std::wstring defined. I only need it fo some internal use. So, I defined: typedef unsigned short uchar16 typedef basic_string<uchar16> string16; and it was enough for me (I don't do iostreams with this string) But, I need regex support for this. As I read in a few mail boost does not create wregex on some platforms with limited support for wchar_t, so I tried to create one the same as I did with string: typedef reg_expression<uchar16, regex_traits<uchar16>, BOOST_DEFAULT_ALLOCATOR(uchar16)> regex16; When I try to use regex16 I get a big load of errors. Did I missed something? Thanks

2 11

Mutex synchronized LockingPtr in Boost?
by Christopher D. Russell 15 Mar '05

15 Mar '05

Is there a class in Boost that implements functionality similar to Andrei Alexandrescu's mutex-synchronized LockingPtr as described in his Feb. 2001 CUJ article http://www.cuj.com/documents/s=7998/cujcexp1902alexandr/? I checkout boost::smart_ptr but don't see that any of these deal with interprocess / interthread synchronization. - Regards Chris -- --- Chris Russell, Encapsule Systems, Inc., Yarmouth, Maine USA 04096 http://encapsule.com // http://hyperworx.org // http://chrisrussell.net cdr(a)encapsule.com // voice (207) 846-7773 // mobile (207) 671-5963 Skype user "encapsule"

1 0

[boost graph] adjusting vertex_descriptors when performing a remove_vertex
by Yariv Tal 15 Mar '05

15 Mar '05

In our project we need the ability to associate an object with a vertex, so naturally I add the object ptr as a vertex property. However, we also need to access the vertex according to the object (for example, for performing a shortest-path algorithm from the vertex representing the specific object). So, I also have a map mapping a vertex_descriptor for each object: typedef std::map<ObjectPtr, GraphTraits::vertex_descriptor> ObjVertexMap; Now, the problem is that when an object/vertex is removed from the graph, depending on the container holding vertices (vecS vs. listS), a renumbering of the vertex_descriptors may occur (or may not...) For example: (The typedefs are pretty large and not neccessarily needed to understand the code - so may want to skip them) // *** TYPEDEFS START HERE typedef std::map<ObjectPtr, GraphTraits::vertex_descriptor> ObjVertexMap; typedef Object * ObjectPtr; // Define new prperty struct vertex_obj_t { typedef boost::vertex_property_tag kind; }; // Define graph type typedef boost::adjacency_list< boost::vecS, boost::vecS, // If this is boost::listS then no renumbering on vertex delete??? boost::directedS, boost::property<vertex_tmfobj_t, ObjectPtr>, > GraphType; // *** TYPEDEFS END HERE class GraphMgr { protected: GraphType m_graph; ObjVertexMap m_objects; public: bool addEntity(ObjectPtr a_obj) { if (m_objects.find(a_obj) != m_objects.end()) { return false; } GraphTraits::vertex_descriptor newVertex = boost::add_vertex(Graph::vertex_property_type(a_obj), m_graph); m_objects.insert(ObjVertexMap::value_type(a_obj, newVertex)); return true; } bool removeEntity(const ObjectPtr a_obj) { ObjVertexMap::iterator itr = m_objects.find(a_obj); if (itr == m_objects.end()) { return false; } boost::clear_vertex((*itr).second, m_graph); boost::remove_vertex((*itr).second, m_graph); // will this do a renumbering of the vertices? m_objects.erase(itr); // !!! If renumbering of the vertices was made I must update the ObjVertexMap! return true; } }; The problem is that if I use one type of container for vertices, the vecS, then renumbering on remove_vertex occurs and I need to update all indices in m_objects - this means I need to KNOW that vertex_descriptor is an index and how remove_vertex is implemented... Even worse: as far as I undertand if I use listS then vertex_desfcriptor is no longer an index an no renumbering occurs in remove_vertex! So, unless I want to commit to using vecS and to a specific implementation I need to somehow KNOW whether or not to perform renumbering. I coulld do this via a traits template with sepcialization for each vertices container type, but it seems to me that the library should have (and probably has) a better way of abstracting this, no? Perhaps the problem is that I'm storing vertex_descriptors in the ObjVertexMap, which may be defined as transient entities that (like iterators after an erase) might be invalidated after a remove_vertex - but then, how can I hold some persistent and efficient identifier into the graph that remains valid after remove_vertex? If anyone has any ideas, plz help. Yariv.

2 3

[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