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

Boost related topics proposed by the CGAL Project at the Google Summer of Code 2011
by Andreas Fabri 23 Mar '11

23 Mar '11

Hello, The focus of the CGAL Project is computational geometry, and we use boost wherever it makes sense. We are mentoring organization at the GSoC 2011, and we are looking for students who master boost and who are interested in replacing home-grown solutions by boost solutions in the CGAL library. We propose two topics: Replacing some Basic Non-Geometric Tools in CGAL by Boost/TR1/C++0x Functionality http://www.cgal.org/project_ideas.html#boostification Switching from CGAL::HalfedgeGraph to boost::PlanarEmbedding http://www.cgal.org/project_ideas.html#embeddedGraph Best regards, Andreas Fabri

1 0

Library format required for inclusion in Boost
by Mathias Gaunard 23 Mar '11

23 Mar '11

Hi, I'd like to ask a few questions about what libraries that wish to be included into Boost must look like, and I would like to know whether libraries need to fulfill those requirements for the review or can do so later. Build system: integration with Boost.Build is necessary, additional CMake scripts is a plus. Documentation: the Boostbook toolchain seems recommended, but not necessary. Is that correct? How free are we? Does the documentation necessarily need to be generated with Boost.Build as well? Test system: something that the regression test suite can eat. What is that format? Is that restricted to Boost.Test run through Boost.Build?

4 3

[BGL] clear_out_edges and MutableIncidenceGraph
by Shaun Jackman 23 Mar '11

23 Mar '11

Hi, adjacency_list implements clear_out_edges, but it's not required by any of the graph concepts: http://www.boost.org/doc/libs/1_46_1/libs/graph/doc/graph_concepts.html Could it be added to MutableIncidenceGraph? Actually, now that I check, I don't see MutableIncidenceGraph on that page either, although it is in graph_concepts.hpp. MutableIncidenceGraph requires remove_edge and remove_out_edge_if. clear_out_edges would fit nicely in here, and clear_in_edges in MutableBidirectionalGraph. Cheers, Shaun

2 1

vault unavailable?
by Oliver Kowalke 23 Mar '11

23 Mar '11

Hello, http://www.boost-consulting.com/vault is unavailable since last night. Will it be available soon? thx, Oliver -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

1 0

boost at gitorious.org
by Ivan Sorokin 23 Mar '11

23 Mar '11

Hello! http://gitorious.org/boost/svn is not updated since 15 September 2010. I tried to ask its owner Troy Straszheim, but he didn't respond. As I understand this repository is something like an official mirror of boost svn. Does somebody know how to bring it back to live?

4 3

[odeint] gsoc 2011: finalization of odeint
by Mario Mulansky 23 Mar '11

23 Mar '11

Dear boost community, I would like to propose a project for the GSoC 2011, namely to improve the odeint library currently living in the boost sandbox [1] with the (optimistic) goal to put it on a level suitable for a boost review process. I have been working on this library for about one year now, although I couldn't spent much time on it during the last months. The other author of odeint is my colleague Karsten. We have had contact to this mailing list before [2], getting few, but rather positive feedback. The odeint library is a modern, template based, generic, C++ library for integrating (solving) initial value problems of ordinary differential equations. Such an ode is usually given as dx/dt = f(x,t) with x(t=0) = x0. x here is generally vector valued, possibly high dimensional. The easiest method to solve this problem is the Euler-method, where you introduce a small value Dt and then iterate x(t+Dt) = f(x,t)*Dt. Obviously, in real applications one uses more sophisticated methods, a well known class are the Runge-Kutta methods [3], suitable for many cases. Additionally, there exist special methods for system where the time evolution has conserved quantities, called symplectic methods. Furthermore there are methods for stiff systems and many others. For odeint, our first focus lies on Runge-Kutta methods. We have implemented several such methods together with error control routines and lately added dense output functionality. Our very recent code is a generic Runge-Kutta stepper that allows the user to build any Runge-Kutta method at compile time by providing the appropriate constants and is based on fusion::vectors. Karsten wrote a good article on that [4], unfortunately in German. There are also symplectic routines for Hamiltonian systems and we started to add implicit methods as well. We also have unit tests based on the boost test framework and some basic documentation. The library is currently at a level where it can be used in scientific applications and it is indeed in use by us and several other people in an academic environment. The major enhancement of our library over existing ones like gsl or methods from the numerical recipes is that our routines do not depend on the container type used to represent the vector x. So our library works with the usual std::vector<double> and array<double,N> but also with vector< complex<double> > (already a major improvement over gsl and nr, which we get for free, basically) and blitz++ arrays. The major strength of this approach, however, is seen when you want to solve odes on complex networks where you have to implement your own, non-trivial container type representing some kind of network. With odeint you can fully separate the network-implementation from the ode-solving algorithm. Furthermore, we are able to easily employ the power of CUDA devices to solve odes by the help of the thrust library and using thrust::device_vector as our container type. It is also possible to use odeint with arbitrary precision types like the gmp library. Some more, unfortunately slightly out-dated, information about odeint can be found in [5]. What are my plans for a GSoC? 1. There are still some parts of the library which are not satisfactorily designed and need to be rethought. This is where we could really need the help of an experienced mentor to create a clean, well structured library. 2. Add methods with varying order (burlisch stoer). 3. Add dense output and error control to the generic runge-kutta implementation. 4. Add convenience function that allow users an easier access to the libraries capabilities. 5. Create an observer interface that allows the user to analyze properties of the system while integrating the equations. 6. Make everything ready for a boos review. Points 1-5 can surely be realized during the GSoC period, I believe. And whatever time is left I will spend on documentation and review preparation. A few words to myself: I'm currently a PhD student in physics at the University of Potsdam working on problems in the field of nonlinear dynamics. Solving odes is basically every-day-work for me and I have a used many of the routines in odeint for my scientific research. Thanks for reading. I greatly appreciate any feedback! Regards, Mario Mulansky [1] https://svn.boost.org/svn/boost/sandbox/odeint/ [2] http://boost.2283326.n4.nabble.com/library-proposal-odeint-td2670019.html [3] http://en.wikipedia.org/wiki/Runge–Kutta_methods [4] http://www.c-plusplus.de/forum/282091 [5] http://www.codeproject.com/KB/recipes/odeint.aspx

