- Boost - lists.boost.org

[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

[feature freeze] range issue
by Thorsten Ottosen 18 Feb '06

18 Feb '06

Thomas, Do you have anything to add to the discussion on committing the new version of boost.range? -Thorsten

6 14

[Assign] list_of comma operator removed?
by Jon Willesen 18 Feb '06

18 Feb '06

I recently attempted to upgrade from boost 1.32.0 to boost 1.33.1 got received some compiler errors from boost.assign. My most common usage of boost::assign looks like this: vector<string> data = (list_of<string>(), "foo", "bar", "baz"); I like this better than the alternative syntax (elements delimeted by parentheses) because I can type it more quickly and it more closely resembles array initialization syntax, which makes it more likely that my coworkers, who aren't as familiar with boost, will understand what's going on. But it appears my compiler errors were caused by the removal of the comma operator in the class the list_of function returns. It appears this was intentional since the unit tests were changed, but the current documentation for list_of still indicates the comma operator is legal syntax, and operator+= still uses the comma syntax, so I'm a little confused. I remember there was some discussion on this list earlier about the comma operator and whether it is ever ok to overload it, but I couldn't find anything about actually removing it from any aspect of boost.assign in the mailing list, the documentation, or the version history. Maybe I haven't looked deeply enough yet? Was the comma operator intentionally removed from list_of? If so, I would like to understand why so I can be properly dissuaded from reintroducing it for my own use. Thanks, -- Jon Willesen

2 10

Re: [boost] [serialization] exception-safety of container-serialization
by bwood 18 Feb '06

18 Feb '06

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 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? Brian

1 0