- Boost - lists.boost.org

[numeric_cast] patch: latest borland compiler needs old workarounds
by AlisdairM 19 Feb '06

19 Feb '06

The current version tests very specifically for bcc 5.64 with an == test. I can't imagine this is correct - i.e. older version of the compiler were supported without workarounds! This patch uses BOOST_TESTED_AT instead. If it really is a regression introduced with the last BCB6 patch, that test should be revised. cvs diff -u -wb -- numeric\conversion\cast.hpp (in directory E:\sourceforge\devel\boost\boost\) Index: numeric/conversion/cast.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/numeric/conversion/cast.hpp,v retrieving revision 1.8 diff -u -w -b -r1.8 cast.hpp --- numeric/conversion/cast.hpp 27 Jun 2005 15:05:12 -0000 1.8 +++ numeric/conversion/cast.hpp 19 Feb 2006 12:19:22 -0000 @@ -22,7 +22,7 @@ #include <boost/detail/workaround.hpp> -#if BOOST_WORKAROUND(BOOST_MSVC, < 1300) || BOOST_WORKAROUND(__BORLANDC__, == 0x564) +#if BOOST_WORKAROUND(BOOST_MSVC, < 1300) || BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x581)) # include<boost/numeric/conversion/detail/old_numeric_cast.hpp> -- AlisdairM

1 0

[rational] operator< fails for unsigned value types. Here's a small patch to fix it
by David Benbennick 19 Feb '06

19 Feb '06

There's a minor bug in rational.hpp when using unsigned values. Consider the following simple program: #include <boost/rational.hpp> #include <cassert> int main(void) { boost::rational<unsigned int> x = 0; assert(x.operator<(1)); } The assertion fails. The reason is that in rational.hpp::rational<IntType>::operator< (param_type i) are the lines if (num > zero) return (num/den) < i; else return -i < (-num/den); <-- this is bogus for unsigned types if num == 0. Attached are two patches to fix the problem. The first is a minimal patch, changing the > to >=. The second patch changes more: in the current code, up to 5 comparisons can happen. In the patched version, only 3 comparisons are done. Cheers, David Benbennick

1 0

[Boost Test] - MSVC 6.0 issue in recent HEAD
by Robert Ramey 19 Feb '06

19 Feb '06

In preparing to upload some changes to the serialization library I updated my local tree and re-ran my tests. I'm getting a new kind of error with MSVC 6.0 - here it is. It looks to me that something has been improved in the test library beyond the point of functionality - at leaset as msvc 6.0 is concerned. Robert Ramey logged_expectations.cpp C:\BoostHead\boost/test/utils/named_params.hpp(269) : error C2989: 'typed_keyword<bool,T,0>' : template class has already been defined as a non-template class C:\BoostHead\boost/test/utils/named_params.hpp(269) : error C2988: unrecognizable template declaration/definition C:\BoostHead\boost/test/utils/foreach.hpp(353) : fatal error C1506: unrecoverable block scoping error

6 8

[MPL] Error in replace_if docs
by Bruno Martínez 19 Feb '06

19 Feb '06

Hi. In the reference documentation of mpl, replace_if's synopsis lacks the NewType parameter. Bruno

2 1

[shared_ptr] Workaround for vc7.1 bug
by David Abrahams 19 Feb '06

19 Feb '06

This failure: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/output… Appears to be due to vc7.1 badly misinterpreting a using-directive in the scope of the instantiating function. I suggest full qualification of ::boost::detail in shared_ptr.hpp as a remedy. -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 3

[Range] initial feedback on return values of algorithms
by Thorsten Ottosen 19 Feb '06

19 Feb '06

Dear all, The plan is to include range-based overloads of std algorithms in the next boost.range. We have several options for specifying the return type of functions that normally return an iterator that I would like your feedback on. 1. leave the return type as it is. 2. return an iterator_range describing the range [found,end) this allows us to do stuff like namespace br = boost::ranges; br::erase( rng, br::unique(rng) ); 3. inspired by John Torjo's range lib, provide a whole list of possible return values: std::vector<int> v; namespace br = boost::ranges; br::unique(v); br::unique<br::return_found>(v); br::unique<br::return_next>(v); br::unique<br::return_prior>(v); br::unique<br::return_begin_found>(v); br::unique<br::return_begin_next>(v); br::unique<br::return_begin_prior>(v); br::unique<br::return_found_end>(v); br::unique<br::return_next_end>(v); br::unique<br::return_prior_end>(v); the default would be the range [found,end), but the you can pick different slices or simply iterators. In the above scheme, "found" is the iterator normally returnes by the algorithm, "next" means boost::next(found) and "prior" means boost::prior(found). The advantage of the latter approach is - flexibility/power - safety (we can tjeck that next(found) and prior(found) stays in range) The disadvantage is that it will require twice as many overloads in C++03 (since we can't put defaults template arguments in function templates). Any opinions? -Thorsten

