July 2008 - Boost - lists.preview.boost.org

[test] Gennadiy, did you notice...?
by Daryle Walker 25 Jul '08

25 Jul '08

This is about the Boost.Test library files just uploaded to our Subversion repository, revision 47797. I like the fact that support headers are now automatically #included, but I noticed that "boost/ test/unit_test_suite.hpp" and "boost/test/test_case_template.hpp" #include each other. (The #include guards prevent infinite recursion.) You may want to fix that. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

[test] Broken header (via indirect #includes)
by Daryle Walker 25 Jul '08

25 Jul '08

I was fixing up a test file, and the compilation failed complaining that "'type' is not a member of 'boost'" within the innards of a "BOOST_AUTO_TEST_CASE_TEMPLATE" line. I figured out that the error was referring to the obscure boost::type class template in "boost/ type.hpp". I included that file, and then the compiler complained saying that "'template_test_case_gen' is not a member of 'boost::unit_test::ut_detail'." Doing a multiple-file search, I realized the true problem. 1. BOOST_AUTO_TEST_CASE_TEMPLATE is #defined in "boost/test/ unit_test_suite.hpp" 2. This template depends on boost::type and boost::unit_test::ut_detail::template_test_case_gen 3. template_test_case_gen is defined in "boost/test/ test_case_template.hpp", which happens to #include "boost/type.hpp" 4. Neither of the appropriate headers are directly #included in "unit_test_suite.hpp" 5. I guess that one or both headers were indirectly #included in "unit_test_suite.hpp", but that indirect header purged the headers I needed, and the author _forgot_ that another header was counting on the old indirect #include. I worked around the problem for now by directly #including "boost/ test/test_case_template.hpp" in my test file. But I shouldn't have to do this. Worse, this has happened before with Boost.Test, in regards to the floating point comparison tests. Those test macros called a function that wasn't in the same header, nor #included; i.e. the user has to add an extra #include for the floating-point test macros to work. The floating-point incident was a deliberate design decision, but I guess that my problem here was caused by accident. The point: DIRECTLY #include everything a macro needs in that macro's header. I'm sick & tired of hunting all the extra headers I need. Worse, I'll have to re-hunt when my test program craps out if/when the author re-arranges all the macros & headers. My point [5] is only a guess because I wasted two hours searching the trac/subversion site for where & when the author broke the build. I didn't find it, and I figured that I shouldn't have to. When you fix this, let me know so I can remove the extra #include from my test file. (Apologies in advance if the real problem is that my subversion working copy is severely fried.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 4

[test] RFC: speed up BOOST_CHECK by not formatting the check description if it isn't written anywhere
by Ji�� Pale�ek 25 Jul '08

25 Jul '08

Hello, I have a test that uses many BOOST_CHECKs (~ 10 thousands or so). Running that test is very slow and I have noticed most of the time is spent by formatting the description string to be passed to check_impl, only to be ignored, because I don't want to log successful checks (and they are successful). I have improved this by using some kind of expression template for this (called lazy_output). It works like this: lazy_output is a class that implements an expression template for "x << y << z" expressions. The expression o << a << b << c << (make_lazy_output() << x << y << z) is the same as o << a << b << c << x << y << z which is similar to o << a << b << c << (wrap_stringstream().ref() << x << y << z).ref() The difference is that, in the call f(make_lazy_output() << x << y << z), the data is formatted only if f outputs them to an ostream. This reduced the time needed for running my test from ~12 minutes to ~7 minutes. There is more room for similar (but more complicated) improvements. Any comments or suggestions? Regards Jiri Palecek

3 5

Re: [boost] [Boost-testing] Patch for sigaltstack failure on Leopard with XCode 3.0
by Juergen Hunold 25 Jul '08

25 Jul '08

HI Jeroen ! On Sunday 13 July 2008 17:33:04 Jeroen van der Wulp wrote: > Hello everyone, > The cause seems to be that the implementation of sigaltstack() on > Leopard requires the ss_size of a stack_t structure to be MINSIGSTKSZ at > least. > > The attached patch accomplishes just this. Well, it actually sets the size to BOOST_TEST_ALT_STACK_SIZE. But this should be big enough, shouldn't it ? ;-)) I'm CC'ing Gennadyi and the Boost devel list in case he missed this. I'll take a look at the current regressions for trunk and commit this patch tomorrow evening (CEST) if no one is faster ;-)) Merging Boost.Test to release is another business :-(( Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

[Test] [gcc] more checking for Test tests
by Juergen Hunold 25 Jul '08

25 Jul '08

Hi ! I've just fixed some "-pedantic" warnings from gcc. http://svn.boost.org/trac/boost/changeset/47423 I'd like to raise the warning level for gcc when running the Boost.Test testsuite by always adding "-pedantic". Unfortunately, this will issue errors due to gcc's own stdlib (at least for gcc < 4.2) because of the unprotected use of "long long" from the C99 standard. Thanks to Steven Watanabe for pointing this out. I've had to add "-Wno-long-long" to disable those warnings again. Please find a patch including an explanatory comment attached. Comments ? Wait until 1.36 is out ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

generict container for structure of arrays
by Bradford, Chase 24 Jul '08

24 Jul '08

Over the past few months, I've worked on a generalized structure-of-arrays for use in various scientific applications, and wanted to know if any Boostees had an interest in that sort of container. The library's main goals are 1) Optimized storage by allowing dynamic addition/removal of fields. 2) General performance help (cache coherency, vector processing, etc.) 3) Enabling the use of many types in a single SOA. 4) Provide an interface similar other STL containers 5) Type safety (of course) The library is similar to a tuple of vectors, except all vectors are forced to have the same size, and the members of the tuple aren't fixed. Internally, the data is stored as vectors for each field, but there's also an interface for getting a slice of the data. Chase Bradford

