August 2009 - Boost - lists.preview.boost.org

Timing.
by Edward Grace 03 Aug '09

03 Aug '09

Hello All, Rather than replying to previous messages I felt it would be better to start a new and more appropriately titled thread. In the ongoing quest to try and develop a timing system for in-code use and (now) benchmarking as an example application the original code of Joel de Guzman has been extensively modified and uploaded here: http://tinyurl.com/nmhthy The code uses two techniques for calculating the percentage speedup. It is quite likely that the error estimate for the actual run times is very wrong. I strongly suspect that the random error is over- estimated but the systematic error is under-estimated. Note that changing the machine loading can affect the absolute times noticeably. Burst-like behaviour will not matter too much, but sustained loading will. Consequently if you wish to directly compare the ns/char (nanoseconds per character) values between runs or machines care should be taken to make sure the background load is consistent. When looking at the relative times on a given run - particularly with the Wilcoxon test, this is far less important. I look forward to results anyone gets on other machines. Particularly with respect to robustness of the results against background processes, repeatability and or inter-compiler variations. Cheers, -ed $ echo 1000 15 | ./ejg_uint Enter buffer size: Enter nominal precision (%): initializing input strings... Nominal precision of quantum: 15% Timer overhead (t_c) (ticks): 108.321 Jitter (ticks): 8.24459 Approx clock frequency (GHz): 2.1681 Direct point estimates of actual run time. Function T - delta T (best) T + delta (ns/char) (ns/char) (ns/char) qi_parse 47 67 87 strtol 74 1.1e+02 1.4e+02 atoi 79 1.1e+02 1.5e+02 Speedup percentages based on Wilcoxon matched pair confidence intervals. Func. A vs Func. B Minimum Median Maximum (% faster) (% faster) (% faster) qi_parse atoi 69 69.2 69.3 qi_parse strtol 57.8 57.9 58 strtol atoi 7.14 7.16 7.2 qi_parse qi_parse -0.0762 0.00468 0.0343 Speedup percentages based on the point estimates. Func. A vs Func. B Best - err Best Best + err (% faster) (% faster) (% faster) qi_parse atoi 63.1 69.1 75.1 qi_parse strtol 51.8 57.8 63.8 strtol atoi 1.16 7.16 13.2 qi_parse qi_parse -6 0.00222 6 All done! ------------------------------------------------ "No more boom and bust." -- Dr. J. G. Brown, 1997

1 0

Details on boost::serialization
by Per Nordlöw 03 Aug '09

03 Aug '09

I haven't found any documentation on the header bits of the archive formats supported by boost::serialization. These are added as default when I construct binary and text formats. I am especially interested in skipping these headers completely in my application, that is serializing a char should only result in one byte outputted to stream. Does the headers basic_binary_[io]archive.hpp play any roles in this case? I have tried to use them instead by I got some strange error messages so these are commented out here. Thanks in advance, Nordlöw Compileable sample code follows: #include <fstream> // #include <boost/archive/basic_text_iarchive.hpp> // #include <boost/archive/basic_text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include <boost/archive/binary_oarchive.hpp> class gps_position { public: gps_position() {}; gps_position(int d, size_t m, float s) : degrees(d), minutes(m), seconds(s) {} private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & degrees & minutes & seconds; } int degrees; size_t minutes; float seconds; }; template<class OA, class IA> static void test(const gps_position & pos, const char * filename) { std::ofstream ofs(filename); // create and open a character archive for output { OA oa(ofs); oa << pos; } gps_position newg; { std::ifstream ifs(filename); // create and open an archive for input IA ia(ifs); ia >> newg; } } int main() { const gps_position p(35, 59, 24.567f); // test<boost::archive::basic_text_oarchive, // boost::archive::basic_text_iarchive>(p, "boost_serialization_basic_text_archive"); test<boost::archive::text_oarchive, boost::archive::text_iarchive>(p, "boost_serialization_text_archive"); test<boost::archive::binary_oarchive, boost::archive::binary_iarchive>(p, "boost_serialization_binary_archive"); return 0; }

2 1

[phoenix2][asio] phoenix bind does not work with asio
by Carlos Rafael Giani 03 Aug '09

03 Aug '09

Hi, I am trying to replace all occurrences of boost.bind with phoenix bind, since boost.bind is unusable due to the placeholders not residing in a named namespace. However, asio always fails to compile when used with phoenix bind. The error message always goes like "boost/asio/detail/bind_handler.hpp:130: error: no matching function for call to ‘invoke(const boost::asio::detail::binder2<boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::detail::function_eval<4>, ....." I suspect this is because phoenix bind creates an actor, not a boost function object. This problem is present in boost trunk as well. Does anybody have an idea how to solve this?

3 3

Documentation policy about namespaces
by Lasse Kärkkäinen 03 Aug '09

