- Boost - lists.boost.org

Boost Signal Bug
by Neal Coombes 30 Jun '04

30 Jun '04

I've experienced the same problem discussed on June 3rd titled "Bug, signals, use of default Combiner" http://thread.gmane.org/gmane.comp.lib.boost.devel/103903 . I would have just replied except its a little old, thus a new thread. Doug Gregor wrote: > We intentionally did not return a default-constructed value because > the returned type might not have a default constructor. Granted, this > case might be sufficiently rare to justify using your version of > last_value. I would like to say a few things about this and offer an alternative solution. First, I think not returning a default constructed value is the correct approach with the last_value combiner for the reasons you've mentioned. I don't think the bug is with the last_value combiner, but with the fact that the last_value combiner is the default combiner (ok an exception rather than an assert would probably be better). However, I would venture to claim that a signal being called without any slots is not a rare case. In fact I'd guess that might be the most likely case. Certainly, as a library writer, I cannot assume that all the signals I provide to my users are going to be used in every application. My suggestion is to provide a default combiner that does the bare minimum, just call the slots: namespace boost { struct default_combiner { typedef void result_type; template<typename InputIterator> result_type operator()(InputIterator first, InputIterator last) const { while (first != last) *first++; } }; } I believe this would solve the problem without restricting use of default signals to objects with default constructors, or to signals with at least one slot connected.

2 1

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 30 Jun '04

30 Jun '04

1. Oh, c'mon, I never implied that your design was "dubious and likely incorrect". It was said in the context of operator[] for std:list. 2. IMHO for a library to be accepted, embraced, popular, survive it has to be suitable/convenient/intuitive for 80% of the users. The library should not go out of its way to satisfy esoteric requirements of 20% at the expense of clarity/simplicity/good design. Or example, std:auto_ptr is not for everyone and not always work where I'd like it to work. It does not mean std::auto_ptr needs to sacrifice its efficient and minimalistic beauty to make me happy. Getting back to Boost.Threads I'd still like to see a compelling example where I'd need to declare try_lock but twist its intuitive functionality into behaving like scoped_lock (that is blocking until locked). -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Matt Hurd Sent: Wednesday, 30 June 2004 10:42 AM To: boost(a)lists.boost.org Subject: Re: [boost] Re: Boost.Threads: Do we need all those mutexes? On Wed, 30 Jun 2004 10:17:04 +1000, Batov, Vladimir <vladimir.batov(a)ca.com> wrote: > > Why give the user an alternative with is > dubious and likely incorrect? It is a pattern of need for multithreaded programming where I work to require single and multithreaded awareness for objects where performance excludes the option of using separate object instances. I don't think the design is dubious or incorrect it is mandated by the business requirements. Though most of my designs usually are incorrect or dubious ;-) I just call those tactical :-) matt. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

3 2

[Graph] problem with set_property method when using subgraph?
by Daniel Lou 30 Jun '04

30 Jun '04

Hi, I wanted to set meaningful names for individual subgraphs but I failed with the following test code.... ---------------------------------------------------------------------------- --------------- typedef adjacency_list<vecS, vecS, directedS,no_property, no_property, property<graph_name_t, string> > mygraph_t; typedef subgraph < graph_t > mysubgraph_t; graph_t g; boost::set_property(g, graph_name, "graph"); // **** this is O.K. mysubgraph G; boost::set_property(G, graph_name, "subgraph"); // **** Error C2784 cout << boost::get_property(G, graph_name) << endl; ---------------------------------------------------------------------------- - I use .NET 2003. The error message says: could not deduce template argument for 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,Edg eProperty,GraphProperty,EdgeListS> &' from 'mysubraph_t' Any thoughts? Thanks, Daniel

2 1

[BGL] remove_edge bug
by Vladimir Prus 30 Jun '04

30 Jun '04

Jeremy, I think your reversion 1.120 of detail/adjacency_list.hpp: 2004-04-01 05:30 jsiek * detail/adjacency_list.hpp: fixed remove_edge for bidirectional graphs actually breaks remove_edge in a different way. Please take a look at http://zigzag.cs.msu.su:7813/program_graph.cpp The code there add two vertices, an edge between them, and then removes the edge. After that 'num_edges' returns 1, not 0 as expected. I seems like now remove_edge removes elements from out_edges and in_edges storage, but not from global edges vector. Is it possible to fix this problem? TIA, Volodya

2 3

[BGL] Unused parameter "inf" in dijkstra_shortest_paths?
by Douglas Gregor 30 Jun '04

30 Jun '04

