- Boost - lists.preview.boost.org

Workaround for compiler bugs
by Edward Diener 09 Dec '10

09 Dec '10

In attempting to write a library for Boost I have sometimes run into a given compiler's bug which prevents my work succeeding for a given compiler without a workaround. While I can, and have, gone to a compiler's NG or online forum to report the bug, and hopefully find a workaround, given the nature and difficulty of template metaprogramming there have often been no adequate responses. Of course I have worked to find a workaround on my own, but sometimes I can not find the "magic incantation" <g> to do so, while in other cases I can. Is this a valid NG for bringing such a compiler bug to light so that other Boost developers are not only aware of the bug but might have a solution, if they have not already developed one for themselevs ? Sometimes the bug peripherally involves some Boost library but often the bug just involves some sort of template, or template metaprogramming, construct which a particular compiler just can not handle correctly. In all cases the bug would have to do with some Boost-like library I am working on, preferably in the sandbox, else I would not feel justified in bringing up this issue in a Boost developer NG.

6 13

[gil io_new review] Reading images from in-memory sources
by Phil Endecott 09 Dec '10

09 Dec '10

> review of Christian Henning's extensions to the Boost Generic Image Library > starts on December 1st and lasts until December 10th, 2010. I've been looking at how to read images from in-memory data. For example, I have various places where I mmap() something that contains encoded images (e.g. a large map made up from many tiles in a single file). I can also imagine retrieving an encoded image from a database, for example. According to io.qbk: [h2 Reading And Writing In-Memory Buffers] Reading and writing in-mempory buffers are supported as well. See as follows: `` // 1. Read an image. ifstream in( "test.tif", ios::binary ); rgb8_image_t img; read_image( in, img, tiff_tag() ); // 2. Write image to in-memory buffer. stringstream out_buffer( ios_base::out | ios_base::binary ); rgb8_image_t src; write_view( out_buffer, view( src ), tiff_tag() ); // 3. Copy in-memory buffer to another. stringstream in_buffer( ios_base::in | ios_base::binary ); in_buffer << out_buffer.rdbuf(); // 4. Read in-memory buffer to gil image rgb8_image_t dst; read_image( in_buffer, dst, tag_t() ); In the cases that I described above, using a stringstream would require that all of the data is copied at least once. I guess that if I knew more about how streambufs work I would know how to avoid that. Can anyone help me to implement this: void read_mem_jpeg( some_gil_image_tpye& dest, const char* jpeg_mem_begin, const char* jpeg_mem_end) { ... } in a way that doesn't copy all of the encoded data? Looking at formats/jpeg/read.hpp, it seems that irrespective of that the data will be copied again (into 'buffer') before being read by libjpeg. On the subject of copying, while reading PNGs it looks like the data is always copied into a temporary buffer in read_rows<>() even when no format conversion is needed (or is there some specialisation that I have missed?). And when reading JPEGs, it seems to always read single lines, yet libjeg advises that you should get at least rec_outbuf_height lines on each call to avoid extra copying within the library. Regards, Phil.

6 16

Formal Review of IO and Toolbox extensions to Boost.GIL ends TOMORROW
by Mateusz Loskot 09 Dec '10

09 Dec '10

Dear All, The formal review of the IO and Toolbox extensions terminates tomorrow. I'd like to set the cut-off time at Midnight on Saturday, 11 December 2010, UTC Time (http://www.timeanddate.com/worldclock/fixedtime.html?day=11&month=12&year=2…) I think we have been doing well and received decent amount of feedback. However, anyone feels there is a need for extension, please let me know as soon as possible, so I will have time to negotiate it with the Review Wizards. Mateusz Review Manager for the proposed Boost.GIL.IO and Boost.GIL.Toolbox extensions On 30/11/10 18:01, Mateusz Loskot wrote: > Dear All, > > According to the Boost Formal Review Schedule [1], > review of Christian Henning's extensions to the Boost Generic Image > Library (Boost.GIL, [2]), it is: > * Boost.GIL.IO > * Boost.GIL.Toolbox > starts on December 1st and lasts until December 10th, 2010. > > [1] http://www.boost.org/community/review_schedule.html > [2] http://www.boost.org/doc/libs/release/libs/gil/doc/index.html > > =========== > What is it? > =========== > > The Boost.GIL.IO extension provides an easy to use interface for > reading and writing various image formats. It also includes > a framework for adding new formats. The Boost.GIL.IO is indent > to replace the current IO extension which is part of Boost > for several years now. > > Features: > > * A unified way to read and write image encoded in BMP, JPEG, > PNG, PNM, and TIFF formats. The capabilities to read and write > in various formats have improved dramatically. > > * Image data can be provided via standard file or string streams > > The Boost.GIL.Toolbox provides new color spaces > and other small code to ease programming with Boost.GIL. > > Features: > > * Implementation of color spaces: Gray_Alpha, HSL, HSV, LAB, and XYZ > * Utilities to support dynamic image workflows and color conversions. > * Collection of metafunctions to determine alignment, similarity > and homogeneity at pixel level. > > The Boost.GIL as well as the proposed extensions are provided in > form of a headers-only library Although, some image formats come with > their format dependency, it is corresponding third-party libraries: > > JPEG - libjpeg > PNG - libpng > TIFF - libtiff > > =================== > Getting the library > =================== > > The latest version of both extensions can be downloaded as > Zip package: > > http://gil-contributions.googlecode.com/files/boost_review.zip > > or directly from the Subversion repository: > > http://code.google.com/p/gil-contributions/source/browse/trunk/gil_2/ > > and the docs can built as usual with bjam and quickbook tools > from within libs/gil/io_new/doc directory > > The libs/gil/io_new/test/readme.txt provides a step by step guide to > configuring, building and running the unit tests. > > The boost_review.zip is about 20MB due to its extensive collection of > test images. They are part of the test suite to make sure that > different variations of each image format is read and > written correctly. > > Please, be aware no guarantee can be given that all formats in > their all variants are completely supported. > > ================ > Writing a review > ================ > > If you feel the new IO and Toolbox are interesting extensions > to the Boost.GIL library, then please submit your review > to the developer list (preferably), or > to the review manager (mateusz at loskot dot _n_e_t_) > > Here are some questions you might want to answer in your review: > > - What is your evaluation of the design? > - What is your evaluation of the implementation? > - What is your evaluation of the documentation? > - What is your evaluation of the potential usefulness of the > extensions? > - Did you try to use the extensions? With what compiler? Did you have > any problems? > - How much effort did you put into your evaluation? A glance? A quick > - reading? In-depth study? > - Are you knowledgeable about the problem domain? > > And finally, every review should answer this question: > > - Do you think the extensions should be accepted as a part > of Boost.GIL library? > > Be sure to say this explicitly so that your other comments don't > obscure your overall opinion. > > Mateusz > Review Manager for the proposed Boost.GIL.IO and > Boost.GIL.Toolbox extensions -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

