- Boost - lists.boost.org

[predef] Thanks for all the comments..
by Rene Rivera 01 Mar '12

01 Mar '12

I would like to than everyone who reviewed and/or commented on my library. Instead of trying to respond individually to each point raised I will do a single post about all the points I've gathered, and will gather when I reread all the posts. Hopefully I can write that up by Monday. Needless to say there are a few changes I need to do, regardless of acceptance results :-) Again, thanks to all. And thanks to Joel for managing the review. Rene. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

1 0

Adapting Polygon to work with point attributes
by Paul Miller 01 Mar '12

01 Mar '12

Boost::Polygon looks like exactly what I need to do some boolean operations on polygons but my polygons have additional attributes per point that I want to carry through the operation. But I can't figure out how to get polygon to create sensible values for the attributes other than X,Y, and I can't find an example that covers this scenario. It seems from the documentation that this is possible however. Can someone point me to an example, to say, adapt a polygon with this Point type? struct Point { int x, y; float r, g, b, a; }; Ideally it would average new r, g, b, a values together to make new points and polygon join points, but it could just copy one of the existing Points' attributes instead. I'm not picky. Cheers!

2 2

[TypeTraits] Patch: improving detectability of clang's intrinsics
by Michel Morin 01 Mar '12

01 Mar '12

Attached a patch to improve detectability of `__is_pod` and `__is_empty` intrinsics in clang. This is done by newly introduced `__has_feature(__is_pod__)` and `__has_feature(__is_empty__)` macros. (Clang trunk now accepts feature names with preceding and following double underscores.) Regards, Michel

2 1

Re: [boost] [git] neglected aspects
by Brian Wood 01 Mar '12

01 Mar '12

Dave Abrahams: > I don't see any advantage at all in having a "Boost supertree." If I > need a cluster of five libraries to get a job done, I don't see a reason > to mess around with anything more than those five. And with the > dependencies properly encoded, I won't even have to ask for all of those > explicitly. +1 for keeping things simple. This effort has been discussed for years. Is it close to being ready? Regards, Brian Wood Ebenezer Enterprises http://webEbenezer.net

1 0

[PREDEF] Review
by Ioannis Papadopoulos 29 Feb '12

29 Feb '12

> - What is your evaluation of the design? The design is straightforward and I find it nice, with some exceptions: - BOOST_ARCHITECTURE_* is too long (BOOST_ARCH_* is better) - BOOST_LANGUAGE_* is too long (BOOST_LANG_* is better) - BOOST_CXX would be better if called BOOST_COMPILER or BOOST_COMP - There has to be some macro for compilers that do emulation (for example Intel, PathScale etc appear also as gcc). - I do not like the fact that all macros are defined with a 0 when the compiler/arch/whatever is non-existant. I prefer to do # ifdef BOOST_CXX_GNU ... # endif rather than # if BOOST_CXX_GNU ... # endif - BOOST_VERSION_NUMBER allows only 3 numbers. I don't think that this is the case for all compilers/libraries. - There are some platforms that have unique features (for example Cray machines, IBM BlueGene etc). A BOOST_PLATFORM_* macro would be nice. > - What is your evaluation of the implementation? Including one file includes pretty much everything. It would be more straightforward if everything was in one file (for example merge everything in architecture/ in architecture.h). This also solves the issue of defining macros for things that don't exist. > - What is your evaluation of the documentation? No considerable problems with the documentation. Maybe it should be mentioned what the library supports. > - What is your evaluation of the potential usefulness of the library? I already have something similar in a lot of my codes. I would gladly remove them and use predef - especially if it detects also platforms. > - Did you try to use the library? With what compiler? Did you have any problems? Yes, PathScale is recognized as both gcc and pathscale. > - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A quick reading of the documentation and the code. I ran a small test case. > - Are you knowledgeable about the problem domain? Yes. > - Do you think the library should be accepted as a Boost library? I think that it should be ACCEPTED with the requirement that all issues have been resolved; especially the compiler recognition.

1 0

Determining interest: Pure imaginary number library
by Matthieu Schaller 29 Feb '12

29 Feb '12

Dear all, I have recently been playing a lot on numerical analysis problems containing complex numbers and functions. I have been using the SL std::complex<> library and could observe that some of the algorithms weren't optimized in cases where complex numbers have to be multiplied by pure imaginary numbers (i.e. x*sqrt(-1)). I have implemented a class to represent these numbers and overloaded all relevant operators in a more optimized fashion thanks to the knowledge that the real part of these complex numbers is 0. I could observe an important speed-up in some calculations. As an example, this piece of code (1D Schroedinger equation using finite differences): for(size_t i(0); i<nbPoints; ++i) { Psi_new[i] = Psi_old[i] + ii * hbar * deltaT / (12.*m*deltaX*deltaX) * (-Psi_cur[i-2] + 16.*Psi_cur[i-1] - 30.*Psi_cur[i] + 16.*Psi_cur[i+1] - Psi_cur[i+2]) - 2. * ii * V(x[i]) / hbar * deltaT * Psi_cur[i]; } is more than 2 times faster (g++ 4.6.1 core i7 2820QM) when the imaginary unit (constant) variable ii is defined to be Imaginary<double> ii(1.); than when it is defined as std::complex<double> ii(0.,1.); Some other expressions also benefit from this improvement and can run faster. Expressions including square roots or exponentials of pure imaginary numbers are improved a lot. The range of application of such a class is quite narrow but it may be helpful to speed-up some simple numerical problems. The source code as well as a working example is available here: http://code.google.com/p/cpp-imaginary-numbers/ Thanks, Matthieu

