- Boost - lists.preview.boost.org

compiling boost-1.46.1//python-2.7.1
by luxInteg 28 Mar '11

28 Mar '11

Greetings I am trying to biuld boost-1.46.1 on computer with these:- --cpu amd64 2 cores --os 64bit cblfs linux-2.6.37.2 gcc-4.5.2/python-2.7.1//icu-4.5.2. Results are as follows:- prelims: sh bootstrap.sh \ --prefix=/usr \ --with-toolset=gcc \ --with-bjam=/usr/bin/bjam \ --with-python=python \ --with-python-root=/usr bjam: /usr/bin/bjam --------- running bjam ends like so:- ~/boost_1_46_1/tools/build/v2/build/configure.jam:145: in builds-raw *** argument error * rule UPDATE_NOW ( targets * : log ? : ignore-minus-n ? ) * called with: ( <p~/boost_1_46_1/build/boost/bin.v2/libs/regex/build/gcc-4.5.2/debug>has_icu : : ignore-minus-n : ignore-minus-q ) * extra argument ignore-minus-q (builtin):see definition of rule 'UPDATE_NOW' being called ~/boost_1_46_1/tools/build/v2/build/configure.jam:179: in configure.builds ~/boost_1_46_1/tools/build/v2/build/configure.jam:216: in object(check-target- builds-worker)(a)416.check ~/boost_1_46_1/tools/build/v2/kernel/modules.jam:103: in modules.call-in ~/boost_1_46_1/tools/build/v2/util/indirect.jam:96: in indirect.call ~/boost_1_46_1/tools/build/v2/build/targets.jam:1012: in targets.evaluate- requirements ~/boost_1_46_1/tools/build/v2/build/targets.jam:1393: in basic-target.compute- usage-requirements ~/boost_1_46_1/tools/build/v2/build/alias.jam:47: in compute-usage- requirements ~/boost_1_46_1/tools/build/v2/build/targets.jam:1319: in object(alias-target- class)(a)420.generate ~/boost_1_46_1/tools/build/v2/build/targets.jam:732: in generate-really ~/boost_1_46_1/tools/build/v2/build/targets.jam:704: in object(main- target)(a)810.generate ~/boost_1_46_1/tools/build/v2/build/targets.jam:848: in targets.generate-from- reference ~/boost_1_46_1/tools/build/v2/build/targets.jam:1217: in generate-dependencies ~/boost_1_46_1/tools/build/v2/build/targets.jam:1268: in object(typed- target)(a)423.generate ~/boost_1_46_1/tools/build/v2/build/targets.jam:732: in generate-really ~/boost_1_46_1/tools/build/v2/build/targets.jam:704: in object(main- target)(a)811.generate ~/boost_1_46_1/tools/build/v2/build/targets.jam:848: in targets.generate-from- reference ~/boost_1_46_1/tools/build/v2/build/targets.jam:1217: in generate-dependencies ~/boost_1_46_1/tools/build/v2/build/targets.jam:1266: in object(typed- target)(a)194.generate ~/boost_1_46_1/tools/build/v2/build/targets.jam:732: in generate-really ~/boost_1_46_1/tools/build/v2/build/targets.jam:704: in object(main- target)(a)792.generate ~/boost_1_46_1/tools/build/v2/build/targets.jam:258: in object(project- target)(a)185.generate ~/boost_1_46_1/tools/build/v2/build/targets.jam:848: in targets.generate-from- reference ~/boost_1_46_1/tools/build/v2/build/targets.jam:1217: in generate-dependencies ~/boost_1_46_1/tools/build/v2/build/targets.jam:1268: in object(install- target-class)(a)120.generate ~/boost_1_46_1/tools/build/v2/build/targets.jam:732: in generate-really ~/boost_1_46_1/tools/build/v2/build/targets.jam:704: in object(main- target)(a)622.generate ~/boost_1_46_1/tools/build/v2/build/targets.jam:848: in targets.generate-from- reference ~/boost_1_46_1/tools/build/v2/build/targets.jam:1217: in generate-dependencies ~/boost_1_46_1/tools/build/v2/build/targets.jam:1268: in alias-target- class.generate Jamroot:648: in build-multiple Jamroot:612: in object(top-level-target)(a)127.generate ~/boost_1_46_1/tools/build/v2/build/targets.jam:732: in generate-really ~/boost_1_46_1/tools/build/v2/build/targets.jam:704: in object(main- target)(a)626.generate ~/boost_1_46_1/tools/build/v2/build/targets.jam:848: in targets.generate-from- reference ~/boost_1_46_1/tools/build/v2/build/targets.jam:1217: in generate-dependencies ~/boost_1_46_1/tools/build/v2/build/targets.jam:1268: in alias-target- class.generate Jamroot:648: in build-multiple Jamroot:612: in object(top-level-target)(a)128.generate ~/boost_1_46_1/tools/build/v2/build/targets.jam:732: in generate-really ~/boost_1_46_1/tools/build/v2/build/targets.jam:704: in object(main- target)(a)627.generate ~/boost_1_46_1/tools/build/v2/build/targets.jam:258: in object(project- target)(a)70.generate ~/boost_1_46_1/tools/build/v2/build-system.jam:735: in load ~/boost_1_46_1/tools/build/v2/kernel/modules.jam:283: in import ~/boost_1_46_1/tools/build/v2/kernel/bootstrap.jam:142: in boost-build ~/boost_1_46_1/boost-build.jam:17: in module scope . -------------- advice would be appreciated. sincerely luxInteg ps it compiles on another machine with gcc-4.4.2/python-2.6.4/icu-4.2.1

