February 2011 - Boost - lists.preview.boost.org

[pool][hit-squad] Kudos! Updates?
by Jim Bell 12 Feb '11

12 Feb '11

Looking at the commit log (/sandbox/guild/pool), I see commits by pbristow, ktchan, danieljames, marshall, and steven_watanabe. Thanks for your efforts! Kudos to John Maddock for the idea and impetus. How's it going? Road-blocks? Show-stoppers? Thoughts? Need more hands/eyeballs/brains/hours-in-the-day? Best, -Jim

2 1

[integer][type_traits] invaid values for integer_traits<boost::intmax_t>
by Vicente Botet 12 Feb '11

12 Feb '11

Hi, the following has different behavior depending on whether <climits> in included in gcc-4.5 #include <climits> #include <boost/mpl/assert.hpp> #include <boost/mpl/bool.hpp> #include <boost/integer_traits.hpp> #include <boost/type_traits/integral_constant.hpp> #include <boost/cstdint.hpp> BOOST_MPL_ASSERT_MSG(false, BOOST_RATIO_OVERFLOW_IN_MUL, ( boost::integral_constant<boost::intmax_t,boost::integer_traits<boost::intmax_t>::const_min>, boost::integral_constant<boost::intmax_t,boost::integer_traits<boost::intmax_t>::const_max> )); With error: no matching function for call to 'assertion_failed(mpl_::failed************ (BOOST_RATIO_OVERFLOW_IN_MUL::************)(boost::integral_constant<long long int, -0x8000000000000000ll>, boost::integral_constant<long long int, 0x7fffffffffffffffll>))' and without error: no matching function for call to 'assertion_failed(mpl_::failed************ (BOOST_RATIO_OVERFLOW_IN_MUL::************)(boost::integral_constant<long long int, 128ll>, boost::integral_constant<long long int, -0x000000081ll>))' As you ca see the const_min and cont_max values are not correct in the last case. I was wondering if the <climits> file must be included by <boost/integer_traits.hpp> or <boost/cstdint.hpp>. Comments? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/integer-type-traits-invaid-values-for-in… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 4

[filesystem] Should recursive_directory_iterator follow directory symlinks by default?
by Beman Dawes 12 Feb '11

12 Feb '11

recursive_directory_iterator currently always follows directory symlinks It seems to me that whether or not this behavior is desirable is application dependent. Thus I'd like to add an option to either following directory symlinks or not. Which should the default be? Following symlinks by default avoids breaking existing code, so that's my mild preference, but I'm wondering if anyone has a strong argument for not following directory symlinks by default? --Beman PS: Windows identifies symlinks to directories, so it is possible to have a dangling symlink to a non-existent directory. recursive_directory_iterator currently tries to recurse into the non-existent directory. That's just a bug and I'm about to fix it.

6 8

[UTF String] Feedback on UTF String library, please
by Chad Nelson 11 Feb '11

11 Feb '11

I reiterate my request from this message <http://permalink.gmane.org/gmane.comp.lib.boost.devel/214601>: would those interested in the UTF String library please comment on the new version? Specifically, I'm looking for feedback on: * Technical opinions on the design; * How useful it would be to you as-is; * What would make it more useful to you. The code can be found here: <http://www.oakcircle.com/toolkit.html>. Thanks in advance. -- Chad Nelson Oak Circle Software, Inc. * * *

4 5

[range] A macro to disable iterator_range io
by Samuel Debionne 11 Feb '11

11 Feb '11

Hello, would it be possible to add a configuration macro in iterator_range.hpp like : #if !defined(BOOST_ITERATOR_RANGE_NO_IO) #include "boost/range/iterator_range_io.hpp" #endif so that custom versions of the insertion operator for iterator_range won't clash with the one provided by boost ? We could include only the core include (iterator_range_core.hpp) but other boost libraries seems to include iterator_range.hpp which include the io header... Samuel

1 0

[announce] mirror-lib 0.5.4 released
by Matus Chochlik 11 Feb '11

11 Feb '11

Dear list, I would like to announce that a new version of the Mirror reflection library is available for download from SourceForge: http://sourceforge.net/projects/mirror-lib/files/mirror-lib-0.5.4/ The documentation is hosted online here: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/ To get an idea what the library can do you can look at the examples: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/examples.html Just to mention some of the more important changes since the last announce: 1) The factory generator now fully supports enumerated types in both Mirror (compile-time reflection) and Lagoon (run-time layer) 2) The factory generator now supports (container) types which have a constructor taking a pair of forward iterators. This does not work with the run-time layer yet. See for example: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/mirror_2example_2factor… Some screenshots of input dialogs generated by the factory generator utility can be found here: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/mirror__wx__gui__fact__… NOTE: Since Mirror uses C++1x AFAIK it will currently compile only with gcc (tested with gcc 4.5.1 and 4.5.2 64-bit on Linux and 4.5.1 on cywin) Questions, comments, feedback or potential contributions are always appreciated. Best regards, Matus

