- Boost - lists.boost.org

[Serialization] memory leak when serialising a map containing shared_ptrs
by richard bradley 28 Jan '10

28 Jan '10

I'm finding that Boost.Serialization is leaking memory when deserialising std::map<string,boost::shared_ptr<X>>. Maybe this is a sign that my data structures are too complicated? ;-) This wouldn't bother me that much, except that I'm also using Boost.Test, which gives lots of angry messages about leaked memory at the end of my tests (I'm using MSCRT). I've attached a simple test case which demonstrates this. Can anyone shed some light on what's going on here? Have I used any of the libraries incorrectly? Is there anything I can do to fix this? I'm using Visual Studio 2008, and boost 1.41.0 The output from the attached test looks like: =========== Running 1 test case... MyClass @3532504 with 1 children MyClass @3532960 with 1 children Detected memory leaks! Dumping objects -> {800} normal block at 0x0035EDE8, 1 bytes long. Data: < > CD Object dump complete. =========== I've also attached a stack trace which I got by breaking on the non-free'd memory allocation,using "--detect_memory_leak=800" Thanks very much, Rich

1 1

unzip .zip file and browse to compressed files
by Andrej van der Zee 28 Jan '10

28 Jan '10

Hi, I am looking for a way to uncompress a zip-file (which contains multiple files/dirs) and browse through the contents. Does boost provide support for the first part? I looked at iostreams with a zlib uncompressor, but as far as I can see it assumes a single zipped file. Thank you, Andrej

7 7

[Boost.utility]
by Andrew Chinkoff 27 Jan '10

27 Jan '10

