- Boost - lists.preview.boost.org

[thread] atomic
by Sergei Politov 15 Apr '09

15 Apr '09

Hi, I would like to known state of atomic (class/operations) implementation in boost. There are several threads that contains references to atomics, but I cannot find the state of this issue. May be I've overlooked something. I would like to known the following: 1) Is there defined interface for atomics? Where is it if present? 2) What is the state of this work? Currently I use my own implementation of atomic class. It has interface similar to atomic class from intel tbb (also it contains some ideas from tbb, but AFAIK ideas are not under GPL license). Now it is tested on MSVC 9.0 32-bit, and GCC 4.2.4 under Gentoo linux (both 32 and 64-bit). I can boostify and prepare it for review, if there is no such work already in progress. Best Regards, Sergei

4 3

Re: [boost] [thread] atomic
by markus2004x 15 Apr '09

15 Apr '09

I have been searching for some standard library of this type for some time. Eventually I wrote my own primitives, taking ideas from tbb and other resources on the web. I also have some containers based on atomics, like non-blocking stacks. I think an atomic-ops library would be a great addition to Boost. If that was available, I would happily throw away all my own code. Best regards, M Sergei Politov wrote: > > Hi, > > I would like to known state of atomic (class/operations) implementation > in > boost. > There are several threads that contains references to atomics, but I > cannot find the state of this issue. > May be I've overlooked something. > > I would like to known the following: > 1) Is there defined interface for atomics? Where is it if present? > 2) What is the state of this work? > > Currently I use my own implementation of atomic class. > It has interface similar to atomic class from intel tbb (also it > contains > some ideas from tbb, but AFAIK ideas are not under GPL license). > Now it is tested on MSVC 9.0 32-bit, and GCC 4.2.4 under Gentoo linux > (both 32 and 64-bit). > I can boostify and prepare it for review, if there is no such work > already > in progress. > > Best Regards, > Sergei > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > -- View this message in context: http://www.nabble.com/-thread--atomic-tp22535763p22901742.html Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[serialization] BOOST_NO_EXCEPTIONS bug
by Vladimir Prus 14 Apr '09

14 Apr '09

Hi, KDE folks has reported that trying to use Boost with exceptions turned off results in duplicate symbol error from Boost.Serialization, like so: kdevclassbrowser. dir/allclassesfolder.o: In function `boost::serialization::throw_exception(std::exception const&)': /usr/include/boost/serialization/throw_exception.hpp:29: multiple definition of `boost::serialization::throw_exception(std::exception const&)' The reason is missing inline, which the attached patch fixes? Robert, is this OK for trunk & release branches? - Volodya

4 5

[mpl] mpl::string, help needed (vacpp, sun, borland)
by Eric Niebler 14 Apr '09

14 Apr '09

(Second try....) I recently added mpl::string (a compile-time string class template) to trunk. I expected horrific portability problems with my use of multi-character literals, but it's not as bad as all that judging from the test results. There are only a few failures on compilers I don't have access to: vacpp, sun and borland. I invite anybody with access to these compilers to "bjam string" in the libs/mpl/test directory, try their hand at fixing the problems and submitting a patch. Thanks! -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

[release] README.txt
by Vladimir Prus 14 Apr '09

14 Apr '09

The root of svn tree has file called README.txt that say something about features in 1.34 release. It does not give very good impression -- can this file be either removed or updated? - Volodya

4 5

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

