- Boost - lists.boost.org

[gil] GIL_FORCEINLINE replaced with BOOST_FORCEINLINE?
by Mateusz Loskot 22 Mar '13

22 Mar '13

Hi, In boost/gil/gil_config.hpp, there is GIL_FORCEINLINE defined, but there is no easy way to undef/redefine it. Would it be a good idea to replace GIL_FORCEINLINE with BOOST_FORCEINLINE defined in boost/config/suffix.hpp? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

4 6

GSOC 2013
by David Bellot 22 Mar '13

22 Mar '13

Only 2 projects have been proposed so far for GSOC 2013: wake up Boost ! https://svn.boost.org/trac/boost/wiki/SoC2013 :-D

12 18

[thread] boost::async and launch::deferred - Runtime Error + PATCH
by Fernando Pelliccioni 22 Mar '13

22 Mar '13

Hi Vicente, hi all, The following code snippet throws an exception at runtime boost::future<int> f1 = boost::async( boost::launch::deferred, []() { return 123; }); int x= f1.get(); //exception thrown I am using Boost Trunk revision 83512 I attached a patch, but I'm not sure that's correct, I had no time to see the full future.hpp code I noticed that according to N3558, the future::is_ready() function should be called "ready". http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3558.pdf What do you think? Thanks and regards, Fernando.

2 2

Abstract STL Container Adaptors
by Andy Jost 21 Mar '13

21 Mar '13

Hi Boosters, Is there any interest in an abstract container adaptor library (I'll describe what I mean below)? I'm a little surprised if this has never come up in the context of Boost, but I couldn't find anything on the archives. I did find something on stack overflow (http://stackoverflow.com/questions/5329555/abstract-wrapper-for-stl-contain…) but it did not uncover an existing solution. Motivation: Sometimes we want to write functions that take a container as an argument. For instance, say I have a graph object implemented in terms of ``class Node``. I may expose an algorithm like this: void my_algorithm(Node & root, std::set<Node const *> const & marked); In this case, ``root`` is the root of a graph, and ``marked`` is a set of marked nodes. The problem with this approach is that it forces a particular choice of the set implementation onto the caller. He may, for example, prefer to use ``tr1::unordered_set``. We could get around that limitation by using a template parameter, like this: template<typename Set> void my_algorithm(Node & root, Set const & marked); The problem here is that it forces the implementer of ``my_algorithm`` to expose that code and, potentially, recompile it many times (for different Set types). In some cases, particularly when compile times are more critical than execution times, it would be preferable to let the caller choose the set implementation without losing the advantages of separate compilation. A simple solution is to write an adaptor that mimics the interface of ``set``. With that, the function call would appear as shown here: void my_algorithm(Node & root, abstract_set<Node const *> const & marked); Here, abstract_set<Node const *> is implicitly convertible from any type having the interface of std::set<Node const *>. It internally holds a reference to some implementation of a suitable set-like object and mediates interactions with the outside world through virtual methods. It seems the implementation of this would be a straightforward application of type erasure. It seems too easy, in fact, which makes me wonder whether I'm missing something. In any case, is this a good idea? -Andy

15 34

[config] consexpr workaround
by vicente.botet 21 Mar '13

21 Mar '13

Hi, in order to make easier the introduction of constexpr in a portable way I would like we add a Boost Config workarround. We can define some macros depending on whether BOOST_NO_CONSTEXPR is defined or not. #if defined(BOOST_NO_CONSTEXPR) #define BOOST_CONSTEXPR #define BOOST_CONSTEXPR_OR_CONST const #else #define BOOST_CONSTEXPR constexpr #define BOOST_CONSTEXPR_OR_CONST constexpr #endif For most of the constexpr functions or constructors BOOST_CONSTEXPR will work. constexpr tuple(); =versus= BOOST_CONSTEXPR tuple(); When used for static constants BOOST_CONSTEXPR_OR_CONST is needed as we need to preserv the const keyword when consexpr is not available. static constexpr UIntType xor_mask = a; =versus= static BOOST_CONSTEXPR_OR_CONST UIntType xor_mask = a; We could also add a STATIC_CONSTEXPR macro #define BOOST_STATIC_CONSTEXPR static BOOST_CONSTEXPR_OR_CONST static constexpr UIntType xor_mask = a; =versus= BOOST_STATIC_CONSTEXPR UIntType xor_mask = a; For this case the existing macro BOOST_STATIC_CONSTANT could be modified to use BOOST_CONSTEXPR_OR_CONST when static const was used. static constexpr UIntType xor_mask = a; =versus= BOOST_STATIC_CONSTANT(UIntType, xor_mask = a); Can we introduce this workaround? Best regards, Vicente _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

6 17

[container][intrusive] Treap for Boost.Container?
by Phil Endecott 20 Mar '13

20 Mar '13

Dear All, I have been playing with boost::intrusive::treap, and it seems like a useful thing. I think it would be helpful to create a boost::container::treap, i.e. a non-intrusive treap container, implemented using the intrusive version. That could make this useful data structure available to users who wouldn't otherwise need to learn how to use Boost.Intrusive. (While I'm here.... does anyone know about a list-like container that has lower memory overhead when the data type is small, i.e. ints or chars? I was considering something using chunks like a std::list< std::vector<T> >, but insertion would invalidate other iterators in the same chunk, which is unacceptable. Any ideas?) Regards, Phil.

4 3

[units] c++11 features to speed up compilation times
by Oliver Esser 20 Mar '13

20 Mar '13