Having considered [ http://www.research.ibm.com/designpatterns/pubs/ph-jun96.txt] I propose singleton implementation. I had attached "singleton.hpp" to this letter. Below is the test program: #include <stdio.h> #include <singleton.hpp> class A : public boost::Singleton<A> { // // Only Singleton class can create and delete us! // SINGLETON_IS_MY_FRIEND; public: void foo(){ printf("foo!\n"); } A(){ printf("A()\n"); } ~A(){ printf("~A()\n"); } }; void main() { // It is not compiled: //A a = A::Instance(); // That is exactly as it should be used: A::Instance().foo(); } Test program outputs: A() foo! ~A() I suggest include "singleton.hpp" into "utility.hpp" header that it can be used along with: boost::noncopyable, etc.

14 67

[1.41.0] [filesystem] Undefined references to get_system_category and get_generic_category
by Richard Hadsell 27 Jan '10

27 Jan '10

I am trying to build some code using the 1.41.0 version of the filesystem library. It used to build with version 1.34.1. I am getting errors, when the linker fails to find boost::system::get_system_category and boost::system::get_generic_category. What do I need to do differently to find or build these functions? -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560

2 2

Are any of these bugs _really_ show stoppers?
by Marshall Clow 27 Jan '10

27 Jan '10

There are 25 bugs in the Trac system which are marked as "showstopper". Are any of these really worth holding up the release for? (and if not, should we reclassify these bugs?) http://svn.boost.org/trac/boost/report/29 986 Problem building Python modules on boost 1.34.0 1215 Boost 1.34.1, mpl: Wrong workaround detection using MinGW32 (or.hpp, line #33)" 2411 bzip2_compressor does not work with filtering_istream,new,Bugs,Boost 1.37.0 2512 interval cosh: wrong result if interval contains 0 (but is not identical to [0,0]) 2513 rint not present in Visual Studio 2008 2164 locate_root wrong under CygWin 2797 Two problems with thread_specific_ptr 2255 Compilation error during arm cross compile - boost 1.36 2883 Boost::signals compile problem with GCC 3.4.5 2958 [patch] changes to make asio compile on vxWorks 2956 vxWorks POSIX quirks for date_time 583 Fixes for build on IBM pSeries for AIX and Linux 426 lambda vs pure virtual functions 3325 Limited support for mapping regions to specific addresses in Linux 738 Memory leaks with signal::connect? 3480 Build fails on Debian: 2.6.18-5-686-bigmem #1 SMP Tue Dec 18 22:34:10 UTC 2007 i686 GNU/Linux 3165 wrong project-config.jam generated for intel-linux 2955 [patch] recursive mutex impossible if pthread_mutexattr_settype not defined 1066 Patch to make Boost.Python compile on SunCC 2185 bjam hangs when building libs/python/examples/quickstart under MacOS X 3716 Application crash when using Boost.Python in a plug-in DLL for that application 3723 gzip_docompressor error - basic_array_source no putback member 2330 thread::interrupt() can be lost if condition_variable::wait() in progress 3735 thread_group::interrupt_all() is unreliable 2226 boost::thread 1.36.0 /clr Link Error LNK2022 Just asking.... -- Marshall P.S. I don't mind fixing 2512 and 2513 - and can do that for 1.43 if people don't want them in 1.42.

3 4

BoostCon Conference Hotel Now Accepting Reservations
by David Abrahams 26 Jan '10

26 Jan '10

Hello Boosters and former BoostCon attendees! The BoostCon website has been updated for 2010, registration is open, and the conference hotel is already prepared to start taking our reservations. If you are planning to go to Boostcon this year, I suggest you take a few minutes to register (http://www.boostcon.com/registration) and make your hotel reservation (http://www.boostcon.com/location/lodging) today. -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com

1 0

[chrono] v0.3.2 New frequency, lifetime and percentage stopwatch_accumulator features
by vicente.botet 26 Jan '10

26 Jan '10

Hi, I have update the Boost.Chrono library with some minor features, a lot of bug fixes, and started the tutorial with some examples of features interesting people since the last version. New Features: * Added overloading for operator/(Integer/Duration) (used to get the frequency) * Added frequency, lifetime and percentage to the stopwatch_accumulator. The default format is "%c times, sum%ss, min%ms, max%Ms, mean%as, frequency%fherzs, lifetime%ls, percentage=%p%\n", where %c : the counter of the number of times the pair start/stop has been called. %s : the sum of the samples of elapsed time between the call to start/stop. %m : the min of the samples of elapsed time between the call to start/stop. %M : the max of the samples of elapsed time between the call to start/stop. %a : the mean of the samples of elapsed time between the call to start/stop. %f : the frequency of calls to start. %l : the lifetime of the stopwatch_accumulator. %p : the percentage of time spent by this stopwatch respect to its lifetime. Bug Fixes * Specific formatters didn't work completly * Replace duration(0) by duration::zero() on template classes. * suspend didn't work: partial_ not initialized neither taken in account by the elapsed function. The library can be downloaded from http://www.boostpro.com/vault/index.php?action=downloadfile&filename=chrono… and the documentation is online on the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/index.ht…. SVN repository http://svn.boost.org/svn/boost/sandbox/chrono. I would like to thanks particularly Andrew Chinkoff for his suggestion of the frequency feature and all those that have tried the library and reported the bugs they found, either on this ML or personally. I would really appreciate if people having the possibility to test on other platforms/compilers report me how the library works. As you can see the library is already on the review schedule, waiting for a review manager and a date for the review. I expect to add yet some features for the review release as thread clocks, and suspensible clocks i.e. clocks that can be suspended/resumed. Any idea for better naming the concepts/classes is welcome. Hoping this release works better for you, Vicente (See below the contents of preceding releases) ----- Original Message ----- From: "vicente.botet" <vicente.botet(a)wanadoo.fr> To: <boost-users(a)lists.boost.org>; <boost(a)lists.boost.org> Sent: Wednesday, January 20, 2010 11:02 PM Subject: [chrono] v0.3.1 Support for wide characters Hi, this new version includes: * Added support for wide characters on formatters. * Added chrono.hpp and stopwatches.hpp header files at the boost level. * Update of the doc taking care of preceding comments. Comments are welcome :) Best, Vicente ----- Original Message ----- From: "vicente.botet" <vicente.botet(a)wanadoo.fr> To: <boost(a)lists.boost.org>; <boost-users(a)lists.boost.org> Sent: Sunday, January 17, 2010 9:14 PM Subject: [chrono] v0.3 New Stopwatch Feature Hi, I'm pleased to announce the new version of the Boost.Chrono library. The implementaton is quite stable; the new interface could suffer of some modifications, renaming, ... as far as you submit some proposals. I would request a formal review soon and I will need a review manager. I know that review managers are hard to find, so if you are interested in the library, please the Review Wizards. The library can be downloaded from http://www.boostpro.com/vault/index.php?action=downloadfile&filename=chrono… and the documentation is online on the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/index.ht…. I've tested it with gcc and MSVC. Previoous version of the library have been testted on Mac, but I'm not able to test this platform. Could someone check if there are some regressions on Mac? New Features: * Process cpu clocks * Independent process cpu clocks for real, user, system process CPU time * Global process cpu clock for real, user, system process CPU time * Stopwatch concept measuring elapsed time between different points in time associated to the operations start, stop, suspend and resume. * stopwatch is a model Stopwatch measuring the elapsed time between the start and the stop operations. * stopwatch_accumulator is a model Stopwatch allowing to accumulate several time samples and give the average, ... * Scoped helper classes allowing to pairwise start/stop operations, suspend/resume and resume/suspend a Stopwatch. * Stopwatch Formatter concept * stopwatch formatter "%ds\n" * stopwatch accumulator formatter "%c times, sum%ss, min%ms, max%Ms, mean%as\n" * time formatter "real %rs, cpu %cs (%p%), user %us, system %ss\n" * digital_time decomposition class separating days, hours,minutes,seconds, nanoseconds from any duration class (looking for a better name) * digital_time formatter "%d days(s) %h:%m:%s.%n\n" * stopwatch_reporter is a convenient generic class reporting elapsed time for the Stopwatch concept. * stopclock<Clock> shortcut stopwatch_reporter<stopwatch<Clcok>> * typeof registration for classes duration and time_point Depreceated Features: * The classes process_times, process_clock, process_timer, timer and run_timer are now deprecated as the preceding additions are more generic. However for backward compatibility they are preserved until inclusion of the library in Boost. Next follows the equivalences: timer<> ~ stopwatch<> process_timer ~ stopwatch<process_cpu_clock> run_timer ~ stopclock<> Bug Fixes * Try to correct warning C4251: 'boost::chrono::run_timer::m_format' : class 'std::basic_string<_Elem,_Traits,_Ax>' needs to have dll-interface to be used by clients of class 'boost::chrono::run_timer', by don't including inlines functions using the std::string m_format. For people that doesn't know it yet, Boost.Chrono library provides: * The C++0x Standard Library's common_type. * The C++0x Standard Library's compile-time rational arithmetic. * The C++0x Standard Library's time utilities, including: * Class template duration * Class template time_point * Clocks: * system_clock * monotonic_clock * high_resolution_clock * typeof registration for classes duration and time_point * Process clocks: * process_real_CPU_clocks, capturing real-CPU times. * process_user_CPU_clocks, capturing user-CPU times. * process_system_CPU_clocks, capturing system-CPU times. * process_cpu_clock, tuple-like class capturing at once real, user-CPU, and system-CPU times. * Stopwatches: * stopwatch, capturing elapsed Clock times. * stopwatch_accumulator, capturing cummulated elapsed Clock times. * scoped helper classes allowing to pairwise start/stop operations, suspend/resume and resume/suspend a Stopwatch. * Stopclocks or Stopwatch reporters: * stopwatch_reporter, convenient reporting of models of Stopwatch results. * stopclock<Clock> shortcut of stopwatch_reporter<stopwatch<Clock>> Best regards, _____________________ Vicente Juan Botet Escribá

2 2

floating point FUD
by Thomas Klimpel 25 Jan '10

25 Jan '10

Hi, Find attached a small test program that tries to highlight some of the "usual" floating point traps. The essence is the following small function that outputs the results of some "buggy" floating point logic. The rest is just setting up the environment so that the bugs actually get triggered. void buggy_function(double eps = 1e-13, int length = 3, double delta = 1 / 7.0) { using namespace std; double alpha = 1e-13; double beta = eps; double a = length * delta; double b = length * delta; vector<double> inverse; for (int i = 0; i < length; ++i) inverse.push_back(1.0/(2*i+1)); vector<double> sorted; for (int i = 0; i < length; ++i) sorted.push_back(inverse[i]*delta); double t = -delta*sorted.size(); double tt = -sorted.size()*delta; bool t_tt = (abs(t-tt) < eps); bool abs_t = (abs(t) == -t); double c = (1-alpha) * a + alpha * b; double d = (1-beta) * a + beta * b; bool a_c = (a == c); bool b_d = (b == d); vector<bool> equal; for (int i = 0; i < length; ++i) equal.push_back(inverse[i]*delta == sorted[i]); std::cout << "t_tt = " << t_tt << "\nabs_t = " << abs_t << "\na_c = " << a_c << "\nb_d = " << b_d << "\n"; std::cout << "equal = ["; for (int i = 0; i < length; ++i) std::cout << " " << equal[i]; std::cout << " ]\n"; } The hypothetical "naive" programmer might expect the output: t_tt = 1 abs_t = 1 a_c = 1 b_d = 1 equal = [ 1 1 1 ] However, the actual output is not only different from this, but also depends on the compiler, the compiler settings, the current configuration of the floating points unit and the actual headers included directly or indirectly by the compilation unit. g++ test_fp.cpp -g -Wall compiles without warning and executes with output: t_tt = 0 abs_t = 1 a_c = 1 b_d = 1 equal = [ 1 1 1 ] g++ test_fp.cpp -DNDEBUG -O2 -msse2 -Wall compiles without warning and executes with output: t_tt = 0 abs_t = 1 a_c = 1 b_d = 1 equal = [ 1 0 0 ] I created a new project with MSVC9. The debug version compiles with warnings for the things that go badly wrong and executes with output: t_tt = 0 abs_t = 0 a_c = 1 b_d = 1 equal = [ 1 1 1 ] set floating point unit to 'high' precision: t_tt = 0 abs_t = 0 a_c = 1 b_d = 1 equal = [ 1 1 1 ] The release version compiles with warnings for the things that go badly wrong and executes with output: t_tt = 0 abs_t = 0 a_c = 1 b_d = 1 equal = [ 1 1 1 ] set floating point unit to 'high' precision: t_tt = 0 abs_t = 0 a_c = 0 b_d = 1 equal = [ 1 0 0 ] In my case (see the background story below), it was actually the trap represented by the output "abs_t = 0" instead of "abs_t = 1" that caught me on linux64 but worked on win32. (It turned out difficult to reproduce this with gcc, so the test program reproduces this trap with MSVC, even so MSVC warns quite explicitly about it). I think it is a funny exercise to debug the test program and find out what actually goes wrong (which is especially funny since most traps only go wrong with compiler optimization turned on). Regards, Thomas ------------------------ The background story: The recent reviews of [Constrained Value], [Polygon] and [GGL] all featured interesting disagreements over floating point issues: http://lists.boost.org/Archives/boost/2008/12/145655.php http://lists.boost.org/Archives/boost/2008/12/145788.php http://lists.boost.org/Archives/boost/2009/03/149567.php http://lists.boost.org/Archives/boost/2009/08/155767.php http://lists.boost.org/Archives/boost/2009/11/158560.php (These were long threads with many messages and many participants, so please don't misinterpret my choice of unrepresentative messages as any form of statement.) Last Wednesday, I had to give an internal live demo of a feature I just finished. I had done the development mostly on win32, but I wanted to run the demo on linux64, to be able to show examples of realistic size (full chip...). While preparing the presentation, I was surprised to find the accuracy of the results significantly worse than I remembered from my previous tests. I repeated my previous tests on linux64, and found out that there was indeed a problem with my code on linux64. I did the demo on win32, but was asked after the presentation to send the source code to somebody from another group. So I spent most of the night trying to find the problem in my code. When I found out that some code with floating point driven logic (I had written years ago) to analytically integrate radial symmetric functions over rectangular domains was showing unexpected behavior, I decided to postpone the floating point fights with the compiler to the next day. I told this story the next day in a group meeting, and was confronted with much floating point FUD and unrealistic suggestions, basically boiling down to either not writing floating point driven logic in the first place, or commenting it in excessive detail. So I lost my temper and explained that it was difficult enough for me to write this code with floating point driven logic, and that anybody suggesting writing it without floating point driven logic should do so please, because I'm unable to do it. I have to admit that I read "What Every Computer Scientist Should Know About Floating-Point Arithmetic" only superficially: http://www.engrng.pitt.edu/hunsaker/3097/floatingpoint.pdf http://docs.sun.com/source/806-3568/ncg_goldberg.html I also have to admit that I write code with floating point driven logic from time to time in case it seems unavoidable to me, and that this code often has bugs that are only discovered months after the code is already finished. But I never found a bug in such code that would have been a fundamental problem with floating point, but always just the "usual" floating point traps I keep overlooking by mistake. Now somebody will probably suggest that I should at least document the "usual" floating point traps then. So I created the attached small test program showing the "usual" floating point traps I could still remember having overlooked at least once. It was actually more difficult than expected to arrange the code in a way that the bugs are really triggered for typically compiler settings of MSVC and gcc.

9 16

[Quickbook] Integrating Spirit docs
by Hartmut Kaiser 24 Jan '10

24 Jan '10

Hey, Not exactly a question for the main devel list, but I'm not sure, where its best to send it to... What do I need to do in order to integrate the Spirit docs (generated by Quickbook) with Boosts overall doc page (i.e. http://www.boost.org/doc/libs/1_41_0/doc/html/libraries.html)? Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

2 1

Re: [boost] RFC: Sequence Properties and Boost Algorithm/Functional
by Grant Erickson 24 Jan '10

24 Jan '10

On Fri, 22 Jan 2010 14:13:31 -0800 Jeffrey Hellrung <jhellrung(a)ucla.edu> wrote: On 1/23/10 12:35 AM, boost-request(a)lists.boost.org wrote: >> For a recent project, I needed to inquire about a sequence of objects and >> make a determination as to whether the sequences were: >> >> * Increasing >> * Strictly Increasing >> * Decreasing >> * Strictly Decreasing >> >> Looking through STL, Boost documentation, Boost sources and headers and the >> Boost mailing lists I was able to find neither an existing algorithm or >> stateful unary predicate functor for accomplishing this for a pair of input >> iterators. However, I was a bit surprised considering that this seems like a >> sequence property query that would tend to come up fairly often and serve a >> general utility. Did I just fail to form the proper search/query or am I >> overestimating the general utility? >> >> Is a smarter realization of this as an algorithm a potential candidate for >> boost::algorithm? > > Perhaps std::adjacent_find and std::less is all you need, e.g., to > determine if a sequence is decreasing? > > I.e., a sequence is decreasing iff all adjacent pairs of elements xi, > x[i+1] satisfies xi >= x[i+1] iff no adjacent pair of elements xi, > x[i+1] satisfies xi < x[i+1] (assuming that (!>=) == (<)). On Fri, 22 Jan 2010 15:24:32 -0800 Marshall Clow <mclow.lists(a)gmail.com> wrote: > I've got this floating around from a while back... > > [ examples omitted ] Marshall and Jeff: Thanks for the feedback. Marshall's feedback seems to indicate that, yes, there is likely general utility need for such functions and Jeff, you are correct that these algorithms are trivially composed from std::adjacent_find, std::not2 and std::{greater,less,greater_equal,less_equal}: namespace boost { namespace detail { template <typename ForwardIterator, typename BinaryPredicate> bool is_creasing(ForwardIterator first, ForwardIterator last, BinaryPredicate binary_pred) { return std::adjacent_find(first, last, std::not2(binary_pred)) == last; } } // namespace detail template <typename ForwardIterator> bool is_increasing(ForwardIterator first, ForwardIterator last) { typedef typename std::iterator_traits<ForwardIterator>:: value_type value_type; return detail::is_creasing(first, last, std::less_equal<value_type>()); } [ ... other three instances follow trivially ... ] } // namespace boost Unless there's any other feedback, I'll work on posting an implementation to Boost Vault. Regards, Grant

1 0