May 2008 - Boost - lists.boost.org

[range_ex] proposal
by Neil Groves 03 May '08

03 May '08

Dear Reviewers, May I kindly request a review to be scheduled at your convenience for the Boost RangeEx library proposal. The code and documentation have been uploaded to the root of the vault ain the form of the range_ex.zip file: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… Thank you for your consideration. Best Wishes, Neil Groves

2 1

Re: [boost] throw_exception rev. 44954 -> g++ warnings
by Ralf W. Grosse-Kunstleve 03 May '08

03 May '08

I think it is OK to disregard the warning below. I just played around a bit trying to resolve the warning. I kept adding throw(), but eventually got compilation errors because apparently there are derived destructors that throw. Therefore I simply silenced the warning (which is easy with this compiler). ----- Original Message ---- From: Ralf W. Grosse-Kunstleve <rwgk(a)yahoo.com> To: boost(a)lists.boost.org Sent: Friday, May 2, 2008 10:40:31 PM Subject: Re: [boost] throw_exception rev. 44954 -> g++ warnings There is another warning, this time from a compiler based on EDG 245 (Tru64 cxx): cxx: Warning: /net/taipan/scratch1/rwgk/auto_build/sources/boost/boost/exception/enable_current_exception.hpp, line 57: #768-D exception specification for implicitly declared virtual function "boost::exception_detail::clone_impl<T>::~clone_impl" is incompatible with that of overridden function "boost::exception_detail::cloning_base::~cloning_base" clone_impl: --------^ Just a throw() missing somewhere? Ralf _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[smart_ptr] cosmetic enhancement in intrusive_ptr
by Carlo Medas 03 May '08

03 May '08

Dear all, I'm kind of newbie here in this mlist although I've been using boost for a while now. I've been using and loving smart pointers in complex production environments with amazing results. Very trivial suggestion for cosmetic enh in intrusive_ptr: why isn't there a method like shared_ptr::reset()? I mean the one with no arguments. It's good in some code sections (e.g. to control release ordering) to reset pointers, but intrusive_ptr is missing the reset with no arguments, thus I have to do 'reset(0)'; this is not nice to read and not symmetric with shared_ptr where you can do sptr.reset() Thanks and best regards, Carlo Medas http://www.linkedin.com/in/carlomedas

1 0

Re: [boost] throw_exception rev. 44954 -> g++ warnings
by Ralf W. Grosse-Kunstleve 03 May '08

03 May '08

There is another warning, this time from a compiler based on EDG 245 (Tru64 cxx): cxx: Warning: /net/taipan/scratch1/rwgk/auto_build/sources/boost/boost/exception/enable_current_exception.hpp, line 57: #768-D exception specification for implicitly declared virtual function "boost::exception_detail::clone_impl<T>::~clone_impl" is incompatible with that of overridden function "boost::exception_detail::cloning_base::~cloning_base" clone_impl: --------^ Just a throw() missing somewhere? Ralf

1 0

GTL compile time and concepts redesign
by Simonson, Lucanus J 03 May '08

03 May '08