4 6

[context review] Windows ABI requirements
by Holger Grund 23 Mar '11

23 Mar '11

Hi, I've had a very brief look at the x64 ASM Windows code as I think I raised concerns about this before. As always, I'm pretty busy and I probably won't be able to properly review the entire lib. Looking at the fcontext_x86_64_ms_pe_masm.asm it would seem that several ABI requirements are violated and it is not clear to me why this would always work. For instance, the stack is not properly aligned in the call to _exit & set_fcontext. At least _exit can call into user code, IIRC (preterminators & terminator registered via .crt$x* sections) and that code may require a properly aligned stack. I don't see proper unwind descriptors. What happens if an async exception is triggered in the middle of set_fcontext? The x86 Windows version seems to have similar problems. IIRC, the dispatch logic checks for EH registration nodes to be on the stack for x86. What happens if an untrapped exception is trigger in a code path called from the context entrypoint? It would seem that there is an unwind chain via make_fcontext (which doesn't appear to have any unwind description and would therefore assumed to be a leaf function). Is its state necessarily live when set_fcontext is called? What guarantees are there that poking a few fields in the TIB is good enough to properly switch the context? At least FLS has more than one field in the TIB. There's also bookkeeping for whether registered callbacks have been called. Why is saving the register you save enough? Why wouldn't a future version of Windows just take down the process if it detects stack hacks. I believe, the unwinder checks the stack pointer in the unwind context against stack limits and for 8-byte align at each caller in the chain until a barrier is found. How are you certain that kernel32/kernelbase/ntdll don't assume that there's a guard page (where guard page has the Windows defined meaning as in PAGE_GUARD) at the end of the stack? Even if that all works today, how can you be sure it will on Win8, 9 and beyond? To be honest, I don't think a library outside the operating system is not the proper place to do this kind of thing at all (and even if you're part of the OS it's an incredibly hard thing to get right -- UMS had tons of problems in Win7 RTM) BTW, glancing over the docs, an implicit conversion from size_t to protected_stack seems weird, but that might just be a glitch in the doc build. Thanks! -hg

2 4

Getting started guide updates
by Vladimir Prus 23 Mar '11

23 Mar '11

Folks, I've tried to update the getting started guide (for Unix so far) to better explain building, in particular: - To make the "bootstrap + bjam" process the only documented one, since it turns out to be fairly painless on Unix - To clarify some common questions inline The result can be previewed at http://lvk.cs.msu.su/~ghost/unix-variants.pdf , see section 5. I would appreciate if folks take a look and suggest whether it can be improved further. I plan to make a similar update for Windows, but it's somewhat tricker. Thanks, -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40

5 8

stream-cons & stream-cdr using boost.proto & boost.fusion
by Niitsuma Hirotaka 23 Mar '11

23 Mar '11

I try to make stream-cons & stream-cdr using boost.proto & boost.fusion. code is here http://d.hatena.ne.jp/niitsuma/20110323/1300850731 But this is not work in the following case auto s= stream_cons(2,stream_cons(1,0)); auto ss= stream_cons(3, s); std::cout << proto_force( proto_force(ss.cdr.car).cdr.car).car << std::endl; //not work std::cout << stream_cdr(stream_cdr(ss)).car << std::endl; //not work Where is problem?

1 0

Boost Talk: "How I Code" (?)
by Gottlob Frege 23 Mar '11

23 Mar '11

I was wondering if anyone here wanted to take part in a Boost talk about real world programming experiences. Something like "rules to code by" or "nuggets of experience" or...? ie if you had to give your 1 favorite rule you code by, what would it be? For me it might be: - Inversion Principle or - Comments with the word "otherwise" are the best comments I could explain the Inversion Principle, or tell the story of when I started using "otherwise" in comments, within 10-15 minutes, maybe less. Then someone else could explain something helpful they've learned over the years. It could be the easiest way to get your feet wet in giving a talk - you just need to do a few minutes. I don't think there is much detail needed actually - I think just knowing that the author of so-and-so library actually does use TDD daily, or that a respected regular on the list does things this way, etc - just *knowing* that someone you respect does things a certain way, might be all that is needed. You can always find more details about certain rules/principles on the web, so in-depth explanations aren't really necessary. The important part, I think, is that someone you know (even just "virtually") is doing things that way. I'm thinking it would be called "How I Code". Not "How you should code" (although that might be implied). Just how each presenter codes in real world programming tasks. But I can't do this alone - no one wants to hear just about how I code - they want to hear about how you code. Plus I will probably have another Boost talk to frantically make last minute changes to, so I can't handle 2 talks - but I can help get people together and organize this and do a part. Overall, hopefully it would be more discussion than presentation, and maybe even some contradicting favorite rules - real life programming is never that simple such that one rule always works, right? Tony Van Eerd

10 19