- Boost - lists.preview.boost.org

[swap] please update documentation with the header I need to include
by Thorsten Ottosen 01 Jul '09

01 Jul '09

-Thorsten

8 20

Re: [boost] Fixed point integer proposal
by Soren Holstebroe 01 Jul '09

01 Jul '09

> > Some years ago I wrote a fixed point template for transparent fixed point > > integer arithmetics and conversion. > > To me, "fixed point" => !"integer". Obviously fixed point is not an integer in mathematical sense. What I meant was that a fixed point represented by an integer shares some of the same computational properties: Arithmetic is faster than floats on most architectures. Adding (and accumulating) fixed points or multiplying by an integer is exact. Conversion to integer is fast. > particular, saturating or otherwise detecting overflows seemed to be > required. Saturation and overflow detection can be specified as a policy. For me there are two important design criteria: 1st priority is that computational performance matches integer performance. 2nd priority is that it is possible to make a seamless float type and the fixed point type exchange. Adding saturation handling and overflow checks, that are not natively supported by the underlying integer is of lower priority for me. In my fixed point class I implemented overflow check as an optional policy. That way you can add all the overhead checks you want in your debug configuration and strip it in your release build. As of saturation (I assume it's computer graphics people that want that feature) it should be straight forward to implement that as a policy too in the same way as the overflow check. In my option I see little practical use of a saturation policy. Saturation code would kill performance and people would be better off using MMS registers for native saturation. > recall that someone was actually working on that. It was also > suggested that I ought to provide all of the features that <cmath> > provides for floating point. It makes sense to support rounding, abs and mod. I don't see a practical need to natively support trigonometry functions. A conversion to float and back has to be fine. Soren

5 10

[config] problem with sys/select.h on Linux/Unix
by Iain K. Hanson 01 Jul '09

01 Jul '09

Hi, boost config seems to be indirectly including sys/select.h on Linux. This causing me a problem in my sockets library where I have my own declarations of select, fd_set etc which cause duplicate symbols errors. No only can I not use config but also any boost lib as they all use config :-(. Can someone please suggest a fix for this? Out of curiosity, why does config use select.h? regards /ikh -- "I disapprove of what you say, but I will defend to the death your right to say it," Evelyn Beatrice Hall who wrote under the pseudonym S.G. Tallentyre in a biography of Voltaire. #include <std_disclaimer>

2 4

[serialization] Memoryleak in void_caster::recursive_register
by Runar Undheim 01 Jul '09

01 Jul '09

// implementation of void caster base class BOOST_SERIALIZATION_DECL(void) void_caster::recursive_register(bool includes_virtual_base) const { void_cast_detail::set_type & s = void_cast_detail::void_caster_registry::get_mutable_instance(); s.insert(this); // generate all implied void_casts. void_cast_detail::set_type::const_iterator it; for(it = s.begin(); it != s.end(); ++it){ if(m_derived == (*it)->m_base) new void_caster_shortcut( (*it)->m_derived, m_base, m_difference + (*it)->m_difference, includes_virtual_base ); if((*it)->m_derived == m_base) new void_caster_shortcut( m_derived, (*it)->m_base, m_difference + (*it)->m_difference, includes_virtual_base ); } } The new void_caster_shortcut in void_caster::recursive_register give memory leak. The leak is only at startup of program, so it doesn't eat any memory while the program is running. But it makes it difficult to find other memory leaks when the program contain several leaks you don't care about. - Runar

2 2

[gil] gcc 4.4.0 namespace fix
by Philipp Schwaha 01 Jul '09

01 Jul '09

Hi! I hope this is an appropriate place (and time ;) ) for this. I found a few namespace issues concerning GIL and gcc 4.4.0 while working on a project and have (hopefully) fixed them (patch attached - svn revision 54347). Cheers, Philipp Index: boost/gil/color_base.hpp =================================================================== --- boost/gil/color_base.hpp (revision 54347) +++ boost/gil/color_base.hpp (working copy) @@ -85,7 +85,7 @@ // grayscale pixel values are convertible to channel type operator Element () const { return _v0; } - template <typename E2, typename L2> homogeneous_color_base(const homogeneous_color_base<E2,L2,1>& c) : _v0(at_c<0>(c)) {} + template <typename E2, typename L2> homogeneous_color_base(const homogeneous_color_base<E2,L2,1>& c) : _v0(gil::at_c<0>(c)) {} }; @@ -107,13 +107,13 @@ homogeneous_color_base(Element v0, Element v1) : _v0(v0), _v1(v1) {} template <typename E2, typename L2> homogeneous_color_base(const homogeneous_color_base<E2,L2,2>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)) {} // Support for l-value reference proxy copy construction template <typename E2, typename L2> homogeneous_color_base( homogeneous_color_base<E2,L2,2>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)) {} // Support for planar_pixel_iterator construction and dereferencing template <typename P> homogeneous_color_base(P* p,bool) : @@ -155,15 +155,15 @@ homogeneous_color_base(Element v0, Element v1, Element v2) : _v0(v0), _v1(v1), _v2(v2) {} template <typename E2, typename L2> homogeneous_color_base(const homogeneous_color_base<E2,L2,3>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)), - _v2(at_c<mapping_transform<Layout,L2,2>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)), + _v2(gil::at_c<mapping_transform<Layout,L2,2>::value>(c)) {} // Support for l-value reference proxy copy construction template <typename E2, typename L2> homogeneous_color_base( homogeneous_color_base<E2,L2,3>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)), - _v2(at_c<mapping_transform<Layout,L2,2>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)), + _v2(gil::at_c<mapping_transform<Layout,L2,2>::value>(c)) {} // Support for planar_pixel_iterator construction and dereferencing template <typename P> homogeneous_color_base(P* p,bool) : @@ -212,17 +212,17 @@ homogeneous_color_base(Element v0, Element v1, Element v2, Element v3) : _v0(v0), _v1(v1), _v2(v2), _v3(v3) {} template <typename E2, typename L2> homogeneous_color_base(const homogeneous_color_base<E2,L2,4>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)), - _v2(at_c<mapping_transform<Layout,L2,2>::value>(c)), - _v3(at_c<mapping_transform<Layout,L2,3>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)), + _v2(gil::at_c<mapping_transform<Layout,L2,2>::value>(c)), + _v3(gil::at_c<mapping_transform<Layout,L2,3>::value>(c)) {} // Support for l-value reference proxy copy construction template <typename E2, typename L2> homogeneous_color_base( homogeneous_color_base<E2,L2,4>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)), - _v2(at_c<mapping_transform<Layout,L2,2>::value>(c)), - _v3(at_c<mapping_transform<Layout,L2,3>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)), + _v2(gil::at_c<mapping_transform<Layout,L2,2>::value>(c)), + _v3(gil::at_c<mapping_transform<Layout,L2,3>::value>(c)) {} // Support for planar_pixel_iterator construction and dereferencing template <typename P> homogeneous_color_base(P* p,bool) : @@ -278,19 +278,19 @@ homogeneous_color_base(Element v0, Element v1, Element v2, Element v3, Element v4) : _v0(v0), _v1(v1), _v2(v2), _v3(v3), _v4(v4) {} template <typename E2, typename L2> homogeneous_color_base(const homogeneous_color_base<E2,L2,5>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)), - _v2(at_c<mapping_transform<Layout,L2,2>::value>(c)), - _v3(at_c<mapping_transform<Layout,L2,3>::value>(c)), - _v4(at_c<mapping_transform<Layout,L2,4>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)), + _v2(gil::at_c<mapping_transform<Layout,L2,2>::value>(c)), + _v3(gil::at_c<mapping_transform<Layout,L2,3>::value>(c)), + _v4(gil::at_c<mapping_transform<Layout,L2,4>::value>(c)) {} // Support for l-value reference proxy copy construction template <typename E2, typename L2> homogeneous_color_base( homogeneous_color_base<E2,L2,5>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)), - _v2(at_c<mapping_transform<Layout,L2,2>::value>(c)), - _v3(at_c<mapping_transform<Layout,L2,3>::value>(c)), - _v4(at_c<mapping_transform<Layout,L2,4>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)), + _v2(gil::at_c<mapping_transform<Layout,L2,2>::value>(c)), + _v3(gil::at_c<mapping_transform<Layout,L2,3>::value>(c)), + _v4(gil::at_c<mapping_transform<Layout,L2,4>::value>(c)) {} // Support for planar_pixel_iterator construction and dereferencing template <typename P> homogeneous_color_base(P* p,bool) : Index: boost/gil/color_base_algorithm.hpp =================================================================== --- boost/gil/color_base_algorithm.hpp (revision 54347) +++ boost/gil/color_base_algorithm.hpp (working copy) @@ -101,7 +101,7 @@ template <typename ColorBase, int K> struct kth_semantic_element_reference_type { BOOST_STATIC_CONSTANT(int, semantic_index = (mpl::at_c<typename ColorBase::layout_t::channel_mapping_t,K>::type::value)); typedef typename kth_element_reference_type<ColorBase,semantic_index>::type type; - static type get(ColorBase& cb) { return at_c<semantic_index>(cb); } + static type get(ColorBase& cb) { return gil::at_c<semantic_index>(cb); } }; /// \brief Specifies the return type of the constant semantic_at_c<K>(color_base); @@ -109,7 +109,7 @@ template <typename ColorBase, int K> struct kth_semantic_element_const_reference_type { BOOST_STATIC_CONSTANT(int, semantic_index = (mpl::at_c<typename ColorBase::layout_t::channel_mapping_t,K>::type::value)); typedef typename kth_element_const_reference_type<ColorBase,semantic_index>::type type; - static type get(const ColorBase& cb) { return at_c<semantic_index>(cb); } + static type get(const ColorBase& cb) { return gil::at_c<semantic_index>(cb); } }; /// \brief A mutable accessor to the K-th semantic element of a color base Index: boost/gil/pixel.hpp =================================================================== --- boost/gil/pixel.hpp (revision 54347) +++ boost/gil/pixel.hpp (working copy) @@ -143,11 +143,11 @@ private: static void check_gray() { BOOST_STATIC_ASSERT((is_same<typename Layout::color_space_t, gray_t>::value)); } - template <typename Channel> void assign(const Channel& chan, mpl::false_) { check_gray(); at_c<0>(*this)=chan; } - template <typename Channel> bool equal (const Channel& chan, mpl::false_) const { check_gray(); return at_c<0>(*this)==chan; } + template <typename Channel> void assign(const Channel& chan, mpl::false_) { check_gray(); gil::at_c<0>(*this)=chan; } + template <typename Channel> bool equal (const Channel& chan, mpl::false_) const { check_gray(); return gil::at_c<0>(*this)==chan; } public: - pixel& operator= (channel_t chan) { check_gray(); at_c<0>(*this)=chan; return *this; } - bool operator==(channel_t chan) const { check_gray(); return at_c<0>(*this)==chan; } + pixel& operator= (channel_t chan) { check_gray(); gil::at_c<0>(*this)=chan; return *this; } + bool operator==(channel_t chan) const { check_gray(); return gil::at_c<0>(*this)==chan; } }; ///////////////////////////// Index: boost/gil/image_view_factory.hpp =================================================================== --- boost/gil/image_view_factory.hpp (revision 54347) +++ boost/gil/image_view_factory.hpp (working copy) @@ -102,7 +102,7 @@ BOOST_STATIC_ASSERT((!is_planar<HomogeneousView>::value && view_is_basic<HomogeneousView>::value)); BOOST_STATIC_ASSERT((boost::is_pointer<typename HomogeneousView::x_iterator>::value)); - return &at_c<0>(view(0,0)); + return &gil::at_c<0>(view(0,0)); } /// \ingroup ImageViewConstructors @@ -430,7 +430,7 @@ typedef typename type::xy_locator locator_t; typedef typename type::x_iterator x_iterator_t; typedef typename iterator_adaptor_get_base<x_iterator_t>::type x_iterator_base_t; - x_iterator_t sit(x_iterator_base_t(&at_c<K>(src(0,0))),src.pixels().pixel_size()); + x_iterator_t sit(x_iterator_base_t(&gil::at_c<K>(src(0,0))),src.pixels().pixel_size()); return type(src.dimensions(),locator_t(sit, src.pixels().row_size())); } }; @@ -444,7 +444,7 @@ typedef typename view_type<channel_t, gray_layout_t, false, false, view_is_mutable<View>::value>::type type; static type make(const View& src) { typedef typename type::x_iterator x_iterator_t; - return interleaved_view(src.width(),src.height(),(x_iterator_t)&at_c<K>(src(0,0)), src.pixels().row_size()); + return interleaved_view(src.width(),src.height(),(x_iterator_t)&gil::at_c<K>(src(0,0)), src.pixels().row_size()); } }; @@ -494,7 +494,7 @@ template <typename P> kth_channel_deref_fn(const kth_channel_deref_fn<K,P>&) {} result_type operator()(argument_type srcP) const { - return result_type(at_c<K>(srcP)); + return result_type(gil::at_c<K>(srcP)); } }; Index: boost/gil/bit_aligned_pixel_reference.hpp =================================================================== --- boost/gil/bit_aligned_pixel_reference.hpp (revision 54347) +++ boost/gil/bit_aligned_pixel_reference.hpp (working copy) @@ -145,7 +145,7 @@ // Construct from another compatible pixel type bit_aligned_pixel_reference(const bit_aligned_pixel_reference& p) : _bit_range(p._bit_range) {} - template <typename BF, typename CR> bit_aligned_pixel_reference(packed_pixel<BF,CR,Layout>& p) : _bit_range(static_cast<data_ptr_t>(&at_c<0>(p)), at_c<0>(p).first_bit()) { + template <typename BF, typename CR> bit_aligned_pixel_reference(packed_pixel<BF,CR,Layout>& p) : _bit_range(static_cast<data_ptr_t>(&gil::at_c<0>(p)), gil::at_c<0>(p).first_bit()) { check_compatible<packed_pixel<BF,CR,Layout> >(); } @@ -169,8 +169,8 @@ private: static void check_gray() { BOOST_STATIC_ASSERT((is_same<typename Layout::color_space_t, gray_t>::value)); } - template <typename Channel> void assign(const Channel& chan, mpl::false_) const { check_gray(); at_c<0>(*this)=chan; } - template <typename Channel> bool equal (const Channel& chan, mpl::false_) const { check_gray(); return at_c<0>(*this)==chan; } + template <typename Channel> void assign(const Channel& chan, mpl::false_) const { check_gray(); gil::at_c<0>(*this)=chan; } + template <typename Channel> bool equal (const Channel& chan, mpl::false_) const { check_gray(); return gil::at_c<0>(*this)==chan; } }; ///////////////////////////// Index: boost/gil/gil_concept.hpp =================================================================== --- boost/gil/gil_concept.hpp (revision 54347) +++ boost/gil/gil_concept.hpp (working copy) @@ -618,7 +618,7 @@ typedef typename kth_element_const_reference_type<ColorBase,num_elements-1>::type CR; #if !defined(_MSC_VER) || _MSC_VER > 1310 - CR cr=at_c<num_elements-1>(cb); ignore_unused_variable_warning(cr); + CR cr=gil::at_c<num_elements-1>(cb); ignore_unused_variable_warning(cr); #endif // functions that work for every pixel (no need to require them) @@ -655,8 +655,8 @@ typedef typename kth_element_reference_type<ColorBase, 0>::type CR; #if !defined(_MSC_VER) || _MSC_VER > 1310 - CR r=at_c<0>(cb); - at_c<0>(cb)=r; + CR r=gil::at_c<0>(cb); + gil::at_c<0>(cb)=r; #endif } Index: boost/gil/planar_pixel_iterator.hpp =================================================================== --- boost/gil/planar_pixel_iterator.hpp (revision 54347) +++ boost/gil/planar_pixel_iterator.hpp (working copy) @@ -109,8 +109,8 @@ reference operator->() const { return **this; } // PERFORMANCE_CHECK: Remove? - bool operator< (const planar_pixel_iterator& ptr) const { return at_c<0>(*this)< at_c<0>(ptr); } - bool operator!=(const planar_pixel_iterator& ptr) const { return at_c<0>(*this)!=at_c<0>(ptr); } + bool operator< (const planar_pixel_iterator& ptr) const { return gil::at_c<0>(*this)< gil::at_c<0>(ptr); } + bool operator!=(const planar_pixel_iterator& ptr) const { return gil::at_c<0>(*this)!=gil::at_c<0>(ptr); } private: friend class boost::iterator_core_access; @@ -119,8 +119,8 @@ void advance(ptrdiff_t d) { static_transform(*this,*this,std::bind2nd(detail::plus_asymmetric<ChannelPtr,ptrdiff_t>(),d)); } reference dereference() const { return this->template deref<reference>(); } - ptrdiff_t distance_to(const planar_pixel_iterator& it) const { return at_c<0>(it)-at_c<0>(*this); } - bool equal(const planar_pixel_iterator& it) const { return at_c<0>(*this)==at_c<0>(it); } + ptrdiff_t distance_to(const planar_pixel_iterator& it) const { return gil::at_c<0>(it)-gil::at_c<0>(*this); } + bool equal(const planar_pixel_iterator& it) const { return gil::at_c<0>(*this)==gil::at_c<0>(it); } }; namespace detail { @@ -184,7 +184,7 @@ template <typename IC, typename C> inline std::ptrdiff_t memunit_distance(const planar_pixel_iterator<IC,C>& p1, const planar_pixel_iterator<IC,C>& p2) { - return memunit_distance(at_c<0>(p1),at_c<0>(p2)); + return memunit_distance(gil::at_c<0>(p1),gil::at_c<0>(p2)); } template <typename IC> Index: boost/gil/packed_pixel.hpp =================================================================== --- boost/gil/packed_pixel.hpp (revision 54347) +++ boost/gil/packed_pixel.hpp (working copy) @@ -77,19 +77,19 @@ template <typename P> packed_pixel(const P& p, typename enable_if_c<is_pixel<P>::value>::type* d=0) { check_compatible<P>(); static_copy(p,*this); } packed_pixel(int chan0, int chan1) : _bitfield(0) { BOOST_STATIC_ASSERT((num_channels<packed_pixel>::value==2)); - at_c<0>(*this)=chan0; at_c<1>(*this)=chan1; + gil::at_c<0>(*this)=chan0; gil::at_c<1>(*this)=chan1; } packed_pixel(int chan0, int chan1, int chan2) : _bitfield(0) { BOOST_STATIC_ASSERT((num_channels<packed_pixel>::value==3)); - at_c<0>(*this)=chan0; at_c<1>(*this)=chan1; at_c<2>(*this)=chan2; + gil::at_c<0>(*this)=chan0; gil::at_c<1>(*this)=chan1; gil::at_c<2>(*this)=chan2; } packed_pixel(int chan0, int chan1, int chan2, int chan3) : _bitfield(0) { BOOST_STATIC_ASSERT((num_channels<packed_pixel>::value==4)); - at_c<0>(*this)=chan0; at_c<1>(*this)=chan1; at_c<2>(*this)=chan2; at_c<3>(*this)=chan3; + gil::at_c<0>(*this)=chan0; gil::at_c<1>(*this)=chan1; gil::at_c<2>(*this)=chan2; gil::at_c<3>(*this)=chan3; } packed_pixel(int chan0, int chan1, int chan2, int chan3, int chan4) : _bitfield(0) { BOOST_STATIC_ASSERT((num_channels<packed_pixel>::value==5)); - at_c<0>(*this)=chan0; at_c<1>(*this)=chan1; at_c<2>(*this)=chan2; at_c<3>(*this)=chan3; at_c<4>(*this)=chan4; + gil::at_c<0>(*this)=chan0; gil::at_c<1>(*this)=chan1; gil::at_c<2>(*this)=chan2; gil::at_c<3>(*this)=chan3; gil::at_c<4>(*this)=chan4; } packed_pixel& operator=(const packed_pixel& p) { _bitfield=p._bitfield; return *this; } @@ -106,11 +106,11 @@ // Support for assignment/equality comparison of a channel with a grayscale pixel static void check_gray() { BOOST_STATIC_ASSERT((is_same<typename Layout::color_space_t, gray_t>::value)); } - template <typename Channel> void assign(const Channel& chan, mpl::false_) { check_gray(); at_c<0>(*this)=chan; } - template <typename Channel> bool equal (const Channel& chan, mpl::false_) const { check_gray(); return at_c<0>(*this)==chan; } + template <typename Channel> void assign(const Channel& chan, mpl::false_) { check_gray(); gil::at_c<0>(*this)=chan; } + template <typename Channel> bool equal (const Channel& chan, mpl::false_) const { check_gray(); return gil::at_c<0>(*this)==chan; } public: - packed_pixel& operator= (int chan) { check_gray(); at_c<0>(*this)=chan; return *this; } - bool operator==(int chan) const { check_gray(); return at_c<0>(*this)==chan; } + packed_pixel& operator= (int chan) { check_gray(); gil::at_c<0>(*this)=chan; return *this; } + bool operator==(int chan) const { check_gray(); return gil::at_c<0>(*this)==chan; } }; ///////////////////////////// Index: libs/gil/test/performance.cpp =================================================================== --- libs/gil/test/performance.cpp (revision 54347) +++ libs/gil/test/performance.cpp (working copy) @@ -81,9 +81,9 @@ T* first=(T*)_v.row_begin(0); T* last=first+_v.size()*3; while(first!=last) { - first[0]=at_c<0>(_p); - first[1]=at_c<1>(_p); - first[2]=at_c<2>(_p); + first[0]=boost::gil::at_c<0>(_p); + first[1]=boost::gil::at_c<1>(_p); + first[2]=boost::gil::at_c<2>(_p); first+=3; } } @@ -99,9 +99,9 @@ T1* first=(T1*)_v.row_begin(0); T1* last=first+_v.size()*3; while(first!=last) { - first[0]=at_c<2>(_p); - first[1]=at_c<1>(_p); - first[2]=at_c<0>(_p); + first[0]=boost::gil::at_c<2>(_p); + first[1]=boost::gil::at_c<1>(_p); + first[2]=boost::gil::at_c<0>(_p); first+=3; } } @@ -116,12 +116,12 @@ void operator()() const { std::size_t size=_v.size(); T1* first; - first=(T1*)at_c<0>(_v.row_begin(0)); - std::fill(first,first+size,at_c<0>(_p)); - first=(T1*)at_c<1>(_v.row_begin(0)); - std::fill(first,first+size,at_c<1>(_p)); - first=(T1*)at_c<2>(_v.row_begin(0)); - std::fill(first,first+size,at_c<2>(_p)); + first=(T1*)boost::gil::at_c<0>(_v.row_begin(0)); + std::fill(first,first+size,boost::gil::at_c<0>(_p)); + first=(T1*)boost::gil::at_c<1>(_v.row_begin(0)); + std::fill(first,first+size,boost::gil::at_c<1>(_p)); + first=(T1*)boost::gil::at_c<2>(_v.row_begin(0)); + std::fill(first,first+size,boost::gil::at_c<2>(_p)); } }; @@ -135,12 +135,12 @@ void operator()() const { std::size_t size=_v.size(); T1* first; - first=(T1*)at_c<0>(_v.row_begin(0)); - std::fill(first,first+size,at_c<2>(_p)); - first=(T1*)at_c<1>(_v.row_begin(0)); - std::fill(first,first+size,at_c<1>(_p)); - first=(T1*)at_c<2>(_v.row_begin(0)); - std::fill(first,first+size,at_c<1>(_p)); + first=(T1*)boost::gil::at_c<0>(_v.row_begin(0)); + std::fill(first,first+size,boost::gil::at_c<2>(_p)); + first=(T1*)boost::gil::at_c<1>(_v.row_begin(0)); + std::fill(first,first+size,boost::gil::at_c<1>(_p)); + first=(T1*)boost::gil::at_c<2>(_v.row_begin(0)); + std::fill(first,first+size,boost::gil::at_c<1>(_p)); } }; @@ -191,9 +191,9 @@ for_each_nongil_t(const View& v_in,const F& f_in) : _v(v_in), _f(f_in) {} void operator()() const { T1 *first0, *first1, *first2, *last0; - first0=(T1*)at_c<0>(_v.row_begin(0)); - first1=(T1*)at_c<1>(_v.row_begin(0)); - first2=(T1*)at_c<2>(_v.row_begin(0)); + first0=(T1*)boost::gil::at_c<0>(_v.row_begin(0)); + first1=(T1*)boost::gil::at_c<1>(_v.row_begin(0)); + first2=(T1*)boost::gil::at_c<2>(_v.row_begin(0)); last0=first0+_v.size(); while(first0!=last0) { *first0++=0; @@ -261,12 +261,12 @@ copy_nongil_t(const View1& v1_in,const View2& v2_in) : _v1(v1_in), _v2(v2_in) {} void operator()() const { std::size_t size=_v1.size(); - T1* first10=(T1*)at_c<0>(_v1.row_begin(0)); - T1* first11=(T1*)at_c<1>(_v1.row_begin(0)); - T1* first12=(T1*)at_c<2>(_v1.row_begin(0)); - T2* first20=(T2*)at_c<0>(_v2.row_begin(0)); - T2* first21=(T2*)at_c<1>(_v2.row_begin(0)); - T2* first22=(T2*)at_c<2>(_v2.row_begin(0)); + T1* first10=(T1*)boost::gil::at_c<0>(_v1.row_begin(0)); + T1* first11=(T1*)boost::gil::at_c<1>(_v1.row_begin(0)); + T1* first12=(T1*)boost::gil::at_c<2>(_v1.row_begin(0)); + T2* first20=(T2*)boost::gil::at_c<0>(_v2.row_begin(0)); + T2* first21=(T2*)boost::gil::at_c<1>(_v2.row_begin(0)); + T2* first22=(T2*)boost::gil::at_c<2>(_v2.row_begin(0)); std::copy(first10,first10+size,first20); std::copy(first11,first11+size,first21); std::copy(first12,first12+size,first22); @@ -282,9 +282,9 @@ void operator()() const { T1* first=(T1*)_v1.row_begin(0); T1* last=first+_v1.size()*3; - T2* first0=(T2*)at_c<0>(_v2.row_begin(0)); - T2* first1=(T2*)at_c<1>(_v2.row_begin(0)); - T2* first2=(T2*)at_c<2>(_v2.row_begin(0)); + T2* first0=(T2*)boost::gil::at_c<0>(_v2.row_begin(0)); + T2* first1=(T2*)boost::gil::at_c<1>(_v2.row_begin(0)); + T2* first2=(T2*)boost::gil::at_c<2>(_v2.row_begin(0)); while(first!=last) { *first0++=first[0]; *first1++=first[1]; @@ -303,9 +303,9 @@ void operator()() const { T1* first=(T1*)_v2.row_begin(0); T1* last=first+_v2.size()*3; - T2* first0=(T2*)at_c<0>(_v1.row_begin(0)); - T2* first1=(T2*)at_c<1>(_v1.row_begin(0)); - T2* first2=(T2*)at_c<2>(_v1.row_begin(0)); + T2* first0=(T2*)boost::gil::at_c<0>(_v1.row_begin(0)); + T2* first1=(T2*)boost::gil::at_c<1>(_v1.row_begin(0)); + T2* first2=(T2*)boost::gil::at_c<2>(_v1.row_begin(0)); while(first!=last) { first[0]=*first0++; first[1]=*first1++; @@ -369,12 +369,12 @@ F _f; transform_nongil_t(const View1& v1_in,const View2& v2_in,const F& f_in) : _v1(v1_in),_v2(v2_in),_f(f_in) {} void operator()() const { - T1* first10=(T1*)at_c<0>(_v1.row_begin(0)); - T1* first11=(T1*)at_c<1>(_v1.row_begin(0)); - T1* first12=(T1*)at_c<2>(_v1.row_begin(0)); - T1* first20=(T2*)at_c<0>(_v2.row_begin(0)); - T1* first21=(T2*)at_c<1>(_v2.row_begin(0)); - T1* first22=(T2*)at_c<2>(_v2.row_begin(0)); + T1* first10=(T1*)boost::gil::at_c<0>(_v1.row_begin(0)); + T1* first11=(T1*)boost::gil::at_c<1>(_v1.row_begin(0)); + T1* first12=(T1*)boost::gil::at_c<2>(_v1.row_begin(0)); + T1* first20=(T2*)boost::gil::at_c<0>(_v2.row_begin(0)); + T1* first21=(T2*)boost::gil::at_c<1>(_v2.row_begin(0)); + T1* first22=(T2*)boost::gil::at_c<2>(_v2.row_begin(0)); T1* last10=first10+_v1.size(); while(first10!=last10) { *first20++=T2(*first12++*0.1f); @@ -394,9 +394,9 @@ void operator()() const { T1* first1=(T1*)_v1.row_begin(0); T1* last1=first1+_v1.size()*3; - T1* first20=(T2*)at_c<0>(_v2.row_begin(0)); - T1* first21=(T2*)at_c<1>(_v2.row_begin(0)); - T1* first22=(T2*)at_c<2>(_v2.row_begin(0)); + T1* first20=(T2*)boost::gil::at_c<0>(_v2.row_begin(0)); + T1* first21=(T2*)boost::gil::at_c<1>(_v2.row_begin(0)); + T1* first22=(T2*)boost::gil::at_c<2>(_v2.row_begin(0)); while(first1!=last1) { *first20++=T2(first1[2]*0.1f); *first21++=T2(first1[1]*0.2f); @@ -414,9 +414,9 @@ F _f; transform_nongil_t(const View1& v1_in,const View2& v2_in,const F& f_in) : _v1(v1_in),_v2(v2_in),_f(f_in) {} void operator()() const { - T1* first10=(T1*)at_c<0>(_v1.row_begin(0)); - T1* first11=(T1*)at_c<1>(_v1.row_begin(0)); - T1* first12=(T1*)at_c<2>(_v1.row_begin(0)); + T1* first10=(T1*)boost::gil::at_c<0>(_v1.row_begin(0)); + T1* first11=(T1*)boost::gil::at_c<1>(_v1.row_begin(0)); + T1* first12=(T1*)boost::gil::at_c<2>(_v1.row_begin(0)); T2* first2=(T1*)_v2.row_begin(0); T1* last2=first2+_v1.size()*3; while(first2!=last2) { Index: libs/gil/test/pixel.cpp =================================================================== --- libs/gil/test/pixel.cpp (revision 54347) +++ libs/gil/test/pixel.cpp (working copy) @@ -63,8 +63,8 @@ // test homogeneous algorithms - fill, max, min static const int num_chan = num_channels<typename C2::pixel_t>::value; - static_fill(C2::_pixel, at_c<0>(C1::_pixel)+1); - error_if(at_c<0>(C2::_pixel) != at_c<num_chan-1>(C2::_pixel)); + static_fill(C2::_pixel, boost::gil::at_c<0>(C1::_pixel)+1); + error_if(boost::gil::at_c<0>(C2::_pixel) != boost::gil::at_c<num_chan-1>(C2::_pixel)); C2::_pixel = C1::_pixel; error_if(static_max(C2::_pixel) != static_max(C1::_pixel)); @@ -107,7 +107,7 @@ error_if(C1::_pixel!=C2::_pixel); static_generate(C2::_pixel, set_to_one()); - error_if(at_c<0>(C2::_pixel) != 1); + error_if(boost::gil::at_c<0>(C2::_pixel) != 1); // Test swap if both are mutable and if their value type is the same // (We know the second one is mutable) @@ -313,7 +313,7 @@ bgr8_pixel_t bgr8(rgb8); error_if(bgr8[0] == rgb8[0]); error_if(dynamic_at_c(bgr8,0) == dynamic_at_c(rgb8,0)); - error_if(at_c<0>(bgr8) == at_c<0>(rgb8)); + error_if(boost::gil::at_c<0>(bgr8) == boost::gil::at_c<0>(rgb8)); error_if(semantic_at_c<0>(bgr8) != semantic_at_c<0>(rgb8)); error_if(get_color(bgr8,blue_t()) != get_color(rgb8,blue_t()));

2 1

[interprocess] problem compiling
by manmohan.m＠nokia.com 30 Jun '09

30 Jun '09

Hello, I'm trying to use boost::interprocess in my code. The environment being used is S60 armv5 WINSCW (RVCT compiler) . Since it's a header only library, I presumed including it in my USERINCLUDE (i.e placing interprocess inside my local \inc), would suffice the purpose. But there were some dependencies e.g. some include files were not to be found. I managed to solve the interdependencies by including the missing files locally. But when I try to use the sample code for managed_shared_memory (given on the doc page for boost::interprocess), it's giving me errors regarding template-instantiation in ..\inc\boost\interprocess\mem_algo\rbtree_best_fit.hpp. To be precise, the error that I got is attached in the text file. It's too verbose to be written here. The usage is that my main() consists of the following #include "boost/interprocess/managed_shared_memory.hpp" #include "boost/interprocess/containers/vector.hpp" #include "boost/interprocess/allocators/allocator.hpp" int main () { using namespace boost::interprocess; //Shared memory front-end that is able to construct objects //associated with a c-string. Erase previous shared memory with the name //to be used and create the memory segment at the specified address and initialize resources shared_memory_object::remove("MySharedMemory"); managed_shared_memory segment (create_only ,"MySharedMemory" ,65536); //segment size in bytes return 0; } The underlined statement is the point of instatiation and this is creating the above said errror. Could somebody please point out what am I missing? Is there something else that I need to do in order to use boost::interprocess? Thanks & Regards Manmohan P.S.: Boost is already ported under the environment, but not all modules. I could see all the major includes under system include path "R:\epoc32\include\osextensions\stdapis\boost".

1 0

[serialization] impossible to extend xml_iarchive?
by Kenny Riddile 29 Jun '09

29 Jun '09

Here I am again...still trying to add a seemingly trivial bit of functionality to xml_iarchive by following the directions at: http://www.boost.org/doc/libs/1_39_0/libs/serialization/doc/derivation.html In my last post (http://lists.boost.org/boost-users/2009/06/49028.php) I was getting several unresolved externals from basic_xml_grammar<char>. I figured I needed to simply explicitly instantiate this template like the others. The first problem with that is that basic_xml_grammar.ipp isn't in boost/archive/impl/ like the other ipp's are. It's in serialization's source directory, which I, like most people, had thrown away after building Boost. So after I copied that file into my own codebase so I could include it and explicitly instantiate basic_xml_grammar<char>, I then got a single unresolved external complaining about basic_xml_grammar<char>::init_chset() not being defined. After some more digging, I found that that particular method is defined in basic_xml_grammar.cpp which is also in serialization's source directory. Even after all that, I'm still getting some other linker errors that nobody here can figure out after hours of trying, but the aforementioned issues alone suggest to me that it isn't currently possible to extend xml_iarchive by following the instructions in the documentation. -Kenny Riddile

1 0

[MultiArray] number of dimensions as static constant
by Frank Mori Hess 29 Jun '09

29 Jun '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 multi_array and friends should provide the number of dimensions as a static member constant, so it is available at compile time and can be used in generic programming. I assume the num_dimensions() non-static member function was put in the design with the idea that the number of dimensions of a multi_array object might be dynamically changed. But since the multi array concept and classes doen't support changing the number of dimensions, it doesn't provide anything useful over a static constant. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpE4poACgkQ5vihyNWuA4VzQgCfcbKVf2y10seFT7M+fAEkAHr9 KkAAniIZCuLumjb2VcVJgDF6BZMtalfb =wyei -----END PGP SIGNATURE-----

2 2

[MultiArray] shape() return type
by Frank Mori Hess 29 Jun '09

29 Jun '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Has there ever been any thought to making multi_array::shape() return something that models the Collection concept (RandomAccessCollection in particular I suppose) rather than a raw pointer? This would allow the return value from shape() to be passed directly to multi_array::reshape() or multi_array::resize(), for added convenience. It would also allow a debug assertion to be added to make sure you don't try to access beyond the end of the array returned by shape(). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpDxwoACgkQ5vihyNWuA4UrlACcDd/AZgM4lab3pFu96TJsc9Om 6O0AoL4DCYxWtsNBJBdvaVwp/n3p5h80 =6Wss -----END PGP SIGNATURE-----

2 2

[serialization] and [type traites]Problem with has_new_operator
by Runar Undheim 29 Jun '09

29 Jun '09

I have a class that override two different new operators. This give an "ambiguous call to overloaded function" error message in VisualC++2005. Example on code that will give error: class A { public: void* operator new(std::size_t); void* operator new(std::size_t, void*); }; int _tmain(int argc, _TCHAR* argv[]) { boost::has_new_operator<A>(); return 0; } I think that the has_new_operator could be updated with a new check_sig3 test. Where the new(std::size_t, void*) is moved to the new check_sig3. The serialization code use the has_new_operator to decide if it should call T::new or ::new. But what should happen if only the operation new for arrays is overridden? If T::new function only should be called when the operator new(size_t) is overridden then the has_new_operator function should be split into three different functions (ex. has_new_operator, has_new_operator_array and has_new_operator_placement)? - Runar

1 0

version conflicts: is there a solution?
by Lewis Hyatt 28 Jun '09

28 Jun '09

Hi Everyone- This has been discussed before (http://thread.gmane.org/gmane.comp.lib.boost.devel/180008) but I think my question is along a slightly different line so I thought I would ask about it. Let's say I want to compile and distribute a library (without the source), and I happen to use some boost header-only libraries as an implementation detail in some of my functions. None of the headers associated with my library include boost headers; it's purely an internal detail. Now, it seems to me that users of my library will still have to be aware of the fact that I used boost in my implementation -- specifically, if they happen to use different versions of the same boost libraries in their code, then the ODR is violated and the behavior is undefined. I realize this isn't a boost-specific problem (it would affect any library of template functions), but I am wondering if there is a boost-specific solution already worked out? Has anyone thought about this? It seems to me that in this case, what would be ideal would be if I could do: #define BOOST_NAMESPACE some_unique_namespace_for_boost #include "boost/algorithm/string.hpp" BOOST_NAMESPACE::shared_ptr<void> x; //or whatever Then I can insure there are no ODR violations and I don't need to bother users of my library with the fact that I used boost at all. Other than the sheer annoyance of having to go through all the boost code to use this macro, is there a strong downside to this approach? Alternatively, I could try: namespace { #include "boost/..." } But I don't know, could this work? Or are there boost headers that rely on fully qualified references like ::boost::algorithm::whatever? I'd appreciate anyone's thoughts on this issue, thanks! -Lewis

8 17

Building boost against uClibc on arm machine
by Piotr Borys 28 Jun '09

28 Jun '09

Hello all. I'm trying to cross-compile boost for arm machine running linux with uClibc. Most of the libs are built ok, but some of them (including one of the most important to me: thread) failed. One of the mesgs was: -------------------------------- gcc.compile.c++ bin.v2/libs/thread/build/gcc-4.3.2/debug/threading-multi/pthread/thread.o libs/thread/src/pthread/thread.cpp: In static member function 'static unsigned int boost::thread::hardware_concurrency()': libs/thread/src/pthread/thread.cpp:394: error: 'get_nprocs' was not declared in this scope -------------------------------- and somehow I'm afraid this is related to uClibc... some facts: Boost 1.39.0 G++ 4.3.2 (cross sysrooted compiler) Any help what I can take a look on? cheers -- Piotr "utak3r" Borys http://utak3r.pl

3 4

[Graph] iterator range splitting
by Tim Keitt 28 Jun '09

28 Jun '09

I've run into some problems with the Graph library as there is a lot of code that splits iterator ranges. An example of this is: (from depth_first_search.hpp) template <class VertexListGraph, class DFSVisitor, class ColorMap> void depth_first_search(const VertexListGraph& g, DFSVisitor vis, ColorMap color) { // // should the below not be: // graph_traits<VertexListGraph>::iterator vi, vend; // tie(vi, vend) = vertices(g); // if ( vi == vend ) ... ??? // or perhaps to be more terse // if ( empty_range(vertices(g)) ) // where empty_range(g) compares first and second // if (vertices(g).first == vertices(g).second) return; depth_first_search(g, vis, color, *vertices(g).first); } This is causing problems in my code where I have defined custom graph classes. In my case out_edges(g) != out_edges(g) because memory is allocated within the out_edges call and successive calls will return different ranges (vertex ranges are not a problem in my case as I use a simple counting iterator). Must out_edges(g) == out_edges(g) for a graph class to meet the Graph library requirements? If not, then a good bit of the code needs to be altered and possibly some of the iterator macros deprecated. Below I've located every instance where the first or second member of an iterator pair is thrown away. These cases are only problematic if the retained iterator is later compared to an iterator from another range. The fix is simple. One only needs to retain both members of the iterator pair. I am willing to provide a patch if it is agreed that the current code is wrong. THK egrep '(vertices|edges)$.*$\.(first|second)' * adjacency_list_io.hpp: for (vi = vertices(graph).first; vi != vertices(graph).second; ++vi){ adjacency_list_io.hpp: for (ei = edges(graph).first; ei != edges(graph).second; ++ei){ adjacency_list_io.hpp: for (vi = vertices(this->graph).first; vi != vertices(this->graph).second; ++vi){ adjacency_matrix.hpp: return *vertices(g).first; adjacency_matrix.hpp: return *vertices(g).first; adj_list_serialize.hpp: for (vi = vertices(graph).first; vi != vertices(graph).second; ++vi) { adj_list_serialize.hpp: for (ei = edges(graph).first; ei != edges(graph).second; ++ei){ bc_clustering.hpp: if (edges(g).first == edges(g).second) return; bc_clustering.hpp: edge_descriptor e = *max_element(edges(g).first, edges(g).second, cmp); bc_clustering.hpp: } while (!is_done && edges(g).first != edges(g).second); cuthill_mckee_ordering.hpp: if (vertices(G).first == vertices(G).second) cuthill_mckee_ordering.hpp: if (vertices(G).first == vertices(G).second) depth_first_search.hpp: if (start_vertex != implicit_cast<Vertex>(*vertices(g).first)){ vis.start_vertex(start_vertex, g); depth_first_search.hpp: if (vertices(g).first == vertices(g).second) depth_first_search.hpp: depth_first_search(g, vis, color, *vertices(g).first); depth_first_search.hpp: if (vertices(g).first == vertices(g).second) depth_first_search.hpp: *vertices(g).first), edge_connectivity.hpp: std::set_difference(vertices(g).first, vertices(g).second, edge_connectivity.hpp: std::set_difference(vertices(g).first, vertices(g).second, fruchterman_reingold.hpp: Dim minX = position[*vertices(g).first].x, maxX = minX; fruchterman_reingold.hpp: Dim minY = position[*vertices(g).first].y, maxY = minY; graph_test.hpp: bgl_first_9 = vertices(g).first, bgl_last_9 = vertices(g).second; graph_test.hpp: bgl_first_9 = vertices(g).first, bgl_last_9 = vertices(g).second; howard_cycle_ratio.hpp: if (boost::out_edges(vd1, m_g).first == boost::out_edges(vd1, m_g).second) throw bad_graph(m_vim[vd1]); howard_cycle_ratio.hpp: mcr_edge_t ed = *boost::out_edges(vd1, m_g).first; howard_cycle_ratio.hpp: good_vertex = boost::target(*boost::out_edges(good_vertex, m_pi_g).first, m_pi_g); howard_cycle_ratio.hpp: pi_edge_t tmp_ed = *(boost::out_edges(vd, m_pi_g).first); howard_cycle_ratio.hpp: remove_edge(*(out_edges(m_g2pi_g_vm[vd], m_pi_g).first), m_pi_g); is_kuratowski_subgraph.hpp: bipartition_start = next(next(next(vertices(K_3_3).first))); is_kuratowski_subgraph.hpp: si = vertices(contracted_graph).first; isomorphism.hpp: for (typename graph_traits<Graph1>::edge_iterator e1 = edges(g1).first; isomorphism.hpp: e1 != edges(g1).second; ++e1) { isomorphism.hpp: for (typename graph_traits<Graph2>::edge_iterator e2 = edges(g2).first; isomorphism.hpp: e2 != edges(g2).second && !found_edge; ++e2) { iteration_macros.hpp: bgl_first_9 = vertices(g).first, bgl_last_9 = vertices(g).second; iteration_macros.hpp: BGL_FIRST(__LINE__) = vertices(GNAME).first, BGL_LAST(__LINE__) = vertices(GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = vertices(GNAME).first, BGL_LAST(__LINE__) = vertices(GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = edges(GNAME).first, BGL_LAST(__LINE__) = edges(GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = edges(GNAME).first, BGL_LAST(__LINE__) = edges(GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = adjacent_vertices(UNAME, GNAME).first,\ iteration_macros.hpp: BGL_LAST(__LINE__) = adjacent_vertices(UNAME, GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = adjacent_vertices(UNAME, GNAME).first,\ iteration_macros.hpp: BGL_LAST(__LINE__) = adjacent_vertices(UNAME, GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = out_edges(UNAME, GNAME).first,\ iteration_macros.hpp: BGL_LAST(__LINE__) = out_edges(UNAME, GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = out_edges(UNAME, GNAME).first,\ iteration_macros.hpp: BGL_LAST(__LINE__) = out_edges(UNAME, GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = in_edges(UNAME, GNAME).first,\ iteration_macros.hpp: BGL_LAST(__LINE__) = in_edges(UNAME, GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = in_edges(UNAME, GNAME).first,\ iteration_macros.hpp: BGL_LAST(__LINE__) = in_edges(UNAME, GNAME).second; \ johnson_all_pairs_shortest.hpp: typename Traits2::vertex_descriptor s = *vertices(g2).first; kamada_kawai_spring_layout.hpp: for (vertex_iterator ui = vertices(g).first, end = vertices(g).second; kamada_kawai_spring_layout.hpp: vertex_iterator ui, end = vertices(g).second; kamada_kawai_spring_layout.hpp: for (ui = vertices(g).first; ui != end; ++ui) { kamada_kawai_spring_layout.hpp: vertex_descriptor p = *vertices(g).first; kamada_kawai_spring_layout.hpp: for (ui = vertices(g).first; ui != end; ++ui) { kamada_kawai_spring_layout.hpp: for (ui = vertices(g).first; ui != end; ++ui) { kamada_kawai_spring_layout.hpp: for (ui = vertices(g).first; ui != end; ++ui) { kamada_kawai_spring_layout.hpp: for (ui = vertices(g).first; ui != end; ++ui) { king_ordering.hpp: if (vertices(G).first == vertices(G).second) king_ordering.hpp: if (vertices(G).first == vertices(G).second) metric_tsp_approx.hpp: Vertex v(*vertices(g).first); metric_tsp_approx.hpp: metric_tsp_approx_from_vertex(g, *vertices(g).first, metric_tsp_approx.hpp: metric_tsp_approx_from_vertex(g, *vertices(g).first, metric_tsp_approx.hpp: metric_tsp_approx_from_vertex(g, *vertices(g).first, metric_tsp_approx.hpp: metric_tsp_approx_from_vertex(g, *vertices(g).first, w, metric_tsp_approx.hpp: metric_tsp_approx_from_vertex(g, *vertices(g).first, w, id, vis); metric_tsp_approx.hpp: Tree t(mst, *vertices(mst).first, minimum_degree_ordering.hpp: adj_iter nu = adjacent_vertices(u_node, G).first; planar_canonical_ordering.hpp: vertex_t first_vertex = *vertices(g).first; prim_minimum_spanning_tree.hpp: choose_param(get_param(params, root_vertex_t()), *vertices(g).first), prim_minimum_spanning_tree.hpp: (g, *vertices(g).first, predecessor_map(p_map). property_iter_range.hpp: return std::make_pair(iter(vertices(graph).first, get(tag, graph)), property_iter_range.hpp: iter(vertices(graph).second, get(tag, graph))); property_iter_range.hpp: return std::make_pair(iter(vertices(graph).first, get(tag, graph)), property_iter_range.hpp: iter(vertices(graph).second, get(tag, graph))); property_iter_range.hpp: return std::make_pair(iter(edges(graph).first, get(tag, graph)), property_iter_range.hpp: iter(edges(graph).second, get(tag, graph))); property_iter_range.hpp: return std::make_pair(iter(edges(graph).first, get(tag, graph)), property_iter_range.hpp: iter(edges(graph).second, get(tag, graph))); push_relabel_max_flow.hpp: current(num_vertices(g_), out_edges(*vertices(g_).first, g_).second), push_relabel_max_flow.hpp: current[u] = out_edges(u, g).first; push_relabel_max_flow.hpp: current[v] = out_edges(v, g).first; push_relabel_max_flow.hpp: for (ai = current[u], ai_end = out_edges(u, g).second; push_relabel_max_flow.hpp: current[u] = out_edges(u, g).first; push_relabel_max_flow.hpp: for (; current[u] != out_edges(u, g).second; ++current[u]) { push_relabel_max_flow.hpp: if (current[u] == out_edges(u, g).second) { push_relabel_max_flow.hpp: ai = out_edges(u, g).first; push_relabel_max_flow.hpp: while (excess_flow[u] > 0 && ai != out_edges(u, g).second) { push_relabel_max_flow.hpp: ai = out_edges(u, g).first; random.hpp: i = vertices(g).first; random.hpp: return *vertices(g).first; random.hpp: i = edges(g).first; random.hpp: return *edges(g).first; sloan_ordering.hpp: s = *(vertices(G).first); undirected_dfs.hpp: if (start_vertex != *vertices(g).first){ vis.start_vertex(start_vertex, g); undirected_dfs.hpp: undirected_dfs(g, vis, vertex_color, edge_color, *vertices(g).first); undirected_dfs.hpp: *vertices(g).first), -- Timothy H. Keitt http://www.keittlab.org/

6 16

Re: [boost] Warning. Possible virus at vault (thread_lokeable)
by raindog＠macrohmasheen.com 27 Jun '09

27 Jun '09

If anyone still has a copy of it somewhere, can you send it to me? ------Original Message------ From: Rene Rivera Sender: boost-bounces(a)lists.boost.org To: boost(a)lists.boost.org ReplyTo: boost(a)lists.boost.org Sent: Jun 27, 2009 6:47 AM Subject: Re: [boost] Warning. Possible virus at vault (thread_lokeable) Niels Dekker - address until 2010-10-10 wrote: > Agustín K-ballo Bergé wrote: >> The recently uploaded 'thread_lokeable' file at the vault contains an >> executable that appears to be a virus. virustotal.com reports 6/41 hits. >> The name of the owner (marc0x) appears at some hacker related forums. >> >> I don't know what should be done in such cases, so I hope some >> administrator would read this message and take a look at the file. > > I don't know what to do either, but I've just mailed your finding to > Info (at) boostpro.com > > FYI, I've just downloaded the file, thread_lokeable.zip, and AVG > reported to me that the executable it contains (thread_lokeable.exe) is > a "Trojan horse Dropper.VB.CFQ" Thanks for noticing and reporting it. It's taken care of. Although I may have deleted an extra user or two along the way :-\ -- -- 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Sent from my Verizon Wireless BlackBerry

1 0

Warning. Possible virus at vault
by Agustín K-ballo Bergé 27 Jun '09

27 Jun '09

The recently uploaded 'thread_lokeable' file at the vault contains an executable that appears to be a virus. virustotal.com reports 6/41 hits. The name of the owner (marc0x) appears at some hacker related forums. I don't know what should be done in such cases, so I hope some administrator would read this message and take a look at the file. Agustín K-ballo Bergé.-

3 2

[hash][msvc 8.0] <boost/functional/hash/detail/float_functions.hpp> issuing a using namespace std directive?
by JOAQUIN M. LOPEZ MUÑOZ 27 Jun '09

27 Jun '09

If I compile the following wih MSVC++ 8.0: #include <list> typedef list<int> foo; the compiler complains, fairly enough, with some syntax error due to the fact that there's no "list" in the global namespace (we missed a prefixing std::). But if I now try this: #include <boost/functional/hash/detail/float_functions.hpp> #include <list> typedef list<int> foo; compilation succeeds! Somehow, <boost/functional/hash/detail/float_functions.hpp> is importing namespace std into the global namespace, presumably with a using directive. I tried to examine the offending header an saw no obvious using directive to blame, so I hope someone more knowledgeable can take a look at this problem. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

7 19

[function] Unmerged changes and open tickets
by Daniel James 27 Jun '09

27 Jun '09

Hi all, Boost.Function doesn't seem to have been merged to release for the last 8 months. There are also a number of open tickets which look fairly easy to fix. So, if no one objects, I'll try to deal with them in a few days time and then merge outstanding changes a little while later. These tickets fix various problems: https://svn.boost.org/trac/boost/ticket/2642 https://svn.boost.org/trac/boost/ticket/2847 https://svn.boost.org/trac/boost/ticket/2929 https://svn.boost.org/trac/boost/ticket/3012 There's also an optimization which looks sensible to me: https://svn.boost.org/trac/boost/ticket/2319 Daniel

1 0

[ptr_container] ptr_vector across DLL boundaries
by Robert Dailey 27 Jun '09

27 Jun '09

Hi, Suppose I have a DLL that allocates a few objects and places them in a ptr_vector. I then pass this ptr_vector to my executable via a move operation (basically a swap, not a copy). The executable would keep the ptr_vector by value and eventually delete it when it falls out of scope. Is there any danger in doing this? My goal is to make sure that the same memory manager is used to delete the items as was used to create them.

5 28

[variant] Visual Studio debug visualizers
by Dmitry Vinogradov 25 Jun '09

25 Jun '09

I wrote a simple debug visualizer for boost::variant and I want to share it with community. boost::variant<*,*,*,*,*,*,*,*,*,*,*> { preview ( #( #switch($c.which_) #case 0 ( *($T1 *)&($c.storage_.data_) ) #case 1 ( *($T2 *)&($c.storage_.data_) ) #case 2 ( *($T3 *)&($c.storage_.data_) ) #case 3 ( *($T4 *)&($c.storage_.data_) ) #case 4 ( *($T5 *)&($c.storage_.data_) ) #case 5 ( *($T6 *)&($c.storage_.data_) ) #case 6 ( *($T7 *)&($c.storage_.data_) ) #case 7 ( *($T8 *)&($c.storage_.data_) ) #case 8 ( *($T9 *)&($c.storage_.data_) ) #case 9 ( *($T10 *)&($c.storage_.data_) ) ) ) children ( #( value: #switch($c.which_) #case 0 ( *($T1 *)&($c.storage_.data_) ) #case 1 ( *($T2 *)&($c.storage_.data_) ) #case 2 ( *($T3 *)&($c.storage_.data_) ) #case 3 ( *($T4 *)&($c.storage_.data_) ) #case 4 ( *($T5 *)&($c.storage_.data_) ) #case 5 ( *($T6 *)&($c.storage_.data_) ) #case 6 ( *($T7 *)&($c.storage_.data_) ) #case 7 ( *($T8 *)&($c.storage_.data_) ) #case 8 ( *($T9 *)&($c.storage_.data_) ) #case 9 ( *($T10 *)&($c.storage_.data_) ) ) ) }

3 8

Fixed point structure size
by Soren Holstebroe 25 Jun '09

25 Jun '09

Hi, An important feature of the fixed point template is that it takes up no more space than the underlying integer. It should be possible to use reinterpret_cast to convert a third party integer pointer (representing fixed ints) to a fixed point template pointer. The way I ensure that in my fixed point template is with a #pragma: #pragma pack(push, 1) ... template struct ... #pragma pack(pop) This is supported by MSVC++ as well as gcc. However it is only defacto standard, so it might not work on any other compiler. Is there a more standard way to make sure that the struct is not padded to some memory alignment size? Soren

2 1

Re: [boost] Fixed point integer proposal
by Soren Holstebroe 25 Jun '09

25 Jun '09

> For example, does a(24bit) x b(24bit) -> c(24bit), or c(48bit)? > > My preference is to be explicit about these issues, meaning 24bit x 24bit -> > 24 bit. If you want more, you cast the operands first. Similarly there > were some questions on division. In my template N bit x N bit equals N bit per default. The number one design criteria was speed. Why would you use fixed point instead of floats if not for speed? I agree that you should be explicit if you want to promote the return type of a multiplication. That said, my template actually work with a promotion framework I wrote, where you can specify the promoted type of different kind of operations for different types. In the image processing library where the class was used, the promotion framework was set to promote N bit * N bit to 2N bit, but only up till the maximum number of bits natively supported by the CPU architecture. It was combined with an overflow check in debug mode to avoid surprises when the promotion was at the bit loft. That worked pretty well (and speedy). > My implementation also uses boost::operators. In addition, I have 2 > versions, one which the bit-widths are set at compile time, and the other > set at runtime (I use the latter to expose to python). I can't see a way to support run time bit width without sacrificing performance. Soren

3 5

Re: [boost] Linear circular buffer
by Soren Holstebroe 25 Jun '09

25 Jun '09

Hi Dean, >> The boost library contains a circular buffer template by Jan Gaspar. It > I use it just fine in my high performance applications where I > maintain the most recent N timings from API calls. Although iteration > through the dataset may be a little painful, N is not large enough for > me to notice (100 and 1000) the pain. The calls run in sub-microsecond > time and the maintenance of automatically evicting older entries gives > me (the user) a good guarantee that the data I'm getting is > consistent. I think your example is from a scenario where buffer processing is not where most of the cpu time is spent. In that case Jan Gaspars circular buffer is just fine. In fact, if what you want to do is to aggregate a linear response (like an average function), all you have to do is to look at the item going out of the buffer and item going in, you wouldn't even have to look at whats in the middle of the buffer. If your use of circular buffers is in applications, where buffer processing is what the application is all about, then sub-microseconds matter, if you are talking about 1 billion times 5 microseconds vs 1 billion times 3 microseconds. One example is bioinformatics, where you want to drag a window across the whole 3+ gigabases genome and maybe calculate some entropy measure in that window. Another is FIR filters in DSP, where you produce an output by convolving each window with a second buffer. > I agree about read performance, but I don't think you ever need to > call 'linearize' if you don't intend to build a vector out of your > circular buffer. If your buffer processing is done by an external library, then you need to linearize. In image processing and DSP, that would be a very common situation. > Iterating through the container is O(N) where N is > the size of the container, and the check for borders is O(1); In the case where your buffer processing can use the iterators, the overall complexity is the same, but the constant is not. You save a border check if your buffer is linear. > I can imagine that you can use the modulo (%) function given that you know > the initial offset of the "first" entry in the buffer, and N being the > size of the buffer Modulo is (at least in the old days) calculated as the remainder of a division. That is much slower than a border check. > How about space efficiency then? I (the user) expect to have just 100 > elements' worth of memory used when I allocate 100 elements' worth of > a circular buffer at construction time (same goes for the STL vector). First, are you sure you get 100 elements allocated when you resize a vector to 100? A vector implementation might reserve a whole chunk of memory for you when resize to make the next potential reallocation faster. Anyway, my proposal is about speed and the allocation of, lets say 100, extra elements would not be an issue in all practical high throughput application I can think of. > Linear access time is nice especially if you intend to always just go > through the whole data structure everytime -- having said this I don't > think I'd necessarily want to pay for extra space usage if I can > absolutely avoid it. I have the exact opposite priority. I would not trade performance to save a few hundred bytes, that might have been allocated anyway by the allocator (or system paging or whatever). > How do you intend to implement the internal buffer then without having > to use more memory than necessary to store the elements? As discussed, you are, as far as I know, not guaranteed that with std::vector either in most implementations. Soren

1 0

Re: [boost] Fixed point integer proposal
by Soren Holstebroe 25 Jun '09

25 Jun '09

> 2009/6/25 Andrey Upadyshev <oliora(a)gmail.com> >> >> Yes, it is very interesting. I think it will be also useful in finance calculations. >> > > Actually, on that note, would it be possible to allow an arbitrary > scale factor instead of specifying a shift? It ought to still be as > efficient for power-of-two scales, on the assumption that compilers > optimize multiplication and division by such constants... I suppose that it would indeed be possible to use an arbitrary scale. If it is unclear if the compiler will optimize correctly, it should be straight forward to implement a scaling template with power-of-two as template specializations. Soren

1 0

OLE Automation date to local_date_time conversion
by Matthew Chambers 25 Jun '09

25 Jun '09

Hello fellow boosters, Under MSVC boost::date_time supports conversion from FILETIME, so it makes sense to also support conversion from the OLE automation date format, helpfully defined at: http://msdn.microsoft.com/en-us/library/system.datetime.fromoadate.aspx > The d parameter is a double-precision floating-point number that > represents a date as the number of days before or after the base date, > midnight, 30 December 1899. The sign and integral part of d encode the > date as a positive or negative day displacement from 30 December 1899, > and the absolute value of the fractional part of d encodes the time of > day as a fraction of a day displacement from midnight. d must be a > value between negative 657435.0 through positive 2958466.0. In fact, I don't see a good reason this function can't be included in a non-MSVC build too since it doesn't depend on the Win32 API in any way. The code to handle this conversion is quite ugly. Here is my code to do it: namespace boost { namespace date_time { //! Create a time object from an OLE automation date value. /*! Create a time object from an OLE automation date value. * The oa_date parameter is a double-precision floating-point number that * represents a date as the number of days before or after the base date, midnight, * 30 December 1899. The sign and integral part of oa_date encode the date as a * positive or negative day displacement from 30 December 1899, and the absolute * value of the fractional part of oa_date encodes the time of day as a fraction of a * day displacement from midnight. oa_date must be a value between * negative 657435.0 through positive 2958466.0. */ template<class time_type> inline time_type time_from_OADATE(double oa_date) { typedef typename time_type::date_type date_type; typedef typename time_type::date_duration_type date_duration_type; typedef typename time_type::time_duration_type time_duration_type; using boost::math::modf; static const date_type base_date(1899, Dec, 30); static const time_type base_time(base_date, time_duration_type(0,0,0)); int dayOffset, hourOffset, minuteOffset, secondOffset; double fraction = fabs(modf(oa_date, &dayOffset)) * 24; // fraction = hours fraction = modf(fraction, &hourOffset) * 60; // fraction = minutes fraction = modf(fraction, &minuteOffset) * 60; // fraction = seconds modf(fraction, &secondOffset); time_type t(base_time); t += time_duration_type(hourOffset, minuteOffset, secondOffset); t += date_duration_type(dayOffset); return t; } } } Here are some basic unit tests: template<typename time_type> void test_time_from_OADATE(std::ostream* os_ = NULL) { typedef typename time_type::date_type date_type; typedef typename time_type::date_duration_type date_duration_type; typedef typename time_type::time_duration_type time_duration_type; using namespace boost::date_time; if (os_) *os_ << "OADATE: 0.0 -> " << time_from_OADATE<time_type>(0.0) << endl; unit_assert(time_from_OADATE<time_type>(0.0) == time_type(date_type(1899, Dec, 30), time_duration_type(0,0,0))); if (os_) *os_ << "OADATE: 1.0 -> " << time_from_OADATE<time_type>(1.0) << endl; unit_assert(time_from_OADATE<time_type>(1.0) == time_type(date_type(1899, Dec, 31), time_duration_type(0,0,0))); if (os_) *os_ << "OADATE: -1.0 -> " << time_from_OADATE<time_type>(-1.0) << endl; unit_assert(time_from_OADATE<time_type>(-1.0) == time_type(date_type(1899, Dec, 29), time_duration_type(0,0,0))); if (os_) *os_ << "OADATE: 2.0 -> " << time_from_OADATE<time_type>(2.0) << endl; unit_assert(time_from_OADATE<time_type>(2.0) == time_type(date_type(1900, Jan, 1), time_duration_type(0,0,0))); if (os_) *os_ << "OADATE: 2.25 -> " << time_from_OADATE<time_type>(2.25) << endl; unit_assert(time_from_OADATE<time_type>(2.25) == time_type(date_type(1900, Jan, 1), time_duration_type(6,0,0))); if (os_) *os_ << "OADATE: -1.25 -> " << time_from_OADATE<time_type>(-1.25) << endl; unit_assert(time_from_OADATE<time_type>(-1.25) == time_type(date_type(1899, Dec, 29), time_duration_type(6,0,0))); } I made it templated because its sibling function in boost\date_time\filetime_functions.hpp is templated, but it seems that ptime is the only stock type that will work. Local_time doesn't have the right constructors, at least. Thoughts? What's the procedure to add this officially to date_time? Thanks, -Matt Chambers

2 1

Random Numbers
by Dima 25 Jun '09

25 Jun '09

Hi all, this is my first post here. As far as I've seen boost provides standard random number generators for each distribution class. So, if you want a normally distributed class, you're automatically using Box-Mueller.... However, there are other ways of generating random numbers, such as using the inverse cumulative distribution function and evaluate it at a uniformly generated random number. It might be good to add this functionality to the library, since basically everything that is needed is there. Questions: Is this already in development? Is this something of interest? I'd be willing to participate somehow if this is not already in progress. Need first step guidance though. Best regards, Dima

2 1

[MultiArray] constness and documentation bugs
by Frank Mori Hess 25 Jun '09

25 Jun '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am able to modify a const multi_array through a multi_array_ref. For example: const boost::multi_array<int, 2> myarray(boost::extents[2][2]); boost::multi_array_ref<int, 2> myarrayref(myarray); myarrayref[0][1] = 2; IMO, trying to create a multi_array_ref from a const multi_array should fail to compile, only a const_multi_array_ref should work. Also, the reference doesn't include the public inheritance between multi_array, multi_array_ref, and const_multi_array in their class synopses. It is important because it seems to be the only reason you can do conversions from multi_array to multi_array_ref or const_multi_array_ref. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpDgtMACgkQ5vihyNWuA4VKgACg4+vF6iDMXKgROj6Wl0/sDDWl bZ8AoMDKVcGSY3SWGcRRvaxG6ik8VsPS =A71z -----END PGP SIGNATURE-----

1 0

Fixed point integer proposal
by Soren Holstebroe 25 Jun '09

25 Jun '09

Hi, Some years ago I wrote a fixed point template for transparent fixed point integer arithmetics and conversion. It worked well and performance was equal to that of native integer types, at least in MS VC++. The template takes a base type and the number of bits reserved for the fraction part and meta-programming works out boundary safe arithmetics and conversions. The template has been used in an image processing library, but lately I used it for seamless conversion of a 4+28 bit fixed point MAD-library decoded mp3-stream to the output buffer of the sound system, with a detour through a float-based sound effect. Would there be public interest in a template like that in the boost library? Soren

6 5

boost::test documentation typo
by Philippe Vaucher 25 Jun '09

25 Jun '09

Hi, The tutorial at http://www.boost.org/doc/libs/1_39_0/libs/test/doc/html/tutorials/new-year-… uingkeeps using BOOST_AUTO_EST_CASE when it obviously should be BOOST_AUTO_TEST_CASE. If no one replies to this mail saying he'll handle it I'll create a ticket on the trac. Philippe

1 0

Re: [boost] version conflicts: is there a solution?
by Artyom 25 Jun '09

25 Jun '09

There are many problems and this is not as simple as you think. Because if you have two versions of foo() defined in header files they may be exported and... collide. See: http://stackoverflow.com/questions/836875/ This problem is much more significant at UNIX platforms where all symbols are exported by default. Think of boost_1.38 boost/foo.hpp namespace boost { int foo() { return 1; } } boost_1.39 boost/foo.hpp namespace boost { int foo() { return 1; } } Now the library includes this header from 1.38 and automatically exports foo outside. Now, you use 1.39 and may get different values of foo(). You may do simple tests and find how bad this is. So... NO You can't use two versions of boost in same project especially at ELF platforms. ...... I just what to remind that there is a script I had written that renames boost namespace and macros preventing namespace collisions of two different versions of Boost. http://lists.boost.org/Archives/boost/2009/05/151816.php So take a look on it, and give feedback, so I would be able to submit it officially to Boost. Artyom > Having the definitions separated into different translation > units doesn't seem > to be enough to prevent ODR violations according to the > standard. It gives a > list of requirements for multiple definitions in different > translation units > in section 3.2.5. >

2 1

Linear circular buffer
by Soren Holstebroe 25 Jun '09

25 Jun '09

Hi, The boost library contains a circular buffer template by Jan Gaspar. It seems well written and STL robust, but I believe the design has some performance shortcomings in many practical usages. Every time I have used a circular buffer it has been to drag a window over a huge or real time dataset. If the dataset is non real-time and small enough to be contained in memory, there is no practical need for a circular buffer, since the window data pointer can just be dragged in memory along the full length of the dataset. In many algorithms using a dragged window, you would need to process the full length of the window for each time the window is moved. E.g. convolving signal data. Thus, you read from the window a lot more than you write. To maximize performance of your window reading and to utilize external libraries, you need linear access to the data. While Gaspar's circular buffer provide a linearize method, it requires a full reorganization of the contained data. This yields an O(N*M) efficiency, just for dragging the window (size N) over the data (size M). For internal use, the circular buffer provides iterators, but each iteration requires an internal buffer check, in order to wrap around the buffer border. Since the nature of a circular buffer in most practical scenarios (at least that I can think of) is to be involved in the processing of large amount of data, read performance is important. If you allow the internal buffer to allocate more memory than the size of the circular buffer, you can reduce the number of times you need to reorganize the internal buffer to make it linear readable. If you allocate N items more than the circular buffer size, you only need to reorganize every N+1 pushes to the window. Thus, allocating additional 100 items will reduce the reorganization overhead to 1%. I have written to Jan Gaspar, who recognizes that the buffer is not efficient for linear use, but he hasn't got the time anymore to add that feature. Is a circular buffer variant with linear access at a low maintenance cost something that would have public interest? Soren

2 1

Boost.Containers? (WAS Re: Proposal: Monotonic Containers - Comparison with boost::pool, boost::fast_pool and TBB)
by Dean Michael Berris 24 Jun '09

24 Jun '09

On Wed, Jun 24, 2009 at 10:40 AM, Christian Schladetsch<christian.schladetsch(a)gmail.com> wrote: > > What do people think of moving boost::interprocess::containers to > boost::containers? These containers are not really specific to interprocess? > I think this can easily be done through 'using' declarations: namespace boost { namespace containers { using boost::interprocess::list; using boost::interprocess::vector; /* ... */ } } I don't think it should move though to support earlier applications that are already using the interprocess namespace for the containers. -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

4 6

[range][rangex] Joining two unrelated ranges?
by Dean Michael Berris 24 Jun '09

24 Jun '09

Hi Guys, I was wondering if a utility that allows the encapsulation (and merging) of two ranges is already part of RangeEx? I was thinking along the lines of: vector<int> a, b; // populate a, populate b auto r = concat(a, b); // concatenates the ranges into a single range set<int> c(begin(r), end(r)); // r looks like a single forward range I'm not sure if this is already supported in Boost.Range and it'd be nice to know if this is already in RangeEx. TIA -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

8 12

boost::compressed_bitset
by Zachary Turner 24 Jun '09

24 Jun '09

I know there's over a zillion bitset implementations, but often times I have found myself in need of a bitset that is efficient (space-wise) at storing millions, billions, or even trillions (no joke) of bits. For this I have developed an in-house class which stores bits in a structure vaguely reminiscent of a "T-Tree" (http://en.wikipedia.org/wiki/T_tree) You can think of it basically as an std::map<boost::uint64_t, boost::uint64_t> where <key, value> represents the *interval* of bits [key, key+value-1]. So it's basically run-length encoded, with logarithmic lookups instead of linear lookups. Obviously the worst case scenario is where bits alternate 10101... throughout the entire bitset, and this structure will be terrible in that case. But where there are frequent runs of 0 and 1 bits, this gives orders of magnitude savings in space. Since a map is sorted on key, it's still a valid binary search tree and one can find the node for the k'th bit by map::lower_bound(k) and quickly check whether the bit is set by testing whether k is in [iter->first , iter->first+iter->second). The most difficult part is insertion / deletion since it involves splitting (or merging) intervals and rebalancing but the complexity is still no worse than that of a normal rebalancing avl tree. I almost exclusively use this structure in a way that interval nodes represent sequences of 1 bits, but it can just as easily be used the other way around, where intervals represent sequences of 0 bits. In fact now that I think about it probably doesn't even matter. Performing bitwise operations on such a structure is very fast. All you need to do is expand / reduce the intervals appropriately. Lookup / assignment is obviously not constant time but of course that is the tradeoff. Forward / reverse iteration is still very fast however as you only need to take the non-constant time hit once on begin(). It is also very fast to iterate only 1 bits or only 0 bits for the same reason, which can be quite slow with normal bitsets. The implementation I currently have is very unsuitable for boost for many reasons, but if there is enough interest I will (slowly) work on adapting this to be more generic / usable by a wider audience, of course with suggestions and input from the community. Zach

6 9

Re: [boost] version conflicts: is there a solution?
by Artyom 24 Jun '09

24 Jun '09

Hi, Take a look on this namespace renaming script: http://lists.boost.org/Archives/boost/2009/05/151816.php It should work, not sure about correctness of build system. I consider to submit it officially once it polished, but it seems to work. Artyom --- On Wed, 6/24/09, Lewis Hyatt <lhyatt(a)gmail.com> wrote: > From: Lewis Hyatt <lhyatt(a)gmail.com> > Subject: [boost] version conflicts: is there a solution? > To: boost(a)lists.boost.org > Date: Wednesday, June 24, 2009, 3:49 AM > Hi Everyone- > > This has been discussed before > (http://thread.gmane.org/gmane.comp.lib.boost.devel/180008) > but I think my > question is along a slightly different line so I thought I > would ask about it. > Let's say I want to compile and distribute a library > (without the source), and I > happen to use some boost header-only libraries as an > implementation detail in > some of my functions. None of the headers associated with > my library include > boost headers; it's purely an internal detail. > > Now, it seems to me that users of my library will still > have to be aware of the > fact that I used boost in my implementation -- > specifically, if they happen to > use different versions of the same boost libraries in their > code, then the ODR > is violated and the behavior is undefined. > > I realize this isn't a boost-specific problem (it would > affect any library of > template functions), but I am wondering if there is a > boost-specific solution > already worked out? Has anyone thought about this? It seems > to me that in this > case, what would be ideal would be if I could do: > > #define BOOST_NAMESPACE some_unique_namespace_for_boost > #include "boost/algorithm/string.hpp" > BOOST_NAMESPACE::shared_ptr<void> x; //or whatever > > Then I can insure there are no ODR violations and I don't > need to bother users > of my library with the fact that I used boost at all. > > Other than the sheer annoyance of having to go through all > the boost code to use > this macro, is there a strong downside to this approach? > > Alternatively, I could try: > > namespace { > #include "boost/..." > } > > But I don't know, could this work? Or are there boost > headers that rely on fully > qualified references like ::boost::algorithm::whatever? > > I'd appreciate anyone's thoughts on this issue, thanks! > > -Lewis > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Re: [boost] Proposal: Monotonic Containers - Comparison with boost::pool, boost::fast_pool and TBB
by Christian Schladetsch 24 Jun '09

24 Jun '09

> Updated tests (more of them, better formatting of results) for > https://svn.boost.org/svn/boost/sandbox/monotonic/libs/monotonic/test/compa… here > http://tinyurl.com/m83vll for GCC and here http://tinyurl.com/n9g8jv for > MSVC. I also added a column for std::allocator/mono. Have added comparison against TBB, as requested. These results are at the same location as linked to above. Christian.

7 39

Re: [boost] boost namespace
by Artyom 24 Jun '09

24 Jun '09

> I need to use two versions of boost in my > application. One the libs I link > against is statically linked against boost 1.34 and I'd > like to use 1.35's > asio library. First of all Asio comes as stand alone library outside of boost namespace. So, you may just use it as is or use namespace renaming: #ifdef USE_BOOST_ASIO #include <boost/asio.hpp> namespace netio = boost::asio; using boost::system::error_code; using boost::system::system_error; #else #include <asio.hpp> namespace netio = asio; using asio::error_code; using asio::system_error; #endif And then just relate to netio::... so you would keep an ability to upgrade to boost asio in future. This is the way I build CppCMS http://cppcms.sourceforge.net/ conditionally using Boost 1.33.1 and Asio or boost 1.35 and above only. > I believe I can make both versions > co-exist if I can manage > to rename boost 1.35's namespace to something like > boost135. > Take a look on a script I had written once: http://lists.boost.org/boost-build/2009/05/21911.php But note! boost 1.35 and 1.34 are not compatible nither ABI nor API. So you **must** not mix them in same module! This may be very tricky. So you can't use boost in interfaces between modules that use different versions of boost. Artyom

2 1

[Review Request] polygon
by Simonson, Lucanus J 23 Jun '09

23 Jun '09

Gtl was renamed to boost::polygon. The source is available at https://svn.boost.org/svn/boost/sandbox/gtl/boost/polygon/ And the documentation is at https://svn.boost.org/svn/boost/sandbox/gtl/doc/index.htm I have a review manager and a number of prospective reviewers lined up, so we should be able to at least get the review started smoothly. I would like the review wizard to contact me off list to discuss which dates are more suitable to have the review given my personal schedule. Thanks, Luke

2 4

SafeInt code proposal
by Omer Katz 23 Jun '09

23 Jun '09

A friend and I have started working on a SafeInt library which we hope will be included in Boost the library is composed of a template class, which excepts existing integer types as a parameter, and an exception class. not all operators have been implemented and there is still work to be done on the library, but we have reached a stage in which at least the basic operators are ready and tested. I've attached to this thread a zip file containing the code for the library and a tester we wrote (as an example for how the class should be used) I've also uploaded it to the boost vault. We would appreciate it if you took the time to review our code and give us your comments, tips and opinions (either as a reply to this thread or by email - omerktz(a)gmail.com) thanks, Omer Katz and Zil Levi

8 16

[task] boost.task-0.2
by k-oli＠gmx.de 23 Jun '09

23 Jun '09

Hi, I've uploaded a new version of boost.task (boost.threadpool) to boost vault http://www.boost-consulting.com/vault/index.php?directory=Concurrent Programming Changes: - detail/atomic.hpp with atomic_exchange (gcc + x86|ppc) - handle< R > with new function get_future() returning reference to internal shared future - moved execution-policies new_thread, own_thread and as_sub_task in separat headers - async() with as_sub_task as default execution-policy - functions interrupt_and_wait_until() and interrupt_and_wait_for() from handle< R > returning boolean indicating if op. succeeded or timed out - move semantics for task< R > and static_pool< R > - new function interrupt_all_worker() for static_pool< Channel > in order to interrupt all worker-threads without invalidating the pool - default_pool() removed because thread_resource_error exceptions thrown by static pool - support of processor-binding for FreeBSD (>=7.1) - tests updated - examples updated - documentation updated regards, Oliver

1 0

How to speed up the djikstra graph
by Lennart Berg 23 Jun '09

23 Jun '09

Hi Everybody I have had the pleasure of using the boost graph library for my project now, but I have ran into some problems, that I hope you can guide me on. First of all, let me tell a little about the project. I am a third party developer for paradox interactive, making an expansion for one of their games. Now i have implemented the djikstra alghorithm to simulate the transport capacity of countries, and it works pretty well. However I still think that the speeds to be improved somewhat (takes about 1-2 secs to compute), to make it more playable. First of all the map consists of ~2500 provinces / vertexes each with 4-8 edges / neighbours. I Find all the provinces I can access and then add all neighbours from it as edges. Each edge is allocated a cost according to infrastructure, terrain and distance from orgin to destination. Each "round" of the game is an hour, so a day is effectively 24 rounds. Right now I make a new graph once every day, one separate graph for each country, and compute it for every country once a day. However as the game has up to 300+ countries that becomes a pretty harsh computational burden. Now pretty much every variable in this setup can change hourly. ( location of units, conquest / loss of provinces, destruction of infrastructure, expansion / repair of infrastructure) So the question is how I can improve this approach. Optimally the graph should be persistant and allow me to dynamically add / remove provinces and change the cost of the edges every hour (as I understand it the boost library allows that right now with vertex_clear / add etc.), and giving new values without recomputing every single edge in the graph 300 times every hour. Is that possible? And if how would that be done? Thanks in advance Lennart Berg

8 18

[BGL] boost::add_vertex - add unique vertexes to graph
by Mariusz Kwiczala 23 Jun '09

23 Jun '09

Hi, Currently I externally check if vertex exist in graph. But it is look like boost::add_vertex can check internally if vertexes are unique. if (optional<vertex_descriptor> v = g.vertex_by_property(get_property_value(p, vertex_bundle))) return *v; Could you send me any example where boost::add_vertex just return already created vertex (line: "return *v") instead of create new one? boost_1_39_0\boost\graph\detail\adjacency_list.hpp contain: template <class Graph, class Config, class Base> inline typename Config::vertex_descriptor add_vertex(const typename Config::vertex_property_type& p, vec_adj_list_impl<Graph, Config, Base>& g_) { typedef typename Config::vertex_descriptor vertex_descriptor; Graph& g = static_cast<Graph&>(g_); if (optional<vertex_descriptor> v = g.vertex_by_property(get_property_value(p, vertex_bundle))) return *v; typedef typename Config::stored_vertex stored_vertex; g.m_vertices.push_back(stored_vertex(p)); g.added_vertex(g.m_vertices.size() - 1); return g.m_vertices.size() - 1; } Best regards, Mariusz

2 1

Re: [boost] GSoC Unicode library: second preview
by Artyom 23 Jun '09

23 Jun '09

> Of course, the library works with UTF-8 and UTF-32 just as > well, it makes no difference to the generic algorithms > (which don't exist yet, but expect substring searching and > the like), it's up to you to choose what makes the most > sense to use for your situation (for example, you may choose > to use UTF-8 because you need to interact a lot with > programming interfaces expecting that format). > Ok, this is really good. > They should be fairly easy to find. > Either you're using the algorithm that does the task > correctly, or you're fiddling with the encoding by hand > which is likely to be wrong. They are easy to find in the Unicode aware unit tests but not in real program. I did once a small test, what Unicode aware programs support characters outside of BMP, i.e. I tested a glyph that was encoded as surrogate pair in UTF-16... The results were total disaster: - Windows standard dialogs: displayed character correctly but every operation like deletion related to is as two pairs. For example file name dialog had problems. - Same behavior in notepad or any standard text-area widgets didn't work correctly. - Qt3 hadn't supported surrogate pairs at all (in Qt4 most of it was fixed) displaying two square "glyphs". - Opera Web browser, had similar problems with editing and displaying such characters. So... There is a huge problem with this encoding, because such simple QA test shouldn't give such bad results for such big amount of programs. Also, all programs that used internally utf-8 or utf-32 had passed these tests very well. So I really **do not** suggest recommending this encoding as "best" one for internal use. Artyom

1 0

boost namespace
by Igor S 22 Jun '09

22 Jun '09

Hi Everyone. I need to use two versions of boost in my application. One the libs I link against is statically linked against boost 1.34 and I'd like to use 1.35's asio library. I believe I can make both versions co-exist if I can manage to rename boost 1.35's namespace to something like boost135. I know this project could be time-consuming so I'd like you know your thoughts. What changes would I need to make to the build system? Thanks. -- Igor

1 0

GSoC Unicode library: second preview
by Mathias Gaunard 22 Jun '09

22 Jun '09

Here is the documentation of the current state of the Unicode library that I am doing as a google summer of code project: http://blogloufoque.free.fr/unicode/doc/html/ This preview comes a bit later than I planned, but after struggling to keep the documentation and the code in sync I decided to move to automatic documentation generation with doxygen, which I had trouble setting up due to my experience. The reference still lacks a lot of information, however. The library only features UTF support and the Unicode Character Database (not fully updated to latest Unicode version) at the moment, but grapheme clusters and normalization support will come very soon. I would like to get feedback on the UTF codecs, the various concepts (Pipe, Consumer, BoundaryChecker) and the whole approach of lazy ranges. Grapheme clusters (and other text boundaries facilities) support will also be provided in terms of the Consumer and BoundaryChecker concepts. The library features lazy ranges similar to that of Boost.RangeEx, and I used one of the naming conventions that was proposed during review: u8_encode is the eager algorithm, u8_encoded is the lazy one. Since it wasn't really agreed which naming to use for RangeEx, I would like this to be discussed as well.

4 7

Spice up your mobile
by lokesh755＠gmail.com 22 Jun '09

22 Jun '09

1 0

proposal for boost dynamic java styled , efficient class loading library
by dominic ibeme 22 Jun '09

22 Jun '09

Hello.. i wrote a class library that allows C++ classes to be loaded seamlessly using the class names.. just like in java... the library makes heavy use of the BOOST PREPROCESSOR library and is very stable, simple and light... however, it is subject to expansion... and review... i would like to share this library with the boost community as a sign of appreciations for their tremendous offerings... please direct me on how to go about this..

6 5

Re: [boost] GSoC Unicode library: second preview
by Artyom 22 Jun '09

22 Jun '09

Hello, > Here is the documentation of the > current state of the Unicode library that I am doing as a > google summer of code project: > http://blogloufoque.free.fr/unicode/doc/html/ [snip] Where is the source code? .... Some notes: > UTF-16 ... This is the recommended encoding for dealing with > Unicode internally for general purposes To be honest, it is most error prone encoding to work with Unicode: 1. It is variable length encoding 2. There surragate charrecters are quite rare and thus it is very hard to find bugs related with it. It was mostly born as a "mistake" at the beggining of the unicode when it was beleved that 16bit is enough for signle code point. So many software platforms adopted 16 bit encoding that supported only BMP, As a result you can **easily** find **huge** amount of bugs in the code that uses utf-16, In most of cases such bugs are hard to track because these code points are rare. For example, try to edit file-name in Windows with a charrecter that not in BMP you would see that you need to press "delete" twice, try to write such charecter in Qt3 application... that would just not work; There are many examples of it. So, I would be aware of recommending this encoding as internal encoding, just because many platforms use it. > UTF-32 ... This encoding isn't really recommended As I mentioned above, it is not quite true, it is much safer encoding to work with, So I would recommend not to write such "suggestions". More notes: ----------- - For boundary checks I'd suggest to use ICU or Qt4 like API: iterate over string and return each time next bound. Not check if there is a bound on specific character. - Examples and More description is required Artyom

3 3

Proposal: Monotonic Containers
by Christian Schladetsch 21 Jun '09

21 Jun '09

Hello, There is a need in high-performance realtime software to use containers that may only grow in size. These are typically reset at the end of each update cycle. The proposal here consists of a base 'monotonic allocator', which takes its storage from a buffer that you provide. Allocations are made from this buffer, and deallocation only calls an object's destructor; no actual memory-management is performed at all. This is very useful for realtime systems that have to do things like, for example, physics or renderering systems. These systems build up lists and other containers over the period of an update frame, however at the end of that frame the storage can just be reset. The benefit of using this system over a normal std::allocator is that memory is not fragmented, and memory allocation and deallocation is basically optimal. Within the package are: boost.monotonic.inline_storage boost.monotonic.list boost.monotonic.vector boost.monotonic.map boost.monotonic.set boost.monotonic.ptr_list I didn't bother adding the other ptr_* containers yet. The files for the proposal are in the vault at http://www.boostpro.com/vault/index.php?action=downloadfile&filename=Monoto… . I'd be happy to address any issues or comments. There are some improvements that could be made. Regards, Christian.

24 156

DateTime conversion to tm problem?
by Maciej Sobczak 21 Jun '09

21 Jun '09

Hi, The posix_time::to_tm function clears the date fields of the std::tm structure. Having zeros on year, month and day fields represent the 1900-01-00 date according to the std::tm conventions, which is a date that did not exist. Using such value with other APIs might result in out of range conditions. Is it considered to be a problem? What about setting tm_mday to 1 instead (which would represent 1900-01-01 - that is, the first legal date)? Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com

3 4

[BOOST_ASSERT] any one against improving debug support?
by Thorsten Ottosen 21 Jun '09

21 Jun '09

Hi, The current difinition of BOOST_ASSERT is a pain to use with the debugger and Boost.Test because it doesn't trigger a break-point. Does anyone object to defining it like this in <boost/assert.hpp> #if (BOOST_MSVC >= 1400) #include <crtdbg.h> #define BOOST_ASSERT _ASSERTE #endif ? -Thorsten

5 12

policy on compiler warnings?
by Kenny Riddile 21 Jun '09

21 Jun '09

Does Boost have any documented policy on compiler warnings? I, like a lot of people, use warning level 4 when compiling with MSVC. I also usually turn on warnings as errors, but I cannot easily do that since many Boost libraries emit warnings at warning level 4 under MSVC9. I realize that warnings aren't really standardized across compilers, but I would still expect a project that touts itself as "...one of the most highly regarded and expertly designed C++ library projects in the world." to strive for zero warnings under a commonly used setting on one of its official test compilers. I have created the following tickets regarding warnings that are currently causing me trouble: https://svn.boost.org/trac/boost/ticket/3193 https://svn.boost.org/trac/boost/ticket/3194 https://svn.boost.org/trac/boost/ticket/3195 https://svn.boost.org/trac/boost/ticket/3196 https://svn.boost.org/trac/boost/ticket/3197 Thanks, Kenny Riddile

1 1

[config] missing include for FreeBSD
by k-oli＠gmx.de 20 Jun '09

20 Jun '09

Hi, boost/config/platform/bsd.hpp misses include sys/param.h. Without this header __FreeBSD_version can not be evaluated. regards, Oliver

1 0

convert boost::mpl::vector_c<int> into const int[]
by Peter Foelsche 20 Jun '09

20 Jun '09

Is there any way to convert a boost::mpl::vector_c<int> into a const int[] without using boost::mpl::for_each?

3 2

[task] Minor issues
by Chard 19 Jun '09

19 Jun '09

I've been trying out the task library from the vault and have found a few issues. The code does not compile with MSVC 7.1; this appears to be a compiler non-conforming issue rather than code error: The contained impl_pool class inside detail::worker requires access to the static pool class, but even though the detail::worker class is a friend, VC7 doesn't allow impl_pool access. Adding: template< typename Pool > friend class detail::worker::impl_pool; to the class in static_pool.hpp gets around this. <> I believe there is another error in the task config.hpp file; it has the line: # if defined(BOOST_TASK_DYN_DLL) || defined(BOOST_ALL_DYN_LINK) I believe BOOST_TASK_DYN_DLL should be BOOST_TASK_DYN_LINK, following the guide from the main boost config.

2 1

[polygon] GTL name change and pre-review issues
by Simonson, Lucanus J 19 Jun '09

19 Jun '09

I am changing the name of my library from GTL (Geometry Template Library) to boost::polygon and narrowing the scope from "computational geometry" to "polygon manipulation". This scope precisely describes the current scope of what is implemented. It also clarifies the position of the library relative to similar proposals. I have already moved the code into boost::polygon namespace, added dependency on boost::enable_if and gotten the unit tests compiling and passing in windows with the new namespace and dependency. I wanted to ask about the gtl_yes and gtl_no types I use for metaprogramming, defined thus: struct gtl_no { static const bool value = false; }; struct gtl_yes { typedef gtl_yes type; static const bool value = true; }; I need to define type as gtl_yes in gtl_yes and leave it undefined in gtl_no to enable early SFINAE to work around an EDG compiler bug: template <typename geometry_type_1, typename coordinate_type_1> typename enable_if< typename gtl_and< typename is_mutable_polygon_90_set_type<geometry_type_1> #ifdef __ICC ::type #endif ::type, typename gtl_same_type<typename geometry_concept<coordinate_type_1>::type, coordinate_concept>::type> #ifdef __ICC ::type #endif ::type, geometry_type_1>::type operator-(const geometry_type_1& lvalue, coordinate_type_1 rvalue) { geometry_type_1 retval(lvalue); retval -= rvalue; return retval; } Here I am short circuiting template instantiation in the case that ICC (using EDG) is detected by calling the gtl_yes/gtl_no metafunction. This would be a syntax error in MSVC, of course. I need to do this for arithemetic operators because EDG incorrectly tries to match them to operators between pointer and unnamed enum type values in the stl and throws a syntax error when I refer to the unnamed enum type in the declaration of the operator. By SFINAEing out early I can work around this bug, which is fixed in the latest EDG versions, but I need to support older versions as well. Is it acceptable to continue to use my own definitions for true_type/false_type, or does someone have a suggestion for a different workaround that will allow me to replace gtl_yes/gtl_no with boost::true_type, boost::false_type? By the way, complete documentation for my library is now available at https://svn.boost.org/svn/boost/sandbox/gtl/doc/index.htm Feedback on the documentation before the formal review will help me get ready for the review. I'll be checking review ready code into the sandbox later today along with unit tests. If someone can point me to setup my unit test source file to work with the boost unit testing system I'd greatly appreciate it. Right now it just uses returning an error code to indicate test failure, and it is all or nothing in that sense. Regards, Luke

1 0

Proposed addition to the iterator library for iterating over all tuples.
by Alex Mendes da Costa 19 Jun '09

19 Jun '09

Hi folks: I quite often have to write code to do the following: Given N sequences, generate all the N-tuples s.t. the i'th element in each tuple is drawn from the i'th sequence. For example, if sequence S1 is { 1, 2, 3 } and sequence S2 is { 10, 20 }, I need to generate these tuples: (1, 10), (2, 10), (1, 20), (2, 20). I think this problem could be solved elegantly with a iterator similar to zip_iterator. I have some questions: (1) Is there already a way to do this in boost? (2) If not, would this be a worthwhile addition to the iterator library? (3) If so, could I contribute code for this, or must the existing library owners write it? (4) If so, how would I go about getting my code added? Most of the docs seem to be about submitting entire libraries, rather than extensions to existing libraries. Thanks, Alex

4 18

Boost.Bloom_filter now in Sandbox (WAS Re: Interest in a Bloom Filter?)
by Dean Michael Berris 19 Jun '09

19 Jun '09

On Mon, Jun 8, 2009 at 2:55 PM, Dean Michael Berris<mikhailberis(a)gmail.com> wrote: > On Mon, Jun 8, 2009 at 2:47 PM, Joaquin M Lopez Munoz<joaquin(a)tid.es> wrote: [snip] > > Thanks for your insights! I'll make the changes and then maybe put it > in the sandbox along with the documentation that I'll be working on. > The implementation is now available in Boost's Sandbox. You can check out the implementation along with the documentation via: svn co https://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/ Can someone please add this to the Libraries Under Construction page? I'd also like to request to add this to the formal review queue (if this qualifies for a fast track review, that would also be an option I'm open to). Thanks in advance, and I hope this helps. -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

9 33

[boost::noncopyable] compiler warnings with the -Weffc++ flags
by Anand Lakshminath 19 Jun '09

19 Jun '09

Hi, Deriving from the boost::noncopyable class generates warnings when I compile with the -Weffc++ (effective C++) flags. There are two types of warnings: 1) Non-virtual destructor warning (base class 'class boost::noncopyable_::noncopyable' has a non-virtual destructor). Here's a testcase: #include <boost/noncopyable.hpp> #include <iostream> namespace { class DontTreadOnMe : private boost::noncopyable { public: DontTreadOnMe() { std::cout << "defanged!" << std::endl; } }; // DontTreadOnMe } // unnamed namespace main() { DontTreadOnMe object1; } g++ -I/vobs/3rdparty/BOOST/boost_1_38_0/boost_inc -Weffc++ main.cpp main.cpp:10: warning: base class 'class boost::noncopyable_::noncopyable' has a non-virtual destructor 2) I have disabled the copy constructor/assignment operator in a class that has pointer data members by deriving from boost::noncopyable. However, the compiler generates the following warning: warning: 'class<unnamed>::DontTreadOnMe' has pointer data members main.cpp:10: warning: but does not override '<unnamed>::DontTreadOnMe(const <unnamed>::DontTreadOnMe&)' This kind of forces me to explicitly override the copy constructor and assignment operator instead of deriving from noncopyable. Here's the full test case: #include <boost/noncopyable.hpp> #include <iostream> namespace { class DontTreadOnMe : private boost::noncopyable { public: DontTreadOnMe() { std::cout << "defanged!" << std::endl; } private: char* buf; }; // DontTreadOnMe } // unnamed namespace main() { DontTreadOnMe object1; } g++ -I/vobs/3rdparty/BOOST/boost_1_38_0/boost_inc -Weffc++ main.cpp main.cpp:10: warning: base class 'class boost::noncopyable_::noncopyable' has a non-virtual destructor main.cpp:10: warning: 'class<unnamed>::DontTreadOnMe' has pointer data members main.cpp:10: warning: but does not override '<unnamed>::DontTreadOnMe(const <unnamed>::DontTreadOnMe&)' main.cpp:10: warning: or 'operator=(const <unnamed>::DontTreadOnMe&)' Is there a workaround and/or fix? I am using gcc 4.0.1. Thanks, Anand

5 11

Re: [boost] Proposal: Monotonic Containers - Comparison with boost::pool and boost::fast_pool
by Christian Schladetsch 19 Jun '09

19 Jun '09

Hello, I ran the following test http://tinyurl.com/l89llq This compares std::allocator, boost::fast_pool_allocator, boost::pool_allocator and monotonic::allocator. The only test in which monotonic allocation fails to perform faster than the other schemes is thrash_pool_sort_list_int against fast_pool. The reason for this is that fast_pool effectively stores a pre-generated array of correctly-aligned chunks, so allocation against this is a pointer increment. Fast pool can do this, because it stores different pools for different-sized blocks. Rather, the monotonic allocator uses a single buffer for all allocations, so it has to align each time. There is an optimisation I can introduce between a monotonic::allocator<T> and the underlying storage that can improve performance slightly for this case. The downside for fast_pool is that the user has to keep track of each different-sized chunk that can possiblly be used, and it doesn't differentiate on type. From the documentation: "Since the size of T is used to determine the type of the underlying Pool, each allocator for different types of the same size will share the same underlying pool. The tag class prevents pools from being shared between pool_allocator and fast_pool_allocator. For example, on a system where sizeof(int) == sizeof(void *), pool_allocator<int> and pool_allocator<void *> will both allocate/deallocate from/to the same pool." This is problematic for cases where a given allocator is rebound to a different type, as happens for the node-based containers. I am unsure what the best practise is here, or if boost::pool and boost::fast_pool simply leak in this case. You will also not that fast_pool is very slow for thrash_pool_sort, which sorts different-sized vectors. Here, the same mechanism that made it %10-%20 faster than monotonic using lists makes it many times slower when using vectors. In the following tables, the first row is the maximum number of elements in the relevant container; all internal columns are in seconds. Results for MSVC /O2. thrash_pool count fast_p pool std mono local fp/mono pool/mono 10 0.015 0.019 0.02 0.005 0.005 300% 380% 210 0.035 0.037 0.038 0.01 0.009 350% 370% 410 0.051 0.055 0.04 0.013 0.013 392.3% 423.1% 610 0.069 0.072 0.046 0.017 0.017 405.9% 423.5% 810 0.088 0.093 0.048 0.021 0.022 419% 442.9% 1010 0.105 0.111 0.053 0.026 0.028 403.8% 426.9% 1210 0.125 0.138 0.06 0.031 0.03 403.2% 445.2% 1410 0.142 0.143 0.061 0.034 0.033 417.6% 420.6% 1610 0.164 0.162 0.069 0.038 0.038 431.6% 426.3% 1810 0.179 0.184 0.072 0.043 0.042 416.3% 427.9% thrash_pool_iter count fast_p pool std mono local fp/mono pool/mono 10 0.027 0.032 0.032 0.012 0.011 225% 266.7% 210 0.152 0.146 0.118 0.102 0.101 149% 143.1% 410 0.27 0.263 0.199 0.191 0.189 141.4% 137.7% 610 0.4 0.372 0.286 0.283 0.284 141.3% 131.4% 810 0.509 0.487 0.376 0.372 0.372 136.8% 130.9% 1010 0.64 0.598 0.474 0.474 0.464 135% 126.2% 1210 0.765 0.721 0.579 0.563 0.592 135.9% 128.1% 1410 0.895 0.841 0.632 0.662 0.652 135.2% 127% 1610 0.991 0.923 0.701 0.714 0.759 138.8% 129.3% 1810 1.185 1.096 0.793 0.91 0.842 130.2% 120.4% thrash_pool_sort count fast_p pool std mono local fp/mono pool/mono 10 0.01 0.002 0.002 0.001 0.001 1000% 200% 110 0.091 0.011 0.011 0.008 0.009 1138% 137.5% 210 0.233 0.023 0.02 0.017 0.016 1371% 135.3% 310 0.495 0.034 0.026 0.025 0.025 1980% 136% 410 1.347 0.044 0.036 0.035 0.034 3849% 125.7% 510 1.411 0.058 0.045 0.042 0.042 3360% 138.1% 610 2.928 0.067 0.055 0.052 0.053 5631% 128.8% 710 2.54 0.078 0.064 0.065 0.061 3908% 120% 810 6.175 0.089 0.073 0.07 0.07 8821% 127.1% 910 3.976 0.104 0.081 0.082 0.08 4849% 126.8% thrash_pool_sort_list_int count fast_p pool std mono local fp/mono pool/mono 10 0.006 0.011 0.011 0.003 0.004 200% 366.7% 210 0.057 0.087 0.088 0.06 0.059 95% 145% 410 0.102 0.214 0.169 0.135 0.125 75.56% 158.5% 610 0.156 0.367 0.254 0.199 0.196 78.39% 184.4% 810 0.211 0.588 0.346 0.26 0.261 81.15% 226.2% 1010 0.269 0.837 0.459 0.351 0.35 76.64% 238.5% 1210 0.347 1.16 0.547 0.441 0.431 78.68% 263% 1410 0.406 1.504 0.632 0.54 0.511 75.19% 278.5% 1610 0.481 1.882 0.728 0.583 0.587 82.5% 322.8% 1810 0.559 2.32 0.817 0.671 0.674 83.31% 345.8% thrash_pool_map_list_unaligned count fast_p pool std mono local fp/mono pool/mono 10 0.002 0.003 0.004 0.001 0.001 200% 300% 210 0.033 0.083 0.079 0.029 0.029 113.8% 286.2% 410 0.067 0.214 0.164 0.058 0.061 115.5% 369% 610 0.102 0.404 0.246 0.091 0.092 112.1% 444% 810 0.139 0.646 0.338 0.122 0.126 113.9% 529.5% 1010 0.174 0.936 0.415 0.155 0.16 112.3% 603.9% 1210 0.219 1.271 0.51 0.19 0.197 115.3% 668.9% 1410 0.253 1.675 0.594 0.23 0.237 110% 728.3% 1610 0.297 2.144 0.678 0.273 0.274 108.8% 785.3% 1810 0.339 2.692 0.874 0.402 0.313 84.33% 669.7% Results for GCC -O2 thrash_pool count fast_p pool std mono local fp/mono pool/mono 10 0 0.01 0 0.01 0 0% 100% 210 0.01 0.01 0.01 0 0 inf% inf% 410 0.01 0 0.01 0.01 0 100% 0% 610 0.01 0.01 0.01 0 0 inf% inf% 810 0.01 0 0.01 0.01 0 100% 0% 1010 0 0.01 0 0 0.01 nan% inf% 1210 0.01 0.01 0.01 0 0 inf% inf% 1410 0.01 0 0.01 0 0.01 inf% nan% 1610 0 0.01 0.01 0 0 nan% inf% 1810 0 0.01 0 0 0.01 nan% inf% thrash_pool_iter count fast_p pool std mono local fp/mono pool/mono 10 0.01 0.01 0 0.01 0 100% 100% 210 0.05 0.06 0.02 0.02 0.02 250% 300% 410 0.12 0.1 0.04 0.03 0.03 400% 333.3% 610 0.16 0.15 0.05 0.05 0.04 320% 300% 810 0.2 0.21 0.06 0.06 0.07 333.3% 350% 1010 0.25 0.25 0.07 0.08 0.08 312.5% 312.5% 1210 0.29 0.31 0.08 0.08 0.09 362.5% 387.5% 1410 0.33 0.35 0.1 0.08 0.1 412.5% 437.5% 1610 0.38 0.37 0.11 0.12 0.12 316.7% 308.3% 1810 0.43 0.45 0.12 0.13 0.13 330.8% 346.2% thrash_pool_sort count fast_p pool std mono local fp/mono pool/mono 10 0.01 0.01 0 0 0 inf% inf% 110 0.06 0.01 0.01 0.01 0.01 600% 100% 210 0.19 0.02 0.02 0.02 0.01 950% 100% 310 0.47 0.02 0.02 0.02 0.02 2350% 100% 410 0.69 0.04 0.04 0.03 0.02 2300% 133.3% 510 1.99 0.05 0.04 0.03 0.04 6633% 166.7% 610 1.65 0.06 0.04 0.04 0.04 4125% 150% 710 4.73 0.07 0.05 0.04 0.05 1.182e+04% 175% 810 2.28 0.07 0.07 0.06 0.06 3800% 116.7% 910 4.29 0.09 0.05 0.08 0.06 5362% 112.5% thrash_pool_sort_list_int count fast_p pool std mono local fp/mono pool/mono 10 0 0.01 0 0 0 nan% inf% 210 0.03 0.05 0.04 0.04 0.03 75% 125% 410 0.07 0.15 0.1 0.08 0.06 87.5% 187.5% 610 0.1 0.26 0.12 0.11 0.12 90.91% 236.4% 810 0.13 0.39 0.19 0.18 0.14 72.22% 216.7% 1010 0.17 0.57 0.24 0.19 0.2 89.47% 300% 1210 0.24 0.74 0.29 0.23 0.24 104.3% 321.7% 1410 0.26 0.98 0.36 0.26 0.28 100% 376.9% 1610 0.27 1.21 0.37 0.3 0.33 90% 403.3% 1810 0.35 1.51 0.43 0.35 0.37 100% 431.4% thrash_pool_map_list_unaligned count fast_p pool std mono local fp/mono pool/mono 10 0 0 0 0 0 nan% nan% 210 0.02 0.05 0.03 0.02 0.02 100% 250% 410 0.02 0.11 0.06 0.04 0.04 50% 275% 610 0.06 0.19 0.11 0.07 0.07 85.71% 271.4% 810 0.06 0.33 0.13 0.09 0.08 66.67% 366.7% 1010 0.09 0.51 0.17 0.11 0.11 81.82% 463.6% 1210 0.12 0.65 0.21 0.13 0.14 92.31% 500% 1410 0.15 0.93 0.25 0.14 0.14 107.1% 664.3% 1610 0.17 1.11 0.27 0.19 0.15 89.47% 584.2% 1810 0.18 1.35 0.33 0.21 0.21 85.71% 642.9% Regards, Christian

1 1

From Concept class to type traits
by joel 19 Jun '09

19 Jun '09

Is there any deep explanation on how the concept_check class from Boost:/Concept works ? I'm trying to see how to turn a concept into a traits but all my attempt are failing miserably and I think that's because I don't get how the concept check work in itself. Regards -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

5 6

Fwd: bug fix in boost/libs/python/pyste/src/Pyste/declarations.py
by YuQian Zhou (周宇前) 19 Jun '09

19 Jun '09

Hi, I was unable to reach Dave, and https://svn.boost.org/trac/boost/newticket doesn't work for me. ("Secure Connection Failed"). So I'm posting here, can anyone take a look this? thanks. ---------- Forwarded message ---------- From: YuQian Zhou (周宇前) <zhou(a)google.com> Date: 2009/6/15 Subject: Fwd: bug fix in boost/libs/python/pyste/src/Pyste/declarations.py To: dave(a)boost-consulting.com Hi Dave, Can you tell me where I should submit this change? Thanks. ---------- Forwarded message ---------- From: Bruno Oliveira <nicoddemus(a)gmail.com> Date: 2009/6/15 Subject: Re: bug fix in boost/libs/python/pyste/src/Pyste/declarations.py To: "YuQian Zhou (周宇前)" <zhou(a)google.com> Hi YuQian, Unfortunately I don't maintain Pyste anymore; I advise you to send this fix to the boost-python list, since I don't have commit privileges anymore (I think). Best Regards, On Mon, Jun 15, 2009 at 5:32 PM, YuQian Zhou (周宇前) <zhou(a)google.com> wrote: > > Hi Bruno, > > I found a bug in boost/libs/python/pyste/src/Pyste/declarations.py (I > tried the latest version (Version 1.39.0) from boost.org, it has the > same bug.) > > The bug is: when paring an anonymous struct, the name passed to a > Declaration object is None, then on > libs/python/pyste/src/Pyste/GCCXMLParser.py: line 57 > > def AddDecl(self, decl): > if decl.FullName() in self._names: > > The call to FullName() will concatenate name, line 53: > > return namespace + self.name > > TypeError: cannot concatenate 'str' and 'NoneType' objects > > I made a fix below, please let me know if it's correct, and you can > include in the release. > > Thanks. > > YuQian > > Below is a test file: > > $ cat test.h > > typedef int __jmp_buf; > > typedef struct > { > struct > { > __jmp_buf __cancel_jmp_buf; > int __mask_was_saved; > } __cancel_jmp_buf[1]; > void *__pad[4]; > } __pthread_unwind_buf_t __attribute__ ((__aligned__)); > > > here is the diff of libs/python/pyste/src/Pyste/declarations.py > > 16d15 > < _anonymous_name_counter = 0 > 33,36d31 > < global _anonymous_name_counter > < if name is None: > < name = 'anonymous_name_%s' % _anonymous_name_counter > < _anonymous_name_counter += 1

1 0

Request: boost deprecated tag
by Chard 18 Jun '09

18 Jun '09

Given that there is a current move to rationalize the bind placeholders, and potentially introduce deprecated definitions, would it worth introducing a boost deprecated marker that makes use of compiler support to notify the user that they are using such definitions? I recently recompiled a project with BOOST_FILESYSTEM_NO_DEPRECATED (for no particular reason, except perhaps for tr1 readiness) and I was surprised how many uses of the old native_file_string and boost::native tags were buried in the code-base. Personally, I think it would be useful to be notified (or nagged :-)) if I was using deprecated functionality; I don't examine every comment of every function, and after successful compilation/unit-test they are easily forgotten. I don't know the best, generic, way of achieving this, but a simple approach that should work with MSVC and gcc would be to have: #ifndef BOOST_NO_DEPRECATED_WARNINGS // Don't nag me, compiler # if [BUILDING_WITH_MSVC] # define BOOST_DEPRECATED __declspec(deprecated) # else if [BUILDING_WITH_GCC] # define BOOST_DEPRECATED __attribute__ ((deprecated)) # else if [BUILDING_WITH_acme] # define BOOST_DEPRECATED ... # end if #endif #ifndef BOOST_DEPRECATED // No compiler support, just a tag # define BOOST_DEPRECATED #end if Then usage is: BOOST_DEPRECATED void TheFunction(...); The intent here is clear, and uncluttered, but may not be flexible enough. For example, a compiler may use syntax that declares its deprecated tag after the definition (which gcc supports, and it is usually shown that way in the guidelines). In which case, I expect the whole definition would have to be wrapped up in the macro. Also, there may be a case for separating the deprecated tags for functions, variables, types, etc.. As an (untested) illustration: #ifndef BOOST_NO_DEPRECATED_WARNINGS # if [BUILDING_WITH_MSVC] # define BOOST_DEPRECATED_FUNCTION(_F_) __declspec(deprecated) _F_ # else if [BUILDING_WITH_GCC] # define BOOST_DEPRECATED_FUNCTION(_F_) _F_ __attribute__ ((deprecated)) # else if [BUILDING_WITH_acme] # define BOOST_DEPRECATED_FUNCTION(_F_) ... # define BOOST_DEPRECATED_VARIABLE(_V_) ... # define BOOST_DEPRECATED_TYPE(_T_) ... # end if #endif #ifndef BOOST_DEPRECATED_FUNCTION # define BOOST_DEPRECATED_FUNCTION(_F_) _F_ #end if #ifndef BOOST_DEPRECATED_VARIABLE // Some compilers may use different syntax for variables, if not, // use same as deprecated function tag # define BOOST_DEPRECATED_VARIABLE(_V_) BOOST_DEPRECATED_FUNCTION(_V_) #endif #ifndef BOOST_DEPRECATED_TYPE // As for variables.. # define BOOST_DEPRECATED_TYPE(_T_) BOOST_DEPRECATED_FUNCTION(_T_) #endif Usage example: class path { ... BOOST_DEPRECATED_FUNCTION(string_type native_file_string() const) { return file_string(); } ... }; This is noisier, and may be worse if parentheses/comma expansion work-arounds are required, but it's an example. Personally, I prefer the simple BOOST_DEPRECATED, but I don't have experience with other compilers to know if that would suffice. Even if no support is available, having a benign tag in the definition provides information at the least. Regards...

2 2

Boost Trac/Subversion upgrade this Friday
by Doug Gregor 18 Jun '09

18 Jun '09

The Boost Trac and Subversion repository will be offline for a few hours this Friday, June 19th, while we upgrade to a new version of Trac. Mailing lists will not be affected. Here is the approximate down-time: Date: Friday June 19, 2009 Time: - 11:00am-2:00pm Pacific US time - 12:00pm-3:00pm Mountain US time - 1:00pm-4:00pm Central US time - 2:00pm-5:00am Eastern US time - 6:00pm-9:00pm GMT Cheers, - Doug

2 1

Getting involved in Boost
by Anteru 18 Jun '09

18 Jun '09

Hi, I'm a Boost user since quite some time now (1.33 or so), however, I did not contribute a library to Boost, and I was also not too active on the news groups (a few posts so far, at most.) When I look at the review queue, I can see lots and lots of interesting libraries waiting. So my question is: How can I, primary a Boost user, contribute to the community to help with getting new libraries into Boost? Primary, I'd be interested in PIMPL and the ThreadPool, possibly in AutoBuffer and Sorting. Is there some recommended way of reviewing a library "out-of-order" with no review manager, such that the review is easily identifiable and can be found when it comes to the real review? For me, it seems to be no problem to gather reviews of a library up-front. This could make it easier for a review manager to do his work, as he could simply start a formal review only after a certain number of reviews has been done. Side note: I couldn't find a recent review status on the website -- under Development, Submissions, the latest report is from 2008, while the one latest one I could find is from June 2009. However, it does not say what the current status of the UUID is -- did I miss some obvious page with the status of all libraries? Cheers, Anteru

2 1

some mpl programming task -- don't get this compiled
by Peter Foelsche 18 Jun '09

18 Jun '09

I'm still unclear about some fundamentals of the mpl library. Could somebody have a look at this source code? I'm playing around with this since quite a while. I'm trying to convert some information into an array of strings. I'm using boost::mpl::map instead of vector as I want to overwrite points in a two dimensional matrix. So in fact this is a map indexed by a long containing another map indexed by a long containing char. Two dimensional quadratic matrix of char. Thanks Peter

2 5

[date_time] [#1861] Change for the default duration format
by Andrey Semashev 17 Jun '09

17 Jun '09

Hi, There's a Boost.DateTime ticket: https://svn.boost.org/trac/boost/ticket/1861 The initial problem was that the default handling of the %H format specifier (passing it to strftime) played badly with time durations that could be longer than 24 hours. The resolution was to provide additional %O format specifier that does not have 24 hour restriction. However the original poster proposes to change the default format of time durations from %H:%M:%S%F to %O:%M:%S%F so that formatted durations are always allowed to be longer than 24 hours. I mostly agree with this change, however it is clearly a breaking change that can affect error checking in some cases. What do the community and the maintainer (Jeff?) in particular think about this?

4 15

Proposal: MapReduce library (single machine)
by Craig Henderson 17 Jun '09

17 Jun '09

MapReduce is a programming model from Google that is designed for scalable data processing. Google's implementation is for scalability over many thousands of commodity machines, but there is value in using the idiom on multi-core processors to partition processing to efficiently use the CPU available, and avoid the complexities of multi-threaded development. I have a implemented a MapReduce runtime library in C++ using Boost and would like to see if there is interest from you all to submit the library to Boost. I have preliminary documentation on my website at http://www.craighenderson.co.uk/mapreduce/ Regards -- Craig Craig Henderson <http://craighenderson.co.uk/> http://www.craighenderson.co.uk http://www.siteupdatenotification.com

6 11

Compilation error in boost::bind
by Zachary Turner 17 Jun '09

17 Jun '09

The documentation for __stdcall in MSVC says the following: On Itanium Processor Family (IPF) and x64 processors, __stdcall is accepted and ignored by the compiler. Because of this, the following fragment from <boost/bind/bind.hpp> fails when causes build errors for either of these platforms: #define BOOST_BIND_CC #define BOOST_BIND_ST #include <boost/bind/bind_cc.hpp> #undef BOOST_BIND_CC #undef BOOST_BIND_ST #ifdef BOOST_BIND_ENABLE_STDCALL #define BOOST_BIND_CC __stdcall #define BOOST_BIND_ST #include <boost/bind/bind_cc.hpp> #undef BOOST_BIND_CC #undef BOOST_BIND_ST #endif Since it ignores the __stdcall the second time around, all the templates are re-declared with cdecl causing duplicate symbol definition errors. This is confirmed on MSVC 9.0 but I assume it exists on all versions of MSVC. What is the best way to fix this? I don't know much about how to use the BOOST_WORKAROUND macros, but I have patched this in my own version of bind.hpp by changing the block inside the ifdef to the following: #if defined(BOOST_BIND_ENABLE_STDCALL) && !(defined(BOOST_MSVC) && defined(_WIN64)) #define BOOST_BIND_CC __stdcall #define BOOST_BIND_ST #include <boost/bind/bind_cc.hpp> #undef BOOST_BIND_CC #undef BOOST_BIND_ST #endif This doesn't handle the itanium case obviously but off the top of my head I'm not sure what MSVC #defines for itanium. What would be the most robust way to fix this?

3 2

[mpl] is there a or_seq like logical metafunction?
by vicente.botet 17 Jun '09

17 Jun '09

Hello, I needs calculate the mlp::or_ of a sequence of nullary logical metafunction. This seams quite simple. I have do the following: <code> template <typename Seq> struct or_seq; template <typename Seq, long N> struct or_seq_aux : mpl::or_< typename mpl::front<Seq>::type, or_seq<typename mpl::pop_front<Seq>::type> > {}; template <typename Seq> struct or_seq_aux<Seq, 1> : mpl::front<Seq>::type {}; template <typename Seq> struct or_seq : or_seq_aux<Seq, mpl::size<Seq>::value> {}; </code> Is there a boost or_seq like logical metafunction? Is there a better way to do it? I would be extremely interested in any suggestions. Best regards --------------------------- Vicente Juan Botet Escriba

5 34

Unable to compile boost.wave
by Sean Farrow 17 Jun '09

17 Jun '09

Hi: The following is my boost compile output when trying to compile the latest trunk. Boost.wave fails to compile, this seems to be an issue with boost.spirit. Visual c++ 2005/2008, all latest patches/service pacs applied, windows xp sp3. Any help appreciated. Sean. --start log. Building C++ Boost. After the build, the headers will be located at C:\Program Files\boost The libraries will be located at C:\Program Files\boost\stage\lib Use 'bjam install --prefix=<path>' if you wish to install headers and libraries to a different location and remove the source tree. warning: Building Boost.Regex with the optional Unicode/ICU support disabled. note: Please refer to the Boost.Regex documentation for more information note: this is a strictly optional feature. warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user_config.jam warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. ...patience... ...patience... ...patience... ...found 6725 targets... ...updating 12 targets... compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi\instan tiate_cpp_grammar.obj instantiate_cpp_grammar.cpp C:\Program Files\boost\boost/spirit/home/support/iterators/detail/split_std_deque_p olicy.hpp(102) : error C2440: '<function-style-cast>' : cannot convert from 'int' to 'boost::wave::cpplexer::lex_token<>' No constructor could take the source type, or constructor overload resolution was ambiguous C:\Program Files\boost\boost/spirit/home/support/iterators/multi_pass.hpp(117) : see reference to function template instantiation 'void boost::spirit::iterator_policies::split_std_deque::unique<Value>::increm ent<boost::spirit::multi_pass<T,Policies>>(MultiPass &)' being compiled with [ Value=boost::wave::cpplexer::lex_token<>, T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type, MultiPass=boost::spirit::multi_pass<std::pair<boost::wave::cpplexer::imp l::lex_iterator_functor_shim<token_type>,boost::wave::cpplexer::lex_inpu t_interface<token_type> >,boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::impl::le x_iterator_functor_shim<token_type>>::policy_type> ] C:\Program Files\boost\boost/spirit/home/support/iterators/multi_pass.hpp(115) : while compiling class template member function 'boost::spirit::multi_pass<T,Policies> &boost::spirit::multi_pass<T,Policies>::operator ++(void)' with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] C:\Program Files\boost\boost/wave/cpplexer/cpp_lex_iterator.hpp(170) : see reference to class template instantiation 'boost::spirit::multi_pass<T,Policies>' being compiled with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] C:\Program Files\boost\boost/wave/grammars/cpp_grammar_gen.hpp(81) : see reference to class template instantiation 'boost::wave::cpplexer::lex_iterator<TokenT>' being compiled with [ TokenT=token_type ] libs\wave\src\instantiate_cpp_grammar.cpp(45) : see reference to class template instantiation 'boost::wave::grammars::cpp_grammar_gen<LexIteratorT,TokenContainerT>' being compiled with [ LexIteratorT=lexer_type, TokenContainerT=token_sequence_type ] call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"bin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi\inst antiate_cpp_grammar.obj.rsp" ...failed compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi\instan tiate_cpp_grammar.obj... compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi\instan tiate_defined_grammar.obj instantiate_defined_grammar.cpp C:\Program Files\boost\boost/spirit/home/support/iterators/detail/split_std_deque_p olicy.hpp(102) : error C2440: '<function-style-cast>' : cannot convert from 'int' to 'boost::wave::cpplexer::lex_token<>' No constructor could take the source type, or constructor overload resolution was ambiguous C:\Program Files\boost\boost/spirit/home/support/iterators/multi_pass.hpp(117) : see reference to function template instantiation 'void boost::spirit::iterator_policies::split_std_deque::unique<Value>::increm ent<boost::spirit::multi_pass<T,Policies>>(MultiPass &)' being compiled with [ Value=boost::wave::cpplexer::lex_token<>, T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type, MultiPass=boost::spirit::multi_pass<std::pair<boost::wave::cpplexer::imp l::lex_iterator_functor_shim<token_type>,boost::wave::cpplexer::lex_inpu t_interface<token_type> >,boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::impl::le x_iterator_functor_shim<token_type>>::policy_type> ] C:\Program Files\boost\boost/spirit/home/support/iterators/multi_pass.hpp(115) : while compiling class template member function 'boost::spirit::multi_pass<T,Policies> &boost::spirit::multi_pass<T,Policies>::operator ++(void)' with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] C:\Program Files\boost\boost/wave/cpplexer/cpp_lex_iterator.hpp(170) : see reference to class template instantiation 'boost::spirit::multi_pass<T,Policies>' being compiled with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] C:\Program Files\boost\boost/wave/grammars/cpp_defined_grammar_gen.hpp(42) : see reference to class template instantiation 'boost::wave::cpplexer::lex_iterator<TokenT>' being compiled with [ TokenT=token_type ] libs\wave\src\instantiate_defined_grammar.cpp(41) : see reference to class template instantiation 'boost::wave::grammars::defined_grammar_gen<LexIteratorT>' being compiled with [ LexIteratorT=lexer_type ] call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"bin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi\inst antiate_defined_grammar.obj.rsp" ...failed compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi\instan tiate_defined_grammar.obj... compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi\instan tiate_predef_macros.obj instantiate_predef_macros.cpp C:\Program Files\boost\boost/spirit/home/support/iterators/detail/split_std_deque_p olicy.hpp(102) : error C2440: '<function-style-cast>' : cannot convert from 'int' to 'boost::wave::cpplexer::lex_token<>' No constructor could take the source type, or constructor overload resolution was ambiguous C:\Program Files\boost\boost/spirit/home/support/iterators/multi_pass.hpp(117) : see reference to function template instantiation 'void boost::spirit::iterator_policies::split_std_deque::unique<Value>::increm ent<boost::spirit::multi_pass<T,Policies>>(MultiPass &)' being compiled with [ Value=boost::wave::cpplexer::lex_token<>, T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type, MultiPass=boost::spirit::multi_pass<std::pair<boost::wave::cpplexer::imp l::lex_iterator_functor_shim<token_type>,boost::wave::cpplexer::lex_inpu t_interface<token_type> >,boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::impl::le x_iterator_functor_shim<token_type>>::policy_type> ] C:\Program Files\boost\boost/spirit/home/support/iterators/multi_pass.hpp(115) : while compiling class template member function 'boost::spirit::multi_pass<T,Policies> &boost::spirit::multi_pass<T,Policies>::operator ++(void)' with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] C:\Program Files\boost\boost/wave/cpplexer/cpp_lex_iterator.hpp(170) : see reference to class template instantiation 'boost::spirit::multi_pass<T,Policies>' being compiled with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] C:\Program Files\boost\boost/spirit/home/classic/tree/common.hpp(1531) : see reference to class template instantiation 'boost::wave::cpplexer::lex_iterator<TokenT>' being compiled with [ TokenT=token_type ] C:\Program Files\boost\boost/wave/grammars/cpp_predef_macros_grammar.hpp(157) : see reference to class template instantiation 'boost::spirit::classic::tree_parse_info<IteratorT>' being compiled with [ IteratorT=boost::wave::cpplexer::lex_iterator<token_type> ] C:\Program Files\boost\boost/wave/grammars/cpp_predef_macros_grammar.hpp(157) : while compiling class template member function 'boost::spirit::classic::tree_parse_info<IteratorT> boost::wave::grammars::predefined_macros_grammar_gen<LexIteratorT>::pars e_predefined_macro(const boost::wave::cpplexer::lex_iterator<TokenT> &,const boost::wave::cpplexer::lex_iterator<TokenT> &)' with [ IteratorT=boost::wave::cpplexer::lex_iterator<token_type>, LexIteratorT=lexer_type, TokenT=token_type ] libs\wave\src\instantiate_predef_macros.cpp(41) : see reference to class template instantiation 'boost::wave::grammars::predefined_macros_grammar_gen<LexIteratorT>' being compiled with [ LexIteratorT=lexer_type ] call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"bin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi\inst antiate_predef_macros.obj.rsp" ...failed compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi\instan tiate_predef_macros.obj... ...skipped <pbin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi>libb oost_wave-vc90-mt-gd-1_40.lib for lack of <pbin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi>inst antiate_cpp_grammar.obj... ...skipped <pstage\lib>libboost_wave-vc90-mt-gd-1_40.lib for lack of <pbin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi>libb oost_wave-vc90-mt-gd-1_40.lib... ...skipped <pstage\lib>libboost_wave-vc90-mt-gd.lib for lack of <pstage\lib>libboost_wave-vc90-mt-gd-1_40.lib... compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi\inst antiate_cpp_grammar.obj instantiate_cpp_grammar.cpp .\boost/spirit/home/support/iterators/detail/split_std_deque_policy.hpp( 102) : error C2440: '<function-style-cast>' : cannot convert from 'int' to 'boost::wave::cpplexer::lex_token<>' No constructor could take the source type, or constructor overload resolution was ambiguous .\boost/spirit/home/support/iterators/multi_pass.hpp(117) : see reference to function template instantiation 'void boost::spirit::iterator_policies::split_std_deque::unique<Value>::increm ent<boost::spirit::multi_pass<T,Policies>>(MultiPass &)' being compiled with [ Value=boost::wave::cpplexer::lex_token<>, T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type, MultiPass=boost::spirit::multi_pass<std::pair<boost::wave::cpplexer::imp l::lex_iterator_functor_shim<token_type>,boost::wave::cpplexer::lex_inpu t_interface<token_type> >,boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::impl::le x_iterator_functor_shim<token_type>>::policy_type> ] .\boost/spirit/home/support/iterators/multi_pass.hpp(115) : while compiling class template member function 'boost::spirit::multi_pass<T,Policies> &boost::spirit::multi_pass<T,Policies>::operator ++(void)' with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] .\boost/wave/cpplexer/cpp_lex_iterator.hpp(170) : see reference to class template instantiation 'boost::spirit::multi_pass<T,Policies>' being compiled with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] .\boost/wave/grammars/cpp_grammar_gen.hpp(81) : see reference to class template instantiation 'boost::wave::cpplexer::lex_iterator<TokenT>' being compiled with [ TokenT=token_type ] libs\wave\src\instantiate_cpp_grammar.cpp(45) : see reference to class template instantiation 'boost::wave::grammars::cpp_grammar_gen<LexIteratorT,TokenContainerT>' being compiled with [ LexIteratorT=lexer_type, TokenContainerT=token_sequence_type ] call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"bin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi\in stantiate_cpp_grammar.obj.rsp" ...failed compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi\inst antiate_cpp_grammar.obj... compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi\inst antiate_defined_grammar.obj instantiate_defined_grammar.cpp .\boost/spirit/home/support/iterators/detail/split_std_deque_policy.hpp( 102) : error C2440: '<function-style-cast>' : cannot convert from 'int' to 'boost::wave::cpplexer::lex_token<>' No constructor could take the source type, or constructor overload resolution was ambiguous .\boost/spirit/home/support/iterators/multi_pass.hpp(117) : see reference to function template instantiation 'void boost::spirit::iterator_policies::split_std_deque::unique<Value>::increm ent<boost::spirit::multi_pass<T,Policies>>(MultiPass &)' being compiled with [ Value=boost::wave::cpplexer::lex_token<>, T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type, MultiPass=boost::spirit::multi_pass<std::pair<boost::wave::cpplexer::imp l::lex_iterator_functor_shim<token_type>,boost::wave::cpplexer::lex_inpu t_interface<token_type> >,boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::impl::le x_iterator_functor_shim<token_type>>::policy_type> ] .\boost/spirit/home/support/iterators/multi_pass.hpp(115) : while compiling class template member function 'boost::spirit::multi_pass<T,Policies> &boost::spirit::multi_pass<T,Policies>::operator ++(void)' with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] .\boost/wave/cpplexer/cpp_lex_iterator.hpp(170) : see reference to class template instantiation 'boost::spirit::multi_pass<T,Policies>' being compiled with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] .\boost/wave/grammars/cpp_defined_grammar_gen.hpp(42) : see reference to class template instantiation 'boost::wave::cpplexer::lex_iterator<TokenT>' being compiled with [ TokenT=token_type ] libs\wave\src\instantiate_defined_grammar.cpp(41) : see reference to class template instantiation 'boost::wave::grammars::defined_grammar_gen<LexIteratorT>' being compiled with [ LexIteratorT=lexer_type ] call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"bin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi\in stantiate_defined_grammar.obj.rsp" ...failed compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi\inst antiate_defined_grammar.obj... compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi\inst antiate_predef_macros.obj instantiate_predef_macros.cpp .\boost/spirit/home/support/iterators/detail/split_std_deque_policy.hpp( 102) : error C2440: '<function-style-cast>' : cannot convert from 'int' to 'boost::wave::cpplexer::lex_token<>' No constructor could take the source type, or constructor overload resolution was ambiguous .\boost/spirit/home/support/iterators/multi_pass.hpp(117) : see reference to function template instantiation 'void boost::spirit::iterator_policies::split_std_deque::unique<Value>::increm ent<boost::spirit::multi_pass<T,Policies>>(MultiPass &)' being compiled with [ Value=boost::wave::cpplexer::lex_token<>, T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type, MultiPass=boost::spirit::multi_pass<std::pair<boost::wave::cpplexer::imp l::lex_iterator_functor_shim<token_type>,boost::wave::cpplexer::lex_inpu t_interface<token_type> >,boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::impl::le x_iterator_functor_shim<token_type>>::policy_type> ] .\boost/spirit/home/support/iterators/multi_pass.hpp(115) : while compiling class template member function 'boost::spirit::multi_pass<T,Policies> &boost::spirit::multi_pass<T,Policies>::operator ++(void)' with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] .\boost/wave/cpplexer/cpp_lex_iterator.hpp(170) : see reference to class template instantiation 'boost::spirit::multi_pass<T,Policies>' being compiled with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] .\boost/spirit/home/classic/tree/common.hpp(1531) : see reference to class template instantiation 'boost::wave::cpplexer::lex_iterator<TokenT>' being compiled with [ TokenT=token_type ] .\boost/wave/grammars/cpp_predef_macros_grammar.hpp(157) : see reference to class template instantiation 'boost::spirit::classic::tree_parse_info<IteratorT>' being compiled with [ IteratorT=boost::wave::cpplexer::lex_iterator<token_type> ] .\boost/wave/grammars/cpp_predef_macros_grammar.hpp(157) : while compiling class template member function 'boost::spirit::classic::tree_parse_info<IteratorT> boost::wave::grammars::predefined_macros_grammar_gen<LexIteratorT>::pars e_predefined_macro(const boost::wave::cpplexer::lex_iterator<TokenT> &,const boost::wave::cpplexer::lex_iterator<TokenT> &)' with [ IteratorT=boost::wave::cpplexer::lex_iterator<token_type>, LexIteratorT=lexer_type, TokenT=token_type ] libs\wave\src\instantiate_predef_macros.cpp(41) : see reference to class template instantiation 'boost::wave::grammars::predefined_macros_grammar_gen<LexIteratorT>' being compiled with [ LexIteratorT=lexer_type ] call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"bin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi\in stantiate_predef_macros.obj.rsp" ...failed compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi\inst antiate_predef_macros.obj... ...skipped <pbin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi>li bboost_wave-vc90-mt-1_40.lib for lack of <pbin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi>in stantiate_cpp_grammar.obj... ...skipped <pstage\lib>libboost_wave-vc90-mt-1_40.lib for lack of <pbin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi>li bboost_wave-vc90-mt-1_40.lib... ...skipped <pstage\lib>libboost_wave-vc90-mt.lib for lack of <pstage\lib>libboost_wave-vc90-mt-1_40.lib... ...failed updating 6 targets... ...skipped 6 targets... --end log. __________ Information from ESET NOD32 Antivirus, version of virus signature database 4160 (20090616) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

2 1

Interest in a Bloom Filter?
by Dean Michael Berris 17 Jun '09

17 Jun '09

Hi Everyone, During the weekend, I got acquainted with and excited about Bloom Filters and the utility of such a data structure. I then proceeded to look at generic implementations of a bloom filter and I thought about implementing one myself instead as a simple exercise. Attached is what I came up with which I'm submitting as a library for review (and uploading to the vault). Also attached is a sample program which uses the bloom_filter. I've yet to write some documentation about it, which would be in the list of things to do in case there's enough interest for the library to be included in Boost. Thanks in advance and I hope this helps! -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

5 12

Boost on solaris compiled and linked with libCstd
by CREMARENCO Cosmin 16 Jun '09

16 Jun '09

Hi We have a solaris distribution of our software and we would like to use the boost libraries. In my understanding you recommend compiling and linking with stlport. However we depend on third party libraries that were built with libCstd, which is the old standard non-conformant library from sun. Sun docs clearly state that one should use either stlport or libCstd in the same program but not both. Also, we use sun studio 11. Now, we tried building boost with libCstd. A number of libraries built without problems: date, iostreams, prg, signals, system. In our application we use mostly header-only libraries and a small number of libraries that need to be linked with the program. We could get program-options (which we use extensively) to build by patching it (a tentative patch for 1.39 is attached). Of course one also needs to change tools/build/v2/tools/sun.jam in order to disable compiling and linking with stlport. My question is: if we send patches that allow boost to be compiled and linked with libCstd is there a chance that you will accept them in your main codeline? Best regards, Cosmin

2 1

[test] Untraceable Boost.Test framework internal error: unknown reason
by Peter Soetens 16 Jun '09

16 Jun '09

Hi, I'm using Boost 1.37.0 (Ubuntu Jaunty). When I run my testcases, they seem to complete well, but just before the end of the program exit, I get this error from Boost UTF: Boost.Test framework internal error: unknown reason FATAL: exception not rethrown Aborted I spent an hour trying to figure out 1) how to find out where the exception was thrown and 2) if the exception catching in boost could be disabled such that a simple gdb backtrace could point me to it. I have the suspicion that one of the signal handlers that boost UTF installs gets triggered, but I also did not find any way to disable the boost signal handlers. I'm really out of options... Any help/hints (would upgrading boost help?) really appreciated. Peter

2 3

[repost][threads] final decision on making parts of Boost.Threads header-only
by joaquin＠tid.es 16 Jun '09

16 Jun '09

I'm reposting this in the hope of catching the attention of the lib's author, who is at the end of the day the person reponsible of making the decision: Hi, A few weeks ago we had a discussion about the convenience of making part of Boost.Threads, namely mutexes and locks, header-only. Some (including Anthony Williams) supported the idea, others disliked it: http://lists.boost.org/Archives/boost/2009/04/150524.php What the final decision on this issue is? If positive (i.e. favoring the change), can it be expected to be done for Boost 1.40? As a remainder, I've created an associated trac ticket: https://svn.boost.org/trac/boost/ticket/2964 Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 4

Proposal: null pointer class
by Martin Törnwall 15 Jun '09

15 Jun '09

Hello Boost developers, I'd like to propose the inclusion of a null_ptr class in Boost. While I am fully aware that this topic has been brought up several times in the past, it appears as if though all discussions slowly died off without any final decision as to whether it is a worthy candidate for inclusion in Boost or not. The null pointer class proposals I have seen before were all designed to function in a manner similar to that of the "nullptr" keyword of C++0x. That is, the classes typically provided a template conversion operator, which allows it to evaluate to any pointer type with the value zero. My approach is to make the class, rather than the operator, a template: template<typename T> class null_ptr { public: operator T*() const { return reinterpret_cast<T *>(0); } }; As we can see, passing a null_ptr requires us to explicitly specify the type of pointer. While slightly verbose, I believe that it can be highly beneficial, for the following reasons: 1. In cases where multiple overloaded functions that take pointers exist, there is no way that we could accidentally call the wrong overload (since we have to explicity specify the type). 2. It makes code easier to read and understand. When reading the code, another programmer will instantly be able to see what type argument(s) a particular function accepts, thus making it much clearer than using NULL or nullptr. As with all other null pointer classes that have been suggested to date, the primary benefit of using my null_ptr over the NULL constant is that it solves the following problem: void f(int) { ... } void f(char *) { ... } int main() { func(NULL); func(null_ptr<char>()); } When passing NULL, f(int) will be called -- probably not what the programmer intended. The second call utilizes null_ptr<char> to guarantee that the overload of f() taking char* will be called instead of the one taking int. As noted above, my null_ptr class also handles multiple overloads taking pointer types gracefully. Please let me know what you think! P.S: I have tested the code on Microsoft Visual C++ 2008 as well as gcc 4.3.3 (Linux). Regards, Martin Törnwall

6 12

A question about Units & Spirit
by John Phillips 15 Jun '09

15 Jun '09

In the middle of the directX thread, Daniel Duffy asked a question that seems more suited to its own thread. I'm starting that thread and giving others a chance to join into the discussion by giving you the content of the few messages that have passed by so far. John From Daniel --------------------------------------------------- Hello, This is my first mail, so I hope I have sent it to the right address :) I am using the Units library for Dimensional Analysis. So far it is very useful. Up till now I am using it in a hard-coded/compile time way as in a test.cpp. My inteterst is in using Units as part of a larger run-time system so I need some way of making my code more flexible. Lambda library is an option here but I would also like to create units and quanties from string input as well as being able to parse these strings to units and then store the units in a database. Can I use Spirit (and Serialization) for these features? Maybe the functionality already exist, and I have not found it. best regrads Daniel J. Duffy From Hartmut --------------------------------------------------- Sure Spirit is your friend for all parsing and output generation needs. What did you have in mind? Regards Hartmut From Daniel ---------------------------------------------------- Hartmut, I would like to generate well-formed units and create expressions of the followiong kinds: Examples of unit expressions: 1. 2m + 15m*32s/16s = 32m. 2. 3m*7s + 2m*10s/5m = 21m + 4s -> ERROR. Can't add meters to seconds. The second group looks more tricky. Examples of simplification: 1. (x-2)2 + 4x2 - 2^x + 1 = 5x2 - 8x + 10 2. x2 + 7x + 10 = (x + 2)(x + 5) 3. (a + b)(a - b) = a2 - b2 4. sin(x)2 + cos(x)2 = 1 5. 2sin(x)cos(x) = sin(2x) One tricky part is for example #5 where the code needs to 'know' trigonometry. best regards Daniel From John ---------------------------------------------------------- Daniel J. Duffy wrote: > Hartmut, > I would like to generate well-formed units and create expressions of the followiong kinds: > > Examples of unit expressions: 1. 2m + 15m*32s/16s = 32m. 2. 3m*7s + 2m*10s/5m = 21m + 4s -> ERROR. Can't add meters to seconds. So, you want this to happen at run time, or at compile time? At compile time, I think you are already set with the Units library. At run time, there are examples with the library that would help. If parsing the input is your concern, then Spirit is a good choice. (Spirit 2 is even better, by the way.) Using the two together, you could write a program where a user enters your example lines and gets correct responses. > > The second group looks more tricky. > > Examples of simplification: 1. (x-2)2 + 4x2 - 2^x + 1 = 5x2 - 8x + 10 2. x2 + 7x + 10 = (x + 2)(x + 5) 3. (a + b)(a - b) = a2 - b2 4. sin(x)2 + cos(x)2 = 1 5. 2sin(x)cos(x) = sin(2x) > One tricky part is for example #5 where the code needs to 'know' trigonometry. As far as I can tell here, you are looking for a program that does symbolic algebra. If that is true, then I don't think boost has a complete solution for you. Writing the parser for the input with Spirit wouldn't be that bad, but writing the processing engine that matches patterns and does simplifications is not covered by any current Boost libraries. I don't recall seeing anyone poll for interest on this, so I don't think there is even a partial library in the sandbox. Would you want this at run time, compile time, both? I haven't tried to write it, but I think a pure compile time implementation would be prohibitively slow. For a pure run time solution, you might consider linking to already existing solutions, such as Maple or Mathematica. > > best regards > > Daniel > John

2 2

[ptr_container] Can't store a pointer to const in multimap?
by Amit Kumar 15 Jun '09

15 Jun '09

Please consider the following code: #include "boost/ptr_container/ptr_map.hpp" int main() { typedef boost::ptr_multimap<char, const int> M; M m; char c = 'c'; int* j = new int(7); m.insert(c, j); return 0; } The gcc 4.3.3 compiler fails to compiler the above code. Am I doing something wrong by inserting a non-const? Can't I store a pointer to const in the multimap? try.cpp: In function ‘int main()’: try.cpp:8: error: expected primary-expression before ‘=’ token /usr/include/c++/4.3/bits/stl_pair.h: In constructor ‘std::pair<_T1, _T2>::pair(const std::pair<_U1, _U2>&) [with _U1 = char, _U2 = const int*, _T1 = const char, _T2 = void*]’: boost/boost_1_39_0/boost/ptr_container/ptr_map_adapter.hpp:765: instantiated from ‘typename boost::ptr_container_detail::ptr_map_adapter_base<T, VoidPtrMap, CloneAllocator, Ordered>::iterator boost::ptr_multimap_adapter<T, VoidPtrMultiMap, CloneAllocator, Ordered>::insert_impl(const typename boost::ptr_container_detail::ptr_map_adapter_base<T, VoidPtrMap, CloneAllocator, Ordered>::key_type&, typename boost::ptr_container_detail::ptr_map_adapter_base<T, VoidPtrMap, CloneAllocator, Ordered>::mapped_type) [with T = const int, VoidPtrMultiMap = std::multimap<char, void*, std::less<char>, std::allocator<std::pair<const char, void*> > >, CloneAllocator = boost::heap_clone_allocator, bool Ordered = true]’ boost/boost_1_39_0/boost/ptr_container/ptr_map_adapter.hpp:799: instantiated from ‘typename boost::ptr_container_detail::ptr_map_adapter_base<T, VoidPtrMap, CloneAllocator, Ordered>::iterator boost::ptr_multimap_adapter<T, VoidPtrMultiMap, CloneAllocator, Ordered>::insert(typename boost::ptr_container_detail::ptr_map_adapter_base<T, VoidPtrMap, CloneAllocator, Ordered>::key_type&, typename boost::ptr_container_detail::ptr_map_adapter_base<T, VoidPtrMap, CloneAllocator, Ordered>::mapped_type) [with T = const int, VoidPtrMultiMap = std::multimap<char, void*, std::less<char>, std::allocator<std::pair<const char, void*> > >, CloneAllocator = boost::heap_clone_allocator, bool Ordered = true]’ try.cpp:9: instantiated from here /usr/include/c++/4.3/bits/stl_pair.h:106: error: invalid conversion from ‘const void*’ to ‘void*’ I also tried but failed with const casting j before insertion.

3 2

[serialization][trunk] Latest patch for void_cast.cpp causes segfaults
by Hartmut Kaiser 15 Jun '09

15 Jun '09

Hi all, apparently the latest patch to boost/libs/serialization/src/void_cast.cpp (rev.53078, svn:date: 2009-05-18T06:25:56.023190Z, svn:author: ramey, svn:log: fix errors in extended_type_info management) causes an existing application to segfault during cleanup. The application was working properly before. The attached patch fixes the issue. Ok to commit? Regards Hartmut

1 0

Removing Bind placeholders from the global namespace
by Peter Dimov 15 Jun '09

15 Jun '09

This topic has again come up recently in boost-users. I have already assigned myself a ticket, https://svn.boost.org/trac/boost/ticket/2240 but have done nothing so far, in part because it would break other Boost libraries. (Patching placeholders.hpp is trivial in itself.) This is one case in which the trunk/release procedures don't work well as-is unless someone volunteers to produce a patch against all of Boost that at once moves the placeholders into namespace boost::placeholders _and_ fixes all errors that this would cause. It'd be easier to split the work: I put the breaking change in and then the libraries are fixed one by one. :-) Comments? -- Peter Dimov http://www.pdplayer.com

10 31

[candidate bloom_filter] nitpick
by JOAQUIN M. LOPEZ MUÑOZ 15 Jun '09

15 Jun '09

Hi Michael, I see that internals.hpp declares the following: namespace boost { namespace detail { template <class Input, class BitSet> class bloom_filter_internals {...}; } } boost::detail should not be used for internals of a specific library. The custom is to do it like this: namespace boost{ namespace bloom_filters{ namespace detail{ // you might want to rename to just "internals" // as the qualified name is sufficiently informative template <class Input, class BitSet> class bloom_filter_internals {...}; } } } Note the "s" in "bloom_filters", following the naming guidelines at: http://www.boost.org/development/requirements.html#Naming_consistency Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

Boost and XML-RPC
by Dmitriy Lyfar 15 Jun '09

15 Jun '09

Hello boosters, What do you think about boost.xmlrpc implementation? Some days ago I need simple xmlrpc library with https support, but I cannot find anything for windows. What I've found it's http://libiqxmlrpc.sourceforge.net/ library. But it has too many dependencies, I really don't understand why I should compile half of gnome to have an ability call xmlrpc methods. So after some libs I realized that there is no good xmlrpc lib for windows at least (if you know, please let me know). So what are you thoughs about implementation such lib as part of boost (asio based for example)? Is it needed for community? Thank you, Dmitriy.

2 3

Blechmann's lock-free
by Michael Caisse 14 Jun '09

14 Jun '09

Tim - I just downloaded your lock-free data structure code and was getting ready to take a look at it. Two questions immediately come to my mind: 1. What is your intent for this library? Do you plan on having it reviewed? 2. Do you have pre-made docs available somewhere? I seem to consistently have troubles getting the doc chain going. Best Regards - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 1

[date_time] Change to the time_duration default format.
by Ilya Bobir 14 Jun '09

14 Jun '09

Hi all, I would like to propose a change to the default format for the time_duration objects. Current format is "%H:%M:%S%f". It does not allow one to input a time_duration that is longer than 99 hours. My proposal is to change the format to be "%O:%M:%S%f". time_duration objects are not restricted to 99 hours so the current behavior seems to be incorrect. I have submitted a patch but was told that the change is a braking change and need to be discussed on a mailing list: https://svn.boost.org/trac/boost/ticket/1861#comment:3 Please reply if you think there could be issues with the change to the default time_duration format. Here is a simple test that shows what I'm talking about: #include <iostream> #include <sstream> #include <boost/date_time.hpp> using namespace std; using namespace boost::posix_time; int main(void) { time_input_facet* facet = new time_input_facet(); locale loc(locale(locale(), facet)); time_duration td1(hours(100)); time_duration td2; stringstream ss; ss.imbue(loc); /* Input using default time_duration format. */ facet->time_duration_format("%H:%M:%S%f"); ss << td1; ss >> td2; cout << td2 << endl; /* Input using proposed time_duration format. */ ss.str(""); ss.clear(); facet->time_duration_format("%O:%M:%S%f"); ss << td1; ss >> td2; cout << td2 << endl; } For me it outputs: 00:00:00 100:00:00 It means that you can not serialize and deserialize arbitrary time_duration objects if you are using the default format. While the output facet do write extra digits the input facet will accept only two digits for the hours field. Ilya Bobir

2 1

Re: [boost] first review submission of timer_queue.zip
by JohnQ 14 Jun '09

14 Jun '09

>> Thanks to any who take the time to review this and help me make it better. > >Why the call_back is associated to the timer_queue and not to the timeout? If I understand your question correctly, it's because this allows me to look at a "window" of time when the current timer expires. That way I can call the callback multiple times for timers that are all within the current "window" to avoid invoking context switches for each of those timers. > >Do we really need several timer queues? Shouldn't only one be enough? IMO the class timer_queue >muts be hiden to the user. The interface I would like to use is something like, > > auto h = after_call(miliseconds(10), f, x, y); >or > auto h = at_call(now()+miliseconds(10), f, x, y); > > if (some condition) { > h.interrupt(); > } Let me take a closer look at this and make another reply... I'm short on time right now... but I have a question about the first part... there should only be one timer queue... and actually the container behind the scenes is a multi-index map (not really a queue). > >The user should be also able to wait until the timeout has expired and the function called. So > > h.wait() > >will synchronize with the end of the function call f(x,y). If in addition f returns something the >following should also be correct > > auto res = h.get() > >So the handle returned by > auto h = after_call(miliseconds(10), f, x, y); > >must implement the future interface (an asynchronous completion token). I think I agree... but need more time to go through your suggestion. > >There are classic implementation using a well instead of a queue which make insertion independent >of the number of active timers (see for example "Redesigning >the BSD Callout and Timer Facilities" by Adam M. Costello, George Varghese > http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=B5202FC949FF3EDB0E… ). > Yes, this is good advice... I'll take a look. >Best regards, >Vicente Excellent ! Thanks for giving this a detailed look Vicente. ----- From Dmitry---- >>>> What mechanism do you use to suspend till it's time to fire a callback? >>>> >> >> boost::condition_variable m_timed_cond.timed_wait(timer_lock, cur_timer) >> >> >This approach has a drawback. After the timeout expires timed_wait() has >to lock a mutex. And this can take arbitrary long. >Especially if there are other threads that are waiting for the same >mutex. Any thread that came before your thread will, most probably, >acquire the mutex before your thread. >This obviously spoils precision. Why dont you use a semaphore instead? >In order to improve precision, the library can also wait a bit less than >the client asked to give the thread some time to resume. Under high load >the scheduler can give your thread the processor long later than you asked. Thanks Dmity! As with my answers to Vicente above, let me take a closer look and reply. I've been completely swamped, the last 1-2 weeks and I'm just coming out of it. :) Thanks, John Q.

1 0

[PropertyTree] Rewrite - Please Review
by Sebastian Redl 13 Jun '09

13 Jun '09

Hi PropertyTree users, I have completed the main bulk of the property tree rewrite/cleanup. In the course of this, I have made the code standard-compliant (it previously used a std::list of an incomplete type, which is not, strictly speaking, valid), made it follow the claimed complexities (find() was O(n), although the docs said it's O(log n)), and revised the customization interface quite thoroughly. Inevitably, there were breaking changes in this process. I would ask everyone who has existing code using PropertyTree to look at these changes and tell me their best guess at how much effort it would be to update the code to conform with the new interface, and how I could make this easier. The development is still in a branch, so you need to check out the SVN branch http://svn.boost.org/svn/boost/branches/sredl_2009_05_proptree_update to try out the new version. The breaking changes are as follows: 1) Probably the most common change need: ptree::find() now returns the new type assoc_iterator (const_assoc_iterator for the const version) instead of iterator (const_iterator). This means that you need to change the type of the variable you capture the result with to assoc_iterator. It also means you need to compare the result of find() against ptree::not_found() instead of ptree::end(). You can get an iterator from an assoc_iterator by passing it to ptree::to_iterator(). The other projection direction is currently not supported, although it would be trivial to add. 2) The number and order of template arguments to basic_ptree has been changed. The old arguments were * Key comparison predicate * Key type * Path type * Data type * Translator type The new arguments are * Key type * Data type * Key comparison predicate (defaults to std::less<Key>) The old order prevented defaulting and wasn't very useful in general. The new order is consistent with std::map. The path and translator arguments have been removed to simplify the interface of basic_ptree. Equivalent functionality is available (see below). If you used your own instantiation of basic_ptree before, instead of simply using the (wi)ptree typedefs, you will have to adapt your code to the new order. If you used custom path and/or translator types, read on. 3) put and put_child previously had a final parameter 'bool do_not_replace'. I don't like boolean parameters, especially those whose name contains a negation. I removed the parameter, and replaced its functionality by a pair of new functions, add and add_child. If you previously called put or put_child passing true for do_not_replace, you must change these calls to add or add_child, respectively. If you ever passed false explicitly, you have to remove this parameter. 4) Using custom path types has changed. You can no longer create individual basic_ptree instantiations with custom path types. Instead, a key type has a fixed path type associated with it. I can bring this functionality back pretty easily if required, but I want to see use cases for this first. (Such things are why I make this call for reviews.) Less template parameters to ptree is good, in my opinion. To use a key type other than std::basic_string specializations, you have to specialize boost::property_tree::path_of for this key type. The path_of struct contains a single type called type, which is the path to use for this key type. The way paths are implemented has also changed thoroughly. Previously, you had to implement a const and a non-const variant of get_child, plus put_child (with do_not_replace making that effectively two functions too). These functions contained a lot of logic that really belonged into ptree, making implementing custom paths tedious and error-prone. The new interface requires you to implement four functions, but they're far simpler. The functions are described in ptree_fwd.hpp in C++0x concept syntax, but here's the gist: bool path::empty() const -> is the path empty? bool path::single() const -> does the path contain a single element? key_type path::reduce() -> chop off the first part of this path and return it (basically a pop_front that returns the value). std::string dump() const -> get a readable form of this path for exception messages; feel free to return "" here if you don't care. The new interface should be easy to implement, and the tree traversal is now where it belongs (in the internal implementation functions walk_path and force_path). 5) Using custom translators has changed. A ptree no longer has a fixed translator associated with it. Instead, you can supply a custom translator to every get_value/get/put_value/put operation or use the default, which depends on the tree's data type and the type you extract/insert. An example: ptree pt; pt.put("k1.k2", 100); // Uses the default translator for std::string+int. // Note: the explicit template parameter here will go away. float f = pt.get<float>("k1.k2", my_special_float_string_converter()); The tree's own data type is called the internal type, while the parameter/return type is called the external type. The default translator for a internal+external pair is set by specializing the boost::property_tree::translator_between struct. By default, PropertyTree supplies an id_translator for when the internal and external types are the same, and a stream_translator for converting between a basic_string and anything else. Together, they faithfully emulate the behavior of the old default translator. Writing a custom translator is easy. It's a class that provides two typedefs and two functions: typename internal_type -> the internal data type typename external_type -> the external data type optional<external_type> Tr::get_value(internal_type) -> convert from the internal to the external type, boost::none on failure optional<internal_type> Tr::put_value(external_type) -> convert from the external to the internal type, boost::none on failure That's it for the changes. The new version of property tree is not quite complete yet. I still need to polish the documentation a little and document the new extension mechanisms properly. I also need to clean up a little. Finally, the INI parser doesn't work at the moment. However, the main functionality (tested by property_tree_test) plus the XML, JSON and INFO parsers should all work now. Looking forward to your feedback. Sebastian

3 4

[lexical_cast] Volunteer testers needed
by Adam Badura 13 Jun '09

13 Jun '09

The attached file contains a modification to lexical_cast which I want to be included in Boost 1.40. However that requires testing since lexical_cast is widely used. I did my own tests but it is not enough. Thus I ask anyone willing to volunteer to use the attached code and notify about the result. The attached file should be used instead of Boost's lexical_cast. It adds boost::classic_lexical_cast which acts exactly as boost::lexical_cast with std::locale::classic as the global locale. Two things have to be tested. 1) [more important] Whether boost::lexical_cast works as previously after the changes. 2) [less important] Whether boost::classic_lexical_cast works as expected. The changes allow to use lexical_cast in locale-independent tasks (like serialization of data) through the boost::classic_lexical_cast in applications which set global locale to something else then the classic locale. Also having those changes easies possible addition of text-based conversion function talking arbitrary locale object. Thanks in advance to anyone who helps. Adam Badura

2 2

Doxygen and Boostbook
by Mathias Gaunard 13 Jun '09

13 Jun '09

While looking at the Boostbook documentation, I couldn't find documentation about how Doxygen documentation is transformed into Boostbook. I think documentation that says how one doxygen special block is transformed to a boostbook element would be useful, as well as how to generate boostbook elements from special blocks not supported by doxygen. For example, I don't know how to define concepts in Doxygen. Is such documentation available somewhere?

1 0

Performance of boost::mutex and boost::mutex::scoped_lock
by Zachary Turner 13 Jun '09

13 Jun '09

I have been doing some profiling using VTune recently to investigate the cause of some underperforming multi-threaded code, and it's possible that I'm not interpreting these results correctly, but if I am it's a little surprising. This isn't the best multi-threaded design in the world, but it's basically a naive implementation of a producer consumer that uses a deque as the production queue, a boost::mutex as the lock, and a boost::condition as a signal to wake up when there's stuff in the queue (queue comment about boost::circular_buffer, which this code really should be using instead). There is LOTS of context switching going on, basically I read a 4KB chunk of data from the filesystem, put it in the queue, the other threads takes the 4KB of data, does something with it, and this repeats for a really long time. Since it doesn't take a whole lot of time to read 4KB of data from the disk, you can tell that there are going to be zillions of context switches and contention going on. So on to the point. Obviously most of the time is spent in boost::detail::basic_timed_mutex::lock, but what's surprising is the breakdown of time inside the lock function: (Keep in mind this is not timed over a terribly long sample, hence the small numbers, but it is over thousands of actual locks, and ultimately this locking alone makes up a noticeable portion of the sample duration) boost::detail::basic_timed_mutex.lock Total Time: 1,032,486 microseconds (1.032 seconds) Total Wait Time: 505,884 microseconds (.505 seconds) It appears that only half the time is actually spent inside the lock, which is pretty crazy. The rest is spent doing computations, which doesn't seem right for a lock. I drilled down further and came up with this: boost::detail.get_system_time_sentinel Total Time: 266,657 microseconds Total Wait Time: 264 microseconds So that accounts for about half of the computational time. The rest is in a Windows system call somewhere that I was not able to drill into. I don't know about the details of date_time library, or much about the details of thread library either for that matter, but why is a time necessary here at all? This is eventually resolving down to a boost::detail::basic_timed_mutex, but there's nothing timed about the operations I've done. I simply did the following: boost::mutex m; boost::mutex::scoped_lock lock(m); //... This should ultimately result in an infinite timeout being specified to the system call, so all of this computation seems completely unnecessary. It seems like a scoped_lock should completely bypass anything having to do with date_time, and perhaps even normal timed locks should come up with a more efficient strategy. Thoughts?

4 4

[mpl] mpl::string, ok to merge to release?
by Eric Niebler 13 Jun '09

13 Jun '09

The mpl::string tests look OK to me on trunk, so I was planning on merging this to release for 1.40. Objections? Aleksey, I've had some problems generating the refmanual html from the rst source. It seems to go OK, but then some of the internal links are broken, and I can't figure what I'm doing wrong. Could you generate new html from the rst on trunk and commit it back to trunk? Please let me know the revision number after you do, and I'll merge it all to release in one go. Thanks. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 3

Re: [boost] boost::directx?
by Kasra 13 Jun '09

13 Jun '09

Hi guys, I have been following this thread but haven't really found the significance of boost::directx! If the purpose of the library is to create a comprehensive graphics library, choosing directx or infact any other API seems absurd. For example, ORGE is a graphics library that doesn't choose OpenGL over DirecX but provides a wrapping interface for a graphics library where this library's internal is OpenGL and DirectX depending on the platform. I just think if this library is going to established within boost, it requires a portable interface irrespective of the internals. With Best Regards --- Kasra Nassiri

16 41

Why the integration branchmust remain clean, etc.
by David Abrahams 12 Jun '09

12 Jun '09

I just realized I can articulate what's not working for me about the current trunk/release branch arrangement. * IIUC, there are always lots of failures on the trunk because there's no pressure to keep it clean. * Before I check in a change in one of my libraries, I want to make sure I haven't broken anything else in boost. So naturally, I run the whole regression suite (there oughta be a better way!) * But since the trunk is not clean, I spend a lot of time analyzing problems that have nothing to do with my library. That's a real disincentive to making changes in Boost. In fact, I am confident my low activity in the repo over the last year or so is primarily caused by the amount of labor associated with testing my changes. Now, maybe you'll suggest that I test my own library, then damn the torpedoes and check in the changes, and let other people complain to me when their libraries break. That would work... except that many people aren't paying attention to the health of their libraries on the trunk. I suppose another approach might be to test against the release branch, then svn switch to the trunk and check in my changes there. But that is still laborious. I'm not sure what to do about this, but it's really killin' me. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

5 10

Some good news for boost
by David Abrahams 12 Jun '09

12 Jun '09

Apparently we've been selected as an "alternate finalist" in the SourceForge Community Choice awards! They want us to answer some questions and provide some supporting material. If anyone else in the community would like to contribute to answering questions 1 and 2 below, that would be awesome. Marshall, you're the only person I know of that has any Boost-related video. What do you think about #4? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

5 5

Documentation Edits
by Zachary Turner 12 Jun '09

12 Jun '09

What is the standard protocol for editing documentation? It doesn't appear to be a wiki, unless you have to explicitly request write access in which I wasn't aware of that. The reason I ask is that there are many times where I've spent forever toiling over the documentation of some new library that I wasn't familiar with, because the documentation either provided no / insufficient samples, functions with very general names and one-liner documentation that says (for example) "runs the service". Which is pretty obvious when the function is called run, but no mention of the implications or what "running" even means. Other examples include lack of discussion over memory ownership (I spent 6 hours yesterday trying to trace down a memory corruption only to later find that in one of the many example programs for the library a single line comment that said "this causes X to take ownership of Y". If that had been in the documentation I would have spent 5 minutes tracing down the bug. So my point in all this is can the documentation be in wiki format, and as a fallback is there a way that someone other than a library owner/maintainer can edit it?

2 1

Re: [boost] Possible problem: Christian Schladetsch
by John Maddock 12 Jun '09

12 Jun '09

> Let's not turn an accidental mailing into a tar and feather. All things > said and done, he is at least attempting to contribute something to the > community. Indeed, can we please consider this thread closed now, Thanks, John Maddock. Boost Moderator.

1 0

1.40.0 showstoppers
by Vladimir Prus 12 Jun '09

12 Jun '09

During last release cycle, we talked that there should be a way to flag some issues as showstoppers for next release, so that next release is either delayed until the issue is fixed, or the issue is explicitly downgraded by the release team after consideration. However, I am not sure we've reached definitive agreement on how such issues should be marked. One proposal is to use the 'showstopper' status. Does that sound OK to our release managers? If so, shall this convention be documented somewhere, and should release procedures be adjusted to including checking this list prior to rolling betas and final release? I can do the necessary edits if everybod agrees, and tell me what to edit. Thanks, Volodya

1 0

Re: [boost] "boost cold shoulder" (was proposal for #pragmaonce support)
by Brian Wood 11 Jun '09

11 Jun '09

Sid Sacek writes: > I believe I belong to a third category that you didn't mention below: > 3. The middle-aged mellowed-out "try to always do the right thing", > "using namespace boost", crowd. I don't think doing the right thing implies automatically using a Boost library, but rather considering the options. I encourage people to "chew the meat and spit the bones" when it comes to Boost. Some of the libs are very helpful and are implemented well. Other libs have some problems -- http://webEbenezer.net/comparison.html<http://webebenezer.net/comparison.html> . I will say though that doing the right thing in my book usally means using Boost Intrusive and that Ebenezer Enterprises offers exclusive marshalling/serialization support for two Boost Intrusive containers. If there's interest in having marshalling support for other Intrusive containers, we are willing to consider adding more support in that area. Brian Wood Ebenezer Enterprises www.webEbenezer.net <http://www.webebenezer.net/> "Then Samuel took a rock and set it up between Mizpah and Shen. He named it Ebenezer [Rock of Help] and said, 'Until now the L-RD has helped us.'"

1 0

[multi_array] Negative strides
by John Reid 11 Jun '09

11 Jun '09

I could not find any support in boost::multi_array for negative strides. Does anyone know what the rationale was for not implementing them? John.

3 6

Proposal for #pragma once support
by Zachary Turner 11 Jun '09

11 Jun '09

I would like to propose conditional support for #pragma once be added to all header files in boost. This would involve, at the beginning of every header file, a preprocessor check to determine whether or not the particular compiler is on a whitelist of known compilers to optimized #pragma once. If so, #pragma once is used. so, something like this: #if defined(_MSC_VER) /* || defined(OTHER_PRAGMA_ONCE_ENABLED_COMPILER) ... */ #pragma once #endif the rest of the header file, including the original #include guard, could be as normal. to demonstrate the motivation for this, consider the sample on this page: http://www.gamearchitect.net/Articles/ExperimentsWithIncludes.html. At the bottom there is a zip file with a visual studio solution that contains 3 different projects. Each project contains 200 header file, each of which includes all of the other 199 header files. There is a single cpp file with a main function which includes all 200 header files. All 3 projects use internal #include guards. In addition: Project 'RedundantGuard' - Uses external include guards (wrapping the invocation of #include itself inside the appropriate guard) as discussed in the book Large Scale C++ Software Design Project 'PragmaOnce' - Uses #pragma once Project 'Nothing' - Uses nothing additional other than the internal include guards. Here are the build timings on my machine (Visual Studio 2008 Service Pack 2) RedundantGuard - 1 second compile + link time PragmaOnce - 1 second compile + link time Nothing - 15 seconds compile + link time In addition I have tested this in the code base of a commercial product I am working on (~40,000 lines of code). It consists of about 6 different projects, some of which have dependencies between each other and some which don't, so that parallel compilation can happen in some instances RedundantGuard - Not Tested PragmaOnce - 1 minute, 25 seconds compile + link time Nothing - 2 minutes, 1 second compile + link time So, I believe that boost compile times can benefit significantly from this. Thoughts?

20 38

Re: [boost] Proposal for #pragma once support
by Zachary Turner 11 Jun '09

11 Jun '09

On Tue, Jun 9, 2009 at 11:50 AM, <dherring(a)ll.mit.edu> wrote: > On Tue, 9 Jun 2009, Zachary Turner wrote: > > Here are the build timings on my machine (Visual Studio 2008 Service Pack >> 2) >> >> RedundantGuard - 1 second compile + link time >> PragmaOnce - 1 second compile + link time >> Nothing - 15 seconds compile + link time >> > ... > >> So, I believe that boost compile times can benefit significantly from >> this. >> >> Thoughts? >> > > Could you run benchmarks on gcc? Will my compile times suffer for your > improvement? > > - Daniel > It seems someone else in the thread has already run benchmarks on GCC, but regardless of how the benchmarks did or did not turn out, I can say with 100% certainty that nobody will suffer. That's the exact reason I mentioned that compilers should be whitelisted based on which ones benefit from #pragma once, and only use #pragma once for said compilers. #if defined(_MSC_VER) && (_MSC_VER >= 1020) #pragma once #endif That's all it takes. Everybody benefits. Of course I don't have licenses for every C++ compiler around, but I'm sure there are other compilres in which it benefits also. So I would need some assistance from other people who do have other compilers to help find out which compilers it does offer an improvement on. And of course, the default would be to NOT use pragma once, erring on the side of caution. If you see any downsides to this approach let me know, but it seems like a win/win for everyone. To make it even more explicit, there could even be a global macro, which defaults to undefined, called BOOST_USE_PRAGMA_ONCE. The programmer would be forced to explicitly declare this macro before including any boost headers, and if it is enabled, boost would use pragma once.

9 16

possible problem with boost::iostreams::file_descriptor
by Zachary Turner 11 Jun '09

11 Jun '09

nested file_descriptor implementation class is defined as follows: struct impl { impl() : #ifdef BOOST_IOSTREAMS_WINDOWS handle_(reinterpret_cast<handle_type>(-1)), #else handle_(-1), #endif flags_(0) { } impl(handle_type fd, bool close_on_exit) : handle_(fd), flags_(0) { if (close_on_exit) flags_ |= impl::close_on_exit; } ~impl() { if (flags_ & close_on_exit) close_impl(*this); } enum flags { close_on_exit = 1, append = 4 }; handle_type handle_; int flags_; }; In the second constructor in particular we have this: impl(handle_type fd, bool close_on_exit) : handle_(fd), flags_(0) { if (close_on_exit) flags_ |= impl::close_on_exit; } I think this should be changed. Just because close_on_exit is specified to false does not mean a file is not open. It just means don't close it if it is. I think flags enumeration should be changed to: enum flags { close_on_exit = 1, good = 2, append = 4 }; and constructors / code should be changed accordingly. Otherwise following code (Windows) asserts, even though I don't think it should: bool is_open(HANDLE h) { return h && h!=INVALID_HANDLE_VALUE;} HANDLE h = ::CreateFile("C:\\autoexec.bat", GENERIC_READ, FILE_SHARE_READ|FILE_SHARE_WRITE,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL); boost::iostreams::file_descriptor fd(h, false); BOOST_ASSERT(fd.is_open() == is_open(h)); Thoughts?

3 5

Re: [boost] Proposal: Monotonic Containers: Performance test
by Christian Schladetsch 11 Jun '09

11 Jun '09

void test_speed() { typedef monotonic::map<int, monotonic::list<int> > map_with_list; monotonic::inline_storage<1000000> storage; map_with_list m(storage); size_t count = 10000; boost::timer timer; for (size_t i = 0; i < count; ++i) { int random = rand(); map_with_list::iterator iter = m.find(random); if (iter == m.end()) m.insert(make_pair(random, monotonic::list<int>(storage))); else iter->second.push_back(i); } double elapsed = timer.elapsed(); cout << "monotonic: " << elapsed << endl; // do the same thing, with std::containers { typedef std::map<int, std::list<int> > map_with_list; map_with_list m; for (size_t i = 0; i < count; ++i) { int random = rand(); map_with_list::iterator iter = m.find(random); if (iter == m.end()) m[random] = std::list<int>(); else iter->second.push_back(i); } double elapsed = timer.elapsed(); cout << "std: " << elapsed << endl; } } monotonic: 0.005 std: 0.09

4 5

bug-sprint #2114, 2 comments
by Alexander Arhipenko 11 Jun '09

11 Jun '09

I have 2 major comment on the updated patch. Consider following snippet from gcc.hpp: #if __GNUC__ >= 4 && !defined(__MINGW32__) && !defined(__CYGWIN__) # define BOOST_SYMBOL_EXPORT __attribute__((visibility("default"))) # define BOOST_SYMBOL_HIDE __attribute__((visibility("hidden"))) # define BOOST_SYMBOL_IMPORT BOOST_SYMBOL_EXPORT ...And assume following scenario: Someone is writing shared library (let's name it foo) with 'visilibility=hidden' option. Library foo is using e.g. boost_filesystem. In this case, all the symbols marked with BOOST_FILESYSTEM_DECL will be exported from foo library. This could easily break foo library's ABI (in case of migration to the newest boost version etc.), so BOOST_SYMBOL_IMPORT should be defined for gcc as empty macro: # define BOOST_SYMBOL_IMPORT. The second comment: BOOST_EXCEPTION_EXPORT/IMPORT are intended for re-exporting exceptions from shared library. So, they should be defined for gcc as: # define BOOST_EXCEPTION_EXPORT BOOST_SYMBOL_EXPORT # define BOOST_EXCEPTION_IMPORT BOOST_SYMBOL_EXPORT and not as: # define BOOST_EXCEPTION_EXPORT BOOST_SYMBOL_EXPORT # define BOOST_EXCEPTION_IMPORT BOOST_SYMBOL_IMPORT Note: for the current patch version this part works as expected, since BOOST_SYMBOL_EXPORT == BOOST_SYMBOL_IMPORT for gcc. See also this thread (search for exception): http://lists.boost.org/Archives/boost/2008/12/146068.php Regards

4 8

[candidate bloom_filter] Default Sequence
by JOAQUIN M. LOPEZ MUÑOZ 11 Jun '09

11 Jun '09

Currently, the default Sequence template arg is class Sequence = fusion::vector< detail::default_hash<0>, detail::default_hash<1>, detail::default_hash<2> > which implies the default K is 3. I propose to generalize this a bit so that we have something like template<typename K> default_hash_sequence...; such that default_hash_sequence<K> is the fusion sequence default_hash<0>,...,default_hash<K-1> (I don't know Fusion but I'm sure this can be done) and then put class Sequence = default_hash_sequence<3> So, a user can easily set bloom_filter<foo,default_hash_sequence<K> > with a K other than 3. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] Proposal: Monotonic Containers
by joaquin＠tid.es 10 Jun '09

10 Jun '09

Stewart, Robert escribió: > joaquin(a)tid.es wrote: > On Tuesday, June 09, 2009 9:34 AM > >> Stewart, Robert escribió: >> >>> There's a problem with using an allocator for the node based >>> containers: they use the allocator to allocate the elements >>> but not the nodes. That implies free store (de)allocations >>> for the nodes which is contrary to the intended purpose of >>> this proposal. >>> >> Umm, I beg to differ. If we have a node-based container >> >> xxx<T,...,custom_allocator<T> > >> >> and node<T> is the internal node type, the container is required >> to do the allocation using an allocator of type >> >> custom_allocator<T>::rebind<node<T> >::other. >> >> The container is not allowed to do any kind of allocation using >> other means than the custom_allocator<X> family of allocators. >> > > If custom_allocator<node<T> > is not specialized to do the same as > custom_allocator<T>, or to use the same memory pool, then it > doesn't fit the proposal. Point conceded, but how would you do otherwise? Specifying a custom allocator is your only way to affect the container's allocation behavior. Seems like you're implying that the container wrapping approach is in some way more powerful than directly specifying the custom allocator, which is not. Your only chance to solve the problem you mention is to make custom_allocator<node_type<T> > use the same memory pool. There's a way to do this. If you construct the container with custom_allocator<T> a; xxx<T,...,custom_allocator<T> > x(a); then xxx will use an object of type custom_allocator<node<T> > for its allocation needs, which perforce will be an object differnt to the allocator a you've passed; but the container is required to construct this internal allocator as a copy of a: // inside xxx implementation custom_allocator<node<T> > internal_a(a); So you can use this knowledge to pass info around, for instance on the memory pool to be used. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

10 26

first review submission of timer_queue.zip
by JohnQ 10 Jun '09

10 Jun '09

Hi, Thanks for pointing me to the submission requirements page... I just uploaded timer_queue.zip to boost vault for first review. Haven't got everything shipshape yet but I'm hoping I've satisfied enough of the requirements so I can start getting some feedback on functionality. If not, let me know so I can rework and resubmit. In essence, timer_queue is a library for creating timers that fire at some arbitrary time in the future and hand you back a void* that you provided when you created the timer. Timers can be deleted before they fire by providing an id (can be non-unique) when you create a timer that can be used to delete particular sets of timers later on. Thanks to any who take the time to review this and help me make it better. John Q.

2 1

[mpl]iter_fold_if Forward Backward rationale?
by Larry Evans 10 Jun '09

10 Jun '09

Why is there both a ForwardOp and BackwardOp template argument to iter_fold_if? https://svn.boost.org/trac/boost/browser/trunk/boost/mpl/iter_fold_if.hpp#L… I would have thought that only 1 was needed. Since iter_fold_if is not documented here: http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/refmanual_toc.h… I assume it's not meant to be used by the user, but is only an implementation detail; however, it, or a variation, might be useful to implement the and_seq mentioned here: http://article.gmane.org/gmane.comp.lib.boost.devel/186204 As shown in that post, the template, while_if_then was used, and it does not require anything like both a ForwardOp and BackwardOp, it just requires the If and Then unary metafunctions. One problem I encountered with while_if_then was moving to the end of the sequence, at which time the Then metafunction couldn't be called; hence, I had to make it lazy to avoid dereferencing the end iterator. Is that somehow related to the need for BackwardOp in iter_fold_if. IOW, because iter_fold_if might reach the end iterator, it has to backup? I'm really asking because in the variadic template version of mpl, I wondering if iter_fold_if could be replaced with something like while_if_then (which may be renamed fold_if to be more consistent with other names with similar function). Any insight about the rationale for the iter_fold_if would probably save me considerable time in deciding whether it can be replaced with the proposed fold_if. -regards, Larry

3 28

[filesytem][1.39.0] basic_path::clear mia?
by Jeff Flinn 10 Jun '09

10 Jun '09

http://www.boost.org/doc/libs/1_39_0/libs/filesystem/doc/reference.html#bas… lists void clear(); as an available modifier on basic_path. Neither I nor MSVC8 seem to be able to find it. Am I doing something wrong? Thanks, Jeff

1 0

Re: [boost] Proposal: Monotonic Containers
by Artyom 10 Jun '09

10 Jun '09

> The space has already been created before the allocator is > requested to > provide for new storage. > > Otherwise, we could never use a vector<char> on a > machine that requires > 16-byte alignment. > This is not correct. Allocators allocate memory as single chunk. So, if you use vector<char> that has size of 10 characters, it would allocate a single chunk of at least 10 bytes, and it's beginning would be aligned to 8 or 16. So if you for example, allocate 3 charrecters that start at 0x100 to 0x102, and then you would try to allocate single integer you need to return pointer with value 0x104, 0x108 or 0x110-- aligned to 4, 8 or 16 according to architecture requirements, if you would return 0x103 it may cause illegal operation on some architectures like ARM, hundreds cycles cost on architectures like IA64 and fault in execution of atomic operations like in shared_ptr. You **must** return aligned pointers from allocators. Artyom

3 4

Re: [boost] [multi_array] Negative strides
by pete＠pcbartlett.com 10 Jun '09

10 Jun '09

>John Reid <j.reid(a)mail.cryst.bbk.ac.uk> wrote:John Reid wrote: >> Either the library was designed with negative strides in mind and it is >> just the assertions that are stopping me using them or they were never >> part of the original spec and are not safe to use. In either case I >> can't find them mentioned in the documentation. Could the owner of the >> library clear this up? >Do libraries have owners? Posts on boost.multi_array don't seem to >provoke many responses. Nearly all libraries have owners (see e.g. http://gitorious.org/boost/svn/blobs/master/libs/maintainers.txt ). There is considerable variation in how closely each owner is monitoring this list. Pete

1 0

Re: [boost] [Christian S] Spirit and ANTLR - Request for example
by Christophe Henry 10 Jun '09

10 Jun '09

> brought an idea to boost and had it shot down [...] I quite agree with Luke's explanation and while Christian's behaviour is not perfect, I'd like to point out that bringing a new idea to boost for the first time is a stressful experience, as I myself remember full well. And having his idea immediately shot down is even less nice (as I also remember full well). It seems to happen quite sometimes that people coming with new ideas are met with (unconsciously) not so friendly behaviour. Perhaps we should think about the way new people are met if we don't want to end as a closed (and thus condemned) community... And in the same time, maybe Christian could take a short break and we could all try to restart on a better basis. I therefore offer to close this thread for now as it clearly brings nothing but spam in our mailboxes. If Christian comes up later with interesting examples, we would all profit from them. Regards, Christophe

2 1

Re: [boost] Proposal: Monotonic Containers
by Artyom 10 Jun '09

10 Jun '09

Hi, Several notes: 1st... This code does not compile with gcc-4.3 (mingw) a) Fix: map.h/set.h --> - set(Predicate P, Allocator const &A) - : Set(P, A) + set(Predicate Pr, Allocator const &A) + : Set(Pr, A) because it shadows template parameter P. b) Fix in ./boost/monotonic/storage_base.h Add #include <boost/cstdint.hpp> 2nd... Never use: #pragma once not portable 3rd... Your allocator is not correct you do not align the pointers as required by most of architectures. You need to provide 8-16 bytes alignment... According to system 4th... Why don't you use boost::pool? It is debugged and tested instead of writing new implementation? 5th... Implement ALL constructors of each container. For example I can call. std::string str="Foo"; std::vector<int> v(str.begin(),str.end()); this is not supported 6th... This is bad idea to derive from std containers. They to do not provide virtual destructors. This may be very error prone. This is just short glance. Artyom --- On Tue, 6/9/09, Christian Schladetsch <christian.schladetsch(a)gmail.com> wrote: > From: Christian Schladetsch <christian.schladetsch(a)gmail.com> > Subject: Re: [boost] Proposal: Monotonic Containers > To: boost(a)lists.boost.org > Date: Tuesday, June 9, 2009, 3:06 PM > Hello, > > That is not what I asked for. I wanted online docs and > code. We are very > >> busy people, and anything that takes extra time is > likely to mean we don't > >> bother. > > > > > OK well on second thought, what? > > I am also busy. > > I gave you a link to code and documentation in the one > archive. > http://www.boostpro.com/vault/index.php?action=downloadfile&filename=Monoto… > > Click on the link, get the code and the documentation. > Sorry that you have > to click into the archive twice, but boost doesn't have a > better way of > doing it ATM that I am aware of. > > Chrstian. > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

2 2

Re: [boost] identifying a string type
by Steven Ross 10 Jun '09

10 Jun '09

Is there a boolean argument that can be used to identify whether a data type is some form of string that has a [] operator that returns an integer data type (preferably 2 or less bytes in size)? I now am using enable_if so that strings and floats are identified and the proper specialized call is made for them when spread_sort is called by the user. It would be nice to automatically identify strings too inside enable_if, so that the user can just call "spread_sort" and the correct specialized and optimized sorting call will be made depending on the data type for integers, floats, and strings, and std::sort will be called for unsupported data types.

5 7

Proposal: Extended Allocators (was Montonic Containers)
by Christopher Jefferson 10 Jun '09

10 Jun '09

It is my belief (but I'm happy to shown wrong) that the idea of 'Monotonic Containers' to provide a new allocator for vector to support a small block of memory is fundamentally not going to work, due to 2 limitations of allocators: 1) There is no support for in-line expansion (effectively, realloc which doesn't move if it can't realloc) 2) There is no support for an allocator to say "No, you can't have X memory, but I could give you Y", so it's hard to "exactly fill" a limited memory buffer. I have been working around this by implementing new special containers, which know about the size of a fixed buffer and therefore can make use of the space. I now think I'm probably going about this the wrong way, a much better way would be to implement: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2045.html , or a variant thereof. The big problem with doing this "within boost" is that it would pull in a basically complete implementation of std::allocator and the containers into boost. In an ideal world, such a small and in my opinion useful extension would have been added to C++0x, but it's far too late for that now. tl;dr : Seeing as we are having a "what would boost accept" couple of days, would adding an (extended) implementation of a substantial part of the standard library be acceptable, or would I be better off trying to get this picked up by one of the existing standard libraries to pick this up (my worry being they may not want, quite sensibly, want to accept code which is not standardised). Chris

3 2

boost::directx?
by Christian Schladetsch 09 Jun '09

09 Jun '09

Hello, Is there a possibility of making submissions that use meta-C++ to assist with writing DirectX-based code? Obviously, DirectX is Microsoft-specific (but not necessarily platform specific!). So my question comes down to "is there a space in boost for MS-specific systems"? Perhaps in boost::microsoft or boost::directx or boost::microsoft::directx. I have a number of systems that are generally useful, and would like to support the use of boost in game development. It is hard enough to get gamedevs to use STL, let alone boost. But for example, creating vertex declarations is a royal PITA and can be assisted with some deft use of boost::mpl. Plus, we are already using boost::shared_ptr<> to make com_ptr<>, but it could be made more obvious and a lot of people don't know how to use it. There are two ways of looking at it. First, boost is about C++ and not about supporting specific API's. Fair enough - but then there are many boost libraries that use system-specific idioms such as threads and lock-free containers. It could be argued that boost doesn't want to tie itself to a proprietary API which itself will be versioned and modified externally to boost, but the same is already true in a lot of what boost does. Another way of looking at it is that boost is here to be used by real people solving real problems. In this case, it seems that there is room within a new namespace for domain-specific boost libraries. I realise this is a can of worms. What do you think? Should boost be more egalitarian and increase its possible audiance, or is introducing a dependancy on a 3rd party proprietary API an anathema to boost? Regards, Christian. ----- http://www.linkedin.com/in/christianschladetsch

13 40

[Christian S] Spirit and ANTLR - Request for example
by John Phillips 09 Jun '09

09 Jun '09

Christian, Inside the directx thread you asserted that there are things that ANTLR can do and Spirit can't. This met with some resistance, but I would like to take a different approach. Please post a working code example, along with rationale for why you want to do it, that shows something ANTLR can do, but Spirit can't. The goal is to move this out of the land of unsupported allegations, and into specific examples that can promote specific responses. My experience of Joel and Hartmut suggests that if you have any such real examples, they will use them as a basis for improving Spirit, a process which benefits everyone. If you display examples, and Hartmut and Joel (or anyone else) respond by providing working examples of how Spirit does that, too, then better information is propagated on the list, and again everyone benefits. In general, this is a better way to critique by comparison. Provide actual working code for the comparison, and there is far less room for misinterpretation of intent or conclusions. John

14 27

Borland tests
by Robert Ramey 09 Jun '09

09 Jun '09

The serialization library fails to build on the latest borland compiler with the error message quoted below. This suggests to me that some changes might be in order for config/borland and/or perhaps iterator_facade.hpp Robert Ramey "C:/BuildAgent/work/e5a72339587b6bb4/cb2009_3/bin/bcc32" -j5 -g255 -q -c -P -Ve -Vx -a8 -b- -v -Od -IC:\BuildAgent\work\e5a72339587b6bb4\spirit -tWC -tWR -tWC -tWD -WM- -DBOOST_ALL_NO_LIB=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -I".." -I"C:/BuildAgent/work/e5a72339587b6bb4/cb2009_3/include/" -o"C:\BuildAgent\work\e5a72339587b6bb4\results\boost\bin.v2\libs\serialization\build\borland-6.1.3\debug\basic_text_wiprimitive.obj" "..\libs\serialization\src\basic_text_wiprimitive.cpp" ..\libs\serialization\src\basic_text_wiprimitive.cpp: Unknown compiler version - please run the configure tests and report the results Error E2061 ..\boost/iterator/iterator_facade.hpp 484: Friends must be functions or classes Error E2139 ..\boost/iterator/iterator_facade.hpp 484: Declaration missing ; Error E2061 ..\boost/iterator/iterator_facade.hpp 485: Friends must be functions or classes Error E2139 ..\boost/iterator/iterator_facade.hpp 485: Declaration missing ; Error E2061 ..\boost/iterator/iterator_facade.hpp 487: Friends must be functions or classes Error E2228 ..\boost/iterator/iterator_facade.hpp 487: Too many error or warning messages *** 6 errors in Compile ***

3 4

Re: [boost] Proposal: Monotonic Containers
by joaquin＠tid.es 09 Jun '09

09 Jun '09

Stewart, Robert escribió: > Andrew Sutton wrote: > On Tuesday, June 09, 2009 9:07 AM > >>> People will expect that a monotonic::foo<..> is like a >>> foo<..>, and they will accept that it requires a storage >>> argument. But they will find it harder to accept that it >>> requires retooling from a type-argument level of the >>> allocator. >>> >> Why incur the overhead of expectation, when foo<T, >> monotonic::allocator<T>> gives you exactly what you want? >> > > There's a problem with using an allocator for the node based containers: they > use the allocator to allocate the elements but not the nodes. That implies > free store (de)allocations for the nodes which is contrary to the intended > purpose of this proposal. > Umm, I beg to differ. If we have a node-based container xxx<T,...,custom_allocator<T> > and node<T> is the internal node type, the container is required to do the allocation using an allocator of type custom_allocator<T>::rebind<node<T> >::other. The container is not allowed to do any kind of allocation using other means than the custom_allocator<X> family of allocators. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 4

[program options] why is ->multitoken() not default for vector arguments?
by Thorsten Ottosen 09 Jun '09

09 Jun '09

Hi, I have code like bpo::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("file", bpo::value<std::string>(), ".sug file with graph description") ("new_edge", bpo::value<std::vector<unsigned>>()->multitoken(), "two numbers denoting the new edge"); I had to add the ->multitoken to make a command like ./clique_tester.exe --new_edge 1 2 --file bug1.sug ^^^^^^^^ work. This seems wierd. Why would I want a vector of values, yet only parse one of the trailing argument? Thanks -Thorsten

2 5

[ublas] Fwd: Undelivered Mail Returned to Sender
by Maik Beckmann 09 Jun '09

09 Jun '09

Something seems to be wrong with the ublas mailing list setup. This isn't the first time I get a "Undelivered Mail" response. Posting to boost@ and boost- users@ works fine. -- Maik

2 1

gcc visibility support
by Vladimir Prus 09 Jun '09

09 Jun '09

Over in issue 2114 (https://svn.boost.org/trac/boost/ticket/2114) Jürgen has provided a patch to add gcc visiblity support to all separately compiled libraries. gcc visibility is a mechanism similar to dllexport on Windows, with the same benefits. I have tried to apply it, and rebuild program_options. The the size of release shared library went from 272K down to 224K. The number of relocations went from 972 to 872. Both changes seem to be good. It seems to be unlikely to get the authors of every compiled library to look at the patch, so it looks like an alternative approach is necessary. Does anybody have any objections to this approach? If not, I'll check this in somewhere before Jule 15 deadline, and will take care of checking regression results afterwards. - Volodya

5 6

[website] adding Google analytics reports to boost.org
by joaquin＠tid.es 09 Jun '09

09 Jun '09

After reading about Volodya's insertion of a GA tracker for Boost.Build docs, I wonder whether it'd make sense to add one of these to the boost.org website itself. Some of the data we could gather, like for instance the geographical distribution of visitors, can be very illuminating. There are two problems at first sight with this: * Whose the reports' associated Google account should be? * How to make the data public? This is not technically trivial, but maybe some volunteer would like to do the job of extracting the data via the Google Analytics Data Export API: http://www.techcrunch.com/2009/05/22/make-your-google-analytics-data-public/ Thank you, Joaquín M López Muñoz Telefónica, Inevstigación y Desarrollo

6 6

ublas
by boost＠cyberfiber.org 09 Jun '09

09 Jun '09

hoped you could include this in the upcoming release best regards, michael

2 4

Re: [boost] boost::directx?
by Artyom 08 Jun '09

08 Jun '09

Hi, DirectX can't be relevant because it is not cross platform API. I may think of OpenGL but not DX. > Make this some kind of boost::graphics, target both dx > and ogl or w/e in a > seamless fashion, then you have something worthy. Artyom

12 32

boost/checked_delete.hpp
by mbiddeg＠mtn.co.ug 08 Jun '09

08 Jun '09

Hi Guys. I need serious help here, though this is child's play for you all. >From boost/checked_delete.hpp (attached), template<class T> inline void checked_delete(T * x) { // intentionally complex - simplification causes regressions typedef char type_must_be_complete[ sizeof(T)? 1: -1 ]; (void) sizeof(type_must_be_complete); delete x; } template<class T> inline void checked_array_delete(T * x) { typedef char type_must_be_complete[ sizeof(T)? 1: -1 ]; (void) sizeof(type_must_be_complete); delete [] x; } * What's the result of applying sizeof to an incomplete type? * Why is sizeof called twice? * Why is the result of sizeof cast to void? What exactly does that line do? * Is it an empty statement if the sizeof is legal? * Why not apply x = 0; at the end? This code is not too clear to me & the boost documentation is not either. Please assist. Please do not direct me to the C++ standard text. Then again, smart pointers are simple to understand & use, but their implementations are all rather difficult to understand (maybe except scoped_ptr). Which brings me to one more question, why wasn't Andrei's technique of Smart_Ptr (Loki) chosen over the boost implementation technique (a class per smart pointer) for C++ 0x? His allows for an innumerable number of extension through policies. I ask this purely to understand why, not as a rejoinder. Awaiting your feedback. Thank you. Nice day. ______________________________________________________________________ Kizza George Mbidde Interconnect Billing Systems Analyst IT cell: +256 77 221 2982 email: mbiddeg(a)mtn.co.ug [cid:image001.gif@01C9E853.125FFD20]

3 3

Bug Sprint Final Report
by Marshall Clow 08 Jun '09

08 Jun '09

The boost bug sprint started Friday, May 29th, and ended Sunday June 7th. Thank you to everyone who participated! Just because the bug sprint is over, that doesn't mean you can't fix bugs! ;-) Here's a day by day status: Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. 6:00 AM PDT 5/31: 761 open tickets. 6:00 AM PDT 6/2: 747 open tickets. 6:00 AM PDT 6/3: 748 open tickets. 6:00 AM PDT 6/4: 739 open tickets. 8:00 AM PDT 6/5: 730 open tickets. 7:00 AM PDT 6/6: 719 open tickets. 7:00 AM PDT 6/7: 706 open tickets. 7:00 AM PDT 6/8: 710 open tickets (oops!) Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed 5/30: 2 new tickets, 42 modifications, 17 tickets closed 5/31: 2 new tickets, 27 modifications, 8 tickets closed 6/1: 2 new tickets, 42 modifications, 17 tickets closed 6/2: 5 new tickets, 18 modifications, 5 tickets closed. 6/3: 4 new tickets, 19 modifications, 2 tickets closed. 6/4: 3 new tickets, 42 modifications, 24 tickets closed. 6/5: 3 new tickets, 35 modifications, 8 tickets closed. 6/6: 4 new tickets, 61 modifications, 29 tickets closed. 6/7: 1 new ticket, 20 modifications, 4 tickets closed. [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones. Also, tickets can be closed and reopened. ] -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

3 2

spam in tickets
by Steven Watanabe 08 Jun '09

08 Jun '09

AMDG #2030, #2533, and #2703 (all closed tickets) at least were just spammed. In Christ, Steven Watanabe

1 0

[asio] buffered_read_stream issue, with async_read()
by brad higgins 08 Jun '09

08 Jun '09

Hi, I am using boost asio in a project. My program has a TCP protocol which reads a fixed size message header, followed by a variable-sized message body. It is possible to have a message with a 0-byte body, and it is possible that no messages are received for some time. I have an issue when attempting to async_read() a 0-byte body with the buffered_read_stream, detailed here: (1) My program reads a fixed-sized header (2) After this succeeds, my program issues an async read for 0 bytes, for the message body (3) buffered_read_stream sees that storage_ is empty, so it calls async_fill(), to fill it (4) no more messages arrive for some time, so there is no data available to fill (5) BUG -> My program's 0-byte read timer expires, rather than the read() succeeding and calling my handler immediately If I use the boost::asio::tcp::socket instead of the buffered_read_stream, the 0-byte read occurs immediately, and does not time out. I believe the read() with the buffered_read_stream is getting 'blocked' in async_fill(), rather than succeeding immediately. Do you think the buffered_read_stream should have special cases for 0 byte reads to cover this case, or do you think client code should avoid issuing 0 byte reads? Thanks, Brad

3 3

Re: [boost] boost::directx?
by Artyom 08 Jun '09

08 Jun '09

Hello, It is not about OpenGL, DirectX war, it is about Boost policy: http://www.boost.org/development/requirements.html#Portability Quote: 1. A library's interface must portable and not restricted to a particular compiler or operating system. 2. A library's implementation must if possible be portable and not restricted to a particular compiler or operating system. If a portable implementation is not possible, non-portable constructions are acceptable if reasonably easy to port to other environments, and implementations are provided for at least two popular operating systems (such as UNIX and Windows). DirectX does is **strictly** Windows API, this violates requirement of Boost library portability. You may create general 3D graphics library with implementations in terms of DX for Win32 and OpenGL in terms of UNIX, and add some extended features for OS specific API, just like it is done in Boost.Interprocess or Boost.Asio. But in this case, I think it is just simpler and less error prone to use OpenGL, at least it would be consistent. Best, Artyom --- On Sun, 6/7/09, Christian Schladetsch <christian.schladetsch(a)gmail.com> wrote: > From: Christian Schladetsch <christian.schladetsch(a)gmail.com> > Subject: Re: [boost] boost::directx? > To: boost(a)lists.boost.org > Date: Sunday, June 7, 2009, 1:04 PM > It is certainly untrue to claim that > DirectX is not relevant to C++. I do > not think, and many others would agree, that OpenGL is a > real alternative. > > I have no wish in turning this into a flame war of DX vs > GL. Whatever. I > simply wanted to raise the idea of a boost::directx or > boost::microsoft::directx namespace, to house common > solutions. > > The reality is that DirectX is here, it is supported by > manufacturers, it is > needed by C++ developers, and it will stay here. > > On Sun, Jun 7, 2009 at 9:51 PM, Artyom <artyomtnk(a)yahoo.com> > wrote: > > > > > Hi, > > > > DirectX can't be relevant because it is not cross > platform API. I may > > think of OpenGL but not DX. > > > > > Make this some kind of boost::graphics, target > both dx > > > and ogl or w/e in a > > > seamless fashion, then you have something > worthy. > > > > Artyom > > > > > > > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

4 4

Re: [boost] boost::directx?
by Artyom 08 Jun '09

08 Jun '09

Hi, > The hard reality is that a lot of people use C++ and > DirectX. A lot of > people use C++ *because* they use DirectX. Another group > use DirectX because > they use C++. It is very good to have a good C++ library for DirectX/Direct3D... But it **does not** belong to Boost that is cross platform project. Project that helps writing good software without vendor lock-in. You can just create another library that may be tightly integrated with Boost. But it does not have place in Boost, like many other good C++ libraries that have no place in Boost. > That audience not only includes but primarily consists of > game developers. > And they all use DirectX. You wrong. I can give you a list of great games that use OpenGL like: - IL-2 - Quake - Unreal Tournament - World of Warcraft And many others. Actually, any game that supports Mac OS X or other OSs uses OpenGL. The fact that most of games developed for MS Windows under MS Windows does not means that all of games use Direct3D. So... You can't claim that directX is only video gaming API, not talking about that not everything is video games, actually in Scientific and research project OpenGL has clear dominance. Best, Artyom

4 6

unique_ptr for C++0x exprimental compilers?
by Dean Michael Berris 08 Jun '09

08 Jun '09

Hi, Is there anybody already implementing an auto_ptr replacement (unique_ptr) for Boost? I've got a really simple implementation that I'm attaching to this email (with tests) that I'm submitting for review. HTH -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

5 7

[mpi] Unmerged change
by Daniel James 08 Jun '09

08 Jun '09

Hi, Changest 48610 has only been partially merged, it needs to be merged because mpi currently includes some deprecated headers that have been removed in trunk. https://svn.boost.org/trac/boost/changeset/48610 Is it okay for me to merge it? Daniel

2 1

Bug Sprint Report for Friday, June 5th
by Marshall Clow 08 Jun '09

08 Jun '09

The boost bug sprint started Friday, May 29th, and runs through Sunday June 7th. We've only got two more days - keep up the good work! Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. 6:00 AM PDT 5/31: 761 open tickets. 6:00 AM PDT 6/2: 747 open tickets. 6:00 AM PDT 6/3: 748 open tickets. 6:00 AM PDT 6/4: 739 open tickets. 8:00 AM PDT 6/5: 730 open tickets. 7:00 AM PDT 6/6: 719 open tickets. Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed 5/30: 2 new tickets, 42 modifications, 17 tickets closed 5/31: 2 new tickets, 27 modifications, 8 tickets closed 6/1: 2 new tickets, 42 modifications, 17 tickets closed 6/2: 5 new tickets, 18 modifications, 5 tickets closed. 6/3: 4 new tickets, 19 modifications, 2 tickets closed. 6/4: 3 new tickets, 42 modifications, 24 tickets closed. 6/5: 3 new tickets, 35 modifications, 8 tickets closed. [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones. Also, tickets can be closed and reopened. ] What can you do? See <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> for details. I've added four new reports to the trac: Open ticket count by owner: <https://svn.boost.org/trac/boost/report/18> Open ticket count by component: <https://svn.boost.org/trac/boost/report/19> Open ticket count by ticket type: <https://svn.boost.org/trac/boost/report/20> Open ticket count by milestone: <https://svn.boost.org/trac/boost/report/21> There's been a lot of discussion on the list about tickets; and there are about a dozen patches that have been tested and are ready to be applied. If you're looking to help, you can look at some of the older bugs, say, the ones for Boost 1.36, and determine if they still apply. If they do, note that in the ticket. There are 35 tickets that are still open that are marked as "to be fixed in Boost 1.36" See <https://svn.boost.org/trac/boost/report/3> for a list of open tickets by milestone. --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

3 3

Fwd: [Math/Statistical Distributions] Help on using distributions' global accessors
by Marco Guazzone 07 Jun '09

07 Jun '09

Hi all, I've decided to "cross-post" the message below to boost devel mailing list in the hope someone can answer to my questions. Sorry for the duplicate Ciao! -- Marco ---------- Forwarded message ---------- From: Marco Guazzone <marco.guazzone(a)gmail.com> Date: Thu, Jun 4, 2009 at 3:40 PM Subject: [Math/Statistical Distributions] Help on using distributions' global accessors To: boost-users(a)lists.boost.org Dear Boost users, I don't understand why the code in the attached file "test_distributions_ko.zip" does not work. :( It compiles without problems, but as I run it I get the following error as soon as the *variance* accessor is called: --- [error] --- Running 2 test cases... ... unknown location(0): fatal error in "exponential_distribution": memory access violation at address: 0x7fffa6254ff8: no mapping at fault address test.cpp(34): last checkpoint *** 1 failure detected in test suite "test::stats test suite" --- [/error] --- I've also tried to replace the use of inheritance with the removal of class "exponential_distribution" and directly injecting inside my namespace the Boost one, that is: namespace test { namespace stats { using ::boost::math::exponential_distribution; using ::boost::math::exponential; }} but without success. Instead, the error *disappear* if I use the code in "test_distributions_ok.zip", where instead of using inheritance and "injection" I use membeship (i.e., composition). Why? My compiler is GCC 4.3.2 and my system is Fedora 10 x86_64. If you want to try the attached code you can simply type 'make' from your shell (provided you have a unix like system) and then run the command "./test". A note about the code: you may ask yourself why I'm redefining some functions already defined by the Boost library. The reason lies in the fact that my final goal is to create a wrapping library in order to change without pain the underlying real implementation. An help or a hint would be very very very appreciated!! :) Thank you very much! -- Marco

2 1

[Bug Sprint] Anyone familiar with the utility library want to try bug #2285?
by Marshall Clow 07 Jun '09

07 Jun '09

Writing some docs for "unwrap_ref". https://svn.boost.org/trac/boost/ticket/2585 -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

4 7

[function] -fno-exceptions
by Vladimir Prus 07 Jun '09

07 Jun '09

There's a bug report that function library fails to compile with -fno-exceptions, with a patch attached: https://svn.boost.org/trac/boost/ticket/2900 The patch seems pretty safe -- any objections if I apply it? I primarily care because there is a similar bug report against program_options, which I can't fix until function is similarly modified. Of course, there's still the approach to declare that we don't care about -fno-exceptions at all. - Volodya

2 1

Bug Sprint Report for Friday, June 5th
by Marshall Clow 07 Jun '09

07 Jun '09

The boost bug sprint started Friday, May 29th, and runs through Sunday June 7th. Today is the last day! Can we get under 700 open tickets? Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. 6:00 AM PDT 5/31: 761 open tickets. 6:00 AM PDT 6/2: 747 open tickets. 6:00 AM PDT 6/3: 748 open tickets. 6:00 AM PDT 6/4: 739 open tickets. 8:00 AM PDT 6/5: 730 open tickets. 7:00 AM PDT 6/6: 719 open tickets. 7:00 AM PDT 6/7: 706 open tickets. Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed 5/30: 2 new tickets, 42 modifications, 17 tickets closed 5/31: 2 new tickets, 27 modifications, 8 tickets closed 6/1: 2 new tickets, 42 modifications, 17 tickets closed 6/2: 5 new tickets, 18 modifications, 5 tickets closed. 6/3: 4 new tickets, 19 modifications, 2 tickets closed. 6/4: 3 new tickets, 42 modifications, 24 tickets closed. 6/5: 3 new tickets, 35 modifications, 8 tickets closed. 6/6: 4 new tickets, 61 modifications, 29 tickets closed. [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones. Also, tickets can be closed and reopened. ] What can you do? See <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> for details. I've added four new reports to the trac: Open ticket count by owner: <https://svn.boost.org/trac/boost/report/18> Open ticket count by component: <https://svn.boost.org/trac/boost/report/19> Open ticket count by ticket type: <https://svn.boost.org/trac/boost/report/20> Open ticket count by milestone: <https://svn.boost.org/trac/boost/report/21> There's been a lot of discussion on the list about tickets; and there are about a dozen patches that have been tested and are ready to be applied. If you're looking to help, you can look at some of the older bugs, say, the ones for Boost 1.36, and determine if they still apply. If they do, note that in the ticket. There are 42 tickets that are still open that are marked as "to be fixed in Boost 1.36" See <https://svn.boost.org/trac/boost/report/3> for a list of open tickets by milestone. --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

[website] Tracking for Boost.Build docs
by Vladimir Prus 07 Jun '09

07 Jun '09

During the last release cycle some concerns were raised about Boost.Build index.html containing Google Analytics tracking code in the release tarballs. See: http://article.gmane.org/gmane.comp.lib.boost.devel/188808 That code was removed, but it had the negative effect that I no longer can see access statistics for the live website -- specifically, for http://beta.boost.org/boost-build2/index.html Is there any way to make the website dynamically add the necessary code? I have modified doc/display_build.php to do that for the generated docs, but I cannot find any similar hook that would handle top-level index.html. Thanks in advance, Volodya

3 2

Boost.logging bugs
by Dmitriy Lyfar 06 Jun '09

06 Jun '09

Hello, We are using boost.logging library in our project. We prefered that library because of header-only structure and it looks great. But recently I have found some two bugs. First of them its crash while output in syslog. I found that template<class msg_type> void operator()(const msg_type & msg) const { syslog( LOG_INFO, msg.c_str() ); } looks incorrect, because second argument is format string, so next line lead boost.logging to crash: amazon.co.uk%2fgp%2f%26nbsp%3b%2fref%3dpe_15031_15751501_pe_47%2f%26nbsp%3b (I need output some html parts in syslog like debug info). So I replaced code above with: template<class msg_type> void operator()(const msg_type & msg) const { syslog( LOG_INFO, "%s", msg.c_str() ); } Which works correct, but it seems not general solution. What do you think? And the second one is compiling under gcc 3.4.6 issue: ../3rdparty/boost/boost_1_37_0/boost/logging/format/destination/syslog.hpp: In member function `void boost::logging::destination::syslog_no_levels_t<convert_dest>::operator()(const msg_type&) const [with msg_type = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, convert_dest = boost::logging::destination::do_convert_destination]': ../3rdparty/boost/boost_1_37_0/boost/logging/detail/manipulator.hpp:571: instantiated from `void boost::logging::manipulator::detail::generic_holder<generic_type, manipulator_base>::operator()(typename manipulator_base::param) const [with generic_type = boost::logging::destination::syslog_no_levels_t<boost::logging::destination::do_convert_destination>, manipulator_base = boost::logging::destination::base<boost::logging::default_, boost::logging::default_>]' LMLog.cpp:219: instantiated from here ../3rdparty/boost/boost_1_37_0/boost/logging/format/destination/syslog.hpp:41: error: expected primary-expression That can be fixed by pointing template keyword before operator() calling: ../3rdparty/boost/boost_1_37_0/boost/logging/detail/manipulator.hpp:571 Use virtual void operator()(param val) const { m_val.template operator()(val); } Instead virtual void operator()(param val) const { m_val.operator()(val); } Thank you for such library, I'm waiting for your comments. Regards, Dmitriy Lyfar.

2 2

Forwarded Message: Re: Bug Sprint - #1777 provide md5
by Kasra 06 Jun '09

06 Jun '09

Hi, I an Kevin Sopp are working on boost::crypto which will have an implementation of md5 and many other algorithms. The library is scheduled to be finished before Xmas. With Best Regards Mr. Kasra Nassiri Department of Mathematics & Computer Science Imperial College London

1 0

Interest check: Boost.Debug
by Zachary Turner 06 Jun '09

06 Jun '09

In my spare time I have been working on a library to analyze debug information from a running program. It either already does, or I would like to have it before I'm done, support all of the following (I'm sure there are plenty of other neat additions that I haven't thought of): - Loading debug info either for the currently running executable or from an offline executable - Printing human readable stack traces from a running program - Dumping stack traces to a file in release mode. In this case it's usually just a dump of the entire stack in binary. - Matching dumped stacks from step 3 to debug information offline to get post-mortem information. - Assuming symbol information is loaded either for the running program or an offline program, format a block of memory in a human readable format to print the structure of the memory (for example, display member values of a class with field names, given a block of memory representing an instance of the class) - Iteration of loaded modules - Check whether debugger is attached - output stream that goes to the debugger console, and is not visible in the debugged process. I'm not sure about the feasibility under non-windows platforms (it's very easy in windows), but I would think that if it's possible to figure out the PID of the process debugging you, that it should be possible to send output to their stderr which should achieve the same effect. - launch process under a debugger and receive basic types of debugging notifications. There's some obvious portability concerns, and some of these things are (considerably) more difficult than others, so I can't say I'd be able to support everything. However I already have rudimentary support for about half the items on the list although it is definitely in its infancy since before now I had not considered extending this to any other platforms / architectures. Main problem is that I can't say that I know enough about OSes other than Windows, and architectures other than x86/x64 to know if it would be not worth the hassle to prepare something like this for introduction into boost. Also everything I've done so far is only on Windows, and I don't suppose I'd have the know-how to make it work on any other OS, so in that sense I'd need some assistance. That being said, is it worth it to tackle something like this or should I just not worry about the generality and keep working on it for personal use only?

7 18

[spirit]
by Chandrashekhar Kumar 06 Jun '09

06 Jun '09

Hi, I have to parse the file, the contents of which(with a header) is below and stuff the double part only to std::vector<double>: "A","B","C","D" 1,2,3,4 5,6.7,8 ........ I started simple without header approach first : from libs/spirit/example/lex/example.hpp: inline std::string read_from_file(char const* infile) { std::ifstream instream(infile); if (!instream.is_open()) { std::cerr << "Couldn't open file: " << infile << std::endl; exit(-1); } instream.unsetf(std::ios::skipws); // No white space skipping! return std::string(std::istreambuf_iterator<char>(instream.rdbuf()), std::istreambuf_iterator<char>()); } from libs/spirit/classic/examples/number_list.hpp: /////////////////////////////////////////////////////////////////////////////// // // Our comma separated list parser // /////////////////////////////////////////////////////////////////////////////// bool parse_numbers(char const* str, vector<double>& v) { return parse(str, // Begin grammar ( real_p[push_back_a(v)] >> *(',' >> real_p[push_back_a(v)]) ) , // End grammar space_p).full; } int main() { std::string str = read_from_file("test.csv"); std::vector<double> v; if (parse_numbers(str.c_str(), v)) { cout << "-------------------------\n"; cout << "Parsing succeeded\n"; cout << str << " Parses OK: " << endl; for (vector<double>::size_type i = 0; i < v.size(); ++i) cout << i << ": " << v[i] << endl; cout << "-------------------------\n"; } else { cout << "-------------------------\n"; cout << "Parsing failed\n"; cout << "-------------------------\n"; } } But after running it, I am getting the result as "Parsing failed". I am going thru the doc to understand it better, but any quick spot will help me immensely. Thanks, Chandra

4 5

[Bug Sprint] Ticket #351
by Marshall Clow 05 Jun '09

05 Jun '09

https://svn.boost.org/trac/boost/ticket/351 is the oldest "bug" in the trac system. I'm trying to figure out what Jens meant in his last comment (dated 4-11-2005), where he said "See issue 4.40 in the C++ committee's library TR issue list". I looked at the current version of the library issues list <http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html>, and they don't have a 4.40 :-( I looked at revision #33 of this document (from April 2005), and they didn't have a 4.40 either. Anyone know what document he was referring to? -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

4 5

Bug Sprint Report for Thursday, June 4th
by Marshall Clow 05 Jun '09

05 Jun '09

The boost bug sprint started Friday, May 29th, and runs through Sunday June 7th. Thursday was a very good day - let's keep it up! The bug sprint will be over Sunday night. Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. 6:00 AM PDT 5/31: 761 open tickets. 6:00 AM PDT 6/2: 747 open tickets. 6:00 AM PDT 6/3: 748 open tickets. 6:00 AM PDT 6/4: 739 open tickets. 8:00 AM PDT 6/5: 730 open tickets. Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed 5/30: 2 new tickets, 42 modifications, 17 tickets closed 5/31: 2 new tickets, 27 modifications, 8 tickets closed 6/1: 2 new tickets, 42 modifications, 17 tickets closed 6/2: 5 new tickets, 18 modifications, 5 tickets closed. 6/3: 4 new tickets, 19 modifications, 2 tickets closed. 6/4: 3 new tickets, 42 modifications, 24 tickets closed. [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones. Also, tickets can be closed and reopened. ] What can you do? See <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> for details. I've added four new reports to the trac: Open ticket count by owner: <https://svn.boost.org/trac/boost/report/18> Open ticket count by component: <https://svn.boost.org/trac/boost/report/19> Open ticket count by ticket type: <https://svn.boost.org/trac/boost/report/20> Open ticket count by milestone: <https://svn.boost.org/trac/boost/report/21> There's been a lot of discussion on the list about tickets; and there are about a dozen patches that have been tested and are ready to be applied. If you're looking to help, you can look at some of the older bugs, say, the ones for Boost 1.36, and determine if they still apply. If they do, note that in the ticket. There are 35 tickets that are still open that are marked as "to be fixed in Boost 1.36" See <https://svn.boost.org/trac/boost/report/3> for a list of open tickets by milestone. --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

[iterator] std::sort on zip_iterator (repost)
by Jeremiah Willcock 05 Jun '09

05 Jun '09

(Resubmitting to Boost list because I did not receive any answers on boost-users, nor any helpful answers on the Boost list.) I would like to sort two separate vectors of numbers, treating corresponding elements of the two vectors as tuples and sorting the tuples. In particular, I am only comparing the first elements of the tuples; that may or may not be relevant to my problem. An example program is: #include <vector> #include <algorithm> #include <iostream> #include <boost/tuple/tuple.hpp> #include <boost/iterator/zip_iterator.hpp> struct compare_first_elements_in_tuples { template <typename Tuple> bool operator()(const Tuple& a, const Tuple& b) const { return (a.template get<0>()) < (b.template get<0>()); } }; int main(int, char**) { size_t a_data[5] = {0, 2, 1, 2, 4}; size_t b_data[5] = {1, 1, 5, 3, 7}; std::vector<size_t> a(a_data, a_data + 5); std::vector<size_t> b(b_data, b_data + 5); std::cout << "Before:"; for (size_t i = 0; i < a.size(); ++i) { std::cout << " (" << a[i] << ", " << b[i] << ")"; } std::cout << std::endl; typedef std::vector<size_t>::iterator vec_iter; typedef boost::zip_iterator<boost::tuple<vec_iter, vec_iter> > zip_iter; std::sort(zip_iter(boost::make_tuple(a.begin(), b.begin())), zip_iter(boost::make_tuple(a.end(), b.end())), compare_first_elements_in_tuples()); std::cout << "After:"; for (size_t i = 0; i < a.size(); ++i) { std::cout << " (" << a[i] << ", " << b[i] << ")"; } std::cout << std::endl; return 0; } On gcc 4.0.1, the sort operation results in the element (2, 1) (a pair of corresponding elements in a and b) being duplicated, while the element (1, 5) does not appear in the result at all: Before: (0, 1) (2, 1) (1, 5) (2, 3) (4, 7) After: (0, 1) (2, 1) (2, 1) (2, 3) (4, 7) I suspect the problem is related to the fact that zip_iterator does not return a "real" reference when dereferenced. Am I mistaken about this? Is the code above supposed to work? If not, is there an alternative way to sort one sequence while swapping elements in another in a corresponding way? I am not able to join the two input sequences into a single sequence of pairs because of other factors in the use case for this code. Thank you for your help. -- Jeremiah Willcock

6 24

[Bug Sprint] [variant] #2839 ambiguous swap call
by Daniel Hulme 05 Jun '09

05 Jun '09

I've just added a test program to ticket #2839: it fails on vc9. The ticket, I think, explains the problem pretty well, but I would like an expert to look at the code. I believe that the program is ill-formed, and it only works on gcc because the BOOST_WORKAROUND disables the code in question. The issue is that variant/detail/move.hpp:114 introduces a templated swap() overload in the same scope it will be called from, to allow move emulation. But, if the variant bounds a type defined in std::, like std::vector, then std::swap is another templated swap() and will be found by ADL. This makes the call ambiguous. My recommendation is that the move-emulation code be removed -- or enable_if'd, if that's possible -- until the generalised Boost.Move implementation is ready to be adopted. If we believe the code as it stands is correct, then I think the test case should be added to trunk and release, and additional BOOST_WORKAROUNDs added for all the compilers where the test fails. -- “Papa Hegel he say that all we learn from history is that we learn noth- hing from history. I know people who can't even learn from what happened this morning. Hegel must have been taking the long view.” -- John Brunner, ‘Stand on Zanzibar’

4 9

Re: [boost] boost.timer library submission...
by JohnQ 05 Jun '09

05 Jun '09

Hi Dmitry, Answers in-line... >> Do you hold a mutex locked while invoking a callback? yes, I'm holding a boost::unique_lock<boost::mutex>... as a result, the callback method shouldn't do much. Mine only records the fact that the timer fired and the data passed back and puts it on a queue for another of my app threads to handle. >>What mechanism do you use to suspend till it's time to fire a callback? boost::condition_variable m_timed_cond.timed_wait(timer_lock, cur_timer) >>What is the precision of your library? I mean if you instruct the >>library to invoke your callback in so many ms usually your callback will >>be invoked at bit later. The question is how long later? Or earlier? Typically fires later than earlier... the tolerance window I've been using is 5 ms - 10ms. The unit test included in the lib I uploaded to boost value includes a test that puts 100 timers up and measures when they fire. Occassionally out of that window. So far I've been running this on my mac and there's a lot running on it typically, so I'm suspicious of my results and think they could be better. >>Does the precision degrade when you register lots of callbacks? Not that I know of... I've put a couple of hundred thousand in there... so far the time to rebalance the underlying map for insertion / deletion hasn't shown up as an effect. >>What's the smallest possible timeout the library lets to register a >>callback with? How does the library handle small (e.g. 1 ms) timeout >>requests? Currently, millisecond resolution but totally happy to change it to reflect the greatest accuracy the underlying system timer can achieve. I've been testing this with a timing window (i.e., anything within, say, 10ms of the original timer also gets called back). The timing window is configurable. What platforms does the library work on? Been compiling this on my mac. Will have it running on Centos shortly. Haven't tried it at all on Win platform yet. >>BR, Dmitry Thanks, John Q.

2 1

Re: [boost] sorting library proposal
by Steven Ross 05 Jun '09

05 Jun '09

Is there a good way to issue a compile-time warning telling people that integer_sort or float_sort isn't being used, because they passed in an incompatible data type? I see static assertions, but what I need is an equivalent static warning, after which I use std::sort. integer_sort won't run on long longs, because it uses size_t for distance codes. I've added a check to see whether the key type being used is of the same size or smaller than a size_t to handle this problem. I don't think integer_sort is an appropriate algorithm for data types larger than a size_t, unless comparisons are ridiculously slow, as the k/s factor starts becoming quite large. Also, I'm using a simple if to decided this: if(sizeof(Div_type) <= sizeof(size_t)) because enable_if appears to only work with classes. I'm assuming here that the compiler is smart enough to figure out that the expression is constant and to only bring in the code if it's true. It would be nice to be able to eliminate the compiler warnings about size, and issue a more concise and meaningful message telling the user that their data type is too big for integer_sort (or incompatible with float_sort, as appropriate).

3 3

Re: [boost] unique_ptr for C++0x exprimental compilers?
by Artyom 05 Jun '09

05 Jun '09

Hi, You can test it using g++-4.3 and g++-4.4. - g++-4.3 supportd rvalue - g++-4.4 implements unique_ptr You may send the code to me if you don't have an access to them Artyom P.S.: I eraced your previous mail accidently > Hi, > > Is there anybody already implementing an auto_ptr > replacement > (unique_ptr) for Boost? I've got a really simple > implementation that > I'm attaching to this email (with tests) that I'm > submitting for > review.

1 0

[fusion] improving compile times
by Eric Niebler 05 Jun '09

05 Jun '09

I'm attaching a simple patch to vector_n_chooser.hpp that replaces some template metaprogramming with preprocessor metaprogramming in the interest of improving compile times. I found this hotspot through profiling, and there are likely to be many more such patches in the near future. I could open a trac ticket and attach all the patches there, or I could just commit them to trunk as I go. Thoughts? P.S. It would be great to get some other heavy users of template metaprogramming interested in making other such changes to bring down the compile times of the core TMP libraries like MPL, Fusion, Proto, etc., etc. -- Eric Niebler BoostPro Computing http://www.boostpro.com Index: vector_n_chooser.hpp =================================================================== --- vector_n_chooser.hpp (revision 53535) +++ vector_n_chooser.hpp (working copy) @@ -25,11 +25,13 @@ #include <boost/fusion/container/vector/vector50.hpp> #endif -#include <boost/mpl/distance.hpp> -#include <boost/mpl/find.hpp> -#include <boost/mpl/begin_end.hpp> #include <boost/preprocessor/cat.hpp> +#include <boost/preprocessor/arithmetic/dec.hpp> +#include <boost/preprocessor/arithmetic/sub.hpp> +#include <boost/preprocessor/facilities/intercept.hpp> #include <boost/preprocessor/repetition/enum_params.hpp> +#include <boost/preprocessor/repetition/enum_trailing_params.hpp> +#include <boost/preprocessor/repetition/enum_params_with_a_default.hpp> namespace boost { namespace fusion { @@ -38,40 +40,23 @@ namespace boost { namespace fusion { namespace detail { - template <int N> - struct get_vector_n; + template <BOOST_PP_ENUM_PARAMS(FUSION_MAX_VECTOR_SIZE, typename T)> + struct vector_n_chooser + { + typedef BOOST_PP_CAT(vector, FUSION_MAX_VECTOR_SIZE)<BOOST_PP_ENUM_PARAMS(FUSION_MAX_VECTOR_SIZE, T)> type; + }; template <> - struct get_vector_n<0> + struct vector_n_chooser<BOOST_PP_ENUM_PARAMS(FUSION_MAX_VECTOR_SIZE, void_ BOOST_PP_INTERCEPT)> { - template <BOOST_PP_ENUM_PARAMS(FUSION_MAX_VECTOR_SIZE, typename T)> - struct call - { - typedef vector0 type; - }; + typedef vector0 type; }; #define BOOST_PP_FILENAME_1 \ <boost/fusion/container/vector/detail/vector_n_chooser.hpp> -#define BOOST_PP_ITERATION_LIMITS (1, FUSION_MAX_VECTOR_SIZE) +#define BOOST_PP_ITERATION_LIMITS (1, BOOST_PP_DEC(FUSION_MAX_VECTOR_SIZE)) #include BOOST_PP_ITERATE() - template <BOOST_PP_ENUM_PARAMS(FUSION_MAX_VECTOR_SIZE, typename T)> - struct vector_n_chooser - { - typedef - mpl::BOOST_PP_CAT(vector, FUSION_MAX_VECTOR_SIZE) - <BOOST_PP_ENUM_PARAMS(FUSION_MAX_VECTOR_SIZE, T)> - input; - - typedef typename mpl::begin<input>::type begin; - typedef typename mpl::find<input, void_>::type end; - typedef typename mpl::distance<begin, end>::type size; - - typedef typename get_vector_n<size::value>::template - call<BOOST_PP_ENUM_PARAMS(FUSION_MAX_VECTOR_SIZE, T)>::type - type; - }; }}} #endif @@ -85,14 +70,12 @@ #define N BOOST_PP_ITERATION() - template <> - struct get_vector_n<N> + template <BOOST_PP_ENUM_PARAMS(N, typename T)> + struct vector_n_chooser< + BOOST_PP_ENUM_PARAMS(N, T) + BOOST_PP_ENUM_TRAILING_PARAMS(BOOST_PP_SUB(FUSION_MAX_VECTOR_SIZE, N), void_ BOOST_PP_INTERCEPT)> { - template <BOOST_PP_ENUM_PARAMS(FUSION_MAX_VECTOR_SIZE, typename T)> - struct call - { - typedef BOOST_PP_CAT(vector, N)<BOOST_PP_ENUM_PARAMS(N, T)> type; - }; + typedef BOOST_PP_CAT(vector, N)<BOOST_PP_ENUM_PARAMS(N, T)> type; }; #undef N

9 21

Change to documentation writing guidelines
by Daniel James 05 Jun '09

05 Jun '09

Hi, I'd like to change the guideline for writing reference documentation to include header and namespace information in the detailed documentation. If you arrive at a page by a link or from a search engine, it isn't always easy to work this out. I'll add them to the list here: http://beta.boost.local/doc/libs/release/more/writingdoc/structure.html#det… Boostbook documentation already includes this. Any objections? Daniel

6 15

[threads] final decision on making parts of Boost.Threads header-only
by JOAQUIN M. LOPEZ MUÑOZ 04 Jun '09

04 Jun '09

Hi, A few weeks ago we had a discussion about the convenience of making part of Boost.Threads, namely mutexes and locks, header-only. Some (including Anthony Williams) supported the idea, others disliked it: http://lists.boost.org/Archives/boost/2009/04/150524.php What the final decision on this issue is? If positive (i.e. favoring the change), can it be expected to be done for Boost 1.40? As a remainder, I've created an associated trac ticket: https://svn.boost.org/trac/boost/ticket/2964 Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

boost trac for upcoming libraries?
by Barend Gehrels 04 Jun '09

04 Jun '09

Hi, Is the Boost Trac system intended for official libraries only, or can we also use it for (to be) proposed libraries? Thanks, Barend

6 6

Discussion on compilation-error-when-using-ptr-container
by Eric Niebler 04 Jun '09

04 Jun '09

You should direct questions to boost(a)lists.boost.org.

1 0

[lexical_cast] Locale used during conversion
by Adam Badura 04 Jun '09

04 Jun '09

lexical_cast does not allow to pass the locale to be used during conversion. This is justified with analogy of lexical_cast to other casts which all take only one parameter. So lexical_cast always uses the current global locale. A reasonable choice. However I wanted to propose some additional features. It would be useful to provide (lets call it so for now) classic_lexical_cast which would use std::locale::classic() instead of the global one. I just finalized globalization/localization of our application by adding setting of the global locale to appropriate value according to the selected language. I noticed that all of sudden serialized data (mainly projects) stopped loading/saving correctly. The reason was easy to find. Where previously we had XML node named "item1000" we now have "item1,000" in English or "item1 000" in Polish for example. The projects are no longer interchangeable between applications running in different language version. I corrected this by adding our own lexical_cast which resets the global locale to the classic one, calls boost::lexical_cast and finally resets the global locale back. This special cast is used now whenever we are dealing with texts which are not presented to the final user. This works fine however it seems that resetting the global locale often (each time we save a number in the project for example...) is causing significant performance overhead. (Exact tests have not been yet performed but this seems the only change which might have affected all serialization slowdown.) I might reset it before saving the project and then save the project as usually but this is not very handy as I would have to remember to do it each time I am serializing any data. Also other problems are implied. Other threads for the short period of time see different global locale as well and thus might produce bad strings. And in the end it is impractical. It would be handy to have classic_lexical_cast as well as it could introduce some optimizations knowing that the requested locale is the classic one. Another thing is that it would be handy to introduce a function textual_convert (another example name) which would act like lexical_cast but would take the requested locale as a parameter (this is no longer a cast so it may). lexical_cast might take that locale as a second parameter with default value being the global locale so it could still be used just as any other casting. But I suppose this would not be well seen. Thus why not introduce a different function for that (or maybe there already is one?). It seems those changes would not be difficult to implement and could be hidden in the details of lexical_cast easily. What do you think of that? Finally lexical_cast's documentation might mention explicitly that current global locale is used as it does not mention that if I am not mistaken (I haven't found "locale" word in that document). Adam Badura

3 6

Bug Sprint Report for Wednesday, June rd
by Marshall Clow 04 Jun '09

04 Jun '09

The boost bug sprint started Friday, May 29th, and runs through Sunday June 7th. Wednesday was not a good day in terms of bug closing; the good news is that we've already (as of 6 AM) closed more bugs on Thursday than all of Wednesday. Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. 6:00 AM PDT 5/31: 761 open tickets. 6:00 AM PDT 6/2: 747 open tickets. 6:00 AM PDT 6/3: 748 open tickets. 6:00 AM PDT 6/4: 739 open tickets. Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed 5/30: 2 new tickets, 42 modifications, 17 tickets closed 5/31: 2 new tickets, 27 modifications, 8 tickets closed 6/1: 2 new tickets, 42 modifications, 17 tickets closed 6/2: 5 new tickets, 18 modifications, 5 tickets closed. 6/3 4 new tickets, 19 modifications, 2 tickets closed. [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones. Also, tickets can be closed and reopened. ] What can you do? See <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> for details. I've added four new reports to the trac: Open ticket count by owner: <https://svn.boost.org/trac/boost/report/18> Open ticket count by component: <https://svn.boost.org/trac/boost/report/19> Open ticket count by ticket type: <https://svn.boost.org/trac/boost/report/20> Open ticket count by milestone: <https://svn.boost.org/trac/boost/report/21> There's been a lot of discussion on the list about tickets; and there are about a dozen patches that have been tested and are ready to be applied. If you're looking to help, you can look at some of the older bugs, say, the ones for Boost 1.36, and determine if they still apply. If they do, note that in the ticket. There are 35 tickets that are still open that are marked as "to be fixed in Boost 1.36" See <https://svn.boost.org/trac/boost/report/3> for a list of open tickets by milestone. --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

Trac unwell?
by Vladimir Prus 04 Jun '09

04 Jun '09

Hi, it looks like Trac is not feeling very well: 1. Opening an issue takes at least 10 seconds, sometimes a minute. 2. Adding a comment to an issue takes equally weird time. 3. From time to time it gives: "Database locked" errors. The page with the error does not have any additional information. Can somebody look into this? - Volodya

5 6

Ticket #637 - Adjusts mpl::pair concept to be compatible with STL pairs
by Joel Falcou 04 Jun '09

04 Jun '09

https://svn.boost.org/trac/boost/ticket/637 Is this feature request still sensible or does fusion make this useless somehow ? If not, I can provide patch+test -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

4 4

trunk vs release
by troy d. straszheim 04 Jun '09

04 Jun '09

From another thread: Steven Watanabe wrote: > AMDG > > troy d. straszheim wrote: >> I've been wondering a bit about this in-syncness recently. >> >> - Does anybody know offhand what the last release was that was >> branched directly from trunk? >> >> - Is there a way to determine, with SVN, how many lines of diff >> there are between trunk and release? I've tried without >> success.... the diff gets to ~80k lines and then the network times >> out. I wonder if I'm doing something wrong. Of course I can get >> some numbers with git but I'm not quite sure I trust them yet. >> >> % git diff --shortstat svn/release svn/master 3505 files changed, >> 209061 insertions(+), 58428 deletions(-) > > This is probably correct as far as it goes. However, it's hard to > tell how much it really means. About half the modified files seem to > be generated html, judging by the output of > > svn diff https://svn.boost.org/svn/boost/branches/release > https://svn.boost.org/svn/boost/trunk --summarize > Hm, that svn command isn't very helpful and runs for ~5 minutes. I'm seeing about 160k lines total changed in actual code (.cpp, .ipp, .hpp). Full report in case anybody is interested: http://sodium.resophonic.com/trunk_vs_release.txt Poking around it looks like the current release branch was created from the fixed 1.34.1 tag in oct 2007 (@ r40341). The 1.34.1 release was in turn branched from... looks like that goes back into the days of CVS, I'll consider it lost. Git maintains that the last common commit between the current trunk and release branches is > 3 years ago: http://gitorious.org/boost/svn/commit/4914d4934fbc7368e2d43e057f6fffdac0f46… So if the trunk is really just a staging area for merges to release, does the notion of having the release branch and trunk 'in sync' at this point make any sense? Why have just one such staging area? -t

13 74

[Serialization]#3118 basic_binary_oarchive.hpp - save_override possible loss of data warnings
by Jeff Flinn 04 Jun '09

04 Jun '09

I've posted the following ticket in light of the current bug sprint. ----------- The following save_override overloads cause possible loss of data warnings on MSVC8 and XCode3.1.2/gcc4.0.1 void save_override(const version_type & t, int) void save_override(const class_id_type & t, int) void save_override(const class_id_reference_type & t, int) with their respective assignments: const unsigned char x = t.t; const int_least16_t x = t.t; While a possible fix would be: const unsigned char x = static_cast<unsigned char>(t.t); const int_least16_t x = static_cast<int_least16_t>(t.t); there is still a possibility of a silent loss of data. We could be safer and use numeric_cast, but that would possibly impact code size and performance, and would introduce a library dependency. Why are the xxx_type strong typedef's using int rather than the smaller types that are being serialized? Any thoughts on the best solution? Thanks, Jeff

4 5

[Bug Sprint][random] overload resolution for constructors/seed
by Steven Watanabe 03 Jun '09

03 Jun '09

AMDG I'm looking at the following tickets: https://svn.boost.org/trac/boost/ticket/351 https://svn.boost.org/trac/boost/ticket/2887 https://svn.boost.org/trac/boost/ticket/2424 #351 and #2887 are effectively the same boost::mt19937 prng1; boost::mt19937 prng2(prng1); // does not call copy constructor #2424 is int seed = 0; boost::mt19937 prng1(seed); // doesn't compile #2424 can be fixed easily without breaking backwards compatibility. Fixing #351 and #2887 will silently change the meaning of the constructor call above. It will also be difficult to emulate the previous (documented) behavior. However, looking at the current standard draft, the constructor that causes these problems is not present, so the standard mersenne twister will have a well behaved copy constructor. Also, only lagged_fibonacci_01, mersenne_twister, and subtract_with_carry provide the offending constructor, so Boost.Random is not consistent. I'd like to have the copy constructor called. What do others think? When testing fixes, I found that rand48 behaves differently with an int64_t seed than with an int32_t seed. According to the current draft standard, they should be equivalent. Should rand48 be changed or should I leave it alone? In Christ, Steven Watanabe

2 2

[iostreams] #2406: implementation in header causes link errors
by Vladimir Prus 03 Jun '09

03 Jun '09

Looking at Trac, I've run into the bug above, which seems both fairly severe and easy to fix, so I took the liberty to commit a patch: https://svn.boost.org/trac/boost/changeset/53427 I've tested it on Linux. Can somebody give it a try on Windows? While I've added necessary BOOST_IOSTREAMS_DECL, I might have missed something. Thanks, Volodya

2 1

[parameter] Testing for existence of a parameter, building ArgumentPacks, more lazy return types
by Jeremiah Willcock 03 Jun '09

03 Jun '09

I have a few questions about the parameter library. Please note that I am using argument packs directly, since I am creating them from another data structure. 1. Is there a way to build Boost.Parameter ArgumentPacks from a program? I am currently using many internal data structures of Boost.Parameter (empty_arg_list and such). Is there another interface to use? 2. Is there a way to tell at compile-time whether a particular parameter exists in an ArgumentPack? I currently have a metafunction that uses a special default type and tests for that; is there a more "official" way? 3. I have a case where the default type for a named parameter cannot be instantiated in some cases where that parameter is given explicitly. The operator||() lazy defaults don't seem to work for that because they get the result_type member from my default right away, even if it won't be used. I currently have a hack to work around this using my parameter_exists test and some metaprogramming. The reason I am working on this low of a level is that I am playing with converting Boost.Graph named parameter structures into ArgumentPacks to have access to Boost.Parameter's nicer capabilities and syntax. I thus need to build all of the argument data structures and such within another function and then access them later. Thank you for your help. -- Jeremiah Willcock

2 5

[Modularization] A new approach to header modularization
by Beman Dawes 03 Jun '09

03 Jun '09

I've started to put together a wiki page based on our ongoing Header Modularization discussions. See http://svn.boost.org/trac/boost/wiki/HeaderModularization I listed eight approaches to meeting the Goals/Objectives/Needs/Wants, and was about to identify the weaknesses of each approach when I hit on approach nine: Move (permanently) each library's root/libs/libname contents into root/boost/libname for the library. In other words, instead of moving the boost/... tree headers to the libs/... tree, merge the libs/... tree into the boost/... tree. For example, Boost.Filesystem is currently organized like this: root/ boost/ filesystem.hpp filesystem/ config.hpp convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp libs/ filesystem/ build/ ... CMakeLists.txt doc/ ... example/ ... index.html ... module.cmake src/ ... test/ ... After the reorganization, filesystem would be organized like this: root/ boost/ filesystem.hpp filesystem/ config.hpp convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp build/ ... CMakeLists.txt doc/ ... example/ ... index.html ... module.cmake src/ ... test/ ... In theory, the root/libs/... tree isn't needed anymore. In practice we might want to keep a root/libs/libname/index.html entry for each library so docs links don't break. Apologies if someone already suggested this approach. It is so simple I can't believe someone didn't already suggest it. Unless I'm missing something, this is the only approach that appears to do fairly well for all of the Goals/Objectives/Needs/Wants, and very well for most of them. It would require some rework of scripts and other setups that depend on the current organization of libs/..., but that seems minor compared to the long-term benefits. Comments? --Beman

18 50

Attachments from old bug tracker
by Jeremiah Willcock 03 Jun '09

03 Jun '09

It appears that somebody attached patches to the equivalent of bug 900 (https://svn.boost.org/trac/boost/ticket/900) in the old bug tracker, and these patches were not moved over to the new tracker. Is it possible to get these attachments? -- Jeremiah Willcock

2 1

Re: [boost] boostcon videos?
by Chandrashekhar Kumar 03 Jun '09

03 Jun '09

> > does anyone know where can I get the videos of the presentations at >> boostcon? >> > > When they are available (i.e, when I finish working on them), I will post > here > detailing where they are. > > Note: Not all the presentations were videotaped. > Thanks! Just curious, was the presentation by Andrei(Iterators must go) was videotaped? and any chance to grab the videotapes(and the ppts) for earlier boostcons?

2 1

boostcon videos?
by Chandrashekhar Kumar 03 Jun '09

03 Jun '09

does anyone know where can I get the videos of the presentations at boostcon?

2 1

[Bug Sprint] What to do with "library submissions"?
by Marshall Clow 03 Jun '09

03 Jun '09

I'm not sure they belong in the Trac system; but where do they belong? I guess it depends on what's going to happen to them.... If they're additions to existing libraries, should they be "feature requests"? If they're new libraries, should they go in the sandbox? https://svn.boost.org/trac/boost/ticket/2749 https://svn.boost.org/trac/boost/ticket/2893 -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

2 1

Bug Sprint Report for Friday, May 29th
by Marshall Clow 03 Jun '09

03 Jun '09

The boost bug sprint started Friday, May 29th, and runs through Sunday June 7th. We're off to a great start! Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones ] What can you do? See <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> for details. I've added three new reports to the trac: Open ticket count by owner: <https://svn.boost.org/trac/boost/report/18> Open ticket count by component: <https://svn.boost.org/trac/boost/report/19> Open ticket count by ticket type: <https://svn.boost.org/trac/boost/report/20> Open ticket count by milestone: <https://svn.boost.org/trac/boost/report/21> The following bugs appear to have been fixed, but the tickets were never closed. I would appreciate it if the library maintainers could verify this and close the tickets. https://svn.boost.org/trac/boost/ticket/145 Iterator https://svn.boost.org/trac/boost/ticket/287 date_time The following tickets are feature requests that are unlikely ever to be implemented. Should they be closed? https://svn.boost.org/trac/boost/ticket/558 database https://svn.boost.org/trac/boost/ticket/100 concept_check https://svn.boost.org/trac/boost/ticket/182 concept_check --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

3 3

[#1497] Ruling needed on tracker usage
by Beman Dawes 03 Jun '09

03 Jun '09

Dave is pressing to do something about this ticket: > Yes, please! Beman, please read the head of that thread: > http://thread.gmane.org/gmane.comp.lib.boost.devel/167139 > > IMO this is '''exceedingly''' important, and the only reason I'm not doing > it myself is that it seems to be the domain of the release managers. It > will be an especially huge missed opportunity if we don't get this > straightened out before the bug sprint. Oops! That starts today! We'd > better get moving. > > Again, if there's any way I can help, including writing the policy, please > let me know. By the way, I'm not attached to eliminating "to be > determined," if that helps in any way to resolve this. The concern of the thread mentioned was about milestones for 1.35.0. The same concern applies today, although the milestone numbers have changed. > [the milestone list] > shows all the tickets that have been assigned to the 1.35.0 milestone. > Does this list have any meaning? It doesn't for me, and hasn't since we went to a schedule-driven release system a year and a half ago. > In other words, are we actually > intending to address all of these problems for 1.35, and put off other > tickets for 1.35.1 or 1.36.0? > > IMO getting this list sorted out and handling the tickets one-by-one > is the most productive way to get us from here to a successful release > of 1.35.0. That may mean a number of new tickets need to be added > (probably at least one for each major failure we're seeing in > http://engineering.meta-comm.com/boost-regression/1_34_1/developer/issues.h… > and possibly others) and it will require part of the release team to > triage the whole list of tickets assigned to 1.35.0 and make some > decisions to put certain tickets off for later. In an organization with paid developers and paid managers, it might be possible to look at the tickets, look at the people and other resources available, assign milestone priorities accordingly, and then use progress on clearing them as a metric to guide release activities. But I'm at a loss for how we could use such milestones for Boost. So any ideas would be appreciated if folks think the milestones do have a place in Boost's process of getting releases out. --Beman

3 2

[profile_templates] minor issue + patch
by Jonathan Franklin 03 Jun '09

03 Jun '09

Steven, I was playing around w/ the profile_templates tool on my Ubuntu box (Jaunty Jackelope - 9.04), and wasn't getting any results. After a little investigation, I discovered that the regex that postprocess.cpp uses for the enter_message wasn't matching the warning that my gcc compiler (4.3.3) was spitting out. Turns out that the regex is looking for a single char here: (.*): warning: .int -----------------^ But I'm getting a unicode E28098 (left single quotation mark), which is 3 chars, hence the failure to match. Being somewhat content w/ my terminal settings (and lazy to boot), I just modified the regex to match .+int instead of .int, and it *seems* to work fine. I think I have a sandbox account, and can commit the attached patch if you like the fix. Jon

2 2

Bug Sprint Report for Tuesday, June 2nd
by Marshall Clow 03 Jun '09

03 Jun '09

The boost bug sprint started Friday, May 29th, and runs through Sunday June 7th. We slowed down a lot on Tuesday - let's pick it up again. Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. 6:00 AM PDT 5/31: 761 open tickets. 6:00 AM PDT 6/2: 747 open tickets. 6:00 AM PDT 6/3: 748 open tickets. Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed 5/30: 2 new tickets, 42 modifications, 17 tickets closed 5/31: 2 new tickets, 27 modifications, 8 tickets closed 6/1: 2 new tickets, 42 modifications, 17 tickets closed 6/2: 5 new tickets, 18 modifications, 5 tickets closed. [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones. Also, tickets can be closed and reopened. ] What can you do? See <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> for details. I've added four new reports to the trac: Open ticket count by owner: <https://svn.boost.org/trac/boost/report/18> Open ticket count by component: <https://svn.boost.org/trac/boost/report/19> Open ticket count by ticket type: <https://svn.boost.org/trac/boost/report/20> Open ticket count by milestone: <https://svn.boost.org/trac/boost/report/21> There's been a lot of discussion on the list about tickets; and there are about a dozen patches that have been tested and are ready to be applied. If you're looking to help, you can look at some of the older bugs, say, the ones for Boost 1.36, and determine if they still apply. If they do, note that in the ticket. There are 35 tickets that are still open that are marked as "to be fixed in Boost 1.36" See <https://svn.boost.org/trac/boost/report/3> for a list of open tickets by milestone. --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

Unicode: what kind of binary compatibility do we want?
by Mathias Gaunard 03 Jun '09

03 Jun '09

As I am finishing putting property look-up together for the Unicode library GSoC, I am wondering what kind of binary compatibility it should aim for. The work from Graham Barnett back in 2005 defined an abstract base class with virtual functions for every unicode-related feature but I believe that's overkill. Basically, the current property design I have is like this struct some_property { enum type { some_default, some_value1, some_value2, ... _count; } }; some_property::type get_some_property(char32 ch); With get_some_property a simple look-up in the table, but the table layout being version dependent it would need to be in the library TUs. However, a new version of the library may return a value that is not within the enum. Should it then work like this? some_property::type get_some_property(char32 ch) { some_property::type p = get_some_property_impl(ch); if(p >= some_property::_count) return some_property::some_default; return p; } some_property::type get_some_property_impl(char32 ch); Is that suitable? Or do we want more/less flexibility? Apart from that, expect a documentation update by the end of the week.

5 7

[parameter] Bug 3114
by Jeremiah Willcock 03 Jun '09

03 Jun '09

I submitted bug 3114 (https://svn.boost.org/trac/boost/ticket/3114) with a preliminary patch to implement my feature request several days ago, and have not yet received a response. I believe that this feature would make Boost.Parameter much more useful for certain use cases, especially in libraries such as Boost.Graph where the defaults for named parameters may use templates that cannot be instantiated or do not include required members in some cases when users specify explicit arguments to a function. I made sure not to change the interface for existing default handlers by requiring a special tag to enable the new interface on a handler-by-handler basis. Could I please have the patch examined, generalized to more platforms, and possibly applied? Thank you. -- Jeremiah Willcock

2 1

[Bug Sprint][smart_ptr] #398
by Steven Watanabe 02 Jun '09

02 Jun '09

AMDG It looks like https://svn.boost.org/trac/boost/ticket/398 can just be closed? In Christ, Steven Watanabe

1 0

boost.timer library submission...
by JohnQ 02 Jun '09

02 Jun '09

While using Boost for a recent project, I needed a timer class that would allow me to set a time in the future at which some data would be handed back to me via callback. It had to be thread-safe, boost friendly, and allow for deletion of timers after they were set but before they expired. I took a look at the Timer library that Beman had submitted but that didn't appear to satisfy my needs, so I wrote one. I think this type of library is a fairly common request... while looking for one I saw a number of people also looking for the same thing... so I'm hoping this fills a gap. In addition, I'm hoping that peer review will help increase the robustness of this library to the benefit of all. Where do I begin for submitting it? Thanks, John Q.

5 4

Bug Sprint Report for Monday, June 1st
by Marshall Clow 02 Jun '09

02 Jun '09

The boost bug sprint started Friday, May 29th, and runs through Sunday June 7th. Monday was a good day - lets keep it up! Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. 6:00 AM PDT 5/31: 761 open tickets. 6:00 AM PDT 6/2: 747 open tickets. Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed 5/30: 2 new tickets, 42 modifications, 17 tickets closed 5/31: 2 new tickets, 27 modifications, 8 tickets closed 6/1: 2 new tickets, 42 modifications, 17 tickets closed [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones. Also, tickets can be closed and reopened. ] What can you do? See <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> for details. I've added four new reports to the trac: Open ticket count by owner: <https://svn.boost.org/trac/boost/report/18> Open ticket count by component: <https://svn.boost.org/trac/boost/report/19> Open ticket count by ticket type: <https://svn.boost.org/trac/boost/report/20> Open ticket count by milestone: <https://svn.boost.org/trac/boost/report/21> There's been a lot of discussion on the list about tickets; and there are about a dozen patches that have been tested and are ready to be applied. If you're looking to help, you can look at some of the older bugs, say, the ones for Boost 1.36, and determine if they still apply. If they do, note that in the ticket. --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

[Bug Sprint] [fusion] tickets needing maintainer / OP attention
by Stjepan Rajko 02 Jun '09

02 Jun '09

The following fusion tickets are ready for maintainer action or feedback from the OP: #1404 - Unordered Fusion Map constructors * could use feedback from the OP (Dean Michael Berris) #1529 - Missing include statement * patch ready #1601 - distane of boost::tuple * patch ready, see comments #1614 - vector workaround needed for MSVC9 * could use feedback / test case from OP (François Barel) Stjepan

2 1

[task] - boost.task (replacement for boost.threadpool)
by k-oli＠gmx.de 01 Jun '09

01 Jun '09

Hi, boost vault (section 'Concurrent Programming' - http://www.boostpro.com/vault/) contains boost.task. It replaces boost.threadpool and provides a framework for parallel execution of tasks (launching task in the current thread, in a new thread, as sub-task or in a pool of threads). The code looks someting like this: std::string echo( std::string const& msg) { return msg; } void main() { boost::task::handle< std::string > h( boost::task::async( boost::task::new_thread(), boost::task::make_task( echo, "Hello World!") ) ); std::cout << h.get() << std::endl; } or long fibonacci_fn( long n) { if ( n == 0) return 0; if ( n == 1) return 1; long k1( 1), k2( 0); for ( int i( 2); i <= n; ++i) { long tmp( k1); k1 = k1 + k2; k2 = tmp; } return k1; } void main() { std::cout << "worker-threads running in default-pool == "; std::cout << boost::task::default_pool().size() << "\n"; boost::task::handle< long > h1( boost::task::async( boost::task::default_pool(), boost::task::make_task( fibonacci_fn, 10) ) ); boost::task::handle< long > h2( boost::task::async( boost::task::default_pool(), boost::task::make_task( fibonacci_fn, 5) ) ); std::cout << "fibonacci(10) == " << h1.get() << "\n"; std::cout << "fibonacci(5) == " << h2.get() << std::endl; } best regards, Oliver

2 3

[Bug Sprint] - Ticket #816 - duplicat initial members -> erase_key postcond. fail
by Larry Evans 01 Jun '09

01 Jun '09

This ticket now has a simple solution: https://svn.boost.org/trac/boost/ticket/816#comment:4 Since it just changes the docs, it won't break any code and will help avoid any complaints about the documentation when some user inadvertently includes duplicates in the args to set. Could this doc change be applied and the ticket closed? -Larry

1 0

float_mem_cast
by Steven Ross 01 Jun '09

01 Jun '09

There is one function necessary for users to be able to cast their own float types. Should it be in spreadsort.hpp or some separate header file? It seems silly to have a separate header file for it, but I guess it might be used on its own. //Casts a float to the specified integer type template<class Data_type, class Cast_type> inline Cast_type float_mem_cast(const Data_type & data) { //Only cast IEEE floating-point numbers, and only to a same-sized integer BOOST_STATIC_ASSERT(sizeof(Cast_type) == sizeof(Data_type)); BOOST_STATIC_ASSERT(std::numeric_limits<Data_type>::is_iec559); BOOST_STATIC_ASSERT(std::numeric_limits<Cast_type>::is_integer); Cast_type result; std::memcpy(&result, &data, sizeof(Cast_type)); return result; }

4 7

Second call: The Boost Bug Sprint is coming!!
by Marshall Clow 01 Jun '09

01 Jun '09

The boost bug sprint is coming! It starts _this_ Friday, May 28th, and runs through Sunday June 7th. The goal is to address a large number of open bugs/patches/feature requests in the Trac system at <http://svn.boost.org/trac/report/1>. There are currently 791 open tickets; we'd like to knock that number down _a lot_. What can you do? 1) You can fix bugs. * If you are a library maintainer, you can commit your fixes. ;-) * If you are not a library maintainer, you can fix a problem on your local machine (and test it!!), and then attach your fix as a patch to the Trac ticket for the library maintainer to commit. If you do this, please provide a test case that exercises the problem; i.e, one that fails w/o your patch, and succeeds afterwards. 2) You can characterize bugs. * You can attempt to replicate the bug on your system(s), and attach information that you discover to the Trac ticket. This will make it easier for other people to solve the problem, even if you cannot. * You can write test cases demonstrating the problem, and attach them to the Trac ticket. * You can determine if the bug still exists; sometimes they get fixed, and the ticket never gets closed. In this case, try to identify a checkin that addresses the bug; it's always suspicious when bugs go away "by accident." 3) You can test patches. * Some of the tickets in the Trac system contain patches - some are quite old. You can install these patches on your system, and determine if they (a) build, and (b) work. * You can write test cases for the patches, and attach them to the ticket. 4) You can help implement new features. * There are a whole set of "feature requests" in the Trac system. If you have an idea about one of these, you can add comments to the Trac system. You can attempt to implement these new features, and attach the patch to the ticket. (Don't forget the test cases!!). Every day during the bug sprint, I'll post the # of tickets modified/closed/opened on the previous day, as well as the total number of open tickets. --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

14 34

Bug Sprint Report for Sunday, May 31st
by Marshall Clow 01 Jun '09

01 Jun '09

The boost bug sprint started Friday, May 29th, and runs through Sunday June 7th. Well, we've slowed down some, but we're still making progress. Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. 6:00 AM PDT 5/31: 761 open tickets. Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed 5/30: 2 new tickets, 42 modifications, 17 tickets closed 5/31: 2 new tickets, 27 modifications, 8 tickets closed [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones. Also, tickets can be closed and reopened. ] What can you do? See <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> for details. I've added four new reports to the trac: Open ticket count by owner: <https://svn.boost.org/trac/boost/report/18> Open ticket count by component: <https://svn.boost.org/trac/boost/report/19> Open ticket count by ticket type: <https://svn.boost.org/trac/boost/report/20> Open ticket count by milestone: <https://svn.boost.org/trac/boost/report/21> There's been a lot of discussion on the list about tickets; and there are about a dozen patches that have been tested and are ready to be applied. If you're looking to help, you can look at some of the older bugs, say, the ones for Boost 1.36, and determine if they still apply. If they do, note that in the ticket. --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

Boost.Process article: Tutorial and request for comments
by Boris Schaeling 01 Jun '09

01 Jun '09

I've written an article about Boost.Process: http://www.highscore.de/cpp/process/ I've also fixed a few bugs in Boost.Process (which is now 0.31): http://www.highscore.de/boost/process.zip And the latest source code can also be found in the sandbox: https://svn.boost.org/svn/boost/sandbox/process/ For developers not familar with Boost.Process the article is a tutorial to get more easily started. For developers familiar with Boost.Process it is a request for comments. I've been looking at the big picture finally trying to find out where and how Boost.Process should be changed and in which direction it should move to become a complete library one day. As not everyone will read the entire article here are my thoughts: 1) Boost.Process is based on a few concepts like 'process' and 'context'. While those make sense there are other concepts where I wonder if they should be dropped: * 'executable' is the executable name which in practice must be a std::string. I think the original idea was to support numerous string types. This leads to the question how to support different Unicode encodings which I think is still unanswered in the Boost community. Other libraries, eg. Boost.Interprocess, simply stick to one string type (typically std::string). * 'handle' is the underlying native file handle of a stream (file descriptor on POSIX systems, handle on Windows). The concept is based on a class in the detail namespace of Boost.Process. There is just one class and it's not meant to be used by users of the library either. Thus I'm not sure what's the benefit of having an explicit 'handle' concept at all. 2) Environment variables must be sorted on Windows but not on POSIX systems. On Windows the type environment could be a typedef for std::map and on POSIX systems for std::unordered_map. Currently it's always a typedef for std::map. Is that ok? Should it be changed? Should a macro be provided in case developers want to use different typedefs? 3) Currently Boost.Process is really only useful for creating child processes. It's not possible for example to detect and iterate over other processes on a system. I guess Boost.Process should be enhanced here. Then one day the well-known utility 'ps' on POSIX systems could be implemented in Boost C++. Any comments? 4) When a process is created the standard streams (stdin, stdout and stderr) are closed by default. Is this a good choice? If it isn't what should happen otherwise? Inherting standard streams (which is the default behavior with fork on POSIX systems)? 5) Boost.Process requires to specify an absolute path to an executable which should be started. There is a helper function which returns the absolute path for an executable name (it uses the environment variable PATH). The question is if this should be done automatically if no absolute path is given? 6) When a stream of a child process is captured Boost.Process automatically creates a pipe. As pipes don't support asynchronous operations on Windows a named pipe is required (called FIFO on POSIX systems). Currently a macro must be defined to make Boost.Process use a named pipe on Windows. It might make more sense to enable developers to choose either a pipe or a FIFO explicitly - not only on Windows but on all platforms. Any comments? 7) It's possible to capture and access streams of a child process. Those streams are derived from std::istream and std::ostream and thus only support blocking I/O operations. Currently the underlying handle has to be fetched to initialize a generic I/O object from Boost.Asio to use asynchronous I/O operations. How should the library be changed to make it easier to use asynchronous I/O? 8) There is a method wait() which makes it possible to wait for another process to exit. Currently wait() is provided by the class child though. Shouldn't it really be defined by the class process (so you can wait not only for child processes to exit)? 9) As wait() blocks an asynchronous alternative should be provided. 10) The Windows-specific classes all start with win32_ (eg. win32_child). Wouldn't it make more sense to use windows_ instead (like windows_child) or a windows namespace? First other libraries use windows_ (see Boost.Interprocess). Second there should be no reason why a class like win32_child can't be used on a 64-bit Windows. Boris

4 10

Interest check: container with preallocated buffer
by Dmitry Vinogradov 01 Jun '09

01 Jun '09

Boost.Array offers constant size container with preallocated buffer, Boost.Optional provides from zero to one element. There are no STL container with preallocated buffer and it seems custom allocator does not help to do this with existing containers. Does any container exist to offer functionality like Boost.Array but allowing to store from 0 to N elements? Is there any interest in such container? PS. It's similar to fixed_string but as a generic container. -- Dmitry

9 23

[Bug Sprint] Ticket #315 (new Feature Requests) - Implement operator[] for Tokenizer
by Joel Falcou 01 Jun '09

01 Jun '09

https://svn.boost.org/trac/boost/ticket/315 Is there any objection in term of concept to give tokenizer this kin dof random access operator ? If no one is against that, I'll attach patch and test. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

2 3

[thread] #2739 shouldn't at_thread_exit work on the main thread?
by vicente.botet 01 Jun '09

01 Jun '09

Hi, Anthony, I have submitted a patch that makes a regression on the test test_tss. My patch was related to add a atexit call for the main thread when make_external_thread_data is called, but it adds also for the thread created with native threads. So the patch don't work. Is there a way to make a difference between the main thread and the others? BTW the test fails on cygwin gcc 3.6.4, could someone test it on Windows or Linux to see if this is specific to cygwin? Thanks, _____________________ Vicente Juan Botet Escribá

3 9

[Bug Sprint] Ticket #2867 - Adding a get_expected_args member to format
by Joel Falcou 01 Jun '09

01 Jun '09

https://svn.boost.org/trac/boost/ticket/2867 This ticket has a working patch + test attached. Should be merged and closed. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

2 2

Tickets with patches & mpl::switch_
by Joel Falcou 01 Jun '09

01 Jun '09

Here is some ticket that already contains a valid patch and test * mpl::zip doesn't support metafunction use https://svn.boost.org/trac/boost/ticket/1992 * Various unused args warning removal in ASIO : https://svn.boost.org/trac/boost/ticket/1341 * Various gcc warning in numeric https://svn.boost.org/trac/boost/ticket/1338 Other things. I've submitted some MPL::switch_ correction and addition here: https://svn.boost.org/trac/boost/ticket/2249 Now I'm not sure if the fix is what switch was really about after second thoughts. So can soemoen confirm I didn't modified the intended semantic. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

1 0

[config] Deprecate/remove BOOST_NO_INITIALIZER_LISTS
by Daniel James 01 Jun '09

01 Jun '09

Hi, Once BOOST_NO_0X_HDR_INITIALIZER_LIST has been added to release, I think we should remove BOOST_NO_INITIALIZER_LISTS. It's confusing having both macros. BOOST_NO_INITIALIZER_LISTS is probably useless as it only indicates compiler support and initializer lists can't really be used without the header. I seem to be the only person who uses it, so it might be okay to just remove it immediately or if not, deprecate it and remove it in the next release. Does that sound okay? Daniel

3 5

Bug Sprint Report for Saturday, May 30th
by Marshall Clow 31 May '09

31 May '09

The boost bug sprint started Friday, May 29th, and runs through Sunday June 7th. We're off to a great start! Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. 7:15 AM PDT 5/31: 763 open tickets. Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed 5/30: 2 new tickets, 42 modifications, 17 tickets closed [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones. Also, tickets can be closed and reopened. ] What can you do? See <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> for details. I've added four new reports to the trac: Open ticket count by owner: <https://svn.boost.org/trac/boost/report/18> Open ticket count by component: <https://svn.boost.org/trac/boost/report/19> Open ticket count by ticket type: <https://svn.boost.org/trac/boost/report/20> Open ticket count by milestone: <https://svn.boost.org/trac/boost/report/21> --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

[Bug Sprint] Ticket #613 - boost/crc.hpp uses non-standard conforming syntax
by Joel Falcou 31 May '09

31 May '09

https://svn.boost.org/trac/boost/ticket/613 The bugs seems indeed to have disappeared on gcc 4+. Should we close this one ? -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

2 2

Re: [boost] [Modularization] A new approach to header modularization
by JOAQUIN M. LOPEZ MUÑOZ 31 May '09

31 May '09

________________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de Beman Dawes [bdawes(a)acm.org] Enviado el: jueves, 28 de mayo de 2009 23:06 Para: boost(a)lists.boost.org Asunto: Re: [boost] [Modularization] A new approach to header modularization > > On Thu, May 28, 2009 at 10:53 AM, troy d. straszheim > <troy(a)resophonic.com> wrote: > > In no particular order: > > > > - There is still the toplevel filesystem.hpp and friends to deal with. > > The way to deal with that is to migrate those to within the library's > header directory. > > As boost grows, filling the boost/ with headers becomes less and less > attractive. I don't see why this is less attractive than having boost/ filled with folders. > Of course we have to leave the current headers there for > compatibiltiy, but that location could be deprecated and eventually > only <boost/filesystem/filesystem.hpp> supported. *This* is less attractive to me; I think a Boost lib is entitled to have at least one top level header; many use it to include all or the the most usual components. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

[Bug Sprint] - Ticket #2599 - corner case in boost::fusion::all
by Joel Falcou 31 May '09

31 May '09

https://svn.boost.org/trac/boost/ticket/2599 This ticket contains a working patch and should be merged/closed. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

2 1

Patches on tickets #3050 and #3051
by Marshall Clow 31 May '09

31 May '09

I tested these patches on darwin (gcc 4.0.1). They didn't break anything; which is not really surprising, since they are merely ifdef-ing out code on some systems - but not on darwin. If anyone builds with BOOST_NO_IOSTREAM and/or BOOST_NO_TYPEID, I would appreciate it if you could test out these patches. Thanks in advance! -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

Can someone (using Windows) check ticket #316?
by Marshall Clow 31 May '09

31 May '09

It's hard to tell, but those look like Visual Studio warnings. If they no longer exist, that ticket should be closed. If they do still exist, they should be looked into. <https://svn.boost.org/trac/boost/ticket/316> Thanks! -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

2 4

Phoenix Reloaded
by Eric Niebler 31 May '09

31 May '09

I'm kick-starting the development effort to reimplement Phoenix on top of Proto. There's already been some discussion off-list among the interested parties, but there was general agreement to move the discussion here to do our work out in the open and possibly involve more people. To that end, I have ... ... created a Wiki page for coordinating our efforts: https://svn.boost.org/trac/boost/wiki/BoostPhoenix3 ... created a branch at branches/phoenix_v3. Anybody interested in helping out or just following along should do the following from BOOST_ROOT (trunk): cd boost svn co https://svn.boost.org/svn/boost/branches/phoenix_v3/boost/phoenix cd ../libs svn co https://svn.boost.org/svn/boost/branches/phoenix_v3/libs/phoenix There is nothing in boost/phoenix right now but stub headers, and libs/phoenix is simply copied from trunk/libs/spirit/phoenix. On the Wiki I put uploaded a miniphoenix.cpp file that demonstrates some ideas I have about what Phoenix-on-Proto might look like. Feedback is welcome. -- Eric Niebler BoostPro Computing http://www.boostpro.com

6 14

Re: [boost] [BCP] Script for global renaming Boost Namespace
by Artyom 30 May '09

30 May '09

Hello, > I > think there is interest for such a feature, especially if > you are willing to > maintain it on regular basis. If there is an interest in it and, it would be accepted I'd be glad to continue supporting it on regular basis. Probably it may be integreted with regeression test to ensure that Boost still works after renaming. > If we do expect all > possible users to have Python > installed, it may be nice to use python for this. But > how do you propose to > integrate with bcp? 1. First of all this script is "one time use" and it is targeted for mostly project maintainers/managers that need to solve name collision problems. So, if it is not a big price to install Python to run such script, especially that it is availible by default for most supported platforms, like Solaris, FreeBSD, Linux, with an exception of Windows where in can be easily installed. So I don't see a real problem in using Python for this purpose. In any case there are already some Perl scripts are used for code generation. (See Boost.Asio for example) 2. I don't see it as a part of BCP but rather the tool that can be used together, like: bcp --boost=/path/to/boost bind.hpp regex asio my_boost_dir boost_rename.py my_boost_dir mybst Because it can be actually applied on full Boost tree, if someone wants its full version. Artyom > -- > Bjørn Roald > > > On Saturday 30 May 2009 10:55:25 am Artyom wrote: > > Hello, > > > > Some updates: > > ------------- > > > > 1. Added copyright - Boost License. > > 2. Some more regression tests passed, some code > cleanup > > > > Questions: > > ---------- > > > > 1. How can I submit it as an addon to BCP utility? > > 2. Have anybody tested it, I'd like to see if there > any problems, > > especially on Windows platform -- I > hadn't tested it there. > > > > > > Thanks > > Artyom > > > > P.S.: The source is there http://art-blog.no-ip.info/files/rename.py > > > > --- On Mon, 5/25/09, Artyom <artyomtnk(a)yahoo.com> > wrote: > > > From: Artyom <artyomtnk(a)yahoo.com> > > > Subject: [BCP] Script for global renaming Boost > Namespace > > > To: boost(a)lists.boost.org > > > Date: Monday, May 25, 2009, 11:14 AM > > > Hello, > > > > > > Today Boost does not provide any backward binary > > > compatibility. This > > > makes big problems in shipping 3rd part libraries > that > > > depend on Boost > > > because library user must use the same version of > Boost as > > > that 3rd > > > part library was compiled with. > > > > > > The problem is become even more critical for ELF > platforms > > > (UNIXes) > > > where all symbols are exported by default. > > > > > > I had written a small Python script that switches > boost > > > namespace > > > to other, allowing 3rd part project include it > without > > > collisions > > > with primary Boost namespace. > > > > > > The script passes over the source tree of boost > and changes > > > each > > > include path from <boost/foo/bar.hpp> too > > > <newnamespace/foo/bar.hpp> > > > and renames all macros and identifiers from > > > some_BOOST_something to > > > some_NEWNAMESPACE_something and > some_boost_something to > > > some_newnamespace_something. > > > > > > It does not touch comments (copyright) and > strings unless > > > the string > > > is in form "boost/.*" which is usually some > reference for > > > include. > > > > > > I've run this script on the 1.39 version of boost > and > > > successfully build full boost release and run > some of > > > regression tests > > > like Boost.Asio, Boost.Regex, Boost.Function and > others, > > > > > > The source code is available at: > > > http://art-blog.no-ip.info/files/rename.py > > > > > > You run it as: > > > > > > ./rename /path/to/boost/source > > > new_namespace_name > > > > > > It renames all macros and namespaces to new > namespace, and > > > renames > > > main include directory to new_namespace_na,e. > > > > > > Few points: > > > > > > 1. It is only alpha version script, I just want > to see > > > feedback and > > > proposals > > > 2. I do not update build scripts. I assume that > each > > > library that > > > tryes to import its own version of > Boost > > > would provide its own > > > build system. > > > 3. The build scripts should be updated > differently because > > > they have > > > different syntax and grammar. The > > > required changes are to > > > fix different build defines > > > > > > Please, give feedback proposal. If there someone > who is > > > familiar > > > with Boost.Build systems can actually help, this > would be > > > very good. > > > > > > Today there is a big problem with working with > different > > > versions of > > > Boost. It should be solved. > > > > > > I think this script may be a valuable addition > to > > > Boost.BCP utility > > > that allows extracting a subset of boost for > integration in > > > 3rd part > > > tools and libraries. > > > > > > Thanks, > > > Artyom > > > > > > > > > > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

mingw help
by Vladimir Prus 30 May '09

30 May '09

We have two issues: https://svn.boost.org/trac/boost/ticket/1907 https://svn.boost.org/trac/boost/ticket/2181 that claim the the names of library files on mingw are wrong. Unfortunately, the picture is not exactly clear, and it's not even clear what the right naming would be. I'd appreciate if somebody who actually uses mingw could clarify these points: 1. Currently, we use the same naming on mingw as on windows -- foo.dll and foo.lib for shared libs and import libs, and libfoo.lib for static library. Is this OK? 2. Are the search rules listed in tools/build/v2/tools/gcc.jam around line 657 matching the reality? 3. Is naming in (1) compatible with using -Bstatic to request static libs? Thanks, Volodya

3 4

Re: [boost] [BCP] Script for global renaming Boost Namespace
by Artyom 30 May '09

30 May '09

Hello, Some updates: ------------- 1. Added copyright - Boost License. 2. Some more regression tests passed, some code cleanup Questions: ---------- 1. How can I submit it as an addon to BCP utility? 2. Have anybody tested it, I'd like to see if there any problems, especially on Windows platform -- I hadn't tested it there. Thanks Artyom P.S.: The source is there http://art-blog.no-ip.info/files/rename.py --- On Mon, 5/25/09, Artyom <artyomtnk(a)yahoo.com> wrote: > From: Artyom <artyomtnk(a)yahoo.com> > Subject: [BCP] Script for global renaming Boost Namespace > To: boost(a)lists.boost.org > Date: Monday, May 25, 2009, 11:14 AM > Hello, > > Today Boost does not provide any backward binary > compatibility. This > makes big problems in shipping 3rd part libraries that > depend on Boost > because library user must use the same version of Boost as > that 3rd > part library was compiled with. > > The problem is become even more critical for ELF platforms > (UNIXes) > where all symbols are exported by default. > > I had written a small Python script that switches boost > namespace > to other, allowing 3rd part project include it without > collisions > with primary Boost namespace. > > The script passes over the source tree of boost and changes > each > include path from <boost/foo/bar.hpp> too > <newnamespace/foo/bar.hpp> > and renames all macros and identifiers from > some_BOOST_something to > some_NEWNAMESPACE_something and some_boost_something to > some_newnamespace_something. > > It does not touch comments (copyright) and strings unless > the string > is in form "boost/.*" which is usually some reference for > include. > > I've run this script on the 1.39 version of boost and > successfully build full boost release and run some of > regression tests > like Boost.Asio, Boost.Regex, Boost.Function and others, > > The source code is available at: > http://art-blog.no-ip.info/files/rename.py > > You run it as: > > ./rename /path/to/boost/source > new_namespace_name > > It renames all macros and namespaces to new namespace, and > renames > main include directory to new_namespace_na,e. > > Few points: > > 1. It is only alpha version script, I just want to see > feedback and > proposals > 2. I do not update build scripts. I assume that each > library that > tryes to import its own version of Boost > would provide its own > build system. > 3. The build scripts should be updated differently because > they have > different syntax and grammar. The > required changes are to > fix different build defines > > Please, give feedback proposal. If there someone who is > familiar > with Boost.Build systems can actually help, this would be > very good. > > Today there is a big problem with working with different > versions of > Boost. It should be solved. > > I think this script may be a valuable addition to > Boost.BCP utility > that allows extracting a subset of boost for integration in > 3rd part > tools and libraries. > > Thanks, > Artyom > > > >

2 1

[Conversion] Looking for a review manager
by vicente.botet 30 May '09

30 May '09

Hi there, I'm looking for a review manager for the new Conversion library. Anyone around here who would like to volunteer? "Generic explicit conversion between unrelated types: generic convert to and assign to functions which can be specialized by the user to make explicit conversion between unrelated types + partial specialization for std::complex, std::pair, boost::optional, boost::rational, boost::interval and between boost::chrono::time point and boost::ptime and between boost::chrono::duration and boost::time duration" Waiting for that any comments on the library is welcome. You can retrieve it from https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Conv… Regards, _____________________ Vicente Juan Botet Escribá

1 0