6 10

[phoenix] Using Phoenix V2.0
by Robert Jones 24 Jul '08

24 Jul '08

I'm struggling a little to navigate my way through the Boost svn repository for the correct Phoenix V2.0 files. There seem to be many deprecated locations and shell wrappers. Eg. boost/spirit/phoenix/operators.hpp states it is deprected in favour of boost/spirit/include/phoenix1_operators.hpp which simply #includes boost/home/classic/phoenix/operators.hpp which seems to be the real thing. Which, if any, of these is likely to emerge as the 'correct' long term home for these files? Thanks, Rob. -- ACCU - Professionalism in programming - http://www.accu.org

3 5

[graph] Max Flow Uninitialized Warning in adjacency_list.hpp
by Lex Fridman 24 Jul '08

24 Jul '08

When I try to compile the Edmunds Karp Max Flow example (or any of the other max-flow examples) I get a set of warnings as to m_source or m_target being used uninitialized in adjacency_list.hpp. I'm using gcc 4.2.3. Is there a way to get rid of this warning? Code example: http://www.nabble.com/file/p18596627/main.cpp main.cpp Warning example (this is all one line): /usr/include/boost/graph/detail/adjacency_list.hpp: In function ‘int boost::read_dimacs_max_flow(Graph&, CapacityMap, ReverseEdgeMap, typename boost::graph_traits<G>::vertex_descriptor&, typename boost::graph_traits<G>::vertex_descriptor&, std::istream&) [with Graph = main()::Graph, CapacityMap = boost::adj_list_edge_property_map<boost::directed_tag, long int, long int&, unsigned int, boost::property<boost::edge_capacity_t, long int, boost::property<boost::edge_residual_capacity_t, long int, boost::property<boost::edge_reverse_t, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>, boost::no_property> > >, boost::edge_capacity_t>, ReverseEdgeMap = boost::adj_list_edge_property_map<boost::directed_tag, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>&, unsigned int, boost::property<boost::edge_capacity_t, long int, boost::property<boost::edge_residual_capacity_t, long int, boost::property<boost::edge_reverse_t, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>, boost::no_property> > >, boost::edge_reverse_t>]’: /usr/include/boost/graph/detail/adjacency_list.hpp:270: warning: ‘p.boost::property<boost::edge_capacity_t, long int, boost::property<boost::edge_residual_capacity_t, long int, boost::property<boost::edge_reverse_t, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>, boost::no_property> > >::<anonymous>.boost::property<boost::edge_residual_capacity_t, long int, boost::property<boost::edge_reverse_t, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>, boost::no_property> >::<anonymous>.boost::property<boost::edge_reverse_t, boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>, boost::no_property>::m_value.boost::detail::edge_desc_impl<boost::directed_tag, unsigned int>::<anonymous>.boost::detail::edge_base<boost::directed_tag, unsigned int>::m_target’ is used uninitialized in this function -- View this message in context: http://www.nabble.com/-graph--Max-Flow-Uninitialized-Warning-in-adjacency_l… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

[release] nightly generated docs?
by Eric Niebler 24 Jul '08

24 Jul '08

Once upon a time, Boost's docs were built nightly and publicly hosted. Have we fallen out of that practice? Beman, have you tried building the documentation for the release yet? It'd be nice to get a regular build going again so we can work any kinks out of the system. Any volunteers? -- Eric Niebler BoostPro Computing http://www.boostpro.com

5 15

[1.36] release blurb?
by JOAQUIN M. LOPEZ MUÑOZ 24 Jul '08

24 Jul '08

Hi, I wonder whether we already have some place to begin adding content to the 1.36 release notes--you know, listing the new libraries and significant updates. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 10