1 0

Anyone got any ideas on Trac #2409? [ Boost::Optional; MSVS 9; one byte alignment ]
by Marshall Clow 09 Dec '10

09 Dec '10

Is this still a problem? It was reported against 1.36.0 https://svn.boost.org/trac/boost/ticket/2409 [ If someone could try to reproduce it, and add their results to the ticket, that would be great ] -- Marshall

1 0

[serialization] boost 1.45. I did not find any information about serios flaw in 1.44
by Sergey Voropaev 09 Dec '10

09 Dec '10

I am reporter of bug #4660 (https://svn.boost.org/trac/boost/ticket/4660) I am glad this bug was fixed in 1.45 version. But I did not find any information in release notes (http://www.boost.org/users/download/version_1_45_0) and in library documentation (http://www.boost.org/doc/libs/1_45_0/libs/serialization/doc/index.html) about what was fixed in 1.44 version. There are not any recommendations or comments about using version 1.44 with binary archives. I think that the absence of such information is very dangerous for the future of the serialization library, since this is a serious indicator of the quality of maintenance of the library. (I have no complaints about the quality of the library and its design) Should I reopen this bug, or open a new one, or this letter would be sufficient to restore order to the documentation of serialization library?

4 4

Boost on Sun CC without STLPort
by Martin Elzen 08 Dec '10

08 Dec '10

I've done a 'port' of one of our products which involved Boost 1.38. ... 0 or 1, using the Boost regex, system and filesystem libs with Sunstudio 12.0 (not the 'recent' .1 upgrade) on Solaris 10. To build Boost enabling the stlport option is a must (a certain Sun employee blogged about it a year or two ago). Unfortunately that will mean that all your other C++ code will need to be compiled with that same option. I did end up having to mess with one of the Boost system-ish files (maybe a .jam file) 'manually' to convert the -library=stlport4 option to -library=stlport4_dbg in 2 separate location in that file to get correct debugging libs. Except for that everything seemed to work fine at least as far as the Boost parts went...

1 0

copy on write for std containers
by Peter Foelsche 08 Dec '10

08 Dec '10

I wrote a couple of lines and replaced std::set and std::map with some copy-on-write-wrappers and I got a dramatic speed improvement with the last gcc 4.5. I think. My code was using recursive functions iterating over a tree returning and setting such objects. I looked and it seems there is nothing like this in boost! Ideally this should be an template argument for the std containers. Peter

6 11

Half-baked GIL IO extension review
by Edd Dawson 08 Dec '10

08 Dec '10

