December 2011 - Boost - lists.preview.boost.org

Boost.Math and Math Constants
by Paul A. Bristow 17 Dec '11

17 Dec '11

Boost.Math has always had an inconspicuous collection of useful math constants, mainly those that are used internally. The presentation of these was as a function-template, called for example, as pi<double>(). using namespace boost::math::constants; return pi<Real>() * r * r; This leads to some rather ugly equations and is most unpopular with scientific and engineering users. John Maddock has now added a new cunning feature that allows the vast majority of users who just want a built-in double to get the constants quickly as plain variables. So in non-template code, users can write using boost::math::double_constants; double area = pi * r * r; and users can read the equations easily. (Float and long double are similarly available in their own namespaces). The original mechanism which can be used for higher multiprecision user-defined floating-point types appears unchanged but has been improved to work better with UDTs and high precision types. Some draft detailed docs about just these new proposals are at http://boost-sandbox.sourceforge.net/libs/math_constants/doc/html/index.html We would like to be sure that 1 This additional mechanism of presenting constants is acceptable. 2 It is acceptable to add more constants (current new list is about 60 constants). Are there important constants that you think we have missed? Do we need a mini-review? Other views? Paul PS 1 Are there important constants that you think we have missed? 2 Please tell me of mistakes and typos in the draft docs. --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

9 24

Standard library Technical Report 2 proposals for Boost libraries
by Beman Dawes 17 Dec '11

17 Dec '11

The C++ committee hasn't decided whether to do a TR2 or to move directly on to the next standard. Either way, there will be a call for library proposals, but the details will be up in the air at least until the next meeting, which will be in Kona, Hawaii, in February. For the moment, the term "TR2" is being used as a surrogate for moving the standard library forward regardless of exact details. In discussions, library working group (LWG) members have made it clear they want a filesystem library based on Boost.Filesystem, and a networking library based on Boost Asio. Individual members of the committee have voiced interest in other Boost libraries, large and small. If you are a Boost developer (or user), and there is a Boost library you would like to see proposed for TR2, now is a good time to start thinking about writing a preliminary proposal to the committee. The point of such a proposal is to gauge interest before putting in a lot of work on a full-blown proposal only to find the LWG isn't interested. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html for the original TR2 call for proposals. While the details will change, it is still a reasonable introduction to what is required. A preliminary proposal would just say "To be supplied" for the "Proposed Text for the Standard" section. It is very helpful to do at least the initial presentation of such a proposal in person. That said, John Maddock and Peter Dimov had many proposals accepted for TR1 without ever attending a standards committee meeting. If you don't plan to present a proposal in person, the best bet is to ask someone who is familiar with the library to present it. Feel free to contact me publicly or privately with questions about proposals or information about attending committee meetings, --Beman

7 18

Slow Bugs Tracker
by Olaf van der Spek 17 Dec '11

17 Dec '11

Hi, Trac, the bugs tracker used, is really slow. Using it is a bad experience, every single time. Would it be possible to use a better bugs tracker? -- Olaf

5 14

Submitting patches
by Pedro Larroy 17 Dec '11

17 Dec '11

Hi What's the proper way to submit patches for boost trunk? Regards.

3 4

[thread] 5351 interrupt a future get boost::unknown_exception
by Vicente J. Botet Escriba 17 Dec '11

17 Dec '11

Hi, I have reached to compile the example with some variants. See the attached file in http://svn.boost.org/trac/boost/ticket/5351. It seems the problem comes from the fact that packaged_task catch every exception void do_run() { try { this->mark_finished_with_result(f()); } catch(...) { this->mark_exceptional_finish(); } } and store it to rethrow in the wait() function using boost::rethrow_exception. if(rethrow&& exception) { boost::rethrow_exception(exception); } As thread_interrupted doesn't inherits from std/boost::exception the thrown exception is translated as boost::unknown_exception. A solution could be to catch specifically thread_interrupted and store this fact. catch(thread_interrupted& it) { this->mark_interrupted_finish(); } void mark_interrupted_finish() { boost::lock_guard<boost::mutex> lock(mutex); thread_was_interrupted=true; mark_finished_internal(); } When wait is called, a test if the thread has been interrupted is done so that the exception thread_interrupted is thrown. if(rethrow && thread_was_interrupted) { throw boost::thread_interrupted(); } The single problem I see is that the this new exception doesn't contains from where the initial thread_interrupted was thrown. Could the interested parties inspect the patch attached to http://svn.boost.org/trac/boost/ticket/5351 and check it, please? Is there something I forgot or a simple or more robust way to solve this missing feature? Best, Vicente

