May 2009 - Boost - lists.preview.boost.org

Review Request: Algorithm.Sorting
by Steven Ross 15 May '09

15 May '09

I have uploaded algorithm_sorting.zip for a formal review to become Boost.Algorithm.Sorting, if people feel that is appropriate. It is 3 templated hybrid radix-based/comparison-based algorithms, specialized to sort certain types of data more efficiently. All 3 have superior worst-case and average-case performance to std::sort, based upon my testing. None of these algorithms use much additional memory. All of them can sort key + data, and as they do fewer swaps, tend to do so much faster than std::sort. As a general rule, the speedup of these algorithms relative to std::sort increases as data set size increases. These algorithms tend to be faster relative to std::sort when comparisons are slow, as they do less (or no) comparisons. string_sort, which sorts strings in O(n*length) time, as compared to O(n*length*log(n)) for pure comparison-based algorithms. It is consistently faster than std::sort in string sorting, by a little more than a factor of 2 based upon my testing. float_sort, which sorts IEEE floating-point numbers as integers, but attaining the same ordering as std::sort, with the exception of -0.0 and NaNs, both of which cannot be ordered based upon their comparison function. float_sort is roughly twice as fast as std::sort on UNIX-type OSes I've tested on, and roughly 7X as fast on Windows. I believe this speedup to be because floating-point comparisons are slow on Windows. integer_sort, which sorts integers around 60% faster than std::sort on UNIX-type OSes, and 25% faster on Windows. On Windows with MSVC, std::sort sorts already-sorted and small range data extremely quickly, and integer_sort processes already-sorted data slower than it by as much as a factor of 3X. I believe this to be due to some optimization for already-sorted data, as integer_sort takes substantially less absolute time on already-sorted data than unsorted data. So integer_sort on Windows has a tradeoff: better worst-case and average-case performance, but worse best-case performance. integer_sort and float_sort share some tuning parameters. I have set values that seem to work well on both UNIX-type and Windows OSes, but people are welcome to try to see what values are best for their system and problem type. The ideal values for integers and floats may be different on some systems (such as Windows), but for simplicity they are kept the same. A tuning/testing script named tune.pl is included, for those who wish to see how fast these algorithms are on their system (and verify correctness). I don't recommend using it for tuning without the -large option, and that takes days. If you do use it for tuning, I also recommend the -verbose option, to see what it's doing.

6 19

[exception] current_exception mishandling standard exceptions
by Adam Badura 14 May '09

14 May '09

It seems that current_exception mishandles standard exceptions. I noted two problems: 1) Some standard exceptions are not handled at all. This includes std::runtime_error and its derived (std::overflow_error, std::range_error, std::underflow_error), std::domain_error (handled by general std::logic_error), std::length_error (handled by general std::logic_error) and std::ios_base::failure (handled by general std::exception). Why is it so? 2) Non-standard exceptions derived from standard exceptions are sliced by current_exception. It detects those types by throwing and caching and thus will catch also derived types (like null_pointer : public std::invalid_argument). But during construction of internal structures the standard exception type is used and thus copy construction slices the original exception object. If typeid was used instead of throwing/catching (or dynamic_cast) to detect the type current_exception could at least detect that is will slice the original object and use a different type so it would not pretend everything is OK. Adam Badura

3 6

[property_tree] XML parser broken in 1.39.0
by Boris Schaeling 14 May '09

14 May '09

Calling boost::property_tree::xml_parser::read_xml() to parse a XML file and populate a property_tree doesn't work anymore in Boost 1.39.0 (at least not in Visual C++ 2008). The compiler error I see is: boost\iterator\iterator_adaptor.hpp(230) : error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>' with [ x=false ] The property_tree headers include boost\spirit\home\classic\iterator\position_iterator.hpp which includes boost\iterator\iterator_adaptor.hpp. I also see this warning: Warning: This header is deprecated. Please use: boost/spirit/include/classic.hpp Warning: This header is deprecated. Please use: boost/spirit/include/classic_position_iterator.hpp It looks like as if a change in Boost.Spirit or Boost.Iterator broke the XML parser. Does Boost.PropertyTree have a maintainer who can look into this? Boris PS: As it turns out it's broken in Boost 1.38.0, too. With 1.36.0 I don't get a compile error (1.37.0 I don't have installed and can't test).

3 5

Re: [boost] [rfc] Unicode GSoC project
by Graham 14 May '09

14 May '09

> 1. The vast majority of characters (by frequency of use) are > on the BMP. > 2. For seamless integration with the majority of existing > software with good Unicode support. > >I don't find either of those claims very convincing. I hope that your >library will not try to make UTF-16 some sort of default encoding, or >otherwise give it special treatment. Phil, I think each application needs to be assessed on its own merits. For example: For data storage on mainly ASCII text I use UTF-8. For text manipulation I often use UTF-16. For a Unicode text editor I use UTF-32. There is not a one size fits all. Yours, Graham

1 0

New version of C++ Middleware Writer now on line
by Brian Wood 14 May '09

14 May '09

