April 2008 - Boost-users - lists.preview.boost.org

Question about Any usage
by Jeffery Cavallaro 30 Apr '08

30 Apr '08

I have a question about the use of Any, especially when used in a larger facility such as program_options. There doesn't seem to be a (easy) way to post-process the results of a facility that has generically stuffed a bunch of values into a list of Any's. For example, if I wanted to a program to spit out all of its options to standard out, there doesn't seem to be any hooks to extract an Any value in a generic way (e.g., as a string). Granted, I could derive a class and add methods to do so, but that doesn't work when Any is already embedded in the program_options implementation. I certainly could be missing something here. I haven't used Any or program_options yet, and trying to understand all of the possibilities from the spec-like doc is hard. How do the rest of you do such things? -- Jeffery Cavallaro, 1055 Joaquin-191A Infrastructure Engineering Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 650-214-2552

7 6

[concept_check] Why does char not qualify as "Integer"?
by Peter 30 Apr '08

30 Apr '08

The statement BOOST_CONCEPT_ASSERT((boost::Integer<T>)); triggers an error if T is the type char. It does not trigger an error if T is either of type signed char or unsigned char. I can understand why it's not so easy to detect for SignedInteger or UnsignedInteger given type char, but to my understanding using type char should work with the above statement. Peter

1 0

MPL preprocessed question
by Neal Meyer 30 Apr '08

30 Apr '08

Alright I've been through the mailing list a few times, and thanks to Ovanes for the help on getting some of the mpl stuff working. Here's what I've got working so far. I built a vector100.hpp and placed it in the boost\mpl\vector and added the following to my header. #define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS #define BOOST_MPL_LIMIT_VECTOR_SIZE 100 #include "boost/mpl/vector.hpp" #undef BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS #undef BOOST_MPL_LIMIT_VECTOR_SIZE Great everything works great, except for the fact that it takes an extra long time to compile. So following some threads on the list, I'd like to pregenerate a header file with the definitions for the vector that takes 100 elements. Placed the vector100.cpp in the \libs\mpl\preprocessed\vector and ran the preproces.py and got the vector100.hpp file generated in boost\mpl\vector\aux_\preprocessed\plain. Everthing seems like I'm heading in the right direction to get it proprocessed. So know what do I do to get it included in the same way as the previous code? I've tried including the new header directly and playing around with various macros to get it to be included, but no dice so far. Is there a way to have the preprocessing scripts regenerate the vector.hpp in boost\mpl\aux_\preprocessed\plain? So that I can use boost::mpl::vector instead of a version with the number of parameters in it, because that's varies dramatically throughout how this code is being used and would be a major pain. -Neal

1 0

[gil] [announcement] New IO lib
by Christian Henning 30 Apr '08

30 Apr '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

2 2

Boost CGI
by Brad 29 Apr '08

29 Apr '08

What is the current status of Darren Garvey CGI library? I am starting a CGI project and am wondering whether this is mature enough for the job? At the moment I am only looking at CGI but I may need FastCGI, etc. at a later date. My current opinion from looking at the source downloaded from http://cgi.sourceforge.net is that it will be suitable. Anyone know of any alternatives? Darren, are you still working on this? I noticed the site says you had some study to get out of the way, we've all been there ;-) Cheers, Brad

3 3

[iostreams] Prepending and appending output data in a filter
by Edward Diener 29 Apr '08

29 Apr '08

I have a filter, derived from multichar_output_filter, in which I am both prepending data and appending data. In other words the data being written to the sink will be greater than the data being passed into the filter's 'template<typename Sink> std::streamsize write(Sink& dest, const char* s, std::streamsize n)' member function, which my filter is implementing. Is this an allowable use of filters ? Do I still return the 'n' streamsize data being passed in or do I return the actual length of the data being written ? Can I use the 'template<typename T> std::streamsize write( T& t, const typename char_type_of<T>::type* s, std::streamsize n );' function to write the data, or do I need to 'put' each character to the sink using the 'template<typename Sink> void put(Sink& snk, typename char_type_of<Sink>::type c);' function instead ?

