- Boost - lists.boost.org

Boost.Process 0.3 released
by Boris 14 Apr '09

14 Apr '09

I've released Boost.Process 0.3. Here's the documentation and a link to download the zip archive: Docs: http://www.highscore.de/boost/process/ Code: http://www.highscore.de/boost/process.zip It's a header-only library and thus pretty easy to use: Just copy the files to your Boost directory. In this release my main goal was to merge various snapshots: * There was my Boost.Process 0.2 version which was based on Boost.Process 0.1 from 2006. * There was a post-0.1 version of Boost.Process in SVN from 2007. * Chris Fairles had modified a Boost.Process snapshot for Unix platforms. * Ion Gaztañaga had also some ideas and bug fixes he sent to this mailing list recently. I just saw that Ilya Sokolov created another snapshot based on Boost.Process in SVN. That means we have again at least two different versions of Boost.Process. :-/ In my Boost.Process 0.3 version I concentrated on merging and overhauling code. I did not change the design but tried to make the code work: All the code which was written since 2006 should become usable. That's why I also concentrated a lot on test cases. There are quite a lot of test cases, and they all can be built and passed successfully on three platforms with four compilers. As it would be great if others run the test cases, too (ideally on new platforms), I'll send another message in a few minutes with a description how to run the test cases yourself. As the documentation was written in 2006 I also updated it. It's not yet really a good documentation: There are some files coming from 2006 while other files I wrote myself only last week. While the documentation can be improved it's at least up-to-date: The examples all work and can be compiled. As the documentation was not my priority for Boost.Process 0.3 it should be ok for now. Boris

9 14

Question about boost::multi_index::random_access splice()
by Michael Watkins 14 Apr '09

14 Apr '09

It appears that when calling splice() for a random_access index in a multi_index container, the splice calls a copy constructor. This is apparently by design (since the documentation says that it will do an insert) but why was this chosen? Is there another method to move an item from one container to another without having to call the copy constructor? Or can the code be changed to do splice the same way that std::list does? Michael Watkins _________________________________________________________________ Quick access to your favorite MSN content and Windows Live with Internet Explorer 8. http://ie8.msn.com/microsoft/internet-explorer-8/en-us/ie8.aspx?ocid=B037MS…

2 1

Re: [boost] request for interest in a garbage collection library
by Kasra 14 Apr '09

14 Apr '09

>> 3) gc pointers can point to middle of objects and arrays. >I don't really understand how this works. Would the middle of an >object/array get collected separately from the rest of it? That seems >ridiculous, so I'm confused. hi, I think the following if what was ment: base of array 'x' | v [ 0 ][ 1 ][ 2 ][ 3 ][ 4 ] // an array of 5 elements ^ | pointer to 4-th element (ptr) {c++} gc_free(ptr); remove the entier object 'x' from memory so you don't have to make sure you have a base pointer to 'x' to delete 'x'. This comes handly for example when: {c++[ char* x = (char*)gc_malloc(5); char* end = x + 5; set_zero(x, 5); while(x != end && *x != 0) { // error, x should have been al zero gc_free(x); // note x doesn't point to base // of the allocated memory anymore! } ]} With Best Regards -- Kasra

1 0

atomic_count::operator++ return type
by JOAQUIN M. LOPEZ MUÑOZ 14 Apr '09

14 Apr '09

Hi, Some of the implementations of boost::detail::atomic_count::operator++ return a long (vg. Win32) while for others the return type is void. Is it feasible to change this so that a long (i.e. the value of the atomic count after incrementing) is returned always? As it happens, I have a usage case for this in Boost.Flyweight. Thanks in advance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 10

Re: [boost] BoostCon 2009 Early Registration Extended to April 26th
by Brian Wood 14 Apr '09

14 Apr '09

David Abrahams writes: on Thu Apr 09 2009, woodbrian77-AT-gmail.com wrote: >> Would you agree that recoding that takes advantage of C++ 1998 >> should be higher priority than C++0x? > > In general, maybe. For BoostCon, no. > >> For example, Boost Serialization doesn't use hinted inserts with >> (mulit)set or (multi)map. > > Have you submitted a ticket for that at http://svn.boost.org? I created ticket 2945 now. I'd like to make it to a BoostCon sometime, but am not sure about this year. -- Brian Wood Ebenezer Enterprises www.webEbenezer.net

