- Boost - lists.preview.boost.org

Parts of linkflags are disappearing: $ISALIST gone
by Maciej (Matchek) Bliziński 05 Mar '12

05 Mar '12

My linkflags setting involves a dollar sign: linkflags='-R/opt/csw/lib/$ISALIST' The $ISALIST dynamic token tells the linker to iterate through supported instruction sets and pick the best one[1]. When the Boost binaries are built, the RPATH in the binaries is missing the dollar sign and everything after it: $ /usr/ccs/bin/dump -Lv work/solaris10-sparc/pkgroot/opt/csw/gxx/lib/sparcv9/libboost_iostreams.so.1.49.0 | grep RPATH [13] RPATH /opt/csw/lib/64:/opt/csw/gxx/lib/:/opt/csw/gxx/lib/64:/opt/csw/lib/ Do you see the /opt/csw/lib/ bit with the slash at the end? It could be explained by the contents of linkflags being interpolated by a shell. In my build, it's important to pass the dollar sign unchanged. Here's an example of correctly set RPATH: /usr/ccs/bin/dump -Lv /opt/csw/lib/libz.so.1 | grep RPATH [6] RPATH /opt/csw/lib/$ISALIST:/opt/csw/lib I need to pass the same flag to Boost libraries. Has anyone else seen this problem? Maciej [1] http://docs.oracle.com/cd/E19082-01/819-0690/appendixc-3/index.html

1 0

[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

bug in gcc.jam
by Oliver Kowalke 04 Mar '12

04 Mar '12

Hello, gcc.jam:451 applies always -m32 for 32bit systems. In the case of ARM architecture this is false because gcc on arm does not recognize -m32. In order to correct this issue I need to know how to test for ARM architecture at this code line (sorry I'm not that boost.build expert). Oliver

1 0

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

03 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 03 Mar '12

03 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

[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 29 Feb '12

29 Feb '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

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

Re: [boost] Is there interest in static code analysis?
by Ben Robinson 27 Feb '12

27 Feb '12

I would be interested in that static analysis tool. Thank you, Ben Robinson Sent from my Verizon Wireless smartphone Antony Polukhin <antoshkka(a)gmail.com> wrote: >Hi, > >I`ve recently found a tool and organization, that specializes on >static code analysis for C/C++. They already interact with some famous >open source projects and successfully find bugs. Looks like for >open-source projects they help for free. > >If someone is interested, I can send their web address in private >message (don`t want to ad on mailing list) > >Best regards, >Antony Polukhin > >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0