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

boost-1.33 [date_time] simple_format template: missing default for <charT>
by Michael Haubenwallner 10 Sep '05

10 Sep '05

Hi, is there any reason besides being a bug why the formatters found in boost/date_time/date_formatting.hpp have a default value 'char' for template argument 'charT', but boost::date_time::simple_format does not ? Thanks, haubi -- Michael Haubenwallner SALOMON Automation GmbH Forschung & Entwicklung A-8114 Friesach bei Graz mailto:michael.haubenwallner@salomon.at http://www.salomon.at No HTML/MIME please, see http://expita.com/nomime.html

1 0

Re: [Boost-users] Thread events
by Christopher Hunt 10 Sep '05

10 Sep '05

On 10/09/2005, at 2:12 AM, boost-users-request(a)lists.boost.org wrote: >> Thanks for your replies. >> >> To me boost::condition looks very much like the old event >> variable, except >> that it works together with a mutex. I am now wondering why you >> should >> lock >> a mutex before waiting for the condition? Is there a rationale >> about this? > Also note that the wait() on the condition unlocks the mutex until you > return from the wait call. That's not always obvious from the > examples. Someone else mentioned the Butenhof book so I won't go down that path; suffice to state that anyone that wants to do any thread programming absolutely must read that book. In fact, the book really is more about thread paradigms than pthreads. IMHO pthreads are more of a case study in the book. A quick example to fill in the time between you ordering the book and receiving it might help. Suppose you have a mutex for the purpose of protecting a variable. Suppose you must also wait on a condition because that variable isn't in a state that you need to progress. If you keep the mutex locked while waiting on a condition then no other thread will get the opportunity to modify the variable's value. To solve this many programmers will just unlock the mutex prior to waiting on the condition. However, the problem with this approach is that in the time between the mutex being unlocked, and the condition is waited on, another thread can come along, lock the mutex and change the variable. Thus you might be waiting on a condition that never occurs. Remember that conditions are generally signaled only to threads currently waiting on them or to the 1st thread that comes along and waits on a condition. Thus, if you're not waiting on a condition, you may never receive its signal. You may think that the chances of another thread coming along and upsetting your world are slim, but one day, it will happen and you'll be wanting to ignore that bug in your app 'cause it'll be hard to reproduce. pthread conditions are associated with mutexes so that they guarantee to unlock a mutex and wait on a condition without the chance of another thread coming along and doing what is described above. From an implementation perspective, I imagine pthread conditions enter into a critical section while they unlock a mutex and move to a wait state. As stated before, when you return from the condition, the mutex will be locked again, and you should re-test for your condition. Something like the following logic may help: ***** lock mutex while var not in state you need to proceed { wait on condition associated with mutex } unlock mutex do your stuff. ***** Note that it is also healthy to unlock your mutexes asap so as to reduce contention. 'hope that this helps. Cheers, -C

1 0

Problem with BGL copy_graph algorithm - HELP
by Tony Cook 09 Sep '05

09 Sep '05

