- Boost - lists.boost.org

Iterators Must Go (Ahead)
by Andrei Alexandrescu 10 Sep '09

10 Sep '09

Hello, I wrote an article about D's ranges, contrasting them to other iteration idioms. Those who'd be interested in reviewing the article, please send me email. (I may not be able to reply to all requests.) Bear in mind that the article is rather long - about the size of two usual magazine articles. Thanks, Andrei

7 6

[unordered] please don't allocate memory in the default constructor
by Thorsten Ottosen 10 Sep '09

10 Sep '09

Hi Jeremy, I think this a really bad idea to allocate in the default construtor. The user can always call rehash() on the empty container, just like when we call reserve() for vector. Thanks -Thorsten

5 8

[PropertyTree] Help tracking down test failure.
by Sebastian Redl 10 Sep '09

10 Sep '09

Hi, If you look at the PTree regression results: http://www.boost.org/development/tests/trunk/developer/property_tree.html you'll see that the test_property_tree test currently fails on a log of platforms, especially Darwin. An assertion fails. Since I cannot reproduce the error on any of my systems, could someone who can please send me a stack trace, and perhaps a debug print of the two objects involved? Here's the test output of one runner: http://www.boost.org/development/tests/trunk/developer/output/minion-mpi-bo… I'd like the debug representations of 'this' and 'o', please. Thank you, Sebastian

1 1

[mpl] ForwardIterator concept recursion
by Marcin Zalewski 10 Sep '09

10 Sep '09

I have been trying to implement a concept for mpl ForwardSequence, and besides the lack of const expr requirements in the latest version of concepts I have stumbled across the problem of concept recursion. One example of such recursion is the ForwardIterator [1] concept. The requirement on the next<i>::type type is that it must be a ForwardIterator. One could try to write a concept like that: concept ForwardIteratorStatic<typename I> { typename deref; typename next; requires ForwardIteratorStatic<next>; } But for the above concept, the ConceptGCC compiler gives an error. Also, this should not compile according to the latest concepts proposal that states that a concept is not defined until the closing brace of the concept body. As for now, I think that one can try to apply technique described by Doug [2]: concept IteratorStatic<typename I> { } concept ForwardIteratorStatic<typename I> : IteratorStatic<I> { typename deref; typename next; requires IteratorStatic<next>; } But to get to my question finally, I wonder if the recursion in mpl is intentional and thought out, or is it an accident that should be re-examined. If the decision was indeed thought out, I really wonder what would be a reasonable semantics of concept recursion. Cheers, Marcin [1] http://www.boost.org/doc/libs/1_40_0/libs/mpl/doc/refmanual/forward-iterato… [2] http://www.osl.iu.edu/MailArchives/conceptgcc/2007/03/0084.php

3 3

Re: [boost] [GIL] image rescale algorithms
by Est 10 Sep '09

10 Sep '09