- How much effort did you put into your evaluation? A quick glance. I am interested in perhaps using the GIL in future and so keep half an eye on it, but I haven't yet had time to really sink my teeth in to it. I currently maintain a couple of C++ libraries for PNG and JPEG I/O [1][2] and wouldn't mind being released of the burden ;) So I'm really looking at the code to see whether it solves *my* problems. Hope that's ok. - What is your evaluation of the design? I think it's fine on the whole. But I'm left with some questions, some arising from real-world uses: 1. is there explicit support for reading images from files with Unicode file names? Or do I have to prepare a stream myself? I ask because there seem to be a lot of overloads for reading from files whose paths are specified by char*s and std::strings. IMO, in anything other than a toy application, these would be useless for writing portable code. And for toy code I'd probably use the PIL[3] (Python) instead. So for *me*, these functions are redundant. I'm aware of this redundancy because it exists in my code too :) 2. is it wise to drag the stuff from e.g. the IJG JPEG library's public headers in to client scope? I ask because I've had clashes with the "boolean" macro before and this would outright prevent me from using the library. The implication of addressing this would probably mean that the GIL would no longer be header-only. That's fine by me, but perhaps it's a design goal of the GIL for some reason? 3. Is there support for things like performing lossless JPEG rotations? Not a big deal to me right now, but potentially I would like to use such a facility in future. 4. Is there support for obtaining the real-world dimensions of a loaded raster in millimetres, say? I work on CAD/graphics applications which need this functionality in order to generate reasonable texture coordinates. - What is your evaluation of the implementation? Looking again at the JPEG code here. As far as I can tell setjmp/longjmp have been used with appropriate care, but I worry what will happen if a method on a Device throws an exception, for example. I've had both Visual C++ 2008 and Apple's g++ 4.0.1 crash on me in this kind of situation. In my code, I attempt to store an exception by doing something akin to boost::current_exception(), then longjmp out to a safe point before re-throwing it. The IJG JPEG library can be compiled as C++ code and there's some new stuff in Version 7 to control whether or not extern "C" blocks are used (look for DONT_USE_EXTERN_C in the IJG source). It would be desirable in my opinion to allow the user of the library the ability to use a build of libjpeg that was compiled as C++. If compiled in such a manner, with a little care it is possible to entirely replace setjmp/longjmp with exceptions. The same is true of libpng and possibly of libtiff. - What is your evaluation of the documentation? Couldn't find a lot. Either my eyes are poor, or the documentation is :) - What is your evaluation of the potential usefulness of the extensions? Potentially very useful. - Are you knowledgeable about the problem domain? I know little about the inner workings of the file formats and compression schemes involved, but have written my own C++ wrappers for libpng and the IJG JPEG library ('libjpeg'). - Do you think the extensions should be accepted as a part of Boost.GIL library? I personally couldn't use it until some of my concerns/requests were addressed. But I certainly think it could be of value to others as-is. However, I would say that there has to be more documentation, assuming I haven't simply missed it... For this reason, my answer at the moment is regrettably 'no'. I hope this was useful and my lack of general GIL knowledge doesn't invalidate too much of my evaluation. Kind regards, Edd [1] http://bitbucket.org/edd/pngxx [2] http://bitbucket.org/edd/jpegxx [3] http://www.pythonware.com/products/pil

5 14

Boost on Sun CC without STLPort
by Dean Michael Berris 08 Dec '10

08 Dec '10

Hi Everyone, Is there any specific reason why Boost isn't tested against Sun CC without STLPort -- aside from the obvious reason that there's nobody running the regression tests on that platform? Is it something inherently wrong in Sun's standard library implementation that's preventing Boost from working properly on the Sun compiler? Insights would be very much appreciated. Thanks in advance. -- Dean Michael Berris deanberris.com

7 14

[GIL] new IO extension review
by Domagoj Saric 08 Dec '10

08 Dec '10

