- Boost - lists.boost.org

Re: [boost] Core libraries should separated from experimental libraries
by Tom Brinkman 21 Nov '09

21 Nov '09

C++ is an for expert system and "boost" is a place for the most advanced users of c++ to share experiences. If you don't agree with that basic statement, we don't have much to talk about. I know that calling some one "average" at a particular skill is a loaded statement. It implies a sense of superiority that is uncomfortable to some. However, "average" only comes with a great deal of practice and hard work. Most of us, only ever become average at a handful of things in our life, if we are lucky. Actually, calling someone average at something is highly complimentary. If you are uncomfortable with the term "average", take your sensibilities elsewhere. No back to the issue at hand: Boost needs to separate out the core libraries from the experimental libraries. The libraries within boost that have stable api's should separated from those that don't. Boost needs a system similar to debains. People need to know what parts of boost are backwards compatible. At the same time, we need to allow for complete interface changes to the experimental libraries, to encourage and nurture those libraries that are still in active development, but still very usable. I don't see this as a difficult issue to comprehend at all. Its quite surprising to me that it gets so much push back. This is the single reason why so many people are so resistant to using boost. Hopefully somebody will take up this issue, as I fear without it, boost will become trivialized after the next release of the c++ standard. I'm just saying what people are thinking in the trenches. >From my perspective, as the former review wizard, and long time follower of boost, the current situation of having a dozen libraries in the queue, and probably a dozen more waiting behind the scenes is unacceptable. If we distributed those libraries currently waiting to be reviewed as part of the non-stable part of boost, we could be much more liberal about what libraries get accepted. The important review would then be determining when a library is going to be switched from the non-stable to the stable portion of boost. Tom Brinkman

2 1

[ANN] Elements of Programming study group
by David Abrahams 21 Nov '09

21 Nov '09

FYI, over at http://cpp-next.com we're running a study group on the new book by Alex Stepanov & Paul McJones that might be of interest to generic library authors and users.

2 1

[Ticket #3548] Comeau C++ reports global scope has no int64_t
by Mateusz Loskot 21 Nov '09

21 Nov '09

Hi, I've been trying to diagnose and fix the problem with missing definition of int64_t and uint64_t when using Comeau C/C++ frontend on Linux 32-bit with GCC 4.x. I submitted all details to the Trac: https://svn.boost.org/trac/boost/ticket/3548 Shortly, the problem is that if <sys/types.h> header is included then <boost/cstdint.hpp> can't import uint64_t/int64_t types. However, if <stdint.h> is used, everything works. 1) Does compile with Comeau + GCC #include <boost/cstdint.hpp> int main() { boost::int64_t a(0); } 2) 1) Does compile with Comeau + GCC as well #include <stdint.h> #include <boost/cstdint.hpp> int main() { boost::int64_t a(0); } 3) Does not compile with Comeau + GCC #include <sys/types.h> #include <boost/cstdint.hpp> int main() { boost::int64_t a(0); } What I found is that there are slight differences, in GNU C Library, in how those integer types are defined: 1) <sys/types.h> # elif __GLIBC_HAVE_LONG_LONG __extension__ typedef long long int int64_t; # endif 2) <stdint.h> # else __extension__ typedef long long int int64_t; # endif More details are in the #3548 ticket report. Shortly, sys/types.h vs stdint.h are somewhat competing and seem to confuse <boost/cstdint.hpp> definitions. Both headers define __int8_t what disables the other definitions, thus depending on which header goes first, that one wins but with different effect regarding int64_t type. I exchanged a few e-mails with Comeau team about it and, as for this moment, we've concluded this slight differences between the two headers seem a bit odd and competing indeed. Comeau team has been very helpful and they are willing to make further investigation of this problem. In the meantime, I decided to report this issue to GNU C Library bugzilla (I should send to their mailing list first, my mistake): http://sourceware.org/bugzilla/show_bug.cgi?id=10990 Ulrich Drepper confirmed that this is not GNU C Library issue: "stdint.h is a C99 header and C99 demands the implementation of long long. The headers are correct." Fair enough. However, it makes it more difficult to me to understand where fixes should go. So, I'd like to ask the Community here for help in diagnosing this problem. My thought for now is that if Boost Integer is used with Comeau C/C++ frontend with GCC, Boost configuration could detect if <sys/types.h> was included first and try to disable its effects, like undefine __int8_t and only let int64_t and uint64_t definitions from <stdint.h> header. I believe that solving this problem is quite important to make Boost compilable with Comeau C/C++ frontend, because, as far as I've tested, it mostly leaks when compiling Boost.Test and tests of Boost libraries. I'd be thankful for any thoughts on this. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

1 0

Status of Comeau toolset for upcoming 1.41.0
by Mateusz Loskot 21 Nov '09

21 Nov '09

