- Boost - lists.boost.org

Re: [boost] [#pragma once]
by Graham 14 Apr '09

14 Apr '09

Incredibuild (xoreax) and other parallel compilation systems have problems with pragma once

7 8

[thread] Ticket #1470 Compilation errors with non-__cdecl calling convention
by Arno Schödl 14 Apr '09

14 Apr '09

Hello, any chance to get this change incorporated? We are running into the same problem. Regards, Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Berlin-Charlottenburg, HRB 85229

1 0

[1.39.0][Signals2] Release branch test failures
by Beman Dawes 14 Apr '09

14 Apr '09

Signals2 is failing five tests on all Mac OS testers. See http://beta.boost.org/development/tests/release/developer/signals2.html Please fix or markup. Thanks, --Beman

4 11

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