March 2013 - Boost - lists.preview.boost.org

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

[math] Extended float in C++ : Was : Support for libquadmath/ __float128
by Christopher Kormanyos 19 Mar '13

19 Mar '13

There has been some recent discussion on extended floating-point types in C++. >>> So the only way to add Q or q suffixes would be to find a way to query >>> the environment if it is supported. I wonder if GCC with >>> --enable-libquadmath has a kind of query for this. >> I haven't found one - gcc-4.7.2 has all sorts of __SIZEOF_XXX__ >> defines for every last type *except* >> __float128 and __float80 :-( > It won't help now, but is 'more precise types' an issue to > raise with WG21 for the next C++ standard? > Or is Multiprecision the way to go? Is there any definitive interest in adding more precise floating-point types to C++ in the next draft? Here, I am talking about floating-point types with fixed precision such as 24, 54, 113 or more binary digits, and possibly even extending beyond these to potential multiprecision types. See also Boost.Multiprecision. Consider the C language in ISO/IEC 9899:2011 (in other words C11). Extended precision is not specified, but there is a remark in Section 6.11.1: "Future standardization may include additional floating-point types, including those with greater range, precision, or both than long double." Recent specification of fixed-size integer types in C99, C11 and C++11 has drastically improved integer algorithm portability and range. Similar specification of fixed-size floating-point types could potentially improve the C++ language significantly, especially in the scientific and engineering communities. One could envision two ways to go: * Types such as float24_t, float53_t, float113_t, ... * Types such as float32_t, float64_t, float128_t, ...The first set above is intuitively coined from IEE754:2008. It is also consistent with the gist of std::uint32_t, et al --- in so far as the number of binary digits of precision is contained within the name of the data type. Is there any interest in committing to this project? Specification takes a long time and requires a coalition of collaborators. I could potentially contribute to this project as a subordinate author. But I don't feel confident enough to champion such a cause. Best regards, Chris.

2 1

Libaries accepted by not in Boost release yet - suitable for GSoC?
by Paul A. Bristow 19 Mar '13

19 Mar '13

I note there are some libraries that have been accepted but are not yet in a Boost release - and development seems to be stalled. This seems unfortunate - much effect from many people has gone into the whole process but we are not quite there yet - so a lot of work may be wasted? No doubt authors have other more pressing priorities J I spotted "Constrained value" and "endian" for example. Are any accepted but unfinished libraries suitable for Google Summer of Code students - with the task being to knock them into final shape? Is anyone willing to mentor these? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

5 5

[local_function] End scope function name declaration makes code hard to read.
by Mostafa 18 Mar '13

18 Mar '13

(This is a feature request/inquiry.) I'm just now seriously starting to use local_function, and I'm finding that having to "visually parse" until the end of scope to determine the local function name makes the code much harder to read. Is it possible to declare the function name at the beginning of the scope? (I don't mind having to also register the function name at the end of the scope.) Something like: BLF2(add, (int), (int lhs, int rhs)) { return lhs + rhs; } BLF2_REGISTER(add); Having said, I don't see why needing an "ending macro" for the local function scope is a requirement (albeit my understanding of the library internals is limited to implementation annex of the documentation). Can't the start macro just expand to something like: //----------------------------- //Macro Generated Output Start. //----------------------------- //Local class definition. //Local class instance registration. //Out of class method definition starts here: inline void local_add::body(int& sum, const int& factor, const int& num) //----------------------------- //Macro Generated Output End. //----------------------------- //User generated content starts here: { return lhs + rhs; } Thanks, Mostafa

4 8

[docs] How to install boost documentation?
by Mostafa 18 Mar '13

18 Mar '13

I'm having a real hard time trying to figure out how to install boost documentation. Can't find any instructions on boost.org nor any on google. Am I missing something really obvious?

2 3

[gil] Pixel arithmetic operations.
by Harg Tholan 18 Mar '13

18 Mar '13

Hi, Has it ever been considered to overload arithmetic operators for "pixel"? In many situations it may be useful to add, sub or divide the value of two or more pixels. Thanks.

2 1

Re: [boost] [gil] What is the status of the Gil extension numeric?
by Krzysztof Czainski 18 Mar '13

18 Mar '13

2013/2/21 Krzysztof Czainski <1czajnik(a)gmail.com> > Hello, > > During my first steps wit Boost.Gil I bumped onto an example [1], that > uses the numeric extension. For this extension, the the example [1] and a > ling from Boost.Gil docs [4] point to [2], where I couldn't find any Gil > extensions to download. Most Google links pointed to the same page, but I > finally found [3]. > > So my questions are: > a) Is there a plan to add the extension numeric to Boost? > b) Is [3] the newest version? And could the Boost.Gil docs be updated to > point to the right place? > c) I corrected a few bugs in boost/gil/extension/numeric/sampler.hpp -- is > this list the right place to discuss modifications to the numeric extension? > > Regards, > Kris > > [1] http://www.boost.org/doc/libs/1_53_0/libs/gil/example/resize.cpp > [2] http://opensource.adobe.com/gil > [3] http://code.google.com/p/gil-contributions/ > [4] http://www.boost.org/doc/libs/1_53_0/libs/gil/doc/index.html > Hello, Any word about above questions? Regards, Kris

3 14

[test] Any dependency on Boost.Test requires C++11 ?
by John Maddock 18 Mar '13

18 Mar '13

At present any test in Boost.Math that depends on Boost.Test fails for GCC prior to 4.5 because the build script for Boost.Test has: <toolset>gcc:<cxxflags>-std=gnu++0x Is this really required? It looks wrong headed to me: * We already have testers that test both C++03 and C++11 modes - so we don't need this to test C++11 support. * It's presence makes testing gcc in C++03 mode impossible if the library uses Boost.Test - so there may be C++03 breakages that we don't know about because of this. * As mentioned above, this is a hard error for GCC prior to 4.5, so those compilers can't be tested either. Can this be safely removed? Many thanks, John.

4 4