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

[preprocessor] break "names"
by Felipe Magno de Almeida 10 Sep '05

10 Sep '05

Hi, Maybe it is a naive question, but I've been researching a little and couldnt find an answer to this(not an affirmative and nor negative): Is it possible to have such usages: SOME_MACRO(hello world) or SOME_MACRO("hello world") (or something that doesnt have much "characters overhead", like using space for every character) and have the expansion result in this: h e l l o w o r l d or even better: 'h','e','l','l','o', ' ', 'w', 'o', 'r', 'l', 'd' Well, what I'm trying to find is if it is … [View More]

1 0

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 … [View More]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 [View Less]

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 … [View More]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 [View Less]

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 … [View More]

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 (… [View More]

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 … [View More]

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 … [View More]

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 … [View More]

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