- Boost - lists.boost.org

What happens when a Boost library is unmaintained?
by Peter Simons 02 Feb '09

02 Feb '09

Hi, suppose that an accepted and officially distributed Boost library has become unmaintained, meaning that a) the code is not developed any further, b) reported bugs are not fixed, confirmed, or otherwise responded to, and c) questions on the mailing list aren't answered, then what is the procedure to deal with that situation? Take care, Peter

4 3

Boost::Graph --- why does this program not compile?
by Oliver Kullmann 02 Feb '09

02 Feb '09

Hello, in parallel to trying to get 1_34_1 compiling again, I'll also try to understand why the code won't compile with 1_37_0. Now I found the following program which actually compiles neither with 1_34_1 nor with 1_37_0, but it should: ------------------- #include <utility> #include <vector> #include <boost/graph/adjacency_list.hpp> template <class Graph> inline Graph orthogonality_relation() { typedef std::pair<unsigned int, unsigned int> edge_type; std::vector<edge_type> ev; Graph g(ev.begin(), ev.end(), 0, 0); return g; } typedef boost::adjacency_list<boost::listS, boost::vecS, boost::undirectedS> UndirectedGraph; int main () { orthogonality_relation<UndirectedGraph>(); } ------------------- The abbreviated error-message from gcc (version 4.1.2) is: Error.cpp:17: instantiated from here Boost/1_37_0+4.1.2/include/boost-1_37_0/boost/graph/detail/adjacency_list.hpp:2113: error: invalid type argument of ‘unary *’ where line 17 is the last line of the main-function. Oliver

3 7

Re: [boost] Review process question
by Christophe Henry 02 Feb '09

02 Feb '09

> It is enough to specify which revision that is to be reviewed. Is it possible to change it after the submission request? It would allow me to make some bugfixes (if necessary) while being in the queue.

2 1

Review process question
by Christophe Henry 02 Feb '09

02 Feb '09

Hi, I just read the submission process page and being a bit new to this, I have some questions. The page states that all the files making up a library should be compressed into a zip file and posted in the Vault upon submission. - Wouldn't it be better to use the Sandbox for this? After all, this seems to be quite the goal of SVN. It would also allow bugfixes who might appear between submission and review. This leads us to the next question. - Does it mean that while the library is in the review queue, it cannot be changed? I understand this is a long process and it would be nice to correct problems which might appear during this time. It would be also sad to stop development too early. Sorry if I ask stuff which is already broadly known. Christophe

3 2

Re: [boost] [LibrariesUnderConstruction] Thanks!
by Christophe Henry 01 Feb '09

01 Feb '09

Hi Vicente, Then you are the winner of a bottle of wine. And no I will definitely not forget :) Thank you again, it was very nice from you to even look into the Msm documentation to add a description! BTW, this wiki page is very useful, great idea! Christophe

1 0

Forwarded Message: tokenizer feature request
by Kasra 01 Feb '09

01 Feb '09

Hi, what sort of hash function are you requesting? -- Kasra

1 0

test--please ignore
by Sean Farrow 01 Feb '09

01 Feb '09

1 0

tokenizer feature request
by Sean Farrow 01 Feb '09

01 Feb '09

Hi: I would like to request a hash function for tokenizer be implemented. I'm not sure how doable this is, but need to use this for a project I'm involved in. Cheers Sean.

1 0

Interest check: memoization
by James Porter 01 Feb '09

01 Feb '09

After hacking around with some simple dynamic programming, it occurred to me that it should be possible to write a simple class template to handle memoization of functions. With the changes in C++0x that help solve the forwarding problem, writing a generic memoizer should be fairly straightforward. (Or so I thought!) The interface is straightforward, so I'll let the following code snippet speak for itself: memoizer<int (int,int)> memo(my_func); int ret = memo(i,j); As you'd expect, this creates a memoizer that caches results of calls to my_func. Pretty simple, right? Well, not exactly. :) (If you'd rather not read about the implementation, you can skip ahead to the end, where there is a link to download the source.) There are a number of issues that make this a fairly complicated problem, even with the improved generic programming facilities in C++0x. Chief among these is copying. With the naive implementation of the memoizer, I found that calculating the result of an unmemoized value created 3 copies (one for creating a tuple to search a map for, and two to insert the tuple into the map), and returning a memoized value created 1 copy (to create a tuple to search the map). To make a long story short, I set about trying to reduce the number of copies to the expected amount: 1 copy for unmemoized values and 0 for memoized values. I'm happy to say that this was a success! The trick was creating a tuple that holds references to each argument and can be upgraded to hold the arguments by value. In this way, we can compare by reference and store by value. This is simple on the surface, but requires some care when dealing with rvalue references. There are also issues with passing convertible types to the memoizer (e.g. passing floats when the function expects ints). For complicated types, you certainly wouldn't want to copy them more than once, and you'd want to use move constructors where possible. This is resolved with some creative manipulation of template types (lines 52-58 of memoizer.hpp). There are still a number of things missing in this code, such as the ability to use function objects with the memoizer, or the ability to specify the map type, but I believe that the most important issues are resolved: * Minimizes copying of arguments * Supports move constructors wherever possible * Safely converts arguments to the appropriate types The full source code for this is available here (requires gcc 4.3 or a compiler that supports variadic templates and rvalue refs): http://www.teamboxel.com/misc/memoizer.tar.gz Comments and criticisms are welcome. If there's interest, I will - of course - work on a version that supports the current C++ standard. - Jim

5 21

Numeric constants
by John Maddock 01 Feb '09

01 Feb '09

Folks, someone's just filed a feature request asking for more numeric constants to be added to Boost.Math (these are currently an implementation detail, albeit a semi-documented one: http://www.boost.org/doc/libs/1_37_0/libs/math/doc/sf_and_dist/html/math_to…) but we know what troubles we had agreeing on anything last time this came up for review! Even so it appears to be time to fearlessly open up this particular can of worms again ;-) So, it appears that there is still interest, but as you know last time we tried this there was no agreement on interface, some folks felt a template interface was essential: template <class T> T pi(); leading to: template <class T> T circumference(T r) { return 2 * boost::math::constants::pi<T>() * r; } While others were absolutely adament that they wouldn't use a syntax other than: template <class T> T circumference(T r) { return 2 * pi * r; } Various attempts were made to solve this conundrum via expression templates and/or overloaded operators, but all introduced their own new issues as well, and IMO none were wholly satisfactory (not least due to the complexity introduced, a complexity that becomes all too apparent to the user if they do get a compiler error due to an unsupported use case). So.... here's what I think Paul Bristow and I might be persuaded to submit: * A library based on the existing Boost.Math code, with pi<T>() as the main interface / use case. * Possibly add constants of specific precision in alternative namespaces, so we could have: double circumference(double r) { using namspace boost::math::double_constants; return 2 * pi * r; } And that's pretty much it: no overly complex stuff, just a really simple library with a few constants in it, that makes it really easy to add new constants when required. Thoughts? Regards, John.

11 27