Shalom Version 1.9 of the C++ Middleware Writer is now available. This version adds support for Boost Array and it also has a command line interface that allows users to bypass the web interface. In other words, it makes it easy to integrate the C++ Middleware Writer into your build process. http://webEbenezer.net/build_integration.html<http://webebenezer.net/build_integration.html> -- Brian Wood Ebenezer Enterprises http://www.webEbenezer.net <http://www.webebenezer.net/>

1 0

Binary compatibility of boost releases. Is there such a thing at all?
by Alexander Churanov 14 May '09

14 May '09

Hi folks! I am working on boost port for FreeBSD. At present I am investigating into versioning of shared libraries. Historically, versions of boost shared libraries on FreeBSD do not match boost release version. Some FreeBSD folks beleive that application should not be recompiled just because the boost was updated, say from 1.37 to 1.39 and that shared library version for 1.39 may stay the same as it was for 1.37. I'm afraid it's not correct. I've read that there is no binary compatibility for boost shared libraries from different releases, and that application must use exactly the same library it was compiled for. However, these documents are of 2003-2004. Here is the question: What is the actual status of binary compatibility for boost? Alexander Churanov, maintainer of devel/boost

3 3

[future] usage question for new accepted library
by Alan Patterson 14 May '09

14 May '09

Hi, I see Anthony William's future implementation has been accepted over Braddock Gaskill's. I have been using Braddocks implementation and in particular a couple of features which I believe are not in Anthony's implementation. So I am looking for some pointers for how I might do the following with the accepted futures implementation. 1) Using the implicit cast of future<T> to T. I have an application where I can submit jobs to a scheduler, have them executed and provide me with a return value. My scheduler uses a policy for implementation: scheduler<single_threaded_policy> scheduler<threadpool_policy> The user submits a task and gets the result like result_type r = scheduler.submit(some_task()); where result_type is obtained from the scheduler and can either be of type T for single_threaded or future<T> for threadpools. Either way the client doesn't care which, because he can use a T or future<T> identically IF future<T> casts to T. I like this because the client never knows anything about futures, he treats all result_types as type T. I guess the way to do this with the accepted future implementation is to create a template function that does the following: T actual_r = get<result_type>(r); which call get() if it is a future or just returns r if not. But this is no where near as nice IMHO. The user no longer just uses the result_type of his task directly for what seems to be a basic type. 2) callbacks when future is set I have a usage scenario where I submit a batch of tasks where I collect results until I either have the result I want or collect enough that I can return what I have. This is neither a wait_for_any or a wait_for_all, more a kind of wait_until_i_have_enough. I currently implement this by submitting the batch of tasks and getting a batch of futures. I then register a callback on each future that gets called as each future gets set. The callback collects results as they come in and can decide to bail out early if it has enough results. How would I go about implementing this usage with the new futures implementation? Thanks in advance and sorry for the long post. Alan

2 1

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

[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

Boost Libraries under development: Bitfields
by vicente.botet 13 May '09

13 May '09

Hi, I have adapted the Bitfield library from Emile Cormier with its permision. Boost.Bitfield consists of: a.. a generic bitfield traits class providing generic getter and setter methods. b.. a BOOST_BITFIELD_DCL macro making easier the definition of the bitfield traits and the bitfield getter and setter functions. struct X { typedef boost::ubig_32 storage_type; storage_type d0; typedef unsigned int value_type; BOOST_BITFIELD_DCL(storage_type, d0, unsigned int, d00, 0, 10); BOOST_BITFIELD_DCL(storage_type, d0, unsigned int, d01, 11, 31); }; The library is quite stable but I want to add some test with Boost.Endian before adding it to the formal review schedule list. Here is the link from which you can get the library code + documentation + test https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Bitf… I'd appreciate if people could take a look, test it on their compiler and give me some feedback. Thanks for all, _____________________ Vicente Juan Botet Escribá

2 2

[1.40.0] OK to build release?
by Beman Dawes 13 May '09

13 May '09

There has been little feedback on the 1.40.0 beta release. I'm hoping that is a good sign:-) Unless someone objects, I'll start building the actual release in an hour or so. --Beman

9 28

Boost Install Target
by Esben Stien 13 May '09

13 May '09

I guessed that I had to run bjam install and it worked, but this was not mentioned in the manual, getting started guide. -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact sip:b0ef@ e e jid:b0ef@ n n

2 1

[sorting] Implementation of histogram sort
by Jeremiah Willcock 12 May '09

12 May '09

Does the proposed Boost sorting library contain an implementation of histogram sort or some other in-place variant of bucket sort (American flag sort, etc)? I would like to use an integer sort for a problem I have but need to save as much memory as possible. Having one element of temporary storage per bucket is fine, though. -- Jeremiah Willcock

3 2

SafeInt library for Boost
by Omer Katz 12 May '09

12 May '09

Hi everyone, I am considering adding a safeInt library to Boost. If there are any suggestions regarding a special content of such a library, or any special implementation ideas, I'll be glad if you'd let me know. right now I plan to use a template class for it. I'll be glad to accept your comments. Regards, Ziv

1 0