- Boost - lists.boost.org

Comment spam in bugs
by Sebastian Redl 14 May '09

14 May '09

There's comment spam in this bug: https://svn.boost.org/trac/boost/ticket/1989 Is there a unified way for reporting this, aside from posting here? Sebastian

1 0

[RFC] thread::access_monitor
by Gregory Petrosyan 14 May '09

14 May '09

I would like to hear your comments on the idea behind access_monitor template, which ensures (at compile-time) that data, protected by it, can be accessed only with associated lock held. It can be useful when you want to expose all the native interface of your data type (STL container, for example): in such a case, using ordinary monitor pattern is almost impossible. Example usage: typedef access_monitor<data_type, mutex_type> data_access_monitor; void f(data_access_monitor const& d) { data_access_monitor::value_type const* data; data_access_monitor::lock_type lock; boost::tie(data, lock) = d.const_lock(); // do something with data here } Code: #include <boost/thread.hpp> #include <boost/tuple/tuple.hpp> template <typename T, typename Lockable> struct access_monitor { typedef T value_type; typedef boost::unique_lock<Lockable> lock_type; private: typedef boost::detail::thread_move_t<lock_type> lock_move_type; public: boost::tuple<value_type const*, lock_move_type> const_lock() const { lock_type lock(mutex_); return boost::make_tuple(&data_, lock.move()); } boost::tuple<value_type*, lock_move_type> lock() { lock_type lock(mutex_); return boost::make_tuple(&data_, lock.move()); } private: // mutex_ is guaranteed to be locked when you access data_ mutable Lockable mutex_; T data_; }; Sorry for draft-quality code (however, something like the above compiles with MSVC 9). Please CC me, because I am not subscribed. Gregory

2 1

[random] cross-platform secure seeding methods planned?
by Sebastian Nowozin 14 May '09

14 May '09

Hello everybody, I like the flexibility boost::random offers. However, a severe drawback of the current library is that it does not offer a safe way of generating seeds. Of course the methods for providing this feature would vary quite a lot across platforms (e.g. on some systems its safe to use /dev/random, on some it is not). However, as the library is currently, many users will resort to ad-hoc or unsafe seeding methods instead of implementing a safe solution themselves. Hence, is a cross-platform secure seeding feature planned for boost::random in the future? Thanks, Sebastian

2 1

[exception] Lifetime of exception refered to by exception_ptr
by Adam Badura 14 May '09

14 May '09

I failed to find in Boost.Exception documentation any note on how long is the lifetime of an exception object referred to by an exception_ptr. Also I failed to find it in the referred N2179 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2179.html) It seems logical to assume that the lifetime is not shorter then the lifetime of any exception_ptr object referring to the exception object. N2179 suggests possibility of use of smart pointer as implementation of exception_ptr which makes that assumption even more justified. However I think that documentation should be explicit with this. Adam Badura

3 5

[iterators] Proof-of-concept for a sentinel iterator adapter
by Beman Dawes 13 May '09

13 May '09

