- Boost - lists.boost.org

[boos][threadalert] What about a submision to boost?
by vicente.botet 24 Sep '08

24 Sep '08

Hello Ronald, I need a transactional thread specific context which can also be accesible from other threads during consistency checking. I've found in your library threadalert (available on the boost vault) the thread_member_ptr which corresponds completely to my needs. I'think that independently of the alert library the thread_member_ptr might be a good candidate to Boost. thread_specific_ptr behaves as a private member of a thread and thread_member_ptr as a public member. This seems a natural extension. BTW, it would be nice to be able to associate a cleanup function as it is the case of the thread_specific_ptr. If you need some help I would like to collaborate with you. Please, let me know what do you think. Best regards, Vicente Juan Botet Escribá

1 0

feature request for building boost libraries for msvc
by Hansi 24 Sep '08

24 Sep '08

Hello, I have a question to building boost. I have read now a lot of posts where it is written that with msvc the SECURE option is really slow. In some posts I have read that this option breaks the ABI and for that it is needed to build also the boost library with the right compiler switch. isn't it? 1) How I can build it with a custom compiler switch? sorry if it is documented, but I don't have found it... 2) Is it possible to add a make option(complete build) which builds a library with this switch and against which boost links automatically when the application defines _SECURE_SCL=0? Best regards Hansjörg

1 0

boost::atomic<T> foo;
by Janek Kozicki 24 Sep '08

24 Sep '08

Hi, I looked through Boost.Threads and Boost.Interprocess libraries, but (as far as I can tell) none of them offers me simple: class Foo { boost::atomic<int> bar; } which would mean that *ALL* attempts to access bar would be atomic, eg. bar=10; Am I left with troublesome usage of boost::mutex to block all that access attempts by myself? -- Janek Kozicki |

6 8

[Filesystem] has_root_path()
by Robert Jones 24 Sep '08

24 Sep '08

Boost 1.33.1 used to support has_root_path() on directory_iterators. 1.36 seems to use a slightly different mechanism for directory_iterators, based on instantiating basic_directory_iterator, and I'm struggling to see what has happened to has_root_path(). It's there somewhere, but not accessible in quite the same way as it was. How do I express directory_iterator -> has_root_path() in 1.36.0 ? Thanks - Rob.

1 0

Boost::log : File rotation based on day of week
by Rajpal Dangi 24 Sep '08

24 Sep '08

Is it possible to configure Boost::log to rotate log files based on day of week in addition to size of file? What I'm targeting is a logger putting files in separate directory for each day of week and automatic cleanup of logs older than a week. Rajpal

2 1

[log] RFC: An alternative implementation is coming up
by Andrey Semashev 23 Sep '08

23 Sep '08

Hi, After more than a year of development my implementation of logging library is coming to its first release. Here are some feature highlights: * independent logger/sink and multimodule-friendly design with great extensibility potential * support for both embedded and global loggers * full-fledged attribute support (global, thread-specific and logger-specific attributes supported) * filtering and formatting support, including lambda expressions for filters and formatters construction * support for writing log to streams (files, console), rotating files support * support for Syslog API * support for library initialization helpers, including settings file support * thread safety support with least possible locking * wide-character logging support The library documentation can be found online on SourceForge: http://tinyurl.com/5e4fd7 Some requirements background can also be found on this Wiki: http://tinyurl.com/2fndfg The library code is quite stable, however, minor changes are still possible. The code can be checked out from the SourceForge CVS, the detailed instructions can be found here: http://tinyurl.com/6k9vvp There are currently no automatic tests, but there are some examples, which were compiled and run on Linux and Windows. I would like to see what Boost community thinks of this library, whether it worth submitting, has any critical flaws or any other thoughts. I also would appreciate if Gennadiy Rozental and John Torjo expressed their thoughts on possibility to review this library in parallel with John's solution, which is currently in the review queue. I would gladly discuss this privately, if they find it more suitable.

3 5

[asio] Compiler error with Sun C++ 5.9 on Solaris
by Boris 23 Sep '08

23 Sep '08

I sent this bug report to the Asio mailing list. As it didn't show up I send it here again. Sun C++ 5.9 on Solaris has a problem with the following conversions: "../../../boost/asio/detail/socket_ops.hpp", line 218: Error: Cannot assign void* to char*. "../../../boost/asio/detail/socket_ops.hpp", line 229: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 66: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 72: Error: Cannot assign void* to char*. Boris

2 1

[UUID] Still alive?
by Burc Arpat 23 Sep '08

23 Sep '08

Hi, Any idea what happened to the UUID library? I believe the mini review that was supposed to happen after the library got accepted provisionally never happened, right? Thanks, G. Burc ARPAT burcarpat.com pdgm.com

5 18

[gil] new io extension
by Christian Henning 23 Sep '08

23 Sep '08

Hi there, I've been busy working on the next version of gil's IO extension. The last iteration was very slow to compile especially when reading or writing tiff images. This and other problems have been fixed. As a result compilation is a lot faster but also a lot more tiff formats can now be read or written. Please grab the latest from: http://gil-contributions.googlecode.com/svn/trunk/gil_2/boost/gil/extension… This download is a little bigger than to usual since there are test images included. Please see my original announcement below for documentation. The goal of this extension is to substitute the original io lib which is part of gil, and though shipped with boost. To do this a review is probably needed. I'll work on a proper documentation as the next step. Can anyone tell me where to find a tutorial for creating quickdoc? There is one problem I cannot fix and would like to ask the experts on this list. Please read the readme.txt in libs\gil\io_new\unit_test which explains the scenario. This problem has something to do with erroneously choosing the wrong functions by the compiler. The enable_if metafunction doesn't work correctly here. As usual any feedback is welcome. Thanks, Christian ------------------------------------------------------- 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 ) ); 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

1 0

[filesystem] has_branch_path()
by Robert Jones 23 Sep '08

23 Sep '08

I'm upgrading the Boost release in use at work from 1.33.1 to 1.36.0, with surprisingly few issues actually, but I am stuck on one thing. There's a function in 1.33.1, has_branch_path(), for which I cannot see the equivalent functionality in 1.36. Part of my difficulty is that the 1.33.1 header declares but does not define the function, and I cannot see where the body code is! Any suggestions would be appreciated at this point. Thanks. - Rob.

1 0