November 2009 - Boost - lists.preview.boost.org

[shared_ptr] Set pointer to null
by Mateusz Loskot 09 Nov '09

09 Nov '09

Hi, I'd like to make a custom deleter resetting pointer to 0 or other value (e.g. for debugging purposes) after resource has been deallocated. Would anyone suggest better option to this presented below? struct DeleterT { void operator()(::T* ptr) { ::DestroyT(ptr); // uses Visual C++ specific integer type *reinterpret_cast<__int64*>(&ptr) = 0; } }; Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

[iostreams] building zlib from source
by Vladimir Prus 09 Nov '09

09 Nov '09

I am working on improving detection of external dependencies (for 1.42), and I've noticed that the iostreams library is rather smart when it comes to building zlib (and bz2). It allows the user to specify either: - location of headers and libraries files, or - location of sources for zlib In the latter case, the sources will be compiled automatically. How important is the second use case? It's not very hard to support, and appears handy for Windows users, but if in practice, nobody cares, I can spend the time on other matters. Thanks, Volodya

2 3

[thread] Is interrupting a non boost.thread possible?
by Christoph Mathys 09 Nov '09

09 Nov '09

Hello I've a question about boost.threads: Is it possible to interrupt a thread for which I don't have a thread-object but which is using boost synchronization primitives (mutex, condition)? Thanks! Christoph

2 1

[1.41.0] Beta 2 plans
by Beman Dawes 08 Nov '09

08 Nov '09

Due to the issues exposed in the "Official warnings policy?" thread, there will be a second 1.41.0 beta, tentatively scheduled for Sunday, November 15th. Until Saturday, November 14th, the release branch is open for merges of low-risk bug fixes. In particular, fixes that clear compiler warnings are encouraged. Please do, however, make sure any changes are stable on trunk before merging them to release. I'll be traveling until Monday, with little or no email connectivity. So if questions arise, it would be great if the other release managers could step in with responses. Thanks, --Beman

5 5

ppc64 and OSX Snow Leopard
by Vladimir Prus 08 Nov '09

08 Nov '09

Folks, it was reported that in Snow Leopard, Apple has removed support for ppc64, and folks trying to use that receive fairly obscure errors. Some of Boost users were already confused by this. Now, this is of course more like Apple's problem, but here's a patch, against current trunk, to do a nice diagnostic of this in Boost.Build. The intention is that if you try to build just ppc64, or a two-way fat binary including ppc64 you get an error message, and if you try tobuild 4-way fat binary, ppc64 is skipped and you get 3-way binary. Can some of OSX users apply this patch to trunk and give it a try? If it works, I would like to merge to release branch. Thanks, Volodya

2 1

[1.41.0] Beta 1 release candidate
by Beman Dawes 07 Nov '09

07 Nov '09

1.41.0 beta 1 release candidates are available at http://boost.cowic.de/rc/ Before pushing the beta out to SourceForge, I'd appreciate it if several people would try the release candidate and report success or problems. Thanks, --Beman

16 38

compile problem with thread without rvalue references
by Bob Walters 07 Nov '09

07 Nov '09

I've just attempted a build of the current (1_40_0) boost distribution on a Solaris 10 machine, using the SunStudio12 compiler (cc). There seems to be a problem with boost::thread which is related to this compiler's lack of rvalue references. My build process has been: tar xzf boost_1_40_0.tgz cd boost_1_40_0 export BOOST_ROOT=`pwd` ./bootstrap.sh ./bjam toolset=sun address-model=64 The error I'm receiving: "./boost/thread/detail/thread.hpp", line 344: Error: boost::thread::thread(boost ::thread&) is not accessible from boost::move(boost::detail::thread_move_t<boost ::thread>). 1 Error(s) detected. "CC" -library=stlport4 -xO4 -mt -erroff=%none -m64 -KPIC -DBOOST_ALL_NO_LIB= 1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DNDEBUG -I"." -c -o "bin.v2/l ibs/thread/build/sun/release/address-model-64/stdlib-sun-stlport/threading-multi /pthread/thread.o" "libs/thread/src/pthread/thread.cpp" move() seems to rely on a copy constructor for its returned thread when rvalue references aren't supported. There is no such constructor. Aside from changing compilers, is there any work around for this?

1 0

[system][filesystem v3] Question about error_code arguments
by Beman Dawes 07 Nov '09

07 Nov '09

