- Boost - lists.boost.org

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

[PREDEF] Review ends today
by Joel Falcou 29 Feb '12

29 Feb '12

The review of Boost.PRedef by Rene Rivera is ending today, February 29th. I recall to all people wanting to submit a formal review to do so. Regards

1 0

[Predef] Pre-review comments
by Mathias Gaunard 28 Feb '12

28 Feb '12

Misc ==== - This stuff partially exists in Boost.Config. How will this be integrated? - AMD stands for Advanced Micro Devices, not American Micro Devices - The whole set of C and C++ standard libraries doesn't seem to be covered. Are we supposed to infer it from the compiler or operating system? Naming ====== - BOOST_ARCHITECTURE_ is maybe a bit long. Have you considered a shorter name like BOOST_ARCH_ALPHA ? Same comment for BOOST_LANGUAGE_ - BOOST_LANGUAGE_XXX uses a STD prefix for most languages except for Objective-C. How about dropping the STD prefix? Also why not use CXX instead of CPP? - Standard C library is identified by LIBC, but standard C++ library is identified by LIBSTD. I find that confusing, it should be orthogonal. I take it LIBCXX wasn't chosen due to possible confusion with libc++. It's their fault for choosing a ridiculously broad name. glibc is often just called libc as well, yet this is not a problem. - BOOST_CXX_GNUC might be better as BOOST_CXX_GNU or BOOST_CXX_GCC - BOOST_OS_DRAGONFLY_BSD might be better as BOOST_OS_BSD_DRAGONFLY to indicate that "macro refinement" goes left to right. It could be BOOST_OS_BSD_FREEBSD for FreeBSD. Compiler frontend vs backend ============================ The BOOST_CXX_ macros is used to define both frontends (BOOST_CXX_CLANG, BOOST_CXX_EDG) and backends (BOOST_CXX_LLVM) and things that can be both (BOOST_CXX_GNUC) As for BOOST_CXX_CYGWIN, I have no idea what it's doing there. Cygwin should be exclusively in BOOST_OS_CYGWIN. The compiler is a normal GCC. As such it might be hard to tell which set of flags might be defined at the same time. Maybe the solution would be to split the set of frontends and backends, with each value in each set being mutually exclusive. Most compilers do not decouple frontends and backends, so it will end up with a lot of unnecessary duplication though. Non-mutually exclusive macros ============================= Currently, the only macros that are not mutually-exclusive (outside of the CXX macros outlined above, since they cover two different things) are the BOOST_OS_BSD macros along with BOOST_OS_UNIX and BOOST_OS_SVR4. It might be a good idea to expand on that on the architecture side (i.e. any x86, 32 or 64 bit), and the compiler side (GCC-like compilers). There are many variants of ARM as well, and a new 64-bit ARM will be released soon. The design needs to be flexible enough to integrate this. It might be good as well to put a clear distinction between a set of mutually-exclusive macros and more global macros that can cover several configurations. My use-cases ============ Just a few real use cases for which I use custom code in my software today, and that I'd be glad to replace: - Work-around a bug in the GCC frontend - Use a feature present in GCC-like frontends - Work-around a bug in the GCC backend - Define special versions of functions for x86 both 32- and 64-bit - Define special versions of functions for x86-64 only - Use special code for Windows or POSIX operating systems (for that, I currently use BOOST_SYSTEM_WINDOWS_API / BOOST_SYSTEM_POSIX_API)

4 11

Re: [boost] [git] neglected aspects
by David A. Greene 28 Feb '12

28 Feb '12

> The only downside (I can see) with GIT is that it has a bit of a learning curve. It is a bit more complicated but I believe (and experienced myself) that a lot of that learning curve is unnecessarily steep due to the way many of the tutorials out there are written. For some reason most of them start out describing the guts and inner workings of git (blobs, trees, packs, etc.) rather than teaching workflows. The one great exception I've found to this is Scott Chacon's fabulous _Pro_Git_ (http://progit.org/book) It teaches you how to use git to manage sources. Reading that is what make it "click" for me. -Dave

17 42