- Boost - lists.boost.org

Large Integer Library
by Michael Tryhorn 03 Jul '12

03 Jul '12

Dear Boosters, I have written a Boost-compatible library for the representation and manipulation of integers of large or arbitrary size (including 128bit and above). I would like to make a preliminary submission of this library for your review and input, for potential inclusion into Boost v1.51.0 or later, as per the Boost Library Submission Process. The library and all its files are publicly available on github, at: http://github.com/mjtryhorn/Boost.LargeInt A tagged .zip of these files (v1.0.0) is available for download at: http://github.com/mjtryhorn/Boost.LargeInt/tags This library has been written for strict conformance to C++03 and the Boost coding guidelines. This library is also header-only, and as such may be directly merged into existing Boost installations without the need for recompilation. All files are distributed under the Boost Software License, Version 1.0. Now a quick explanation of why I've written this library and what it does: I have found myself on several occasions to be working with unsigned 64bit numbers, mostly for the sizes of files or C++ collections. Where I had a need to perform a calculation upon those numbers, there was often the possibility of overflow. 128bit integers would have been an appropriate fix, but these are either entirely unavailable, non-portable, or in a library which I preferred not to use either due to its complexity or incompatible licensing. Floating-point arithmetic is also a means around the problem, but is inherently inaccurate. I decided to fix this problem once-and-for-all by writing a new integer arithmetic library, making judicious use of C++'s template-metaprogramming and Boost to make my solution both as simple and as transparent as possible. Now, what started out as 128bit integers for my own use has grown into a fully- functional library which has the ability to compose any two integer or integer- like types into a new, larger, signed or unsigned integer type, including all the standard integral operators and a number of utility functions to support them. Thus, Boost.LargeInt supports not only signed and unsigned 128bit integer arithmetic but 24bit, 64bit, 160bit, 192bit, 256bit, 512bit and more. Boost.LargeInt is compatible and has been tested with the following compilers and platforms: GNU GCC 4.6.1, 4.6.2 (Linux, Ubuntu 11.10 (64bit) & openSUSE 12.1 (32bit)) Borland C++ 5.6.4 (Windows XP SP3, Borland C++ Builder 6) Microsoft Visual C++ 2010 (Windows XP SP3, Microsoft Visual Studio 2010) (I have also tried to add compatibility for Microsoft Visual C++ 6, but unfortunately this compiler's support for template-metaprogramming is insufficient and the tests for Boost.LargeInt fail to compile.) Documentation is included in BoostBook format (.qbk), but a pre-compiled version is available alongside the library code itself for your convenience. Please, if you have the time, download this library and give it a try. Any comments, or information upon its compatibility (or lack thereof) with compilers which are or are not listed would be greatly appreciated. If no-one has any comments (I think that unlikely ;-) ), then I shall resubmit this library for formal review. Thanks, Michael J. Tryhorn

9 20

CRC 16 Bit Implementation
by GAURAV GUPTA 03 Jul '12

03 Jul '12

Hi, In my application I need to use crc_64_type. I did not find its implemetation in crc.hpp. Anyone implemented it? -- Regards, Gaurav

2 1

[range] treating N-ary function with N-1 default args as unary
by Nathan Ridge 03 Jul '12

03 Jul '12