1 0

TTI library updated in the sandbox
by Edward Diener 10 Feb '11

10 Feb '11

I have updated the TTI library in the sandbox 'tti' directory to version 1.1. The TTI library, which is an abbreviation for the 'Type Traits Introspection' library, allows a programmer to introspect at compile time the inner elements of a C++ type. The introspection process depends on specifying the name of the inner element by different macros for different types of elements, and then using a generated metafunction to determine whether that element exists within the enclosing type. The inner elements which can be introspected are type, class template, member data, member function, static member data, and static member function. Features of the update include support for the older gcc 3.4.2 and 3.4.5, finer-grained introspection for the basic macro metafunctions, documentation examples, better and tighter design, and better use of Boost MPL methodology ( metafunctions are now passed as lambda expressions and metafunction globbing has been removed from the two metafunctions where it previously existed ). You can view the changes in the History section of the documentation. The TTI library is based on the type_traits_ext portion of the Concept Traits Library, with improvements and additions, and also lifts functionality, for the purposes of orthogonality, from Boost.MPL regarding introspection of types and templates. The purpose of the library is to provide a consistent set of interfaces for doing compile-time introspection of a type, which other template metaprogrammers can use in their code. If you are at all interested in compile-time introspection of types, please take a look at the functionality of this library. There is a readme.txt in the top-level sandbox tti directory, for anyone browsing the sandbox for interesting libraries, which basically replicates what is written here. There is a build.txt file in the doc subdirectory for building the documentation and running the tests. The documentation is also included as part of the sandbox files for those who can not build the docs. The library has been tested and works with gcc 3.4.2, 3.4.5, 4.3.0, 4.4.0, 4.5.0-1, 4.5.2-1 and VC++ 8.0, 9.0, 10.0. It may also work with other compilers. Questions, comments, suggestions, and bug reports are all welcome.

4 9

[random] [tr1] xor_combine min/max
by Steven Watanabe 10 Feb '11

10 Feb '11

AMDG Currently these are implemented as std::min(_rng1.min(), _rng2.min()) and std::max(_rng1.max(), _rng2.max()). This is obviously wrong, although it happens to work for taus88 which is the only use of xor_combine right now. I looked at boost/tr1/random.hpp and it has a more complex implementation. Unfortunately, I don't think it's completely right either as computes min/max(x ^ y) where (_rng1.min() << s1) <= x <= (_rng1.max() << s1) and (_rng2.min() << s2) <= y <= (_rng2.max() << s2) Alas, when a random value is shifted left, the low order bits are always zero, so this algorithm may overestimate the bounds. Also, when the shift causes either base engine to lose bits, the algorithm forces the max to std::numeric_limits::max. This is clearly wrong if _rng1.min/max = [0x80000000, 0x800000FF], s1 = 1, since this ends up being equivalent to [0, 0xFF]. So, I have a couple of options a) Require the base ranges to be something sane like [0, 2^k-1]. The advantage of this is that it's easy, and it's automatically guaranteed that the combined engine is equidistributed if the base engines are. b) Somehow make it work. It would be nice if it were fully general, but working out the bit-twiddling for this will be a pain and the code will probably end up unintelligible. I'd rather not do this unless it's really needed. Are there any algorithms that need to xor numbers from non power-of-two ranges? For example, is xoring the outputs of two LCG's ever useful? Thoughts? In Christ, Steven Watanabe

1 0

[fiber] mini review - symmetric a. asymmetric continuation
by Oliver Kowalke 10 Feb '11

10 Feb '11

I've uploaded a new version to boost vault (section 'Concurrent Programming') which contains to fiber implementations - sym_fiber (symmetric fiber/continuation) and asym_fiber (asymmetric fiber/continuation). I'd like to ask for a mini review in order to get a bit feedback if the design is appropriate. Oliver

3 7

Re: [boost] Patch to make code_converter flushable
by Eddie Carle 10 Feb '11

10 Feb '11

On Thu, 03 Feb 2011 17:35:56 -0700, Eddie Carle wrote: > I've attached a little patch that makes iostreams::code_converter > flushable. It seems like it really should be. Is there any chance > someone could look at this? I've included some test code as well that > outputs the following. Is anyone actually interested in this? I've been working on moving the fastcgi++ library over to boost iostreams but unless this patch is applied I cannot actually do so. One cannot derive from iostreams::code_converter to make it flushable because the necessary components are private and not protected. Is there any chance whatsoever of getting this patch applied or am I just wasting my time? -- Eddie Carle

3 4