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

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

[GSoC] Bits and Ints
by Gaurav Menghani 30 Mar '10

30 Mar '10

Hello, I am keen on working on the Bits and Ints project. However, I would be glad if someone could answer my queries. In the project description, the second line says: "Compressed value array and vector (like vector<bool> but also for multi-bit values)" 1) When we are talking of Compressed Value Array, are we looking at a functionality similar to the Deflater() class in Java, or something like Run Length Encoding / Delta Encoding? 2) I am also not sure if I get what is meant by "but also for multi-bit values", do you mean multi-dimensional bit-fields? 3) Can we discuss the proposal-drafts on the mailing list, even after the application time frame begins (March 29, 2010, 19:00 UTC)? Warm Regards, Gaurav Menghani

2 1

5 Observations - My experience with the boost libraries
by Tom Brinkman 29 Mar '10

29 Mar '10

Over the past years, every project that I have been involved with has tried and then either abandoned boost or highly restricted its use. As a long time boost user, I can't tell you how much debate we've had about this. I want boost to succeed, grow and be successful. Its sad. As someone who has used boost from the beginning, and has taken far more than I have given, here are some of my observations. Many of the reasons don't have specifically to do with boost, but more have to do with a preference for one programming style versus another. I have identified 5 key issues about why boost was abandoned. 1) Boost uses exceptions. 2) Printf versus Iostream. 3) Dependencies. 4) Research Projects 5) Macros 1) Boost uses exceptions. This issue is best illustrated when you want to just do something as simple as converting a "string" to an "int". boost::numeric_cast throws an exception, which forces you to wrap it into a try-catch block. The seemingly trivial issue of how to handle exceptions causes endless grief. It seems that developers still prefer "C" style casts. The prevailing view on projects that I have worked on is that C++ exception handling should optional and not required. int value = 0; try {value = boost::numeric_cast<int>("3.00");}catch (...){} versus int value = atoi("3.00"); I think the lesson is that there is no correct answer here. As most "C++" projects use some "C" libraries, you will need to be flexible in your approach to exception handling. A pure "C++" approach of try-catch blocks is not practical. As boost libraries tend to throw exceptions, it forces you to put try-catch blocks all over your code. Many developers will simply ignore this issue and end up with lots of code that is not exception safe. Small issue, but is undoubtably a source of a huge amount of problems. 2) Printf versus Iostream. Most developers still prefer "printf" over "iostream" style "api's". Unfortunately, Boost libraries have long ago adopted "iostream", as the preferred API style. This issue has been the source of many hours of needless debate. Pure C++ developers seem to have a aversion to "printf" style arguments. As there are very few pure C++ projects (if any), I dont hear about this as much as I once did. Most C/C++ developers prefer a printf style api. Boost needs to start providing printf style api's. Boost needs to be more practical. By not also providing printf style api's, boost is not meeting the needs of developers. Iostream may be preferable for purely academic reasons, but for practical reason, "printf" is the api style that is universally adopted. Is it boosts goal to meet only the needs of a small subset of its c++ users? If that is the goal, than it needs be clearly stated as such. As most developers have adopted a combined C/C++ style of development, a pure academic C++ style syntax is not practical for every day use. Boost needs to look at what the popular api styles are and adopt them and not be so dogamtic about its style of so-called pure "C++". 3) Dependencies. Everyone has a few favourite boost libraries. Unfortunately, because of confusing dependencies between them, its practically impossible to isolate the ones you want from from the ones you don't. What does this mean? Well, it requires the leads of a given project to create a policy about which boost libraries are approved and which ones aren't. Because of the difficulty of doing this, after a while, its can become eaiser to just say "screw it". We won't use boost at all. This issue may seem trivial, but it is the cause endless hourse of grief. It seems that once you add boost to your project, some developers feel that you should be able to use any part of boost. For obvious reasons, project leads prefer to have control over which libraries are used in a given project. Few will just give blanket approval to all boost libraries. The way boost was developed makes this practically impossible. Boost needs to advertise itself correctly and not pretend to be something its not. Its simple a place for promising research libraries to live, to get some exposure, and possibly be adopted by the larger C/C++ community. Currently, boost provides the best place to do that, but it needs to be honest with its users. 4) Many boost libraries seem more like they research projects. The prevailing view is that boost libraries push the envelope of what is possible. This is universally considered a good thing and it is always interesting to see what the best and brightest are up too. Unfortunately, boost pretends to be something else. It pretends to be a collection of libraries that meet your day to day needs. Experience proves otherwise. The practical needs of large scale active projects are in conflict. Boost is very dogmatic and encourages a particalular style of development, which is very template based. In the right hands, a heavy templated based project can work. In my experience, however, it takes many many iterations to get a template based designed library correct and usable. Many more iterations, in fact, than the equivalent non-template design. It is soo difficult, that I am very reluctant to use others template based libraries. I approach them with fear. That being said, boost::mpl and boost::spririt are wonderful accomplishments and I use them regularly. 5) Macros. Need I say more. The core boost libraries are full of macros. So much in fact, that close examination makes many of them practically unmaintainable. I know there are practical reasons to use them. The main reason being compiler inadequacies. However, many developers question the value of a cutting-edge template library that is full of macros. What is the point of having the source code, when it take an experienced developer many weeks to understand what the library is doing underneath? What is the practical value of a library that can only be maintained by the original developer(s)? This issue has surprised many, but has comes up often. If it takes more than a day to examine a libraries source code and have some idea what its doing, its very dangerous to use. This issue will cause many to avoid complex templated macro-style boost libraries. Tom Brinkman

