- 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