- Boost - lists.boost.org

Re: [boost] boost::shared_ptr<>::compare_and_swap()--AmIinsaneforwanting this?
by Talbot, George 13 Nov '06

13 Nov '06

OK...attached is a test version of atomic_shared.h that does implements this using pthread_spin_lock/pthread_spin_unlock. Let me know if it looks sane whatsoever. Now I just saw the post by Chris Thomasson--is there a way to write something like atomic_shared without the spinlocks? I'm looking for a class that's as easy to use as shared_ptr, but that is read/write thread-safe and supports compare_and_set/swap. I'm not worrying about the ABA problem just yet. I also do not have a good answer to the post by Sohail Somani about what the compiler will do with this in the future. Note that I implemented atomic_shared::compare_and_set(), not compare_and_swap(). -- George T. Talbot <gtalbot(a)locuspharma.com> > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Peter Dimov > Sent: Friday, November 10, 2006 1:21 PM > To: boost(a)lists.boost.org > Subject: Re: [boost]boost::shared_ptr<>::compare_and_swap()-- > AmIinsaneforwanting this? > > Talbot, George wrote: > > > Wow...this is great! I think I may try to code up a wrapper that > > privately inherits from shared_ptr and just provides the spinlock > > around > > the operations, as a proof-of-concept. I'm doing this on Linux on x86 > > right now (32-bit). Should I use this spinlock implementation: > > http://en.wikipedia.org/wiki/Spinlock > > To be on the safe side, you'll probably need something a bit more > elaborate > than that: > > for( int i = 0; i < 4; ++i ) > if( atomic_exchange( &spinlock, 1 ) == 0 ) return; // got spinlock > > // we probably need to yield to the thread holding the lock > > for( int i = 0; i < 32; ++i ) > { > if( atomic_exchange( &spinlock, 1 ) == 0 ) return; // got spinlock > sched_yield(); > } > > // we might need to yield to a lower-priority thread holding the lock > > for( ;; ) > { > if( atomic_exchange( &spinlock, 1 ) == 0 ) return; // got spinlock > nanosleep( some-small-value ); > } > > where 4 and 32 are fudge factors. But the simple version will work for a > proof of concept. > > On Linux, it seems easiest to just use pthread_spin_lock/unlock for the > prototype. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[BLL] Nesting STL algorithms and mutable iterators
by MuTPu4 13 Nov '06

13 Nov '06

While using standart algorithm wrappers (::boost::lambda::ll) I find out that there is no way to call non-constant versions of begin/end without defining new helper functors in the user code. In other words, algorithms like ll::sort as- is are unusable. I think it would be nice to add a pair of non-const helper functors, i.e. call_mutable_begin and call_mutable_end to the library.

1 0

2D Matrix
by Jason Kraftcheck 13 Nov '06

13 Nov '06

Hi, I have written a simple 2D matrix template where the extents of the matrix are template parameters. The multi_array container and the uBLAS matrix class both provide matrices of fixed dimension (template parameter for multi_array and 2 for uBLAS) but variable extents. I think my matrix definition is complementary to these. There are several advantages to having an array of fixed extents; but the implementation is, of course, unusable when the extents are not known at compile-time. If the extents of the matrix are part of the type, the compiler can enforce correct matrix extents for operations, avoiding the cost of runtime checks. For example: double b[3][2] = { ... }; matrix<3,3> A(2.0); // 2 * identity matrix<3,2> B(b); matrix<2,3> C; matrix<3,2> D; D = A * B; // OK C = A * B; // compile error - mismatched types C = transpose(B) * A; // OK Optimizing compilers can trivially unroll the loops used to define the operations. Use of this class does not require heap allocation. The storage required for the matrix is the minimal possible (assuming no assumptions about the values of the elements.) An array of matrices can be "serialized" to an array of doubles with a single reinterpret_cast. The proposed implementation is unsuitable for very large matrices: defining the element storage as a contiguous array may be problematic, most of the performance gains become insignificant, and the implicit copying will become significant. I've attached my current implementation. In it's current form, it is unsuitable for inclusion in Boost. I will fix any required issues if there is any interest in including it in Boost. The things that need to be changed (that I'm aware of) are: o license - GPL is not acceptable for Boost o naming (namespace and class name) o change explict 'double' for element type to a template parameter Some other changes that should probably be done before inclusion: o implement inverse for other than 2x2 and 3x3 matrices o more efficient determinant implementation for larger matrices o LU factorization o QR factorization In timing tests using G++ 4.1 on a Linux/Pentium4 platform, the performance of the arithmetic operations was equivalent to those of a special 3x3 matrix implementation with all operations explicitly unrolled (the 'old' implementation this one was to replace.) Is there any interest in including such a matrix definition in Boost? Is there already an effort to include something equivalent? I searched back a few years in the mailing list archive and didn't notice anything. Any suggested changes (other than those I listed above) for the attached implementation?

6 18

Exception lib proposal: renaming boost::exception_info
by Emil Dotchevski 13 Nov '06

13 Nov '06