Hello, Can anyone tell me if I've exposed a bug in the Boost Graph Library or if the following behaviour is expected and I need to code the solution in a different way, and if so HOW? In summary the boost::copy_graph algorithm fails to compile when defining the graph using std::vector for the edge container and std::list for the vertex container (Visual Studio 7.1, Boost 1.32.0). Other graph type definitions work. (NB I can't use the "working" graph types in my main application as VC 7.1 bombs with an Internal Compiler Error. I'm forced to use a vecS,lists graph just to work round the ICE problem!!). I've distilled the problem down to the minimum code possible. ------------------------------------------------- // A vecS, vecS based graph works typedef boost::adjacency_list <boost::vecS, boost::vecS, boost::undirectedS, boost::no_property, boost::no_property, boost::no_property> GoodGraphType ; GoodGraphType good_graph_1 ; GoodGraphType good_graph_2 ; boost::copy_graph (good_graph_1, good_graph_2) ; // Compiles OK ------------------------------------------------- // A listS, vecS based graph also works typedef boost::adjacency_list <boost::listS, boost::vecS, boost::undirectedS, boost::no_property, boost::no_property, boost::no_property> AnotherGoodGraphType ; AnotherGoodGraphType another_good_graph_1 ; AnotherGoodGraphType another_good_graph_2 ; boost::copy_graph (another_good_graph_1, another_good_graph_2) ; // Compiles OK ------------------------------------------------- // A vecS, lists based graph fails to compile - BGL error or expected?? typedef boost::adjacency_list <boost::vecS, boost::listS, // root cause of compilation failure boost::undirectedS, boost::no_property, boost::no_property, boost::no_property> BadGraphType ; BadGraphType bad_graph_1 ; BadGraphType bad_graph_2 ; boost::copy_graph (bad_graph_1, bad_graph_2) ; // ***** Does not compile ****** ------------------------------------------------------- Here is the exact wording of the VC7.1 compiler output. ------------------------------------------------------- ..\boost_1_32_0\boost\property_map.hpp(349) : error C2678: binary '+' : no operator found which takes a left-hand operand of type 'const std::vector<_Ty>::iterator' (or there is no acceptable conversion) with [ _Ty=boost::detail::adj_list_gen<boost::adjacency_list<boost::vecS,boost::vec S,boost::undirectedS,boost::no_property,boost::no_property,boost::no_propert y>,boost::vecS,boost::vecS,boost::undirectedS,boost::detail::retag_property_ list<boost::vertex_bundle_t,boost::no_property>::type,boost::detail::retag_p roperty_list<boost::edge_bundle_t,boost::no_property>::type,boost::no_proper ty,boost::listS>::config::vertex_ptr ] ...\boost_1_32_0\boost\property_map.hpp(349) : while compiling class-template member function 'void boost::iterator_property_map<RandomAccessIterator,IndexMap,T,R>::operator [](boost::iterator_property_map<RandomAccessIterator,IndexMap,T,R>::key_type ) const' with [ RandomAccessIterator=std::vector<boost::detail::adj_list_gen<boost::adjacenc y_list<boost::vecS,boost::vecS,boost::undirectedS,boost::no_property,boost:: no_property,boost::no_property>,boost::vecS,boost::vecS,boost::undirectedS,b oost::detail::retag_property_list<boost::vertex_bundle_t,boost::no_property> ::type,boost::detail::retag_property_list<boost::edge_bundle_t,boost::no_pro perty>::type,boost::no_property,boost::listS>::config::vertex_ptr >::iterator, IndexMap=boost::property_map<boost::adjacency_list<boost::vecS,boost::listS, boost::undirectedS,boost::no_property,boost::no_property,boost::no_property> ,boost::vertex_index_t>::const_type, T=std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::ve cS,boost::vecS,boost::undirectedS,boost::no_property,boost::no_property,boos t::no_property>,boost::vecS,boost::vecS,boost::undirectedS,boost::detail::re tag_property_list<boost::vertex_bundle_t,boost::no_property>::type,boost::de tail::retag_property_list<boost::edge_bundle_t,boost::no_property>::type,boo st::no_property,boost::listS>::config::vertex_ptr >::value_type, R=std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::ve cS,boost::vecS,boost::undirectedS,boost::no_property,boost::no_property,boos t::no_property>,boost::vecS,boost::vecS,boost::undirectedS,boost::detail::re tag_property_list<boost::vertex_bundle_t,boost::no_property>::type,boost::de tail::retag_property_list<boost::edge_bundle_t,boost::no_property>::type,boo st::no_property,boost::listS>::config::vertex_ptr >::value_type & ] ...\boost_1_32_0\boost\graph\copy.hpp(323) : see reference to class template instantiation 'boost::iterator_property_map<RandomAccessIterator,IndexMap,T,R>' being compiled with [ RandomAccessIterator=std::vector<boost::detail::adj_list_gen<boost::adjacenc y_list<boost::vecS,boost::vecS,boost::undirectedS,boost::no_property,boost:: no_property,boost::no_property>,boost::vecS,boost::vecS,boost::undirectedS,b oost::detail::retag_property_list<boost::vertex_bundle_t,boost::no_property> ::type,boost::detail::retag_property_list<boost::edge_bundle_t,boost::no_pro perty>::type,boost::no_property,boost::listS>::config::vertex_ptr >::iterator, IndexMap=boost::property_map<boost::adjacency_list<boost::vecS,boost::listS, boost::undirectedS,boost::no_property,boost::no_property,boost::no_property> ,boost::vertex_index_t>::const_type, T=std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::ve cS,boost::vecS,boost::undirectedS,boost::no_property,boost::no_property,boos t::no_property>,boost::vecS,boost::vecS,boost::undirectedS,boost::detail::re tag_property_list<boost::vertex_bundle_t,boost::no_property>::type,boost::de tail::retag_property_list<boost::edge_bundle_t,boost::no_property>::type,boo st::no_property,boost::listS>::config::vertex_ptr >::value_type, R=std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::ve cS,boost::vecS,boost::undirectedS,boost::no_property,boost::no_property,boos t::no_property>,boost::vecS,boost::vecS,boost::undirectedS,boost::detail::re tag_property_list<boost::vertex_bundle_t,boost::no_property>::type,boost::de tail::retag_property_list<boost::edge_bundle_t,boost::no_property>::type,boo st::no_property,boost::listS>::config::vertex_ptr >::value_type & ] ...\CopyGraphTest.cpp(50) : see reference to function template instantiation 'void boost::copy_graph<BadGraphType,BadGraphType>(const VertexListGraph &,MutableGraph &)' being compiled with [ VertexListGraph=BadGraphType, MutableGraph=BadGraphType ] ------------------------------------------------------- Here is the code from property_map.hpp the generates the error - error line marked with //<----- HERE //========================================================================= // Adapter to turn a RandomAccessIterator into a property map template <class RandomAccessIterator, class IndexMap #ifdef BOOST_NO_STD_ITERATOR_TRAITS , class T, class R #else , class T = typename std::iterator_traits<RandomAccessIterator>::value_type , class R = typename std::iterator_traits<RandomAccessIterator>::reference #endif > class iterator_property_map : public boost::put_get_helper< R, iterator_property_map<RandomAccessIterator, IndexMap, T, R> > { public: typedef typename property_traits<IndexMap>::key_type key_type; typedef T value_type; typedef R reference; typedef boost::lvalue_property_map_tag category; inline iterator_property_map( RandomAccessIterator cc = RandomAccessIterator(), const IndexMap& _id = IndexMap() ) : iter(cc), index(_id) { } inline R operator[](key_type v) const { return *(iter + get(index, v)) ; } //<----- HERE protected: RandomAccessIterator iter; IndexMap index; }; -------------------------------------------------------- TIA for any help in this matter Tony Cook

