June 2010 - Boost - lists.preview.boost.org

[filesystem] Version 3 of Boost.Filesystem added to trunk
by Beman Dawes 06 Jun '10

06 Jun '10

Because version 3 will break some user code, both v2 and v3 will be shipped for several releases. For 1.44, the default is v2 and the user has to explicitly switch to v3. I'd really appreciate it if some Boosters could give v3 a try on your own code that uses Boost.Filesystem. If you already have trunk on your machine, just run "svn up" on it. Otherwise, checkout a copy: mkdir boost-trunk svn co http://svn.boost.org/svn/boost/trunk boost-trunk If you prefer, "svn export http://svn.boost.org/svn/boost/trunk boost-trunk" should also work. Then read boost-trunk/libs/filesystem/dual_versions.html, and follow the instructions there. Then please let me know your results: * Are the instructions for changing to version 3 sufficient? They are pretty minimal, but I'm assuming those doing this have a high level of background knowledge. * Did you have any problem changing to version 3? * Did you have problems compiling your code against version 3? * If there were compile errors, do you have any ideas about how to mitigate the problem? * Did you have any problems testing or running your code with version 3? * Any other comments or suggestions? Thanks, --Beman

8 28

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