- Boost - lists.boost.org

[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

boost regex build problem
by Qihong Wang 13 Apr '09

13 Apr '09

Hi, I feel awkward to post almost the same question again. But I really have a problem when I build 32 bits boost.regex with icu support on a 64 bits Linux machine. If I build 64 bits regex with icu support, they are fine. If I build 32 bits regex without icu support, they are fine. When I tried to build 32 bits regex with icu support, I used command for ICU building ./runConfigureICU Linux --disable-64bit-libs ./configure --prefix=/home/qhwang/mylibs_32/icu --disable-64bit-libs I checked icu libraries they are not dependent on 64bits libraries. So I'm confident they are 32bits. But when I use the command to build 32 bits regex ./bjam --prefix=/home/qhwang/mylibs/boost/ --with-regex --build-dir=/tmp/boost_build/ --build-type=complete --address-mode=32 --architecture=x86 -sHAVE_ICU=1 -sICU_PATH=/home/qhwang/mylibs/icu/ install Bjam showed ...failed updating 4 targets... ...skipped 12 targets... ...updated 7477 targets... there were only static libraries built. When I linked them to my program which were also compiled in 32 bits, the linker complained the libraries were incompatable. Could someone give me some help again? Thanks in advance. Qihong

3 6

[fusion] repetitive_view
by Stjepan Rajko 12 Apr '09

12 Apr '09

Hello, I just noticed `repetitive_view` in boost/fusion/view. It doesn't appear to be documented, but judging from the test, it appears that repetitive_view<Sequence> is an infinite repetition of the elements of the sequence. Is that correct? I would find this extremely useful, but I'm slightly put off by the lack of documentation and the fact that it results in a (not currently officially supported?) infinite sequence. What is the status of repetitive_view? Is it safe to use? Stjepan P.S. we have discussed infinite sequences before: http://archives.free.net.ph/message/20080716.025311.1b54b65e.da.html

2 3

boost/pool/pool.hpp why reinterpret_cast instead of static_cast?
by Philippe Vaucher 12 Apr '09

12 Apr '09

Hi, In the file https://svn.boost.org/trac/boost/browser/trunk/boost/pool/pool.hpp there's the following code: struct default_user_allocator_malloc_free { ... static char * malloc(const size_type bytes) { return reinterpret_cast<char *>(std::malloc(bytes)); } ... }; It is my understanding that void* to T* convertions should be done using static_cast and not reinterpret_cast. Is there a reason for using reinterpret_cast there? Thanks, Philippe

7 11