2 3

Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)
by Brian Wood 28 Mar '11

28 Mar '11

Robert Kawulak: > You can eliminate the try/catch from the code. For example, instead of: > > try { > // do sth dangerous using cmpRead > } catch(...) { > cmpRead = 0; > throw; > } > > write: > > auto tmp = cmpRead; > cmpRead = 0; > // do sth dangerous using tmp > cmpRead = tmp; Hi, Robert, Thanks for that. I tried it. The implementation is available here -- http://webEbenezer.net/misc/rcb.hh . It's one line shorter than the version with the try/catch, but it adds 3 minor statements to the non-error path. On Fedora 14 with g++ 4.5.1 one of my executables increased in size by over 500 bytes when using the version without a try/catch. On Windows 7 with MSVC++ 10 there wasn't any size difference in the executable. I find the try/catch version easier to understand though. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

[context] review
by Gordon Woodhull 28 Mar '11

28 Mar '11

Hi Oliver, Vicente, all, Here is my uneducated review of the Context library. I would like to see the library Accepted. However, I do not have the expertise to pore over assembly instructions, nor do I know whether this is the right approach. I would probably be just as happy with a slower safe cross-platform library built on OS support, as with the fast (dangerous?) assembly version. I hope that people who know better, like Giovanni and Holger, will continue to help make the library more robust. > - What is your evaluation of the design? From a user's perspective, it seems fairly clear how to use the library. I thought I had understood from discussion that the class is moveable, but this didn't work for me. I ended up having to wrap contexts up in shared_ptrs in order to get my example to work (attached). I am confident that higher-level libraries will take away the ugliness that arises from both coroutines in my example having to have access to the context for the other routine. I admire the way Oliver split and then split his library again, to make this a very manageable library for review. > - What is your evaluation of the implementation? I only glanced at it. > - What is your evaluation of the documentation? The documentation is quite spare and completely lacks examples. It needs copy-editing (I can help there). It also seems to be out of date. For example, it states: "To get the current user-level context boost::context::current() has to be called" but I couldn't find this function at all; it seems to have been replaced with the default-constructed context<>? > - What is your evaluation of the potential usefulness of the library? It would be great to have teleportation (or is it time travel? ;-) in C++. I expect this will unlock many interesting paradigms in addition to coroutines & generators. I ran into a problem recently that I thought would be nicely solved if only I had coroutines. A parallelization framework had a callback when it needed more tasks to send out, and the routine that produced tasks was a hairy loop-of-loops. Neither could have its control inverted without making a big mess. I've attached an extreme simplification of the problem (without the callback part that made it impossible to invert control). > - Did you try to use the library? With what compiler? Did you have any > problems? Yes. I used Ubuntu 9.10 (in a VM), gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8). Since I used the review version from the vault and didn't do anything special, I think this means I used the ucontext version (how do I try fcontext? docs don't seem to explain how to choose.) I had one problem which turned out to be a misunderstanding: I tried to construct a context with a next-context and then call it multiple times, but this crashed. In retrospect this isn't any better than a regular function call! and doesn't make much sense. But it would be good for the documentation to make it clear that a context is dead if the function returns. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? I spent a couple of hours reading docs and discussion, a few hours getting my example running, and an hour or two on writing this review. > - Are you knowledgeable about the problem domain? Color me interested but no expert. Cheers, Gordon

2 6

Re: [boost] [Boost-users] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
by Joachim Faulhaber 27 Mar '11

27 Mar '11

2011/3/27 Frédéric Bron <frederic.bron(a)m4x.org>: >> Yuk, to be honest, sorry! > > I found "an expression of disgust" in Cambridge Online. Is that what you mean? > OK. In respect of lingual appropriateness or "beauty" of naming constructions, I think we should listen to the advice of our native speakers. > Honestly, I wonder how to solve the desires of everybody on the naming topic. Since your library extension is accepted unconditionally you have the freedom and also the duty to make a final choice yourself after considering all the arguments. Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0

Re: [boost] Boost.Polygon edge, polyline and edge set concepts
by Gabriela Botea 27 Mar '11

27 Mar '11

Hello! I am 3rd year Computer Science student from the Polytechnic University of Bucharest, Romania, and I am interested in working in this project, studying polygon edge, polyline and edge set concepts. I was wondering if for this project or any other proposed by the Boost org I should be submitting some code or an application draft before actually submitting my application. Also, any suggestions or guide lines in applying are welcome. My e-mail: gabriela.botea(a)gmail.com Thank you, Gabriela

3 2

[C++0x] C++0x FDIS ships!
by Beman Dawes 27 Mar '11

27 Mar '11

On Friday In Madrid, Spain, the ISO C++ committee approved the Final Draft International Standard (FDIS) for C++0x. So C++0x is now complete in a technical sense. There is no possibility for further technical change. It will be a few weeks before the actual FDIS document is available. The ISO formal voting process will take until August or later. It's an up or down, yes or no, vote. All the countries actively participating voted yes for shipping the FDIS, so this ISO vote is mostly a formality. Most of the changes approved in Madrid were minor wording changes fixing mistakes in specification. Proposals to remove several features on the grounds they haven't been implemented or tested were rejected, usually by overwhelming vote margins. For example, the range-based-for-loop problem that surfaced on the Boost list caused a tweak in name lookup wording. On the library side, a lot of effort was devoted to "noexcept". A much more coherent set of usage guidelines was agreed on, and that meant going through the standard library and removing a lot of uses of "noexcept" that were over aggressive. More on that later, since Boost will probably want to use a similar set of guidelines. A straw poll for restarting work on Library Technical Report 2 passed without opposition. There was a lot of private discussion as to which Boost libraries committee members wanted to see go into TR2. --Beman