Hi everybody, this is my first official Boost review so <insert the usual disclaimer> ;) I'm glad to see that at last more people have joined the discussion... In case some have not noticed, there was a very recent 'pre-discussion' about io_new titled "[gil] New IO release" and can be found here: http://lists.boost.org/Archives/boost/2010/10/index.php http://lists.boost.org/Archives/boost/2010/10/171450.php ...where I've already written (about) my thoughts and objections in detail: http://lists.boost.org/Archives/boost/2010/10/171732.php For the sake of brevity (and tight time management :) I will not repeat all the details here, rather try to reiterate through them briefly (omitting tests, examples and/or detailed argumentation) while perhaps adding some new thoughts... Mateusz, can you please confirm whether this approach (to assume that the "[gil] New IO release" notes and conclusions are part of the final review discussion) is OK or should I somehow repack that discussion into the new one..? ------ What is your evaluation of the design? ------ While the design can be considered an improvement from GIL.IO I nonetheless consider it lacking. As the new interface already constitutes a breaking change, this opportunity could have been used to provide a much more powerful and flexible interface (while still maintaining ease of use). A brief reiteration from "[gil] New IO release", the free function interface is inflexible/weak because it: - makes it difficult or practically impossible to reuse underlying backend instances across calls which, for example, has serious performance implications for ROI based access or when you want to read the image info/metadata before reading the image... - (as is done now) couples the choice of the backend with the choice of the image format (i.e. it makes it much more difficult to use/add alternate backend implementations for various image formats, for example if one wants/has to use LodePNG or GDI+ or ... as a backend) - does not allow access to the underlying backend which is necessary both for faster/easier solving of real world problems (either later found deficiencies in the interface or more complex/unconventional/corner use cases) and a more future-proof design (that can be more easily extended without breaking changes and/or introduction of additional overheads) ------ What is your evaluation of the implementation? ------ Considering that the GIL.IO implementation already has an inefficient implementation (which was even hinted by the "this will be simplified" comments in the code) I would hope io_new to provide a step forward in this regard...unfortunately it turns out it is a big step backward, both in terms of code bloat and code speed (as demonstrated by the tests and in-depth analysis in the "[gil] New IO release" thread)... In fact, the mentioned test practically demonstrates a 'theoretical' effect: on an Intel i5 CPU, with a relatively large cache, io and io2 benefit from being compiled/optimized for speed (as opposed for size) while io_new actually executes slower when compiled for speed (probably because the inherent code size increase/excessive inlining which overflows even a large CPU cache)...this effect was not demonstrated when the same test was run a much weaker Via C7-M CPU (with a much smaller cache)... In addition to efficiency concerns, the io_new implementation (or 'internal design') is also inflexible in certain areas where it causes duplication/repetitive code between different backend wrappers (thus not making it easier to extend with new backends). ------ What is your evaluation of the documentation? ------ Did not build it... ------ What is your evaluation of the potential usefulness of the extensions? ------ A makeover for GIL.IO is long over due and the general ideas that Christian put in io_new are mostly very welcome even though I have serious objections as to how those ideas were actually put in practice... ------ Did you try to use the extensions? ------ Yes, but only JPEG, PNG and TIFF IO extensions (did not try the opencv, sdl and toolbox extensions)... ------ With what compiler? ------ MSVC++ 10.0 ------ Did you have any problems? ------ Yes, for example the broken TIFF reading-with-conversion, Christian did fix it later but the fix seems more like a patch as it demonstrates an inherent inflexibility (mentioned at the end of the implementation section) in the io_new design that requires the backend-wrapper maintainer to provide the (possibly very long) conversion switch cases for each backend... ------ How much effort did you put into your evaluation? ------ As mentioned, I dug only through the core IO extension (and specifically through the LibJPEG, LibPNG and LibTIFF backend wrappers) but the areas I did investigate I examined relatively thoroughly (and over a longer period of time...in parallel, over the many months of development of io2)... ------ Are you knowledgeable about the problem domain? ------ My main use case consists of simple image loading on application startup (for the application skin) and only minor adjustments (like PC to Mac gamma fixup). However, as I was unsatisfied with existing solutions (including the direction in which io_new went) I decided to roll my own solution and for this to get accepted I had to look into and cover all reasonably possible use cases (which included going through the GIL.IO documentation as well as old/previous GIL.IO related discussions). ------ Do you think the extensions should be accepted as a part of Boost.GIL library? ------ (To make it clear) The way they are now - no. However, as mentioned earlier, a makeover of GIL.IO is undoubtedly needed and the work Christian has done so far is truly massive. For example, the properties system could prove to be quite useful (as a C++ abstraction for the various options and metadata specific to each image format) if done right (if not coupled to a particular backend, so that, for example, the PNG properties can equally be used, if supported, with LibPNG, LodePNG, GDI+, WIC ....)... Actually, IMO some of the extensions (like new GIL image/pixel formats) should maybe enter GIL itself, not merely as extensions (this would possibly even make it easier to implement the more complex IO backends/formats, like TIFF, that support those types of images)... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

3 2

Re: [boost] Boost on Sun CC without STLPort
by pfee＠talk21.com 08 Dec '10

08 Dec '10

Beman Dawes wrote: > On Tue, Dec 7, 2010 at 11:12 AM, Dave Abrahams <dave(a)boostpro.com> wrote: >> On Tue, Dec 7, 2010 at 11:07 AM, Dean Michael Berris >> <mikhailberis(a)gmail.com> wrote: >>> Hi Everyone, >>> >>> Is there any specific reason why Boost isn't tested against Sun CC >>> without STLPort -- aside from the obvious reason that there's nobody >>> running the regression tests on that platform? Is it something >>> inherently wrong in Sun's standard library implementation that's >>> preventing Boost from working properly on the Sun compiler? >> >> It used to be wicked noncompliant, to the point where it was a waste >> of time to even try. I'm not sure what the status today, though. > > It is way better than it used to be. My understanding is that in the early days of Sun CC 5.x, the compiler was non-compliant. Over time, the compiler improved, but the libCstd ABI was set in stone. The compiler has become more capable, but the RogueWave derived STL is still configured to be non-compliant in order to maintain the ABI set when the compiler was less capable. I presume backwards compatability was considered more important than standards compliance. Here's an OpenSolaris proposal to change this (not sure of the status of Solaris 11). The RogueWave STL has become the Apache STDCXX project, http://stdcxx.apache.org/. If that becomes the new STL on Solaris, then Boost may be usable with the default compiler and STL configuration. http://arc.opensolaris.org/caselog/PSARC/2008/549/proposal.txt However Boost + SunStudio/libCstd is likely to be non-starter as Boost requires a high level of standards compliance. Even Boost + SunStudio/STLport didn't work for quite some time. Here's a blog I used to follow as SunStudio/STLport approached usability with Boost. The first version that worked out of the box was 1.34.1. http://blogs.sun.com/sga/category/Boost Thanks, Paul

2 1

How to make a soft copy of a temporary Python object inside C++
by Raul Durand 07 Dec '10

07 Dec '10

