April 2008 - Boost - lists.boost.org

result_of usability
by David Abrahams 06 May '08

06 May '08

The difficulty of implementing the result_of protocol has always bothered me. I've often found myself writing a primary result<...> template and several specializations to handle different cv-qualifications, and I've still not felt that I was doing it quite right. It's lucky that operator() has to be a member function, or I'd be worried about capturing the r/lvalue-ness of the function object itself. Now I just ran into another issue, from the other side of the result_of interface. If I have a function template taking a function object argument by reference, and I want to use result_of with it, I need to do something special to account for the case where I've been passed a function reference. To wit: template <class F> typename result_of<F()>::type call(F const& f) { return f(); } int f() { return 0; } int x = call(f); The problem is that in the above case, F is deduced as int(), and we form an illegal function type (one that itself returns a function type) in result_of<F()>::type. To deal with this I need something more like template <class F> typename result_of< typename mpl::if_< is_class<F> , F , typename add_pointer<F>::type >::type() >::type call(F const& f) { return f(); } Is there an easier way? -- Dave Abrahams Boost Consulting http://boost-consulting.com

5 11

[Math/nextafter] A question of naming functions...
by John Maddock 06 May '08

06 May '08

Folks I'm looking for some good names for some functions I'm on the brink of adding to Boost.Math (all in namespace boost::math::): T nextafter(T val, T dir) Returns the next representable floating point value to "val" in the direction of "dir". This name is basically fixed, since it's the one that C99 uses. T next_greater(T val) Returns the next representable value greater than "val". T next_less(T val) Returns the next representable value less than "val". T edit_distance(T a, T b) Returns the number of floating point representations between values a and b. So the questions are: can you think of any better names, or are these OK? And should edit_distance return a signed or absolute value? Thanks in advance, John.

12 41

C++ Memory Management Innovation: GC Allocator
by shiwei xu 06 May '08

06 May '08

Most of the C++ programmers do not benefit from "Garbage Collection" technique (GC). They are sick of deleting objects but have to do this. There are some C/C++ memory GC implementations, but they are complex and are not widely used. I am going to introduce a new memory management technique named "GC Allocator". "GC Allocator" isn't an implementation, but a concept. Now, we have two "GC Allocator" implementations, named "AutoFreeAlloc" and "ScopeAlloc". This article consists of three parts: 1. What is GC Allocator? 2. GC Allocator implementations: ScopeAlloc and AutoFreeAlloc 3. Applications based on GC Allocator For more information, see http://www.codeproject.com/KB/cpp/gc-allocator.aspx To obtain a copy of this paper in pdf format click here<http://xushiwei.com/local--files/gc-allocator/GCAllocator.pdf>(or from google code <http://code.google.com/p/stdext/downloads/list>).

9 42

[1.35][lexical_cast][concept check][range] Build error and warnings with MSVC8 on Warning Level 4
by Stephan Diederich 05 May '08

05 May '08

As we tried to update to 1.35 today, we found some warnings with MSVC on Warning Level 4 in: lexical_cast: There was a return statement after a call to throw_exception which causes a unreachable code warning. I can see no problem by just removing that return. see http://svn.boost.org/trac/boost/ticket/1791 concept_check: BOOST_concept(SGIAssignable,(TT)) causes two warnings: C4510: default constructor could not be generated C4610: object 'class' can never be instantiated - user-defined constructor required solved thorugh pragmas see http://svn.boost.org/trac/boost/ticket/1792 and an error in range/iterator_range: see http://svn.boost.org/trac/boost/ticket/1793 for details. The patch is attached, as I was not able to discuss with Akismet that it's no spam ;) "Submission rejected as potential spam (Akismet says content is spam)" cheers, stephan

4 7

Header only pro's and con's?
by Roland Schwarz 05 May '08

05 May '08

Please don't misunderstand this mail. I do not want to start a header contra lib war. I just want to learn about the pro's and the contras of header only. The issue has popped up in this list quite some times, but I was not able to find any document which tries to do a serious in-depth discussion of when to header only and when not. If anyone knows about such a document I would be pleased if he could point me at it. Thank you. -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at

4 3

[random] Rician and Weibull distributions
by Matthias Schabel 04 May '08

04 May '08

If there's any interest, I've implemented these two distributions (attached). They have only been lightly tested at this point, but might be of interest to some users of Boost.Random. Cheers, Matthias

