- Boost - lists.boost.org

Boost
by Enrique Nieloud 02 Mar '10

02 Mar '10

Hi, I just wanted to report that the following two links are broken: boost/gil/extension/numeric/sampler.hpp boost/gil/extension/numeric/resample.hpp In the file: http://www.boost.org/doc/libs/1_42_0/libs/gil/example/resize.cpp thanks, - Enrique

3 2

[iostreams][patch] position_to_offset() is broken for Microsoft Visual C++/Dinkumware
by Sylvester-Bradley, Gareth 02 Mar '10

02 Mar '10

The recent work on Boost.Iostreams by Richard Smith and Daniel James has really improved this library. Thanks guys; this kind of maintenance is really appreciated. I have found a bug in position_to_offset() on Microsoft Visual C++/Dinkumware demonstrated by the following test app - #include <iostream> #include <boost/iostreams/positioning.hpp> int main( int, char*[] ) { const boost::int64_t twoGB = 2 << 30; std::streampos pos = boost::iostreams::offset_to_position( twoGB ); pos -= 2; if ( twoGB - 2 != boost::iostreams::position_to_offset( pos ) ) { std::cout << "Failed!" << std::endl; return -1; } return 0; } This has the potential to affect many parts of Boost.Iostreams but in particular it means the "small seeks optimization" in indirect_streambuf.hpp is broken. I believe this is resolved by the following patch to boost/iostreams/positioning.hpp. 105,106c105,106 < static_cast<stream_offset>(static_cast<std::streamoff>(pos)) - < static_cast<stream_offset>(_FPOSOFF(streampos_to_fpos_t(pos))); --- > static_cast<stream_offset>(static_cast<std::streamoff>(pos) - > _FPOSOFF(streampos_to_fpos_t(pos))); Raised on Trac: https://svn.boost.org/trac/boost/ticket/3969 Best regards, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards

1 0

Boost_Test: Initialize fixture only once
by Dmytro Ovdiienko 02 Mar '10

02 Mar '10

Hello All, I have a question about boost test. Please help. I have set of test_suites. Every test_suite consists of a bunch of test_cases. Every test case should be initialized before execution. So, I created Fixture for every test_suite. The problem is Fixture initialization takes a lot of time and boost creates it for every test_case (not for every test_suite) How to solve this? Best regards. Dima

3 5

[iostreams] array and gzip_decompressor
by Nikolay Mladenov 01 Mar '10

01 Mar '10

Recently I came back to a source written some time ago, that was running then but it is not compiling now. the failing snippet is: typedef boost::iostreams::composite<boost::iostreams::gzip_decompressor, boost::iostreams::array_source> array_gzip_decompressor; boost::iostreams::gzip_decompressor filter; boost::iostreams::array_source source(&_storage[0], _storage.size()); array_gzip_decompressor dev(filter,source); boost::iostreams::stream_buffer<array_gzip_decompressor> ibuf(dev); the error is: > boost\iostreams\read.hpp(191) : error C2039: 'putback' : is not a member of 'boost::iostreams::detail::direct_adapter<Direct>' > with [ Direct=boost::iostreams::array_source ] It seems to me that gzip_decompressor requires peekable source, but array_source is not peekable. Is there another way I should be creating gzipped stream into memory? Or maybe the arrays could be made peekable? Thanks in advance, Nikolay Mladenov

3 5

boost::optional<void>
by Daniel Larimer 01 Mar '10

01 Mar '10

I am writing some generic code and would like to handle "all values" the same way; however, I keep running into the problem of return void return types that need "special treatment". There is nothing I can do about it most of the time except template specialization. That said, it would be helpful if boost::optional<void> could have some sensible default implementation where it acts more or less like a boolean. As it is, I will probably provide my own specialization of boost::optional to simplify my templates. Any thoughts on this? Dan

4 4

[ITL][Review] A late mini review
by Thomas Klimpel 01 Mar '10

01 Mar '10