1 0

[mpl][fold.html] apply<op, _1, deref<_2> > correction needed.
by Larry Evans 13 Apr '09

13 Apr '09

The vault file: http://preview.tinyurl.com/cbr9k3 demonstrates the bug. What's the correct value for the ForwardOp arg to iter_fold in http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/fold.html? TIA. -Larry

5 20

link=shared and runtime-link=static
by Vladimir Prus 13 Apr '09

13 Apr '09

In present, with --build-type=complete all variants with <link>shared and <runtime-link>static are explicitly not built, because they are deemed risky. The code to exclude those variants is written in such a way that: 1. It produces pile of unclear messages. 2. It prevent build of those variants no matter what -- even if you specify this explicitly on command line, you'll get nothing built. I am fixing (1) and this allows (2) to be changed. Should I? In other words, what should happen if user say: bjam link=shared runtime-link=static ? Options are: 1. This variant is built. 2. This variant is built, a huge warning is printed. 3. Error is emitted, user can pass --yes-I-know-what-I'm-doing to build 4. Error is emitted. I believe that on Linux, (4) is most appropriate. I don't know about Windows. Comments? - Volodya

3 6

[convert] Version in the Vault ready for review.
by Vladimir.Batov＠wrsa.com.au 13 Apr '09

13 Apr '09

After listening to many views, opinions, suggestions I've re-done boost::convert and would like it scheduled for a review. It is certainly nowhere as MPL and still not perfect. However, I believe it will be very useful to many developers (like me) not satisfied with lexical_cast and not (yet?) needing (or ready for) something like upcoming Spirit 2.0. Overall, after weighing all pros and cons, I am reasonably happy with the current interface and implementation. It does not implement all that have been discussed and suggested. It is most unlikely implemented the way some would like it to see. However, I had to make choices I felt comfortable with and I feel the current interface is minimal, readable and allows for further growth. With that review-request I would like to avoid opening up another round of discussions if 'from' was a good, bad, mediocre choice. I feel we've exhausted that topic and I would like people to simply vote if they find the functionality needed. I am most certainly prepared to eat my humble pie if the vote is 'no'. Still, I am very much looking forward to any implementation-related suggestions/corrections or new ideas we have not discussed so far. The current interface can be summed up as with as little as int i = convert<int>::from(str); // Throws on failure int i = convert<int>::from(str, -1); // Returns -1 on failure More details can be found in the accompanying document (just remember I am not Shakespeare). If/when we decide to extend that by incorporating, say, Boost.Parameter and/or Spirit, then it might be as int i = convert<int>::from(str)(radix_ = 10, more_parm_ = ...); int i = convert<int>::from(str)(some Spirit related stuff); I am prepared to look into it further... if this initial proposal is accepted... otherwise, it'll be less work for me. :-) Thank you everyone who participated in the lexical_cast/convert discussions. Your views, opinions, suggestions were very helpful and educating and are very much appreciated. I hope I did not forget anyone in the "acknowledgements" list. The file called boost-string-convert.zip can be found in the Vault at http://www.boostpro.com/vault/. Thanks, Vladimir.

6 17

[threads] making parts of Boost.Threads header-only
by joaquin＠tid.es 13 Apr '09

13 Apr '09

Hi, Looks like a sensible part of Boost.Threads, namely that dealing with mutexes and locks, would be header-only but for its relying on boost/thread/exceptions.hpp, whose implementation is located at /libs/thread/*/exceptions.cpp. Given that this .cpp mostly consists of extremely simple definitions (as simple as do-nothing functions in many cases), would it make sense to move this to inline definitions in boost/thread/exceptions.hpp thus making mutexes and locks header-only? This would greatly enhance the appeal of this part of Boost.Threads, as having to link a separate module is a considerable burden. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

12 24

[1.39.0][Build] Release branch failures on all platforms
by Beman Dawes 13 Apr '09

13 Apr '09

Although most of the tests pass, default_toolset is failing on all platforms. There are a few other scattered failures. See http://beta.boost.org/development/tests/release/developer/build.html Please fix or markup, Thanks, --Beman

3 2