4 3

Geometry Template Library from Intel
by Simonson, Lucanus J 03 May '08

03 May '08

Some of you may remember discussion related to a potential submission of a computational geometry library from Intel last year. Interest in the library was expressed, and some interesting conversation about technical specifics of the library ensued. The most common feedback was "show us the code". At that time, I said that it would take several months to get approval to release the code outside of Intel. Eventually I decided to put the further discussion of my library in boost on hold until I could release the code to you. Now I have gotten approval to release the code to boost, licensed it under the boost license and uploaded it to the vault under Math Geometry. Please feel free to take a look and discuss the library on the list or directly with me. See the README file for some more specific information about the submission. I realize that there has been a recent submission of a GIS data processing library targeting cartography applications mostly, from Barend Gehrels. I agree with him that the overlap between his library and mine is minimal. He is using floating point arithmetic and works with arbitrary angle polygons. My library is integer based and works with polygons that are restricted to right angles and 45-degree angles. Since last year I have added support for resizing of sets of polygons that may have 45-degree edges. While there is some minimal numerical adjustments that need to be made to ensure integer coordinates on the output of such resize operations, that is still a far cry from what CGAL or a good GIS data crunching library is doing. The two capabilities are more complementary than competing. I expect that many changes to my library will be recommended (or required) by the boost community before it might be considered for acceptance into boost. Also, I recognize that some synthesis between multiple related geometry submissions (and ideas) is likely to take place. I'm fine with that. That is what I want to happen and I why I came to boost. Now that I am able to share the original source code with you it is possible for fruitful discussion in that vein to resume. Luke

9 33

[gil] [announcement] New IO lib
by Christian Henning 02 May '08

02 May '08