[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

[1.39.0][Spirit] Release branch test failures
by Beman Dawes 13 Apr '09

13 Apr '09

Spirit is failing a few Darwin tests. A couple of the problems are caused by exceeding -ftemplate-depth-128, so that might require a fix to the toolset. See http://beta.boost.org/development/tests/release/developer/spirit.html Please fix or markup. Thanks, --Beman

2 1

[1.39.0][Filesystem] Release branch test failures
by Beman Dawes 13 Apr '09

13 Apr '09

Filesystem is failing two tests on two Mac OS testers. See http://beta.boost.org/development/tests/release/developer/filesystem.html Please fix or markup. Thanks, --Beman PS: Yep, me too:-)

1 0

[1.39.0] Schedule
by Beman Dawes 13 Apr '09

13 Apr '09

My apologies for lack of progress on 1.39.0. Hopefully I can put in more time on it this week, and we can get the beta out sometime next week. The release will remain open for bug fixes until Monday, April 20th, without having to ask permission to merge. --Beman

1 0

[thread_local] emulation !?
by Kasra 13 Apr '09

13 Apr '09

Hi, I have been using a mechanism to emulate [thread_local] storage for some time now. However, I am aware of boost.thread has thread local heap. The difference is with thread_local emulator we have similar c++0x syntax working seemlessly. for example: thread_local <int> tlocal_integer(-1); // assign the global thread_local value void foo(int i) { *tlocal_integer = i; std::cout << this_thread::get_id() << " : " << *tlocal_integer << endl; } int main() { boost::thread_group tg; for(int i=1;i<500;i++) tg.create_thread(bind(&::foo, i)); *tlocal_integer = 0; std::cout << "main : " << *tlocal_integer << endl; tg.join_all(); return 0; } Wondering if anyone is interested into porting this to boost???

1 0

[mpl][docs]why use list?
by Larry Evans 13 Apr '09

13 Apr '09

Comparing the vector doc: http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/vector.html which contains: supports constant-time insertion and removal of elements at both ends, and linear-time insertion and removal of elements in the middle. with the list doc: http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/list.html which contains: supports constant-time insertion and removal of elements at the beginning, and linear-time insertion and removal of elements at the end and in the middle. shows these documents indicate no reason to prefer list over vector but does indicate a reason to prefer vector over list. Is there any reason to prefer list over of vector? -regards, Larry

4 13

[build] error: No best alternative for ./install
by Bjørn Roald 13 Apr '09

13 Apr '09

Hi, I am trying to test trunk against external projects using boost. But "bjam install" has stopped working recently on my Linux box. $ sudo ./bjam install error: No best alternative for ./install next alternative: required properties: (empty) matched next alternative: required properties: (empty) matched ...found 1 target... I have no idea what this means and is basically stuck. Any help? -- Bjørn

2 2

new version of Join library
by Yigong Liu 13 Apr '09

13 Apr '09

Hello, i just uploaded a new version of Join library to Vault/ Concurrent programming. A brief summary of Join library: an asynchronous message coordination and concurrency library based on JoCaml and Cw. It provides a high level api of asynchronous ports, synchronous ports, chords and joints which support multithreaded applications and orchestration of asynchronous messages. There are some major changes for this new version: 1. originally the library is structured as 2 layers: a port api at bottom and a function api at top. In this new version, function level api is dropped to simplify the interface and implementation. There are some benefits coming with it: 1> the signature of chord's function can be directly mapped from the types of its ports, there is no need for argument wrappers (async_o, synch_o) anymore. so a thread safe message queue can be defined as: template <typename T> class msg_que : public joint { public: async<T> send; synch<T,void> recv; msg_que() { chord(recv, send, &msg_que::proc); } T proc(void_t, T s) { return s; } }; 2> we can use boost::lambda or phoenix to define chord's function; so the above class becomes: template <typename T> class msg_que { public: async<T> send; synch<T,void> recv; msg_que() { joins().chord(recv, send, _2); } }; 2. apply "pimpl" idiom to major port classes and joint class. the benefits of this: 1> port/joint classes play well with standard c++ containers and other libraries 2> better control of lifetime of port/joint objects 3> we can do JoCaml (functional) style "Join" programming, instead of Cw's class based design. For example the msg_que can be created using "factory" function as in JoCaml: template <typename T> tuple<async<T>, synch<T,void> > create_msg_que() { async<T> send; synch<T,void> recv; joins().chord(recv,send,_2); return make_tuple(send,recv); } So the code which uses this "factory" function look like this: ... async<int> send; synch<int,void> recv; tie(send,recv) = create_msg_que<int>(); //spawn 2 threads, thread1 creates data and send it, thread2 receives and use data spawn(bind(thread1_func, send)); spawn(bind(thread2_func, recv)); The documents and samples are updated. You can view them from the following link. http://channel.sourceforge.net/boost_join/libs/join/doc/boost_join_design.h… You can download it from Vault / Concurrent Programming or the project website http://channel.sourceforge.net Comments and corrections are highly appreciated. Thanks Yigong

1 0