July 2004 - Boost - lists.boost.org

Re: Threads Rewrite?
by Tonko Juricic 27 Jul '04

27 Jul '04

Michael Glassford wrote: > The next release will clean up TLS right after the > thread function exits, but that doesn't work for > threads that aren't created by Boost.Threads. If > that's good enough for you, good! However, if you > need TLS cleanup for threads not created by > Boost.Threads, the DLL_THREAD_DETACH or some other > approach is still necessary. I see your point! I guess this is more of a taste/philosophy issue. Leaning toward "less code is better" philosophy I would tend to take a position : you are not using boost threads? Then it's yours, rather than boost code responsibility, to clean up TLS. I don't see anything particularly productive coming out of discussing such issues here so let's put it in IMHO folder. Regards, Tony __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

2 1

BOOST_BIG_ENDIAN
by Jody Hagins 27 Jul '04

27 Jul '04

This macro (and its friend BOOST_LITTLE_ENDIAN) definition appears in boost/detail/limits.hpp. However, that file is included only if boost/limits.hpp does not detect the standard <limits>. Thus, it does not get defined for more standard compilers. The serialization library makes use of this macro (in a test), so I wonder how it works on standard compilers. I could use the ENDIAN macros in some of my code to provide compile time performance options (linux provides something similar). Is it possible to move the ENDIAN macros into some other header so that they are more easily obtained, and also do not force including a limits workaround? I also imagine if they were actually included in more compilations, that they could get checked for correctness and the maintenance of newer platforms would increase. Thanks!

6 8

RE: [boost] Building Libraries in Boost
by Reece Dunn 27 Jul '04

27 Jul '04

Jody Hagins wrote: >Most of boost is implemented in header files (as most is based on >templates). However, what are the guidelines for splitting code into >compilable units? As far as I know, anything sensible. >For example, if a library is not a template library, should the author >strive to implement it entirely in headers as inline functions, or >should it be implemented as part inline functions and part a compiled >library? If the code is non-template and is non-trivial, it should really be a part of a compiled library. For trivial functions (e.g. returning data information), these should be inlined. Boost uses the Boost.Build system to compile the libraries (see the installation docs for information on how to setup and configure either V1 or V2). You will need to create a Jamfile that describes the library so that it can be built (this will normally be in libs/<library>/build), with the source in libs/<library>/src. I suggest that you take a look at the existing libraries that have built components: Boost.DateTime; Boost.RegEx; Boost.Signals; Boost.Graph; Boost.Thread; Boost.FileSystem and Boost.ProgramOptions. If you get stuck with Boost.Build you can contact the Boost.Build mailinglist. >A fair amount of code uses the PIMPL pattern to reduce header >complexity, reduce interface and implementation exposure, and to reduce >compile times. However, this requires, in large part, separate compiled >libraries. Whether or not to use PIMPL should be a design decision based on the library requirements. There are also non-class functions that may be a part of a library that exist in a compiled unit (see Boost.FileSystem). Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

1 0

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