March 2011 - Boost - lists.preview.boost.org

boost build: C/CXX(flags) and if testing howto
by luxInteg 28 Mar '11

28 Mar '11

I am building boost on a linux64-bit amd64 machine with these --gcc-4.5.2, boost-1_46_1 python-2.7.1 I have two questions regarding building boost: a) Is there a way to set options for ${CFLAGS}/${CXXFLAGS} when running sh bootstrap.sh ? b) Is it of any use to test a newly compiled build of boost AND IF SO is there a way to invoke testing the said build with bjam or whatever?

1 0

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