- Boost-users - lists.preview.boost.org

[units] extend system: temperature unit for cgs system
by alfC 18 Feb '11

18 Feb '11

Hi, in a recent project I am working in cgs units because the people involved is used to that system. I was surprised to find that the cgs unit system defined in boost.units doesn't have a temperature unit. Therefore this program compiles and gives a strange result: #include<boost/units/systems/cgs/io.hpp> #include<boost/units/physical_dimensions/temperature.hpp> #include<iostream> using namespace boost::units; int main(){ std::clog << quantity<unit<temperature_dimension, cgs::system> >::from_value(4.) << std::endl; return 0; } prints "4 dimensionless". The fact that there is no temeprature unit in cgs system may be by design, although I am pretty sure that if any "kelvin" is the unit of temperature in cgs. But independly of that I would like to have a cgs-system with kelvin as unit of temperature. How can I do that without having to create a whole new system of derived units almost equal to cgs and without modifying the boost sources? Is there a mechanism to extend (give a new dimension) to an existing system? Thank you, Alfredo

1 0

[GIL] gray pixel iterator in generic algorithm
by Curtis Gehman 17 Feb '11

17 Feb '11

I'm trying to use GIL pixel iterators in a generic STL-style algorithm. I'm primarily using GIL for the generic 2D iterators. And in my context, I'm only interested in grayscale images. The value_type associated with GIL iterators is a pixel type, which typically is an object representing multiple channels (e.g., colors). It makes sense that comparison operators (e.g., <) are not defined for general color pixel types. For grayscale images, however, it makes sense that common arithmetic and comparison operators would be defined for the pixel type. This seems to be the case for the 8-bit grayscale GIL type (gray8_view_t). The iterator's value_type appears to be seamlessly evaluated to an unsigned char, exactly as I would expect. When I try to use a float image view type, however, the same magic doesn't seem to happen. Below is some toy code that demonstrates the issue. When the last line is knocked out with "//", the code compiles. But with that second template instantiation (for floats) there, the compiler (gcc 4.2 and VC++2010) exits when it does not find an operator< for the iterator's value_type when instantiating for gray32fc_view_t. I suppose that I can roll my own less<iterator_traits<SrcView::x_iterator>::value_type> functors. But I just started using GIL, and I'm hoping that there is a simpler solution. Any ideas? #include <algorithm> #include <iterator> #include <vector> #include <boost/gil/gil_all.hpp> namespace g = boost::gil; using std::vector; using std::iterator_traits; template <typename SrcView> inline vector<typename iterator_traits<typename SrcView::x_iterator>::value_type> row_min(const SrcView& src) { typedef typename iterator_traits<typename SrcView::x_iterator>::value_type value_t; vector<value_t> result; for (int y = 0; y < src.height(); ++y) { result.push_back(*std::min_element(src.row_begin(y), src.row_end(y))); } return result; } // Explicit template instantiation // Works for gray8c_view_t. template vector<iterator_traits<g::gray8c_view_t::x_iterator>::value_type> row_min(const g::gray8c_view_t& src); // Compile error for gray32fc_view_t. // No operator< for iterator_traits<g::gray32fc_view_t::x_iterator>::value_type. template vector<iterator_traits<g::gray32fc_view_t::x_iterator>::value_type> row_min(const g::gray32fc_view_t& src);

3 7

[boost-users][graph] There is graph::null_vertex, but no "null_edge"!
by al.zatv 17 Feb '11

17 Feb '11

Hello! There is graph::null_vertex, but no "null_edge". Atl east, I don't find it. How can I return such a "special" edge descriptor, to mark,for example, that edge is not found or something like that?

2 5

[website] 1.45 docs link to version 1.29 on sourceforge
by John Reid 17 Feb '11

17 Feb '11

At http://www.boost.org/doc/libs/1_45_0/libs/libraries.htm the link "Documentation for some Boost libraries is available in other forms, including DocBook, XSL Formatting Objects, and Unix man pages. This documentation is available on Sourceforge." points to https://sourceforge.net/project/showfiles.php?group_id=7586&package_id=1597… which is for version 1.29.

2 1

[date_time] Memory leak in io example?
by Jim Bell 17 Feb '11

17 Feb '11

In the example code under Date Time Input/Output <http://www.boost.org/doc/libs/1_45_0/doc/html/date_time/date_time_io.html>, "A simple example of this new system:", it shows a date_facet being constructed with new, then a locale constructed with it, and finally ios::imbue called on that. >From what I can tell from locale's constructors <http://stdcxx.apache.org/doc/stdlibref/locale.html#idx811> and imbue, neither will own/release that pointer. True?

2 2

Offering a possible replacement for boost::Pool
by Lang Stefan 17 Feb '11

17 Feb '11

To whom it may concern... Two years ago I was looking for an implementation of a pool allocator, and found boost::pool. Unfortunately, the implementation was incomplete and hadn't been maintained for years, so I decided to write my own library, based on some of the ideas I found in the documentation for boost::pool. Now that I have a working library, I wondered if I should offer my results back to the community, but I am unsure how to go about that. What I currently have is an implementation that allocates, constructs, deconstructs, and deallocates class type objects from pool, and deallocates all unused blocks, all at constant time. The memory overhead is low, and there is some potential to reduce it even further, close to the original implementation of boost::pool. I am still missing some kind of 'garbage collection' (i. e. pack objects spread out over several blocks into one, so that I can release some unused blocks), and a decent method to allocate a whole array of m elements at O(m) (can't be less than that since I have to call constructors for each element). So this is still a work in progress. I've also started something resembling an article, that describes my goals, and how I came to make certain design decisions, down to the individual classes, structs, and their members. But I'm afraid in its current state it's not particularly helpful. How should I go about this - is there any place I can or should submit my stuff to, and what parts of it (naked lib, article, test program, VS project files)? Regards, Stefan

