- Boost - lists.boost.org

[serialization] Does this have any effect?
by David Abrahams 14 Dec '08

14 Dec '08

Hi All/Robert, I've been using the enclosed "untracked" wrapper around some things that I've been serializing... but I think I may have been barking up the wrong tree. Does it have any effect? In other words, I suspect that ar << untracked(anyexpression) is equivalent to ar << anyexpression Is that the case? Thanks in advance, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

[proto][design]why unary_expr,binary_expr; but no nullary_expr?
by Larry Evans 14 Dec '08

14 Dec '08

Although there's unary_expr<Tag,*>, binary_expr<tag.*,*> in traits.hpp there's no nullary_expr<Tag>. I realize this would be a replacement to the current terminal template but with a user specified tag. After all, if a user specified tag for n-ary (where n>0) expressions *is* desirable, why is a user specified tag for 0-ary expressions *not* desirable? On case where this would be useful is for algebraic morphisms where n-ary ops in a source algebra are mapped to n-ary ops in a target algebra. This *includes* 0-ary ops. An op would be the equivalent to proto tags. I think this could be done by another transform similar to the pass_through transform but allowing transformation of the tag. Currently pass_through just uses the source tag in the target expression. It seems like it should be pretty easy to allow transformation on the tag also.

2 3

BoostCon 2009: Call for Participation
by Hartmut Kaiser 13 Dec '08

13 Dec '08

Hi all, before we all relax into the holidays I wanted to remind you all about next year's Boost Conference in Aspen, CO, USA, May 3-9. Even if all important dates are listed in the attached Call for Participation, I'll list them here once again: Proposals for submissions due: January 10th 2009. Proposals acceptances sent (tentative program available): February 10th, 2009 Fully scheduled program available: March 1st, 2009 Session materials due: April 1st 2009. IOW, you might want to use some of your free time during the next weeks to think about a possible contribution. It really doesn't take much time to come up with a short abstract! Let's make sure BoostCon 2009 will be a major C++ event! Happy holidays! Regards Hartmut Program Committee Chair BoostCon 2009

1 0

[thread] reset a thread_specific_ptr by this pointer
by Pengcheng Song 12 Dec '08

12 Dec '08

Hi All, I was experimenting with the boost.threads library and especially boost::thread_specific_ptr. However, I ran into problems trying to reset the thread_specific_ptr by the this pointer (see the code below). // ========= beginning of code ============= #include <iostream> #include <boost/thread/thread.hpp> #include <boost/thread/mutex.hpp> #include <boost/thread/tss.hpp> boost::mutex mutex_; class A { private: double x_; static boost::thread_specific_ptr ptr_; public: A(double x=0) : x_(x) {} void operator()() { if (0==ptr_.get()) { ptr_.reset(this); } boost::mutex::scoped_lock lock(mutex_); std::cout << "x_=" << x_ << std::endl; } }; boost::thread_specific_ptr A::ptr_; int main() { boost::thread thrd1( A(1) ); boost::thread thrd2( A(2) ); thrd1.join(); thrd2.join(); return 0; } // ======= end of code ========= This compiled fine with boost_1_36 (binary from boostPro) under VC9 with multithreaded debug DLL code generation. But when I ran it under the debug mode, I got the following error message: Debug Assertion Failed. Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse) I searched the web and this seemed to be a memory problem. And I noticed that it failed to call the destructor of thread_specific_ptr. Is my code legal? Or one is not supposed to reset a thread_specific_ptr to this pointer? Your feedback would be greatly appreciated. Pengcheng Song -- View this message in context: http://www.nabble.com/-thread--reset-a-thread_specific_ptr-by-this-pointer-… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[iterators] how about an identity_iterator or generate_iterator?
by Dean Michael Berris 12 Dec '08

12 Dec '08