1 0

[context review] Review will end Mars 30st 2011
by Vicente BOTET 27 Mar '11

27 Mar '11

Hi all, The review of Oliver Kowalke Context library will end on Mars 30th. There were a few interesting reviews with quite constructive comments. I encourage you to make a review so you can help improving the library and also help me to take the right decision ;-) Please let me know if you needs more time so I can see if the review could be extended. Vicente Review Manager Boost.Context is a basic building block library that is used for more higher abstractions. It is used by Boost.Fiber, Boost.Tasklet and Boost.Task from the same author. I really hope to see your vote and your participation in the discussions on the Boost DEVELOPMENT mailing lists! WARNING !!!!!!!!!!!!! Only on the Boost DEVELOPMENT mailing lists Please use [context review] as prefix of your post to make easier the review follow up. You can download a frozen version for the review from the Vault, TinyURL: http://tinyurl.com/5r77rel or The documentation is available directly here: http://ok73.ok.funpic.de/boost/libs/context/doc/html/ --------------------------------------------------- About the library: Boost.Context provides a possibility to switch between different user-level context and is intended to be the basis for a higher abstraction like coroutine and fiber. A user-level context represents the current execution state, including all registers and CPU flags, the instruction pointer, the stack pointer. boost::context encapsulates such a user-level context and is able to store/restore its associated user-level context. This allows multiple execution paths running on a single thread using a sort of cooperative scheduling (in contrast a thread is preemptively scheduled) - the running boost::context decides explicitly when its yields to allow another boost::context to run (user-level context switching). A context can only run on a single thread at any point in time but may be migrated between thread. A context switch between threads costs usually thousands of CPU cycles on x86 compared to a user-level context switch with few hundreds of cycles. Boost.Context differes to setjmp()/longjmp() in the fact that the C99 standard does not require that longjmp() preserves the current stack frame, e. g. jumping into a function which was exited via a call to longjmp() is undefined. Boost.Context allows to select the mechanism provided by the operating system (ucontext on UNIX, Windows Fibers on Windows) or a faster implementation provided by this library (fcontext using assembler). --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - 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? Have a good review, Vicente Review Manager

1 0

GSOC 2011: idea
by Xu Sun 27 Mar '11

27 Mar '11

Hi there, I have been working on the component detection problems for one year and Boost helps me a lot on my research. However, I found there is no implementation about doing component problems in Boost. Is it possible to get a chance to implement this idea in the summer ? Since I have been working on this problem for a time and I have my own codes to do it both in C++ and Java. So the time may not be a problem for modifying my codes and embedding it into Boost. Thanks, Xu

2 1

GSoC'11 [Own Idea] -Mentor Needed
by Sitesh Shrivastava 27 Mar '11

27 Mar '11

Hello Everyone!, I am a Junior Undergraduate at BIT Mesra, one of the premier institutes in the field of Engineering and Sciences in India, pursuing Computer Science & Engineering. I am looking forward for a challenging project as a part of GSOC '11 under Boost Organisation during summers. I would like to put forward my own idea for a Library which is: - Templatized General Purpose Tree based data structures and algorithms for them The idea is to provide template based containers which will provide general purpose tree containers as there are for Stack, Queue and few others in the Standard Template Library. As of now, I would like to propose the library to consist of 5 containers which includes: 1. Binary Search Trees 2. Red-Black Trees 3. B-Trees 4. Binomial Heaps 5. Fibonacci Heaps Now, these containers will provide the used a generic container set as they are used along with their common operations like Insertion, Deletion, Search etc. Also, they will provide the user with specific operations for each type of container like, Decreasing key of a node in Fibonacci Heaps, Rotation in Red-Black Trees etc. [PS: Any Additions as well as Modifications are welcome to be put forward] I am looking forward towards Boost Community so that I can find a mentor for this project. I would like to discuss more about the details of the above project so that I can contribute to the Boost as well as OSS Community. I would like to mention that I have strong foundations in algorithm intensive programming and have advanced foundations in C/C++ too. I am fully aware of the responsibilities and requirements for this position. To consolidate my knowledge in the fields of interest, I have acquired conceptual knowledge in the fields of algorithms and data structures & have done basic projects in these fields too. If any further information is required, I would be glad to furnish the same. -- Regards, Sitesh Shrivastava Junior Undergraduate, BIT Mesra Phone: +91-9470521313 E-Mail: siteshshrivastava(a)gmail.com Home-Page: https://sites.google.com/site/siteshshrivastava

8 13

[dynamic_bitset] tickets triaging
by Alexey Stukalov 26 Mar '11

26 Mar '11

Dear boost developers, there's a number of untriaged issues related to dynamic_bitset component in boost trac. In particular, there are 2 patches by me addressing the performance of find_first()/find_next(): https://svn.boost.org/trac/boost/ticket/5158 https://svn.boost.org/trac/boost/ticket/5159 Is there a possibility they would be reviewed? Thanks, Alexey

1 0

GUI objects for boost
by farah inamdar 26 Mar '11

