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

Re: [Boost-users] What is this HEAD everybody is talking about?
by shams 10 Apr '07

10 Apr '07

Here we go and daily snapshots are available at: http://www.boost-consulting.org/boost/ and see "Snapshots" (this page will be updated on boost.org I believe when 1.34 is released) Or go directly to: http://engineering.meta-comm.com/boost.aspx and see "main truck" Thanks Shams

1 0

Re: [Boost-users] What is this HEAD everybody is talking about?
by Pfligersdorffer, Christian 10 Apr '07

10 Apr '07

Robert Ramey wrote: > have been made in an attempt to accomodate it. The lastest version > of these changes have been checked into the HEAD. You might look at Hey folks, where or what is this ominous HEAD Robert is talking about? I know about the releases versions via boost.org and the developer version via CVS but no more. Please enlighten me! I tried to check it out of my head which surprisingly didn't work ;) Christian Pfligersdorffer Software Engineering EOS GmbH

2 1

Regex - how to match everything beginning at '<a href=' and ending at '</a>'
by Jeff 10 Apr '07

10 Apr '07

I am new to regex and see how to match the URL string using the expression below: Expression: <a href[^<]*</a> To match: <a href="http://art.com">Art Page</a> Unfortunately, the URL strings vary and I am basically wanting to get everything beginning at '<a href=' and ending at '</a>'. Doing so, would allow me to get URL strings like the one above as well as: <a href="http://art.com" target="_blank">Art Page<br>And More</a> or <a href="http://art.com/"><img src="http://art.com/flower.jpg" alt="Art"></a>

3 4

Adding debugging statements during boost graph construction eliminates breadth_first_search missing vertices
by Stephen Torri 10 Apr '07

10 Apr '07