Hi Nicolas, I used your code in Ramen (http://sourceforge.net/projects/ramenhdr/) It works great. Thank you. And now, some feedback... I think filters should be a small separate GIL extension. They are useful also for other image resampling algorithms. In clamp_channel_fn I added an overload like this: template <typename SrcChannel, typename T, typename S, typename U> void operator()(const SrcChannel& src, scoped_channel_value<T,S,U>& dst) { typedef typename channel_traits<scoped_channel_value<T,S,U>>::value_type dst_value_t; dst = dst_value_t( src); } to avoid clamping floating point channels. Another option would be to clamp only negative values. I think template <typename PixelType> struct create_accum_pixel_type : public create_accum_pixel_type<PixelType> {}; can be replaced with template <typename PixelType> struct create_accum_pixel_type {}; I had to add some typenames in front of accum_pixel_t in rescale_rows, rescale_cols and rescale to build with gcc. and I made a parallel version using Intel TBB. It's here: http://ramenhdr.svn.sourceforge.net/viewvc/ramenhdr/trunk/extern/gil/extens… Est.

2 1

[sandbox] git?
by k-oli＠gmx.de 09 Sep '09

09 Sep '09

Is a official git-repo available? boost vault uses svn

3 2

[cmake] revision 50756 failed to merge some file properties
by JOAQUIN M. LOPEZ MUÑOZ 09 Sep '09

09 Sep '09

Hi, this is a repost of a message that went unnoticed three months ago: http://lists.boost.org/boost-cmake/2009/06/0592.php and that's causing problems when merging CMake-specific stuff from trunk to release, as discussed at: http://lists.boost.org/Archives/boost/2009/08/154996.php http://lists.boost.org/Archives/boost/2009/08/155003.php CMakeLists.txt and related files in trunk do have a "svn_keywords" property with value "Id", while the counterparts in the release branch are missing this property. I guess this was an oversight when applying revision 50756: https://svn.boost.org/trac/boost/changeset/50756 Unless fixed, this is going to pop up again when the release manager prepares for 1.41. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 9

Re: [boost] Are warnings acceptable artifacts from builds?
by pete＠pcbartlett.com 09 Sep '09

09 Sep '09

On Wed 09/09/09 15:19 , Maciej Sobczak <prog(a)msobczak.com> wrote: > If a given user has a strict policy of > not > having *any* warnings during their build, then that policy is enough > to > prevent them from using Boost. I'm pretty sure that this scenario is > not > something that library authors would easily accept. > Regards, With gcc, we have chosen to include Boost using -i_system rather than -i so that /all/ Boost-generated warnings are suppressed, on the grounds that Boost developers know what they are doing and that all warnings are thus spurious. I'm interested if others think this approach is too cavalier.

2 1

Re: [boost] [warnings] Are warnings acceptable artifactsfrom builds?
by pete＠pcbartlett.com 09 Sep '09

09 Sep '09

"Stewart, Robert" <Robert.Stewart(a)sig.com> wrote: >I regularly code with two-up emacs buffers, 80 columns each. That approach also permits me to print source code -- which I do not infrequently -- >without hard to follow line breaks. Consequently, I like the 80 column limit and am frustrated by code that exceeds that limit. Printing landscape may ease your frustration somewhat.

1 0

Interest request for pointer+bit compression optimization
by vicente.botet 09 Sep '09

09 Sep '09

Hi, I have recently found in the blog of Joaquin the following optimization consisting in embed a bit into the representation of a pointer. Please read it, it is not too long (http://bannalia.blogspot.com/2008/11/optimizing-red-black-tree-color-bits.h…) I was wondering if it would be interesting to provide some generic template classes making easier this kind of optimization. We can define two templates (See below) template <typename E> struct bit_ref; template <typename T> struct pointer_ref; So instead of having enum color_type{red=false,black=true}; class rb_node { private: color_type color_; regular_rb_node_header* parent; color_type& color(){return color_;}? color_type color()const{return color_;}? rb_node*& parent(){return parent_;}? rb_node* parent() const{return parent_;} } we can compress the colot_type and the rb_node* as follows class rb_node { private: uintptr_type parentcolor_; public: bit_ref<color_type> color(){return bit_ref<color_type>(&parentcolor_);} color_type color()const{return bit_ref<color_type>(&parentcolor_);} pointer_ref<rb_node> parent(){return pointer_ref<rb_node>(&parentcolor_);} rb_node* parent() const {return pointer_ref<rb_node>(&parentcolor_);} }; Next follows the definition of the template classes template <typename E> struct bit_ref { bit_ref(uintptr_type* r_):r(r_){} operator E() const { return E(*r&uintptr_type(1)); } bit_ref& operator=(E c) { *r&=~uintptr_type(1); *r|=uintptr_type(c); return *this; } bit_ref& operator=(const bit_ref& x) { return operator=(x.operator T()); } private: uintptr_type* r; }; template <typename T> struct pointer_ref { pointer_ref(uintptr_type* r_):r(r_){} operator T*() const { return (T*)(void*)(*r&~uintptr_type(1)); } pointer_ref& operator=(T* p) { *r=((uintptr_type)(void*)p)|(*r&uintptr_type(1)); return *this; } pointer_ref& operator=(const pointer_ref& x) { return operator=(x.operator T*()); } pointer_ref operator->()const { return operator T*(); } private: uintptr_type* r; }; Thanks Joaquin for sharing simple things like this one, stable_vector and others in your Bannalia blog. _____________________ Vicente Juan Botet Escribá

12 27