- Boost - lists.boost.org

Boost Build Changes break serialization jamfile and stop regression tests
by Anthony Williams 18 Jul '08

18 Jul '08

Hi, I just tried to run a batch of regression tests against trunk, and found that they failed rather quickly due to bjam aborting with the following error: error: Unable to find file or target named error: 'serialization_test//test_class_info_save_text_archive' error: referred from project at error: '.' This error causes the entire test run to fail before it's even started. It appears this was caused by revision 47536. Please could someone either revert the change or fix the failure. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

3 2

[serialization] Change between 1.33.1 & 1.35
by loic.actarus.joly＠numericable.fr 18 Jul '08

18 Jul '08

1 0

Strange commit failure on release branch.
by John Maddock 18 Jul '08

18 Jul '08

Folks, I'm trying to update the Boost.Math docs on the release branch but I get: Error: Commit failed (details follow): Error: File or directory 'html\math_toolkit\special\expint\expint_i.html' is out of Error: date; try updating Error: The version resource does not correspond to the resource within the Error: transaction. Either the requested version resource is out of date (needs to be Error: updated), or the requested version resource is newer than the transaction root Error: (restart the commit). Now the thing is I *have* made sure that the whole branch is up to date, and in any cases there are no changes to that file in SVN, so I'm stumped. Any ideas anyone? Thanks, John.

2 2

[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