February 2004 - Boost - lists.stage.boost.cppalliance.org

Proposed change to license references
by David Abrahams 03 Apr '04

03 Apr '04

Given recent advice from Diane Cabell, director of Harvard's Berkman Center for Internet and Society, I propose we change the way that boost source files refer to the bost license from: // Use, modification, and distribution is subject to the Boost Software // License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy // at http://www.boost.org/LICENSE_1_0.txt) to: // Distributed under the Boost // Software License, Version 1.0. (See accompanying file // LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) The earlier license reference, by referring explicitly to "use, modification, and distribution", legally excludes important issues like "display", which are covered by the license itself and are intended to apply to source files. I'm posting this now to give people a chance to come up with any other issues -- **with the license reference comment**, not the license itself -- that may need to be addressed before we make a change. If there are no new issues within a week or so, we'll make it official. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Moving tss changes from thread_dev branch to HEAD
by Michael Glassford 27 Mar '04

27 Mar '04

The thread_dev branch in CVS contains a number of changes to the thread_specific_ptr / tss implementation that I would like to move to the main branch. I plan to look at it more carefully before I do so, but will anyone interested please take a look at the implementation on the thread_dev branch to see if has any problems (or if there are known problems that it doesn't fix)? It contains changes to fix a number of issues with the current implementation, including, among others: 1) thread_specific_ptr::reset() doesn't check error: http://lists.boost.org/MailArchives/boost/msg55713.php. 2) Double deletes: http://lists.boost.org/MailArchives/boost/msg50266.php, http://lists.boost.org/MailArchives/boost/msg50543.php, http://lists.boost.org/MailArchives/boost/msg30433.php, http://lists.boost.org/MailArchives/boost-users/msg05531.php. 3) Not enough tss keys/slots: http://lists.boost.org/MailArchives/boost/msg55376.php, http://lists.boost.org/MailArchives/boost/msg55712.php. 4) Ability to register custom cleanup functions. For reference, see: tss.hpp, http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/boost/thread/t… tss.cpp, http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/thread/sr… threadmon.cpp, http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/thread/sr… Mike

2 1

[BGL] transpose_graph documentation.
by Cromwell Enage 21 Mar '04

21 Mar '04

Accodring to <http://www.boost.org/libs/graph/doc/transpose_graph.html> the graph that will hold the transposition is supposed to have no edges in it and to have the same number of vertices as the input graph. However, looking through the source code in <boost/graph/copy.hpp>, which the algorithm uses, I see as many vertices being added to the output graph as there are in the input graph. Does this mean that the output graph is actually supposed to have no vertices to begin with? In the attached program, if the #if condition is set to 1, the program does as the documentation currently suggests, but the output is wrong. With the #if condition left at 0, the program gives the correct output. What's the verdict? Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools

1 0

BOOST_TRY like macros: time to add them?
by Pavel Vozenilek 12 Mar '04

12 Mar '04

Disabling try/catch through preprocessor when compiling without exception support was suggested e.g by Robert Ramey in: http://aspn.activestate.com/ASPN/Mail/Message/boost/1799735 Right now there are 3 libraries near review, each using their own set of similar macros: - circular_buffer - indexed_set - serialization The reasons to use macros instead of RAII is convenience and performance. Some compilers (BCB) do not allow try/catch with exceptions disabled so some solution is needed. It would be better to have and use standardized macros in Boost. Example: macros used in indexed_set: #if !defined(BOOST_NO_EXCEPTIONS) # define BOOST_INDEXED_SET_TRY try # define BOOST_INDEXED_SET_CATCH(x) catch(x) # define BOOST_INDEXED_SET_RETHROW throw #else # define BOOST_INDEXED_SET_TRY # define BOOST_INDEXED_SET_CATCH(x) if(0) # define BOOST_INDEXED_SET_RETHROW #endif Compiles w/o warnings on VC6+, BCB gives unreachable code warning (but I'll try to find workaround). /Pavel

8 10

Re: [boost] small addition to functional
by Fredrik 12 Mar '04

12 Mar '04

John Torjo wrote: >Hi all, >I think since member functions can be wrapped up as >functors, why not >same for member data? >Therefore, I think this could be a useful addition to >functional: <<snip>> >What do you think? I think Peter Dimov has already thought about this ;) Read the current mem_fn docs carefully and you'll find a data-case also. I agree it's very useful functionality. It was added fairly "silently" though (mid 2002 IIRC) which might have made people miss it(?). // Fredrik Blomqvist

1 0

[math constants] a new approach (perhaps)
by Thorsten Ottosen 11 Mar '04

11 Mar '04

Dear boosters, I discovered something that at least was new to me. It's a simple way of coding floating point constants s.t. 1. no overhead at all 2. no order dependencies occur 3. the context in which the constant appears decides the precision of the constants [important in template code] 4. whenever a narrowing or widening conversion is required, explicit action must be taken by the programmer to determine what he wants 5. all precisions of the constants co-exist, so there is no need for several headers Example: #include "math_constant.hpp" #include <iostream> #include <cmath> #include <iomanip> using namespace std; template< typename T > void test(); int main() { cout << setprecision( 10 ); test<float>(); test<double>(); test<long double>(); // cout << pi; // ambiguous cout << float( pi ) << " " << double( pi ) << " " << (long double)( pi ); // ok // int i = pi; // ambiguous int i = float( pi ); // ok cout << sqrt( float( pi ) ); } template< typename T > void test() { T two_pi = T(2) * pi; two_pi = T(pi) + pi; // note: pi operator X() pi is ambiguous T plus = T(1) + pi; T minus = pi - T(1); T divide = pi / T(2); T all = pi + T(3) - T(pi) * pi / T(3); // also ambiguous cout << T( pi ) << " "; } Any comments are more than welcome. I know there are several proposals for defining math constants, but I don't see what the big problems are (so please help me understand them :-) ) br Thorsten

