- Boost - lists.boost.org

Fw: Making a new contribution - weak_hash_map
by Yoni Lavi 15 Dec '08

15 Dec '08

Anyone? am I sending this to the right mailing list? It doesn't seem like I've gotten any reply to this. If there is some general principle precluding this contribution from being considered, please let me know. ----- Forwarded Message ---- From: Yoni Lavi <l_yoni(a)yahoo.com> To: boost(a)lists.boost.org Sent: Friday, November 28, 2008 3:09:33 AM Subject: Making a new contribution - weak_hash_map I'd like to contribute a C++ class template that implements something similar to java.util.WeakHashMap; it uses boost::intrusive::iunordered_set and boost::pool::fast_pool_allocator internally. This is the first time I'm looking to get into boost development in general. I'm not aware of any trivial way to implement this using existing components of the boost library, but I could have easily overlooked something so let me know if I am mistaken. I'd also like to know if there's any interest in such a contribution at all - anyone else thinks this class could be useful? Briefly, given a key space and value space, the class provides a way to lookup (and optionally create) values by a unique key, in a thread safe manner. A smart pointer to the entry (<key, value> pair) is returned from the lookup/create function. The tricky part is to make such entries automatically destroy themselves when no longer in use. The set itself cannot store a shared_ptr or the use count would never reach zero; it has to rely on weak_ptr and try to lock() it. There is also a race condition that needs to be taken care of (lock() may fail if refcount just dropped to zero in another thread). Lastly, it also has to handle the case where the weak_hash_map is destroyed but its entries persist, and again this needs to be properly synchronized. The implementation makes use of insert_check and insert_commit to implement a "create-or-get" function as well. I have also written an intrusive smart pointer type and that made it possible to use raw pointers instead of the weak_ptr's in the implementation. It's not that this stuff is rocket science as much as it involves lots of boilerplate code (e.g. making an entry hasher out of a key hasher, key/entry and entry/entry equality from key/key equality, resizing the hash table automatically, synchronization, allocation... the class I've written takes care of a lot of the ugly details. If anyone's interested, please fill me in on the process of making such a contribution? Thanks.

2 1

<build>no in common properties
by K. Noel Belcourt 15 Dec '08

15 Dec '08

Hi, The Sandia-darwin-intel-11.0 results are failing because essentially every Boost product is not being built (actually being skipped). This message is present for almost every Boost library. Skipping build of: ../libs/date_time/test/date_time_serialization <build>no in common properties Skipping build of: ../libs/disjoint_sets/disjoint_sets <build>no in common properties Skipping build of: ../libs/dynamic_bitset/dynamic_bitset <build>no in common properties Skipping build of: ../libs/exception/test/is_output_streamable_test <build>no in common properties Any idea what's up with this? The Sandia-leopard-x86 results didn't seem to suffer from this problem last night. Thanks. -- Noel

3 11

Measuring compile time performance
by dan marsden 15 Dec '08

15 Dec '08

Hi We're looking at optimizing some of the compile time performance in Boost.Fusion. I'm looking for any experience in Boost of measuring build times / compile time cost, how to structure tests that cover it etc. Does Boost.Build provide any support for measuring compile time for example? I'm aware there's a Perl script by Steven Watanabe that measures template instantiations if I understand correctly. Are there any other techniques that are being used that I should be aware of? Cheers Dan Send instant messages to your online friends http://uk.messenger.yahoo.com

9 14

Re: [boost] [Boost-users] BoostCon 2009: Call for Participation
by Raindog 15 Dec '08

15 Dec '08

Hartmut Kaiser wrote: > 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 > Any idea when the boostcon website will be updated with 2009 info?

1 0

[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