June 2012 - Boost - lists.boost.org

Still a monolithic library? Or a bunch of independent ones?
by hello world 21 Jun '12

21 Jun '12

Hello, It's been a few years since I didn't come around boost.org, and I was just wondering... Is boost still a monolithic library? or Is it a collection of separate libraries now? Or to state it another way: Is it ``easy'' to take only one library's files from the boost distribution and use it. Or do I have to carry everything around even If I'm using just one library? I understand that this must be library specific, but I'm just asking this to know what your general feel overall. Thanks.

3 2

Interest in a "breadth first" algorithm?
by Gary Powell 21 Jun '12

21 Jun '12

A while ago I needed to serialize and de-serialize a std::map and I realized that the only interface was begin(), end() which of course meant that re-creating this same map was the least efficient way possible, as all the elements were added in sorted order. Because I wrote them out using begin() -> end() So I wrote a breadth first template which takes a container, a template to use as the core of a queue, a template for the allocator, the container and a function to apply to the elements. It doesn't quite do a true breadth first traversal because I don't look at the inner data structure of the map, (works with sets as well) but instead does a middle, then right, left push until it's hit all of the nodes. And it doesn't copy the elements, it pushes the iterators, and calls the function on that iterator when the length is 1. It ended up speeding up my map recreation by about 20% (because I start with a center enough node that it should never have to be rebalanced) at a cost of about 5% to write it this way (It's more expensive to create the queue, and traverse the map from center on out), for a roughly 15% gain in speed. Is there any interest this for boost? I've got working code but not any documentation. And rather than spend a huge amount of time on that I'm looking to see if anyone else has an interest in this. -Gary- -- ------------------ powellg(a)gmail.com "Come gather 'round people wherever you roam. And admit that the waters around you have grown. And accept it that soon you'll be drenched to the bone. If your time to you is worth savin'. Ahh you better start swimmin' or you'll sink like a stone. For the times they are a-changin'" Bob Dylan

4 4

Integrating CUDA nvcc into bjam
by jombi01821 21 Jun '12

21 Jun '12

I would like to know how to take an existing project that build with bjam and have it understand how to handle .cu CUDA files -- View this message in context: http://boost.2283326.n4.nabble.com/Integrating-CUDA-nvcc-into-bjam-tp463163… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[1.50] Is it too late for fixes?
by John Maddock 21 Jun '12

21 Jun '12

I have a trivial fix for 1.50 if it's not too late (missing include guards on a header), see https://svn.boost.org/trac/boost/ticket/7001 Is it too late now, suspect it is? Thanks, John.

1 0

[exception] gcc 4.7 non-virtual destructor warning
by Daniel Larimer 21 Jun '12

21 Jun '12

/usr/local/include/boost/checked_delete.hpp:34:5: warning: deleting object of polymorphic class type 'boost::error_info<boost::tag_original_exception_type, const std::type_info*>' which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] Is there a reason why the destructor isn't virtual? This only shows up when I compile with -Wall, which I like to do because it catches many important errors. Unfortunately, if I have to filter out boost warnings it makes it less effective.. particularly when the warning is actually about 30 lines long in my console. Dan

3 3

[release] merge request for test fix
by Jürgen Hunold 20 Jun '12

20 Jun '12

Hi, I would like to merge r78972 to the release branch. It fixes some test failures introduced by 78802 which renamed UTC_TIME to UTC_TIME_. Trunk tests have cycled for 2 days and the interprocress results start to turn green. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 2

hex/unhex()?
by Olaf van der Spek 19 Jun '12

19 Jun '12

Hi, Does Boost have hex/unhex() that support std::string? I can't find them and I think they'd be quite handy to have. -- Olaf

7 35

[svn] post commit hooks broken
by Jürgen Hunold 19 Jun '12

19 Jun '12

Hi, the subversion post commit hooks seem to be broken. The last commit mail I got is Author: garcia Date: 2012-06-07 16:20:43 EDT (Thu, 07 Jun 2012) New Revision: 78856 and there habe been numerous commits since. I have also checked in a followoup to r78802 yesterday, which should have triggered an automated trac entry for #6940. But nothing happens. Can someone with enough karma please take a look at this? As a sidenote: The inofficial git mirror seems stalled, too. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 2

[Locale] VC11 Regressions
by Joshua Boyce 19 Jun '12

19 Jun '12

I am currently porting some code to the VC11 compiler beta, and as part of that process I ran the unit tests on the libraries I use and noticed some failures in Boost.Locale under VC11 that are not present under VC10. Ones of the tests (test_winapi_collate) actually crashes (showing the WER dialog etc). Logs for comparison (tests were run on trunk): http://dl.dropbox.com/u/74751/cpp/boost/logs/locale-test-vc10-20120330-2143… http://dl.dropbox.com/u/74751/cpp/boost/logs/locale-test-vc11-20120330-2143… Has anyone else observed this or is it a configuration issue on my end?

4 11

Multiprecision vs. xint
by Phil Endecott 18 Jun '12

18 Jun '12

Dear All, I'd like to encourage people who are looking at the proposed Multiprecision library to remind themselves of the xint review last year. See e.g. http://thread.gmane.org/gmane.comp.lib.boost.devel/218624 (result) http://thread.gmane.org/gmane.comp.lib.boost.devel/215968 (my review) etc. etc. To what extent do we believe that this new library addresses the weaknesses of the last proposal? It would be great if Vladimir Prus, review manager for xint, could write a review of Multiprecision. Here's my take on it: Multiprecision addresses many of the problems of xint, and also extends the scope into areas that xint did not address at all. However it still suffers some of the same problems: if I want an int128_t that is just 128 bits of data, it doesn't help me. Furthermore, it doesn't help me to build the int128_t that I want. Although Multiprecision is divided into "front" and "back"-ends, this division is not in the right place to let me substitute my own backend that just provides the 128 bits of storage. In the xint reviews, we suggested that the algorithms should be decoupled from the data structures and the same applies here. Similarly, this implementation doesn't provide hooks that would allow me to substitute e.g. assembler implementations of the algorithms. Regards, Phil.

5 9