- Boost - lists.boost.org

Interest in Devector implementation?
by christopher hopman 28 Nov '09

28 Nov '09

So, I have been working on a devector implementation for the last week or so (see https://svn.boost.org/trac/boost/wiki/soc2009#Boost.Devector) There is some stuff that still needs to be done, and some testing that is still needed, but I thought I would check if there was interest in such a thing. The implementation is basically a standard deque implementation with one addition. That is, there can be allocated "chunks" both before and after those in use. This leads to a couple of advantages for users. First, in many use cases, devector is faster than deque because it will have less allocations. For example, when used strictly as a queue, the regular deque has a number of chunk allocations linear in the total number of elements inserted in the queue, devector has allocation linear in the maximum elements in the deque at one time. When used as a stack, a particularly bad case can occur with a normal deque implementation, the case where the top of the stack switches back and forth between two chunks. Second, this allows users of devector to reserve space on either side of the structure. This does not give the same efficiency boost as vector::reserve, but, possibly more important, it allows for stronger exception guarantees and for better guarantees about when iterators are invalidated. Another benefit of devector is that chunk size is not a compile time constant. In fact, chunk size is not even required to be constant over the lifetime of a given devector. Also, devector iterators allow lower level access than std::deque as described by Matt Austern ( http://lafstern.org/matt/segmented.pdf) Support for in-place construction (described at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2212.html) will become available with c++0x's emplace_back(). Though I expected that std::deque would have a slight performance advantage due to its compile-time constant chunk_size, early tests have actually shown devector to have a slight advantage even in cases where it has no advantage from not deallocating unused blocks. My guess is that this is due to std::deque needing to do more work to maintain its invariants in the face of exceptions. Again though, that is just some simple early testing that I did. The current implementation does not actually allow changing chunk_size (though this is actually a matter of like 5 LOC), nor does it give the segmented iterator access (again a simple addition). Code is available at http://pages.cs.wisc.edu/~hopman/devector/ (along with code that tests most of the std::deque interface). -Chris Hopman

1 0

[serialization] polymorphic archives + boost_class_export generates linker errors
by Christoph Heindl 28 Nov '09

28 Nov '09

Hi, I've posted this with no luck to the boost-users mailing list: the attached example [1] generates a couple of linker [2] errors on msvc 9.0 / boost 1.40.0 all related to missing archive_serializer_map symbols. when switching from polymorphic archives to corresponding non-polymorphic archives the attached example runs fine. It seems that the usage of BOOST_CLASS_EXPORT in conjunction with polymorphic archives triggers the linker error. I tried to add explicit template instantiations, such as [3], for the missing types to boost archive, recompiled boost and was able to get rid of the linker error. The problem then, however, is that the example fails at runtime with an assertion that a type-lookup did not succeed. So I guess adding the explicit template instantiations was not the correct approach. Is this a bug? Can anyone confirm this issue? Best regards, Christoph

4 10

[random] documentation rewrite
by Steven Watanabe 28 Nov '09

28 Nov '09

AMDG I'm in the process of updating the Boost.Random documentation. I've put what I have right now at: http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/ The content is mostly the same as the current docs, although I've filled in some missing pieces and fixed some of the more egregious out of date docs. Any comments, criticism, etc, are welcome. In Christ, Steven Watanabe

5 10

Re: [boost] Boost.Array Maintainer
by raindog＠macrohmasheen.com 27 Nov '09

27 Nov '09

*top post* I think that it should be acceptable for other people to have the authority to submit patches and have them reviewed by other people and as long as they submit high quality code there should be the expectation that the code gets merged by someone who has the rights to do so. Look at other open source projects for ideas *end too post* ------Original Message------ From: Vicente Botet Escriba Sender: boost-bounces(a)lists.boost.org To: boost(a)lists.boost.org ReplyTo: boost(a)lists.boost.org Subject: Re: [boost] Boost.Array Maintainer Sent: Nov 27, 2009 7:58 AM John Maddock wrote: > >>> Question: does someone have to be a maintainer of an existing library >>> (or author of one of the accepted libraries) to become a maintainer of >>> an existing (orphaned?) library? >> >> This is a very interesting question. Some lingering tickets with patch >> could be cleared faster if soem orphaned components of bosot were >> assignated new manager. > > Indeed. Something that occurred to me earlier was "how many tickets were > looked at in the last sprint, assigned a patch, but haven't been looked at > since?" That would be a good test of the owner being missing-in-action! > > Re Boost.Array, I seem to remember Alisdair Meredith taking this on, I'm > cc'ing him just in case my memory isn't what it once was ! ;-) > > It seems to me though that the bug sprints would be a good opportunity to > widen the maintainer list a little - what if we assigned an interested > volunteer to act as temporary maintainer for an orphan library during the > sprint. (S)he fixes whatever they can fix, then gets another bug sprint > volunteer to review the changes, if all looks well, and the tests are all > passing on Trunk, only then merge to release. > > Thoughts? John. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > Hi, I don't know if this is the best way, but it is clear that we have a problem with very old tickets. It will be great to identify the libraries that will need this kind of help, and make a call for volunteers. Best, Vicente -- View this message in context: http://old.nabble.com/Boost.Array-Maintainer-tp26534655p26544289.html Sent from the Boost - Dev mailing list archive at Nabble.com. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Sent from my Verizon Wireless BlackBerry

1 0

warning policy issue
by Robert Ramey 27 Nov '09

27 Nov '09

On page https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines#warn… it's suggested that the following warning at level 4 can be eliminated with a static cast warning C4244: 'argument' : conversion from <type1> to <type2> possible loss of data I've found this not to be true at least with msvc 7.1 Robert Ramey

5 9

Removing LEDA adaptors from Boost.Graph
by Jeremiah Willcock 27 Nov '09

27 Nov '09

Are there any users who are using the LEDA interfaces to Boost.Graph? There are several tickets filed against them but the tickets are all years old. Is it safe to remove them? Do they need a deprecation period first? -- Jeremiah Willcock

2 2

[LibrariesUnderConstruction]Mirror - update
by Matus Chochlik 27 Nov '09

27 Nov '09

Hi, I would like to ask the admins to update the info about the Mirror library on the LibrariesUnderConstruction page in particular to add the links to the C++0x version of Mirror on sourceforce: http://sourceforge.net/projects/mirror-lib/ and to add a link to the online docs for the C++0x version: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/ TIA ________________ ::matus_chochlik

2 2

[LibrariesUnderConstruction] Boost.Numeric_Bindings
by Rutger ter Borg 27 Nov '09

27 Nov '09

Hello all, I see the Numeric_Bindings library is missing on the LibrariesUnderConstruction trac page. This library is under development since 2002. Herewith a short description of the library. Boost.Numeric_Bindings is a C++ library for numeric computing. It is a generic layer between data containers and linear algebra algorithms. For the data container part, it supports both compile-time statically sized and run-time dynamically sized vectors, matrices, through a traits system. Currently it includes traits for C-arrays, for standard vectors, for uBLAS' containers, Eigen containers, TNT, Boost.Array, to name a few. It offers compile-time inspection, iterators, and views on all mentioned containers. For the algorithm part, it provides a C++ interface to algorithms offered by BLAS, LAPACK, and more. This covers algorithms from most vendor-provided math libraries, such as the reference BLAS, ATLAS, Intel's MKL, AMD's CML, NVidia's CUDA, etc.. The "stable" release is available at http://svn.boost.org/svn/boost/sandbox/numeric_bindings-v1/ The current development version is available at http://svn.boost.org/svn/boost/sandbox/numeric_bindings/ Questions and/or comments are welcomed. Thanks, Rutger

3 4

Compiler warnings from Macs, IBM acc, Borland, Comeau, Metroworks, et al - are they a Problem?
by Paul A. Bristow 27 Nov '09

27 Nov '09

https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines (bottom of the page) has a collection of suggestions for 'quieting' warnings on MSVC and GCC, but no information on other compilers yet. Can users of these compilers please 1 Assert that they never have a problem with unhelpful compiler warnings from Boost stuff, or 2 Send common warnings and suggestions for dealing with them by suppressing or by 'fixing' the code (so that I can add to the guidelines. Thanks Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

1 0

Boost.Array Maintainer
by Dean Michael Berris 27 Nov '09

27 Nov '09

Good day everyone, Does anybody already maintain Boost.Array? I see quite a number of patches and "todo" tickets and am wondering whether someone should be taking care of such a crucial piece of the collection. If there isn't anybody willing to maintain Boost.Array I don't mind looking after it until someone else does. Question: does someone have to be a maintainer of an existing library (or author of one of the accepted libraries) to become a maintainer of an existing (orphaned?) library? HTH -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

6 6