Symptom: Breadth first graph visitor misses visiting vertexes when debugging statements removed during graph construction. OS: Fedora Core Linux BOOST: 1.33.1-11.fc6 GCC: 4.1.1-51.fc6 Problem: I am suspecting that there is a timing issue or something else that I am missing that causes the boost breath first visitor to miss two nodes in a graph. The reason why U suspect something is that when I add three debugging statements to determine what is happening with graph construction that the visitor is able to visit all vertexes. The following commented out lines are the ones that I add. void Component_Graph::add_Component ( Component::ptr_t obj_ptr ) { bool no_duplicate; IdVertexMap_t::iterator pos; Vertex_t node; /* std::cout << boost::format("Component_Graph::add_Component for id %d") % obj_ptr->get_ID() << std::endl; */ if ( obj_ptr.get() == 0 ) { std::cerr << boost::format("Exception throw in %s at line %d") % __FILE__ % __LINE__ << std::endl; throw errors::Component_Exception ( errors::Component_Exception::NULL_POINTER ); } boost::tie (pos, no_duplicate) = m_index.insert (std::make_pair(obj_ptr->get_ID(), node)); if ( no_duplicate ) { /* std::cout << boost::format("Component_Graph::add_Component - no duplicate with id = %d") % obj_ptr->get_ID() << std::endl; */ // Insertion was successful // Make a new vertex and return handle to 'node' node = add_vertex(m_graph); // Get list of Components boost::property_map<Graph_Base::Graph_t, vertex_name_t>::type clist = get(vertex_name, m_graph); // Assign component to vertex position clist[node] = obj_ptr; // Add vertex handle to map position pos->second = node; // Get list of indexes boost::property_map<Graph_Base::Graph_t, vertex_index_t>::type ilist = get(vertex_index, m_graph); ilist[node] = obj_ptr->get_ID(); // Grab list of parent ids std::list<boost::uint32_t> source_list = obj_ptr->get_Source_List (); for ( std::list<boost::uint32_t>::const_iterator cpos = source_list.begin(); cpos != source_list.end(); ++cpos ) { /* std::cout << boost::format("Component_Graph::add_Component parent(id=%d) for child(id=%d)") % (*cpos) % obj_ptr->get_ID() << std::endl; */ // Call add_child. This adds a edge from the parent Component to the child Component this->add_Child ( (*cpos), obj_ptr ); } } else { std::cerr << "ERROR: Duplicate source found. Skipping Component" << std::endl; return; } } The graph is a simple adjacency list that I keep in a class called Component_Graph. When it comes time to visit the boost graph is returned from the Component_Graph. Here is my definition: typedef property< vertex_index_t, uint32_t, property< vertex_name_t, boost::shared_ptr<Component> > > VertexProperty_t; typedef adjacency_list<setS, // OutEdgeList setS, // VertexList directedS, // Directed VertexProperty_t> // VertexProperties Graph_t; As you can see a standard adjacency list graph with a component as the property. The graph visitor going to each vertex is inherited from the default breadth first search visitor. Each Component performs its task via 'run()' and the results are collected for storage in the Data_Map_t for use by children Component. Order of operation is important. All parents to a Component must be executed before a child works. This was the reason why I choose a breadth first search visitor. class Graph_Visitor : public boost::default_bfs_visitor { public: // Constructor explicit Graph_Visitor ( infrastructure::Component_Graph const& graph_ref, infrastructure::Graph_Base::Data_Map_t* dmap ); // Visitor functions template <class Vertex, class Graph> void discover_vertex(Vertex v, Graph const& g) { boost::shared_ptr<infrastructure::Component> src_obj_ptr = m_graph_ref.get_Component(v); std::cout << "Visiting node: " << src_obj_ptr->get_ID() << std::endl; // This will execute the Component to perform its task src_obj_ptr->run ( m_data_map ); typename Graph::degree_size_type num_children = out_degree (v, g); // Print out the id of the vertex being visited std::cout << boost::format(" Node(%d) - children: %d") % src_obj_ptr->get_ID() % num_children << std::endl; // Save results for children Components infrastructure::Graph_Base::Result_Data_t result_data = std::make_pair ( src_obj_ptr->results(), num_children ); m_data_map->insert ( std::make_pair ( src_obj_ptr->get_ID(), result_data ) ); typename Graph::out_edge_iterator pos; typename Graph::out_edge_iterator end; typename Graph::vertex_descriptor node; boost::shared_ptr<infrastructure::Component> target_obj_ptr; // Notify children Components that the parent Component data is available for ( boost::tie(pos,end) = out_edges(v, g); pos != end; ++pos ) { node = target (*pos, g); target_obj_ptr = m_graph_ref.get_Component ( node ); target_obj_ptr->received_Input_Source_Data ( src_obj_ptr->get_ID() ); } } private: infrastructure::Component_Graph const& m_graph_ref; infrastructure::Graph_Base::Data_Map_t* m_data_map; }; So a resulting graph, which I output via a separate visitor, shows one arrange of components as it should be and how the vertexes are being visited at present ----------------------------- EXPECTED ----------------------------- digraph analysis { 1 [label="File_Type_Detector(1)"]; // Visitor starts here 1 -> 20; // All children components are initialized with Component #1 data 1 -> 30; 1 -> 40; 1 -> 5; 20 [label="Arch_Type_Detector(20)"]; // Component #20 executes 20 -> 5; // Component #5 initialized with Component #20 data 30 [label="Data_Section_Detector(30)"]; // Component #30 executes 30 -> 5; // Component #5 initialized with Component #30 data 40 [label="Code_Section_Detector(40)"]; // Component #40 executes 40 -> 5; // Component #5 initialized with Component #40 data 5 [label="Meta_Writer(5)"]; // Component #5 executes } ----------------------------- PRESENT RESULTS ----------------------------- digraph analysis { 1 [label="File_Type_Detector(1)"]; // Visitor starts here 1 -> 20; // All children components are initialized with Component #1 data 1 -> 30; 1 -> 40; 1 -> 5; 20 [label="Arch_Type_Detector(20)"]; // Component #20 executes 20 -> 5; // Component #5 initialized with Component #20 data 5 [label="Meta_Writer(5)"]; // Component #5 fails to execute. Missing data from Component #30 and #40 } STEPS TAKEN: 1. I went through the code and reviewed its design a. Redesign Component so its a pure virtual class b. Added new classes to add the old functionality via composition 2. Added the debug print statements to see what was happening with the visitors. NOTE: This is where I noticed that it work with them but fails without them. 3. Checked to see if making the copy constructors for the objects that compose the Component functionality as 'explicit' was the problem. They were not. Are there any reasons which would make a breadth first search visitor skip visiting a vertex? Stephen

1 0

boost.function and boost:bind in MSVS2005
by HeavyWave 10 Apr '07

10 Apr '07

Hi there. I'm using boost.function and boost:bind to point to Member function this way: class ModuleRegister { public: ModuleRegister(void); ~ModuleRegister(void); typedef boost::function1< std::string, std::map<std::string,std::string> > HEFunc; void RegisterClassMember(std::string & name, const HEFunc & f); }; class News : public BaseModule { public: News(void); ~News(void); std::string show(std::map<std::string,std::string> bb); }; than in other class void IParser::PrepareModules() { ModuleRegister::HEFunc f; f = boost::bind(&News::show, &NewsObj, _1); MRegister.RegisterClassMember(std::string("News.show"),f); } and I get 1>IParser.obj : error LNK2005: "union boost::detail::function::any_pointer __cdecl boost::detail::function::make_any_pointer(void *)" (?make_any_pointer@function@detail@boost@@YA?ATany_pointer@123@PAX@Z) already defined in Main.obj 1>IParser.obj : error LNK2005: "bool __cdecl boost::detail::function::has_empty_target(...)" (?has_empty_target@function@detail@boost@@YA_NZZ) already defined in Main.obj IParser.h is actually included in Main.h and #include "boost/function.hpp" is in ModuleRegister.h which is included in IParser.h can't handle this problem

1 0

[filesystem] basename() removes suffix?
by Chris Fairles 10 Apr '07

10 Apr '07

In boost, the default behavior is to remove not only all text before the last "/", but to remove all text after the first "." from the end (i.e. the file extension or suffix). In GNU and POSIX, the suffix is not removed. In PHP and Bash, the suffix is removed only if specified as an optional 2nd parameter. Whats the rationale for boost having different behavior than the above implementations? It causes a bit of a compatibility/portability issue if someone using GNU/POSIX replaces all basename functions with boost's. Chris

1 0

[Format] Errors resulting from optional.hpp
by Ferng, Andrew D 10 Apr '07

10 Apr '07

Hi all, Got a problem with using the format lib and I've no idea how to fix or get around this. I'm on an AIX using xlC ver 6. My other code using BGL compiled and ran fine so I'm assuming my library is built correctly. When I tried to compile using xlC, I get the errors listed below. The strange thing is that the same code does not generate errors in VS2005 or if I use g++ 4.11 on AIX. As indicated from the error below, line 389 in optional.hpp is: void destroy_impl ( is_not_reference_tag ) { get_ptr_impl()->T::~T() ; m_initialized = false ; } What is this optional.hpp? From the name, it sounds like it's not required? Are there certain compiler options that boost requires? I have to use xlC because of compatibility issues so I've got to figure this out. Any help would be appreciated! Thanks! Error below: --------------------------------------------------------------------- IDTApplication.cpp: "/a/Boost/include/boost/optional/optional.hpp", line 389.66: 1540-0210 (S) "T" is not a base class of "locale". "/a/Boost/include/boost/optional/optional.hpp", line 389.10: 1540-0700 (I) The previous message was produced while processing "boost::optional_detail::optional_base<std::locale>::destroy_impl(is_not _reference_tag)". "/a/Boost/include/boost/optional/optional.hpp", line 362.9: 1540-0700 (I) The previous message was produced while processing "boost::optional_detail::optional_base<std::locale>::destroy()". "/a/Boost/include/boost/optional/optional.hpp", line 208.24: 1540-0700 (I) The previous message was produced while processing "boost::optional_detail::optional_base<std::locale>::~optional_base()". "/a/Boost/include/boost/optional/optional.hpp", line 130.7: 1540-0700 (I) The previous message was produced while processing "boost::optional_detail::optional_base<std::locale>::__dftbdt()". "/a/Boost/include/boost/optional/optional.hpp", line 472.5: 1540-0700 (I) The previous message was produced while processing "boost::optional<std::locale>::~optional()". "/a/Boost/include/boost/format/internals.hpp", line 38.9: 1540-0700 (I) The previous message was produced while processing "boost::io::detail::stream_format_state<char,std::char_traits<char> >::stream_format_state(char)". "/a/Boost/include/boost/format/internals.hpp", line 78.53: 1540-0700 (I) The previous message was produced while processing "boost::io::detail::format_item<char,std::char_traits<char>,std::allocat or<char> >::format_item(char)". "/a/Boost/include/boost/format/format_implementation.hpp", line 121.40: 1540-0700 (I) The previous message was produced while processing "boost::basic_format<char,struct std::char_traits<char>,class std::allocator<char> >::make_or_reuse_data(size_t)". "/a/Boost/include/boost/format/parsing.hpp", line 415.9: 1540-0700 (I) The previous message was produced while processing "boost::basic_format<char,struct std::char_traits<char>,class std::allocator<char> >::parse(const string_type &)". "/a/Boost/include/boost/format/format_implementation.hpp", line 33.13: 1540-0700 (I) The previous message was produced while processing "boost::basic_format<char,struct std::char_traits<char>,class std::allocator<char> >::basic_format(const char *)". "IDTApplication.cpp", line 1082.17: 1540-0700 (I) The previous message was produced while processing "IDTApplication::createO(Pnt29aFile &, IDTConditionCodeFile &, string &, IDTDetails_File &)".

2 1

boost::thread - Checking that an object is called from the right thread
by Thomas Sondergaard 10 Apr '07

10 Apr '07

I've got an object that should only be called from the thread that instantiated, and I'd like the object to check that. Using pthreads I've checked this with pthread_self, but now I'm moving to boost threads, my code looks like this: class MyClass { boost::thread instantiating_thread; public: void doSomething() { // Verify that we have been called from the right thread assert(boost::thread() == instantiating_thread) // Actually do something... } }; Is this alright? The boost::threads documentation has this to say about the boost::thread() default constructor: 1. thread(); Effects: Constructs a thread object representing the current thread of execution. Postconditions: *this is non-joinable. Notes: Danger:*this is valid only within the current thread. (http://www.boost.org/doc/html/thread.html) If *this is not valid from another thread, as the documentation states, then my assert above is broken, right? Regards, Thomas Søndergaard

1 0

Boost Filesystem Library - TYPO?
by SmokingRope 10 Apr '07

10 Apr '07

I have been reading through the Boost Filesystem library trying to get a feel for syntax. I'm looking at the current version available through sourceforge (1.33.1). I also noticed that the sourceforge version is different than the CVS version. Anyway: file: /libs/fileystem/src/path_posix_windows.cpp function: m_path_append(const std::string&, name_checker) lines: 305 -311 // append '/' if needed if( !empty() #ifdef BOOST_WINDOWS && *(m_path.end()-1) != ':' // QUESTION related to this #endif && *(m_path.end()-1) != '/' ) m_path += '/'; ------------------------------------------------------------- The line in question appears to be a typo and should actually read && *(m_path.end()-1) != '\\' Has this gone past the radar or do my eyes decieve me?

1 0

[mpl] public inheritance
by Igor Mikushkin 08 Apr '07

08 Apr '07

Hello! Can I use public or protected inheritance using inherit and inherit_linearly metafunctions?

2 2