- Boost - lists.boost.org

Google Summer Of Code
by Brian Bartman 30 Mar '10

30 Mar '10

Hello my name is Brian Bartman and I am an undergraduate at Kent State University Majoring in computer science. I was interested in the bits & ints project, specifically Compressed array and Compressed vector as well as the utilities for bit mask manipulation. Could some one help me better understand the requirements of this project? I would like to draft a proposal for GSoC 2010 and wanted to better understand the project before I write a proposal.

4 8

Re: [boost] [MSM] using irow "internal transitions" and constructorarguments for frontend ?
by Christophe Henry 30 Mar '10

30 Mar '10

Hi, >We have seen that there was a review early this year is there a boost >version where msm will be officially part of boost lib ?. I'm finishing it and hope to bring it into the 1.43. Hopefully, the newest version will be online in a few days. If you cannot wait, I can send it to you before. >Is anybody used boost::msm in a real life project is there any >measures about stability ?. I did but I'm biased ;-) Seriously, I know a few people who did and reported here and there a bug (which is usually corrected very fast) but nothing critical. I'd also be interested in live reports. >Furthermore we had the following problems during our evaluation: > >1.) in the documentation there is a section about internal transitions >using irow : I think this is in the documentation from the sandbox, not the vault. The doc in the sandbox is not up to date because I made an almost full rewrite. MSM 2.0 supports no internal transitions, but the subject was brought by Michael Caisse during the review and the coming version 2.10 has them. The sandbox version also has internal transitions and is usually up to date, except, as I said, the doc (but not for long). >2.) State machine constructor with arguments in the documentation >there is an example but we did not managed to get it working > >is this example correct in the documentation ?. The example is correct and should work but I admit I'm unsure if it was already in the 2.0. I guess not. Please try the sandbox or the coming 2.10. But thanks for telling me, I just realize I forgot this part in the new doc, so I will add it. Thanks, Christophe

2 1

BoostCon2010 lodging - M4MW
by Robert Ramey 30 Mar '10

30 Mar '10

I'm making arrangements to attend BoostCon2010. I'm reviewing the Aspen Meadows Resort web page. Seems like a very fancy and nice setup. The rates are $159 + 10% + $18 / day for one or two persons. I expect to be going by myself as my wife considers attendance at such an event as boring beyond belief. I'm also a free lance software developer so I will be paying myself. So it would be economically advantageous for me to share this with at least one other person (The room has a capacity up to 4 persons). So anyone who want's to split this with me should let me know via private email ramey(a)rrsd.com. BTW- I'm still considering options about getting there. I haven't been on an airplane since 1995. From what I hear, it's even more unpleasant now than it was then. But it's a long drive from where I live. Anyway ... Robert Ramey

2 1

Boost.Graph GSoC 2010
by Cezary Bartosiak 30 Mar '10

30 Mar '10

Hi, I am Cezary, a student of computer science at the Cybernetics Faculty, Military University of Technology, Warsaw. I am interested in developing the BGL. I've got an idea related to the Topology Generators. I have participated in a project concerning epidemics spreading and, as a part of the project, we have implemented several social networks generators (Barabási–Albert model for instance). I hit upon an idea to implement these algorithms apart from proposed topology generators. I know that Boost.Graph contains some algorithms for generating networks, I would like to add some extensions: 1. There is Erdős-Rényi model generator in two versions G(n, p) and G(n, m). I think I could provide some additional implementations for specific cases, I mean: a) Fast generator of sparse graphs inspired by http://www.inf.uni-konstanz.de/algo/publications/bb-eglrn-05.pdf. b) Fast generator of dense graphs, algorithm by Keith M. Briggs Mar 31, 2006 (the only implementation of this one I've seen in NetworkX library). 2. There is only Beta-model generator of Small World network in the library. I would like to add Alfa-model generator as well as Kleinberg model generator. Here are some interesting materials: http://tam.cornell.edu/tam/cms/manage/upload/SS_nature_smallworld.pdf http://www.bsos.umd.edu/socy/alan/stats/network-grad/summaries/Watts-Six%20… http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.83.381&rep=rep1&ty… 3. At the moment we've got only PLOD algorithm to generate ScaleFree networks. I could provide other ones: a) Basic generator often seen in popular libraries, for instance NetworkX. b) Generalized generator with probabilities of adding new edges and rewiring existing ones. c) Simplified models generators: A (uniform attachment) and B (no growth). Coming back to Topology Generators I would implement them for some "basic" topologies, let's say: path, star, cycle, wheel, ladder, grid, hypercube, barbell, complete, frucht and many others if time remains... I would be glad to know your opinion. Best, Cezary