Hi there, over the past few months I have been working on a new version of gil's io extension. In this release I've added support for: * more image formats, most importantly bit_aligned images ( like 1bit images ), * reading of subimages like one row at a time for huge images, * reading image information, only. * having a unified interface for all sorts of devices, subimages, and converter objects. So far, png, jpeg, and tiff images are supported. In the not so distant future there will be bmp and pnm images added. You can grab the current version via subversion from: https://gil-contributions.googlecode.com/svn/trunk/gil_2/boost/gil/extensio… If desired I can supply a zip file to the vault. The images libraries can be grabbed from: ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6b.tar.gz ( www.ijg.org isn't responding ) http://www.libpng.org/pub/png/libpng.html http://www.libtiff.org/ It's highly advised to built your own version of the image lib you need. I installed the GNU's binaries for Windows, but unfortunately, I only had problems with them. The library is still header-only. When using boost::filesystem's paths, of course, you add a dependency to the filesystem lib. The Read Interface ------------------------ Reading an image can be done in multiple ways depending on what your need is. Like the old io lib there are 4 different ways of reading images. As there are: * read_image: Read image, the right amount of memory will be allocated beforehand. The supplied image type needs to be compatible with actual image file. * read_view: Read image, the image's memory must be already allocated. The supplied image type needs to be compatible with actual image file. * read_and_convert_image: Same as read_image, but the user can specify an color converter. * read_and_convert_view: Same as read_view, but the user can specify an color converter. There is a new function for reading image information. Since every image format has it's own set of tags, the library defines seperate image_read_info<format_tag> structures. Please see, for instance, the jpeg_tags.hpp header. As for the function parameters the following sections in the same order. 1. String for file name ( std::string, std::wstring, char*, boost::filesystem::path ) OR devices ( FILE*, TIFF*, std::ifstream ) 2. Image or view type 3. Optional: Subimage definition ( top_left corner + dimensions ) 4. Optional: Color converter. This parameter is only valid for converting functions. The default parameter is gil's default_color_converter 5. Format Tag. Reading the image information only takes parameter 1 and 5. Here are some examples for reading images: #include <boost/gil/extension/io_new/jpeg_read.hpp> // Read image information std::string filename( "..\\test_images\\jpg\\found online\\test.jpg" ); image_read_info< jpeg_tag > info = read_image_info( filename, tag_t() ); // Read image FILE* file = fopen( filename.c_str(), "rb" ); rgb8_image_t img; read_image( file, img, tag_t() ); // Read image ifstream in( filename.c_str(), ios::in | ios::binary ); rgb8_image_t img( 136, 98 ); read_view( in, view( img ), tag_t() ); // Read and convert image, use gil's default converter. rgb8_image_t img; read_and_convert_image( filename, img, tag_t() ); // Read a 10x10 subimage, starting from the top_left corner. rgb8_image_t img; read_image( filename, img, point_t( 0,0 ), point_t( 10, 10 ), tag_t() ); I have created some header files to support the old read interface. For example: #include <boost/gil/extension/io_new/jpeg_io_old.hpp> std::string filename( "..\\test_images\\jpg\\found online\\test.jpg" ); rgb8_image_t img( 136, 98 ); jpeg_read_view( filename, view( img ) ); The Write Interface --------------------------- The write interface is a much simpler than the read interface. Here, we only have write_view as the entry point. As for parameters the following sections are supported: 1. String for file name ( std::string, std::wstring, char*, boost::filesystem::path ) or devices ( FILE*, TIFF*, std::ofstream ) 2. View type 3. Optional: image_write_info< FormatTag > 4. Format type The image_write_info<...> structure defines a format specific properties which can be used when writing an image. A good example is jpeg's image quality value. Examples: #include <boost/gil/extension/io_new/tiff_write.hpp> // Write image string filename( "..\\test\\tiff\\test1.tif" ); gray8_image_t img( 320, 240 ); write_view( filename, view( img ), tiff_tag() ); // Write image string filename( "..\\test\\tiff\\test2.tif" ); TIFF* file = TIFFOpen( filename.c_str(), "w" ); rgb8_image_t img( 320, 240 ); write_view( file, view( img ), tag_t() ); I have created some header files to support the old write interface. For example: #include <boost/gil/extension/io_new/tiff_io_old.hpp> string filename( "..\\test\\tiff\\test3.tif" ); gray8_image_t img( 320, 240 ); tiff_write_view( filename, view( img ) ); Supported image formats ------------------------------------- In the process of developing the new version I tried to include as many formats as possible. One consequence is a much higher compilation time. Hopefully, a design review by the community can hint me better ways to reduce it. Also, there are still holes in the support. Most noteably is TIFF, since it can support almost everything. This makes it very hard not to have code explosion during compilation. Here is a list of list of supported formats: TIFF: * Number of samples: 1, 3, 4 ( eg. RGB would be 3 ) * Bits per sample: 1, 2, 4, 8, 16, 32, 64 * planar and interleaved images * indexed images. Indices can be of 1, 2, 4, 8, or 16 bit depth, whereas the palette must a rgb16_image_t. PNG: * gray, gray_alpha, rgb, rgba * bit_depth can be 1, 2, 4, 8, 16 JPEG: * gray, rgb, cmyk, ycck ( will be read as cymk ) Please note, that I'm still in process of testing all these different formats. The primary goal of this new version is to eventually replace the old io library which is part of boost's distribution. Do I need to apply for a review? I'm not sure how to go from here. I know there is still some work to do before a possible review. Documentation is lacking and support for dynamic image needs to be added. But what I want for now is to get some feedback on design and implementation. I would like to thank Lubomir Bourdev and Andreas Pokorny for their most valueable input. Thanks, Christian

6 16

[thread]joining the first thread finishing from a group of threads
by vicente.botet 02 May '08

02 May '08

Hello, I have several implementations of the same function with different algorithms. I want to launch these in parallel and join the one finishing the first, and stop the others. I have started and in my solution I need to wrap the function in order to make the needed synchronization, which seam not quite satisfactory. Is there an easy way to join the first thread that finish from a thread group and getting it? boost::thread_group tg; // ... boost::thread* first = tg.join_one(); Do you find useful this feature? Regards _____________________ Vicente Juan Botet Escriba

3 3

Strange font settings on www.boost.org
by Jens Seidel 02 May '08

02 May '08

Hi, I noticed that headlines look very strange on the new website. I think the problem is #content h1, #content h2, #content h3, #content h4, #content h5, #content h6 { margin: 0em; color: #000000; font-family: "Times New Roman",serif; font-variant: small-caps; clear: both; } in http://www.boost.org/style/css_0/content.css. Why is a special font used? I do not have such a font and I would also prefer if the browser would be able to use a default. As far as I know it is save to use a few standard font aliases such as sans-serif or similar in HTML but "Times New Roman" is probably not one of these, right? Jens

4 3