2 1

enable_shared_from_this2
by Peter Soetens 17 Feb '11

17 Feb '11

Hi list, I was in the need for a shared_from_this() in my constructor, so I chose this implementation for my class. Apart from the header being there and one mailing list thread, there's nothing that points to the existence of this header. Since we want to keep compatibility with Boost 1.38, I tried to backport the enable_shared_from_this2 class to that version. I was wondering why the weak_ptr::_empty() method was added to the weak_ptr API and why weak_ptr::expired() was not used instead ? I tried to emulate the same behavior by adding a 'bool' to the enable_shared_from_this2 class. Which works for my tests, but is there a pitfall to that solution ? Could I just replace this logic with weak_this_.expired() ? diff --git a/rtt/internal/enable_shared_from_this2.hpp b/rtt/internal/enable_shared_from_this2.hpp index a5bfcff..cb659f0 100644 --- a/rtt/internal/enable_shared_from_this2.hpp +++ b/rtt/internal/enable_shared_from_this2.hpp @@ -53,11 +53,13 @@ template< class T > class enable_shared_from_this2 { protected: - enable_shared_from_this2() + enable_shared_from_this2() : weak_init(false) { } - enable_shared_from_this2( enable_shared_from_this2 const & ) + // note: the copy constructor and operator= don't do anything, ie, they don't copy + // refcount status from the other object. + enable_shared_from_this2( enable_shared_from_this2 const & ) : weak_init(false) { } @@ -75,6 +77,7 @@ private: mutable weak_ptr<T> weak_this_; mutable shared_ptr<T> shared_this_; + mutable bool weak_init; // we deviate from the boost 1.40 implementation because weak_this_._empty() is not available in older versions. public: @@ -94,10 +97,11 @@ private: void init_weak_once() const { - if( weak_this_._empty() ) + if( !weak_init ) { shared_this_.reset( static_cast< T* >( 0 ), detail::esft2_deleter_wrapper() ); weak_this_ = shared_this_; + weak_init = true; } } @@ -111,6 +115,7 @@ public: // actually private, but avoids compiler template friendship issues if( weak_this_.use_count() == 0 ) { weak_this_ = shared_ptr<T>( *ppx, py ); + weak_init = true; } else if( shared_this_.use_count() != 0 ) { Thanks for any feedback, Peter

1 0

[range] Using container find
by Robert Jones 17 Feb '11

17 Feb '11

The boost range library provides a smart version of begin/end that resolves to different things depending on whether its argument is a pair or something with its own begin/end method. Does a similar thing exist anywhere for find? Ie., if a find exists, eg,. for maps, then use it, otherwise fall back to std::find()? Thx - Rob.

1 0

[Proto] Nested Types in Transforms
by Hossein Haeri 17 Feb '11

17 Feb '11

Dear all, In my namespace arity_caller, I have a struct CanBeCalled<> such that CanBeCalled<T, mpl::int_<n> >::type is an mpl::bool_<> representing whether T can be called with n doubles. I also have the following grammar (in a file called 'EmtnGram.hpp') in which I am trying to employ this CanBeCalled<>::type: struct EmtnShiftFObjGram: boost::proto::and_ < boost::proto::shift_right < EmtnTermOrGram, boost::proto::terminal<boost::proto::_> >, boost::proto::if_ < arity_caller::CanBeCalled < boost::proto::_value(boost::proto::_right), EmtnTermOrGram(boost::proto::_left) >::type > > {}; For an expression like x >> f, here, I am trying to make sure that f can be called with the right number of doubles -- that I have accumulated in x. When I compile this under GCC 4.5.1 (MinGW32, WinXP, SP3) and Boost 1.42, I get the following errors: In file included from main.cpp:5:0: EmtnGram.hpp:141:4: error: incomplete type 'arity_caller::CanBeCalled<boost::proto::_value(boost::proto::_child_c<1>), EmtnTermOrGram(boost::proto::_child_c<0>)>' used in nested name specifier EmtnGram.hpp:141:4: error: incomplete type 'arity_caller::CanBeCalled<boost::proto::_value(boost::proto::_child_c<1>), EmtnTermOrGram(boost::proto::_child_c<0>)>' used in nested name specifier EmtnGram.hpp:146:3: error: template argument 1 is invalid EmtnGram.hpp:147:2: error: template argument 2 is invalid Do I get it correctly that it's the ::type part of CanBeCalled<>::type that is confusing the compiler? Why is that happening? And, what's the cure? TIA, --Hossein

2 3

[thread] equivalent of WaitForSingleObject
by Sean Farrow 16 Feb '11

16 Feb '11

Hi: I've got some boost code that calls wait for single object on windows. I'd like to transition this to use boost.thread. What is the best way of doing this, in the while loop I'm doing: while( WaitForSingleObject( hDir, WAIT_TIMEOUT ) != WAIT_OBJECT_0 ) Any help appreciated. Cheers Sean.

2 1