5 29

[pkg-boost-devel] Boost on Debian
by Steve M. Robbins 19 Feb '06

19 Feb '06

Hello Dave, I'm responding to your message on boost mailing list http://lists.boost.org/Archives/boost/2006/02/100262.php Domenico Andreoli also contributed to this response. Apologies for the tardy response. I read the list very infrequently via web archives and I have only just noticed the message. So you ask: I am going to be trying to write some new "getting started" documentation for Boost for the upcoming release. I would really like to include some information about what people can expect when they get Boost packages from their Debian, RedHat, whatever distribution. All of our documentation so far is written from the perspective that users have a complete Boost CVS tree, but I guess that's not true for everyone? Can you fill us in? The short answer is: someone wishing to develop code using Boost under Debian need install the package libboost-dev (and, possibly, other -dev packages like libboost-filesystem-dev). The headers as well as static and shared library files are all installed into standard linux locations. Compilation and linking is done with no special options other than specifying the library; e.g. "-lboost_filesystem". Our goal is to make the Debian Boost library packages as much like standard libraries as possible. For Debian, this means that headers and link-time library files are contained in a "-dev" package. In addition, for each library that builds a shared object, we have a separate, versioned package, e.g. "libboost-filesystem1.33.1". Normally, however, one isn't concerned with the library package because the "-dev" package depends on the shared library package and installing the former automatically brings in the latter. The list of all -dev packages can be obtained by looking at what libboost-dev suggests with standard Debian tools like "aptitude" or "apt-cache". The "-dev" package contains the "release" build with both single- and multi-threaded versions, in both static and shared flavours for a total of 4 libraries. So the developer may choose to link using "-llibboost_filesystem-gcc-1_33_1" or " "-llibboost_filesystem-gcc-mt-1_33_1", shared or static. We also provide a shorthand symbolic link for the multithreaded version; you can use just "-llibboost_filesystem" (shared or static). In addition to the "-dev" packages, we have libboost-doc (documentation) bcp boost-jam boost-build (v2) Finally, there is a "libboost-dbg" package that contains the debug build of all the shared libraries, both single- and multi-threaded. Hope this is helpful, -Steve _______________________________________________ pkg-boost-devel mailing list pkg-boost-devel(a)lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-boost-devel

1 0

[serialization] exception-safety of container-serialization
by Thorsten Ottosen 19 Feb '06

19 Feb '06

Dear All, I have just added serialization to Boost.Ptr container. I briefly discussed an issue with Robert, namely that the current implementation calls clear() before reading the new values. The alternative is to provide roll-back guarantee by default by creating a local container and swap() in the end. By default this would temporarily use more memory. IMO we should go for the strong guarantee. Any thoughts? -Thorsten

5 13

Re: [boost] [serialization] exception-safety of container-serialization
by JOAQUIN LOPEZ MU?Z 18 Feb '06

18 Feb '06

----- Mensaje original ----- De: bwood <brass(a)mailvault.com> Fecha: Sábado, Febrero 18, 2006 7:42 pm Asunto: Re: [boost] [serialization] exception-safety of container-serialization > Joaquín M López Muñoz wrote: > >I would NOT go for the strong guarantee for the following > two reasons: > > > >1. Given the basic guarantee, all-or-nothing semantics can > >be implemented externally, and as efficiently as you'd do it > >internally. > >2. It might be of interest to keep a partially recovered object. > >For instance, think of the situation in which a container is > being > >marshalled thru a socket and you lose internet conectivity. > > I started to reply to this and then wondered if I understood > what you meant. Were you talking about the container as the > "partially recovered object" or an object that will be stored > by the container? The former. > The subsequent discussion I guess points to > the latter. I think the first case is interesting. If a program > sends 100 objects and another receives 99 of them no problem, > it would probably be helpful to get that information back to > the sender so the whole thing isn't repeated. Does Boost:: > serialization support this? > It does, at least for STL containers: if an error is found during the process of loading elements into a container, the container retains the elements succesfully loaded so far. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

A small utility for template policy selection
by Spencer Collyer 18 Feb '06

18 Feb '06