Hello everybody, Maybe it is obvious but I could not figure out how to solve it yet.. Consider the A and B classes: Class B { public: int func() {return 1; } }; class A { public: void setB(B & b_instance) { b = &b_instance; // if in Python setB is called as: a=A(); a.setB(*B()*) where B() creates a temporary, // the b pointer becomes invalid after setB() function gets out of scope. } B * b; }; BOOST_PYTHON_MODULE(my_module) { _class<B>("B") .def("func",&B::func); _class<A>("A") .def("setB", &A::setB); } The function A::setB sets the b data member of class A. b is a pointer to an object of class B. In Python I can use: a=A() b=B() a.setB(b) that's ok since 'b' exists as long as 'a', which could be dangerous. Things get worse when in Python I write: a=A() a.setB(B()) because the pointer b in class A gets invalid when the setB function gets out of scope. So, how can I avoid Python for destroying the temporary and keep the object alive in C++? Does it have anything to do with the object ownership? Is there a way to change the ownership? Can I make a soft copy of the b_instance object inside the setB function? so it would increase the object counter and keep it alive and consequently the b pointer will not get invalid. I want to avoid making a deep copy. Thanks in advance. Raul Durand

2 3

[assign] operators+= and -= for set/reset bits in std::bitset
by Winkler, Bernd 07 Dec '10

07 Dec '10

Dear All, I was a little bit tired of using string initialization of std::bitset like: bitset<8> flag_pattern(string("00111000")); What I found more readable was this: Bitset<8> flag_pattern; //initialisation to "00000000" flag_pattern += 1,3,4,5; //set bits at indices 1,3,4,5 to true: 01011100 flag_pattern -= 1,3; //set bits at indices 1,3 to false: 00001100 In that way I can specify an easy readable configuration of flags: enum { left, right, center } flag_pattern += left,right; If interest exists I could contribute the respective code for the assign library. Best regards, Bernd P.S. Please let me know if I missed some formal criteria for this post as I am new to this NG

4 3

Re: [boost] [assign] operators+= and -= for set/reset bits instd::bitset
by Winkler, Bernd 07 Dec '10

07 Dec '10

>Doesn't the interpretation of that depend on the endianness of your architechture? I don't know but I can imagine. If so, it would be one more reason to address and/or initialize single or multiple bits using e.g. enum values .. preferably in an easy way like the one shown. Bernd

1 0

[trac] Performance for last week?
by Rene Rivera 07 Dec '10

07 Dec '10

First after disabling the trac source browser for most of the week here's the new breakdown of the top ten sections the web server spent time on (including www.boost.org) total_time = 319654701.643986 43.88 140251178.52 /svn 43.88 140251171.39 /svn/boost 42.47 135748391.81 /svn/boost/!svn 40.86 130621926.05 /svn/boost/!svn/vcc 40.86 130621926.05 /svn/boost/!svn/vcc/default 27.50 87894354.72 /trac 26.23 83846699.34 /trac/boost 14.81 47331832.95 /doc 14.26 45569562.87 /doc/libs 10.90 34846318.37 /style-v2 As you can see trac is no longer at the top of the list. And SVN is taking up almost half the time. Which is to be expected since many SVN interactions take considerable clock time to complete as data is sent to clients. So big questions with respect to last week: * Is trac performance to an "acceptable" point? * Do you miss the trac source browser, and desperately want it back? And now regarding SPAM.. I did some updates of the spam modules that improve overall performance, the dns sub-module was know to cause global trac delays. I was hoping to introduce CAPTCHAs with the updates.. But there was a problem with the one I got yesterday. I'll try a new update tonight and hopefully we can really cut down on the spam once and for all :-) PS. No I haven't looked at what, if anything, needs to get done to reduce the svn times. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

4 3

GIL IO extension review
by Kenny Riddile 06 Dec '10

06 Dec '10

Sorry if this review seems short, but most of my time is spoken for. Still, I think this extension is useful enough that I found time to review it. I've been using the new version of the GIL IO extension for over a year now and am glad to finally see it up for review. I've primarily used it for loading various image formats for use as OpenGL textures. I recently gained some experience with extending the library to support an additional image format (TARGA) as well. - What is your evaluation of the design? My use case for the library is conceptually simple, so I would expect the library to make it simple to accomplish. The provided read_image() and write_view() functions are about as simple an interface as one could expect, but without sacrificing flexibility and extensibility due to the usage of tag dispatching and standard iostreams. As a user, I have no complaints about the design and how it integrates with GIL. - What is your evaluation of the implementation? I hadn't looked at the implementation much prior to recently adding support for reading and writing TARGA images, and my evaluation of the implementation is from that standpoint. The fact that I (of all people) was able to easily add support for a new format without much documentation on the subject suggests that the relevant parts of the implementation are easily understandable. I mostly used the BMP implementation as a reference, and didn't notice anything egregious or suspicious. I have some concerns about the usage of setjmp/longjmp in the PNG and JPEG implementations (honestly I get suspicious any time I see those). I think there was discussion elsewhere about adding additional test cases to exercise the error cases that result in a longjmp so that all of the supported platforms can be verified. I think this is a good idea. Another nitpick that came up when adding TARGA support are the read_int8, read_int16, read_int32, write_int8, etc. member functions of the Device models in io_device.hpp. To me, these names suggest that these functions return and accept signed integers when in reality they return and accept unsigned integers. - What is your evaluation of the documentation? The documentation was sufficient enough for me to quickly figure out how to read and write images from all of the supported formats. The section on extending the library to support new formats was enough to get me started, but I ended up just relying on the existing BMP code as a reference. This suggests that maybe that section of the documentation should be fleshed out a little more. - What is your evaluation of the potential usefulness of the extensions? This new IO extension is extremely useful. It nicely fills huge gaps in the existing IO extension, such as loading from streams instead of only being able to supply a file name. The interface is simple enough to integrate into just about any design, while still providing both flexibility and extensibility. - Did you try to use the extensions? With what compiler? Did you have any problems? I've used the proposed IO extension to read and write BMP, PNG, JPEG, and TARGA files with both MSVC9 and GCC in combination with the last several Boost releases. I had no problems. - Do you think the extensions should be accepted as a part of Boost.GIL library? Yes, provided additional tests are added to exercise currently untested error cases, and they pass on all platforms officially supported by Boost. This extension is just as simple to use as the existing GIL IO extension, yet is better in every way. Therefore, I see no reason not to accept it as a replacement.

2 1

Re: [boost] Partial preprocessing for Fusion, et.al. (was: [netlib] Update: 0.9 will not be header-only)
by Hartmut Kaiser 06 Dec '10

06 Dec '10

> On Sun, Dec 5, 2010 at 2:02 AM, joel falcou <joel.falcou(a)lri.fr> wrote: > > In my own experience, problem lies in Proto/MPL/Fusion preprocessor > > time more than anything else. > > MPL became managable thansk to the preprocessed headers, maybe > > Fusion,Proto and maybe Spirit should do the same > > +1 > > Does anybody have an idea on how this can be done? I seem to recall that > GCC only had options for preprocessing when compiling an object file -- > that would mean for making a .cpp file for each of the headers that need > to be pre-processed independently, running it through the compiler's > preprocessor (or wave) to get the appropriate output. > > Maybe someone already has a script to do that which can be adapted? What everybody is looking for is partial preprocessing, i.e. expansion of only some of the macros. Wave does not directly support this (does any preprocessor?), but you can do is to use #pragmas to enable/disable output generation. This creates the effect of partially expanding only a subset of the input. Here is an example: File: example.hpp: // stuff here will be preprocessed but not be output #if defined(__WAVE__) && defined(CREATE_PREPROCESSED_FILES) #pragma wave option(preserve: 2, line: 1, output: "preprocessed/example.hpp") #endif // stuff here will be preprocessed and written to the file // preprocessed/example.hpp (here: relative to example.hpp) #if defined(__WAVE__) && defined(CREATE_PREPROCESSED_FILES) #pragma wave option(output: null) #endif // stuff here will be preprocessed but not be output File: example.cpp // stuff here will be preprocessed but not be output #include "example.hpp" The crucial trick is to invoke the wave driver with the --output=- (short option: -o-) command line option, which starts off with the output suppressed. Having to add -DCREATE_PREPROCESSED_FILES is obvious. Regards Hartmut --------------- http://boost-spirit.com

2 4

How to correct when Auto-link gets it wrong in VS
by Paul Bergen 06 Dec '10

06 Dec '10

I installed boost both with bjam and with the BoostPro installer, both times with the same option. I specified that it should install as Multi-Threaded Debug DLL. I'm using Visual Studio 2008 EE. I followed the steps here: http://www.boost.org/doc/libs/1_45_0/more/getting_started/windows.html But Visual Studio won't link, it says it can't find: libboost_system-vc90-mt-sgd-1_44.lib, which is because the file really is: boost_system-vc90-mt-gd-1_44.lib According to this page: http://www.boost.org/doc/libs/1_45_0/more/getting_started/windows.html#libr… the problem is that VS is trying to find the static library, although I installed the dynamic one. I can't find in the getting_started where you tell VS which version to use. Thanks.

6 6

[netlib] Update: 0.9 will not be header-only
by Dean Michael Berris 06 Dec '10

06 Dec '10

Hi Everyone, To those who are following the development of cpp-netlib (which shall be submitted for review /soon/ as Boost.Netlib), the current state of 0.9-devel and thus what's going to come out officially as 0.9 in a couple of weeks, will not be header-only. Aside from the obvious reason that the compile-times are starting to become unbearable (>10 minutes to build the whole test suite!!) and after noticing that the intended simplicity of the API with tag-metafunction dispatch is limiting the expressiveness of the HTTP client types, the 0.9 release will be the first release that will require an externally linked-in static library. The biggest culprit at the moment has been the implementation of the URI parser that uses Boost.Spirit Qi and >10 rules in the URI parsing grammar. The URI implementation is really declarative and nicely written (thanks go out to Jeroen Habraken for making that happen). The down-side of this has been the compile times: building the simple HTTP client takes close to one minute on the machine I'm using -- and by moving it to an externally-linked static lib, the compile of the same HTTP client is cut down to 10 seconds. Before you ask if I'm using GCC, the answer is no, I'm using Clang when developing so that I get as much speed as I can when doing the edit-rebuild-test cycle. I've written about what I've been doing and what I'll be doing in my three recent articles at C++ Soup. If you want to get more details, please follow the links below. http://cplusplus-soup.com/2010/12/03/cpp-netlib-moving-away-from-header-onl… http://cplusplus-soup.com/2010/12/02/cpp-netlib-demolition-day/ http://cplusplus-soup.com/2010/12/01/cpp-netlib-reducing-compilation-times/ Have a great weekend everyone, please send your qestions/comments/suggestions over either directly to me or through the various mailing lists (Boost-devel, Boost-users, cpp-netlib-devel). -- Dean Michael Berris deanberris.com

9 11

[Bug Sprint] Status for Sunday, December 5th
by Marshall Clow 05 Dec '10

05 Dec '10

There were only 13 changes to the trac database yesterday - mixed in with a lot of spam [ I'd like to say "13 tickets were changed", but some tickets were changed more than once. ] It's time to ramp it up - today is the last day of the Bug Sprint! In the last bug sprint, we closed almost 200 tickets (not 100 - I misremembered). So far this time, we're down a (net) 13 tickets from the start of the sprint! If you think it's too late to get involved - you're wrong! A couple of notes: 1) Please log into the Trac system before you add/modify a ticket. "Anonymous said:" is hard to follow up. 2) It is perfectly OK to add a comment to a ticket that says "I tested this patch on my system (foo, gcc 1.2.3.4, etc) and it worked fine/didn't work/etc" General information about the bug sprint is here: https://svn.boost.org/trac/boost/wiki/BugSprintNov2010 General information about how the Trac system works is here: https://svn.boost.org/trac/boost/wiki/TicketWorkflow Overall bug count: November 26: 946 November 27: 939 November 28: 930 November 29: 934 (whoops, that's the wrong direction!) November 30: 931 (better, but the delta is too small) December 1: 929 December 2: 930 December 3: 933 (ouch!) December 4: 931 December 5: 934 (ouch, again!) Activities on the trac system yesterday: New tickets 4 Tickets closed 2 Tickets changed 7 bemandawes 3 rleigh@ 2 --others-- 8 Useful reports: https://svn.boost.org/trac/boost/report/1 -- full list of tickets https://svn.boost.org/trac/boost/report/18 -- ticket counts by owner https://svn.boost.org/trac/boost/report/19 -- ticket counts by component https://svn.boost.org/trac/boost/report/20 -- ticket counts by ticket type https://svn.boost.org/trac/boost/report/21 -- ticket counts by milestone -- Marshall

1 0

Re: [boost] [build] bjam in boost/tools/build/v2/test doesn't work
by Jim Bell 04 Dec '10

04 Dec '10

I'm re-posting this (from 11/22). I'd really like to reconcile command-line vs run.py... On 1:59 PM, Vladimir Prus wrote: > > Jim Bell wrote: >> >> Running bjam in boost/tools/build/v2/test doesn't (seem to) run build's >> >> regressions. Instead, I get: >> >> >> >> jamfile.jam:8: in modules.load >> >> rule project-root unknown in module > > You should be using 'python test_all.py'. Running 'bjam' there is not really > > supposed to do anything. Thanks! This works and gives me results like this... unit_tests : FAILED module_actions : PASSED startup_v1 : PASSED ... I see, too, that '--verbose' enables detailed output, from BoostBuild.Tester's docstring (and from trying it). But it says "Note that it does not also enable more verbose build system output like the --verbose command line option does." What does that mean? If I run "python test_all.py --verbose verbose" it doesn't seem to like that (attempts to run verbose.init). Also, I'm seeing a different pass/fail pattern between when I run it like this and when it runs from run.py. I'm running it with mingw-4.4.3 on the same trunk revision that the "MinGW-32 jc-bell.com" regression has reported. Picking "absolute_sources", for example, I see absolute_sources : PASSED But the regression shows it failed. How do I reconcile these?

1 0

[Bug Sprint] Status for Saturday, December 4th
by Marshall Clow 04 Dec '10

04 Dec '10

There were only 6 changes to the trac database yesterday - mixed in with a lot of spam [ I'd like to say "6 tickets were changed", but some tickets were changed more than once. ] The decrease in activity continues. It's time to ramp it up - there are only three more days in the Bug Sprint. In the last bug sprint, we closed almost 200 tickets (not 100 - I misremembered). So far this time, we're down a (net) 15 tickets from the start of the sprint! If you think it's too late to get involved - you're wrong! A couple of notes: 1) Please log into the Trac system before you add/modify a ticket. "Anonymous said:" is hard to follow up. 2) It is perfectly OK to add a comment to a ticket that says "I tested this patch on my system (foo, gcc 1.2.3.4, etc) and it worked fine/didn't work/etc" General information about the bug sprint is here: https://svn.boost.org/trac/boost/wiki/BugSprintNov2010 General information about how the Trac system works is here: https://svn.boost.org/trac/boost/wiki/TicketWorkflow Overall bug count: November 26: 946 November 27: 939 November 28: 930 November 29: 934 (whoops, that's the wrong direction!) November 30: 931 (better, but the delta is too small) December 1: 929 December 2: 930 December 3: 933 (ouch!) December 4: 931 Activities on the trac system yesterday: bemandawes 2 anonymous 1 ramey 1 degtyariov.a@ 1 m_fedyszyn 1 --others-- 0 Useful reports: https://svn.boost.org/trac/boost/report/1 -- full list of tickets https://svn.boost.org/trac/boost/report/18 -- ticket counts by owner https://svn.boost.org/trac/boost/report/19 -- ticket counts by component https://svn.boost.org/trac/boost/report/20 -- ticket counts by ticket type https://svn.boost.org/trac/boost/report/21 -- ticket counts by milestone

2 1

[trac] WARNING: Anonymous ticket creation disabled..
by Rene Rivera 04 Dec '10

04 Dec '10

Because of the current influx of SPAM tickets in trac, I've temporarily disabled creating tickets by "anonymous" users. So if you get hit by this either: *** Make sure you are logged in before creating a ticket. *** Or.. *** Fill some information for the user in trac. *** Hopefully after the holidays the SPAM traffic will die down, it usually does, and perhaps I'll turn the anon tickets back on. And sorry for the abrupt change.. But I was getting really tired of deleting tickets all day yesterday and today. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

2 2

Re: [boost] Library for configuration file parsing
by Pierre Morcello 04 Dec '10

04 Dec '10

Hello Denis, >>> - I can not imagine a more simple interface... :-) If you want to go 'macro', it is certainly possible : Example 1.1 : BOOST_CONFIGURATOR_OPTION( UdpHost , "System::Server::UdpHost" ); BOOST_CONFIGURATOR_OPTION( UdpPort , "System::Server::UdpHost" ); Example 1.2 : class SomeConfigOptions { public: int updport; Ip updhost; }; BOOST_CONFIGURATOR_OPTION( SomeConfigOptions, (updport, "System::UdpServer::Port") (udphost, "System::UdpServer::Host") ); then, after parsing all wanted files : SomeConfigOptions myConfig; if( !conf.get(myConfig) ) { return error; } >>> What do you think about it? This need real life experience, to check what works and what does not. If you have 4 levels in the parse tree, and 250 values, you will have to rewrite many times the types, to declare them and to access them at the same level. After such tests, you can see what works and what does not work. The user will also have to create lots of types in a namespace with the macro you provide. I consider that configuration files often reflect the c++ tree of classes. I doubt you will want to use something like System::UdpServer::Host in the config file, when you only have 1 int in your program. I consider it is easier to have a c++ classes tree like : Example 1.3 struct SoundConfiguration { int option1; double option2; }; // here a macro to declare SoundConfiguration & its attributes... BOOST_CONFIGURATOR_OPTION( SoundConfiguration, (option1) (option2) ); struct SoundConfigurations { double volume; std::vector<SoundConfiguration> sounds; }; // here a macro to declare SoundConfigurations & its attributes... BOOST_CONFIGURATOR_OPTION( SoundConfigurations, (volume) (sounds) ); to describe the design of your config file. That way : a/ you can manipulate compiler-checked information, without creating many types. b/ You don't need to repeat the "System::Sound" thing everywhere. c/ The 'designation string' could be optional though (ex: ((sounds)("sons")) for a french guy). d/ If I want the configurator to check the Ip, I create a "Ip myIp" attribute. If I want to check the Ip myself, I create a "std::string myIp" attribute. I suppose the best 'configurator' system would support both ways. 1/ allow to serialize and deserialise from a human-readable/editable subsection of the file (like a deferred boost.serialize) 2/ allow to use a specific identifier like "System::Udp::Server" to retrieve some other values. Either from the config line or a file. Boost.PP/boost.spirit/'boost.serialization + boost.xpressiv' offer means to do that easily. This is at least what comes to me when I read the rationnale you wrote : " 1. obtaining options from configuration file, 2. check correctness (in all senses of this word) of obtained options, 3. storing options, 4. issuance of the options values on demand. " > <System> > <UdpServer> > Host = 127.0.0.1 > Port = 100 > </UdpServer> > </System> I think writing the tag name twice is harder for humans. Example 2.1 System { UpdServer { Host = 127.0.0.1 Port = 127.0.0.1 } } Or even python-like : Example 2.2 System UpdServer Host = 127.0.0.1 Port = 127.0.0.1 Anyway, this need real life experience, to see what works and what does not(and more tests & examples ! Good that you have already added some in the sandbox!). Just my point of view. Best regards, Pierre Morcello

1 0

Library for configuration file parsing
by Denis Shevchenko 04 Dec '10

04 Dec '10

Hi all! Is there any interest in a library for configuration file parsing? I know there is a good library Program_options, but it supports (asit is written in the documentation) "parsing of simple INI-like configuration files". If all you need for configure your programs is INI-like files - use Program_options and forget about this letter. But if you want to use a more complex configuration files, you may be interested in my library, Configurator. simplest.conf: Host = 127.0.0.1 Code for work with this config: cf::configurator configurator; configurator.add_option( "Host" ); configurator.parse( "/some/path/to/simplest.conf" ); std::cout << "Value of host: " << configurator.get_value( "Host" )<< std::endl; Features - Header-only - Allows to set option's default value or/and necessity. - Allows to use arbitrary nesting of sections. - Provides "standard" checks of value's semantic, like correct path, IP validity, email correctness, etc. - Provides "extended" checks of value's semantic, like time period and file size. - Provides common checks of options and sections, like duplication, incorrection, etc. - Supports single-line and multi-line comments (in C++ style). - Allow to register values with multi-values. - Allows to set another "name-value" separator (including space symbol), instead default '='.

23 72