36 161

GSOC BigInt Licensing Issues
by swagat konchada 29 Mar '10

29 Mar '10

I had a look upon the BigInt code from the sandbox. It's entirely wrapped around GMP(linked to gmblib). #inlcude<gmp.h> #ifdef BOOST_BIGINT_HAS_GMP_SUPPORT #include <boost/bigint/bigint_gmp.hpp> namespace boost { typedef bigint_base<detail::bigint_gmp_implementation> bigint; } I also read the LGPLicense which the GMP library carries with itself. This is my inference : The bigint code(from the boost sandbox) could be addressed in LGPL terms as "An Application" : which LGPL defines "as any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library.", since it just uses the gmp.h interface and linking to gmplib. So the combined work, application and GMP, should be conveyed with a GNU GPL license. The Boost License allows skipping the copyright notices if only it's executables are used, unlike the LGPL which requires to distribute it's license. And there are even restrictions on "conveying the object code under terms of your(Boost') choice", in addition to other restrictions. 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. I hope my understanding of the issue is correct. I would be grateful to receive suggestions and comments which would help my GSOC proposal for BigInt, which I plan to submit as early as possible. -- Problem is a phenomenon indicating lack of thought. Swagat Konchada

3 2

[GSoC]
by Andrew Sutton 29 Mar '10

29 Mar '10

Just a reminder, Google Summer of Code student applications can now be submitted here [1]. The deadline for submitting an application is Apr 9. Ideas for some student projects and other information about the program can be found here [2]. Andrew Sutton andrew.n.sutton(a)gmail.com [1] http://socghop.appspot.com/ [2] https://svn.boost.org/trac/boost/wiki/SoC2010

1 0

[GSoC] Mentors group
by Andrew Sutton 29 Mar '10

29 Mar '10

All, If you are registered as a mentor for GSoC 2010, I'm going to invite you to the mentor's group/mailing list here [1]. This will be used to discuss student proposals and vote on the set of final projects for Boost. If you are already registered, then you probably won't be receiving a new invitation. This list is historically low-traffic. If you have any questions or comments, please let me know. Andrew Sutton andrew.n.sutton(a)gmail.com [1] http://groups.google.com/group/boost-gsoc-mentors

1 0

Observations - moving from boost_1_39_0 to boost_1_42_0
by Jeff Flinn 29 Mar '10

29 Mar '10

Lets not lose site of what boost is doing right. I've just updated to boost_1_42_0 from boost_1_39_0 for XCode and MSVC. 1. All but 2 previous workarounds for compiler warnings are non longer needed 2. One wrinkle in build for xcode - now require --layout=versioned 3. MSVC (distributed) build of my app using boost completes 20% faster 4. My app's full test suite runs 10% faster Thanks to all who've made this happen! If your curious, the workarounds are for the archive exceptions in portable_binary_archive, which should have been patched back in 1.40. These are actually in the examples folder, not fully supported by serialization at this time. Jeff