Hi, Some Boost.Range adaptors, such as 'transformed' or 'filtered', require a unary function. The documentation does not formally define "unary function", but it's pretty clear what it ought to be: a function (object) that's callable with one argument. Thus, to me, the following is a perfectly valid unary function: int foo(int a, int b = 0); as it is callable with one argument. However, Boost.Range does not accept such a function as an argument to 'transformed' or 'filtered'. For example, the following code: #include <boost/range/adaptor/transformed.hpp> int foo(int a, int b = 0); int main() { int A[5]; A | boost::adaptors::transformed(foo); } produces the following compiler errors (recent Boost trunk, with GCC 4.7): In file included from boost/preprocessor/iteration/detail/iter/forward1.hpp:52:0, from boost/utility/result_of.hpp:113, from boost/iterator/transform_iterator.hpp:23, from boost/range/adaptor/transformed.hpp:16, from test.cpp:1: boost/utility/detail/result_of_iterate.hpp: In instantiation of 'struct boost::detail::cpp0x_result_of_impl<int (* const(int&))(int, int)>': boost/utility/detail/result_of_iterate.hpp:46:8: required from 'struct boost::result_of<int (* const(int&))(int, int)>' boost/mpl/eval_if.hpp:38:31: required from 'struct boost::mpl::eval_if<boost::is_same<boost::use_default, boost::use_default>, boost::result_of<int (* const(int&))(int, int)>, boost::mpl::identity<boost::use_default> >' boost/iterator/iterator_adaptor.hpp:160:12: required from 'struct boost::detail::ia_dflt_help<boost::use_default, boost::result_of<int (* const(int&))(int, int)> >' boost/iterator/transform_iterator.hpp:50:17: required from 'struct boost::detail::transform_iterator_base<int (*)(int, int), int*, boost::use_default, boost::use_default>' c++/4.7.0/bits/stl_iterator_base_types.h:143:1: recursively required from 'constexpr const bool std::__has_iterator_category_helper<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >::value' c++/4.7.0/bits/stl_iterator_base_types.h:143:1: required from 'struct std::__has_iterator_category<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' c++/4.7.0/bits/stl_iterator_base_types.h:160:12: required from 'struct std::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/detail/iterator.hpp:81:8: required from 'struct boost::detail::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/iterator/iterator_traits.hpp:30:75: required from 'struct boost::iterator_value<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/iterator_range_core.hpp:139:49: required from 'class boost::iterator_range<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/adaptor/transformed.hpp:25:16: required from 'struct boost::range_detail::transformed_range<int (*)(int, int), int [5]>' test.cpp:8:41: required from here boost/utility/detail/result_of_iterate.hpp:69:5: error: too few arguments to function In file included from boost/range/iterator_range_core.hpp:22:0, from boost/range/iterator_range.hpp:13, from boost/range/adaptor/transformed.hpp:15, from test.cpp:1: boost/iterator/iterator_traits.hpp: In instantiation of 'struct boost::iterator_value<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >': boost/range/iterator_range_core.hpp:139:49: required from 'class boost::iterator_range<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/adaptor/transformed.hpp:25:16: required from 'struct boost::range_detail::transformed_range<int (*)(int, int), int [5]>' test.cpp:8:41: required from here boost/iterator/iterator_traits.hpp:30:75: error: no type named 'value_type' in 'struct boost::detail::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/iterator/iterator_traits.hpp: In instantiation of 'struct boost::iterator_difference<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >': boost/range/iterator_range_core.hpp:143:54: required from 'class boost::iterator_range<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/adaptor/transformed.hpp:25:16: required from 'struct boost::range_detail::transformed_range<int (*)(int, int), int [5]>' test.cpp:8:41: required from here boost/iterator/iterator_traits.hpp:49:80: error: no type named 'difference_type' in 'struct boost::detail::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/iterator/iterator_traits.hpp: In instantiation of 'struct boost::iterator_reference<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >': boost/range/iterator_range_core.hpp:157:53: required from 'class boost::iterator_range<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/adaptor/transformed.hpp:25:16: required from 'struct boost::range_detail::transformed_range<int (*)(int, int), int [5]>' test.cpp:8:41: required from here boost/iterator/iterator_traits.hpp:36:74: error: no type named 'reference' in 'struct boost::detail::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' Would it be possible to treat N-ary functions with N-1 default arguments as unary? Thanks, Nate

6 8

[Trac] New components
by Daniel James 03 Jul '12

03 Jul '12

Hello, Please can someone with the appropriate trac permissions add two new components "functional/overloaded function" and "local function", both have maintainer "lcaminiti". Maybe also "utility/identity type", or does that come under "utility"? thanks, Daniel

3 4

Thread (win32) and current_thread_tls_key issues
by Pekka Seppänen 03 Jul '12

03 Jul '12

