- Boost - lists.boost.org

Workaround for clang-linux + GNU stdlib + Boost.Iostreams
by Bryce Lelbach 09 Jan '11

09 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There's a discrepancy in the definition of wint_t between GCC and some later versions of clang (clang defines it as an int, GCC an unsigned int). This ends breaking Boost.Iostreams with a GNU GCC compiled version of the GNU stdlib and clang (I'll restrain myself from giving the lengthy technical explaination - if you have link-time errors with clang + GCC compiled stdlib + Boost.Iostreams, this is probably the issue). Unfortunately, I cannot patch this issue with a workaround in Boost easily. The right combination of clang flags can work around this by not using the clang intrinsic/builtin headers, but this has a good chance of causing other problems. The simplest solution here is to rebuild clang (building the GNU stdlib with clang is tricky at best). I think newer version of the mainstream clang trunk may have fixed this, but if not, you need to change the assignment to WIntType in the clang::TargetInfo ctor ($CLANG_ROOT/lib/Basic/TargetInfo.cpp, line 40-50ish). It should be UnsignedInt. You also need to hack $CLANG_ROOT/lib/Headers/stdint.h, around 630 - the macro definition of WINT_MIN and WINT_MAX need to be changed to: #define WINT_MIN 0u #define WINT_MAX __UINTN_MAX(__WINT_WIDTH__) If you'd rather not recompile clang, you can try hacking your clang intrinsic headers (not advisable, might break more stuff). Find the resource/intrinsic header directory (usually something like /usr/local/clang/2.9/include/), and make the change specified above to the stdint.h header there. In the stddef.h header, around like 60, you can change the wint_t typedef. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk0fnjQACgkQO/fqqIuE2t7NVQCgowl7TqnCRgWyjRGN+/u3fh2R NywAoK59zWsZiB7vVvtKU0IehHiMIVdz =COrS -----END PGP SIGNATURE-----

4 5

[wiki] Warning Guidelines for VC
by Michael Caisse 08 Jan '11

08 Jan '11

A question just came up on IRC concerning the use of the /Za ("disable language extensions") and it not working. While searching for a previous post from STL on the subject [1] Google offered this link: <https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines> STL's (Stephan Lavavej's) advice on the subject was to *not* use /Za because it has "an extremely nasty bug". Unfortunately our guidelines suggest it should be used. I began to edit the wiki page but considering the amount of text and an example on the subject I thought it might be best to ask permission first. Should I edit the page to be in-line with STL's suggestion or just leave it as-is? [1] <http://lists.boost.org/Archives/boost/2010/04/165531.php > michael -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

5 13

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