2 1

[BGL] Help with Brandes' Betweenness
by Rui Carvalho 09 Sep '05

09 Sep '05

Hi, I'm trying to write code to compute Brandes' Betweenness Centrality for a very simple graph: a star. I'm doing this, as I haven't been able to find simple examples in the documentation [hint :)] for vecS,vecS graphs and still haven't grasped how edge property maps work. I've got it running if all I want is to compute vertex BC (see below, also attached), but can't get it to compute both vertex and edge BC. I'd appreciate any suggestions -perhaps my example (or something similar) could be corrected and included in the BGL? Thanks, Rui #include <iostream> // for std::dataout #include <utility> // for std::pair #include <boost/utility.hpp> // for boost::tie #include <boost/graph/graph_traits.hpp> // for boost::graph_traits #include <boost/graph/graph_utility.hpp> #include <boost/graph/betweenness_centrality.hpp>//for boost::brandes_betweenness_centrality #include <boost/graph/adjacency_list.hpp> using namespace boost; using namespace std; typedef adjacency_list < vecS, //Store out-edges vecS, //Store vertex set undirectedS, //the graph is undirected property<edge_index_t, int> > Graph; typedef graph_traits<Graph>::vertex_descriptor Vertex; typedef graph_traits<Graph>::vertex_iterator Vertex_Iter; typedef graph_traits<Graph>::edge_descriptor Edge; typedef graph_traits<Graph>::edge_iterator Edge_Iter; typedef property_map<Graph, vertex_name_t>::type Name_Map_t; typedef property_map<Graph, edge_index_t>::type Edge_Map_t; int main(int,char*[]) { int n_vrtx = 5; //Builds graph with vertices, but no edges Graph g_star(n_vrtx); //Add edges. Graph g_star is a star add_edge(vertex(0, g_star), vertex(4, g_star), g_star); add_edge(vertex(1, g_star), vertex(4, g_star), g_star); add_edge(vertex(2, g_star), vertex(4, g_star), g_star); add_edge(vertex(3, g_star), vertex(4, g_star), g_star); Vertex_Iter vertex_iterator_begin, vertex_iterator_end; std::vector<double> centrality(n_vrtx); brandes_betweenness_centrality(g_star, centrality_map(make_iterator_property_map(centrality.begin(), get(vertex_index, g_star),double())).vertex_index_map(get(vertex_index, g_star))); for ( tie(vertex_iterator_begin, vertex_iterator_end) = vertices(g_star); vertex_iterator_begin != vertex_iterator_end; ++vertex_iterator_begin) { cout << "Vertex: " << *vertex_iterator_begin <<"\tBC: "<< centrality[*vertex_iterator_begin] << endl; } }