Whilst working on a policy-based sparse-array class (which I hope to submit to Boost at some point), I had the problem that there did not seem to be any sensible way to organise the policies such that sensible defaults could be coded in the template. Rather than always forcing the users to specify the earlier policies, even when the default would be fine, simply because they wanted to use a different policy for one of the later parameters, I came up with the following little utility. =============================================================== #include <boost/mpl/find_if.hpp> #include <boost/mpl/deref.hpp> #include <boost/type_traits/is_base_of.hpp> using namespace boost; using namespace boost::mpl; template<typename Base, typename Types, typename DefType> class PolicySelector { private: typedef typename find_if< Types, is_base_of<Base,_1> >::type pos; typedef typename end<Types>::type end_pos; public: typedef typename if_< is_same<pos, end_pos>, DefType, typename deref<pos>::type >::type type; }; =============================================================== Basically, you pass a boost::mpl sequence in the Types argument (I usually use a mpl::vector), along with the base class for the policy classes and a default class to use if none is found otherwise, and the 'type' member gives the selected policy. The only restriction it imposes is that all classes implementing a particular policy type have to inherit from a single base class. A (slightly contrived :-) ) example to show how this is used: =============================================================== #include <boost/mpl/find_if.hpp> #include <boost/mpl/deref.hpp> #include <boost/type_traits/is_base_of.hpp> #include <boost/mpl/vector.hpp> #include <boost/mpl/placeholders.hpp> #include <iostream> using namespace boost; using namespace boost::mpl; template<typename Base, typename Types, typename DefType> class PolicySelector { private: typedef typename find_if< Types, is_base_of<Base,_1> >::type pos; typedef typename end<Types>::type end_pos; public: typedef typename if_< is_same<pos, end_pos>, DefType, typename deref<pos>::type >::type type; }; class a_base { }; class a1 : public a_base { }; class a2 : public a_base { }; class a3 : public a1 { }; class b_base { }; class b1 : public b_base { }; class b2 : public b_base { }; class b3 : public b_base { }; // Select the 'A' policy. Default is a3. template<typename Types> class A_Selector { public: typedef typename PolicySelector< a_base , typename Types::type , a3>::type type; }; // Select the 'B' policy. Default is b2. template<typename Types> class B_Selector { public: typedef typename PolicySelector< b_base , typename Types::type , b2>::type type; }; // Utility class to ease building a mpl::vector. template<class p1=na, class p2=na> class sel_types { public: typedef typename vector<p1,p2>::type type; }; // Test class template. template<class Policies> class testit : public A_Selector<Policies>::type , public B_Selector<Policies>::type { public: typedef typename A_Selector<Policies>::type APolicy; typedef typename B_Selector<Policies>::type BPolicy; }; int main() { // Test policies listed in 'normal' order typedef testit<sel_types<a1, b1> > types1; typedef types1::APolicy A1; typedef types1::BPolicy B1; A1 aa1; std::cout << "Got " << typeid(aa1).name() << "\n"; std::cout << "Expected " << typeid(a1).name() << "\n"; B1 bb1; std::cout << "Got " << typeid(bb1).name() << "\n"; std::cout << "Expected " << typeid(b1).name() << "\n"; // Test missing 'B' policy - should use default typedef testit<sel_types<a2> > types2; typedef types1::APolicy A2; typedef types1::BPolicy B2; A2 aa2; std::cout << "Got " << typeid(aa2).name() << "\n"; std::cout << "Expected " << typeid(a2).name() << "\n"; B2 bb2; std::cout << "Got " << typeid(bb2).name() << "\n"; std::cout << "Expected " << typeid(b2).name() << "\n"; // Test missing 'A' policy - should use default typedef testit<sel_types<b1> > types3; typedef types1::APolicy A3; typedef types1::BPolicy B3; A3 aa3; std::cout << "Got " << typeid(aa3).name() << "\n"; std::cout << "Expected " << typeid(a3).name() << "\n"; B3 bb3; std::cout << "Got " << typeid(bb3).name() << "\n"; std::cout << "Expected " << typeid(b1).name() << "\n"; // Test policies in 'reversed' order. typedef testit<sel_types<b1, a1> > types4; typedef types1::APolicy A4; typedef types1::BPolicy B4; A4 aa4; std::cout << "Got " << typeid(aa4).name() << "\n"; std::cout << "Expected " << typeid(a1).name() << "\n"; B4 bb4; std::cout << "Got " << typeid(bb4).name() << "\n"; std::cout << "Expected " << typeid(b1).name() << "\n"; } =============================================================== As you can see, it doesn't matter which order the policies are specified in, nor whether they are specified at all. Would this utility be useful to anyone else? Is it worth my while writing up some proper documentation and submitting it for review? If so, which library would it go into? Spencer Collyer -- 12:47pm up 48 days 20:28, 21 users, load average: 0.09, 0.06, 0.13 Registered Linux User #232457 | LFS ID 11703

8 24