26 Mar '11

hi; I would like to discuss my project idea with the boost developer mailing list and mentors. I wold like to work with the UI for box , btn , frame etc etc and this is the way I am going to do it. What ever road map you set for the project idea. -- Warm Regards, Farahnaj......... :-)

2 1

Boost.Polygon edge, polyline and edge set concepts
by farah inamdar 26 Mar '11

26 Mar '11

I am studying in Mtech cs. In my graduation i built software in java which has have most of functions like PowerPoint. So i am confident that i can handle this polygon edge related problem. just give me some guide lines. My Id is farahinamdar(a)gmail.com -- Warm Regards, Farahnaj......... :-)

2 1

[GSOC]Asking for advice
by Faiçal 26 Mar '11

26 Mar '11

I want to participate (for the first time) in GSoC, particularly boost's projects. I first choosed to apply for the "Checks & Hashes" project but I discussed briefly on #boost irc and people here convinced me to take a look on the SIMD Library project. This project seems very challenging, I'll try it despite my poor experience. I start reading about SIMD, I'm currently reading it's wikipedia article and some articles found by google and I download the AltiVec programming interface manual. It would be useful for me if some of you guys give me links for good references articles or documentation about this technology. This post is essentially for introducing myself to your community and asking advice in preparing my application for the project. Thanks.

2 2

Intel compilation
by barend 26 Mar '11

26 Mar '11

Hi, The Boost.Trunk summary now gives for some Intel compilers, since some time: Test output: Sandia-intel-10.1 - geometry - distance / intel-darwin-10.1Rev 70458 / Wed, 23 Mar 2011 01:41:17 +0000 Report Time: Thu, 24 Mar 2011 07:47:34 +0000 Compile [2011-03-23 04:42:50 UTC]: fail "/opt/intel/cce/10.1.024/bin/icpc" -xc++ -w1 -O0 -g -inline-level=0 -vec-report0 -DBOOST_ALL_NO_LIB=1 -D__WINT_TYPE__=int -I".." -I"../boost/geometry/extensions/contrib/ttmath" -I"../libs/geometry/test" -c -o "/Volumes/Scratch/kbelco/boost/results/boost/bin.v2/libs/geometry/test/algorithms/distance.test/intel-darwin-10.1/debug/distance.o" "../libs/geometry/test/algorithms/distance.cpp" ../boost/detail/fenv.hpp(11): catastrophic error: #error directive: This platform does not have a floating point environment #error This platform does not have a floating point environment ^ compilation aborted for ../libs/geometry/test/algorithms/distance.cpp (code 4) Meaning the boolean variable BOOST_NO_FENV_H is not set. Is that compiler-detection broken somehow? It is not on all Intel compilers. Regards, Barend

3 6

Compilation for PGI and ublas
by Barend Gehrels 26 Mar '11

26 Mar '11

hi, The Boost.Trunk regression report gives me for most of the tests, on Sandia-pgi-11.2: catastrophic error: #error directive: Your compiler and/or configuration is unsupported by this verions of uBLAS. Define BOOST_UBLAS_UNSUPPORTED_COMPILER=0 to override this message. Boost 1.32.0 includes uBLAS with support for many older compilers. This message is also reported for all tests in numeric/ublas. We're only slightly dependant on ublas (only in matrix transformations). They are indirectly included in many testfiles but are not really used there. Will I set BOOST_UBLAS_UNSUPPORTED_COMPILER to 0, for the tests? I checked and didn't notice any other library doing that. Regards, Barend

1 0

[Review] XInt Review
by Joel Falcou 26 Mar '11

26 Mar '11

