- Boost - lists.boost.org

[1.36.0] Libraries with unmerged changes?
by Beman Dawes 18 Jul '08

18 Jul '08

Below is a list of libraries whose header files appear to differ between the trunk and branches/release. The most likely causes are: * Changes that should be merged into branches/release for 1.36.0. If that is the case, developers need to merge those changes right away! * Work in process that should *not* be merged into branches/release for 1.36.0. Please let me know that that is the case so I can stop worrying:-) * Issues with the newly minted script used to generate the report. Please let me know so the script can be improved. Thanks, --Beman archive asio bimap circular_buffer compatibility config date_time detail dynamic_bitset exception filesystem format function function_types fusion gil graph intrusive io iostreams iterator math mpi mpl numeric optional parameter pending pool program_options property_tree python random regex serialization signals spirit statechart system test thread tr1 type_traits units utility

23 94

[test] BOOST_TEST_MAIN,BOOST_AUTO_TEST_CASE and MFC
by Robert Caldecott 18 Jul '08

18 Jul '08

I use the Boost Test library extensively, and to save time, I always define BOOST_TEST_MAIN and add tests using BOOST_AUTO_TEST_CASE. This works fine for most projects, but now I need to test some MFC code. In order for MFC objects to work correctly, I need to make a call to AfxWinInit, but the only way I can see to do this is to define my own init_unit_test_suite function and add tests 'by hand', rather than using BOOST_AUTO_TEST_CASE. Does anyone know of a way I can avoid adding tests by hand? Does the Boost auto main stuff make a call to any init function I can override, so I can squeeze in an MFC init call? Thanks in advance.

2 2

[bind] function_equal with binds holding weak_ptr values
by Sylvester-Bradley, Gareth 18 Jul '08

18 Jul '08

(Apologies for not posting my previous question in plain-text.) Bind can be used with weak_ptr values, but should function_equal work with binds holding weak_ptrs? Since weak_ptr doesn't have operator==, the following results in a compiler error: #include <boost/function_equal.hpp> #include <boost/bind.hpp> #include <boost/weak_ptr.hpp> int h( boost::weak_ptr<void> wp ) { return wp.use_count(); } template < typename F > bool self_equal( F f_ ) { return function_equal( f_, f_ ); } int main( int argc, char * const argv[] ) { self_equal( boost::bind( h, _1 ) ); // OK self_equal( boost::bind( h, boost::weak_ptr<void>() ) ); // compiler error return 0; } Would it be appropriate to use operator< equivalence? I suspect the answer may be "it depends...", but I made the above compile by adding the following: namespace boost { namespace _bi { template<class T> class value< weak_ptr<T> > { public: value(weak_ptr<T> const & t): t_(t) {} weak_ptr<T> & get() { return t_; } weak_ptr<T> const & get() const { return t_; } bool operator==(value const & rhs) const { return !(t_ < rhs.t_) && !(rhs.t_ < t_); } private: weak_ptr<T> t_; }; } } Is that a good or bad idea? Thanks, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards

2 2

[bind] function_equal with nested binds
by Sylvester-Bradley, Gareth 18 Jul '08

18 Jul '08

Should function_equal work with nested binds? I expected the following to work but it results in a compiler error: #include <boost/function_equal.hpp> #include <boost/bind.hpp> void f( int ) {} int g( int i ) { return i+5; } template < typename F > bool self_equal( F f_ ) { return function_equal( f_, f_ ); } int main( int argc, char * const argv[] ) { self_equal( boost::bind( f, _1 ) ); // OK self_equal( boost::bind( g, _1 ) ); // OK self_equal( boost::bind( f, boost::bind( g, _1 ) ) ); // compiler error } I made it compile by adding the following: namespace boost { namespace _bi { template<class R, class F, class L> bool ref_compare( bind_t<R,F,L> const & a, bind_t<R,F,L> const & b, long ) { return a.compare(b); } } } Is that OK? Thanks, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards

2 2

