- Boost - lists.boost.org

[function] improvements/proposals
by Domagoj Saric 27 Feb '10

27 Feb '10

A while back, in various threads more or less related to the topic, I posted various ideas and/or code contributions to the effect of improving boost::function in terms of efficiency (concentrated on invocation speed, assignement performance/overhead and reducing template and RTTI bloat) and configurability, however there was no "official response" as to whether it was any good, or whether any of it would be accepted or what's wrong with it if not. IMHO the results { - 'Speed': the test presented here http://marc.info/?l=boost&m=118835709647084&w=2 modified to work with boost::signals2 (because it is a header only library/does not require a recompilation of boost if something in boost::function changes) with the dummy mutex/no threading support and a simple recompilation with the new boost::function<> code yielded a ~10% boost, changing the default policy to be nothrow the boost doubled to ~20% - 'Size': my real life project, that uses heavy metaprograming for generating function objects (that as a consequence have _very_ long type names, and thus RTTI records) to assign to boost::functions shrunk by ~10% simply by using the modified boost::function (with RTTI features disabled)...This post http://lists.boost.org/Archives/boost/2009/12/160202.php has more detailed and updated results when my project grew further (with an even bigger difference) } show/hint that there is room for improvement in boost::function and therefor warrant atleast some kind of response (even if along the lines of 'it's no good' or 'there is no time for this now')...which is the reason for (re)posting this (in a separate thread). The relevant threads with more detail are these: http://thread.gmane.org/gmane.comp.lib.boost.devel/196906 http://thread.gmane.org/gmane.comp.lib.boost.devel/194514/focus=195351 since then I've moved the modified code from the vault into the sandbox SVN (under the obvious name "function" :) -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley

6 9

Re: [boost] [Review] ITL
by Wuttke Peter 27 Feb '10

27 Feb '10

To Begin with the most important point: YES, boost::ITL should be accepted as a boost library. (Please be don't be to disappointed of my english, for i'm a developer from Germany, and this would be my first review on Boost). The ITL (interval template library) is a very valueable part of our (the Cortex Software GmbH, incidently the company i work for) daily development routine. In our industry (which is health care) sampling of Status-Informations for collections of evaluations (in time) are an essential part of our work, so we are using the ITL-Library for some years with great success. (We have to aggregate Events based on equivalent properties, eg. same admission - which diagnosis, same discharge - which diagnosis, and so on. ) . As far as I know, there is really no alternative for using the ITL do work with Intervals - I've tried is with plain SQL, and, belive me: It's possible - but really no fun - no,no,no. (I've also seen Experiments trying to implement the ITL-Solution for specific problem-domains - they aren't usefull or elegant, either. Forget them.) Until now, we only used the library for intervals of datetimes (coded as integers), but i Im sure, that its usefullness goes far beyond. Concerning the overall architecture, I think, the actual version is more than complete, I'm especially impressed withn the idea of big, sparse bitsets implmenented by the ITL - it's cool. The documentation (using samples) is clear and completly comprehensive - couldn't hope for more. So, being not a specialist in template/generics programming (or in algebraic specification), I LIKE this Library - and use it.

2 1

[random] new documentation
by Steven Watanabe 26 Feb '10

26 Feb '10

AMDG This is hopefully the final version of the work I did back in November to convert the Random docs to Quickbook/Doxygen/Boostbook. I've uploaded the generated documentation to http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/ The patch itself is rather large, even compressed, so I uploaded it to http://www.cs.hmc.edu/~swatanabe/random.patch.zip Okay to commit? In Christ, Steven Watanabe

9 19

[exception] virtual inheritance troubles
by Eric Niebler 26 Feb '10

26 Feb '10

In xpressive, I'm trying to follow the recommended use of Boost.Exception and use virtual inheritance in my exception class, regex_error. I'm also trying to hew as closely as possible to the standard, which says that regex_error should inherit from std::runtime_error. However, this simple use of Boost.Exception does not compile: #include <string> #include <exception> #include <boost/throw_exception.hpp> #include <boost/exception/exception.hpp> struct regex_error : virtual std::runtime_error , virtual boost::exception { explicit regex_error(std::string const& what) : std::runtime_error(what) {} }; int main() { boost::throw_exception(regex_error("what")); } On VC9, I get the following: > C:\boost\org\trunk\boost/exception/exception.hpp(400) : error C2512: 'std::runtime_error::runtime_error' : no appropriate default constructor available The trouble is that std::runtime_error does not have a default constructor, and that boost::throw_exception doesn't simply throw the exception passed to it; it throws an object of type of clone_impl<regex_error>. Because of the virtual inheritance, clone_impl needs to call std::runtime_error's directly, but it doesn't. It can't know to do that in general. What is the recommended practice here? <aside> It actually doesn't seem to be particularly useful in this case to use virtual inheritance because std::runtime_error inherits from std::exception non-virtually. In order to avoid the pitfall described here <http://tinyurl.com/yb2jpns>, it seems *ever* exception type in the hierarchy needs to use virtual inheritance, and that unfortunately is not the case for the standard exception hierarchy. </aside> -- Eric Niebler BoostPro Computing http://www.boostpro.com

4 6

[forward] looking for help to keep MSVC7.1 from ICEing
by Tobias Schwinger 26 Feb '10

