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

min, max, GCC 2.95.3, and STLport
by Doug Gregor 01 Jul '04

01 Jul '04

The new handling of min/max seems to break under GCC 2.95.3 with STLport. I'm not quite sure _why_ it doesn't work (I don't have the compiler around), but you can see the failure here: http://tinyurl.com/ytdlf Perhaps someone with that compiler/lib combination could get preprocessed output for the problem area so we could see what's happening? Doug

4 5

ccref
by alnsn＠yandex.ru 01 Jul '04

01 Jul '04

This is not a typo, I'm trying to emphasize that ref, cref, ... sequence lacks one element which imposes more strict requirements on its argument. According to IQ tests logic that sequence should be continued with ccref :) If seriously, cref allows silent binding of a temporary to a reference. Apparently, this is not always fine. Inspired by N1610 (thanks to Dave and Gary) I've tried to detect both const and non-const rvalues. I didn't yet opened my copy of the standard to check it but the code seems to work on g++ 3.2.2, g++ 3.4.0, Intel 8.0 (all under linux) and Comeau online. #include <boost/ref.hpp> template<class T1, class T2> struct enable_if_same { }; template<class T> struct enable_if_same<T,T> { typedef int type; }; template<class T> boost::reference_wrapper<T const> const ccref(T volatile& r, typename enable_if_same<T,T const>::type = 0) { return boost::reference_wrapper<T const>(const_cast<T const&>(r)); } struct convertible_to_int { operator int() const { return 0; } }; template<class T> boost::reference_wrapper<T const> const ccref(T const volatile& r) { return boost::reference_wrapper<T const>(const_cast<T const&>(r)); } int rvalue() { return 0; } int const const_rvalue() { return 0; } int main() { int i; int const j = 0; ccref(i); ccref(j); // Try uncommenting any of these lines: // ccref(rvalue()); // ccref(const_rvalue()); } -- Alexander Nasonov

3 4

Links at ACCU
by David Abrahams 01 Jul '04

01 Jul '04

Hi, I recently got this request from the ACCU website admins: Please take a look at www.accu.org/terse/cpp.htm and let me know how the Boost library/people would like to be represented on www.accu.org/terse/cpp.htm. So I figured I'd ask. Anyone have an opinion? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

5 4

RE: [boost] Re: Cvs tag dependency
by Rozental, Gennadiy 01 Jul '04

01 Jul '04

> "Rozental, Gennadiy" <gennadiy.rozental(a)thomson.com> writes: > > > 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? > > I _think_ what you're proposing is interesting, but the means > of getting there may be completely inappropriate for > Boost.Build, if I understand it at all. Why don't you try to > say what you're trying to accomplish without trying to design > the Boost.Build feature? I want to be able to use regression testing facility not only for HEAD cvs state. > Are you trying to get cvs checkout > actions into the build system? Namely. I want build system be aware about different versions of files/components and want to be able to specify which version I prefer to use for this particular test. > If so, why? What's wrong with doing > > cvs update -rwhatever_tag > before kicking off the test? Nothing. I just want it happened automatically on a computer that performs regression testing, depends on a rule defined in a Jamfile. > Dave Abrahams Gennadiy.

3 2

[MPL] rational_c and fixed_c
by Cromwell Enage 30 Jun '04

30 Jun '04

A while back it was mentioned that boost::mpl::rational_c and boost::mpl::fixed_c needed redesigning. Before I attempt to tackle this task anymore than I already have, I should have some questions answered. 1. For those compilers for which BOOST_NO_LIMITS is defined, I've learned that there is no way to include a floating-point number in an integral constant expression. Does this mean that no matter how I define fixed_c::value, I cannot pass fixed_c as a template argument to a metafunction that ordinarily takes integral_c as input? Do I have to duplicate the functionality as a result? If so, what should be the naming convention for these new metafunctions? 2. Should I define fixed_c in terms of rational_c, to reduce the amount of functionality I may need to duplicate? Something like this: template <typename IntType, IntType N, IntType PowerOf10> struct fixed_c { typedef rational_c<IntType,...,...> type; }; 3. Eventually the compile-time rational-number representation will need to be converted to a runtime floating-point value. Should I define this conversion function within rational_c (which means an additional template parameter, with either function or class scope, defining the return value type), within a wrapper struct, or somewhere else? And how? 4. I only have to deal with rational numbers, right? I don't have to worry about accurately representing a transcendental number or a complex-number expression? TIA! Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer

3 7

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

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

[1.32 Plan] multi_index
by Joaquín Mª López Muñoz 30 Jun '04

30 Jun '04

This is the plan for release of Boost.MultiIndex. This is a newly added library. Current status: commited in the CVS since 6 weeks or so. Regression tests are OK for all the compilers that I intend to support. If someone is interested in some other compiler being supported, please contact me. Pending issues: #1 Minor updates to the docs. No big deal. #2 Some changes related to the new defect macro BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS These issues will be resolved way before the branching date, I hope. Questions: #1 Dave talked about Aleksey going to merge a new version of MPL in the main trunk. When will that happen? How disruptive do you expect it to be wrt to the rest of libraries? #2 Should I update the additional stuff right away (links in the main and libraries pages, uploading of bio and picture etc.)? Or is anybody else taking care of that stuff? #3 Vladimir just talked about "adding markup for the failures". What is this? Is this something required as part of the regression fixing process? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 5

Explicit markup notes
by Aleksey Gurtovoy 30 Jun '04

30 Jun '04

Could I ask that every time we are adding an explicit failure to "status\explicit-failures-markup.xml" or, even more so, marking up a library as unusable, we also provide a note explaining the markup? We don't have to come up with a specific wording for every single failure -- there are a few standard notes at the end of the document that fit many common situations, and can be simply referenced by their ID (e.g. <note refid="3"/>), but not saying anything at all significantly defeats reports' usefullness. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Library doc link is broken
by Jeff Garland 30 Jun '04

30 Jun '04

The current CVS doc link seems to have gone down... Not Found The requested URL /regression-logs/cs-win32_metacomm/doc/html/libraries.html was not found on this server. Jeff

2 1

[Formal review result] Tribool
by Thomas Witt 30 Jun '04

30 Jun '04

Hi, I am happy to report that the "Tribool" library by Doug Gregor has been ACCEPTED into boost. Other than this there is very little to be said. Reviews were generally in favour of the library and the issues surfaced during the review have been addressed by Doug. There were some comments regarding the scope of the library. While I agree that an broader coverage of 3-valued logic might be good to have, I do not think it justifies delaying acceptance of the library. Regards Thomas Review Manager Tribool -- Thomas Witt witt(a)acm.org

1 0

Bug in token_functions.hpp
by Joe Gottman 30 Jun '04

30 Jun '04

I have found a bug in token_functions.hpp. I have a hello-world program that looks like this: ----------begin file #include <boost/token_functions.hpp> int main(int argc, char* argv[]) { boost::char_separator<char> sep; printf("Hello World!\n"); return 0; } ----------end file It fails under MSVC 6.0 with the following error messages: c:\jobs\boost\token_functions.hpp(261) : error C2065: 'is_pointer' : undeclared identifier c:\jobs\boost\token_functions.hpp(267) : see reference to class template instantiation 'boost::tokenizer_detail::get_iterator_category<Iterator>' being compiled c:\jobs\boost\token_functions.hpp(261) : error C2275: 'Iterator' : illegal use of this type as an expression c:\jobs\boost\token_functions.hpp(267) : see reference to class template instantiation 'boost::tokenizer_detail::get_iterator_category<Iterator>' being compiled c:\jobs\boost\token_functions.hpp(261) : error C2059: syntax error : ',' c:\jobs\boost\token_functions.hpp(267) : see reference to class template instantiation 'boost::tokenizer_detail::get_iterator_category<Iterator>' being compiled c:\jobs\boost\token_functions.hpp(264) : error C2238: unexpected token(s) preceding ';' c:\jobs\boost\token_functions.hpp(267) : see reference to class template instantiation 'boost::tokenizer_detail::get_iterator_category<Iterator>' being compiled c:\jobs\boost\token_functions.hpp(266) : error C2653: 'cat' : is not a class or namespace name c:\jobs\boost\token_functions.hpp(267) : see reference to class template instantiation 'boost::tokenizer_detail::get_iterator_category<Iterator>' being compiled I believe the problem is that we need to add the line #include <boost/type_traits/is_pointer.hp> to token_functions.hpp. If I add this line to my program before including token_functions.hpp, everything compiles fine. Joe Gottman

1 0

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Hurd, Matthew 29 Jun '04

29 Jun '04

> Behalf Of Batov, Vladimir > > > 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. >" Thread-safety should not be a run-time configurable property." I think this is somewhat incorrect as absolutes usually are. I currently have a design where I use both an interface that supports locking and an interface which does not. It is an important feature of the design. Using such a run time parameter is not my choice because I am especially sensitive to performance but it might be a better design for others given other requirements. Non-locking versions are also useful when you want to combine operations. Take a lock, do stuff, and then release lock. Repeatedly locking has deficiencies which may or may not matter to you. $0.005, Matt Hurd. FWIW I wrap boost mutexex and locks in my own policy-like stuff. E.g: ___________________________________________________________ struct shareable { protected: struct adapted_mutex : public boost::rw_mutex { adapted_mutex( lock_priority::type lp = lock_priority::exclusive ) : rw_mutex( convert( lp) ) {} ~adapted_mutex() {} }; struct adapted_try_mutex : public boost::try_rw_mutex { adapted_try_mutex( lock_priority::type lp = lock_priority::exclusive ) : try_rw_mutex( convert( lp) ) {} ~adapted_try_mutex() {} }; struct adapted_timed_mutex : public boost::timed_rw_mutex { adapted_timed_mutex( lock_priority::type lp = lock_priority::exclusive ) : timed_rw_mutex( convert( lp) ) {} ~adapted_timed_mutex() {} }; public: typedef adapted_mutex mutex; typedef adapted_try_mutex try_mutex; typedef adapted_timed_mutex timed_mutex; typedef shareable_lock<mutex> lock; typedef shareable_lock<try_mutex> try_lock; typedef shareable_lock<timed_mutex> timed_lock; typedef atomic_op_interlocked atomic_op; }; ___________________________________________________________ So I can parameterise classes with a synch policy. (Less than ideal but I haven't got around to making it nicer yet.) For the interface where I need to support single threaded and multi-threaded usage of the same object ( as opposed to type ) I use this approach... ___________________________________________________________ template < class S = synch::shareable > class instrument : public synch::monitor<S> { SYNCH_SIMPLE_ATTRIBUTE( susquehanna_code, std::string ); SYNCH_SIMPLE_ATTRIBUTE( exchange_code, std::string ); SYNCH_SIMPLE_ATTRIBUTE( underlying, std::string ); SYNCH_SIMPLE_ATTRIBUTE( bid, double ); SYNCH_SIMPLE_ATTRIBUTE( bid_volume, double ); SYNCH_SIMPLE_ATTRIBUTE( ask, double ); SYNCH_SIMPLE_ATTRIBUTE( ask_volume, double ); SYNCH_SIMPLE_ATTRIBUTE( last, double ); SYNCH_SIMPLE_ATTRIBUTE( last_volume, double ); SYNCH_SIMPLE_ATTRIBUTE( prior_settlement, double ); }; ___________________________________________________________ This way I can use an object in the following manner: ___________________________________________________________ te::instrument<> i_sample; i_sample.exchange_code<true>("hello"); // locking { te::instrument<>::lock lk( i_sample.guard() ); i_sample.exchange_code<false>("hello"); // non-locking } i_sample.exchange_code("hello"); // locking std::string hello = i_sample.exchange_code(); // locking hello = i_sample.exchange_code<false>(); // non-locking hello = i_sample.exchange_code<true>(); // locking hello = i_sample.exchange_code_ref(); // non-locking by nature ___________________________________________________________ I could also specify te::instrument< synch::no_synch > // locking is elided te::instrument< synch::simple > // exclusive locking te::instrument< synch::no_synch > // allows recursive locking te::instrument< synch::shareable > // allows shared or exclusive locks (think r/w) The interface to the non-locking version is still valid. User must code to shareable concept for everything to work for all concepts. Where SYNCH_SIMPLE_ATTRIBUTE defines a bunch of simple attribute helpers and looks like: #define SYNCH_SIMPLE_ATTRIBUTE( VAR_NAME, VAR_TYPE ) \ \ public: \ template< bool > \ void \ VAR_NAME \ ( \ boost::call_traits< VAR_TYPE >::param_type new_ ## VAR_NAME \ ) \ { \ if ( boost::needs_lock<VAR_TYPE>::value ) { \ lock lk(guard_ ); \ VAR_NAME<false>( new_ ## VAR_NAME); \ } else { \ VAR_NAME<false>( new_ ## VAR_NAME); \ } \ } \ \ void \ VAR_NAME \ ( \ boost::call_traits< VAR_TYPE >::param_type new_ ## VAR_NAME \ ) \ { \ VAR_NAME < true > ( new_ ## VAR_NAME ); \ } \ \ template< > \ void \ VAR_NAME<false> \ ( \ boost::call_traits<VAR_TYPE>::param_type new_ ## VAR_NAME \ ) \ { \ VAR_NAME ## _ = new_ ## VAR_NAME; \ } \ \ template< bool > \ VAR_TYPE \ VAR_NAME( ) const \ { \ if ( boost::needs_lock< VAR_TYPE >::value ) { \ lock lk(guard_, synch::lock_status::shared ); \ return VAR_NAME<false>( ); \ } else { \ return VAR_NAME<false>( ); \ } \ } \ \ VAR_TYPE \ VAR_NAME( ) const \ { \ return VAR_NAME<true>( ); \ } \ \ template< > \ VAR_TYPE \ VAR_NAME <false>() const \ { \ return VAR_NAME ## _; \ } \ \ boost::call_traits<VAR_TYPE>::const_reference \ VAR_NAME ## _ref( ) const \ { \ return VAR_NAME ## _; \ } \ \ private: \ VAR_TYPE VAR_NAME ## _; \ SYNCH_SIMPLE_ATTRIBUTE includes an extra thing boost::needs_lock<VAR_TYPE>::value that checks if the size of the type is > pointer size which means, for Intel & AMD, that locking is not required as the assignment of aligned types is atomic. Copy constructors, assignment and cloning are further issues ;-) IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

Proposal: signed.hpp
by Jeffrey C. Jacobs 29 Jun '04

29 Jun '04

Based on Dave Abrahams' recent notes, may I suggest the following draft for revision? http://starship.python.net/crew/timehorse/signed.hpp Thanks! Jeffrey

2 1