1 1

[local] "true" lambdas without C++11 but only on GCC
by Lorenzo Caminiti 17 Dec '11

17 Dec '11

Hello all, A curiosity: On GCC compilers (but _only_ on GCC compilers) it is possible to combine Boost.Local and the non-standard GCC "expression statements" feature to implement lambda functions. In other words, it is possible to define a Boost.Local closure within a GCC expression statement: std::vector<int> v(3); v[0] = 1; v[1] = 2; v[2] = 3; int factor = 10; std::for_each(v.begin(), v.end(), LAMBDA(int x, const bind& factor) { std::cout << x * factor << std::endl; } LAMBDA_END ); This is just a curiosity because it is NOT standard C++03 and it will ONLY work with GCC compilers. #include <boost/local/function.hpp> #include <vector> #include <algorithm> #include <iostream> // WARNING: This macros only work on GCC!!! #define LAMBDA_WITH_RESULT(result_type, ...) \ ({ /* open GCC statement expression */ \ result_type BOOST_LOCAL_FUNCTION_PARAMS(__VA_ARGS__) #define LAMBDA(...) \ LAMBDA_WITH_RESULT(void, __VA_ARGS__) #define LAMBDA_END \ BOOST_LOCAL_FUNCTION_NAME(BOOST_PP_CAT(lambda, __LINE__)) \ BOOST_PP_CAT(lambda, __LINE__); \ }) /* close GCC statement expression */ int main() { std::vector<int> v(3); v[0] = 1; v[1] = 2; v[2] = 3; int factor = 10; std::for_each(v.begin(), v.end(), LAMBDA(int x, const bind& factor) { std::cout << x * factor << std::endl; } LAMBDA_END ); return 0; } I might mention this code example as a curiosity in Boost.Local docs, currently it's not mentioned there. Thanks. --Lorenzo

2 3

[log] sourceforge trunk broken with clang
by Michael Caisse 17 Dec '11

17 Dec '11

Changeset 633 fails to compile with clang. The trivial logger example in tutorial will trigger multiple errors. My guess is that simply including trivial.hpp will do the same. -- Michael Caisse Object Modeling Designs www.consultomd.com

2 1

New libraries implementing C++11 features in C++03
by Jeffrey Lee Hellrung, Jr. 17 Dec '11

17 Dec '11

Within the discussion for the review of the proposed Boost.Local library, Hartmut Kaiser raised a concern that I think should be addressed more broadly by the community, if possible. I quote Hartmut: > Ok. However this raises a more serious question. Should we as the > Boost community still encourage solutions and libraries solely for > portability with ancient compilers? I'd say no, but YMMV. Boost will > be still around 2, 5, or 10 years from now. What's the utility of > adding such a _solely_ backwards oriented library from this POV? Indeed, I ask the community, do such libraries belong in Boost? If so, is the bar for acceptance of such libraries automatically and necessarily higher than libraries that introduce genuinely new capabilities in C++11? If so, what additional criteria must such a library meet? I add two additional notes to help put the discussion in context: - Within the proposed Boost.Local review discussion, several individuals pointed out that they will likely have to work professionally on C++03 compilers for at least a few more years. - Recall that Boost has several (recent) libraries that could easily be labelled as "transitional" libraries: Move, Atomic (at least proposed, not sure if accepted), Container. Further, several older libraries are now part of the C++11 standard (e.g., Thread (right?)). - Jeff

20 45

Speeding up set and map insertion
by Tweety 16 Dec '11

16 Dec '11

Hi, I think it would speed up inserting range of elements into set and map, when in tree.hpp we replace: template <class InputIterator> void insert_equal(InputIterator first, InputIterator last) { //Insert with end hint, to achieve linear //complexity if [first, last) is ordered const_iterator end(this->cend()); for( ; first != last; ++first) this->insert_equal(end, *first); } with: template <class InputIterator> void insert_equal(InputIterator first, InputIterator last) { //Insert with hint, to achieve linear //complexity if data is even partially ordered const_iterator it(this->cend()); for( ; first != last; ++first) it = this->insert_equal(it, *first); } I will make almost linear complexity when data is ordered ascending, descending, and even partially ordered. Because when inserting with end hint (btw. wasn't here a bug? because "end" wasn't updated) it's only linear if we insert elements in ascending order.

2 1

[crc] Does anyone know who did issue #2492?
by Daryle Walker 16 Dec '11

16 Dec '11

I ask because I don't see any bug; his/her example works just fine for me. I need a complete (minimal!) program that shows the error. See more at [https://svn.boost.org/trac/boost/ticket/2492]

1 0