Attached is proof-of-concept code for a sentinel iterator adapter. It turns a pointer to sentinel terminated sequence, such as a C-style string, into a forward iterator with a conforming end iterator. This is more efficient than doing a separate sequence traversal just to find the end. I'm a little surprised that Boost doesn't already have such an iterator adapter. Or am I just missing it? Would a production version of this iterator adapter be a worthwhile addition to Boost.Iterators? Any other comments appreciated, --Beman // sentinel terminated sequence iterator proof-of-concept // Copyright Beman Dawes, 2009 #include <cassert> // sentinel terminated sequence iterator template < class T, T Sentinel = T() > class sentinel_iterator { public: sentinel_iterator() : m_ptr(0) {} // construct end iterator sentinel_iterator( T * p ) : m_ptr( (p && *p != m_sentinel) ? p : 0 ) {} sentinel_iterator & operator++() { assert(m_ptr); if ( *++m_ptr == m_sentinel ) m_ptr = 0; return *this; } T & operator*() const { assert(m_ptr); return *m_ptr; } bool operator==( const sentinel_iterator & rhs ) const { return m_ptr == rhs.m_ptr; } bool operator!=( const sentinel_iterator & rhs ) const { return m_ptr != rhs.m_ptr; } private: T * m_ptr; // 0 == the end iterator static const T m_sentinel = Sentinel; }; int main() { // test cases using default sentinel sentinel_iterator<char> it( "abc" ); assert( it != sentinel_iterator<char>() ); assert( *it == 'a' ); assert( *++it == 'b' ); assert( *++it == 'c' ); assert( ++it == sentinel_iterator<char>() ); sentinel_iterator<char> it2( "" ); assert( it2 == sentinel_iterator<char>() ); sentinel_iterator<char> it3( 0 ); assert( it3 == sentinel_iterator<char>() ); // test cases using non-default sentinel typedef sentinel_iterator<unsigned, -1> my_iter_type; unsigned data[] = { 0, 1, -1 }; my_iter_type my_it( data ); assert( my_it != my_iter_type() ); assert( *my_it == 0 ); assert( *++my_it == 1 ); assert( ++my_it == my_iter_type() ); unsigned my_sentinel = -1; my_iter_type my_it2( &my_sentinel ); assert( my_it2 == my_iter_type() ); my_iter_type my_it3( 0 ); assert( my_it3 == my_iter_type() ); return 0; }

10 23

Boost::Lambda + Boost::Tuple + unresolved overloaded function type
by Dmitry V. Krivenok 13 May '09

13 May '09

Hello! I wrote two simple examples to demonstrate the problem. First one is: //////////////////////////////////////////////////////////////// #include <vector> #include <utility> #include <algorithm> #include <cassert> #include <boost/lambda/lambda.hpp> #include <boost/lambda/bind.hpp> int main() { std::vector<int> v1; v1.push_back(1); v1.push_back(2); v1.push_back(3); std::vector<std::pair<int*, bool> > v2; namespace bll = boost::lambda; std::transform(v1.begin(), v1.end(), std::back_inserter(v2), bll::bind(std::make_pair<int*, bool>, &bll::_1, true)); assert(v2.size() == 3); return 0; } //////////////////////////////////////////////////////////////// This program compiles and works fine. The second program is: //////////////////////////////////////////////////////////////// #include <vector> #include <utility> #include <algorithm> #include <cassert> #include <boost/tuple/tuple.hpp> #include <boost/lambda/lambda.hpp> #include <boost/lambda/bind.hpp> int main() { std::vector<int> v1; v1.push_back(1); v1.push_back(2); v1.push_back(3); namespace bll = boost::lambda; std::vector<boost::tuple<int*, bool> > v3; std::transform(v1.begin(), v1.end(), std::back_inserter(v3), bll::bind(boost::make_tuple<int*, bool>, &bll::_1, true)); assert(v3.size() == 3); return 0; } //////////////////////////////////////////////////////////////// It doesn't compile: $ g++-4.3.2 -I /usr/local/dev/boost-1.38.0/include/ main2.cpp main2.cpp: In function 'int main()': main2.cpp:22: error: no matching function for call to 'bind(<unresolved overloaded function type>, const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::other_action<boost::lambda::addressof_action>, boost::tuples::tuple<boost::lambda::lambda_functor<boost::lambda::placeholder<1> >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >, bool)' $ What's wrong in the second program? Thank you beforehand! -- Sincerely yours, Dmitry V. Krivenok Orange System Co., Ltd. Saint-Petersburg, Russia work phone: +7 812 332-32-40 cellular phone: +7 921 576-70-91 e-mail: krivenok(a)orangesystem.ru web: http://www.orangesystem.ru skype: krivenok_dmitry jabber: krivenok_dmitry(a)jabber.ru icq: 242-526-443

2 1

Dynamic bitset library - compilation problem on windows (boost 1_37_0onwards)
by Aniket Bhat 13 May '09

13 May '09

