June 2009 - Boost - lists.boost.org

boost::test documentation typo
by Philippe Vaucher 25 Jun '09

25 Jun '09

Hi, The tutorial at http://www.boost.org/doc/libs/1_39_0/libs/test/doc/html/tutorials/new-year-… uingkeeps using BOOST_AUTO_EST_CASE when it obviously should be BOOST_AUTO_TEST_CASE. If no one replies to this mail saying he'll handle it I'll create a ticket on the trac. Philippe

1 0

Re: [boost] version conflicts: is there a solution?
by Artyom 25 Jun '09

25 Jun '09

There are many problems and this is not as simple as you think. Because if you have two versions of foo() defined in header files they may be exported and... collide. See: http://stackoverflow.com/questions/836875/ This problem is much more significant at UNIX platforms where all symbols are exported by default. Think of boost_1.38 boost/foo.hpp namespace boost { int foo() { return 1; } } boost_1.39 boost/foo.hpp namespace boost { int foo() { return 1; } } Now the library includes this header from 1.38 and automatically exports foo outside. Now, you use 1.39 and may get different values of foo(). You may do simple tests and find how bad this is. So... NO You can't use two versions of boost in same project especially at ELF platforms. ...... I just what to remind that there is a script I had written that renames boost namespace and macros preventing namespace collisions of two different versions of Boost. http://lists.boost.org/Archives/boost/2009/05/151816.php So take a look on it, and give feedback, so I would be able to submit it officially to Boost. Artyom > Having the definitions separated into different translation > units doesn't seem > to be enough to prevent ODR violations according to the > standard. It gives a > list of requirements for multiple definitions in different > translation units > in section 3.2.5. >

2 1

Linear circular buffer
by Soren Holstebroe 25 Jun '09

25 Jun '09

Hi, The boost library contains a circular buffer template by Jan Gaspar. It seems well written and STL robust, but I believe the design has some performance shortcomings in many practical usages. Every time I have used a circular buffer it has been to drag a window over a huge or real time dataset. If the dataset is non real-time and small enough to be contained in memory, there is no practical need for a circular buffer, since the window data pointer can just be dragged in memory along the full length of the dataset. In many algorithms using a dragged window, you would need to process the full length of the window for each time the window is moved. E.g. convolving signal data. Thus, you read from the window a lot more than you write. To maximize performance of your window reading and to utilize external libraries, you need linear access to the data. While Gaspar's circular buffer provide a linearize method, it requires a full reorganization of the contained data. This yields an O(N*M) efficiency, just for dragging the window (size N) over the data (size M). For internal use, the circular buffer provides iterators, but each iteration requires an internal buffer check, in order to wrap around the buffer border. Since the nature of a circular buffer in most practical scenarios (at least that I can think of) is to be involved in the processing of large amount of data, read performance is important. If you allow the internal buffer to allocate more memory than the size of the circular buffer, you can reduce the number of times you need to reorganize the internal buffer to make it linear readable. If you allocate N items more than the circular buffer size, you only need to reorganize every N+1 pushes to the window. Thus, allocating additional 100 items will reduce the reorganization overhead to 1%. I have written to Jan Gaspar, who recognizes that the buffer is not efficient for linear use, but he hasn't got the time anymore to add that feature. Is a circular buffer variant with linear access at a low maintenance cost something that would have public interest? Soren

2 1

Boost.Containers? (WAS Re: Proposal: Monotonic Containers - Comparison with boost::pool, boost::fast_pool and TBB)
by Dean Michael Berris 24 Jun '09

24 Jun '09

On Wed, Jun 24, 2009 at 10:40 AM, Christian Schladetsch<christian.schladetsch(a)gmail.com> wrote: > > What do people think of moving boost::interprocess::containers to > boost::containers? These containers are not really specific to interprocess? > I think this can easily be done through 'using' declarations: namespace boost { namespace containers { using boost::interprocess::list; using boost::interprocess::vector; /* ... */ } } I don't think it should move though to support earlier applications that are already using the interprocess namespace for the containers. -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

4 6

[range][rangex] Joining two unrelated ranges?
by Dean Michael Berris 24 Jun '09

24 Jun '09

Hi Guys, I was wondering if a utility that allows the encapsulation (and merging) of two ranges is already part of RangeEx? I was thinking along the lines of: vector<int> a, b; // populate a, populate b auto r = concat(a, b); // concatenates the ranges into a single range set<int> c(begin(r), end(r)); // r looks like a single forward range I'm not sure if this is already supported in Boost.Range and it'd be nice to know if this is already in RangeEx. TIA -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

8 12

boost::compressed_bitset
by Zachary Turner 24 Jun '09

24 Jun '09

