February 2012 - Boost - lists.boost.org

[range] adaptors and member functions pointers
by Yanchenko Maxim 17 Mar '12

17 Mar '12

Hi, While transforming and filtering sequences, it's pretty common to call the elements' member functions, so I think it's worth adding some syntactic sugar for range adaptors in order to achieve cleaner syntax. E.g. if we have a class struct Foo { std::string description() const; }; and we want to get all non-empty descriptions, we could just write this clean code: foo_list | transformed(&Foo::description) | filtered(&std::string::size) To enable this syntax, the attached patch should be applied to boost/range/adaptor/argument_fwd.hpp (diff against 1.47.0). Is there any interest to add this to Boost.Range? Thanks, Maxim

7 9

[git] neglected aspects
by Steven Samuel Cole 14 Mar '12

14 Mar '12

Hi all, First post here, so please bear with me. A lot has been said in the last year on the subject of a possible migration from svn to git. However, after reading pretty much every message on the issue on this list (sic!), I have the impression that some of the most important aspects did not get the consideration they require. I would therefore like to add my outside perspective. SUMMARY: 1. an svn --> git migration does cause some major, but one-time disruption. However, svn right now causes minor, but continuous disruption on a daily basis - which often goes unnoticed. 2. git's distributed concept is nothing less than one generation ahead of centralized VCSs like svn. The benefits usually do not become apparent until git is actually used in practice. 3. at the moment, boost is significantly missing out on fresh enthusiasm that new contributors could bring into the project; svn and the policies it mandates are partly too blame for that. 4. svn trunk (i.e. boost library) maintainers are too limited by the svn concept in their decision which changes they merge at what point in time and may be pressured into rushing suboptimal decisions; this can make maintenance work painful and frustrating. git greatly alleviates that problem. 5. IMO, it's not 'if', it is 'when'. The longer a migration is delayed, the longer boost development will be slowed down without even noticing. DETAILS: I am aware that some of my points technically are mentioned on the boost git wiki page at https://svn.boost.org/trac/boost/wiki/Git/WhyGit, but they still seem somewhat neglected. This is probably not surprising as many participants in the discussion 1. presumably are established boost contributors and thus share a 'from the inside' view of the subject and 2. are only marginally affected by svn's conceptual problems This is what happened here in the last couple of days: I needed a tool for a job in my current project and I couldn't find one, so I thought about what components I need to build my own. A little web research - Boost.Iostreams looks perfect for the purpose. You have all been through what comes next, be it with boost or with other open source software: Download the latest release, install the libraries, start reading the docs, run some sample code, etc. While reading, I spot a typo in an HTML doc, then another in an include file comment, a third one in another file... the fourth one at the latest makes me think - this is open source, I should sync the latest sources, fix all those typos as I come across them while reading and contribute them back to the project. A quick read on submitting bugs on boost.org, svn co yadi yadi, fix the typos locally. Of course I don't have write privileges to the repo, so the best I can do for now is create a patch and attach that to a bug report. Within minutes, someone takes care of the bug, comments and takes ownership. Excellent! Smithers, money fight! I go back to reading, find more typos. My patch has not been committed to the trunk yet, so my local changes are still sitting there on my local hard drive. If I do another svn diff > file_2.patch, the patch will also contain the changes I have already attached to the bug report. What are my options now ? Revert my changes, base the new ones on the head revision and send another patch ? Create a new patch file and manually remove the diffs of the old changes I already sent ? How will the upstream maintainer know which changes are based on what version ? Also, I notice a few other things that in my opinion could be done better to facilitate adoption of the iostreams library. I would be willing to do the work and I would in the perfect position as I am walking in the shoes of an adopter right now - but these are separate from the typo fixes and they are larger issues; considering I can't check my changes in, would I really want to have them sit on my local harddrive, waiting possibly for months for someone upstream to review and hopefully merge them ? A couple of hours later: I get an email from boost bugs/svn; the upstream maintainer has committed my changes. However, I actually receive not one, but two emails, because the upstream guy chose to split my patch into changes on documentation and changes on source code (which presumably required extra work on his part). I do an svn up and now have to deal with conflicts between my local changes and the new commits: I make a note of my second set of changes and overwrite my local files with the new repo versions, then bring the second set back in. Uff! That's a lot of work just to fix some typos! And these are just cosmetic issues in discrete chunks that do not require any testing; contributing changes to source code would take even more effort and more caution - build and test on several platforms, peer review, etc. Also, the upstream maintainer jumped on the bug report right away and integrated my changes within hours. This is the ideal situation (thanks again Daniel, great job! :-) - usually, things don't happen so quickly - especially around major release time. HOW THIS IS DONE IN GIT: 1. google 'github iostreams' --> click first search result: https://github.com/boost-lib/iostreams (this can be even reduced to 'gh: iostreams' by integrating github into chrome search engines, but that's another story...) 2. on githup website, click 'fork', wait a few seconds --> this auto-creates my personal online github iostreams repo 3. on my local machine, open a shell, enter 'git clone ', copy & paste the repo .git url shown on the website in there and run e.g. 'git clone git(a)github.com:<username>/iostreams.git' --> this creates a local fork of my personal online iostreams repo + the mailing list probably changes the line above to 'hidden' + there is github/desktop integration and a plethora of gui clients 4. i change local files and commit to the local repo. once a set of changes is complete, i push them online into my personal online repo; once my work has reached some maturity, I send a pull request to the upstream maintainer of the official iostreams repo, aka the keeper of the trunk. disclaimer: I have omitted one-time steps to set up local git, github.com account, ssh keys, lastpass integration, yadi yadi. these steps are abundantly documented online, done in minutes and required only once. THE GIT ADVANTAGE: I don't have to wait for the first set of changes to be merged into the trunk before I resync, resolve conflicts and base the second set on the new head revision; I simply create a new branch for a new change set and send a new pull request once my work is complete. The upstream maintainer has no peer pressure to merge any changes in: He/she is sitting on the head revision and is looking at a number of pull requests for change sets in various personal forks like mine; these are more like 'change offers' the maintainer is free to merge in if he/she so chooses (cherry-picking) - or postpone if this is not the time because for example a major release is due and they seem too risky. I as a contributor do not really care so much: Of course I am stoked if my work actually makes it into the project eventually, but the point in time when this happens technically does not matter to me - pending changes will not get in my way if the merge takes a little longer. This is the major difference between svn and git - and I can not stress this advantage enough: I am decoupled from, but still connected to the official trunk. I can make arbitrary changes and group them in any way I see fit. I offer them to upstream and move on to new development. As a side effect, this also provides an overview impression of quality and continuity of the work of a potential new contributor. Of course it is technically correct that svn also supports the concepts of forks and branches, but in terms of tooling and mentality, they are considered much more heavy-weight than in git and might get created a couple of times a year - while in git, they might come and go a couple of times a day. Finally, the 'series of tubes' metaphor IMO does not really hit it. Subversion to me seems more like a freight train where the waggons move at different speeds, so they constantly bump into the car behind and in front of them; movement of the entire train is jerky. Git on the other hand is a bunch of space ships linked by hyperelastic tractor beams: Even if one travels out as far as the delta quadrant, the upstream connection will always make sure the collective does benefit from any new development it brings back from there. [snipped several paragraphs about cultural and other aspects; maybe some other time.] # ssc