Here is my review for XInt. Currently I think the library should not be included in boost as a lot of problems are, in my opinion, still to be fixed and the design has to be rethought. *********************************************************************** * What is your evaluation of the design? Large integer is a bit like XML and Unicode. Lots of people want to do such a library because it has a high impact of usefulness and, from afar, it doesn't sounds *this* complicated. Alas, it is :/ The premises are OK. We have some large integer type that has proper value semantic and can be used in a variety of operations and functions. So far, so good. The main culprit is that the current library design is rather hardwired to work with a choice of implementation the author thought to be OK at some point but which still have to be proven better than existing solution. The overall design lacks separation between the data and the algorithm that makes the library difficult to extend: what if i want to take an arbitrary range of integers and look at them as a huge series of bits ? What if i don't want the extra memory overhead so i can mmap some files directly into memory (cause reading a 10k bits integer is a no-no) ? Can I pass the integer type to a STD algorithm if I want to iterate over the bytes it contains ? or copy them using boost::range copy ? On the data side, i think being forced to use a given representation is wrong. The Ideal should be that the library provide a fall back implementation but provide adaptor to adapt any kind of data to be looked at as a large integer. The definition of a LargeInteger concept would help defining such an adapting interface and make the library more fluid. For example, what if i want to implement LCM ? * What is your evaluation of the implementation? The implementation is poor for various reasons: - author uses COW for performance reasons. Alas COW has been demonstrated again and again to be of little interest. Looking at the problem 10s (types holding arbitrary large amount of data to be chained in operations without copy) should have lead to an expression template based solution. Capture a whole chain of operations on values, compute the worst case nbr of bits to store, allocate once then compute inside. It prevent spurious allocation and make the algorithms easier to write. Additionally, ET would help detecting expression pattern for which a non naive algorithm could be applied. - virtual inheritance: looking at integer_t shows: class integer_t: virtual public .... Why ? It seems you're trying to implement some policy based design but i cant see why virtual inheritance is used ? Do you get problem not having multiple definition in your mixins ? - There is a lot of unwarranted pass-by-value function prototype which seriously impact performance even with COW. pass-by-ref > pass-by-value + COW. Moreover, the "thread safety" COW is dubious. - the headers are obscenely big. It could be easier to follow the code it there was not this 2k+ line mammoth files. * What is your evaluation of the documentation? The documentation is OK but it is rather hard to navigate as there is real links between sections, forcing me to go back and forth between sections. * What is your evaluation of the potential usefulness of the library? The problem the library tries to solve is a very important one as shown by the large amount of similar project. Having such a library is worthy of inclusion in boost but not in the present form and shape. * Did you try to use the library? With what compiler? Did you have any problems? I tried some examples from the doc on gcc 4.5 with no real 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? I've been doing research and development on scientific computing for 9 years. If the specific problem of large integer is a bit of a fringe domain for me, I have been collaborating on such design in some projects. * Do you think the library should be accepted as a Boost library? No. In its current form, the library *should not* be accepted into Boost. performances claims are not backed up (and other reviewers show it can be far better0 the design lacks of genericity and its implementation is , in my opinion, sub-optimal. To be accepted the following point should be addressed: - use expression template to handle efficient combination of operations and potentially detect optimisable pattern. Proto is a shoe-in for this. - the library entities should be made more generic by providing an extended integer adaptor facility that make one able to substitute a custom integer representation (like having extended_integer<GMP>) for corner case stuff. This adaptor will provide an interface able to turn these types into a type fulfilling the underlying Large Integer concept the library need to handle. Being compatible with GMP should even be a goal and a selling point for the library. - do real benchmarks and compare to existing state of the art solution, at least show benchmarks against GMP on realistic use cases. - the algorithm should be more generic and not be tied to the concrete type of large integer used. Frankly, licensing issues aside, a proto based library able to wrap GMP if needed and with Range based interface could already cover 80% of needs and provides correct speed. Then building on top of that to add new algorithm and new back end representation and adaptors would fill the library in a very smooth way.

13 34

failed to auto link
by Tal Agmon 26 Mar '11

26 Mar '11

It seems to be an issue with auto link when BOOST_VERSION ends with 0 (in example 1.47.0) windows fails to auto link since generate libs truncates '0'. May I suggest adding 'x' at the end (1.47.0x) Tal Agmon -- Sent from my mobile device

3 4

hash_combine vs hash_value
by Michael Goldshteyn 26 Mar '11

26 Mar '11

After reading the explanation of how hash_combine should be used, I am left wondering. Why is the recommendation for hash_combine different from what one would intuitively expect? Namely, given: struct MyStruct { int a; int b; int c; }; The recommendation via examples and documentation is: size_t hash(const MyStruct &s) { size_t hashValue=0; // Combine hashes of all elements hash_combine(hashValue,s.a); hash_combine(hashValue,s.b); hash_combine(hashValue,s.c); return hashValue; } Rather than what I would think is the expected correct approach: size_t hash(const MyStruct &s) { // For a composite hash, start by hashing the first element size_t hashValue=hash_value(s.a); // Then, combine with hashes of the remaining elements hash_combine(hashValue,s.b); hash_combine(hashValue,s.c); return hashValue; } Thanks, Michael Goldshteyn

5 8

[thread] Boost 1.46 and 1.46.1 fails on SunStudio/OpenSolaris
by Artyom 26 Mar '11

26 Mar '11

Hello, I've got failures when tried to use Boost.Thread on OpenSolaris with SunStudio, I hadn't got such problems with older versions The error is: "./boost/thread/future.hpp", line 422: Error: boost::unique_lock<boost::mutex>::operator=(boost::unique_lock<boost::mutex>&) is not accessible from boost::detail::future_waiter::all_futures_lock::all_futures_lock(std::vector<boost::detail::future_waiter::registered_waiter>&). It wasn't a problem in older versions of Boost. At least 1.41 worked fine for me. The patch that fixes this issue is attached. Artyom

1 0

[inspect] exceptions (FW: [Boost-users] no exceptions)
by Robert Kawulak 26 Mar '11

26 Mar '11

>From Boost Users ML: > From: Hochhaus, Andrew > I would like to use boost with BOOST_NO_EXCEPTIONS [1] and the g++ > -fno-exceptions flag. However, it appears that some spots in boost > library code: > > a) throw exceptions with the "raw" throw keyword [instead of > BOOST_THROW_EXCEPTION or boost::throw_exception] > b) use try ... catch blocks without "#ifnef BOOST_NO_EXCEPTIONS" guards Wouldn't it be a good idea to add checks for these to the inspect tool? Also, non-empty exception specifications are discouraged by Boost guidelines - should appropriate checks be added too? Best regards, Robert

11 48

[xint] quick review
by Domagoj Saric 25 Mar '11

25 Mar '11