Hi, Has anybody found a need for an "identity_iterator"? Something that you can initialize to a value and returns that value every time it's referenced? It could model a random access iterator, and a default constructed version will mark an "end" of the identity_iterator. Something to the effect of: template <class Type> struct identity_iterator { identity_iterator(size_t count = 0) : v_(), count_(count) {} identity_iterator(const identity_iterator & o) : v_(o.v_), count_(o.count_) {} Type operator*() { return v_; } identity_iterator & operator++() { ++count_; *this; } identity_iterator & operator++(int) { ++count_; *this; } bool operator==(identity_iterator const & rhs) { return (this->count_ == rhs.count_); } bool operator<(identity_iterator const & rhs) { return (this->count_ < rhs.count_); } // ... and other required iterator nested types private: Type v_; size_t count_; }; Or even a "generate_iterator" which takes a nullary function object of signature "tuple<bool, T>()" where bool indicates whether it's at the end? It can be modeled as an input iterator. Something like: template <class T> struct generate_iterator { generate_iterator() : f_(), at_end(true) { } generate_iterator(function<tuple<bool, T>() > f) : f_(f), at_end(false) { } // copy constructor, swap, assignment, etc. T operator* () { T return_; tie(at_end, return_) = f_(); return return_; } // other required nested types private: function<tuple<bool, T>()> f_; bool at_end; }; Or is there already something out there which allows these iterator semantics? -- Dean Michael C. Berris Software Engineer, Friendster, Inc.

3 3

Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today
by Kim Barrett 12 Dec '08

12 Dec '08

At 2:23 PM +0100 12/6/08, Robert Kawulak wrote: >... maybe the problem >could be somehow solved if we have a function float exact(float) that, given a >floating point value (that may have greater precision because of caching in a >register), returns a value that is truncated (has exactly the precision of >float, not greater). I think that something along the lines of the following will likely work: inline double exact(double x) { struct { volatile double x; } xx = { x }; return xx.x; } The idea is to force the value to make a round trip through a memory location of the "correct" size. The use of volatile should prevent the compiler from optimizing away the trip through memory. If worried about whether a compiler will really do what's needed here, then I think the only other option is inline assembler to produce the equivalent behavior. Looking through the x86 instruction set, I don't see any other way to cause the desired rounding.

10 26

[Graph] random_access_iterator_property_map
by remi.chateauneu＠gmx.de 11 Dec '08

11 Dec '08

Hi, I try to use random_access_iterator_property_map following the example here: http://www.boost.org/doc/libs/1_37_0/libs/graph/doc/using_property_maps.html I have exactly the same problem mentioned here, on 2003-01-04 : http://www.mail-archive.com/boost@lists.boost.org/msg02627.html The interesting thing is that the documentation is still not updated, and there are still occurences of this class: /usr/include/boost/graph/detail/self_avoiding_walk.hpp: SAW_visitor< random_access_iterator_property_map<Tri*,Tri,Tri&>, /usr/include/boost/graph/detail/self_avoiding_walk.hpp: HList, random_access_iterator_property_map<Iter*,Iter,Iter&> > /usr/include/boost/graph/detail/self_avoiding_walk.hpp: typedef random_access_iterator_property_map<Tri*,Tri,Tri&> TriD; /usr/include/boost/graph/detail/self_avoiding_walk.hpp: typedef random_access_iterator_property_map<Iter*,Iter,Iter&> IterD; Is it a mistake from me, or ? Thanks

1 0

[ref] provide unref( T& )?
by Thorsten Ottosen 11 Dec '08

11 Dec '08

Hi, To be able to call a function object wrapped in boost::reference_wrapper<T>, we need something like the following: template< class T > inline typename boost::unwrap_reference<T>::type& unref( T& value ) { return static_cast<typename boost::unwrap_reference<Fun>::type&>(value); } which can then be used like template< class Fun > int algorithm( Fun fun ) { return unref(fun)(42); } any objections to adding this to ref.hpp? -Thorsten

2 1

[variant]compile-time-checked boost::get<T>?
by Arno Schödl 11 Dec '08

11 Dec '08

Hello, I just replaced our own union implementation by boost::variant and was surprised that boost::get<T> does not compile-time check T. IMHO, boost::get<T> should only compile if T is a possible member of the variant. We implemented this with an enable_if without much difficulty. As a further extension, boost::get<S> where S is a base class of a T contained in the variant, should also work. I believe this would also be implementable with enable_if/disable_if, but we have not done it, so no guarantee. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

5 7

[constrained_value] need help with runtime error
by Neal Becker 11 Dec '08

11 Dec '08

This code has an error: #include <boost/numeric/ublas/vector.hpp> #include <boost/constrained_value.hpp> namespace cv = boost::constrained_value; namespace ublas = boost::numeric::ublas; typedef cv::bounded<int>::type val_t; typedef cv::bounded<int>::type::constraint_type constraint_type; int main() { int min = -200; int max = 200; val_t init (10, constraint_type (min, max)); ublas::vector<val_t> v (10, init); ublas::vector<val_t> w = -v; } This code will throw an exception. The last line invokes: ublas/functional.hpp:70 (scalar_negate), which for some reason calls constrained.hpp:224, which is: constrained(const value_type & v) That is, initialize only the value, not the constraint! Any ideas?

4 4