June 2004 - Boost - lists.preview.boost.org

Implicit failures in MetaComm regression tests?
by Doug Gregor 30 Jun '04

30 Jun '04

The Boost.Function test case "lambda_test" for intel-win32-7.1-vc6 (and its STLport variant) come out as unexpected passes. I'd like to move these over to explicit passes, but they don't seem to be marked as expected failures in status/explicit-failures-markup.xml. How can I make these expected passes, to get that nice cushy all-green feeling? Doug

3 4

Cvs tag dependency
by Rozental, Gennadiy 30 Jun '04

30 Jun '04

Hi, Inn a light of recent discussion on earlier freezing, I have following question/proposition: Is it exist in Boost.Build or could we add feature that allow us to specify cvs tag dependency as a dependency grist? Example1: Jamfile ------- MY_SRCS = .... tag_to_test = my_lib_dev # HEAD run my_test : <tag:$(tag_to_test)>$(MY_SRCS) Now If I want to test my new development branch I just set tag to appropriate value. Example2: Jamfile ------- exe my_test : ...sources... <tag:1_31_0><lib>../build/boost_unit_test_framework Now I want stable version of library - I specify which one I want. Example3: Jamfile ------- exe my_test : ...sources... <tag:1_30_0>...abc.h Here I know my code works with that version of header file I want to use it specifically. And so on. This feature could allow us to: 1. Test development branches for regressions 2 .Test new features before moving it in cvs HEAD 3. Depend on stable version of dependency, without need to keep up with changes in it. 4. Test development version Boost.Test with stable version of it e.t.c I am sure it's not easy to do. But may be it worth a shot. Gennadiy.

3 2

boost::variant visitor member instantiation question
by craig perras 30 Jun '04

30 Jun '04

Hello - I want to do type conversions (checked at compile-time) using boost::variant. So I naively made a 'convert' visitor, which has designed to (hopefully) safely convert the variant value to another type (eg: a client might try to assign the variant's int value to an unsigned short). For instance: typedef boost::variant < std::string, int, double > ParamValue; // ----- ConvertParamValueVisitor //T is the type which will be assigned the variant's value //V is the Variant/Visitor template<typename T> struct ConvertParamValueVisitor<T> { typedef ConvertParamValueVisitor self; typedef void result_type; self( T*& val ) : value_(val) {} template<typename V> result_type operator()( const V& v, typename boost::enable_if<TypeTraits::is_arithmetic<V> >::type* dummy = 0 ) const { *value_ = boost::numeric_cast<T>(v); } template<typename V> result_type operator()( const V& v, typename boost::enable_if<TypeTraits::is_string<V> >::type* dummy = 0 ) const { *value_ = v; } private: T*& value_; }; It seems boost::variant will instantiate all members for all variant types, even the ones I try to suppress using enable_if. To work around this, I've tried various things, like specializing ConvertParamValueVisitor based on T, using lazy_enable_if, etc. Here's one attempt: // ----- ConvertParamValueVisitor //T is the type which will be assigned the variant's value //V is the Variant/Visitor //not implemented template<typename T, class Enable = void> struct ConvertParamValueVisitor; //ConvertParamValueVisitor int, double: use numeric cast template<typename T> struct ConvertParamValueVisitor<T, typename boost::enable_if<TypeTraits::is_arithmetic<T> >::type > { typedef void result_type; typedef ConvertParamValueVisitor self; self( T*& val ) : value_(val) {} template<typename V> result_type operator()( const V& val, typename boost::enable_if<TypeTraits::is_arithmetic<V> >::type* dummy = 0 ) const { *value_ = boost::numeric_cast<T>(val); } //not implemented template<typename V> result_type operator()( const V& val, typename boost::enable_if<TypeTraits::is_string<V> >::type* dummy = 0 ) const; private: T*& value_; }; //ConvertParamValueVisitor string template<typename T> struct ConvertParamValueVisitor<T, typename boost::enable_if<TypeTraits::is_string<T> >::type > { typedef void result_type; typedef ConvertParamValueVisitor self; self( T*& val ) : value_(val) {} //not implemented template<typename V> result_type operator()( const V& val, typename boost::enable_if<TypeTraits::is_arithmetic<V> >::type* dummy = 0 ) const; template<typename V> result_type operator()( const V& val, typename boost::enable_if<TypeTraits::is_string<V> >::type* dummy = 0 ) const { *value_ = val; } private: T*& value_; }; Is there any way to get something like this to work? Am I simply mis-applying boost::variant? I could of course just throw an exception in the unsupported/not implemented methods above, but I'd like this checked at at compile time if possible. (note that my question is generally applicable to visitors, not just to boost::variant). thanks! --craig __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

1 0

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