I have modified my example code to move the accessors out of the templated traits class and into a non-templated concept struct as Fernando suggested. I also added compile time accessors that are parameterized by enum values, which I decided would give me the benefits of type safety and readability I was getting with my isotropic types as runtime parameters, while allowing the much desired compile-time parameter for people who prefer it. The runtime accessors are still there and call the compile-time accessors by default. The user can specialize the accessors to adapt them to their type, but now it is significantly harder to do so, because previously the accessors were members of a template class, and it was the class that was specialized, allowing the functions to retain their template parameter list. Now I am unable to partially specialize the accessor functions, which means that I cannot make their arguments template parameters of the function (because the user can't be expected to specialize for every conceivable type.) The user also has to explicitly specialize each version of the compile-time accessor, such as: template <> inline rectangle_traits<LayoutObject>::interval_type rectangle_concept::get<HORIZONTAL>(const LayoutObject& rectangle) { return rectangle_traits<LayoutObject>::interval_type(rectangle.xl, rectangle.xh); } template <> inline rectangle_traits<LayoutObject>::interval_type rectangle_concept::get<VERTICAL>(const LayoutObject& rectangle) { return rectangle_traits<LayoutObject>::interval_type(rectangle.yl, rectangle.yh); } and can't do the following: template <orientation_2d_enum orient> inline rectangle_traits<LayoutObject>::interval_type rectangle_concept::get(const LayoutObject& rectangle) { if(orient == HORIZONTAL) return rectangle_traits<LayoutObject>::interval_type(rectangle.xl, rectangle.xh); return rectangle_traits<LayoutObject>::interval_type(rectangle.yl, rectangle.yh); } as might be their first inclination. I'm not sure to what extent that makes specializing the accessors harder. User feedback I get is that specialization (all kinds) is hard, and in practice I usually help them out by providing the specializations they need for the types they have to get them over that first hurdle and running with library. I feel that there is still some more progress to be made here, please have a look. Thanks, Luke

1 0

Going to Boostcon? Need a ride from Denver?
by Marshall Clow 03 May '08

03 May '08

I'll be arriving in Denver about 1:00 PM on Sunday, renting a car and driving to Aspen. If anyone needs a ride, there should be room for at least a couple in my car. Reply privately, please - not to the list. -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

Re: [boost] throw_exception rev. 44954 -> g++ warnings
by Ralf W. Grosse-Kunstleve 02 May '08

02 May '08

> In my opinion, this warning should be issued only if an attempt to > call the non-virtual destructor of a type with virtual functions > through a base class pointer is actually made, not simply because the > possibility exists. What's the disadvantage of adding the virtual destructors? It certainly is a huge disadvantage if -Wall cannot be used anymore. Until rev. 44954 everything we have compiled noise-free with -Wall (heaps of sources, many different gcc versions). I think the warning is useful. A library author cannot anticipate all situations in which the library may be used. If someone wants to derive from a class in a library and this triggers the smarter warning you propose for the first time, it is probably too late. If the library is part of the system headers it cannot be changed. The user is stuck. Ralf

2 1

[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

Re: [boost] detail/shared_cout.hpp: missing workaround.hpp include
by Ralf W. Grosse-Kunstleve 02 May '08

02 May '08

Done. Thanks! ----- Original Message ---- From: Peter Dimov <pdimov(a)pdimov.com> To: boost(a)lists.boost.org Sent: Friday, May 2, 2008 12:25:54 PM Subject: Re: [boost] detail/shared_cout.hpp: missing workaround.hpp include Ralf W. Grosse-Kunstleve: > I'm getting compilation errors on several platforms due to a missing > include in boost/detail/shared_count.hpp. This header makes use of > BOOST_WORKAROUND, but workaround.hpp isn't included. > Are the any objections to adding the include? No. Please go ahead.

1 0

detail/shared_cout.hpp: missing workaround.hpp include
by Ralf W. Grosse-Kunstleve 02 May '08

02 May '08

I'm getting compilation errors on several platforms due to a missing include in boost/detail/shared_count.hpp. This header makes use of BOOST_WORKAROUND, but workaround.hpp isn't included. Are the any objections to adding the include? Ralf Index: boost/detail/shared_count.hpp =================================================================== --- boost/detail/shared_count.hpp (revision 45030) +++ boost/detail/shared_count.hpp (working copy) @@ -28,6 +28,7 @@ #include <boost/detail/bad_weak_ptr.hpp> #include <boost/detail/sp_counted_base.hpp> #include <boost/detail/sp_counted_impl.hpp> +#include <boost/detail/workaround.hpp> // In order to avoid circular dependencies with Boost.TR1 // we make sure that our include of <memory> doesn't try to // pull in the TR1 headers: that's why we use this header

2 1