Apologies for lack of proper review structure, I'm working with last bits of free time to post before the deadline... IMO, the proposed XInt, as can be downloaded from the vault, should NOT be accepted into Boost. Rationale: The reasons were mostly already covered by other boost.devel posters and pretty much all fall into the categories of a too coupled/inflexible and inefficient design. My primary concern is lack of support for true, efficient, no-fail-guarantee fixed-size integers: the provided fixed-size support still uses dynamic memory allocation (which can fail and requires/introduces EH code) and the nothrow policy does not in fact disable the use of exceptions (it only wraps and 'eats' them with try-catch blocks...which is just plain inefficient...this is like implementing malloc in terms of new instead of the other way around). For such low level operations, as fixed-sized integer arithmetic, it is quite reasonable to expect the implementation to be able to work even without linking to the CRT (i.e. no use of keywords new, virtual or throw)... This might at first be viewed as a possibly 'conditional yes' vote but since Chad has repeatedly said that he considers fixed-sized integers to be 'second class citizens' of his library I vote no for such a library... I am also not convinced by the rationale behind the different-than-built-in-behaviour (sign-magnitude, overflow NaN...). >"Chad Nelson" <chad.thecomfychair(a)gmail.com> wrote in message >news:20110302202855.5cd8067f@ubuntu... > >>On Wed, 02 Mar 2011 18:18:33 +0100 >>Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> wrote: >> >> [...] Also, it seems that the object always contains the copy count >> and a readonly boolean, which total 2 words, even if COW is disabled. > >Eliminating sixteen bits of overhead, on an integer that is almost >always going to be larger than 64 bits (and often *much* larger), seems >to be a premature optimization at best. 2 words are 64 bits on a 32 bit system and 128 bits on a 64 bit system...that's 25% of a 512 bit number. In fact, for a fixed-sized integer with disabled COW, there are, AFAICT, two redundant std:size_ts and two bools (in addition to the data pointer and dynamic memory allocation) per integer...that certainly is not so easily dismissible, especially on a 64 bit system and especially if we also consider the code that maintains those 'useless' data members...Quite to the contrary, I would sooner accuse your approach of premature pessimization (have you even examined the assembly output of your code?). In one post you complained that you are already tired of all the criticism on this list but please try to learn from this. The above misunderstanding and/or unwarranted dismissal of data layout/storage issues along with things like thinking that virtual inheritance is resolved at compile time, not knowing about the CRTP and misunderstanding of when to 'pass by value for performance' shows that you have holes in your knowledge which should make you more humble before honest criticism... You also complained about not getting enough feedback in the last iteration of your library, IMHO your attitude (of fixing your library on your own set of use cases) again may have something to do with that. I remember way back then people were already criticising the hardwired dynamic allocation and data-layout&storage coupling design. I proposed that you extract algorithms into free functions that simply take and work on data ranges as this would both eliminate template bloat (in your current design the algorithms get replicated for every integer_t instantiation) and allow for cleaner implementation of different data storage strategies. As far as I remember you gave little heed to these concerns/suggestions or complained that that would be too much time consuming to implement while OTOH you spent who knows how much time on implementing COW which AFAICT turned to be a misguided premature optimization (of an a priori inefficient design)... When I finally saw that you actually defended your hardwired dyn.mem. allocation by saying that it enables faster swaps I simply gave up on replying at that time deciding I'd wait for an official review (when boost.devel input has to be taken into consideration else you don't get accepted)... ps. I'm sorry if some/all of the above mentioned issues were already resolved (I did not manage to read through the whole discussion before the review deadline)... pps. I saw FFT being mentioned, you migh want to check out this http://drdobbs.com/cpp/199500857 ppps. You use a member-function-pointer based "unspecified bool type" implementation which produces suboptimal code on MSVC <10...IMO a plain operator bool would probably do just fine here as the built-in integral types also implicitly convert to bool... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

12 29

Unable to build boost python library in 1.46.1
by Richard Hadsell 25 Mar '11

25 Mar '11

I am trying to build the Boost 1.46.1 libraries on a Fedora 7 Linux system with the default g++ 4.1.2 and Python 2.5. The compilations do not find the python headers, producing a zillion error messages starting with one like this: In file included from ./boost/python/detail/prefix.hpp:13, from ./boost/python/converter/registrations.hpp:8, from libs/python/src/object/function_doc_signature.cpp:9: ./boost/python/detail/wrap_python.hpp:50:23: error: pyconfig.h: No such file or directory The reported compilation command looks like this: "/usr/bin/g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -fPIC -fno-strict-aliasing -fno-tree-ccp -march=opteron -pthread -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE -DNDEBUG -I"." -c -o "bin.v2/libs/python/build/gcc-4.1.2/release/address-model-64/instruction-set-opteron/threading-multi/object/function_doc_signature.o" "libs/python/src/object/function_doc_signature.cpp" I tried to follow the latest Getting Started instructions, which changed a bit from the last version I built (1.44.0) to build bjam: cd tools/build/v2 bootstrap.sh bjam install --prefix=../../.. cd ../../.. bin/bjam --user-config=user-config.LINUX_AMDF7 threading=multi instruction-set=opteron address-model=64 variant=release link=static,shared --stagedir=stageF7 stage My user-config.LINUX_AMDF7 file contains this: using gcc : 4.1.2 : /usr/bin/g++ : <compileflags>"-fPIC -fno-strict-aliasing -fno-tree-ccp" <linkflags>"-fPIC -fno-strict-aliasing -fno-tree-ccp" ; using python : 2.5 : /usr ; Can someone explain why the compilations are not getting the correct include path for Python (/usr/include/python2.5/)? BTW, the Getting Started page http://www.boost.org/doc/libs/1_46_1/more/getting_started/unix-variants.html in section 5.2.1 step 2 tells me to "Run bootstrap.bat". -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560

4 8