1 0

[GSoC] Boost.Process
by Moncef Mechri 29 Mar '10

29 Mar '10

Hi boosters, My name is Moncef Mechri (aka "fireboot" on IRC). I'm a 20 years old french student in my final undergraduate year at the Faculté des Sciences de Luminy, Marseille, France. I would like to apply as a student for the Boost.Process SoC idea. My main domains of interest include C and C++ programming languages, system programming (especially on POSIX systems), parallel computing, generic programming, object-oriented design, software optimizations, graph theory, and UI development (using Qt). So far I've used a couple of boost librairies : Boost.Thread, Boost.Random, some features from Boost.Interprocess (principally atomic operations), Boost.SmartPointers, Boost.Foreach and Boost.Bind. They were all a pleasure to use and it's why I've just written a (french) paper about one of them : Boost.thread [1]. I'll would be glad to help improving the set of high quality libraries that Boost is. I have some ideas to help finishing Boost.Process and I'd be happy to hear your opinions about them: 1) Abstract the string type used to name executables. This could be done for example using a traits class 2) Move find_executable_in_path() and executable_to_progname() to Boost.Filesystem. I think their job is filesystem-related so maybe it would be wise to move them accordingly. 3) On POSIX systems, provide raise(3) and kill(3) functions to respectively send a signal to the current process and send a signal to a child. Sending signals to unrelated process should probably not take place in Boost.Process but rather in Boost.Interprocess 4) On POSIX systems, when a process dies it becomes a zombie process until wait() is called. Since wait() blocks, things may become tricky if there are a lot of child process. When a process die, the SIGCHLD signal is sent to his creator. It might be nice to use that by setting up a SIGCHLD signal handler which calls wait() when this signal is received. Since a similar problem exists on Windows, Boost.Process should provide a similar solution on this platform, but I've not yet thought about a possible design for it. It might be also useful to provide a way to activate/deactivate this feature, for example with a macro BOOST_MANAGES_DEAD_PROCESS 5) Right now, boost::process::wait_children() returns the first exit code which is not equal to EXIT_SUCCESS, and if there are more than one process which finished abnormally, return values of those child processes are ignored. I think we could improve that by returning for example a vector<boost::process::status> instead of just one boost::process::status. Doing that, we can retrieve all the status codes. It might be useful to define a way to toggle on/off 6) Actually in Boost.Process, if the developer wants to be able to do asynchronous operations on Windows he has to define the BOOST_PROCESS_WINDOWS_USE_NAMED_PIPE macro. By doing so, it makes Boost.Process on Windows create named pipe for all streams even if asynchronous operations are not used in all of them. First of all I propose to add a boost::process::anonymous_pipe class to Boost.Process, and a boost::process::named_pipe class to Boost.Interprocess (because named pipe can be used between unrelated process). After that the developer should be able to choose between anonymous pipe or named pipe on a per-stream basis (but of course asynchronous operations will only work on streams using named pipes). Thanks for reading, it'd be nice if someone accept to comment my ideas Moncef Mechri. [1] http://fz-corp.net/?p=505

5 11

[Build] How to find a library (ICU)?
by Artyom 29 Mar '10

29 Mar '10

Hello, I'm trying to convert CMake build system for Boost.Locale to Boost.Build one. I have one obvious issue: how do find a library? How do I convert this CMake code to Boost.Build one: if(MSVC AND "${CMAKE_BUILD_TYPE}" STREQUAL "Debug") set(ICU_SUFFIX "d") endif() find_library(ICU_UC icuuc${ICU_SUFFIX}) find_library(ICU_DATA icudt NAMES icudata) find_library(ICU_I18N icuin${ICU_SUFFIX} NAMES icui18n${ICU_SUFFIX}) find_path(ICU_INCLUDE_DIR unicode/unistr.h) Note: I search for icuuc or icuucd under debug/msvc icuin or icui18n or icuind under debug/msvc icudata or icudt Also I need the build to fail or disable library if ICU not found. I've looked into the Jamfile of regex... but it does not look correctly for debug icu version when debug build is done! (And actually this is a bug). Also the code looks like a hack. Is there any specific way do to this? Thanks, Artyom