2 2

[GSoC] Advanced data structures library
by Rui Gonçalves 30 Mar '10

30 Mar '10

Hello, I'm new to this community. My name is Rui Gonçalves and I'm thinking about submitting an application to Boost in Google Summer of Code. In particular, due to my own programming interests in data structures, generic programming and abstraction layer developing in general, I would be very happy in developing an advanced data structures library. As suggested in the ideias page, it would have includes various types of heaps and queues. I haven't had time to look at all different libraries, but if there is some known data structure with implementation needed, I would not mind implementing that too. I had a look at the /boost/pending available implementations. A lot of code could be reused / ported; however, I think that the source code could be more standardized between heap implementations. I'm thinking in a STL-like implementation, like: template < class T, class Heap = binary_heap<T>, class Compare = less<T> > class priority_queue; template < class T, class Container = vector<T>, class Compare = less<T> > class fibonacci_heap; I already looked in books for some more obscure details of each algorithm, and haven't found anything excessively difficult. This seems a rather simple project (although I recognize it can take some time). Is there some convention or requirements for data structures in Boost? Is there any difficulty that I should be aware of but didn't notice, or any detail about GSoC that I should know? (I'm new to that program and I feel kind of lost). Thank you in advance for your help, Rui Gonçalves

3 4

[MSM] using irow "internal transitions" and constructor arguments for frontend ?
by Richard Szabo 30 Mar '10

30 Mar '10

Hi All We are in a process to evaluate boost::msm 2.0 we would like to use it in our project. We were using sources from http://www.boostpro.com/vault/index.php?directory=Msm version 2.0. We have seen that there was a review early this year is there a boost version where msm will be officially part of boost lib ?. Is anybody used boost::msm in a real life project is there any measures about stability ?. Furthermore we had the following problems during our evaluation: 1.) in the documentation there is a section about internal transitions using irow : see : irow < Empty , cd_detected , &p::internal_action ,&p::internal_guard > but we did not find the irow definition in the sources ?. 2.) State machine constructor with arguments in the documentation there is an example but we did not managed to get it working is this example correct in the documentation ?. struct player_ : public msm::front::state_machine_def<player_> { player_(int some_value){…} } This is still possible, using the back-end as forwarding object: typedef msm::back::state_machine<player_ > player; player p(3); // do something with the state machine Thanks in Advance Richie & Michi

1 0

GSOC Boost BigInt design issues
by swagat konchada 30 Mar '10

30 Mar '10

> >swagat konchada wrote: > > > > I had a look upon the BigInt code from the sandbox. It's > > entirely wrapped around GMP(linked to gmblib). > [snip] > > That is uncompatible with the Boost license, which hinders > > the distribution > > of a Boost_bigInt library which wholly is a wrapper around GMP. > > > > Keeping in view the above issues what should be our priority? > > Improving the > > wrapping around GMP for time being or Starting Boost's own version of > > BigInt. I see mixed reactions on this subject. My personal > > opinion is that > > suggested by Paul A. Bristow, i.e, of a Boost's own BigInt, > > which I think is in line with Boost's long term aspirations. > > > Rob Stewart wrote > The usual idea is that BigInt would provide expression templates and other > optimizations to avoid calling the back end engine inefficiently. That may > require an adapter layer between the user-visible BigInt API and the > computation engine, like GMP, at the back end, to insulate the API from > differences in the back end engines. (Then again, there may be nothing left > to a layer above the adapter layer; I'm not saying there must be three > layers.) > > If GMP is an optional batck end supported by BigInt, along with other back > ends, controlled by conditional compilation, then a BigInt user can choose > to use GMP if they like, but the licensing issue will be theirs and not > Boost's. > > HTH, > > _____ > Rob Stewart robert.stewart(a)sig.com > Software Engineer, Core Software using std::disclaimer; > Susquehanna International Group, LLP http://www.sig.com > > If we consider performance issues based on design, planning the BigInt architecture could be designed in two ways 1. 3 layers to allow optional binding to Boost's own bigint, GMP, or anyother bigint library, for the user during compile time. 2. 2 layers if we plan to limit Boost.Bigint's options to only itself and GMP. In a 3 layered architecture, 3 function calls would take place for each overloaded operator, whatever the option chosen by the user. Whereas in a 2 layered architecture, in which only GMP is an extra option, there is an equal probability of a user using Boost's own bigint or GMP and thus half of the times, 2 function calls are made and in the other half only 1 function call for each overloaded operator. This means doubling in the number of function calls. Though I realize most of the time is spent inside the function rather than in calling the functions, does this result in an overhead we should worry about? -- Problem is a phenomenon indicating lack of thought. Swagat Konchada

3 2

Library dependencies and intrer-library code reuse
by Zachary Turner 30 Mar '10

30 Mar '10

There's a lot of chatter on the list recently about how to "grow" boost. I wanted to add my own idea to the pot. Due to the scope of what I describe, I don't think it's reasonable to expect everyone to be on board with it because TBH it's a lot of work, but I'm just throwing it out there, and I think that if you forget about what would be involved in actually making it happen, it actually has many highly desirable properties. But comments would be welcome. So anyway, one of the recurring questions that pops up over and over and over is that of whether or not a library should reinvent the wheel, or use some data structure / class from some other library. On one side of the fence, there's people who say that it's often ok to reinvent the wheel inside library A if it avoids introducing a dependency on boost library B. Generally, the problem is that introducing a dependency on B a) increases compile time, because often only an extremely small component of library B is needed, but the header-onlyness of most libraries causes inclusion explosion, and b) introduces logistical problems when library B is not "permitted" for use in a certain organization. This is becoming increasingly common as certain organizations begin whitelisting boost libraries that are allowed in their codebase. On the other side of the fence, there's people who say that reinventing the wheel is almost always bad. The reasons for this are obvious and I think everyone here is well aware of the issues, so I won't repeat them. Note that I'm not taking sides here, just pointing out that the argument against reinventing the wheel is well understood. Is there a way to solve *both* of these problems at the same time? I think there is. Consider the following system: 1) Library maintenance is more flexible, and not necessarily limited to only a single maintainer or a whitelisted group of maintainers. There is another thread on this topic already, so rather than debating this particular point here, it's probably better suited in the other thread. For the purposes of this post, just assume that there is *some* system, with completely unspecified parameters, where there is *some* way for people to easily get their own code into an existing library that they are not necessarily the author / maintainer of. At the very least, *other library authors* would be given a "fast track" to submitting changes to other libraries, whatever "fast track" means. 2) All libraries would be required to support both pimpl'ed and header-only implementations. I realize this is sort of a huge undertaking and requires retrofitting tons of libraries, but I think the advantages are worth it. The users end up winning in the long run, nobody ever has to have this debate again about whether or not header only libraries are good or bad. If you want header only libraries, use #include <boost/someheader.hpp>. If you want pimpl'ed libraries, use #include <boostp/someheader.hpp>. pimpled' headers only include other pimpled headers. Also it makes the system I'm describing possible. 3) The boost build process is changed to allow additional options that either: a) automatically select all libraries for external visibility, b) select a specific list of libraries for external visibility, or c) select a specific list of libraries to disable external visibility. During the build process, what is currently known as the "boost" directory (e.g. the boost folder in #include <boost/shared_ptr.hpp>), gets a different name. Perhaps it's changed to something like <boost/internal/shared_ptr.hpp>. This happens EVERYWHERE. All boost library header and source files would need to be updated to include from boost/internal. For those libraries that were selected for external visibility, a symlink is created under the boost directory inside the internal directory. On windows a directory junction is used. Note that directory junctions are supported since Windows 2000, so I don't think this is an issue. It's very easy to create them, just that people rarely do. The end result of this is the following: 1) Users notice minimal impact. The only difference, in fact, is that if they want pimpled implementations they #include <boostp/...> instead of #include <boost/...>. This means the current behavior continues to be the default. After they build boost, the build process handles all the logistics. Everything is already in the correct structure to "just work", all symlinks have been created as described in 3) above, and the user only needs to set their include path to the top level boost directory. 2) All boost libraries can use all other boost libraries with ease, regardless of whether or not an organization's policy allows use of those libraries in user code, because internally all libraries include from boost/internal. 3) Despite the fact that all these additional dependencies that a user isn't technically allowed to be using due to his organization's policy are indeed being used, compile times can be kept sane because the user has access to pimpled libraries, and pimpled libraries only depend on other pimpled libraries, which is possible since all libraries are required to support pimpled versions. So there we go. Does this work, and if not why not? Even if we agree it's a huge undertaking, is it worth it? And if not, why not? Zach

9 16

Boost, Decoupled and Accelerated
by David Abrahams 30 Mar '10

30 Mar '10

Hi All, I know I'm not the first person to notice that, as Boost has grown, it has become harder and harder to manage, Subversion is getting slow, our issue tracker is full to overflowing, and the release process is a full-time job. For me, this situation has taken a lot of the fun out of participating. It's time to make Boost development fun again. To that end, Troy Straszheim and I have started building a system called Ryppl to decentralize development, testing, release, and installation of interdependent projects, like—but not limited to—Boost libraries. I will be holding a session **Tuesday night at BoostCon** to formally unveil this system and demonstrate it in action, and I intend to propose that Boost make the move immediately thereafter. I believe this project has the potential to change the face not only of Boost, but of open-source software in general. By the time of BoostCon, ryppl will be live, and we'll be able to use it to work on Boost. I encourage anyone who is interested in these developments to register for BoostCon immediately. If you're interested in working on development of this system, *please* send me an email; we can really use your help. Be forewarned, though: this may not operate like many other open-source projects. Given the short period of time remaining before the conference, we have little time for design discussion and debate, and we need to be maximally effective: there's simply no time to waste. You can expect me to take a “Benevolent Dictator” role, if not “For Life,” (BDFL) then at least “For the Time Being” (BDFTB). Cheers, -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com

12 23

[GSoC] Generic Linked List library
by Thomas Mullaly 30 Mar '10

30 Mar '10

Hi, my name is Thomas Mullaly. I am currently an undergraduate in the Computer Science department at Kent State University and I am interested in contributing a generic linked-list library to Boost as a GSoC project and I just wanted to see if there is any interest from the Boost community about having these contributed as a library. I am implementing the linked lists project from 'Elements of Programming' (ch. 12, I think), and am trying to provide lists for both constant-time size and constant-time splice. My library currently implements a number of variations of both singly- and doubly-linked lists, and I have implemented a wrapper that adds a node count and acts as a counted list. While the basic list types are already implemented, there is still a lot of work to done on them. For my GSoC project I would like to integrate allocator support into them, clean up the existing interface, and create a generic interface to the different types of lists with the help of a mentor. By the end of my GSoC project I would like to have a functional list library to contribute to Boost. I feel that this would be a valuable library to Boost because the standards implementation limits you (depending on your library vendor) to either a constant time size() function with a linear time splice operations or constant time splice operations with a linear time size() function. With my implementations a developer will be able to pick and choose whether they want a singly or a doubly linked list, or if they want to use a counted listed instead of a non-counted list. Also their is variations in memory/runtime efficiency between the different variations of the list types which a developer will be able to choose for. Currently my list implementations make heavy use of the new features available in C++0x such as rvalue references and move semantics, but, I will be more than happy to create a backport of these for the current C++ standard so they can be included in Boost. If anyone is interested in the source code for my current list implementations I will be able to provide tarballs of them.

4 3