> Please always state in your review, whether you think the > library should be accepted as a Boost library. ITL should be accepted as a Boost library. > - What is your evaluation of the design? I haven't spend sufficient time reviewing the library to be able to judge the design. At least, I haven't seen any obvious flaws during my short review. > - What is your evaluation of the implementation? I took a cursory look at all source (header) files, and they look nicely written. I took a cursory look at the directory structure, to verify that it follows boost conventions. It does so in general, but I was surprised to find a "libs/itl/build" folder, since I "know" that ITL is a headers only library. The content of the build folder also didn't make me happy (it's extremely "unportable"), but this is a completely different topic that has nothing to do with this specific library. The template meta programming in boost/itl/type_traits/* could follow MPL conventions more closely. > - What is your evaluation of the documentation? The documentation is nicely written. However, please don't invent new words like "aggrovering" or "unon". Please also try to avoid changing the meaning of existing words like "neutron". > - What is your evaluation of the potential usefulness of the library? The need to work with "interval sets" arises sufficiently frequently in "time based" and "geometry based" problem domains to warrant a library dedicated especially to this problem domain. (In my review of Boost.Polygon, I pointed out that interval set concepts were missing.) I have to admit that I haven't spend sufficient time evaluating ITL to be able to judge whether ITL is able to handle all these needs. > - Did you try to use the library? With what compiler? Did you have any problems? No, I didn't try to use the library. > - How much effort did you put into your evaluation? > A glance? A quick reading? In-depth study? Some month ago, I read through the documentation just for the pleasure it gave me, pondered a bit about the concept and looked at the BoostCon2009 slide show. I was certainly planning to do a proper review during the review period, but I was (and still am) occupied with other things. What I've done now while writing this review was just a glance. > - Are you knowledgeable about the problem domain? This is not important in this case, since I haven't spend enough time for the review anyway. Regards, Thomas P.S.: As I guessed from recent experience, the review period has just been extended. However, I decided to submit this mini review nevertheless. I may have a look at "I have to admit that I haven't spend sufficient time evaluating ITL to be able to judge whether ITL is able to handle all these needs." with respect to the issue raised by Phil Endecott in http://lists.boost.org/Archives/boost/2010/02/162198.php (and write about it in case I can make up my own opinion), because this seems to be an interesting question. Even so I want to thank Phil Endecott for his courage to bring up this issue, and I guess that he is right (in a certain sense), I think it is wiser to base my review only on my personal experiences and not on my judgment of whether Phil is right or wrong with respect to this issue.

2 1

[numeric][intervall] msvc_rounding_control.hpp broken in 64 bit build.
by Juergen Hunold 01 Mar '10

01 Mar '10

Hi ! boost/numeric/interval/detail/msvc_rounding_control.hpp does not compile in x64 (64bit) build with (at least) msvc-9 The offending commit is: ------------------------------------------------------------------------ r59350 | marshall | 2010-01-29 19:01:34 +0100 (Fri, 29 Jan 2010) | 1 line Applied patches to fix #2512 and #2513 ------------------------------------------------------------------------ This does not show up in regression test because we don't have a test runner running a 64bit version of msvc. The compiler bails out on the x86 inline assembler introduced in that commit when running in 64bit mode. The simple patch is to fall back to the old behaviour using "rint" for target "x64": Index: msvc_rounding_control.hpp =================================================================== --- msvc_rounding_control.hpp (revision 59697) +++ msvc_rounding_control.hpp (working copy) @@ -25,7 +25,7 @@ namespace interval_lib { namespace detail { -#if BOOST_MSVC < 1400 +#if BOOST_MSVC < 1400 || defined(WIN64) extern "C" { double rint(double); } #else inline double rint(double x) I can apply this if necessary. Tested with msvc-9.0 I have not looked into the referenced tickets. Any (better) ideas ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

ptr_container move support
by Zachary Turner 01 Mar '10

01 Mar '10

The collections in ptr_container don't seem to support move constructors. All the recent compilers support r-value refs, has there been any discussion of adding support for this? Zach

2 1

[Serialization] extended_type_info.hpp
by fab 01 Mar '10

01 Mar '10

Hi, With boost 1.42.0, when I use BOOST_CLASS_EXPORT, I always need to include extended_type_info.hpp to resolve this error : xxx.hpp:153: error: 'guid_defined' is not a template xxx.hpp:153: error: explicit specialization of non-template 'boost::serialization::guid_defined' xxx.hpp:153: error: expected initializer before '<' token xxx.hpp:153: warning: 'boost::archive::detail::<unnamed>::init_guid<MyClass>::g' defined but not used Maybe extended_type_info.hpp can be included in export.hpp ? Fabien Castan

4 5

Setting up a test suite
by Marshall Clow 28 Feb '10

28 Feb '10

I've got two implementations of the same functionality I want to compare with Boost.Test. One's in C++ (natch), the other in Python. Currently, they're packaged as tools that take a file as a parameter, and write results to stdout. Call them "dumpinfo.cpp" and "dumpinfo.py". How would I use Boost.Test to compare the output of these tools for a selection of sample tests? Conceptually, I would do: g++ -o dumpInfo dumpInfo.cpp ./dumpInfo testFile > /tmp/c.out python dumpInfo.py testFile > /tmp/py.out diff -q /tmp/c.out /tmp/py.out But how to do this using Boost.Test? Notes: * I have several (many) test files. It would be nice to list these files in a Jamfile. * There are a couple bugs in the Python packages I am using. I need to mark some of them as "expected failures" Thanks in advance! -- Marshall

1 0