- Boost - lists.boost.org

[context] very brief review
by Phil Endecott 28 Mar '11

28 Mar '11

Dear All, This is a very brief note about the proposed Boost.Context that is not really worthy of being called a "review". My main point is that I am pleased to see this functionality being broken out as a separate library, rather than being hidden as a detail of a higher-level functionality e.g. co-routines. This is something that should be encouraged, and furthermore I think that the weaknesses (e.g. documentation) should be reviewed in the context of the alternative being to hide all of this inside Boost.CoRoutine and not documented at all. I have had a quick look at the ARM assembler implementation. Parameter-passing conventions especially wrt the various FP and vector registers is not something that I know much about. If I were going to use this code somewhere, I would like to see a note in the docs or in the source pointing to the reference documentation that the author used to decide what should and what should not be saved. It seems that the ARM code assembles to only three or four instructions for each function. I would have written that as inline assembler, rather than in a .S file. In my view, after this very brief look, I believe that the library should be accepted. Cheers, Phil.

2 1

re-installing boost openMPI
by luxInteg 28 Mar '11

28 Mar '11

Greetings I am playing with boost on a machine with these:- --amd64 linux, gcc-4.5.2 boost-1_46_1 OpenMPI I have compiled boost-1_46_1. I do not yet have mpi installed and later on after MPI is installed I would like recompile boost with mpi support. I would like to know if there are any problems associated with reinstalling boost over an existing installation sincerely luxInteg

2 1

[phoenix] comma woes
by Steven Watanabe 28 Mar '11

28 Mar '11

AMDG I was going to post a response to Lorenzo's question using phoenix, but I ran into a few issues. The initial version I wrote compiles, but doesn't work. #include <boost/phoenix/core.hpp> #include <boost/phoenix/operator.hpp> #include <iostream> #include <vector> #include <algorithm> int main() { double sum = 0.0; int factor = 10; using namespace boost::phoenix; using namespace boost::phoenix::placeholders; std::vector<double> v(3); v[0] = 1.0; v[1] = 2.0; v[2] = 3.0; std::for_each(v.begin(), v.end(), ( ref(sum) += factor * _1, ref(std::cout) << "Summed: " << ref(sum) << std::endl )); return 0; } This is because the overloaded comma operator is provided by statement.hpp, not operator.hpp as I had erroneously assumed. Can we please make sure that the built-in comma operator can't get silently called? After I added #include <boost/phoenix/statement.hpp>, it still doesn't compile and I have no idea how to make it compile, because it tries to copy std::cout. I'm guessing that the result of the comma operator is being deduced as a non-reference, since the cout part compiles fine by itself. In Christ, Steven Watanabe

3 7

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