24 81

Is there interest in static code analysis?
by Antony Polukhin 14 Mar '12

14 Mar '12

Because of some interest on this topic, I would like to clarify some things: Of course you can have some trial version and use it by yourself, BUT more mature solution would be to find a "boost's liason contact". This contact will interact with the company, provide access to reports for developers. In that case all developers can get access to reports without downloading/installing the trial version and use static analysis tool for a longer time. That case will also require from a "boost's liason contact" to look carefully through the license for that tool and agree to it as a maintainer of a whole boost project (I am not permitted to take such solutions). Best regards, Antony Polukhin

3 6

Boost B-Tree Library Status
by Joel 12 Mar '12

12 Mar '12

Beman et al, Is the Boost B-tree Library still on track to be proposed? The reception at BoostCON 2011 was quite warm, IIRC. http://github.com/boostcon/2011_presentations/raw/master/tue/proposed_b_tre… Activity on github seems to be dried up. https://github.com/Beman/Boost-Btree Also, how well do you think it would work with large keys and small payloads (512 byte keys, a few integers for payload). Thanks! Joel

3 3

[numeric] Applying trivial bugfix
by Antony Polukhin 06 Mar '12

06 Mar '12

Hi, There are a lot of feature requests to support compilation with disabled exceptions #5731, #5076, #5393, #5800. Fix is trivial and well known: replace throw x; with BOOST_THROW_EXCEPTION(x); in a converter_policies.hpp file. But the library maintainer does not like BOOST_THROW_EXCEPTION because of code bloat. Can I apply another trivial fix: struct def_overflow_handler { void operator() ( range_check_result r ) // throw(negative_overflow,positive_overflow) { #ifndef BOOST_NO_EXCEPTIONS if ( r == cNegOverflow ) throw negative_overflow() ; else if ( r == cPosOverflow ) throw positive_overflow() ; #else if ( r == cNegOverflow ) ::boost::throw_exception(negative_overflow()) ; else if ( r == cPosOverflow ) ::boost::throw_exception(positive_overflow()) ; #endif } } ; Adding this will fix all the tickets and allow some of the dependent libraries to build with disabled exceptions. Boost.Lexical_cast tests will cover Boost.Numeric usage cases with disabled exceptions. Best regards, Antony Polukhin