26 Feb '10

Hello, I'm trying to make Forward release-ready and I'd really like to support MSVC 7.1 which is currently ICEing (in msc1.cpp, line 2701). According to online research that ICE typically occurs when the ODR is violated and the compiler fails to diagnose it. Although the code should be valid, it's likely to be about name management. The code uses an inheritance chain to add call operators of different arities. IOW the class template for arity N inherits from the class template for arity N-1. A 'using base::operator();' is used to pull in the base class' overloads. A stripped-down version of this pattern compiles. When I take out the 'using' declaration the ICE disappears (and so do the base class' overloads). Ideas anyone? Anyone keen enough to look into it? In case of the latter, I recommend the simpler of the two headers: trunk/boost/functional/lightweight_forward_adapter.hpp [ link to svn: http://tinyurl.com/ydoyoa4 ] Thanks, Tobias

1 0

Boost.Polygon : How to deal with per point attributes
by philippe.lamontagne.2＠ens.etsmtl.ca 26 Feb '10

26 Feb '10

Hi Boost community, I am currently experimenting with the BOOST polygon library and I have a few questions. Question 1: For my specific application the points inside the polygons need to contain attributes in addition to their x and y coordinates. This extra information is required in a per-point basis. I need to compute intersections and differences of polygons. The operations can be performed regardless on the attributes, but it's important that the attributes be present in the polygons resulting from the operations. Does BOOST provide a mechanism for keeping such per point attributes? I followed the example to make my own point and polygon classes work with BOOST, but for what I can see, the polygons operations are performed using GTL's own data types and transferred back to my types, loosing any attributes in the process. I am missing something here? Question 2: I noticed that if I have multiple points located on the same straight line only the initial and final points will be kept in the resulting polygon and that the intermediate points will be discarded. Whereas this behavior is probably preferable in the general case, it causes me a problem if I want to maintain point attributes because the attributes are not guaranteed to be the same all over the straight line. Is there a way to change this behavior? I'm aware that polygon operations may create new points. I can deal with a few empty attributes as long as original points keep their initial attributes. We hope there are some solutions or workarounds because I strongly appreciate the library. Thanks for the excellent work.

2 2

[Boost][Container] Non mandatory template parameter not defaulted
by Mathieu - 26 Feb '10

26 Feb '10

Hi, I was reading the boost.container vector sources, and I can't figure how this vector instantiations can work : boost::container::vector<int> foo; considering that the vector definition looks like : template <typename T, typename A> vector; As the second template parameter A has no default type, I believe it's actually mandatory but it's not the case as this : boost::container::vector<Type> compiles fine. I've been reading through the whole source file but I can't find where the trick is. if anyone can enlighten me? ps : sorry for my bad english..

2 2

[filesystem] 1.40 documentation refers to wrong API version?
by Johan Nilsson 26 Feb '10

26 Feb '10

Hi, the Boost.Filesystem documentation at e.g.: http://www.boost.org/doc/libs/1_40_0/libs/filesystem/doc/reference.html#Ope… seems to refer to more recent version. As a specific example, there are no overloads of remove in 1.40 that accepts an instance of boost::system::error_code (as opposed to what the documentation indicates) - easily verifiable in e.g.: http://svn.boost.org/svn/boost/tags/release/Boost_1_40_0/boost/filesystem/o… Is the actual 1.40 documentation available online somewhere? / Johan

1 0

Re: [boost] review system in place is extremely slow? (was Re: [rfc] rcpp)
by Brian Wood 26 Feb '10

26 Feb '10

Mathias Gaunard writes: >> Currently there are a lot of libraries to review, but no review managers. >> That means that the user community don't want to spend a little bit of >> their time to manage a review. >> >> In addition, the last review didn't had too much of reviewers >> (I'm also concerned by this point) > > So you can see, indeed, that this is fairly concerning. I think this may be due to economic changes. When Boost was getting started the economy was better than today. I think Boost should work on turning traffic on it's pages into advertising revenue. That money could be used to help those who want to be involved in the project. Giving a review manager $200 for 40+ hours of work only makes sense. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384

5 4

Re: [boost] review system in place is extremely slow? (was Re: [rfc] rcpp)
by Brian Wood 25 Feb '10

25 Feb '10

On 02/25/2010 11:56 AM, Nevin Liber wrote: > Then comes the "which jobs do we pay for?". If a reviewer > spends 80 hours doing a detailed review, should we pay > them too? What about all the people who tirelessly work > on getting a release out the door every quarter? Why > should they work "for free" if other people are getting paid? I thought about some of these things as well.... I think release managers should be paid as well and more than review managers. For reviewers, I would set up a system that rewarded them also. The review manager might be expected to judge who has given the best and second best reviews. It would add a little excitement to the whole process... seeing who wins the gold and silver medals. > If we don't make enough money from web advertising, you > can't just not pay the review managers. Who will make up > the deficit? Etc., etc. > The way I'd do it is to make offers based on money already collected and not based on anticipated earnings. That way you commit some income to an individual and should be able to follow through and pay them. It might take a few months before you had enough saved to begin doing this. Advertisers love to reach niche audiences, especially audiences with above average incomes. This approach would be mixed with the current approach. If there was money to pay for a review manager it would be offered. If not you would just keep going hoping some generous soul volunteers. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384

1 0