January 2011 - Boost - lists.preview.boost.org

Boost.Bind and boost.ref propagation
by Felipe Magno de Almeida 07 Jan '11

07 Jan '11

Hi, Why this code asserts? struct foo { typedef void result_type; template <typename T> void operator()(T obj) const { BOOST_MPL_ASSERT ((boost::mpl::or_ < typename boost::mpl::not_ < typename boost::is_same<typename boost::unwrap_reference<T>::type, T>::type >::type , typename boost::is_reference<T>::type >)); } }; int main() { int i = 0; boost::bind(::foo(), boost::ref(i))(); } I would expect the T type to be boost::reference_wrapper<int>, but it is actually int. It is not int& as well. How do I get to propagate the boost::reference_wrapper through boost.bind to a template? I don't want to use T& for the parameter, because the algorithm accepts objects-by-value correctly, but I would like to be able to use boost.bind as I would call this algorithm with boost.ref for some data-types. foo()(boost::ref(i)); // Calls with boost::reference_wrapper<int> Thanks in advance, -- Felipe Magno de Almeida

2 1

serialization linking issue - mac os x 10.6 + boost 1.45
by John Clayton 07 Jan '11

07 Jan '11

Hi i've got a new problem with my code, now that I'm compiling and linking against the 1.45 boost libraries. When I compile and link, I now get these errors at the link stage: "boost::serialization::version<Model::KeyValue<QPointF> >::value", referenced from: __ZN5boost13serialization7versionIN5Model8KeyValueI7QPointFEEE5valueE$non_lazy_ptr in libDataModel.a(Project.o) __ZN5boost13serialization7versionIN5Model8KeyValueI7QPointFEEE5valueE$non_lazy_ptr in libRendering.a(EditorDocument.o) __ZN5boost13serialization7versionIN5Model8KeyValueI7QPointFEEE5valueE$non_lazy_ptr in libDataModel.a(Serialization.o) (maybe you meant: __ZN5boost13serialization7versionIN5Model8KeyValueI7QPointFEEE5valueE$non_lazy_ptr) I have version definitions for the template types using boost serialization, along the form of: namespace boost { namespace serialization { template<typename T, int scale, int defaultCurveType> struct version< Model::PropertyArrayT<T, scale, defaultCurveType> > { typedef mpl::int_<1> type; typedef mpl::integral_c_tag tag; BOOST_STATIC_CONSTANT(unsigned int, value = version::type::value); }; template<typename T> struct version< Model::KeyValue<T> > { typedef mpl::int_<1> type; typedef mpl::integral_c_tag tag; BOOST_STATIC_CONSTANT(unsigned int, value = version::type::value); }; } } I tried instantiating (in the .cpp of the header where this stuff is declared), like this: boost::serialization::version< Model::KeyValue<QPointF> > a; but the link error for this type still persists. The code is compiled into a library, and then the link step fails on the application. I hope its not the linker being extra ingenious and throwing this fake definition away. Can anyone see what I'm doing wrong? The code works OK if I use/link against boost 1.42. Thanks -- John Clayton Skype: johncclayton

1 0

Re: [boost] Are memory leaks reported by Boost.Test Microsoft Memory Leak Detection Enabling spurious or real?
by Thomas Harning Jr. 07 Jan '11

07 Jan '11

Regarding this problem, I've found more details about it on the Visual Studio Connect website: http://connect.microsoft.com/VisualStudio/feedback/details/106937/memory-le… typeinfo is used by the unit test framework if you use BOOST_AUTO_TEST_CASE_TEMPLATE. Few fixes that seem reasonable: All use the following tools: _CrtMemCheckpoint [1] and _CrtMemDumpAllObjectsSince [2] available since VS2003 to report objects in specific regions Few reasonable cases: * For the entire test path, if dumping enabled, checkpoint before all tests start, dump after all tests complete * For each test suite, checkpoint before suite starts, dump after suite ends (complicated by nested suites...) * For each test case, checkpoint before test starts, dump after test ends 1: http://msdn.microsoft.com/en-us/library/h3z85t43(v=vs.90).aspx 2: http://msdn.microsoft.com/en-us/library/hhy09244(v=vs.90).aspx -- Thomas Harning Jr.