2 1

accumulator problem on visual studio 7.1
by Abir Basak 29 Apr '08

29 Apr '08

Hi, Is the boost accumulators library has too deep nesting in template declaration ? I am very interested to use it, but it increases the compile time drastically (with the inclusion of header #include <boost/accumulators/statistics.hpp> and sometimes it gives \boost\boost\lambda\detail\lambda_traits.hpp(53) : fatal error C1204: compiler limit : internal structure overflow, even for a simple program like computing mean of 3 numbers. So it seems there is a very deep template recursion which exceeds the compiler template substitution limit. Has anyone faced this kind of problem ? using the boost svn head version & MSVC 7.1 thanks abir -- Abir Basak, Member IEEE B. Tech , IIT KGP Software Engineer, Read Ink Technologies

3 3

[serialization] serialization/utility.hpp missing include of xpressive/xpressive.hpp
by Sancho McCann 29 Apr '08

29 Apr '08

Anyone else agree this is a problem? I was trying to compile this simple program: #include <boost/numeric/ublas/vector_sparse.hpp> #include <boost/numeric/ublas/io.hpp> #include <iostream> int main(int argc, char** argv) { using namespace boost::numeric::ublas; mapped_vector<double> v(3,3); for ( unsigned i = 0; i < v.size(); ++i ) v(i) = i; std::cout << v << std::endl; return 0; } and the include hierarchy ends up including serialization/utility.hpp. This file uses the template mpl::and_, so I think it should include xpressive/xpressive.hpp. Sancho

1 0

[interprocess] shared memory containing a vector of unions of strings/integers/doubles
by Jason Sachs 29 Apr '08

29 Apr '08

I'm trying to wrap my head around how I would implement a vector of unions of strings/integers/doubles in shared memory. (for those familiar with Micro$oft COM, this would essentially be a SAFEARRAY of VARIANTs) I got a quick example of shared memory working & seem to have a decent handle on the basics. I guess there are two things that I'm not quite confident in: (1) how to make a containable element work nicely within shared memory, e.g. if I have a structure S that needs to allocate shared memory dynamically during its lifetime (and automatically deallocate upon destruction), how do I store the allocator? (or do I?) If I allocate the memory myself and store it in an offset_ptr<>, I can do that, but I need it to manage the shared memory itself. In particular, one process may need to construct some anonymous object X within the shared memory segment and store the result in an offset_ptr<>, and another process may be the one destroying the memory of X later on. (2) unions or Boost.Variant that would work with shared memory-- gack! I am looking for insight both into the general case (all elements of the vector are polymorphic, vector size can vary) and the following specific case: I have a fixed-size vector, format "defined" at runtime using an array of enums that designate the type of variable that can be stored in each element of the vector. If it weren't for string support, I would just allocate a fixed-size chunk of memory rather than a vector, and do all the management within the chunk myself by calculating element size + offsets + what have you, which I've done before in other contexts. I can still do that if I can store a handle to the string (e.g. an offset into the shared memory segment?) rather than a pointer or other high-level object, so that my "vector" object becomes a class that just has to know how to allocate/deallocate memory on its own (hence question #1 still needs an answer, but I can avoid question #2). p.s. there seems to be a lot of missing methods in the documentation for shared_memory_object and managed_shared_memory (e.g. allocate(), construct(), destroy(), destroy_ptr()). Or am I missing something? http://www.boost.org/doc/libs/1_35_0/doc/html/boost/interprocess/shared_mem… http://www.boost.org/doc/libs/1_35_0/doc/html/boost/interprocess/basic_mana…

2 2

any ETA for the BoostPro Binaries 1.35?
by Daniel Önnerby 29 Apr '08

29 Apr '08

Does anyone know if there are any plans for the boost consulting to release the BoostPro Binary Installer for Visual C++ for boost 1.35? I know I can build this myself, but it's always easier when someone else does it ;) Best regards Daniel

1 0