- Boost - lists.preview.boost.org

Universal user interface based only on C++ standard libraries
by Jonathan Enders 07 Jul '09

07 Jul '09

One feature I am always missing when programming in a non-interpreted language like C is the ability to interactively execute the program without writing an entire mechanism for that. This "interpreted when typed"-feature proves itself very useful in python for instance. Although it might be too hard if not impossible to make a "compiled and executed when typed"-feature for C it is possible to just give the user the ability to access a huge amount of the functionality of let's say an object. It's just a lot of work to make all the properties accessible and you might blemish the looks of your actually ui-independent class. A workaround can be applied to lessen the damage. It would consist of just a single function that the class has to implement. That function exports all the functionality (options) to a ui-system which takes care of the command handling and user interaction. This works to the point that it can actually completely replace the ui-design-process (well the ui-system still has to be initialized, 3 lines of code). The work to make the C++ standard library ui-accessible could be taken from the user in advance. As I don't know if any of that is of any relevance to the boost community I will leave it at that. It just seems like a big lack to me that the boost-libraries still have no means of user interaction. If there is any interest in the above I have a working sample which demonstrates what words can only poorly describe. Thanks

8 7

[config] polygon library long long, long double portability
by Simonson, Lucanus J 07 Jul '09

07 Jul '09

I use long long and long double in the configuration of my integer arithmetic traits. I'd like to guard those usages with boost macros to allow the code to compile on platforms that don't support long long and long double (replace with long and double respectively) but I can only find a BOOST_HAS_LONG_LONG macro (which is apparently not documented) and not a corresponding BOOST_HAS_LONG_DOUBLE. Is there some other macro I can use to detect BOOST_HAS_LONG_DOUBLE or a typedef I can use that is already set to long double if available and double otherwise? Thanks, Luke

9 31

[Config] Boost config, long long in xlc 10.1
by Ioannis Papadopoulos 07 Jul '09

07 Jul '09

Hi, 1. I see in config/compiler/vacpp.hpp that versions over 6 are not supported when BOOST_ASSERT_CONFIG is defined: #if (__IBMCPP_ > 600) # if defined(BOOST_ASSERT_CONFIG) # error "Unknown compiler version - please run the configure tests and report the results" # endif #endif Still Boost compiles fine with 10.1, so maybe the number should be changed to 1010, unless there is some other reason that I'm missing. 2. long long is supported through a flag, -qlonglong which also defines _LONG_LONG to be 1. As far as I understand this is not taken into account. Thanks!

2 2

[algorithm] - defect due to accidental ADL
by Neil Groves 07 Jul '09

07 Jul '09

Hello, I have been investigating an issue reported by a user of the RangeEx library proposal. The conclusion was that boost/algorithm/find.hpp suffers from accidental ADL. This was confirmed by protecting against accidental ADL in this file and the user confirming that this solved their problem. Would it be useful to the current maintainer if I went through the source code and fixed similar issues? I would be happy to provide the files for the maintainer to commit. Alternatively is it possible to have agreement and then write access to the repository to fix this problem? Thank you in anticipation, Neil Groves

2 1

[Boost-serialization] Missing file
by K. Noel Belcourt 07 Jul '09

07 Jul '09

Hi, It looks like trunk tests are failing with this error. error: Unable to find file or target named error: 'test_shared_ptr_multi_base.cpp' error: referred from project at error: '../libs/serialization/test' -- Noel

1 0

[pool] Doubling algorithm
by Martin Scheffler 07 Jul '09

07 Jul '09

I just stumbled across an old problem: The maximum size of new allocations cannot be limited in boost::pool. I have a pool that grows to hundreds of megabytes. The pool doubles its allocation size every time it runs out of free space. Because Windows wants to allocate consecutive free space, I get out of memory errors even when my program only uses ~500 mb of main memory. If I could limit the amount of memory to allocate this would not be a problem. This was already discussed here: http://lists.boost.org/Archives/boost/2008/10/143763.php Has anything happened since then? Is boost::pool currently maintained? Or are there alternative memory pool libraries I could use? Thank you! Martin Scheffler