Hmmm, this could be a bug, but I don't have time to look into it now: /home/gregod/Projects/Boost/boost/boost/graph/dijkstra_shortest_paths.hpp: In function `void boost::dijkstra_shortest_paths_no_init(const VertexListGraph&, typename boost::graph_traits<G>::vertex_descriptor, PredecessorMap, DistanceMap, WeightMap, IndexMap, Compare, Combine, DistInf, DistZero, DijkstraVisitor) [with VertexListGraph = boost::adjacency_list<boost::listS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_name_t, std::string, boost::no_property>, boost::property<boost::edge_name_t, std::string, boost::property<boost::edge_length_t, double, boost::property<boost::edge_speed_limit_t, int, boost::property<boost::edge_direction_t, char, boost::property<boost::edge_snow_route_t, bool, boost::no_property> > > > >, boost::no_property, boost::listS>, DijkstraVisitor = boost::dijkstra_visitor<boost::null_visitor>, PredecessorMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<Intersection*, std::vector<Intersection, std::allocator<Intersection> > >, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, Intersection, Intersection&>, DistanceMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > >, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, double, double&>, WeightMap = boost::adj_list_edge_property_map<boost::bidirectional_tag, double, double&, size_t, boost::property<boost::edge_name_t, std::string, boost::property<boost::edge_length_t, double, boost::property<boost::edge_speed_limit_t, int, boost::property<boost::edge_direction_t, char, boost::property<boost::edge_snow_route_t, bool, boost::no_property> > > > >, boost::edge_length_t>, IndexMap = boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, Compare = std::less<double>, Combine = boost::closed_plus<double>, DistInf = double, DistZero = double]': /home/gregod/Projects/Boost/boost/boost/graph/dijkstra_shortest_paths.hpp:171: warning: unused parameter `double inf' /home/gregod/Projects/Boost/boost/boost/graph/dijkstra_shortest_paths.hpp: In function `void boost::dijkstra_shortest_paths_no_init(const VertexListGraph&, typename boost::graph_traits<G>::vertex_descriptor, PredecessorMap, DistanceMap, WeightMap, IndexMap, Compare, Combine, DistInf, DistZero, DijkstraVisitor) [with VertexListGraph = boost::adjacency_list<boost::listS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_name_t, std::string, boost::no_property>, boost::property<boost::edge_name_t, std::string, boost::property<boost::edge_length_t, double, boost::property<boost::edge_speed_limit_t, int, boost::property<boost::edge_direction_t, char, boost::property<boost::edge_snow_route_t, bool, boost::no_property> > > > >, boost::no_property, boost::listS>, DijkstraVisitor = boost::dijkstra_visitor<boost::null_visitor>, PredecessorMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<Intersection*, std::vector<Intersection, std::allocator<Intersection> > >, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, Intersection, Intersection&>, DistanceMap = boost::iterator_property_map<__gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > >, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, double, double&>, WeightMap = TravelTimePropertyMap, IndexMap = boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, std::string, boost::no_property>, size_t>, Compare = std::less<double>, Combine = boost::closed_plus<double>, DistInf = double, DistZero = double]': /home/gregod/Projects/Boost/boost/boost/graph/dijkstra_shortest_paths.hpp:171: warning: unused parameter `double inf' Doug

2 1

Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 30 Jun '04

30 Jun '04

>>" Thread-safety should not be a run-time configurable property." > I think this is somewhat incorrect as absolutes usually are. Well, I'll probably lose the fairly abstract discussion of general incorrectness of absolutes. :-) I just think that compile-time vs. run-time is a pragmatic choice. Why give the user an alternative with is dubious and likely incorrect? For that reason std::list does not provide operator[] even though it could. Surely, one could come up with his/her design that would "require" such an operator for std::list. Does it invalidate the decisions STL designers made? I do not think so. That is why I am suspicious of temptations to lump distinctly different functions of scoped_lock, try_lock and timed_lock into one universal blob. V.

3 2

Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 30 Jun '04

30 Jun '04

> bool foo(bool threadsafe) > { > mutex::scoped_lock l(m, !threadsafe); > } I am not sure if the example above is appropriate and indicative of the problem we are trying to solve. Thread-safety should not be a run-time configurable property. Like we do not decide on the fly (at run-time) if our ref.-counting class is to be thread-safe or not. All that is resolved at compile time. More so, that still can be solved with statically defined lock/nolock constructors: bool foo(bool some_condifion) { mutex::scoped_lock l(m, boost::nolock); if (some_condition) l.lock(); } 2. I feel that our assumptions of try_lock (yes, I know it is try_scoped_lock, I am just lazy) and timed_lock being refinements of scoped_lock are incorrect. At best scoped_lock and try_lock are refinements of timed_lock as scoped_lock is timed_lock with time=infinite and try_lock is timed_lock with time=0. Therefore, we you insist on common lock functionality, it has to be encapsulated in one timed_lock (or maybe some basic_lock or just a lock). Then, all locks would refine that common behavior. That approach has the advantage of covering the case when I do not know what I want :-) -- then I'd simply use the basic_lock. 3. However, I personally feel that our attempts of generalizing locks are misguided. Locks are different, serve different purposes and provide different and distinct functionality. I feel that we should make an effort to keep different locks different and lean. Like try_lock actually tries to lock. Adding blocking (lock()) functionality to such a lock looks like a mistake as IMHO it encourages bad programming style as it allows to use try_lock where scoped_lock is needed. I feel that the situation when I do not know what kind of lock I need when I step into a function shows that the function needs to be-restructured/split so that in every new component I do know what I need. V.

