May 2009 - Boost - lists.boost.org

[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 14 May '09

14 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

[property_tree] streaming operators
by Chris Meyer 13 May '09

13 May '09

More on property_tree: It would be nice if the default translator did not use the << and >> operators by default. In my software, I use << to stream a debugging description of an object -- so it is useless for archiving purposes. Instead, the detail::translator could define and use template <class Ch, class T> inline void writeToStream(std::basic_ostream<Ch> &os, const T &value) { os << value; } template <class Ch, class T> inline void readFromStream(std::basic_istream<Ch> &is, T &value) { is >> value; } Then clients of the library would have more flexibility in implementing the streaming operations by providing specializations of these functions. (These functions would be used in place of the stream >> and << calls in detail::extractor::operator() and it's specializations). Is this list the right place for these requests or is there a better place to put them so that they get tracked?

2 1

property_tree iterators
by Chris Meyer 13 May '09

13 May '09

I've been using property_tree and it is very useful to me. It's easy to add typed data to the tree using something like MyType myvar[10]; for (i=0; i<10; ++i) pt.put(key, myvar[i], true); I can also implement my own translator to convert MyType to a string suitable for serializing to XML, JSON, or whatever. However, if I go to retrieve this data, things are less refined. Iterating over all elements with a given key requires something like this: ptree::key_compare comp; BOOST_FOREACH(ptree::value_type &v, pt) { if (!comp(v.first, key) && !comp(key, v.first)) { MyType myvar = convertStringToMyType(v.second.data()); doSomething(myvar); } } Perhaps there should be a templatized member function which uses the translator to automatically iterate all values of a particular key and have it converted to the desired data type. Then I could use something like: BOOST_FOREACH(MyType myvar, pt.get_all<MyType>(key)) { doSomething(myvar); } Is this possible? Or is there something I'm missing from the existing API that allows me to do this?

2 1

Boost Bug Sprint Proposal
by Marshall Clow 13 May '09

13 May '09

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. I am putting this out for comments: --- Proposal --- >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. > >2) You can characterize bugs. >* You can attempt to replicate the bug on your system(s), and attach >information that you discover to the Trac ticket. This will make it >easier for other people to solve the problem, even if you cannot. >* You can write test cases demonstrating the problem, and attach >them to the Trac ticket. >* You can determine if the bug still exists; sometimes they get >fixed, and the ticket never gets closed. > >3) You can test patches. >* Some of the tickets in the trac system contain patches - some are >quite old. You can install these patches on your system, and >determine if they (a) build, and (b) work. >* You can write test cases for the patches, and attach them to the ticket. > >4) You can help implement new features. >* There are a whole set of "feature requests" in the Trac system. If >you have an idea about one of these, you can add comments to the >trac system. You can attempt to implement these new features, and >attach the patch to the ticket. (Don't forget the test cases!!). > --- End Proposal --- Please let me know what you think, and I will post an updated version. -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

2 1