Re: [boost] A possible GSOC 2011 proposal idea
by Chad Seibert 25 Mar '11

25 Mar '11

Hi, First of all, many thanks for the feedback! Much of the discussion has been in whether it is possible for me to accomplish such a task over the summer. The answer is no; a library designed to meet Boost's standards will not be done over the summer. However, a substantial amount of the work will be done over the summer and it will continue over the next year until it is satisfactory. I will then be responsible for maintaining it for as long as required. In order for you to understand the scope of this project, it must be made clear that the project references itself many times. For example, MILP's and ILP's are solved using the exact same algorithms, so for all intents and purposes, they are the same. Second of all, solving ILP's using branch and bound or cutting planes both require a strong algorithm for solving their relaxed forms, i.e. their LP relaxations. Third, the bulk of the effort in solving LP's using the refined simplex algorithm is in solving a system of linear equations. This is by far the most difficult part of the entire project and is what I intend to spend the summer doing. It will be difficult for the aforementioned reasons; hence the topic of my GSOC proposal will be efficiently solving linear systems (LS). After GSOC, I will continue my work and write LP and ILP solvers. As for the scope of solving LS, there are many different algorithms designed to do just that. In order to limit the scope, I will not consider parallel algorithms or distributed algorithms. If the Boost community thinks that these are reasonable and I should forgo solving LP in favor of solving large (> 100,000x100,000) LS, we can certainly discuss this. The following algorithms are up for consideration: * LU decomposition for small matrices * Iterative methods for large matrices, such as conjugate gradient for positive definite matrices Of course, this will all be integrated into the already existing uBLAS library. There are many issues with getting such solver to work well in practice, namely reducing fill-in, numerical stability, and performance. In any case, getting a general purpose LS solver is the first step towards getting an LP solver running. Therefore, it is the focus of my work this summer and only afterwards will I work on LP-related algorithms. One last this is that it wasn't my intent for my pre-GSOC submission to be anywhere the quality required for Boost submission. It was only there to show my support towards this project and that I'm committed fully to its success. Thanks again for your feedback! Chad

7 15

[xint] Some preliminary review notes
by Vladimir Prus 25 Mar '11

25 Mar '11

Folks, I've promised to post initial summary of Boost.Xint this Monday, but real life has interferred. I apologise. I've made a pass over review emails, and it seems that a few high-level points were raised: - Whether COW is good idea or not, and whether current COW is truly thread-safe. - Whether ET should be used - Whether data copy in "a + b + c" should be eliminated - Whether the library is "fast", in particular: - Do algorithms have best big-O complexity? - Are fixed-size integers fast enough - Whether it would be better to separate algorithms and data represetation - Whether it's possible to optimize specific cases (addition of 128-bit integers, ln+gamma, etc), by some template specializations, or other mechanism. I might have missed something, and I'd appreciate if I was set straight. Please note that we're talking about high-level issues. The number of specific comments is already too high for me to even try tracking them all. At the same time, Chad, I'd appreciate some input from you. - Could you express your current world view of those issues. Whether they are real, important, and what plan do you have about them, if any. Note that you are not required by any means to address every raised concern, but some coherent plan of action will be very important both for further development of your library and for review result. - Do you keep track of technical issues raised? Could you share that list? Thanks, -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40

2 1

[context review]
by Giovanni Piero Deretta 25 Mar '11

25 Mar '11

