July 2012 - Boost - lists.preview.boost.org

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

[contract] C++11-like auto-functions
by Lorenzo Caminiti 02 Jul '12

02 Jul '12

Hello all, I'm thinking to expand Boost.Contract to support C++11-like auto-functions for C++03. The following macro: CONTRACT_FUNCTION( // f template( typename Left, typename Right ) auto (adding_func) ( (Left const&) left, (Right const&) right ) return(BOOT_TYPEOF_TPL(left + right)) ) { return left + right; } Would expand to something like the code below (but the main of course): #include <boost/typeof/typeof.hpp> #include <iostream> template< typename Left, typename Right > // TPARAMS(f) struct adding_func_result_123 { Left const& left; // PARAMS(f) Right const& right; // PARAMS(f) typedef BOOST_TYPEOF_TPL(left + right) // RESULT_TYPE(f) type ; }; template< typename Left, typename Right > typename adding_func_result_123<Left, Right>::type // TPARAMS(f) adding_func ( Left const& left, Right const& right ) { return left + right; } int main ( void ) { std::cout << adding_func(1, 2) << std::endl; return 0; } I got a ticket for it: https://sourceforge.net/apps/trac/contractpp/ticket/59 But I might implement it only after the Boost review... (Are C++11 auto-function really useful?) Thanks. --Lorenzo

3 2

Re: [boost] Exact Decimal library
by Andrew Robb 02 Jul '12

02 Jul '12

Message-ID: <loom.20120702T032954-809(a)post.gmane.org> Hi Andrew, Would you be able to provide a short summary of the advantages, disadvantages or significant differences of your proposal versus the boost multi-precision library or the C++ std decimal proposal? Regards, Josh. The std decimal proposal seems to centre *IEEE 754-2008 * *hardware or slow software. My proposal is simple to make accounting safer to similar to SQL (NUMERIC and DECIMAL) using all hardware (including * *IEEE 754-2008 for IBM) but also in embedded processors.* * * *I *terminal brain cancer so I want to keep these out 'there'. http://ajrobb.livejournal.com/6918.html "I have expressive dyspepsia caused by terminal grade 4 glioblastoma mutiforme brain cancer" so writing and talking are difficult. Regards, Andrew Robb

1 0

[thread/exception] trivial compile fix
by Tim Blechmann 02 Jul '12

02 Jul '12

the boost.lockfree testsuite requires the following trivial patch, which specifies the namespace for enable_if and disable_if. i've applied a similar patch to boost.parameter some time ago [1]. as it is trivial, is it ok to commit to trunk or shall i submit it to trac that the thread/exception maintainers can apply it? tim [1] https://svn.boost.org/trac/boost/changeset/75902

4 13

thread & 1.50 issues
by Tim Blechmann 02 Jul '12

02 Jul '12

i came across two issues of boost.thread in 1.50. the first is a minor issue: the 1.50 tarball contains a libs/thread/src/shared_mutex.cpp source file, which includes boost/thread/v2/shared_mutex.hpp, which does not exist. by default it is not built, so it is not a big problem, but it is not really clean, either. the second issue is a bit more severe, as it is an undocumented API change: boost::TIME_UTC has been renamed to boost::TIME_UTC_ ... not sure what's the reason for it, but it breaks code that used the old symbol. this includes the boost-style threadpool library [1] ... so i wonder, is this change really needed? tim [1] http://threadpool.sourceforge.net

2 2