4 6

boost GSoC XML
by Qingli Ma 29 Mar '10

29 Mar '10

Hi ! I have studied some XML parses both in C++ and Java. After comparing with each other, I think that the API interface are more or less the same, however the performance and the complexity of programming is different. So I think mine is to improve the performance and make XML related programming easier. I decide that I am going to make a backend that supports the Reader and the dom interface. I've asked advice from my teachers and he think I am capable of such a job. Thank you!

2 2

New Boost.XInt Library, request preliminary review
by Chad Nelson 28 Mar '10

28 Mar '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I'm a long-time user (and admirer) of the Boost libraries, and I've just uploaded a new one to the Boost Vault for consideration: the Extended Integer (XInt) library, a unlimited-precision integer library that I've been working on for the last few months. I'd like to request a preliminary review of it, please. I know I was supposed to "determine interest" first, but I've seen posts going back at least five years, expressing a desire for such a library, so I didn't think that was really necessary in this case. :-) It's not perfect. The code is complete, as is the documentation text. But it doesn't yet support auto-linking or Windows DLLs, I'm not sure how the test suite would fit into the Boost test system, and I'm not sure I've got the Jamfile correct. But it should be sufficient for experimental use and review, and I'm eager to hear what you guys think of it. (I'm writing this in the wee hours of March 26th, I hope it isn't held in the moderation queue for too long.) - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkusSQoACgkQp9x9jeZ9/wSwrACfTvCVl6bEZbiTSzZ16WnB1E6B cusAoO8eBd2Ne3cYcpdVmjUoUwFmjlVU =5Ptl -----END PGP SIGNATURE-----

9 35

[GSoC] Boost.XML
by Ilie Halip 28 Mar '10

28 Mar '10

Hi! My name is Ilie Halip, and I'm a student at the Faculty of Computer Science in Iasi, Romania. I'm really interested in this year's Summer of Code, and stumbled upon your list of ideas yesterday. I have a few questions about the Boost.XML project. First, what actually needs to be done? The project proposal isn't clear about that. If it's about parsing using DOM/SAX, using XPath queries, then the project linked from the page already does that, right? So the project would involve working with the existing sources and adding validation, tests etc (as mentioned in the README)? How much working knowledge should a student have before trying to work on such a project? I must admit I haven't used Boost, nor libxml2 in the past, so I guess I should start reading documentation about both. I am good in C++, and I've been working with XML APIs for years, so that's not a problem. But the other two (Boost+libxml2) are? Is there a coding style I should follow if I were to work for this project to conform to Boost standards? Where can I find such info? Do you have any requirements from students working with GSoC? Something like: weekly reports, blogging about their experience, maintaining a wiki page about the status of the project? And last but not least... I'm actually employed right now, but my superiors are willing to give me more than 3 months of time off to be able to work for GSoC. Is that ok? Should I ask for more? I was looking over the timeline, and thought about getting a vacation between May 15th and August 30th. Would that be enough? Is it also alright if I stop working on the project for about a week in early June? Because I have a few exams then. Regards, Ilie. P.S. You can usually find me on IRC too (nickname: ihalip).

8 27

[bgl] Manual include necessary for is_in_subset predicate
by Matthias Walter 28 Mar '10

28 Mar '10

Hi! I'm using a filtered_graph for a project, which filters edges via the is_in_subset predicate. Is it intended that one must manually include boost/graph/detail/set_adaptor.hpp for this to work? If I only include boost/graph/filtered_graph.hpp and want to use the predicate, the compiler complains about missing set_contains function. I didn't find anything about manual includes in the docs, but maybe there are reasons for it. best regards Matthias Walter

2 1

[geometry] Inclusion in the next release?
by Romain CHANU 28 Mar '10

28 Mar '10

Hi boosters, Does anyone know if the Boost Geometry Library is going to be shipped in the next release of Boost? Cheers, Romain

