- Boost - lists.boost.org

[utility] [C++0x] indices/make_indices
by Daniel Frey 22 Jul '08

22 Jul '08

While playing with GCC 4.3 and variadic templates, I came across the following problem: Say I have to write a function that takes a tuple as a parameter and needs to call another function with the expanded tuple. In code: template< typename... Ts > void f( const std::tuple< Ts... >& tp ) { g( tp... ); } OK, tp... doesn't work. Next try: template< typename... Ts > void f( const std::tuple< Ts... >& tp ) { g( std::get< Ns >( tp )... ); } That doesn't work either, but it's close, except that I only have Ts, not Ns (which need to expand from 0 to sizeof...( Ts ) - 1. Doug Gregor pointed me to N2080, which inspired me to create a light-weight general helper for cases where you need indices instead of types (or both). Here's the code that actually works: template< typename... Ts, std::size_t... Ns > void fimpl( const std::tuple< Ts... >& tp, const indices< Ns... >& ) { g( std::get< Ns >( tp )... ); } template< typename... Ts > void f( const std::tuple< Ts... >& tp ) { fimpl( tp, typename make_indices< sizeof...( Ts ) >::type() ); } with the following helpers: template< std::size_t... Ns > struct indices { }; template< std::size_t N, std::size_t... Ns > struct make_indices { typedef typename make_indices< N - 1, N - 1, Ns... >::type type; }; template< std::size_t... Ns > struct make_indices< 0, Ns... > { typedef indices< Ns... > type; }; While I appreciate any feedback/improvement/... on the specific problem/solution, there's also another issue here: These helpers are useful only for C++0x - I don't see how they could make any sense for the current C++ standard. There seem to be three options: a) Consider them an internal, undocumented implementation detail that other Boost libraries may use. No problem here, could be done today if there is interest. b) Make them part of the MPL. My gut feeling is that this is the wrong place - they don't belong to meta-programming because (as the example shows) they are useful in a variety of contexts. c) Make them a user-visible, documented feature of Boost. They are rather small so I'd compare them to next/prior: Not worth to be a full-fledged Boost library, but maybe part of Boost.Utilities. Thoughts? Regards, Daniel

5 15

Conflict between Boost.Integer and boost/detail/numeric_traits.hpp
by J. van der Wulp 21 Jul '08

21 Jul '08

Hello everyone, There seems to be a problem with using Boost.Integer in combination with anything that uses boost/detail/numeric_traits.hpp (development). The latter also defines a struct with name integer_traits that is not compatible with the one declared in Boost.Integer. The problem can be reproduced by including boost/graph/adjacency_list.hpp first and boost/integer.hpp as in: #include <boost/graph/adjacency_list.hpp> #include <boost/integer.hpp> int main() { return 0; } Swapping the include directives avoids the problem. Regards, Jeroen van der Wulp

2 3

Re: [boost] [Boost-users] [Boost.thread] Exception handling strategy ?
by vicente.botet 21 Jul '08

21 Jul '08

----- Original Message ----- From: "Anthony Williams" <anthony.ajw(a)gmail.com> To: <boost-users(a)lists.boost.org> Sent: Thursday, July 17, 2008 11:21 AM Subject: Re: [Boost-users] [Boost.thread] Exception handling strategy ? > > "Emil Dotchevski" <emil(a)revergestudios.com> writes: > >> Yes this should be easy, I'll do it after 1.36 ships. > > Excellent! If I understood, the MSVC-specific code allows the user to get the current exception without throwing the exception with boost::enable_current_exception(). What is the advantage if we can not profit of this mechanism with other compilers? A few months ago I proposed an intrusive way allowing the user to define which exceptions where wrapped by boost::exception_ptr. IMHO, the exception_ptr emulation (without language support) to transport exceptions between threads is not of real use if the user can not configurate the exceptions that can be thrown by 3pp as the Exception library do already for the STL exceptions. If the Exception library do not allow this, how can the Future library transport every exception between two threads? For recall, my proposal was the following: The exception library defines a macro such as: #define BOOST_EXCEPTION_CATCH_RETURN(EXCP) \ catch( EXCP & e ) { \ return exception_detail::current_exception_unknown_boost_exception(e); \ } The current_exception function has a USER_SLOT used us follows inline exception_ptr current_exception() { try { throw; } catch( exception_detail::cloning_base & e ) { exception_detail::clone_base const * c = e.clone(); BOOST_ASSERT(c!=0); return exception_ptr(c); } catch( std::invalid_argument & e ) { return exception_detail::current_exception_std_exception(e); } // ... as before #ifdef BOOST_EXCEPTION_USER_SLOT #include BOOST_EXCEPTION_USER_SLOT #endif catch( ... ) { return exception_detail::current_exception_unknown_exception(); } } The user can define BOOST_EXCEPTION_USER_SLOT to a file containing one line for each exception that must be transported: BOOST_EXCEPTION_CATCH_RETURN(3pp::exception1) BOOST_EXCEPTION_CATCH_RETURN(boost:lock_error) Of course this has a limitation: it works only if the function using the current_exception is also inlined. Best, Vicente