5 5

Re: [boost] [BGL] problem w/ push_relabel_max_flow and floating point capacities
by Marc Schafer 07 Jan '11

07 Jan '11

Jeremiah, I am looking at a particular case in the debugger and I see that is_flow returns false because of comparisons that fail by an error that is many orders of magnitude smaller than the numbers being compared. For example, x==y fails because x and y are both approximately 1. and x-y is 1.e-14. I could replace the particular comparisons that are failing for my test case, but I need to know how to make the entire algorithm generically suitable for use with floating point numbers. is_flow just performs a consistency check after the calculation is complete. Does the calculation itself require any modifications to work correctly with floating point numbers? What are the appropriate tolerances to use? Do the relational tests (<, >) also need modification to properly handle floating point? -Marc "Jeremiah Willcock" <jewillco(a)osl.iu.edu> wrote in message news:<alpine.LRH.2.00.1101051355460.26649(a)flowerpot.osl.iu.edu>... > On Wed, 22 Dec 2010, Marc Schafer wrote: > > > Using the push_relabel_max_flow feature on graphs that have edge > > capacities in double or single precision often results in a failed > > assertion (line 706 push_relabel_max_flow.hpp) on debug builds although > > the answer provided is correct for builds with assertions disabled. > > > > The is_flow() method (line 564, push_relabel_max_flow.hpp) performs some > > consistency checking after the algorithm completes and there is an > > assertion that it returns true. The comparisons inside is_flow are done > > using ==, !=, >, and <. Using a locally modified version, I was able to > > see that all the cases where is_flow returns false are caused by errors > > on the order of machine precision. > > > > I believe the error is a faulty comparison mechanism inside is_flow > > rather than a problem with my graphs or the push_relabel_max_flow > > algorithm. > > I agree with what you are saying. If you just replace the == and != > operations in is_flow (and not < and >), does the code work correctly? > Boost already has floating point equality comparisons with a tolerance, > but does not appear to have inequalities. > > -- Jeremiah Willcock > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

Re: [boost] [BGL] problem w/ push_relabel_max_flow and floating point capacities
by Marc Schafer 07 Jan '11

07 Jan '11

Apologies for the double post. Outlook crashed while I was typing the first one and I didn't think it got sent. -Marc "Marc Schafer" <Marc.Schafer(a)mathworks.com> wrote in message news:<AA067D07858B794CA4E1612284A7E8DAFFF4(a)exmb-01-ah.ad.mathworks.com>... > Jeremiah, > For my test case, is_flow fails on a comparison x==y where x and y are both approximately 1. and x-y is 1.e-14. > > However, the graphs I want to process could have capacities that are any valid floating point numbers. This leads to several questions: > > is_flow is a consistency check after the algorithm is complete, does the algorithm need modifications to work correctly with floating point numbers? > > How do I determine the correct tolerances to use for comparisons? > > How do I deal with the relational operators (<, >)? > > -Marc > > "Jeremiah Willcock" <jewillco(a)osl.iu.edu> wrote in message news:<alpine.LRH.2.00.1101051355460.26649(a)flowerpot.osl.iu.edu>... > > On Wed, 22 Dec 2010, Marc Schafer wrote: > > > > > Using the push_relabel_max_flow feature on graphs that have edge > > > capacities in double or single precision often results in a failed > > > assertion (line 706 push_relabel_max_flow.hpp) on debug builds although > > > the answer provided is correct for builds with assertions disabled. > > > > > > The is_flow() method (line 564, push_relabel_max_flow.hpp) performs some > > > consistency checking after the algorithm completes and there is an > > > assertion that it returns true. The comparisons inside is_flow are done > > > using ==, !=, >, and <. Using a locally modified version, I was able to > > > see that all the cases where is_flow returns false are caused by errors > > > on the order of machine precision. > > > > > > I believe the error is a faulty comparison mechanism inside is_flow > > > rather than a problem with my graphs or the push_relabel_max_flow > > > algorithm. > > > > I agree with what you are saying. If you just replace the == and != > > operations in is_flow (and not < and >), does the code work correctly? > > Boost already has floating point equality comparisons with a tolerance, > > but does not appear to have inequalities. > > > > -- Jeremiah Willcock > > _______________________________________________ > > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Re: [boost] [BGL] problem w/ push_relabel_max_flow and floating point capacities
by Marc Schafer 07 Jan '11