03 Aug '09

I couldn't find any discussion about this, but I have noticed that the documentation often completely neglects to mention the namespaces used or just mentions somewhere which using namespace directives should be used instead of documenting the namespaces of individual symbols. To me it would seem best to use explicit namespace specification in all example code and reference documentation. However, in example code where this is unsuitable (e.g. boost::placeholders::_1), the required using declarations and directives should be documented along with which symbols they are used for. Adding the namespace information to the documentation increases clarity because it instantly tells the reader which symbols are part of the library and which are part of the example code. Additionally, a number of Boost libraries already use the same symbol names in their respective namespaces, so assuming a large collection of using namespace directives is a bad practice. Documenting the header files to use and the libraries to link is another similar issue, but the problem is not as severe as it is with namespaces.

2 1

Release branch regression testing failures
by Beman Dawes 03 Aug '09

03 Aug '09

Stale tests have been cleared, and there is a fresh release branch regression test report up at: http://beta.boost.org/development/tests/release/developer/summary.html Libraries reporting errors on more than one platform are: bimap - all platforms failing build - all non-Linux platforms failing math - all platforms failing numeric/interval - two platforms failing optional - two platforms failing python - Linux platforms failing spirit - all platforms failing type_traits - all platforms failing units - two platforms failing I'd appreciate it if the developers involved would clear these tests in the next few days. Thanks, --Beman

10 12

There's a serious problem with the Boost Community :(
by Jon Biggar 03 Aug '09

03 Aug '09

Even though this is a complaint, let me start off by stating that I'm a happy user of Boost libraries for over six years, and don't intend to stop. That said, here's the problem: simple patches submitted languish without action or response for far too long. I submitted a patch for bjam with ticket #2552 back in November, including test cases to verify that it operates correctly. But despite requesting over several release cycles since then, no action has been taken and I haven't even gotten a response. It's a pain in the butt to have to keep reintegrating the same patch, release after release so I can keep working on code that I hope to one day submit to for inclusion in a Boost release. The Boost Community *really* needs a mechanism to ensure that patches submitted are acknowledged, vetted, and if found worthy, integrated into a release in a timely manner. Not doing so discourages contribution. Let me suggest that the Community set up something like the review queue, where a few volunteers could regularly select the next patch, request comments from the community and then champion getting the patch integrated into the next Boost release. I understand that library owners have a stake in the design vision and integrity of their library's code, so the community will have to figure out a policy where patches with minimal impact on a library's integrity can be quickly integrated without requiring a lot of the primary library owner's or maintainer's time, but will still get integrated or rejected in a timely manner. -- Jon Biggar jon(a)floorboard.com jon(a)biggar.org jonbiggar(a)gmail.com

4 5

Help with SVN required
by Robert Ramey 02 Aug '09

02 Aug '09

I want to merge current state of the directories of the serialization library into the release branch. In order to do this, I consult the SVN documentation as well as the instructions at https://svn.boost.org/trac/boost/wiki/ImprovingPractices When I do the merge - I get a large number of conflicts. It looks like: a) lines deleted from the trunk are not deleted from the new (release) working copy. b) files deleted from the trunk are not deleted from the new (release) working copy. c) files which have been added to the trunk don't show up in my (release) working copy. According to the SVN documentation I should go through the dozens of files with conflicts one by one and examine them and resolve all the conflicts. What I really want is for the current state of the trunk to be "transfered" to the release branch. Any body know what i might be doing wrong? Robert Ramey

3 5

request: BOOST_NO_SFINAE_EXPR macro
by Mathias Gaunard 01 Aug '09

01 Aug '09

It would be very nice if Boost.Config provided the BOOST_NO_SFINAE_EXPR macro, that would be defined if the compiler does not support SFINAE applied to expressions. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2634.html GCC supports this feature since 4.4 both for C++03 and C++0x for example.

3 7

issues when compiling boost with visual c++ 8 and 9
by Sean Farrow 01 Aug '09

01 Aug '09

Hi: The following is the output I am currently getting with the current trunk when trying to compile with visual c++ 9, tried with visual c++ 8 and got a similar error: C:/Program Files/boost/tools/build/v2/tools\msvc.jam:1040: syntax error at keyword = C:/Program Files/boost/tools/build/v2/build\toolset.jam:38: in toolset.using rule msvc.init unknown in module toolset. C:/Program Files/boost/tools/build/v2\build-system.jam:465: in process-explicit-toolset-requests C:/Program Files/boost/tools/build/v2\build-system.jam:545: in load C:\Program Files\boost\tools\build\v2/kernel\modules.jam:283: in import C:\Program Files\boost\tools\build\v2\kernel\bootstrap.jam:138: in boost-build C:\Program Files\boost\boost-build.jam:17: in module scope Hope this helps. Sean.

3 3