- Boost - lists.boost.org

Bug Sprint daily update for Sunday, June 6th
by Marshall Clow 06 Jun '10

06 Jun '10

As of 0800 Pacific time today, we had 988 open trac tickets. This is down by one from yesterday. However, there was lots of activity on the Trac yesterday: There were 4 tickets added There were modifications to 24 tickets. (ok, some were the same ticket more than once, but still...) There were 5 tickets closed. Daniel James did a lot of cleanup on the Quickbook tickets. Vicente Botet did an analysis of many of the Boost.Thread tickets and posted it to the list. Open tickets by type: Bugs 611 (-2) Feature Requests 239 (+1) Patches 95 Tasks 27 Support Requests 15 Library Submissions 1 Open tickets buy milestone: To Be Determined 186 (-1) Boost 1.43.0 181 (+1) Boost 1.42.0 132 Boost 1.40.0 85 Boost 1.36.0 82 Boost 1.41.0 81 Boost 1.39.0 67 <none> 60 (-1) Boost 1.38.0 45 Boost 1.37.0 37 Boost 1.44.0 20 Website 1.X 10 Boost.Jam 4.0.0 1 Top 10 libraries: thread 76 date_time 54 (-1) Python 48 test 43 interprocess 40 iostreams 37 filesystem 36 mpl 36 quickbook 32 (-1) asio 31 Top 10 owners: anthonyw 75 djowel 66 (-5) dave 58 igaztanaga 58 az_sw_dude 52 (-1) vladimir_prus 49 bemandawes 46 rogeeff 43 agurtovoy 36 turkanis 36 -- Marshall

1 0

[phoenix] Result type & compatibility with result_of
by Andrey Semashev 06 Jun '10

06 Jun '10

Hi, Is there a rationale of Phoenix2 being not compatible with STL functors and result_of? I'm trying to bind an STL functor and it fails to compile.

2 1

[Proto] Can't statement like expression be part of proto
by joel falcou 05 Jun '10

05 Jun '10

after digetsing all the contents of eric boost'con talk i came to the conclusion that epxression-tempalte enabled statement may be part of proto like operators. One can see the ability of having if or for as a real expression geenrator for any EDSL as actaully a feature. What may prevent if_, for_ and such to be first class, EDSL agnostic citizen fo proto ?

2 1

[polygon] tutorial done and library ready for release
by Simonson, Lucanus J 05 Jun '10

05 Jun '10

I have just added a tutorial to the documentation. The tutorial walks the reader through the requirements, design and implementation of a toy layout versus schematic comparision application. I would like feedback from the community on whether this is what you are looking for in a tutorial. Also I'd like to check with my review manager, Fernando, if this tutorial satisfies the acceptance requirement that I add a tutorial to the documentation. The tutorial can be found here: https://svn.boost.org/svn/boost/sandbox/gtl/doc/gtl_tutorial.htm At this stage I think I have satisfied the acceptance requirements from the review and would like to coordinate merging the library onto the trunk and release branch to get into the next release of boost. A little guidance from the release manager would be appreciated. Thanks, Luke

9 28

FW: Boost Digest, Vol 2933, Issue 1
by Bartlett, Roscoe A 05 Jun '10

05 Jun '10