2 1

Ticket Resolutions
by Beman Dawes 07 Jul '09

07 Jul '09

I'd like to add "notabug" as a ticket resolution choice. The use would be for tickets that complain about something that is in fact true, but is by design rather than being a bug. In the past, I've marked these as "invalid". But I dislike doing so because it sounds as if I'm saying there is something wrong with the ticket itself. Comments? --Beman

6 6

Boost.Build question
by Zachary Turner 07 Jul '09

07 Jul '09

I notice the cxxflags for passing command line options to the C++ compiler. However, I need to build the boost libraries themselves in such a way that I can pass command line options to the linker. Is this possible somehow? Thanks

2 1

[gil] gcc 4.4.0 namespace fix (second attempt)
by Philipp Schwaha 06 Jul '09

06 Jul '09

Hi! please excuse if this message is posted twice, but my first attempt seems to have gone missing ... 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()));

3 2

[gil] gcc 4.4 fix
by Christian Henning 06 Jul '09

06 Jul '09

Hi there, on 2009-06-25 Philipp Schwaha posted a fix for some namespace issues with gcc 4.4. I just got the latest trunk but the issues remain. Could someone please commit the fix? http://article.gmane.org/gmane.comp.lib.boost.devel/191191 Thanks, Christian

1 0

[iterator] zip_iterator equality comparison
by Jeremiah Willcock 05 Jul '09

05 Jul '09