[flyweight][parameter] is there an interest in this template parameter expresion
by vicente.botet 18 Jul '08

18 Jul '08

Hello, I'm doing a Locally Unique Identifier generator library. The DSL grammar is quite complex, so the use of optional class parameters seams unavoidable. I have started to use the Boost.Parameter Library as the Boost.Flyweight does. The flyweight class that takes 5 optional parameters and is currently declared as follows <code> template< typename T, typename Arg1,typename Arg2,typename Arg3,typename Arg4,typename Arg5 > class flyweight { private: typedef parameter::parameters< parameter::optional< parameter::deduced<tag<> >, detail::is_tag<boost::mpl::_> >, parameter::optional< parameter::deduced<tracking<> >, is_tracking<boost::mpl::_> >, parameter::optional< parameter::deduced<factory<> >, is_factory<boost::mpl::_> >, parameter::optional< parameter::deduced<locking<> >, is_locking<boost::mpl::_> >, parameter::optional< parameter::deduced<holder<> >, is_holder<boost::mpl::_> > > signature; typedef typename signature::bind< Arg1,Arg2,Arg3,Arg4,Arg5 >::type args; typedef typename parameter::binding< args,tag<>,mpl::na >::type tag_type; typedef typename parameter::binding< args,tracking<>,refcounted >::type tracking_policy; typedef typename parameter::binding< args,factory<>,hashed_factory<> >::type factory_specifier; typedef typename parameter::binding< args,locking<>,simple_locking >::type locking_policy; typedef typename parameter::binding< args,holder<>,static_holder >::type holder_specifier; typedef parameter::parameters< parameter::optional< parameter::deduced< detail::unmatched_arg >, mpl::not_< mpl::or_< detail::is_tag<boost::mpl::_>, is_tracking<boost::mpl::_>, is_factory<boost::mpl::_>, is_locking<boost::mpl::_>, is_holder<boost::mpl::_> > > > > unmatched_signature; typedef typename unmatched_signature::bind< Arg1,Arg2,Arg3,Arg4,Arg5 >::type unmatched_args; typedef typename parameter::binding< unmatched_args,detail::unmatched_arg, detail::unmatched_arg >::type unmatched_arg_detected; BOOST_STATIC_ASSERT(( /* You have passed a type in the specification of a flyweight type that * could not be interpreted as a valid argument. */ is_same<unmatched_arg_detected,detail::unmatched_arg>::value)); ... </code> I have made abstraction of the common structure of this code resulting on a 'expr' class. The boost::dsl::expr class has three parameters: * a tag for the expression * a vector of parameters specification, each one been either mandatory or optional, and containing a tag, a predicate stating if a parameter corresponds to the tag, and a default value for the optionals * a vector of the current parameters The parameter associated to a given tag can be obtained using the get template function. For example to get the tracking parameter we can use: typename base_type::template get<tracking<> >::type All the implementation details are encapsulated on the expre class. The flyweight class can then be rewriten as: <code> #define BOOST_FLYWEIGHT_BASE dsl::expr<flyweight<T>, mpl::vector< \ dsl::optional<tag<>, detail::is_tag<mpl::_>, mpl::na >, \ dsl::optional<tracking<>, is_tracking<mpl::_>, refcounted >, \ dsl::optional<factory<>, is_factory<mpl::_>, hashed_factory<> >, \ dsl::optional<locking<>, is_locking<mpl::_>, simple_locking >, \ dsl::optional<holder<>, is_holder<mpl::_>, static_holder > \ >, \ mpl::vector<Arg1,Arg2,Arg3,Arg4,Arg5> > template< typename T, typename Arg1,typename Arg2,typename Arg3,typename Arg4,typename Arg5 > class flyweight : public BOOST_FLYWEIGHT_BASE { typedef BOOST_FLYWEIGHT_BASE base_type; #undef BOOST_FLYWEIGHT_BASE typedef typename base_type::template get< tag<> >::type tag_type; typedef typename base_type::template get< tracking<> >::type tracking_policy; typedef typename base_type::template get< factory<> >::type factory_specifier; typedef typename base_type::template get< locking<> >::type locking_policy; typedef typename base_type::template get< holder<> >::type holder_specifier; // ... }; </code> BOOST_FLYWEIGHT_BASE is used to avoid repeating the long template expression I would like to know if there is an interest in such a class, and if it could be added to the parameters library? Of course, any improvements are welcome. The expr.hpp and expr_pp.hpp files are attached. The class is able to manage with a variable number of parameters (BOOST_DSL_EXPR_ARITY) when BOOST_DSL_EXPR_PP is defined or up to 3 otherwise. Best Regards Vicente Juan Botet Escriba P.S. The variadic template code is not correct.