This is an update to the proposed boost::exception library (the source code, full documentation and tests are available at http://www.revergestudios.com/boost-exception/boost-exception.htm.) Last thing that I wanted to clear before requesting a formal boost review for boost::exception is renaming exception_info as a workaround for the name clash with the macro with the same name (lowercase and all) defined by windows.h. The two candidates I like for renaming exception_info are: except_info throw_info Here is an example of how they would look in code: throw my_exception() << except_info<tag_errno>(errno) << except_info<tag_function>(BOOST_CURRENT_FUNCTION); -or- throw my_exception() << throw_info<tag_errno>(errno) << throw_info<tag_function>(BOOST_CURRENT_FUNCTION); The above is a use case of encoding exception information at the time of the throw. The other use case is to catch a boost::exception, add exception info to it and re-throw. Here is an example of how each of except_info and throw_info would look in that case: catch( boost::exception & x ) { x << except_info<tag_filename>(fn); throw; } -or- catch( boost::exception & x ) { x << throw_info<tag_filename>(fn); throw; } Any strong preferences? Thanks, Emil Dotchevski

4 5

GIL: Survey
by Lubomir Bourdev 13 Nov '06

13 Nov '06

Hi, I am collecting a survey about GIL. I would really appreciate it if people who are thinking about using GIL send me an email with the following: 1. Which company/university/organization are you a member of? 2. Are you thinking of using / will likely use / have adopted GIL? 3. In what context are you using GIL (if you can share that) Of course, any feedback on GIL, including features that you would like to see, is much appreciated! Thanks! Lubomir

2 1

[mpl] metafunctions for stl templates
by Sascha Krissler 12 Nov '06

12 Nov '06

Hi, i had this little idea. when yo want to customize a class with a container like template <typename T, typename Container> struct Foo; then you must instanciate it with: Foo<int, std::vector<int> > the second int is redundant. --- Alternative: template <typename T, template <typename, typename> class Container> struct Foo; Here i do not have an allocator for the instantiation of Container. --- What i would like is: template <typename T, typename Container> struct Foo { typedef typename mpl::apply<Container, T>::type foo; }; and instantiate it with: Foo<int, mpl::stl_foo::vector<mpl::placeholder::_1> > For that i need namespace boost::mpl::stl_foo { template <typename T, typename Alloc> struct vector { typedef std::vector<T, Alloc> type }; } so i can curry containers as i wish. just an idea

5 6

How do I detect if a system is fully 2's complement?
by Daryle Walker 12 Nov '06

12 Nov '06

I'm working on a bug that's only present on machines that use 2's complement for their built-in integers that use all possible bit combinations (like the common platforms). How can I detect this? Stuff I tried (knowing that my system matches): 1. -INT_MIN == INT_MIN My compiler didn't find it a match for some reason (Apple's special GCC on Mac OS X 10.4.8) 2. (INT_MIN % 3 != 0) && (INT_MIN % 2 == 0) This is true, especially since I was doing a GCD(INT_MIN, 6) == 2, but I don't think it's sufficient. 3. -1 == ~0 This worked. Then I found out that ~0 may trap on some systems (like 1s' complement). Worse, I found out that INT_MIN could equal -INT_MAX, leaving out the final power of 2 for trap reasons, so [2] is flawed. 4. ~1 == -2 Also 2's complement, but leaves out the trap possibility (not tried) 5. INT_MIN + INT_MAX == -1 This worked. It guarantees the bounds, but not that INT_MIN is a negative of a power of 2. 6. (INT_MIN + INT_MAX == -1) && ((INT_MIN ^ INT_MAX) == -1) This is what I currently got. It matches two properties of 2's complement systems that use every bit combination. But is it sufficient? 7. [6] && [4] (Not tried) Would this be an improvement? Or is it redundant? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 2

[1.34.0] Boost.Build
by Thomas Witt 12 Nov '06

12 Nov '06

Hi, Please note that we are not going to ship boost.build v1 with 1.34.0. The only supported build system will be v2. Please notify me of any outstanding issues due to this. Thanks Thomas Release Manager -- Thomas Witt witt(a)acm.org

11 20

[serialization] binary archives missing from diagram
by David Abrahams 12 Nov '06

12 Nov '06

See http://www.boost.org/libs/serialization/doc/class_diagram.html I just watched as this omission confounded someone on the Boost IRC channel, FWIW. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

Re: [boost] [1.34.0] Boost.Build
by Matt Doyle 12 Nov '06

12 Nov '06

> [mailto:boost-bounces@lists.boost.org] On Behalf Of Thomas Witt > Johan Nilsson wrote: > > Paul Baxter wrote: > > > > FWIW, I agree. > > > > Keeping BBv1 in CVS and instead making BBv2 the default > when executing > > "bjam" for this release would be easier on the users, in > combination with > > adding support for "bjam --v1". Perhaps also some > deprecation warnings > > should be output when building with v1. > > > > BBv1 could then be removed from Boost CVS in 1.35 and made > available as a > > separate download (tgz, zip). > > That are all valid points, but at the end of the day we just > don't have > the resources. We can barely support one build system. > > FWIW users that depend on v1 can always use 1.33.x > > Thomas Doesn't this seem rather Microsoft-ish? I'm thinking of .NET, the attitude was you wouldn't accept it when we offered it to you so now we're going to force it on you. And, if you really don't want .NET you can always use VC6.5. Do you see the parallels here? If it has to go away, and I'm not saying for a moment that it shouldn't, v1 should at least be formally deprecated for one release cycle so as not to catch the users off guard. Matt Scanned by McAfee GroupShield {X3BTB534}

4 6