4 7

[context] Providing template class enumerate in context.hpp
by Julien Nitard 04 Mar '12

04 Mar '12

Hi all, I am trying to use the newly accepted boost.context and I am wondering why something as useful as the template enumerate is not diretly given when including "context.hpp" and not even in a separate header. Since it's in the doc it would be a good addition IMHO. Thanks, Julien PS: the link to boost.context doc is broken and the git repos seems to have moved.

5 14

boost::adaptors::keys for mutable ranges of pairs
by Valentin Ziegler 04 Mar '12

04 Mar '12

Hello, map.hpp defines two overloads for adaptors::values, one for StdPairRange& and another for const StdPairRange const& rng. On the other hand, there is just a single adaptors::keys which takes StdPairRange const&. In particular, the code below will not compile: boost::find_if( boost::adaptors::keys(rng), SomePredicate() ).base()->second=NewValue(); Therefore, I would propose an adaptors::keys(StdPairRange& rng) overload similar to adaptors::values(StdPairRange&). Iterators of the returned range shall have a mutable base iterator. Further, iterators of the returned range should have a reference type of range_value<StdPairRange>::type::first_type& , so the elements in keys are mutable where StdPairRange admits this. Regards, Valentin -- Valentin Ziegler | vziegler(a)think-cell.com Software Engineer think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

2 1

[config] std::unique_ptr, std::ref detection?
by Peter Dimov 04 Mar '12

04 Mar '12

Suppose I want to implement a shared_ptr constructor taking std::unique_ptr. To avoid breaking pre-C++11 compilers, I need to, at least, know whether <memory> contains std::unique_ptr. (I'd also like to know if there's std::ref in <functional> because the specification of the constructor uses it.) But the config library doesn't seem to provide a way. There's no macro for std::unique_ptr, and there's no macro for "generic C++11 compiler and library".

9 23

Possible Bug in Boost Geometry's Huiller Algorithm
by Brian Ahr 03 Mar '12

03 Mar '12

