- Boost - lists.boost.org

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