- Boost - lists.boost.org

Why I couldn't compare optional<int> and optional<long>
by Rozental, Gennadiy 27 Jul '04

27 Jul '04

IMO relational operators in optional implementation should have two template parameters Gennadiy.

1 0

RE: [boost] Re: counting_iterator_test.hpp fails on aC++
by DY, JERRY U (SBCSI) 27 Jul '04

27 Jul '04

Dave, As you suggested, an auxiliary function template is defined (outside of the iterator_adaptor class - aC++ doesn't like it if it's a member function): // workaround for aC++ CR JAGaf33512 template <typename TR1, typename TR2> inline void iterator_adaptor_assert_traversal () { typedef int assertion[sizeof(detail::static_assert_convertible_to<TR2>(TR1()))]; } Then the old static assertion is replaced like so: # define BOOST_ITERATOR_ADAPTOR_ASSERT_TRAVERSAL(cat) \ iterator_adaptor_assert_traversal<my_traversal, random_access_traversal_tag>(); // typedef iterator_adaptor_assert_traversal<my_traversal, cat> assert_traversal_t; I tested this by adapting an ordinary pointer to a forward traversal iterator and if the program calls the operator+= (calling the adaptor's advance member function and triggering the static assertion), the compile fails, the compile succeeds otherwise. There should be no additional overhead incurred due to the workaround because the function itself is inlined and all it does is a typedef. Is this workaround acceptable for check-in? Thanks! -Jerry -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Saturday, July 24, 2004 8:20 AM To: boost(a)lists.boost.org Subject: [boost] Re: counting_iterator_test.hpp fails on aC++ Probably the right way to fix this is to indirect through an auxilliary function template that does the assertion. I presume _that_ wouldn't be instantiated unless it was actually called.

1 0

Re: [config] seems like VC 8.0 needs BOOST_NO_MEMBER_TEMPLATE_FRIENDS
by Michael Stevens 27 Jul '04

27 Jul '04

On Tuesday 27 July 2004 00:42, JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es> wrote: > error C2888: 'void boost::multi_index::safe_mode::detach_equivalent_iterators(Iterator &)' : symbol cannot be defined within namespace 'detail' The error seems to indicate a namespace problem rather then something specific to member template friends? > > I've searched through the VC 2005 beta docs and, > allegedly, member template friends are supported, so this > particular problem could be a bug rather than complete > lack of support for this feature. Maybe someone with > local access to VC 8.0 can test the above code and > see what happens (I currently don't have the time > and resources to try myself.) Maybe the problem is related to namespace handling in VC 8.0 Boost.numeric.interval library fails when included in uBLAS due to a curious namespace problem. http://www.meta-comm.com/engineering/boost-regression/developer/output/Rudb… The same problem effect VC 7.1 as well. Why the compilers think the 'lower' 'upper' symbols are ambiguous I have no idea! -- Michael ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

6 9

Boost Test Library: Bug in floating-point comparison?
by Michael Kettner 27 Jul '04

27 Jul '04

Hi, I want to use the boost::test floating-point comparison algorithms (Boost 1.31.0) and wrote the following simple lines of code: double d1 = 0.2; double d2 = 0.8; double d3 = d2-d1-d1-d1-d1; // d3 should be zero bool b = boost::test_toolbox::check_is_closed( d3, 0., 1e-3 ); To my surprise, the return value b is FALSE, although d3 should be _very_ close to zero (and is 5.55112e-17 on my machine). Am I missing something or is this a bug in the test library? Thanks, Michael -- Michael Kettner kettner(a)ive.uni-hannover.de

1 0

RE: [boost] Re: Lock unification [move]
by Batov, Vladimir 27 Jul '04

27 Jul '04