1 0

data_binding library for boost... Any interest?
by Tom Brinkman 21 Jul '08

21 Jul '08

Unfortunately, posting lots of code on here does not work well. Small snippits of a library work well, but just pasting the file into the message makes it difficult to read. You should just summarize your proposal and put a link to where the code can be found. Try to have a hello-world style example that gives a 5 minute introduction.

1 0

[lambda] Binding to abstract class methods
by Robert Jones 21 Jul '08

21 Jul '08

Is it possible to bind to pure virtual methods? Like this struct S { void methodOfS( ) = 0; }; void f( S & s ) { using namespace boost :: lambda; bind( & S :: methodOfS, _1 )( s ); } My compiler seems to be complaining that s is abstract, which is surely not a real limitation! Thanks, Rob.

2 2

passing ranges or output iterators to virtual functions
by Simon Richter 21 Jul '08

21 Jul '08

Hi, I've written two small class templates that basically "work for me" in the current state, but are not as generic as I'd like. The task at hand: pass a list of objects through a function call with fixed signature (such as a virtual function) without exposing the actual container type used. I'd like to get a bit of feedback on whether these might be a worthwhile addition to Boost (after some cleanup and implementation of features missing so far). I'll start with the simpler class: template<typename T> class output_iterator { class wrapper_base { public: virtual ~wrapper_base(void) throw() { } virtual void operator=(T const &) = 0; wrapper_base &operator*(void) { return *this; } wrapper_base &operator++(void) { return *this; } wrapper_base &operator++(int) { return *this; } }; template<typename O> class wrapper : public wrapper_base { public: wrapper(O o) : o(o) { } virtual void operator=(T const &v) { *o++ = v; } private: O o; }; public: template<typename O> output_iterator(O o) : o(new wrapper<O>(o)) { } output_iterator(output_iterator<T> const &o) : o(new wrapper<wrapper_base &>(*o.o)) { } output_iterator<T> &operator*(void) { return *this; } output_iterator<T> &operator++(void) { return *this; } output_iterator<T> &operator++(int) { return *this; } output_iterator<T> &operator=(T const &v) { *o = v; return *this; } private: std::auto_ptr<wrapper_base> o; }; Basically, that allows code like the following to work: class base { public: virtual ~base(void) throw() { } virtual output_iterator<int> get_some_ints(output_iterator<int>) = 0; }; class derived : public base { public: virtual ~derived(void) throw() { } virtual output_iterator<int> get_some_ints(output_iterator<int>); }; void derived::get_some_ints(output_iterator<int> o) { *o++ = 5; *o++ = 7; return o; } int main(int, char **) { std::list<int> l; derived d; base &b = d; b.get_some_ints(std::back_inserter(l)); // l now contains {5, 7} } The most obvious problem is that it fails for output iterators that do not advance on assignment, but that can be solved easily with a few more virtual functions in the wrapper. Something that is harder to do is that the return value from get_some_ints should be assignable to a type that is equal to int main(int, char **) { int some_ints[4]; int *next = some_ints; derived d; next = d.get_some_ints(next); } It does work if the returned output iterator is stored in an output_iterator<int>, and passing that to another function works as well. Extracting the int * would probably require RTTI. The third problem is that every time the output iterator is copied, memory is allocated, which is freed only when the last copy goes out of scope (there are some failure cases where memory is freed too early, but I think these are invalid uses of the output iterator). The second class attempts to do the same for range: template<typename T> void intrusive_ptr_add_ref(T *e, typename T::enumerator_tag = typename T::enumerator_tag()) { ++e->refcount; } template<typename T> void intrusive_ptr_release(T *e, typename T::enumerator_tag = typename T::enumerator_tag()) { if(!--e->refcount) delete e; } template<typename T> class range { class wrapper_base { public: virtual ~wrapper_base(void) throw() { } class enumerator { public: enumerator(void) throw() : refcount(0) { } virtual ~enumerator(void) throw() { } virtual T &operator*(void) const throw() = 0; virtual enumerator &operator++(void) throw() = 0; virtual bool operator!(void) const throw() = 0; private: unsigned int refcount; template<typename E> friend void intrusive_ptr_add_ref(E *, typename E::enumerator_tag); template<typename E> friend void intrusive_ptr_release(E *, typename E::enumerator_tag); struct enumerator_tag { }; }; virtual std::auto_ptr<enumerator> get(void) = 0; }; template<typename I> class wrapper : public wrapper_base { public: wrapper(I first, I last) : first(first), last(last) { } class enumerator : public wrapper_base::enumerator { public: enumerator(I current, I end) : current(current), end(end) { } virtual ~enumerator(void) throw() { } virtual T &operator*(void) const throw() { return *current; } virtual enumerator &operator++(void) throw() { ++current; return *this; } virtual bool operator!(void) const throw() { return current == end; } private: I current, end; }; virtual std::auto_ptr<typename wrapper_base::enumerator> get(void) { return std::auto_ptr<typename wrapper_base::enumerator>(new enumerator(first, last)); } private: I first, last; }; public: template<typename C> range(C const &container) : r(new wrapper<typename C::const_iterator>(container.begin(), container.end())) { } template<typename C> range(C &container) : r(new wrapper<typename C::iterator>(container.begin(), container.end())) { } template<typename F> F for_each(F f) { std::auto_ptr<typename wrapper_base::enumerator> e(r->get()); while(!!*e) { f(**e); ++*e; } return f; } class iterator : public std::iterator<std::input_iterator_tag, T> { public: iterator(void) : e() { } iterator(std::auto_ptr<typename wrapper_base::enumerator> e) : e(e.release()) { } T &operator*(void) const { return **e; } T *operator->(void) const { return &**e; } iterator &operator++(void) { ++*e; return *this; } bool operator==(iterator const &rhs) const { if(e.get() && !!*e) return rhs.e.get() && !!*rhs.e; return !rhs.e.get() || !*rhs.e; } bool operator!=(iterator const &rhs) const { return !operator==(rhs); } private: boost::intrusive_ptr<typename wrapper_base::enumerator> e; }; iterator begin(void) { return iterator(r->get()); } iterator end(void) { return iterator(); } private: wrapper_base *r; }; Again, this class is pretty much incomplete, but "works for me". The iterator can only implement the input iterator category as it is not possible to compare two non-singular iterators. More constructors could be added that accept other inputs than containers (I can also see the memory leak, although valgrind can't -- the pointer inside the range<T> class should probably be a shared_ptr or intrusive_ptr). Any comments on these so far? Is the general idea useful? Simon

4 4

[web-site] Bad link...
by Jurko Gospodnetić 21 Jul '08

21 Jul '08

Hi. When you click on the link 'Trunk Issues' (http://www.boost.org/development/tests/trunk/developer/issues.html) on the right side of the http://www.boost.org/development/running_regression_tests.html page. you get two frames with the left one just saying 'File not found'. I'm guessing this is some stale link... Best regards, Jurko Gospodnetić

2 1

Patch for Jamroot on the release branch.
by Jurko Gospodnetić 20 Jul '08

20 Jul '08

Hi Beman. Would it be ok to add an 'import generate ;' statement to the main Boost library Jamroot file (see the attached patch)? That is the module where the 'generate' rule used in that file is defined. Although not strictly necessary this does not change anything for the build but will avoid breaking the build once we remove some extra module imports in Boost Build. I already committed the same change to the trunk. Best regards, Jurko Gospodnetić Index: Jamroot =================================================================== --- Jamroot (revision 47611) +++ Jamroot (working copy) @@ -98,6 +98,7 @@ # - handle boost version # - handle python options such as pydebug +import generate ; import modules ; import set ; import stage ;

1 0

[Boost-users] [multi_array] Everyone, please make your value-types Assignable! (was: Re: more on assignability)
by Daryle Walker 20 Jul '08

20 Jul '08

On Jul 17, 2008, at 3:19 PM, Ronald Garcia wrote: > On Jul 11, 2008, at 6:17 AM, Dr Johann A. Briffa wrote: > >> I realize this topic has been discussed before (I've seen at least >> a thread in 2006 and another in 2007), but I believe there is more >> to add. At issue is the decision that multi_array objects cannot >> be assigned [with the operator=() that is] unless the target is >> already the same size as the source. Further, there is no >> documented way to easily resize an existing array to the same size >> and range as some other array. > > Indeed there is no built-in way to easily resize a multi_array to > be the same size as another multi_array. While there is no resize > member function that takes a pointer, there is one that takes a > model of the Collection concept (classes like boost::array and > std::vector are concepts). Based on this interface, here is a stop- > gap non-invasive solution that can resize a multi_array based on > another model of MultiArray (multi_array, multi_array_ref, etc.): [TRUNCATE] Let's define some stuff here: T: some type you created, probably a class type a: an object of type T; it's valid, i.e. meets its invariants b: another object of type T, also valid; any similarities or differences in its state from a's state is unspecified C: the set of all valid states an object of type T may have Let function F: x -> Y, map a T object state x to a (sub)set of C named Y. This function returns the subset of source states that a given state can receive during an assignment. If there exists at least one x in C such that F(x) = Y < C, then type T is _NOT_ Assignable! In other words, the number of assignment- compatibility classes in T must be exactly one for T to be Assignable. Furthermore, an Assignable type requires that the destination object's observable state post-assignment matches the observable state of the source object. The destination's new state can't be the old state quasi-merged with the source's state. (The destination object's old state must appear to be splattered, but remnants could be cached to the new state.) Fortunately, most types are Assignable. What happens if your type isn't? 1. Users can't use objects of that type in standard containers, which assume to be able to freely copy objects as much as they want. 2. Such objects are a pain to work with. Any containing class must write custom assignment operators to add calls to your custom copying routine. Of course, they have to first check if the source and destination objects are in the same assignment-compatibility class, and reconfigure at least one of those two objects if they're not in the same class. The exception would be if the wrapping class always makes sure that every T object it creates is of the same class. Even that is a pain because the user has to manually confirm that invariant every time s/he changes or adds a mutating function. 3. It isn't safe. You are effectively dumping the responsibility of assignment onto your users, who won't have all the information. The user generally has to test compatibility, reconfigure at least one object, then do call the custom copying routine. These steps are distinct, so if one of the mutating steps throws, the user will probably lose his/her old state forever and have a default-valued object. Your assignment routine would have more information available, so it can structure the assignment with roll-back during throws. (This could be moderated with a swap routine that doesn't care about assignment-compatibility classes. You do have a custom swap, right? And it does work irrespective of class, right?!) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 9

[circular_buffer] release branch still not upated!
by Thorsten Ottosen 18 Jul '08

18 Jul '08

Hi Jan, The default constructor for circular_buffer is still not updated in the release branch, and it is the only reason that ptr_container is failing on the release branch: explicit circular_buffer(const allocator_type& alloc = allocator_type()) : m_size(0), m_alloc(alloc) { initialize(max_size()); } The one in trunk reads: explicit circular_buffer(const allocator_type& alloc = allocator_type()) : m_buff(0), m_end(0), m_first(0), m_last(0), m_size(0), m_alloc(alloc) {} Please update as soon as possible, or tell me to do it for you. Thanks -Thorsten

2 4