2 2

[Logging] Issues with dlls
by Paolo Coletta 09 Sep '05

09 Sep '05

Hi, I'm using Torjo's logging library in both an exe and a dll loaded from that exe (OS: Windows Xp, Compiler VC71 - /MD compile flag - multithreaded dll). I need the exe and the dll to have independent logs, as the dll are plugins implemented by third parties which may or not use boost log. The approach I was trying to follow was: - The exe declares/defines the log it needs. In its main function it initializes the logging system (appenders/modifiers/flush_log_cache). - Some of the dlls (at least the ones developed by me), declare/defines their own logs. In the DllMain they initialize theri logging system (appenders/modifiers/flush_log_cache). Is this expected to work? I made some tests and I got an access violation when exiting the main app, in the destructor of default_log_manager_impl(). (I can send a simple test case if needed). I also tried to compile the exe with BOOST_LOG_DYN_LINK but I always get the access violation (don't know if this could help - I remember to have seen this suggested in a similar case). What am i doing wrong? Paolo Coletta

3 3

Thread events
by Johan 't Hart 09 Sep '05

09 Sep '05

(I'm not that familiair with news servers, so this post might appear for the second time. I hope to get an answer though) Hello, I'm quite a newbie in the boost world, and I read the documentation about boost::threads. Inthere I read that events were not included in boost because they were too error-phrone. That made me wonder how to do multithreading without events, for example, how do you make a thread wait for something to do without events? I don't know how to implement that with just mutexes. Can someone help me? Thanks in advance. Johan 't Hart -- -- Mijn Postvak In wordt beschermd door SPAMfighter 11622 spam-mails zijn er tot op heden geblokkeerd. Download de gratis www.SPAMfighter.com vandaag nog!

8 8

bbv2 filesystem link issue?
by Daniel Schlyder 09 Sep '05

09 Sep '05

Hi, I'm in the process of upgrading to Boost.Build v2 and have run into a problem with Boost.Filesystem (or my use of it). Executables using this library crash when built with my BBv2 files, but work fine with my old BBv1 files. I'm using Boost CVS HEAD, MinGW GCC 3.4.4 and Boost.Jam 03.01.11. The crash is a SIGSEGV in std::string::find_first_of() when called from boost::filesystem::windows_name(). It doesn't matter whether I use a shared or static variant of the library. Moving the definition of windows_invalid_chars into windows_name() fixes it as long as I use a static variant. I guess this should give some clue as to what is going wrong, but I don't get it. I tried comparing the build commands of BB v1 and v2 but if there is anything wrong I don't have the knowledge to see it. I tried duplicating the crash using a simple BBv2 Jamroot and a "hello world"-ish Boost.Filesystem program, but that works fine. I'm completely stuck here and any help would be much appreciated. Thanks, -- Daniel Schlyder http://bitblaze.com/

1 0

Re: [Boost-users] Thread events
by Gottlob Frege 09 Sep '05

09 Sep '05

> > Date: Thu, 8 Sep 2005 21:06:12 +0200 > From: "Johan 't Hart" <jopie64(a)hotmail.com> > Subject: Re: [Boost-users] Thread events > To: <boost-users(a)lists.boost.org> > Message-ID: <BAY109-DAV27468EBFC3012D63D9A99B4990(a)phx.gbl> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=original > > Thanks for your replies. > > To me boost::condition looks very much like the old event variable, except > that it works together with a mutex. I am now wondering why you should > lock > a mutex before waiting for the condition? Is there a rationale about this? > > Johan Also note that the wait() on the condition unlocks the mutex until you return from the wait call. That's not always obvious from the examples.

1 0

request: make atomic operations (boost/detail/atomic_count*) available for library users
by Paul Pogonyshev 08 Sep '05

08 Sep '05

Hi, Is it possible that atomic operations in Boost are made available for library users? `shared_ptr' is good, but sometimes one might need the low-level operations too. Paul

2 2

Boost licensing applied
by Ted Carter 08 Sep '05

08 Sep '05

I'm considering using Boost in a commercial product, but after reading the licensing statement I'm not clear what is required. The candidate project ships to end-users in binary, and sometimes to oems as sources. Does the license statement need to be included with all sources, dependent files, or just in the Boost library sources? Legalese isn't my strong point. Regards, Ted.

3 2