How 'bout scoped_lock lk1(m, defer); scoped_lock lk2(m, try); > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David Abrahams > Sent: Friday, 23 July 2004 1:15 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Lock unification [move] > > Howard Hinnant <hinnant(a)twcny.rr.com> writes: > > > scoped_lock lk1(m, deferred); > > scoped_lock lk2(m, tried); > > > > <shrug> I disliked "tried" more than I liked "deferred". And I also > > felt that the benefit of symmetry was important to make the interface > > easier to learn. > > You only need part-of-speech symmetry. "deferred" is an adjective, so > "non_blocking", "optional", "permeable",... would work find for the > other one, from a grammatical point of view. I don't think "try" > makes a very good adjective, and adding "_lock" to the end of it > doesn't help. So I don't see the symmetry in > "try_lock"/"deferred_lock" other than the suffix :vP > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

10 18

Re: Boost Digest, Vol 801, Issue 2
by Michael Stevens 27 Jul '04

27 Jul '04

On Tuesday 27 July 2004 12:18, "Victor A. Wagner Jr." <vawjr(a)rudbek.com> > >Maybe the problem is related to namespace handling in VC 8.0 > > > >Boost.numeric.interval library fails when included in uBLAS due to a curious > >namespace problem. > >http://www.meta-comm.com/engineering/boost-regression/developer/output/Rudb… > > > >The same problem effect VC 7.1 as well. Why the compilers think the 'lower' > >'upper' symbols are ambiguous I have no idea! > > because there are two different ones to choose from > Did I miss the :-) here? If only things were so simple. The error occurs in interval/io.hpp. Here a templated operator definition is being defined in the boost::numeric namespace. The definitions of lower/upper we are looking for are in this same boost::numeric namespace. The definitions which VC is getting confused with in the boost::numeric::ublas namespace can only be found by argument dependant (Konig) lookup. We could look this up in the ISO standard. Circumstantial evidence from several other compilers suggests VC 7.1 / 8.0beta is doing the wrong thing here. Which is why I suspect these compilers do not implement namespace perfectly. Michael

1 0

Unit test could usefully output more significant digits to log files?
by Paul A Bristow 27 Jul '04

27 Jul '04