4 12

GSoC 2010 : BigInt
by Mario Ynocente Castro 28 Mar '10

28 Mar '10

Hi, I'm a engineering student from Peru. I'm really interested in the BigInt project for GSoC 2010, but there's a part for which I would like a better explanation, the description says : "A successful proposal will include a discussion of licensing concerns". What does it mean? I must choose the license under which the code will be released and indicate it when I submit the aplication? -- Mario Ynocente Castro 20074016B FIIS - UNI

2 5

About Boost XML
by Qingli Ma 28 Mar '10

28 Mar '10

Hi! My idea about XML is listed below: 1.I have experience on processing larege scale xml files(database files).So I feel having boost proccess large xml files in SAX model will be useful and I've make that in Java before. 2.Reading spec about all kinds of XML APIs, and improve current Boost interfaces in Boost to support all kinds of processing without thinking about the backend implemention.By this, interfaces is independent from the backend, thus dynamic backend bindings is possible. 3.Maybe we need a new backend that serves for the API interface,like libxml2.It can parse,tranverse,writer and search(XPath) the document. 4.I am graduating this summer and I'll have enough time. Have you any sugguestions for me?

2 2

[GSoC 2010] Sweepline algorithm
by Marcin Fatyga 28 Mar '10

28 Mar '10

Hello, My name is Marcin Fatyga and I am doing double degree program in computer science and mathematics on Warsaw University. I would like to participate in GSoC 2010 - I would like to implement the sweepline algorithm and use it to solve the problems related to it. In my project I would like to implement the sweepline and then use Fortune's Algorithm to solve the Voronoi Diagram's problem. Then I would provide some modifications to solve the two remaining connected problems : Delanuay triangulation and medial axis. All of these problems have many applications in differnet fields of science and solving them could be useful to may users. Though I don't have quite much experience with the boost library itself, I am particularly interested in algorithms and have some experience with both C++ and generic programming. Though there is no geometry library in current release, I can see it is in development phase. Should the project be integrated with it/use it? Best wishes Marcin Fatyga

7 9

[preprocessor] Computational complexity analysis
by Lorenzo Caminiti 28 Mar '10

28 Mar '10

Hello all: Is there a computational complexity analysis of Boost.Preprocessor data structures? This would be in terms of preprocessing time. For example: Does BOOST_PP_SEQ_ELEM() run* in O(n)? Do BOOST_PP_TUPLE_ELEM() and BOOST_PP_ARRAY_ELEM() run* in O(1)? (*) "Run" within the preprocessor so maybe "expand" is a better term... Thank you. Lorenzo

2 3

[GSoC] Some Ideas about the Boost.Process
by Felipe Tanus 27 Mar '10

27 Mar '10

Hello, I have been studying the project idea about Boost.Process for a while. Some ideas/opinions poped up in my mind and I feel like to share. Please, comment. IMHO, the best design for the library is not to split the APIs from Windows and POSIX. I Believe that boost should provide a higher abstraction level, and get rid of the platform problems. 1.The current implementation of Boost.Process library has the class boost::process::child, and two classes that inherit it, win32_child and posix_child. I don't believe that this is the best solution. There is only one concept of child in both APIs; some resources are different, it is true, but the concept is only one. For example, the call "boost::process::win32_launch()" is defined to launch a process "the windows API way", with the Win32 context. I don't see why can't we create a process with this call in a POSIX system ignoring what don't apply to it (or find some similar concept and use it instead, as named pipes<->fifos). After all, if you are using a Win32 only class, there is no way to run in linux, so if the code works or don't, it does not matter. By doing this way, we could easy a possibly port to another system. This could be done with programming practices as suggested by Vicente Botet, in a previous topic [1] 2.The wait() method, to wait a process (child actually, but this is another problem) to die, is not asynchronous. Sometimes programmers want a synchronous wait() method, so there is no motive for we to remove this. We should implement a new asynchronous wait() method. This method should not be in the asio library, because it's process specific. It may require the asio library, or the asynchronous piece should be implemented in the boost.process. I'm not sure about this, both seems good for me, so please comment. 3.About the process creation, I think the following practice from the documentation should be avoided: “Another important requirement is to always pass at least one argument to the executable. This must be the name of the executable itself”. There is no motive to require a parameter that you can deduce by yourself. The first parameter, in this case, should be implicit. 4.Would really be nice boost::process::launch() be able to receive any kind of string? This tend to let the programmer go for a single platform solution. As a multiplatform library, this may be avoided. I'm not sure about this matter as well, but if the library is here to provide a higher abstraction level, should it also accept API related types? I believe it should not. There is also another points that I would like to discuss in my GSoC proposal; They are well known problems so I'll just cite they: List and access other processes functionality Named pipes and FIFO (following the item #1, would be the same thing? Something would change? Something to be researched yet) move wait from child to process (as well as future asynchronous wait) Deal with process killing bugs (as well as any other known issue) Test platform issues. Should this be enough for a GSoC proposal? Do you have any other suggestion about what could I discuss in it? Thank you for your time, []'s [1] http://thread.gmane.org/gmane.comp.lib.boost.devel/188736 -- Felipe de Oliveira Tanus E-mail: fotanus(a)gmail.com Blog: http://www.itlife.com.br Site: http://www.inf.ufrgs.br/~fotanus/ ----- "All we have to decide is what to do with the time that is given us." - Gandalf