Hi, I was wondering if there was a policy for boost including C++11 features into the libraries. Obviously there might be many projects out there that do not (yet) have access to a compiler implementing the new standard or choosing not to use such a compiler. Anyways I was looking for a dimensional analysis library for compile time units checking and found Boost.Units to be quite slow at compile time even for the relatively small example code in the quickstart documentation. So I've written a bit of code that follows the approach of Boost.Units but uses C++11 features (constexpr, variadic templates, suffix operator, auto). It is not a complete library that I would use in a production environment, but it looks promising, since compilation times are about a factor 2-3 faster on my machine. It would be great if some of you could take a look. https://github.com/legento/units Maybe one could add an implementation like that to Boost.Units as a C++11 compiler detected feature to speed things up. Maybe I am totally wrong and it is some coincidence that this compiles faster on my platform. I did just minimalistic 'ok it seems to work' testing and was about as thorough with measurements. So see this as an implementation sketch. Regards Oliver

3 2

C++Now 2013 is full [ 53 days before the conference ]
by Marshall Clow 19 Mar '13

19 Mar '13

Whoa. In the immortal words of W.C. Fields, "I expected this, but not so soon" We've set up a wait list in case we get any cancellations. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

Re: [boost] [range][iterator] contiguous iterators
by Stefan Strasser 19 Mar '13

19 Mar '13

From [boost-users]: Am 18.03.2013 16:06, schrieb Jeffrey Lee Hellrung, Jr.: > On Sat, Mar 16, 2013 at 7:42 AM, Stefan Strasser <strasser(a)uni-bremen.de > is there any way to generically determine at compiletime whether an > iterator or a boost range refers to contiguous memory? > > is_contiguous<T *>::value == true > is_contiguous<vector<T>::iterator>::value == true > is_contiguous<std::list<T>::iterator>::value == false > AFAIK, not presently, but this has been discussed quite a bit in several > past threads on the Boost developers list. Then I'd like to suggest this again to the maintainers of Boost.Iterator and Boost.Range. I'd also like to suggest another addition to Boost.Range: a RangeOutputIterator, i.e. an OutputIterator that doesn't only accept single values, but assignment of ranges: template<class RangeOutputIterator> ... (...RangeOutputIterator out){ *out=range; where range can be any Boost.Range. You can find an implementation of this concept here, in the form of an back insert iterator that can insert entire ranges into a vector: http://pastebin.com/9M5rPDh9 Using these two things together can make generic algorithms as efficient as is possible, e.g. if the container that is being written to is a vector and the value type is a POD, there's one call to std::memcpy. think e.g. about file or database operations like database.get(1024*1024,out); This is in my "namespace detail" right now and I'd be willing to help make it public and document it. Stefan

2 8

Idea for O(1) hash-table
by Rani Sharoni 19 Mar '13

19 Mar '13

Hi All, I hope that you will find the following idea interesting. I have been using hash-table with, AFAICT, unique implementation and I thought that it might be handy for boost. The hash table is O(1) *non-amortized* lookup via extremely balanced buckets (for example, max 6 entries per bucket). The implementation itself is absurdly simple ;-) The hash-table is basically variation of linear addressing using double-hashing hash-table with special re-insert strategy. Algorithm for linear addressing (easy to adjust for chained hashing): Consider a two dimensional N*K array – N buckets with up to K elements per bucket. Assume that the zero-key is marking an empty entry. Lookup(key): for (hash = key, I = 0 ; I < K ;++i) { hash = HASH(hash); // double-hashing if (A[hash % N][i] == key) return found; } return not-found; Insert(key): for (hash = key, I = 0 ; I < K ;++i) { hash = HASH(hash); // double-hashing if (A[hash % N][i] == 0) { A[hash % N][i] = key; return true; } } return false; The above insert is basically a bounded double-hashing and as-is it has a low utilization (a bit similar to bloom filter). For example, for 100K buckets and K=6 - insert will fail when the table has less than 50% utilization (i.e. fail to insert though most entries are empty). The trick is to perform “re-insert”: Pick some random element, key1, from failed insert phase, replace it with the new key, and (re) Insert(key1). Retrying up to, say, 12 rounds of re-insert improves the utilization, of N=100K/K=6, to ~97%! Table resize is done (if needed) when such repetitive re-insert fails. Altogether this implementation trade-off insert for fast lookup which is very appealing to caches (i.e. insert done in the expensive path - only after a cache miss). Just for comparison, hash-table using naïve liner probing (A[HASH(key)%N][i]) has only ~80% utilization even when using K=128 (i.e. deep buckets)! Such unbalanced behavior is also typical classical hash-tables with link-lists (chained-hashing) since statistically some buckets will outgrow the average. The performance of the classic double-hashing algorithm itself is quite poor when the table is highly utilize since many steps are required to find empty entries. Though this hash-table is general purposed it has some interesting properties: 1) O(1) non-amortized with very low chance for collisions (each key has its own unique “virtual” bucket). 2) Can be implemented on continuous memory without pointers and with excellent utilization 3) Allow wait free implementation of caches (i.e. no lock or even interlocked needed). 4) Allow caches on shared memory – corruption safe/hazard algorithm (assuming at least 64 bit keys). 5) Allow persistent using direct memory to file mapping (i.e. disk representation is same as in-memory one). 6) Average 50% LRU eviction for caches (i.e. on average entry half from the oldest is evicted) BTW – there is little chance for patenting this algorithm since I already published similar idea in the public domain ;-) Thanks, Rani

4 4