Joel, > 13. Re: Review of a safer memory management approach for C++? > (joel falcou) > ------------------------------ > > Message: 13 > Date: Sat, 05 Jun 2010 16:40:01 +0200 > From: joel falcou <joel.falcou(a)lri.fr> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++? > Message-ID: <4C0A61C1.3020804(a)lri.fr> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Bartlett, Roscoe A wrote: > > 1) Well written OO C++ software builds and (more importantly) > rebuilds *much* faster than heavily templated code. This massively > speeds up the development cycle. The difference can be orders of > magnitude of time savings in recompile/relink times. I have seen cases > where carefully using runtime OO can result in recompile/relink cycles > take less than 20 seconds where using all template code would take 20 > minutes. I am *not* exaggerating here at all. > > > You have the right to write proper, fast to compile template code. > Technics and tools exists for this. And if your tempalte takes 20mn to > compile, your template design is wrong ... [Bartlett, Roscoe A] Nonsense. Apparently myself and no-one else in CSE or any other domain knows the right way to write templated code. Apparently all the books I have read on C++ and template programming (see http://www.cs.sandia.gov/~rabartl/readingList.html#_B%29_C++_Books) have not taught me the *right* way to write template C++ code. If it is that hard to write "correct" template C++ code then C++ should die a slow and painful death because no-one will be able to use it correctly. Oh, would you please teach us? > In our own HPC template base > code, everything compiles under 20s and only some exhaustive unti test > that instanciate all and every type/functiosn took up to 5mn. > > 2) Current compilers may not even be able to compile large amounts of > template code at all. There are compilers that we have to support > (e.g. Sun and IBM) that will segfault or return "internal compiler > error" when you give them too much template code. These same compilers > have no problem with virtual functions with standard OO. This is > reality. > > > Sun and IBM are all but references on the point of tempalte handling > ... > gcc, MSVC, ICC and even clang don't choke on most templated code ... > What about stopping working with compilers from before the industrial > revolution ? [Bartlett, Roscoe A] We don't get to pick the platforms that we have to support. If you supply code to ASC customers you will compile on their platforms, including Sun, IBM, and PGI. In fact, this is one reason why we can't have any mandatory dependencies on boost because there have been portability problems with boost on some of these platforms. Things have gotten a lot better with C++ compilers that we have to use in the last 9 years since I have been at Sandia but it is just not true that implicit instantiation with template code will compile just as fast as non-template code. There are fundamental arguments to refute that. Compilers could be much more crafty with templated code than they currently are but they are not (yet) and never will be with some compilers (i.e. Sun, IBM, PGI, etc.). > > 3) Templated programs can result in massive object-code bloat over > equivalent runtime OO programs. If you are really sloppy with > templates and use it for everything, you can easily double, triple, or > more (10x) the size of the object code and executables (see Item 44 in > "Effective C++, 3ed edition"). > > > > > same than 1/ learn to do it right ... And well, since when gigabyte > started to be costly ? [Bartlett, Roscoe A] The size of object code does have some impact, especially some HPC machines. Again, please teach us all how to do this because we apparently don't know what we are doing. > > 5) Well written OO C++ software allows for significant runtime > flexibility. If you use dynamic libraries, for instance, you can add > new implementations of objects without even having to relink customer > executables. Also, you can fix many types of bugs in updated shared > libraries without having to recompile/relink customer executables. In > a large-scale software setting, this can be very helpful. > > > That's maybe th eonyl poitn where I agree with you. > > > *********************************************************************** > ********************* > > *** You can't portably compile and link large C++ programs that > template everything!!!!! *** > > > *********************************************************************** > ********************* > > > Why ? [Bartlett, Roscoe A] The compilers segfault or return internal compiler errors or take hours to compile if they do finish at all in some cases. See above. Reality!!!!!!! > > As long as people keep suggesting that we template all of our codes > for every little reason, I am going to keep reminding people of the > realities of template code in C++. If you can't respond to the above > points (especially #1 and #2) then there is little point in continuing > the discussion. Thinking that we are going to drop runtime > polymorphism and use exclusively compile-time polymorphism for > everything is just fantasy land. > > > Nobody told you to put template everywhere. Same we don't want to put > dynamic polymorphism everywhere. What about learnign to sue the proper > tool for the proper task ? [Bartlett, Roscoe A] Finally we agree. Runtime polymorphism with OO has its place as does templated code with compile-time polymorphism. I was never arguing that template methods should never be used (because I use them all the time, much more than most C++ programmers) but other people did seem to be arguing to never use runtime OO with virtual functions (which is just bad advice). My argument is that current accepted ways of writing OO code in C++ make it too hard to write correct well designed programs and an affordable cost. My argument is that the Teuchos MM approach described in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf together with static analysis tools to help enforce the idioms (and keep raw pointers encapsulated) can largely eliminate undefined behavior in C++ programs due to the usage of memory and also yield programs that are more self-documenting at the same time. That is it. - Ross

2 1

[Beman's endian] explicit native endianes
by vicente.botet 05 Jun '10

05 Jun '10

Hi Beman, I see that there are specific classes for native endian, endian<endianness::native, ...>. I was wondering if instead of defining a separated class we can not define endianness::native depending on the ENDIAN of the host and remove the explicit definition. # ifdef BOOST_BIG_ENDIAN BOOST_SCOPED_ENUM_START(endianness) { big, little, native=big }; BOOST_SCOPED_ENUM_END #else BOOST_SCOPED_ENUM_START(endianness) { big, little, native=little }; BOOST_SCOPED_ENUM_END #endif Will this break the design? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

4 5

[endian] swap_in_place use case
by vicente.botet 05 Jun '10

05 Jun '10

Hi, I'm looking for a use case where the use of swap_in_place (or whatever is renamed) is not followed/preceded by a copy. When I need to send a message I need to copy the information to send in a buffer. I gues that in this case the use of swap (copy) is the function to use. Can somene help me to identify a real use case on which the swap_in_place can be used to send a message that do not need to be initialized before sending? When I receive a message, I will need to store some of the messages information on application context, store them on local variables or pass them to other functions. All this suppose a copy from the buffer to the different kinds of native storage. I gues that swap (copy) should be used in this case also. The example of Terry reveives a array of ints and makes a swap_in_place, but do nothing with. Someone has proposed to sum all these ints, but in this case, we don't need to swap_in_place and the count. With swap approach, we can count at the same time as we do the conversion, so no need to swap in place. Can somene help me to identify a real use case on which the swap_in_place can be used to reveive a message, without needing to do any additional copy from the swapped buffer to native data? Thanks, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

3 3

Trunk tests broken
by Belcourt, Kenneth 05 Jun '10

05 Jun '10

Hi, Could I suggest that when the trunk tests are completely broken, as they are now, and the report generation is cycling normally (every 1 to 2 hours) as it is now, that the likely source of breakage is a recent commit to the trunk repository. To reproduce the trunk failure, simply checkout out a current version of the trunk, cd to the status directory, and run bjam. If you do this right now, you'll find this error message. error: Unable to find file or target named error: 'test_diamond_complex.cpp' error: referred from project at error: '../libs/serialization/test' This is what's currently killing trunk testing. Since it's quite easy to reproduce the trunk failure, I think it would help Boost if developers would, when they recognize a problem, either revert the offending commit or ping the library author(s) to let them know about the breakage. Unfortunately I am unable to keep on top of when trunk testing is broken (i.e. it could be several days before I notice it) so if other developers could help diagnose breakage and report it, that would be very helpful. [ Robert, can you please address this issue? ] Thanks. -- Noel

8 17

Re: [boost] [endian] swap_in_place use case
by Dave Handley 04 Jun '10

04 Jun '10

Vicente Botet wrote: > Couldn't the filter be adapted to the endianess of the file and work directly on the disk format? Surely this violates the most important principle of endian swapping - that you should always work in native endian and swap on the boundaries. If I specifically wrote the algorithm to work on the disk endianess I would need to adapt the algorithm to cope with both big and little endian situations; the algorithm would change depending on which platform I compiled on; and every person coding on the algorithm would need to code to be endian aware. This would be a maintenance nightmare. I'm not sure I've been totally clear on what I mean by a filter. I mean a filter in the signal processing sense of the word. So let's set up a problem where we are reading a 10000x10000 image with 4 byte integer gray scale at each pixel and uncompressed (so 400Mb file). This is in big endian format. What I then want to do is convolve a number of kernel with the original image to perform various image transformation. The kernels I'm going to use are, say, the following (Sobel kernels): [ 3 10 3 ] [ 0 0 0 ] [ -3 -10 -3 ] [ 3 0 -3 ] [ 10 0 -10 ] [ 3 0 -3 ] And maybe a few more. Each will be convolved with the image, and since I'm using this for feature detection, all I want to do is create a list of points over a given (absolute) threshold. So I'm creating a resulting data object that is much smaller than my input object. Now here, if I swap on use, then if I run this code on a little endian machine I will end up swapping everything 9 times per 3x3 kernel that I convolve. If I swap up front and then convolve, on a big endian machine I will end up using twice the memory (and copying the whole source file). If on the other hand I swap in place, on both little and big endian machines I have an efficient algorithm. My pseudo-code for this is going to be: Swap in place version: 1) Memory map big file 2) Endian swap in place 3) For each filter: Convolve filter with image, and output results Swap and copy version: 1) Memory map big file 2) Copy entire big file whilst endian swapping 3) For each filter: convolve with copy of image, and output results Swap on use version: 1) Memory map big file 2) For each filter: convolve with disk-endian image, hence for each pixel in image swap pixel and 8 surrounding pixels, multiply given 9 pixels by the filter and output if over threshold. End up swapping each pixel 9 times. Terry Golubiewski wrote: > I disagree. I have demonstrated that... > > 1) endian-on-access can be zero cost in the native-case. > 2) swapping in place is not any safer because the C++ type system cannot > help to determine which portions of an object have been swapped, nor > document the endian properties of a data structure. endian<big, double> > can, and should, be defined to provided portable floating-point transfer and > persistent storage. > I, in turn, also disagree. I'm not quite sure what you did demonstrate with your test case. If by "endian-on-access" you mean copying during the endian swap, then I don't think it is ever zero cost since a copy is always required. It is the same cost as the swap/swap-in-place code if and only if your code requires a copy to take place at some point, at which point both cases require the cost of a copy. To be honest, because your test case didn't separate reading data in from performing the swap, I was really unsure what information it actually conveyed. I would agree with another commenter (Robert I think) who asked for some timing code to be placed around the actual endian swapping to properly time how long the swap took on its own. I don't think the issue with endian swapping code is "safety" since you should really be endian swapping at the boundaries (when the data is read into the machine you should be converting to machine endian) and that will always be "safe". Actually, the big problem I have with the endian types is that you require 2 versions of every structure you are reading in for swapping (one version with endian types and one without); and that you are tempted to defer endian swapping until very late in the code, which means that you are no longer endian swapping at the boundaries. I would really dislike debugging a program that carried around data in the wrong endianness and only swapped it when used. I actually suspect the most common use case of endian types would be as a really short lived temporary storage for the wrong endian data from disk/network/elsewhere, and as such I don't see what you gain with a "type-safe" interface. Dave Handley

1 0

Boost Bug Sprint #3 starts tomorrow!
by Marshall Clow 04 Jun '10

04 Jun '10

The bug sprint will run from tomorrow June 5th until Sunday, June 13th. As of 11:00 AM PST today, there are currently have 992 open tickets. The goal is to classify and fix bugs, and to close Trac tickets. For those just joining in, the tickets live at https://svn.boost.org The instructions (mostly repeated here) for the first bug sprint are at https://svn.boost.org/trac/boost/wiki/BugSprintJune2009 As the bug sprint progresses, I will be posting updates to the list and to https://svn.boost.org/trac/boost/wiki/BugSprintStatusJune2010 What can you do? You can fix bugs • If you are a library maintainer, you can commit your fixes. • If you are not a library maintainer, you can fix a problem on your local machine (and test it!!), and then attach your fix as a patch to the Trac ticket for the library maintainer to commit. If you do this, please provide a test case that exercises the problem; i.e, one that fails w/o your patch, and succeeds afterwards. You can characterize bugs • You can attempt to replicate the bug on your system(s), and attach information that you discover to the Trac ticket. This will make it easier for other people to solve the problem, even if you cannot. • You can write test cases demonstrating the problem, and attach them to the Trac ticket. • You can determine if the bug still exists; sometimes they get fixed, and the ticket never gets closed. In this case, try to identify a checkin that addresses the bug; it's always suspicious when bugs go away "by accident." You can test patches • Some of the tickets in the Trac system contain patches - some are quite old. You can install these patches on your system, and determine if they (a) build, and (b) work. If you do this, please provide detail. Don't just say "works for me" - say "I installed this over revision XXX on system YYY with compiler ZZZ. The patch installed and compiled successfully, and passed all the tests." • You can write test cases for the patches, and attach them to the ticket. You can help implement new features • There are a whole set of "feature requests" in the Trac system. If you have an idea about one of these, you can add comments to the Trac system. You can attempt to implement these new features, and attach the patch to the ticket. (Don't forget the test cases!!). There are several Trac reports that I find helpful for looking at the bugs: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 and, of course, the main report at https://svn.boost.org/trac/boost/report/1 Some things I see while looking at these reports: * There are 82 bugs with a milestone of "Boost 1.36.0", which was released 22 months ago. * There are 24 tickets with no owner, of which 15 are 'bugs'. * There are 63 tickets with no milestone attached; we have the "to be determined" milestone for cases where you're not sure when the fix will go in. -- Marshall

1 0