7 18

GSOC query for Heaps and Que
by Chirag 27 Mar '10

27 Mar '10

Hello Sir The Boost C++ library has mutable_heap and mutable_que and the current container works perfectly for basic datatypes like double , int etc but for datatypes like pointers it requires that user should have knowledge of property_map types. Sir for making mutable heaps , can we ask user for a hash function from the user for the data type he want to make the heap. This way we can hash each newly added value to heap and store pointer for that which will point to its location in the original heap. Here two problem i am facing 1) Can user provide a hash function for all data types 2) Worst case of hashing search would be O(n) though it chances are very low . I know O(n) case is not wat we are aiming to achieve but for users who dont want to get into understanding of property map they can use this heap instead , and I am thinking of giving it as a option to the already available mutable que in boost. This is just a idea I am proposing and its definately not final , I am thinking on other ways to improve it . I just want to know if it is a good option to give or not. Thanks Chirag IIT guwahati -- Life is short live it happily

1 0

Stability: More on 3 level Boost libraries
by vicente.botet 27 Mar '10

27 Mar '10

Hi, I would like to come back to the 3 level proposition but from a different point of view (stability and quality) 1st level: stable Libraries belonging to this level must be very stable, any modification on the public interface must be reviewed. The goal been that changes in these libraries don't break user code, even if they will need to recompile. Libraries can pretent to be in this level if the library use only libraries at this level, has not introduced breaking changes for a given amount of time and of course if the author wants to be constrained to have a review for changes on the public interface and to correct quicky the possible tickets. 2nd level: quite stable Libraries at this level, even if stable, introduce breaking changes from time to time. Libraries can go to this level if the library use only libraries at this level or the 1st level, after a deep review of the of the interfaces, the documentation, the implementation and the test coverage and have a reduced number of tickets since a to be defined period. 3rd level: unstable It is assumed that young libraries will have a lot of breaking changes at the public interface level. Libraries can go to this level after a review of the interfaces and the documentation. Comments are welcome, _____________________ Vicente Juan Botet Escribá

10 22

Help with GSoC; BigInt and Heaps & Queue
by Lucas Gambarra 27 Mar '10

27 Mar '10

Hi, I'm very interested in participating in GSoC. While watching the list of ideas proposed by the boost C++ Libraries, I was really interested in two of them: 'Heaps & Queues' and 'BigInt'. I am a student of Computing Sciences of the Federal University of Paraíba - Brazil. I wanted information on how to contact the mentortes of such projects. Could someone help me? Forgive me for my English. ------------ --------- --------- --------- --------- --------- --------- --------- -------- Lucas Lucena Gambarra Estagiário no Laboratório de Sistemas Digitais (LASID - UFPB) Projeto Brazil-IP 2010 email: lucas.ufpb(a)gmail.com.br MSN: lucas_gambarra@hotmail. com

2 1