A POSIX sub-group is looking at C++ bindings for POSIX. They are talking about a filesystem library binding at least loosely based on Boost.System, Boost.Filesystem, and C++ TR2. In looking at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2838.html, "Library Support for Hybrid Error Handling (Rev 2)", they are concerned about specifying hybrid error handling like this: void f(error_code& ec=throws()); They would rather see it specified like this: void f(error_code* ec=0); One particular concern is that as currently worded, the N2838 proposal requires throws() return a null reference, which they see as relying on undefined behavior. I wasn't at the meeting where the LWG asked that a null reference be mandated; my reading of the standard is that it is unclear if returning a null reference is or isn't undefined behavior. Some of the core folks seem to think it is undefined, but compilers accept it. Although the reference form is usual for C++, the use of anything other than the default is limited, and usually in low-level code at that. Although I could personally live with either form, I'm leaning slightly toward the pointer form. Regardless, I'd like to hear Boosters views on the two interfaces above. Which do you prefer? Why? --Beman

24 102

[wave][function] Suppressing gcc-4.4.1 warnings
by John Maddock 07 Nov '09

07 Nov '09

Looks like the new type-punning warnings from gcc-4.4.1 are false positives (but I'd like someone else to confirm that!). The fixes below illustrate how to suppress them simply by declaring a temporary variable. HTH, John. Index: boost/wave/util/flex_string.hpp =================================================================== --- boost/wave/util/flex_string.hpp (revision 57230) +++ boost/wave/util/flex_string.hpp (working copy) @@ -1211,7 +1211,10 @@ }; Storage& Data() const - { return *reinterpret_cast<Storage*>(buf_); } + { + Storage* p = reinterpret_cast<Storage*>(buf_); + return *p; + } RefCountType GetRefs() const { Index: boost/function/function_base.hpp =================================================================== --- boost/function/function_base.hpp (revision 57230) +++ boost/function/function_base.hpp (working copy) @@ -316,11 +316,13 @@ new ((void*)&out_buffer.data) functor_type(*in_functor); if (op == move_functor_tag) { - reinterpret_cast<functor_type*>(&in_buffer.data)->~Functor(); + functor_type* f = reinterpret_cast<functor_type*>(&in_buffer.data); + f->~Functor(); } } else if (op == destroy_functor_tag) { // Some compilers (Borland, vc6, ...) are unhappy with ~functor_type. - reinterpret_cast<functor_type*>(&out_buffer.data)->~Functor(); + functor_type* f = reinterpret_cast<functor_type*>(&out_buffer.data); + f->~Functor(); } else if (op == check_functor_type_tag) { const BOOST_FUNCTION_STD_NS::type_info& check_type = *out_buffer.type.type;

6 9

[Boost] Introduction of numeric_adaptor
by Bruno Lalande 07 Nov '09

07 Nov '09

Hi, I would like to introduce the numeric_adaptor library that Barend and I have developed to address a recurring problem: integration of big numbers. We already talked about it in the past, when discussions about geometry would lead to robustness. We're introducing it now because of the upcoming formal review of GGL. The purpose of this library is to turn big-numbers proposed by the most well-known big number libraries into value-types, (almost) usable like any number. This way, a library developer who has a robustness sensible function to write can take numbers as template parameters, and use them in such a way that they can be a fundamental type or one of the value-types provided by numeric_adaptor. This is basically done by: - defining in all the big-number types all the operators needed to manipulate them like fundamental types - defining some free functions in the boost namespace for other operations (sin, cos, hypot, conversions...), which have an default overload for fundamental types and a specific overload for each big-number type proposed Example: template <class T> T my_robustness_sensitive_function(T value) { value /= 2; T value2 = boost::to<T>("123.0123456789"); value += boost::sqrt(value2); return value; }; This function is numeric_adaptor-ready. If T is a fundamental type, boost::to() will forward to boost::lexical_cast and boost::sqrt() will forward to std::sqrt(). If T is one of the big number types provided by the library, specific overloads will be used. The precision of the function will thus entirely depend on the type passed. If the user chooses to sacrifice precision and use fundamental types, there won't be any run-time overhead. If the user wants something more precise and uses a big-number type, the precision of the result will be the one of the chosen type. The library is extensible. Anyone can add a new big number type with all needed operators, and overload the free functions (or specialize a dedicated traits class - see boost::to()). Note: For conversions, we would have liked to extend boost::lexical_cast directly, but the library is not designed in that sense. That's why we wrapped it into a boost::to() function which is explicitly designed to be extended, via traits. Last week on this list list a generic convert_to was discussed and that system could be used alternatively. The library is in the Boost sandbox: https://svn.boost.org/svn/boost/sandbox/numeric_adaptor/ The library currently proposes 2 big number types: CLN and GMP. This is not a formal review request, rather a preview and a reference that we will possibly use during the review of GGL. However, we would really like to have your feedback and to know if such a library would make sense. Regards Bruno

7 13