Hi Folks. I was looking at the implementation of the huiller algorithm in boost, and it seems to be partially incorrect. See boost/geometry/strategies/spherical/area_huiller.hpp In the apply() function, we have if(lon2 < lon1){ E =-E;} which I believe should instead be calculation_type lon;if( lon2 < lon1 ) lon = lon1 - lon2;else lon = lon1 - lon2 + two_pi;if(2* half_pi < lon ) E =-E; according to Graphics Gems 5, pg 45 - 46. The comments at the top of the C++ file state that the code was derived from code in Graphics Gems 4, though the code was later corrected in Graphics Gems 5. I noticed this when trying to calculate areas of polygons on a sphere, where one of the points was (0, 0). In that case, it would always return a negative area, even though the polygon was defined counter-clockwise. Using a point other than (0,0) seemed to alleviate the problem, which got me wondering what was going on. Can anybody else confirm that this is an issue? Any suggestions for cleanly overriding boost's implementation until this is fixed? Thanks! - Brian

2 2

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

[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

Is there interest in portable integer overflow detection, with policy based handling?
by Ben Robinson 28 Feb '12

28 Feb '12

The implementation is complete, with 5 policies created (and users can always create and use more). The policies are: ignore_overflow throw_overflow assert_overflow saturate_overflow nan_overflow The implementation is fully portable, and it provides integer types which can be used like the builtin integers, except they will trigger their policy on an overflow. Also, this library will integrate seamlessly with the Boost Constrained Value Library (contributed by Robert Kawulak). Does this pique anyone's interest? Thank you, Ben Robinson

11 37

Please use BOOST_ASSERT_MSG(x, "message") instead of BOOST_ASSERT(x && "message")
by Mathias Gaunard 28 Feb '12

28 Feb '12

Several libraries, including Boost.Array, use things like BOOST_ASSERT( i < N && "out of range" ); This causes warnings with EDG-based compilers. It would be nice if library authors could replace this with something like BOOST_ASSERT_MSG( i < N, "out of range" ); Not only will it make those warnings disappear, it will also enable users to use those messages more efficiently in custom assert handlers. Thank you.

3 3

[test] Dynamic linking problem?
by Matthijs Möhlmann 28 Feb '12

28 Feb '12

Hello all, Attached a testcase how I use the boost test library. Compiling goes well, but when I try to run it I get a 'symbol lookup error': matthijs@hammer % ./main ./main: symbol lookup error: ./main: undefined symbol: _ZN5boost9unit_test9ut_detail24auto_test_unit_registrarC1ENS0_13basic_cstringIKcEE I compile my files with the following lines: g++ -o main.o -c -I/usr/src/boost_1_49_0 -g -Werror -Wall -std=c++0x main.cpp g++ -o test.o -c -I/usr/src/boost_1_49_0 -g -Werror -Wall -std=c++0x test.cpp g++ -o main -L/usr/src/boost_1_49_0/stage/lib main.o test.o -lboost_unit_test_framework This is done with a fresh install of boost 1.49. (Compiled with ./bootstrap.sh && ./b2 -j3) Compiler: gcc-4.6 If I use the most recent version of trunk (r77131) then everything works as expected. If more information is needed, please let me know. Regards, Matthijs Möhlmann

1 0

[uBLAS] array_adaptor, shallow_array_adaptor, interoperability and bugs
by Guillermo Ruiz Troyano 28 Feb '12

28 Feb '12

It is my first post. I still write worst in English than in C++. I hope don't mess it up… INTEROPERABILITY I'm been trying to use array_adaptor and shallow_array_adaptor to modify data with uBLAS. Yes, both classes are undocumented but it is useful (not this implementation) in some cases to have this kind of adaptor. For example: // Statistics accumulator for regression, correlation, etc. struct simple_regression { void operator()(double x, double y) { … } double mean_x; double var_x; double mean_y; double var_y; double covar; vector_wrapper<double> v() { … } // Return vector with a reference array adapter }; Now, you need (for example) to interpolate two accumulators. Then you should to be able to do: simple_regression sr, sr1, sr2; … double w = 0.5; sr.v() = sr1.v()*w+sr2.v()*(1-w); And you don't want that uBLAS copies data from you objects to inner containers continuously. UNDOCUMENTED ATTEMPT array_adaptor<T> has deep copy semantics. You can to construct an array_adaptor that use the external data, but vector call to copy constructor and this makes a copy: struct point { double x; double y; double z; }; point p = { 1, 2, 3 } array_adaptor<double> a(3, &p.x); // Ok, a holds p address vector<double, array_adaptor<double> > v(a); // v now holds a new address! Well, a bit confusing class. If the only purpose of this class template is to pass plain data as arguments. Why not to put that constructor in unbounded_array and bounded_array? unbounded_array(size_t size, T* data) : size_(size), data_(new value_type[size]) { std::copy(data, data+size, data_); } Then, I found shallow_adaptor_array, more dangerous and funny. It has shallow copy semantics and a dummy shared_array with reference counting... ¿? // Yes, I want troubles… #define BOOST_UBLAS_SHALLOW_ARRAY_ADAPTOR struct point { double x; double y; double z; }; void test() { point p = { 1, 2, 3 } shallow_array_adaptor<double> a(3, &p.x); // Ok, a holds p address vector<double, shallow_array_adaptor<double> > v(a); // Ok, v holds p address v += v; // Ok, now p = { 2, 4, 6 } v /= 2; // Ok, now p = { 1, 2, 3 } v = 2*v; // ¡¡¡What!!! p = { 1, 2, 3 } } // Dummy functor of shared_array in shallow_array_adaptor called, ok. When you assign v with an expression, this constructs a temporary and then swaps between the temporary and v. Here is the issue: class shallow_array_adaptor<T> : … { ... // Swapping BOOST_UBLAS_INLINE void swap (shallow_array_adaptor &a) { if (this != &a) { std::swap (size_, a.size_); std::swap (own_, a.own_); std::swap (data_, a.data_); // This is definitely infidelity } } ... }; This is not a good idea. This member function should have a dual behavior: class shallow_array_adaptor<T> : … { ... // Swapping BOOST_UBLAS_INLINE void swap (array_adaptor& a) { if (own_ && a.own_) { // If they own the data do wife-swapping if (this != &a) { std::swap(size_, a.size_); std::swap(own_, a.own_); std::swap(data_, a.data_); } } else if (&data_[0] != &a.data_[0]) std::swap_ranges(data_, data_+size_, a.data_); // Childs is another thing } ... }; Modifying this function I get: void test() { point p = { 1, 2, 3 } shallow_array_adaptor<double> a(3, &p.x); // Ok, a holds p address vector<double, shallow_array_adaptor<double> > v(a); // Ok, v holds p address v = 2*v; // Ok, now p = { 2, 4, 6 } and v holds p address } // 0kills of dynamic memory WHY NOT? 1. An unbounded_array and bounded_array constructor for C plain arrays and copy semantics. 2. To discontinue this adaptor_array (with a #ifndef) or modify. Its behavior can do it point nº1. 3. To fix, test and document shallow_array_adaptor (or another name). It should be useful. Yes, I know about memory leaks. But there are things like vector proxies, iterator ranges, etc. The problem comes when you have not a clear semantic. Regards, Guillermo Ruiz Troyano.

2 2

[exception] RFC: patch for printing stacktraces during exceptions.
by Brett Lentz 27 Feb '12

27 Feb '12

Hi folks! It's been a few months since I last mailed the list. I've been working on bringing some forked changes from the Passenger project into Boost due to their more general applicability. With some help, I've got a working patch against SVN trunk that enables one of Passenger's more useful features: obtaining exception stacktraces all the way through the stack. However, due to the size of the patch and some namespacing choices made by the Phusion people, I'd like to get some feedback on this patch to ensure it's suitable for being brought into Boost. First, there's some helper classes that Phusion has put in an "oxt" namespace that I'm not really sure where they should be put or if suitable analogues already exist within Boost. For the current version of the patch, these files are simply put into 'boost/oxt' until I have a better location for them. Second, the current patch uses boost::tracable_exception. I'd like to confirm whether that is acceptable or whether I should move this to a different location in the boost namespace. Finally, any other comments about this patch are welcome. I have attached both the patch, and some example code that will demonstrate the functionality. The patch and a simple example are available here: http://wakko666.fedorapeople.org/boost/ ---Brett.

5 9