8 21

How to build on VC11?
by Olaf van der Spek 29 Feb '12

29 Feb '12

Hi, How does one build Boost 1.49 on VC11? It keeps using VC10. -- Olaf

2 1

[assign] list_of ambiguous overload with C++11
by Kim Barrett 29 Feb '12

29 Feb '12

This thread http://lists.boost.org/boost-users/2011/06/68641.php mentions a problem encountered with boost::list_of with C++11 features. It was reported against boost 1.46, and Thorsten said in that thread that a fix was being developed and "should be there soon". It was mentioned in that thread that it was probably already too late for boost 1.47. This problem still seems to be present in boost 1.49. Wondering what happened to that fix. I can probably use the patch from that thread, but a real fix in boost would obviously be better. BTW, what happened to web-based svn browsing of the boost repository? That used to be available (there was a link on the downloads page), but seems to have disappeared. There doesn't seem to be an easy way for a casual observer like me to look at history to see if there's been any possibly relevant changes.

2 2

[PREDEF] Review
by Dan Price 29 Feb '12

29 Feb '12

Hi everyone, This is my first review of a boost library but I have been a long-time boost user. I am excited by this proposal because it is a library that I would use on the day that it is accepted and it fills the need for what is otherwise a hackish and inconsistent task. My review of the library is included below. Thank you, Dan Price **What is your evaluation of the design?** The macros are clear. The BOOST_ARCHITECTURE_ macros are a little too long to type; I would advocate for changing them to BOOST_ARCH_ to make it quicker to type. Note that the operating system macro is BOOST_OS_ and not BOOST_OPERATINGSYSTEM, and BOOST_CXX vs. BOOST_COMPILER, so there is already a precedent for shorter names. The other ones are easy to type and appropriate. Within the headers there are human-readable strings that are intended to be used with a built-in test. It seems as if these might be useful to make these available for other purposes such as debugging. I wanted to add a comment to a question that showed up prevalently on the mailing lists regarding NULL vs. zero for definitions. Before reading this thread, but after having read the documentation, I assumed that definitions took on a NULL (undef) value. That is to say that even after reading the documentation, I made a faulty assumption because of my previous experience with platform detection. I would therefore advocate that an #undef approach be used rather than the zero-based one in order to avoid any gotchas. **What is your evaluation of the implementation?** The design goals of minimal "weight" from the predef headers is a good one. I personally do not think there is much to worry about regarding the implementation as long as the user-facing features (names, completeness) are good. **What is your evaluation of the potential usefulness of the library?** This is a library that I would use on the day that it was introduced to boost and I would even consider patching the distribution of boost I have in version control with this library. **Did you try to use the library? With what compiler? Did you have any problems?** I compiled the tests on a 64-bit version of ubuntu Linux and they worked as expected. **How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?** My effort consisted of reading through the documentation and exploring the headers. I also compiled the tests on one platform and they worked as expected. **What is your evaluation of the documentation?** The documentation is acceptable, but I think that version number description can be cleaned up a bit. Specifically, rather than repeating "Version number available as major, minor, and patch." over and over, perhaps a graphic or an abbreviation can be used? Alternatively this may be better laid out as a table. One error in the documentation (also in the source): "American Micro Devices" -> "Advanced Micro Devices" **Are you knowledgeable about the problem domain?** I am knowledgeable of the preprocessor symbols of the 3 compilers and 3 systems I typically use. My normal habit for systems I am unfamiliar with is to search for information at predef.sourceforge.net but this library would clean up and simplify that work considerably. Additionally, I can see my team members who are not as familiar with detection mechanisms finding this library very useful. **Summary** In summary, I think that this library should be *conditionally accepted* as a boost library, provided that the issue regarding the NULL vs. 0 values for preprocessor symbols be worked out. I am an advocate of the NULL-based approach because it best matches what my expectations are.

1 0

[PREDEF] Review for the Boost.Predef library by Rene Riviera
by Joel Falcou 29 Feb '12

29 Feb '12

The review of BOOST.PREDEF by Rene Riviera is scheduled between Monday, February 20th to February 29th. ================ Contents & Scope ================ BOOST.PREDEF defines a set of compiler, architecture, operating system, and library version numbers from the information it can gather of C++ predefined macros or those defined in generally available headers. The idea for this library grew out of a proposal to extend the Boost Config library to provide more, and consistent, information than the feature definitions it supports. What follows is an edited version of that brief proposal. =============== How to get it ? =============== Sources and documentation can be retrieved from http://tinyurl.com/73n6a3k ================ Writing a Review ================ The reviews and all comments should be submitted to the developers list, and the email should have "[PREDEF] Review" at the beginning of the subject line to make sure it's not missed. Please explicitly state in your review whether the library should be accepted. The general review checklist: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion.

15 34