First of all, I think the library as some issues and it should not be accepted as it is, but see below. - What is your evaluation of the design? The interface is pretty simple and it seems fine on a first evaluation, but I think there are some issues. The first issue is that the destructor of the context class will (at least by default) happily destroy the stack. This unfortunately will leak any resource owned by any object on the stack; This is not unlike destroying an allocator before having destroyed all allocated object. A stack can only be safely deallocated if either has been completely unwound or if it doesn't own any resources (note that is not enough to just destroy any stack allocated object). Context should either: a) provide an interface to unwind the stack (by automatically trowing a special exception for example), or b) detect whether the stack has not been unwound and assert in debug mode in the destructor. As it is, is not clear the level of abstraction this class wants to be. It looks like is trying, using RAII, to manage context creation and destruction safely, giving a false sense of security. Context is neither copyable nor movable; I can understand the reason for making it non-copyable, but I see no reason why it shouldn't be movable. Without either capability it is hard to make context interoperate with existing code without forcing to dynamic allocation. Context is templated on both the context implementation and the stack. The first problem is that the concept requirements for the Stack template arguments are not stated. Second, the stack type should not be part of the context type: the primary reason for specifying different stacks is for option of having the guard page: enabling this should not change the type of Context and it should possible to specify it at runtime. Basically I'm advocating for type erasure; note that it can (and should) be implemented without additional memory allocation. The trampoline function can be defined in such a way that the custom deleter will be invoked after the stack is unwound. Regarding the CtxT type, instead of this template parameter there should be a program wide default controllable at compile time by a macro; I saw elsethread that Oliver is already leaning on this idea. As it is the context class is IMHO flawed and I'm against its inclusion in boost right. I'll be very happy to change my vote if I see a better implementation. A good abstraction layer around the low level context, among other things, should support clean unwind of the stack (or detecting an not-unwound stack), generic functors (and not just function pointers) for type safety and custom deleters. On the other hand the detail fcontext class seems a good, if maybe not complete, portable implementation of a low level ucontext-like API. I would be in favor of a simpler version of context which consists solely on the fcontext class (with a guarantee that this type is a POD), plus the make_context and swap_context functions. A user will have lower expectations from such a low level API and at the same time will give more freedom for other people to implement on top of it. A safe context class would just be one of the client of the API, other library authors could either use Context of the underlying fcontex directly depending on wether they need the speed or safety. I think this basic API could still be tweaked [but my vote won't be conditional on that] to add extra functionality: * Instead of supporting a 'fc_link' a-la ucontext, have the callback function return a new context (it is void now). 'fc_link' is useful only on some limited cases (usually when you have an external scheduler managing your contextes), while the having the callback return the 'next continuation' has more applications (note that fc_link can be implemented easily in term of the continuation returning variant, but the reverse is harder). This is very useful, for example, to implement some kind of 'exit_to' functionality (unwind the stack and restore another context), a key piece for safe context destruction. * Give to fcontext_swap the ability to exchange a parameter with the other context: fcontext_parm_t swap_fcontext( fcontext_t * ofc, fcontext_t const* nfc, fcontext_parm_t parm) where fcontext_parm_t is either union fcontext_parm_t { void * ptr; int int_; }; or simply intptr_t; Swap_fcontext saves the current context in ocf and restores the context ncf as usual; additionally, if ofc was 'captured' on a call to swap_fcontext, this call will return the value of parm on the original context. This extra parameter is equivalent to the second parameter of longjmp. If ofc was created with make_fcontext, 'parm' will be an extra parameter to the function. Note that because you can't mix and match parameterful and parameterless swap_fcontext, you should only have the former as it can be potentially implemented with little or no overhead. * Add a variant of swap_context that allows executing a function on the destination context (in this case 'parm' would be passed parameter to this function. This is mostly useful for injecting an exception on the destination context. This can be potentially implemented on top of the existing functionality, but would slow down every context switch; a possible efficient implementation would manipulate the destination stack to add a call to the function on top of it, so that the cost is paid only when required. All the previous improvements are implementable unobtrusively on top of the exiting API, but such implementations will be much less efficient. I'm suggesting that they should be part of the basic API becausecan be implemented with zero or near zero overhead when not used. - What is your evaluation of the implementation? The implementation seems reasonably efficient, but I have seen elsethread suggestions to make the constructor more expensive (read multiple memory allocations) in exchange for flexibility; this is IMHO wrong, the constructor should not be assumed to be a non critical operation. In fact I think that most of the proposals can be efficiently implemented without additional memory allocation by reusing the already available stack (which can be reused). Most of the 'throw' statements in the context class should actually be asserts. Make_fcontext requires a call to get_fcontex first, a-la ucontext: there is no reason for this, just merge get_context with make_context (and drop the unused set_fcontext). The posix ucontext wapper and the windows fiber wrapper should be made API compatible with fcontext. Regarding the assembler implementations of fcontext, I think they could be simplified if the fcontext itself was represented as a single pointer to the top of the stack. This would save some instructions to move the source address from the stack return address to the fcontext struct and back. The i386 implementation could use register calling convention to simplify the implementation and speed it up. Both the i386 and amd64 asm implementation use the 'ret' instruction to restore instruction pointer of the destination context. This will always be mispredicted (costing 20 cycles or more, easily more than the rest of the swapping code). Just jmping to the the destination will save a push and will give the CPU a chance to predict the jmp (modern CPUs have some dynamic prediction capability for indirect jumps). Bot the i386 and amd64 asm implementation save and restore the fpu control word (the amd64 both x87 and SSE2 control words). Last time I timed it, this was a relatively an expensive operation, not sure about current architectures; I do not think this should be saved and restored: the compiler will treat it as a caller clobbered variable and will take care of it in case of implicit manipulations. The user should be prohibited from changing it across a swap_fcontext call. As a minimum, there should be a compile time option to disable the saving. Note that many posix implementation of the ucontext API need to restore it (along with the full register set) because on traditional unices a context could be captured asynchronously by a signal, but it is not the case with boost.context. BTW, the current code is already inconsistent because it is saving the SSE2 control world on amd64 but not on i386. For posix systems lacking ucontext, fcontext can be implemented using the sigaltstack trick (this can actually be faster than ucontext if the non signal restoring _longjmp is used). For reference see: http://www.gnu.org/software/pth/rse-pmt.ps Finally, an implementation on top of boost threads would be nice. It will be very slow, but useful for portability and when performance is not an issue; also won't probably be much slower than ucontext. - What is your evaluation of the documentation? The documentation is very minimalist and should be expanded. It assumes the user is already familiar with the context swapping concept. The posix ucontext APIs man page are a good start. The fcontext class should be documented. The first time I read the documentation I understood that the constructor captured the current context a-la setjmp (a very bad idea, IMHO). I had to read the implementation to convince myself it was not the case. - What is your evaluation of the potential usefulness of the library? This is definitely not going to be one of the most used boost libraries, but it is a required piece to implement other libraries like coroutines, user lever threading, tasks, etc. - Did you try to use the library? With what compiler? Did you have any problems? I didn't try to use the library. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I did an in-depth study of the implementation. - Are you knowledgeable about the problem domain? I consider myself fairly experienced in this domain: As part of the GSoC project Boost.Coroutine I did some pretty in depth research on the topic and I implemented a very similar functionality; BTW, I see that Context borrows many ideas from Boost.Coroutine implementation (some of the tricks in the fiber wrapper look quite familiar); a small acknowledgement would be appreciated :). -- gpd

4 7