11 24

Re: boost::any: explicit constructor?
by Kevlin Henney 09 Mar '04

09 Mar '04

In message <uk727uuvv.fsf(a)boost-consulting.com>, David Abrahams <dave(a)boost-consulting.com> writes >>> >>>The conversion to boost::any isn't a widening conversion in the usual >>>sense, though, is it? Normally, a widening conversion preserves not >>>only the information but the *interface* of the original data -- you >>>wouldn't consider an implicit conversion from int to string a widening >>>conversion, would you? >> >> Your assumption is not quite correct: most widening conversions are >> not interface preserving. > >So you're saying it's not even a little correct, it sounds like. Can >you give some examples of non-interface-preserving widening >conversions? T * to void *, derived * to base *, int (32 bit) to double (64 bit), T * to const T *, etc. Widening conversions are in the direction of the supertype, hence they often have a subset of the interface of source type. The corresponding narrowing of the interface with the widening of the type is not always the case, eg an int to long is effectively interface preserving -- the same set of operators is supported for both types. Kevlin -- ____________________________________________________________ Kevlin Henney phone: +44 117 942 2990 mailto:kevlin@curbralan.com mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________

5 9

Metrowerks 9.2 approaching 100% on Windows
by Beman Dawes 06 Mar '04

06 Mar '04

The Win32 regression test results now reflect the new Metrowerks 9.2 release. See http://boost.sourceforge.net/regression-logs/ Fails have been reduced to just two: graph adj_list_cc: That's a regression compared to 8.3 and the 9.2 beta that we need to look into. I've emailed Jeremy. type traits is_abstract_test: This is a new test, so it was not tested during the 9.2 beta. I'd appreciate it if the type traits folks would take a look to see if this is a Boost or Metrowerks problem. Anyhow, congratulations to Metrowerks, particularly Howard Hinnant, Andreas Hommel, and Ed Swartz. They put in a lot of effort checking out Boost regression test failures. --Beman

2 1

Re: [boost] Re: [Threads] Simple active object wrapper, take 2
by Mark Blewett 03 Mar '04

03 Mar '04

At 01:02 28/02/2004, you wrote: >scott <scottw <at> qbik.com> writes: > > ps: > > the sample code from mark blewett looks very promising? > > > >Yes. Although from my point of view, it has the same drawback with switching >on messages that you have. I wonder if the queue of messages in the servant >class could be a queue of fully-bound function calls, I'm halfway there, in that the queue holds callbacks, eg in Servant::dispatch the "do something with m" simply executes the callback. To give a usage example class MyServant : public Servant { public: MyServant(Scheduler* scheduler) : Servant(scheduler) {} void do_fn(int x, int y) { std::cout << x << " " << y << std::endl; } }; int main() { Scheduler scheduler; scheduler.start(1,1); MyServant my_servant(&scheduler); my_servant.post_call(new CallbackVAA<MyServant,int,int>(&my_servant, &MyServant::do_fn, 1, 2)); scheduler.stop(); return 0; } will result in the output "1 2" via one of the schedulers worker threads >generated by proxy >objects which describe interfaces? (Yes, I am quite enamoured of that >idea :)) Interesting idea... assuming I'm understanding correctly.. in that the callback is created by an object in the servant class, the above becomes; class MyServant : public Servant { public: MyServant(Scheduler* scheduler) : Servant(scheduler), fn(this, &MyServant::do_fn) {} MethodProxy<MyServant, int, int> fn; private: void do_fn(int x, int y) { std::cout << x << " " << y << std::endl; } }; int main() { Scheduler scheduler; scheduler.start(1,1); MyServant my_servant(&scheduler); my_servant.fn(1, 2); // certainly a lot easier to understand than previous example! scheduler.stop(); return 0; } Regards Mark --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.573 / Virus Database: 363 - Release Date: 28/01/2004

2 1

RE: [boost] [Threads] Simple active object wrapper, take 2
by scott 02 Mar '04

02 Mar '04

> [mailto:boost-bounces@lists.boost.org]On Behalf Of Matthew Vogt nice! only one item of feedback really. think that i follow your machinery and can envisage the "model of execution" - its pretty slick. its also somewhat different to the pattern :-| so i would wonder at the use of "active object"? is your model of execution the one that everyone is expecting of the previously, unimplemented class? this does seem to be a class/framework for (very convenient) arrangement of concurrent method execution. which piece of the ActiveObject pattern does this map to? other than the "claiming of the name", it looks like its got legs! ps: i s'pose anything declared in the private scope of "object" is thread safe? > > // test_active_object.cpp > -------------------------------------------------- > > > #include "active_object.hpp" > > using std::cin; > using std::endl; > <big snip>

4 7