It is standard in STL to have two ranges that are zipped together (such as in the two-input-sequence version of std::transform at http://www.sgi.com/tech/stl/transform.html) where the first range has begin and end iterators and other ranges have only begin iterators. However, boost::zip_iterator does not support this capability because it compares all iterators in the iterator tuple. Therefore, it is not possible to write std::transform on two sequences by using a zip_iterator to join the sequences. Allowing this by only comparing the first elements in the iterator tuples would simplify the code for zip_iterator, although it would no longer allow the zipping of zero sequences unless that was special-cased. Is this a reasonable feature to allow? I could probably put together a patch for it in the next few days if people wanted it. -- Jeremiah Willcock

1 0

Mark throw_exception as noreturn?
by Andrey Semashev 05 Jul '09

05 Jul '09

Hi, I was wondering why the throw_exception function is not marked as noreturn? This makes it troublesome to use it as a drop-in replacement for throw statements as it starts to flag compiler warnings about missing return statements in non-void functions. I suggest to mark the function as noreturn at least for compilers that support it. GCC has __attribute__((noreturn)), MSVC has __declspec(noreturn).

4 6

Library namespace guidelines
by Neil Groves 05 Jul '09

05 Jul '09

Boosters, I have read both the "Library Requirments and Guidelines" and specifically examined the "Boost Header Policy" and the section on naming consistency but have yet to understand how I should choose to use namespaces for the next version of Boost.Range, that incorporates the accepted Boost.RangeEx proposal. It feels indecent and naughty (in a bad way!) to be putting the library into the top-level boost namespace. More importantly I am concerned that general functions such as "find" will clash when combined with other boost libraries both now and in the future. Would the ideal scenario for new libraries be to have a library related namespace under boost in a manner akin to Boost.Filesystem? Is there already a strategy that is well-known that I am ignorant of? Is there an existing strategy to migrate libraries that pollute the top-level boost namespace that maximises backward compatibility? Any assistance with this matter would be greatly appreciated. Thank you in anticipation, Neil Groves

2 2

[proto] grammar compile error
by Felipe Magno de Almeida 05 Jul '09

05 Jul '09

Hello, When I have a grammar like this: struct create_table_grammar : boost::proto::shift_left < boost::proto::shift_left < boost::proto::terminal<tags::create> , boost::proto::terminal<tags::table> > , boost::proto::terminal<const char*> > {}; And this expression: create << table << "lala"; Where create and table are terminals with the respective tags. I have this compile error: examples/test1.cpp: In function ‘int main()’: examples/test1.cpp:12: error: no match for ‘operator<<’ in ‘sql::keywords::create << sql::keywords::table’ If I don't inner expressions, then (create << table) works. But I can't define a more restricted grammar this way. I want create << table to work only when preceded with another specific expression. I wanted create << table to be enabled, but to disable everything else except (create << table) << ""; Is this possible? Thanks, -- Felipe Magno de Almeida

3 7

is_base_of<int, int> behaviour.
by John Maddock 03 Jul '09

03 Jul '09

Folks, Some time ago we made is_base_of<int,int>::value true, for reasons that escape me, and the TR1 followed this. However, C++0X makes is_base_of<non_class, non_class>::value to be false, which seems all round more logical to me. While I'm sorting out what is_base_of<T, const T> does, it's a good time to fix this as well. Are there any objections to changing the behaviour of is_base_of to match C++0X? Cheers, John.

2 1

v2.0 of Identification library
by joel 03 Jul '09

03 Jul '09

I've uploaded an updated version of the identification library in the Vault some weeks ago and IIRC I forgot to mention it. From the doc : "Boost.Identification is a library which aims at providing a simple solution for building a textual representation of a type as a string that can be manipulated at run-time. Such a feature is often desirable when someone wants to dynamically debug large template class instantiation or use a easy to use `type string representation` to use in serialization process or exception display. Those tasks are often done using the typeid operator but its output is compiler dependant and often produce strings which are usually hard to decipher." Comments and remarks are most welcome. I'll also ask vicente to add it to the Library In Progress wiki page. Thanks in advance. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

6 8

boost::spirit -- semantic values
by Anand 03 Jul '09

03 Jul '09

I couldn't find a way to associate a semantic value with a non-terminal. Bison/yacc allows this. For example, here is a rule in Bison that says an expression can be the sum of two subexpressions: expr: expr '+' expr { $$ = $1 + $3; } ; The action says how to produce the semantic value of the sum expression from the values of the two subexpressions. Having semantic values for non-terminals is useful to build an expression tree. For, e.g, I can create a new node in the tree by passing in the semantic values of child nodes in the action. expr: expr '+' expr { $$ = makeNode($1, $3, "+"); } ; In this case the semantic value for each expression is of type Node*. Spirit provides parse trees and ASTs and also semantic actions that take the first last iterator pair. But is there some way I can associate a semantic value with each non-terminal and pass in these semantic values to the action for the rule. Thanks, Anand

2 1

Units of data
by Zachary Turner 03 Jul '09

03 Jul '09

Has anyone extended (even privately) Boost.Units to include support for units of data (bits, bytes, KB, MB, etc)? It seems like this would be a useful addition to Boost.Units. Assuming no, what is the minimum amount of work required to do this myself? There's not a lot of info in the docs on how to define new base units, although I've already begun looking over the source code to try to come up with something.

3 12

[BGL] on using visitor in dijkstra_shortest_path
by Sandeep Gupta 02 Jul '09

02 Jul '09

Hi, The example code for extending dijkstra via gives compilation errors. Attached below is the snippet code and the error messages using gcc-4.3.3 and boost_138_0. typedef boost::adjacency_list<vecS, vecS, bidirectionalS > graphImpl_t; //----taken for doc--- template <class PredecessorMap> class record_predecessors : public dijkstra_visitor<> { public: record_predecessors(PredecessorMap p) : m_predecessor(p) { } template <class Edge, class Graph> void edge_relaxed(Edge e, Graph& g) { // set the parent of the target(e) to source(e) put(m_predecessor, target(e, g), source(e, g)); } protected: PredecessorMap m_predecessor; }; template <class PredecessorMap> record_predecessors<PredecessorMap> //error: expected constructor, destructor, or type conversion before ‘<’ token make_predecessor_recorder(PredecessorMap p) { return record_predecessors<PredecessorMap>(p); } ///---end doc-------------- ..... ... vector<vertex_t> p(num_vertices(gg)); dijkstra_shortest_paths(gg, src, predecessor_map(preds).weight_map(weights).distance_map(dists).visitor(make_predecessor_recorder(&p[0]))); Thanks in advance. -sandeep

3 7

[ann] Urdl - a library for downloading web content
by Christopher Kohlhoff 02 Jul '09

02 Jul '09

Hi all, I have just released a new Boost.Asio-based library, Urdl, which can be used for accessing and downloading web content. <http://think-async.com/Urdl> <http://sourceforge.net/projects/urdl> It currently has limited support for the protocols "http", "https" and "file". It provides an easy-to-use extension to standard C++ iostreams and an asynchronous interface for use with Boost.Asio. In addition to (hopefully) being useful, it is intended as an example of using the Boost.Asio and Boost.System libraries. If you're writing protocol implementations using Asio, you might also be interested in how it uses coroutines to simplify the expression of asynchronous control flow. (Note: here coroutines refers to a macro-based system similar to <http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html>, not Giovanni Deretta's GSoC project). Cheers, Chris

11 20

Fixed point implicity
by Soren Holstebroe 02 Jul '09

02 Jul '09

Hi, I'm generalizing my fixed point class and have come across a few design decisions. 1. Return type of additive arithmetic operation between integers and fixed points Example: a 16 bit integer is added to a 16 bit fixed point with 8 bit fraction. I see three possible return types: 16 bit integer, 16:8 fixed point and promoted 32:8 fixed point If return type is 16 bit integer, the fraction is lost. Clearly not an option. If return type is 16:8 fixed point overflow is possible. A return type of 32:8 would eliminate overflow, but promotion quickly becomes problematic for larger integer types, lets say a 32 bit integer added to a fixed point. In that case we would need a 64 bit integer which could cripple performance on many systems. Another problem with promotion is that the arithmetic expression typically would be in a context where the expression is assigned to a fixed point of the type present in the expression. In that case we have an overflow problem again. I think I favor keeping the return type in 16:8. The user would then have to use an explicit cast to avoid overflow. 2. Return type of additive arithmetic operation between float and fixed points Example: fixed_point<int, 16>(10.5) + 5.5f (integer is representing type, 16 bit is the bit reserved for the fraction) What would you expect the return type to be? I think I favor returning a float. The accuracy of the fixed point is compromised anyway. 3. Return type of additive arithmetic operation between different fixed point types Example: fixed_point<int, 16>(10.5) + fixed_point<int, 8>(10.5) Like in case 1 there is the choice between losing precision, risking overflow or promoting (ex. to fixed_point<boost::int_t<16 + 8>::fast, 16>) I think I favor to simply disallow implicit arithmetic between different fixed point types. This would require the user to cast either type. The problem with that choice is less transparent use of the fixed_point type, since changing a type could break existing code where the previous type was in a valid arithmetic operation with another fixed point type. 4. Similar problems exist for multiplication and division If a fixed_point is multiplied with an integer there is a risk of overflow. If a fixed_point is multiplied with another fixed_point there is a risk of overflow and precision will be lost. If a fixed_point is divided by an integer there is a risk of loss of precision. If a fixed_point or integer is divided by another fixed_point there is a risk of overflow and loss of precision. Soren

5 8

Messages lost
by Chard 02 Jul '09

02 Jul '09

I made two posts to this group on 30 June, around 21:00 UTC. Both received acknowledgements, but neither have appeared. A post to the users group, made at about the same time, appeared there immediately. New messages later than my posting time are appearing, so it doesn't look like it's back-log. Are there any known problems? Apologies if this should be directed elsewhere, but at the moment there doesn't seem to be a route open to www.boost.org (to find out); certainly from my ISP...sigh. (Posting this one at 21:30 UTC)

2 2

[task] 0.2.1 Doesn't compile on VC7.1 / older gcc
by Chard 02 Jul '09

02 Jul '09

Hi Oli, As documented, you're testing MS compilation with VC9. We're currently tied to VC7.1 and as we use a threadpool heavily (Philipp Henkel's) I have a particular interest in seeing an 'official' boost threadpool. So forgive me if I keep these coming ;-) There is another VC7.1 compiler conformance issue: static_pool now has the contained pool_base class. The pool_base::submit method constructs a handle<>, however, this has the VC7.1 'friend access to contained class' problem. The handle<> (non-default) constructor is private, granting friend access to static_pool, however, static_pool<>::pool_base requires access, and VC7.1 barfs. I couldn't figure out the friend syntax (that works) to add to class handle<>, so for now I'm working with handle<> (hacked as) public. (Note: earlier versions of gcc, e.g. 3.4.4, will exhibit this problem, too.) I thought this would've been the syntax: # if BOOST_WORKAROUND(BOOST_MSVC, <= 1300) template <typename Channel> friend class static_pool<Channel>::pool_base; # endif but it doesn't appear to be legal. Is this type of declaration even possible? An alternative would be to move (some or all of) the functionality to the outer static_pool class, and route the inner pool_base class to it, e.g. template< typename R > handle< R > static_pool::pool_base::submit( boost::detail::thread_move_t< task< R > > t_) { static_pool::submit(*this, _t); } template< typename R > static handle< R> static_pool::submit(pool_base &pb_, boost::detail::thread_move_t< task< R > > t_) { ... } Or, perhaps just the handle creation line. However, it may be tidier just to have a detail::create_handle (that is the handle<> friend), seeing as you are just trying to say nobody else should be constructing a handle. Regards, and keep up the good work...

2 1

[task] 0.1 => 0.2.1 removes make_task
by Chard 02 Jul '09

02 Jul '09

Task version 0.1 => 0.2.1 comment. make_task appears to have been removed and the multiple argument mechanism migrated to the task constructor. AFAICT this has removed functionality because the make_task helper had the benefit of determining the return value of the task. The task class is templated on the return type, so the user if forced to declare it (okay, not a great deal, but then we have conveniences like make_pair). e.g. 0.1: task::async(threadpool, task::make_task(TaskFunc)); 0.2.1 (argument order exchanged in 0.2.1): task::async(move(task::task<void>(TaskFunc)), threadpool); I assume the reasoning behind this was the cut-over to using move semantics; if this is the case then the constructor: explicit task( Fn fn, BOOST_ENUM_TASK_MAKE_TASK_FUNC_ARGS(n)) \ : task_( new detail::task_wrapper< \ typename result_of< Fn( BOOST_PP_ENUM_PARAMS(n, A)) >::type, \ function< typename result_of< Fn( BOOST_PP_ENUM_PARAMS(n, A)) >::type() > \ >( bind( fn, BOOST_PP_ENUM_PARAMS(n, a)) ) ) \ {} may as well not use result_of; is this not just the template argument, R ? Could make_task have been preserved, but modified to return the move-type ?

2 1

boost::interprocess - lnk2005 error due to compiler/linker bug in msvc8
by willem hengeveld 01 Jul '09

01 Jul '09

when using boost::interprocess under win32, i ran into the following problem: in boost/interprocess/detail/win32_api.hpp several static inline functions have a function local class for releasing resources, like 'unlink_file', which defines 2 classes: handle_closer, and auto_ptr due to a compiler bug, as discussed here: http://www.eggheadcafe.com/conversation.aspx?messageid=32706692&threadid=32… you get a LNK2005 error <symbol> already defined in <object> when using boost::interprocess from multiple .cpp files a solution is to use boost::shared_ptr instead of local classes in win32_api.hpp, like this: boost::shared_ptr<void> hiPSAPI = boost::shared_ptr<void>(load_library("PSAPI.DLL"), free_library); attached is the complete patch willem

3 2