I am seeing problems with msvc when compiling a simple code snippet that instantiates a dynamic_bitset with a uint64_t. The problem occurs when instantiating a template specialization for the resize function for uint64_t. There was a change made to the block_width_type typedef from an int in 1_36_0 to block_type in 1_37_0. This change seems to have broken support for uint64_t data-types on 32-bit windows systems or any other types which are bigger than size_t on a given platform. Code snippet: #include <boost/dynamic_bitset.hpp> #include <iostream> #if defined (__GNUC__) #if !defined (SUNOS_OS) typedef unsigned long long uint64_t; #endif #else typedef unsigned __int64 uint64_t; #endif typedef uint64_t myType; boost::dynamic_bitset<myType>::size_type foo() { unsigned int blockHandles(10); return (boost::dynamic_bitset<myType>::size_type )(blockHandles*sizeof(myType)*8); } int main(int argc,char**argv) { boost::dynamic_bitset<myType>::size_type t = foo(); boost::dynamic_bitset<myType> m_myBitSet; m_myBitSet.resize(12,false); } Compilation error: Compiling... TestBitSet.cpp c:\p3_dev_boost\common\lib\boost_1_39_0\boost\dynamic_bitset\dynamic_bitset.hpp(673) : error C2220: warning treated as error - no 'object' file generated c:\p3_dev_boost\common\lib\boost_1_39_0\boost\dynamic_bitset\dynamic_bitset.hpp(649) : while compiling class template member function 'void boost::dynamic_bitset<Block>::resize(boost::dynamic_bitset<Block>::size_type,bool)' with [ Block=myType ] c:\documents and settings\abhat\my documents\aniket\projects\dynamic_bitset\testbitset\testbitset.cpp(17) : see reference to class template instantiation 'boost::dynamic_bitset<Block>' being compiled with [ Block=myType ] c:\p3_dev_boost\common\lib\boost_1_39_0\boost\dynamic_bitset\dynamic_bitset.hpp(673) : warning C4244: 'initializing' : conversion from 'unsigned __int64' to 'const boost::dynamic_bitset<Block>::size_type', possible loss of data with [ Block=myType ] The resize function (dynamic_bitset.hpp:673) calls count_extra_bits() which returns a size_type instead of block_width_type resulting in possible loss of data. At all other places this function is called within the header, it returns a block_width_type. I am not sure if it has to return a size_type in this particular case for a specific reason? Thanks, Aniket.

1 0

[chrono] Motivation for Boost version evaporating
by Beman Dawes 13 May '09

13 May '09

The motivation for a Boost version of <chrono> seems to be evaporating since GCC 4.4.0 has shipped with an implementation and Microsoft has also signaled they intend to ship a C++0x standard library implementation sooner rather than later. Thus I'm no longer interested in working on a Boost version. If anyone else would like to take it on, that's OK with me, but I don't see enough benefit to Boost to make the effort worthwhile. --Beman

3 4

Re: [boost] Boost Bug Sprint Proposal
by Beman Dawes 13 May '09

13 May '09

On Tue, May 12, 2009 at 11:08 PM, Marshall Clow <marshall(a)idio.com> wrote: > A few weeks ago, Doug proposed a "Boost Bug Sprint", modeled on the Debian > one; to clean up the backlog of bugs, patches and feature request that have > grown in the Trac system. > > We currently have about 800 open issues. > > I am proposing that we start on Friday, May 29th and finish on Sunday, June > 7th. > That gives us a work week and two weekends, making time for both people who > can work during the week, and those who only have time to contribute to > boost on the weekends. Great idea! Those dates look good and I've added them to the Boost calendar. --Beman

1 0

Re: [boost] Boost Bug Sprint Proposal
by Daniel James 13 May '09

13 May '09

2009/5/13 Marshall Clow <marshall(a)idio.com>: >> What can you do? >> >> 1) You can fix bugs. >> * If you are a library author, you can commit changes. >> * If you are not a library author, you can fix a problem on your local >> machine (and test it!!), and then attach your fix as a patch to the Trac >> ticket for the library author to commit. If you do this, please provide a >> test case that exercises the problem; i.e, one that fails w/o your patch, >> and succeeds afterwards. I think library authors should also try to be more readily available for that week, maybe on IRC or by subscribing to the bug list. Daniel

1 0