07 Jan '11

Jeremiah, For my test case, is_flow fails on a comparison x==y where x and y are both approximately 1. and x-y is 1.e-14. However, the graphs I want to process could have capacities that are any valid floating point numbers. This leads to several questions: is_flow is a consistency check after the algorithm is complete, does the algorithm need modifications to work correctly with floating point numbers? How do I determine the correct tolerances to use for comparisons? How do I deal with the relational operators (<, >)? -Marc "Jeremiah Willcock" <jewillco(a)osl.iu.edu> wrote in message news:<alpine.LRH.2.00.1101051355460.26649(a)flowerpot.osl.iu.edu>... > On Wed, 22 Dec 2010, Marc Schafer wrote: > > > Using the push_relabel_max_flow feature on graphs that have edge > > capacities in double or single precision often results in a failed > > assertion (line 706 push_relabel_max_flow.hpp) on debug builds although > > the answer provided is correct for builds with assertions disabled. > > > > The is_flow() method (line 564, push_relabel_max_flow.hpp) performs some > > consistency checking after the algorithm completes and there is an > > assertion that it returns true. The comparisons inside is_flow are done > > using ==, !=, >, and <. Using a locally modified version, I was able to > > see that all the cases where is_flow returns false are caused by errors > > on the order of machine precision. > > > > I believe the error is a faulty comparison mechanism inside is_flow > > rather than a problem with my graphs or the push_relabel_max_flow > > algorithm. > > I agree with what you are saying. If you just replace the == and != > operations in is_flow (and not < and >), does the code work correctly? > Boost already has floating point equality comparisons with a tolerance, > but does not appear to have inequalities. > > -- Jeremiah Willcock > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Re: [boost] [Boost-commit] svn:boost r67745 - trunk/boost/fusion/container/list/detail
by Steven Watanabe 07 Jan '11

07 Jan '11

AMDG On 1/6/2011 5:17 PM, marshall(a)idio.com wrote: > Author: marshall > Date: 2011-01-06 20:17:40 EST (Thu, 06 Jan 2011) > New Revision: 67745 > URL: http://svn.boost.org/trac/boost/changeset/67745 > > Log: > Applied patch; refs #2823; will merge to release once tests cycle > Text files modified: > trunk/boost/fusion/container/list/detail/build_cons.hpp | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > Modified: trunk/boost/fusion/container/list/detail/build_cons.hpp > ============================================================================== > --- trunk/boost/fusion/container/list/detail/build_cons.hpp (original) > +++ trunk/boost/fusion/container/list/detail/build_cons.hpp 2011-01-06 20:17:40 EST (Thu, 06 Jan 2011) > @@ -48,7 +48,8 @@ > static type > call(First const& f, Last const& l) > { > - return type(*f, next_build_cons::call(fusion::next(f), l)); > + typename result_of::value_of<First>::type v = *f; > + return type(v, next_build_cons::call(fusion::next(f), l)); > } > }; result_of::deref would be better. There's no reason to make an extra copy. (Although this code looks pretty copy-happy to begin with). In Christ, Steven Watanabe

1 0

[chrono] isuue with accuracy test on some platforms
by vicente.botet 06 Jan '11

06 Jan '11