4 7

[ptr_container] Two release branch tests failing on all platforms
by Beman Dawes 18 Jul '08

18 Jul '08

See http://beta.boost.org/development/tests/release/developer/ptr_container.html These tests aren't failing on trunk, yet it doesn't look like there are any unmerged changes pending. Presumably that means some dependency has unmerged changes. We need to clear these failures ASAP. Thanks, --Beman

1 1

[functional/hash] Failing link_ext_test on Windows both trunk and release
by Beman Dawes 18 Jul '08

18 Jul '08

link_ext_test has a link failure on Windows both trunk and release. See http://beta.boost.org/development/tests/release/developer/functional-hash.h… We need to clear this ASAP. --Beman PS: The error is an unresolved external to "test_main" in Boost.Test, so this may be a Jamfile problem rather than a problem with the library's actual code.

2 1

Re: [boost] Is our subversion server/archive 1.5 yet?
by Douglas Gregor 18 Jul '08

18 Jul '08

On Sun, 2008-06-29 at 16:12 -0400, Daryle Walker wrote: > Last week, a was bouncing around sites and found out that Subversion > 1.5.0 has gone final. I've downloaded it because I want to try its > built-in merging support (to fix up Boost.Integer in a branch). Has > our subversion system been updated to 1.5? No, we're still using Subversion 1.4 on the server. > Obviously, if the client and server use subversion versions 1.x and > 1.y respectively, the transactions will proceed as the lower of those > versions. Therefore, both individual clients and the server must be > at least the 1.5 level to use built-in merging. There's another > requirement, though: if the server is upgraded to 1.5, the > repositories it manages aren't automatically upgraded. If a > repository isn't upgraded to the 1.5 format, then the server will act > in 1.4-compatibility mode as needed. > > Is there a schedule for these upgrades to be done (if not done > already)? Is it possible to tell from the client side which mode a > server/repository uses? I actually don't know how to tell from the client-side which version of Subversion the server is running. As for the upgrade... we're looking into Subversion 1.5, but it appears to be a nontrivial process to perform the upgrade and migrate svnmerge.py merge information appropriately, so we need to read more, do some test runs, check that other projects haven't run into serious problems, etc. So much depends on the Subversion repository that we need to be careful. When we're ready to move, we'll send out an e-mail to the mailing list. - Doug

6 8

[fusion] pair documentation issues
by Steven Watanabe 17 Jul '08

17 Jul '08

AMDG The documentation of fusion::pair has a number of problems http://www.boost.org/doc/libs/1_35_0/libs/fusion/doc/html/fusion/support/pa… template <typename First, typename Second> struct first; Should be template<class Pair> struct first; Similarly for second. Also, there is a missing ` in the expression semantics table, which looks horrible as a result. In Christ, Steven Watanabe

2 1

[system] documentation bug, error_code::value_type
by Arvid Norberg 17 Jul '08

17 Jul '08

The boost.system documentation mentions a value_type typedef in boost::system::error_code several times in: http://www.boost.org/doc/libs/1_35_0/libs/system/doc/reference.html#Class-e… In ther header file there is no such typedef, just an int is used. I've filed a ticket here: http://svn.boost.org/trac/boost/ticket/2125 -- Arvid Norberg

1 0