- Boost - lists.boost.org

[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