Hi, I'm observing some errors in Boost.Chrono related to this accuracy test whcih fails if the elapsed time is over 200ms (see http://svn.boost.org/svn/boost/trunk/libs/chrono/example/chrono_accuracy_te… ). The results are showed below. I'm tempted to remove the check on the unit tests as there is nothing working wrong with the library but with the platform. This user can run this test and see the output to have an idea of the accuracy of the std::clock function on her platform. Comments? Best, Vicente ________________________________________ accuracy test for 1 second(s)... 1000000000 timeout_in_nanoseconds 200000000 maximum_delta 1811871936 sys_dur ../libs/chrono/test/../example/chrono_accuracy_test.cpp(74): test 'sys_dur > timeout_in_nanoseconds - maximum_delta && sys_dur < timeout_in_nanoseconds + maximum_delta' failed in function 'void<unnamed>::accuracy_test(int, char**)' 1811868977 mono_dur ../libs/chrono/test/../example/chrono_accuracy_test.cpp(80): test 'mono_dur > timeout_in_nanoseconds - maximum_delta && mono_dur < timeout_in_nanoseconds + maximum_delta' failed in function 'void<unnamed>::accuracy_test(int, char**)' 1811868554 hires_dur ../libs/chrono/test/../example/chrono_accuracy_test.cpp(86): test 'hires_dur > timeout_in_nanoseconds - maximum_delta && hires_dur < timeout_in_nanoseconds + maximum_delta' failed in function 'void<unnamed>::accuracy_test(int, char**)' 3 errors detected. Or accuracy test for 1 second(s)... 1000000000 timeout_in_nanoseconds 200000000 maximum_delta 1536756457 sys_dur ../libs/chrono/test/../example/chrono_accuracy_test.cpp(74): test 'sys_dur > timeout_in_nanoseconds - maximum_delta && sys_dur < timeout_in_nanoseconds + maximum_delta' failed in function 'void<unnamed>::accuracy_test(int, char**)' 1536855050 mono_dur ../libs/chrono/test/../example/chrono_accuracy_test.cpp(80): test 'mono_dur > timeout_in_nanoseconds - maximum_delta && mono_dur < timeout_in_nanoseconds + maximum_delta' failed in function 'void<unnamed>::accuracy_test(int, char**)' 1536855104 hires_dur ../libs/chrono/test/../example/chrono_accuracy_test.cpp(86): test 'hires_dur > timeout_in_nanoseconds - maximum_delta && hires_dur < timeout_in_nanoseconds + maximum_delta' failed in function 'void<unnamed>::accuracy_test(int, char**)' 3 errors detected.

1 0

[system][chrono] header-only libs
by vicente.botet 06 Jan '11

06 Jan '11

Hi, after discussion with Ion about whether Boost.Interprocess could use Boost.Chrono and Boost.System he has found as major drawback that both are not header-only libs. I have implemented Boost.Chrono as a header only lib. If the user wants Boost.Chrono be a header-only lib s/he needs to define the BOOST_CHRONO_INLINED macro. While this could be useful, there is a problem as Boost.Chrono depends on Boost.System that is not a header-only lib. * I have added this on the configuration file #ifdef BOOST_CHRONO_INLINED #define BOOST_CHRONO_INLINE inline #define BOOST_CHRONO_DECL #else #define BOOST_CHRONO_INLINE // as before #endif * Copied all the .cpp files to the detail/inlined directory. * Renamed the .cpp file by .hpp files * Included in the old .cpp files the corresponding .hpp file in the detail/inlined directory * I've replaced the prefix suffix as follows: #ifndef BOOST_CHRONO_INLINED #include <boost/config/abi_prefix.hpp> // must be the last #include #endif #ifndef BOOST_CHRONO_INLINED #include <boost/config/abi_suffix.hpp> // pops abi_prefix.hpp pragmas #else #include <boost/chrono/detail/inlined/file_name.hpp> #endif * prefixed the definitions of the function in the .cpp files by BOOST_CHRONO_INLINE While doing this I have found a minor issue on Windows platform. I hve nedeed to sorrounded by () all the use of min and max functions on the test files to avoid the macros defined on the windows.h file. That means that a header-only lib could break user sources as it will include implicitly some platform files. Another drawback that I have no inspected yet could be the increase in size and compilation time of the user code. Beman do you mind if I try to make your library configurable as header-only, so Ion could use Boost.System and Boost.Chrono and preserve Boost.Interprocess as a header-only lib? Best, Vicente P.S. You can see the sandbox for the last modifications _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

8 23

library_status.cpp
by Bryce Lelbach 06 Jan '11

06 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 library_status.cpp (cd $BOOST_ROOT/tools/regression/build && bjam library_status toolset=gcc) does not build for me. I don't know how long this has been broken for, but who is the maintainer of this software? - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk0lOrQACgkQ9cB/V3/s9Ez94wCgpSQpaWDHsBFm1S1uvdRKrSG9 fwAAoKlJWaEaAuEKZwvZMCIwC5C//tOO =5BVP -----END PGP SIGNATURE-----

3 2