Hi, Currently Threads's Win32 TLS implementation uses a global static variable thread::current_thread_tls_key that is defined in src/win32/thread.cpp. As you may know, static variables have a tendency of not being allocated in a very specific order. Say, that you have a statically allocated class A that ends up calling thread::set_current_thread_data() (eg. uses thread::thread_specific_ptr). If compiler initializes this class before it initializes current_thread_tls_key (this did happen to me on MSVC9) things go boom: a) Compiler initializes class A, thread::set_current_thread_data() is called, thread::create_current_thread_tls_key() is called once (as expected) and ::TlsAlloc() result is stored to thread::current_thread_tls_key. b) Compiler initializes thread::current_thread_tls_key, TLS_OUT_OF_INDEXES is stored and, as you may guess, c) Any following thread::set_current_thread_data calls will fail as the proper result from ::TlsAlloc() was overwritten. Don't know why this haven't happened before, as previous versions use a static variable, too. Maybe some compilers (MSVC in this case) omit initialization code unless initial value is a non-zero (as with TLS_OUT_OF_INDEXES [0xffffffff] in this case) value. I propose that thread::current_thread_tls_key is moved to a static function that sole purpose is to return reference to that variable (and thus ensure that current_thread_tls_key is initialized before it is used for the first time). Also, move thread::current_thread_tls_init_flag to thread::set_current_thread_data() to make sure this won't happen to that, too. Attached a patch that does the above trick (did move TLS_OUT_OF_INDEXES back to a macro as otherwise the code got too cumbersome, does get undef'd unless it was already defined by Winapi). If you like it, I can submit a ticket to Trac that includes the patch. (Haven't looked what happens during destruction, but guess it's not safe to use TLS features thru Thread.) -- Pekka

4 8

memcpy handling bug in regex_raw_buffer.cpp
by GAURAV GUPTA 03 Jul '12

03 Jul '12

Can anyone verify and commit the following Ticket: https://svn.boost.org/trac/boost/ticket/7032 -- Regards, Gaurav

2 1

Does Boost.Pool have a maintainer ?
by DUPUIS Etienne 03 Jul '12

03 Jul '12

Greetings, Does Boost.Pool have a maintainer ? If no, what happens in that case, who decides to include bug fixes for open bugs ? If there is no maintainer, can I become the maintainer ? If the answer to the latter question is yes, can someone volunteer to be my "mentor" to help me with issues related to the way boost development work ? I have already fixed pool bugs in the sandbox and added related test programs. Regards, Étienne Dupuis Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Si vous avez reçu ce message par erreur, merci de nous en avertir immédiatement. ATEME décline toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou encore édité ou diffusé sans autorisation. This message and any attachments are confidential and intended solely for the addressees. Any unauthorized modification, edition, use or dissemination is prohibited. If you have received this message by mistake, please notify us immediately. ATEME decline all responsibility for this message if it has been altered, deformed, falsified or even edited or disseminated without authorization. Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments.

2 2

Priority Deque Container Adaptor
by Nathaniel McClatchey 03 Jul '12

03 Jul '12

Greetings. I have written a container adaptor implementing efficient double-ended priority queues. This preliminary submission is made to determine if/when a formal submission should be made and in the hope that it will be improved by your comments and reviews. The library (a single header file) is publicly available on mediafire: http://www.mediafire.com/download.php?gq8qjpgdoecgqq2 All files are distributed under the Boost Software License, Version 1.0. An explanation of what it does: This library replicates all functions of the STL priority_queue and adds functions for efficient access to the other end of the queue. Where the STL priority_queue uses a max-heap, I use a max-min heap (see article on Wikipedia). This leads to O(log n) complexity for single-element operations, and O(n) complexity for initialization and merging. TL;DR: Double-ended priority queue with algorithmic complexity equaling the STL single-ended priority queue. The current revision has been tested on: GCC 4.7.0 (MinGW on Windows 7 x64) Microsoft Visual C++ 2010 (on Windows 7 x64) Documentation may be generated by Doxygen. Any comments, criticisms, or compatibility information will be appreciated. I currently have one decision to make that requires experience beyond mine. Some const functions require calling operator() in a comparison class; should I make the class mutable, make a non-cost copy of the comparison class when needed, or require that operator() be a const function? So far, I have avoided the last option because it would make the class prerequisites more strict. Thanks, Nathaniel McClatchey

1 0

[1.51.0] Open for merging
by Daniel James 02 Jul '12

02 Jul '12

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging *does not* require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: http://svn.boost.org/trac/boost/wiki/ReleaseSchedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Release Managers, Beman Dawes Daniel James Eric Niebler Marshall Clow Rene Rivera Vladimir Prus

1 0

Is there a macro to test if std::numerc_limits<>::max_digits10 is supported by a platform?
by Paul A. Bristow 02 Jul '12

02 Jul '12

A proposed (but not reverted) fix for Trac #5758: Boost.Test Floating-point comparison diagnostic output does not support radix 10 if( std::numeric_limits<T>::is_specialized && std::numeric_limits<T>::radix == 10 ) ostr.precision( 2 + std::numeric_limits<T>::max_digits10); // Assume that max_digits10 is provided for all radix 10 as they are quite new, // and anyway Kahan formula will not work for decimal. has caused trouble on platforms that do not yet support std::numeric_limits<T>::max_digits10 We need a macro perhaps BOOST_NO_NUMERIC_LIMITS_ MAX_DIGITS10 that will prevent the compiler seeing this code if max_digits10 is not supported. Do I need to add a default for all compilers # define BOOST_NO_NUMERIC_LIMITS_ MAX_DIGITS10 and then undefine for compilers that DO support #if defined (_MSC_VER >=1600) || (... other compilers that DO support) # undef BOOST_NO_NUMERIC_LIMITS_ MAX_DIGITS10 #endif Can anyone advise compiler versions or library versions that DO support max_digits10? Suggestions? Paul PS maxdigits10 will become more useful generally as the wrong value in float in MSVC 2011 seems to be corrected in Microsoft Visual Studio Ultimate 2012 RC 11.0.50522.1 --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

3 4