I know there's over a zillion bitset implementations, but often times I have found myself in need of a bitset that is efficient (space-wise) at storing millions, billions, or even trillions (no joke) of bits. For this I have developed an in-house class which stores bits in a structure vaguely reminiscent of a "T-Tree" (http://en.wikipedia.org/wiki/T_tree) You can think of it basically as an std::map<boost::uint64_t, boost::uint64_t> where <key, value> represents the *interval* of bits [key, key+value-1]. So it's basically run-length encoded, with logarithmic lookups instead of linear lookups. Obviously the worst case scenario is where bits alternate 10101... throughout the entire bitset, and this structure will be terrible in that case. But where there are frequent runs of 0 and 1 bits, this gives orders of magnitude savings in space. Since a map is sorted on key, it's still a valid binary search tree and one can find the node for the k'th bit by map::lower_bound(k) and quickly check whether the bit is set by testing whether k is in [iter->first , iter->first+iter->second). The most difficult part is insertion / deletion since it involves splitting (or merging) intervals and rebalancing but the complexity is still no worse than that of a normal rebalancing avl tree. I almost exclusively use this structure in a way that interval nodes represent sequences of 1 bits, but it can just as easily be used the other way around, where intervals represent sequences of 0 bits. In fact now that I think about it probably doesn't even matter. Performing bitwise operations on such a structure is very fast. All you need to do is expand / reduce the intervals appropriately. Lookup / assignment is obviously not constant time but of course that is the tradeoff. Forward / reverse iteration is still very fast however as you only need to take the non-constant time hit once on begin(). It is also very fast to iterate only 1 bits or only 0 bits for the same reason, which can be quite slow with normal bitsets. The implementation I currently have is very unsuitable for boost for many reasons, but if there is enough interest I will (slowly) work on adapting this to be more generic / usable by a wider audience, of course with suggestions and input from the community. Zach

6 9

Re: [boost] version conflicts: is there a solution?
by Artyom 24 Jun '09

24 Jun '09

Hi, Take a look on this namespace renaming script: http://lists.boost.org/Archives/boost/2009/05/151816.php It should work, not sure about correctness of build system. I consider to submit it officially once it polished, but it seems to work. Artyom --- On Wed, 6/24/09, Lewis Hyatt <lhyatt(a)gmail.com> wrote: > From: Lewis Hyatt <lhyatt(a)gmail.com> > Subject: [boost] version conflicts: is there a solution? > To: boost(a)lists.boost.org > Date: Wednesday, June 24, 2009, 3:49 AM > Hi Everyone- > > This has been discussed before > (http://thread.gmane.org/gmane.comp.lib.boost.devel/180008) > but I think my > question is along a slightly different line so I thought I > would ask about it. > Let's say I want to compile and distribute a library > (without the source), and I > happen to use some boost header-only libraries as an > implementation detail in > some of my functions. None of the headers associated with > my library include > boost headers; it's purely an internal detail. > > Now, it seems to me that users of my library will still > have to be aware of the > fact that I used boost in my implementation -- > specifically, if they happen to > use different versions of the same boost libraries in their > code, then the ODR > is violated and the behavior is undefined. > > I realize this isn't a boost-specific problem (it would > affect any library of > template functions), but I am wondering if there is a > boost-specific solution > already worked out? Has anyone thought about this? It seems > to me that in this > case, what would be ideal would be if I could do: > > #define BOOST_NAMESPACE some_unique_namespace_for_boost > #include "boost/algorithm/string.hpp" > BOOST_NAMESPACE::shared_ptr<void> x; //or whatever > > Then I can insure there are no ODR violations and I don't > need to bother users > of my library with the fact that I used boost at all. > > Other than the sheer annoyance of having to go through all > the boost code to use > this macro, is there a strong downside to this approach? > > Alternatively, I could try: > > namespace { > #include "boost/..." > } > > But I don't know, could this work? Or are there boost > headers that rely on fully > qualified references like ::boost::algorithm::whatever? > > I'd appreciate anyone's thoughts on this issue, thanks! > > -Lewis > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Re: [boost] Proposal: Monotonic Containers - Comparison with boost::pool, boost::fast_pool and TBB
by Christian Schladetsch 24 Jun '09

24 Jun '09

> Updated tests (more of them, better formatting of results) for > https://svn.boost.org/svn/boost/sandbox/monotonic/libs/monotonic/test/compa… here > http://tinyurl.com/m83vll for GCC and here http://tinyurl.com/n9g8jv for > MSVC. I also added a column for std::allocator/mono. Have added comparison against TBB, as requested. These results are at the same location as linked to above. Christian.

7 39

Re: [boost] boost namespace
by Artyom 24 Jun '09

24 Jun '09

> I need to use two versions of boost in my > application. One the libs I link > against is statically linked against boost 1.34 and I'd > like to use 1.35's > asio library. First of all Asio comes as stand alone library outside of boost namespace. So, you may just use it as is or use namespace renaming: #ifdef USE_BOOST_ASIO #include <boost/asio.hpp> namespace netio = boost::asio; using boost::system::error_code; using boost::system::system_error; #else #include <asio.hpp> namespace netio = asio; using asio::error_code; using asio::system_error; #endif And then just relate to netio::... so you would keep an ability to upgrade to boost asio in future. This is the way I build CppCMS http://cppcms.sourceforge.net/ conditionally using Boost 1.33.1 and Asio or boost 1.35 and above only. > I believe I can make both versions > co-exist if I can manage > to rename boost 1.35's namespace to something like > boost135. > Take a look on a script I had written once: http://lists.boost.org/boost-build/2009/05/21911.php But note! boost 1.35 and 1.34 are not compatible nither ABI nor API. So you **must** not mix them in same module! This may be very tricky. So you can't use boost in interfaces between modules that use different versions of boost. Artyom

2 1

[Review Request] polygon
by Simonson, Lucanus J 24 Jun '09

24 Jun '09

Gtl was renamed to boost::polygon. The source is available at https://svn.boost.org/svn/boost/sandbox/gtl/boost/polygon/ And the documentation is at https://svn.boost.org/svn/boost/sandbox/gtl/doc/index.htm I have a review manager and a number of prospective reviewers lined up, so we should be able to at least get the review started smoothly. I would like the review wizard to contact me off list to discuss which dates are more suitable to have the review given my personal schedule. Thanks, Luke

2 4