In setting up a test for math function accuracy, I incorrectly coded thus: BOOST_CHECK_EQUAL(sin(0.5), 0.479426); and got the somewhat puzzling - apparently wrong - message error in "call_test_main": test sin(0.5) == 0.479426 failed [0.479426 != 0.479426] On most days of the week, one would expect [0.479426 == 0.479426]! I should of course have written BOOST_CHECK_EQUAL(sin(0.5), 0.47942553860420301); (or used BOOST_CHECK_CLOSE(sin(0.5), 0.47942553860420301, 1e-16);) But I wonder if the test program would be even more helpful if it output all possibly significant digits. In test_tools.hpp, I have added an increase to the ostream precision (default only 6 digits) int print_log_value thus template<typename T> struct print_log_value { void operator()( std::ostream& ostr, T const& t ) { if(std::numeric_limits<T>::is_specialized && std::numeric_limits<T>::radix == 2) { // Show all possibly significant digits (for example, 17 for 64-bit double). ostr.precision(2 + std::numeric_limits<T>::digits * 301/1000); } ostr << t; // by default print the value. } }; so that the message is no longer test sin(0.5) == 0.479426 failed [0.47942553860420301 != 0.47942600000000002] and my folly obvious. And after the original mistake is corrected BOOST_CHECK_EQUAL(sin(0.5), 0.47942553860420301); The log file reports: info: sin(0.5) == 0.47942553860420301 passed. Paul PS (It does not appear to possible to change the precision 'externally' by calling cout.precision(17); myTestLog.precision(17); probably because ostr in test is contructed with default precision). Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow(a)hetp.u-net.com

3 4

FW: pool cleanup
by Aviad Rozenhek 27 Jul '04

27 Jul '04

I am using the object_pool interface, Calling on the object_pool::free () function. On more scrutiny it came down to this: I am not freeing the objects in reverse order of their creation. When I explicitly change the design to make it so, The pool works fine. It also works fine when I wait for the ~object_pool () To clean it up. So these problems remain: 1. when deallocating objects only once in the running of the program (on ~object_pool) and avoiding the cleanup problem stating earlier the pool classes still actually cause a minor downgrade of peformance rather than boosting it. This is the case both in ms-windows port (using Doug Lee's malloc to circumvent microsoft terrible malloc) And on linux port. 2. when not deallocating objects in the reverse order The penalty is overwhelming. For isntance when I turn off all pooling In my application the cleanup make take 3 seconds. Turning on pooling causes cleanup to take an excess of 10 mins ( I give up after that) Possible causes: 1. its not thrashing, because I tested it on a large memory machine. 2. perhaps it's the simple_segragated_storage::find_prev function Because its run time is linear with the size of the chunk. ------------------------------ Message: 5 Date: Thu, 22 Jul 2004 23:48:53 -0700 From: Mark Deric <laguna(a)laguna1.com> Subject: Re: [boost] performance: pool cleanup takes too long To: boost(a)lists.boost.org Message-ID: <20040722234853.09879c08.laguna(a)laguna1.com> Content-Type: text/plain; charset=US-ASCII On Wed, 21 Jul 2004 17:59:40 +0200 "AviadR" <aviadr(a)pob.huji.ac.il> wrote: > the cleanup part (which consists only of calling the pool release > methods on allocated objects) > on the other hand, takes many minutes (I usually give up after 5 > minutes) Are you freeing each on the allocated chunks using pool.free(), or pool.release()? They would need simple_segregated_storage.nextof() Or are you calling ~pool()? The call to ~pool() doesn't use nextof() and should be pretty quick.

1 0

[License] Request for volunteers: converting to the Boost Software License
by Doug Gregor 27 Jul '04

27 Jul '04

The bcp tool is now capable of automatically converting files over to the Boost Software License. However, we need volunteers to verify that the transformation is correct. I have (locally) converted 1256 files that need to be verified, and am asking for volunteers to verify chunks of 100 files each (it won't take all that long...). If you would like to help, please send me e-mail _privately_ and I'll assign a chunk to you. Please tell me which file numbers in the chunk are fine (so I can commit them) and which file numbers are incorrect. To verify a particular file, go to: http://www.boost.org/all-report.html#bsl-converted (It's an 8MB file; you've been warned). Then locate your file numbers (e.g., 1-100) and look at the "before" (left) and "after" (right) chunks of the file. The changed parts are highlighted in bold. Two things need to be verified for a file to be correct (everything else is automatic and correct already): 1) The entirety of the original license must have been removed. 2) Copyrights, author names, etc. have not been destroyed by the transformation. For instance, look at file #1 (boost/assert.hpp): the old license (on the left) has been completely highlighted and replaced by the Boost Software License (on the right), so this transformation is fine. On the other hand, look at file #66 (boost/lambda/detail/bind_functions.hpp): the old license has a clause "This software is provided 'as is'..." that has not been highlighted on the left, and was retained by the transformation. That's a problem: this transformation is not correct. When sending back replies once you've finished a chunk, try to use this form if you could: Correct: 1-10 15-55 Incorrect: 11-14 56-70 We'll need to iterate the process a bit (as we fix up the heuristics to get everything right), but with a little work from everyone I'm sure we can get much of Boost converted over to the BSL in a relatively short time. Doug

2 3

Problems compiling program_options on vacpp
by Matthias Troyer 27 Jul '04

27 Jul '04

Dear Boosters, I have encountered the following problem compiling program_options on the IBM Visual Age compiler 6.0. There seems to be a problem with exception declarations: xlC -DHAVE_CONFIG_H -I../../src -I../../src -DNDEBUG -I/users/matroyer/boost -DNDEBUG -q32 -qlanglvl=extended -O2 -c -M /users/matroyer/boost/libs/program_options/src/convert.cpp -o convert.o "/users/matroyer/boost/boost/program_options/detail/ utf8_codecvt_facet.hpp", line 144.17: 1540-1163 (S) The exception-specification for "int boost::program_options::detail::utf8_codecvt_facet_wchar_t:: do_length(mbstate_t &, const char *, const char *, std::size_t) const" is less restrictive than the exception-specification for "int std::codecvt<wchar_t,char,char *>::do_length(_St &, const _To *, const _To *, size_t) const throw()". Can the throw() declaration be added to do_length()? Matthias

2 3