3 2

Boost.Threads proposed change: lock constructors
by Michael Glassford 30 Jun '04

30 Jun '04

Below I detail proposed changes to the Boost.Threads lock class constructors. Comments? Questions? Mike ----------------------------------------------------------------- The Boost.Threads lock concept constructors are currently defined as follows: Definitions ----------- L: lock type l: lock variable (type L) m: mutex variable (appropriate Mutex type) s: initial lock state (type bool, true=locked, false=unlocked) Lock Concept ------------ L l(m,s) //Blocking lock if s L l(m) //Blocking lock TryLock Concept --------------- L l(m,s) //Blocking lock if s L l(m) //Non-blocking lock TimedLock Concept ----------------- L l(m,s) //Blocking lock if s L l(m,t) //Blocking lock, failing if not obtained by time t These definitions have the following drawbacks: 1) That one of the TryLock constructors blocks while the other doesn't is neither obvious nor very consistent. 2) That the single-parameter constructor of Lock blocks while the single-parameter constructor of TryLock doesn't is neither obvious nor very consistent. 3) Part of the reason for the above inconsistencies is that it's not clear whether the constructors of TryLock should block or not. 4) The TimedLock constructors have no way to request a non-blocking lock. To address these problems, I would like to redefine the lock concept constructors as follows (changes indicated with "^"): Definitions ----------- L: lock type l: lock variable (type L) m: mutex variable (appropriate Mutex type) s: initial lock state (enum type {NO_LOCK=0, LOCK=1}) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ b: block? (enum type blocking_state {NON_BLOCKING=0, BLOCKING=1}) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Lock Concept ------------ L l(m,s) //Blocking lock if s L l(m) //Blocking lock TryLock Concept --------------- L l(m,s,b) //Lock if s; blocking if b ^ ^^^^^^^^^^^^^ L l(m,b) //Lock; blocking if b ^ ^^^^^^^^^^^^^ TimedLock Concept ----------------- L l(m,s,b) //Lock if s; blocking if b ^ ^^^^^^^^^^^^^ L l(m,t) //Blocking lock, failing if not obtained by time t Note: s and b are defined as enums rather than bools to prevent existing code from breaking silently: e.g., if s and b were bools, "TryLock l(m, false)", which currently means "construct a lock object but don't obtain a lock", would change with the new definitions to mean "construct a lock and make a non-blocking attempt to obtain a lock". Also, enums are more explicit than bools. Note: these changes will cause some existing code to break by producing compile errors; the compile errors can be fixed by appropriately adding or changing parameters being passed to the changed TryLock and TimedLock constructors. Mike

4 10

[1.32 release] Boost.Test plan
by Rozental, Gennadiy 30 Jun '04

30 Jun '04

I plan to add one more big feature and several small one into this release. I should be able to finish all of this within 3 weeks. I mostly worry about some regression on old compilers. I will try to address most of it before committing. Gennadiy.

8 14

two thread libs? [was: Re: [boost] Re: logging library]
by John Torjo 30 Jun '04

30 Jun '04

> [snip] > Static-link build option added > > The option to link Boost.Threads as a static library has been added back with some limitations. This feature was originally removed because boost::thread_specific_ptr required that Boost.Threads be dynamically linked in order for its cleanup functionality to work on Win32 platforms. Several options are currently being explored to resolve this issue. In the meantime, the ability to link Boost.Threads statically has been added back with boost::thread_specific_ptr support removed from the statically linked version. The decision to add it back was made because its lack is one of the most frequent complaints about Boost.Threads and because the other approaches that are being investigated to deal with boost::thread_specific_ptr cleanup look fairly promising. so if I get the latest boost.thread I'll have all this (ability to use it as a static lib)? > > Note > Boost.Threads is still dynamically linked by default. In order to force it to be statically linked, it is necessary to #define BOOST_THREAD_USE_LIB before any of the Boost.Threads header files are #included. I'm not sure this is ok with me. I think it should still be statically linked by default (see below). > > Note > If the boost::thread_specific_ptr cleanup issue cannot be resolved by some other means, it is highly likely that the option to statically link Boost.Threads will be removed again in a future version of Boost, at least for Win32 platforms. This is because the boost::thread_specific_ptr functionality will be increasingly used by Boost.Threads itself, so that proper cleanup will become essential in future versions of Boost.Threads. Again, I don't understand why you need thread_specific_ptr within boost.threads so much. Anyway, if you need thread_specific_ptr so much, maybe we could do away with two libraries, something like: 'thread' and 'thread_ext' or so. In the thread, we should keep what was roughly before: - mutexes (don't tell me they need TLS) and scoped locks - thread class (no cleanup support) - xtime In the thread_ext, include whatever needs thread_specific_ptr, and extra goodies - this will have the statically/dynamically linked issue. I think this would be quite good in the long run, since there are so many libs/applications that only need basic thread support, and who really don't want an extra DLL added to the maintenance list. Best, John -- John Torjo Freelancer -- john(a)torjo.com -- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy!

1 0