Hi, Recently, I've reported [1] issues [2] related to building with Comeau toolset. The upcoming release info [3] does not mention Comeau toolset. May I ask what's the status of support of Comeau? Is it safe to assume Boost 1.41.0 will be usable with Comeau C/C++ ? [1] http://lists.boost.org/Archives/boost/2009/10/157410.php [2] https://svn.boost.org/trac/boost/ticket/3548 https://svn.boost.org/trac/boost/ticket/3558 [3] http://beta.boost.org/users/news/version_1_41_0 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

4 5

Re: [boost] [Boost-users] [Review] GGL review starts today, November 5th
by Barend Gehrels 21 Nov '09

21 Nov '09

> If I had a library that only implemented quad-trees and then proposed > it as Boost.Generic Spatial Index, I would think the reviewers would > have something to say about that. > Please note that GGL is a "geometry library" implemented using "generic programming". Though we aim to a broad scope, we don't aim to "generic geometry" Barend p.s. (please make the To: of this thread: boost, and not boost-users)

2 2

Updating the Boost Review Process Was: [Boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale
by Jose 21 Nov '09

21 Nov '09

I propose these 3 changes (starting with the word ADD: below) to the current review policy in http://www.boost.org/community/reviews.html I realize that there is no mention to the word "vote" in the review policy, just "review comments". See message below for rationale on why these may be good changes. ----------------------------------- INTRODUCTION ... The final "accept" or "reject" decision is made by the Review Manager, based on the review comments received from boost mailing list members. ADD: Consensus should be objectively measured with the votes and otherwise the right to accept solely by the review manager could be revoked. ... RESULTS At the conclusion of the comment period, the Review Manager will post a message to the mailing list saying if the library has been accepted or rejected. A rationale is also helpful, but its extent is up to the Review Manager. If there are suggestions, or conditions that must be met before final inclusion, they should be stated. ADD: In conflicting reviews or with little consensus the Review Manager should justify way the library was accepted or not accepted. NOTES FOR REVIEW MANAGERS ... ADD: The review manager must not have or have had business ties with the library author/organization. ... ---------- Forwarded message ---------- From: Jose <jmalv04(a)gmail.com> Date: Mon, Nov 16, 2009 at 12:09 PM Subject: Re: [boost] [Boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale To: boost(a)lists.boost.org Hi, I am not expert in geometry but what matters is that boost continues to provide generic libraries (if possible !) like BGL, GIL, .. I think there is no blame on library authors which make a huge effort. What was broken is the review process, and some of the reasons why the review process was broken were: 1) The result of the review was 6 positive to 4 negative, when boost normally aims for consensus. This is the most objective point. Also, the issues the review manager was proposing to be fixed would not change the votes as the library was not appropiate even for 2D geo applications 2) The scope of GTL was changed before the review (see snippet 2 at the end) but the review docs still mention a wider app focus (see snippet 1 at the end). This confusion appeared when GTL was being reviewed. 3) The review manager didn't have time for the review (if you look at the apology at the beginning of the review email summary) 4) The GGL library proposal, which had been iterating the design with input from boost, in my opinion received an unfair treatment in the way the schedule was managed. 5) Boost failed to set the scope for a geometry library/ies and created tension with candidate library authors There are more points but I don't like long emails. I propose to change the current review process: http://www.boost.org/community/reviews.html ----------------- NOTES FOR REVIEW MANAGERS Decides if there is consensus to accept the library, and if there are any conditions attached. ----------------- AMENDMENT 1 that consensus should be objectively measured (with the votes) and otherwise the right to accept solely by the review manager could be revoked. Clearly there was no consensus in this library, and no clear discussion if one single library was possible (I understand your points that multiple libraries in this case may be preferable but still that is not incompatible with a complete design discussion) AMENDMENT 2 The review manager should have or have had no business ties with the library author/organization. Amendment 2 is not related to this review, but this would support the current transparency. I feel that in some cases there might be a vague prejudice in favor of big/important/known organizations to get their libraries accepted regards jose --------------------------------------------- Snippet from Boost.Polygon docs http://svn.boost.org/svn/boost/sandbox/gtl/doc/index.htm "These so-called Boolean algorithms are of significant interest in GIS (Geospatial Information Systems), VLSI CAD as well al other fields of CAD, and many more application areas, and providing them is the primary focus of this library." 7/19/09 I am changing the name of my library from GTL (Geometry Template Library) to boost::polygon and narrowing the scope from "computational geometry" to "polygon manipulation". This scope precisely describes the current scope of what is implemented. It also clarifies the position of the library relative to similar proposals. ------------------------------------------------

17 64

Fixing warnings - progress
by Paul A. Bristow 21 Nov '09

21 Nov '09

I've updated https://svn.boost.org/trac/boost/wiki/WarningFixes on progress we are making (a little effort would go a long way to fixing the remaining warnings) to show what has been fixed, and where we need more information, and more work. Please post information to be added, or edit the page yourself - it is a wiki after all ;-) Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

2 2

Re: [boost] [Boost-users] [Review] GGL review starts today, November 5th
by Barend Gehrels 21 Nov '09

21 Nov '09

Hi Michael, Thanks for your review! I don't understand some of the problems you have had, so I'll explain or ask some things. > Some general thoughts: > > Integration with Boost.Units should be encouraged. I don't think > is_angle, etc should be in GGL. If I have a vector of quantities, > things should Just Work. > I think you mean is_radian, which is used internally to know if spherical coordinates are in degree's or in radian's. We didn't thought it a good idea, just for this one piece, to integrate with another boost library. Though for some coordinate systems it certainly would make sense (see also answer to Brandon's review) > As it is, Barend favors GIS, > Bruno favors gaming, and the resulting library is a mashup of GIS > terms and other arbitrary terminology and it excels in no one > particular area. > Thanks for your namespace suggestion in another thread. This will help to improve this. > > Yes. I spent a few hours trying to get it to with ESRI, a leader in > the GIS domain. Their API is completely COM based however, and it > proved extremely difficult to get working with GGL. I wasn't able to > successfully do this with Boost.Polygon either. > Yes, it would be very cool if this would work nicely, and it is meant to work. It is not clear to me if you get anything working, or nothing. However, I'll come back to you because it would be very useful if there is an example, showing integration between GGL and ESRI. > The Examples link at the bottom of the main page of documentation is > broken (last line), This was not a hyperlink (could be though, sorry) > and custom_point_example.cpp doesn't compile - > cs::cartesian needs to be ggl::cs::cartesian. > This surprises me. It is declared within a macro, so ggl namespace is not necessary there. I've not heard of this problem before, and it seems to compile fine normally for everyone (so I must now say: for most people). Are you sure? > It was not clear what includes I had to include to register my custom > point type. GEOMETRY_REGISTER_POINT_2D is defined in > ggl/geometries/register/point.hpp, but the following won't compile: > Normally, including <ggl/ggl.hpp> is enough, but indeed this should also compile, will be add the dependency. > It also doesn't appear that the custom point type can be in its own > namespace when using these registration macros. For instance, the > following doesn't compile: > > namespace foo { > struct test { > double x, y; > }; > } > GEOMETRY_REGISTER_POINT_2D(foo::test, double, ggl::cs::cartesian, x, y) > [...] I had to have "using namespace math" just to register my point correctly. > Yes, that was a known issue and should have been documented. We didn't search for the solution yet, it must be simple. > Using the haversine strategy caused compilation errors > because there was no overload of get_as_radian<>() for my point type. > > 1. It's not documented that the haversine strategy requires > get_as_radian, or at least I didn't see it. > Spherical coordinate systems use get_as_radian internaly (using is_radian), but it should never be necessary to overload it yourself. The normal procedure is registering your point as cs::spherical<degree> coordinate system. That would have been fine, and that was expected for the haversine function. You probably used cs::cartesian, and it didn't know if it was degree or radian. Anyway, I see your problem though, we will correct this and/or document this better. > I finally got haversine working with my point type by defining > get_as_radius as above, and the result was correct. I must say, it is a great workaround, nice that you got it working also like that. > This almost went smoothly, except that I had to specialize > strategy_tag, but didn't see any mention of this requirement in the > docs. Once I did that, my distance strategy worked and returned the > same value as haversine for values along the equator. > To be complete, the vincenty is also part of the gis extension, it was first not included, but later we wanted to show that 07 graph example, showing nicely the integration between BGL and GGL (there were not too many comments on this though). I understand that you implemented your own strategy, very cool. And indeed, you should specialize your strategy_tag, if (and only if) you want to use that one by default. Another way would have been that you specified the strategy as additional parameter. Great you got it all working like this! Of course, everything should work, but you did use some quite advanced features of GGL, and I like to see that you did succeed there. We will work on the documentation so these scenario's will cause less problems. Thanks again, Barend

1 0

Help needed in fixing warnings
by John Maddock 21 Nov '09

21 Nov '09

Dear all, I've started a wiki page here: https://svn.boost.org/trac/boost/wiki/WarningFixes for folks to collaborate on fixing warnings from Boost libraries. As noted the initial effort should be directed towards core libraries - those that get included and reused by other libraries. You can help by: * Running the tests for your favorite libraries (those not already listed, or with "unknown" status), and updating their "Status" field to reflect whether any work is needed. * Filing bug reports if it's not obvious how to silence the warnings. * Filing patches if the fixes are obvious. * Fixing the code if you're a library author! There's something for everyone there, whether you're a Boost newbie, or a hardened veteran, so I hope that many hands can make light work of this! Cheers, John.

9 23

[1.41.0] iostreams/device/mapped_file.hpp has no include guards
by troy d. straszheim 21 Nov '09

21 Nov '09

making a trac ticket... -t

2 2