- Boost - lists.boost.org

[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