- Boost - lists.boost.org

Building Libraries in Boost
by Jody Hagins 28 Jul '04

28 Jul '04

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? 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? 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. What is the Boost position in this regard? Thanks!

2 1

sporadic bjam crashes on WinXP box
by Gennadiy Rozental 28 Jul '04

28 Jul '04

When I run Boost.Test unit test for 10 compilers in crashes sometimes (but quite regularly). How could I track the issue? Looks like it depend on amount target it actually need to update with current run. Gennadiy.

4 5

Re: [boost] RE: Re: DLL library (Was: Re: additional boost libraries?)
by Robert Ramey 28 Jul '04

28 Jul '04

Vladimir Prus wrote: >I know next to nothing about COM, so can't on this idea. In all cases, I >think it's a bit beyond the scope. I have some experience writing applications that use COM. Reading through this discussion makes me wonder if this isn't a re-invention of the COM wheel. I don't know anything about CORBA. I has always presumed it was similar to COM. COM starts out as simple in principle and ends up being very complex. It seems that Microsoft has now rolled up that functionality into Dot Net and no longer promotes COM. I would think a careful study of COM/CORBA would be key to pursuing this line of inquiry. Robert Ramey

4 3

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

28 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 28 Jul '04

28 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