- Boost - lists.boost.org

Book "The Boost C++ Libraries" available at Amazon, Barnes and Noble and others
by Boris Schaeling 01 Aug '11

01 Aug '11

A new edition of my book "The Boost C++ Libraries" has been published. It's not (yet) online at http://en.highscore.de/cpp/boost/ as some may expect. Instead it is available at Amazon, Barnes and Noble and others as a print book. What's new: * Several chapters were updated (to Boost.Spirit 2.x, Boost.Signals 2, Boost.Filesystem 3...) * Many new libraries are covered (Boost.CircularBuffer, Boost.Intrusive, Boost.MultiArray...) * The book has now an index (12 pages with class/function/object names used in the book) * The English has been greatly improved :) The book is based on Boost 1.47.0. It covers 38 libraries which I would describe as general purpose libraries (no libraries like Boost.Quaternions for example). It's based on C++98 and ignores C++0x (in a new edition of the book, I can for example probably drop Boost.Lambda). It has 262 pages and about as many examples. Every example is complete - it can be built and run as is (helpful if my explanations are not good enough and you want to see what an example really does :). One should be able to read the book in one or two days and know then what those 38 libraries do, when to use them and how to use them. To keep this email short - please see http://xmlpress.net/publications/boost for more information. If you read the book and have any comments or questions - please tell me! The book was written by someone part of this community, so I'm interested in what the community thinks. I also hope that I could paint a picture of the community everyone can identify with. I got a lot of feedback on my online book in the past and try to improve the book accordingly. So drop me a line if you like! Boris

1 0

what happened to context mini-review?
by Nathan Ridge 01 Aug '11

01 Aug '11

Hello, Up until a few days ago, the Review Schedule contained an entry for the mini-review of the Context library (which has previously been accepted provisionally) starting from July 28. Now the entry is gone and there is no sign of a mini-review on the list. What is the status of the library? Has the mini-review been postponed? Or will the library be accepted without a mini-review? Thanks, Nate

2 1

Re: [boost] [rpc] Introducing Boost.Reflect, Boost.CMT, and Boost.RPC
by Brian Wood 31 Jul '11

31 Jul '11

Daniel Larimer <dlarimer(a)gmail.com> > 1) No code generation required (best for C++ to C++, but with a proper JSON interface can communicate with any language) Code generation is being done by something here. In this case it is probably being done by a C++ compiler that starts from scratch for every file it has to compile. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net "The heavens declare the glory of G-d; and the firmament shows His handiwork." Psalm 19:1

2 1

[proto] Error with Proto Domains in 1.45
by Fernando Pelliccioni 30 Jul '11

30 Jul '11

Hi Eric, hi all, I'm getting the following errors when I try to compile the example in the atteched file. test_proto_145.cpp: In function ‘int main()’: test_proto_145.cpp:91: error: no match for ‘operator<<’ in ‘emergency << 1’ I am using Boost 1.45 and GCC 4.4.5 This works fine in 1.46.0 and above. Is there a patch ? Thanks and regards. Fernando Pelliccioni.

2 2

[fusion] mpl::clear doesn't work on fusion views
by Eric Niebler 30 Jul '11

30 Jul '11

Today I ran into a limitation in Fusion/MPL interoperability. I couldn't use an mpl algorithm on a Fusion sequence because mpl::clear wasn't defined on it. The sequence was a joint_view. I see that fusion::detail::clear is only defined for Fusion cons, map, set, vector and deque. Can we get it defined for all Fusion sequences? I think for everything else, an empty Fusion vector would do. That is all fusion::clear does, btw. (Aside: it seems strange to me that mpl::clear of a fusion::set gives an empty set, but that fusion::clear of an empty set gives an empty vector. This should probably be made consistent.) -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 4

[Review] TTI
by Noah Roberts 29 Jul '11

29 Jul '11

What is your evaluation of the design? Except for the namespace issue, which seems resolved, it seems to be what it needs to be. I don't know that there are a lot of design options here. It seems to offer a complete set of needs, from metafunction or trait to metafunction class. This is good. What is your evaluation of the implementation? Again, I don't see a lot of room to be innovative here. It's as clean as it can be I think. One thing that I think is missing is the option to check for a named callable within a type. For example, one might want to use enable_if style concept checking. So long as a type has function 'xxx' that takes arguments of type x,y,and z, and returns something convertible to type A, the concept is obeyed. I don't believe this can be done with C++03, but with C++1X I was able to do something using decltype. What is your evaluation of the documentation? Could probably use some more tutorials. What is your evaluation of the potential usefulness of the library? VERY. Having to write all these things by hand is a PITA. Most people who would have use for this library have probably already devised similar sets of macros. It would be nice to have something somewhat standardized. Did you try to use the library? No. How much effort did you put into your evaluation? Quick reading. Are you knowledgeable about the problem domain? I think I can say yes. I've had to write my own such SFINAE and overload metafunction objects numerous times. Do you think the library should be accepted as a Boost library? Yes, so long as the namespace issue is indeed fixed. For thoroughness, the namespace issue is that the current implementation places traits and metafunction objects within the boost namespace. The library would be more useful if the macro declared objects within the scope the macro is used. It's an important feature that I often declare such objects within class scope. Since they aren't providing specializations, it shouldn't be necessary to place them in the boost namespace and the author has agreed to discontinue this policy.

6 23

Is there any possibility that get VC6 support of C++11 tuple?
by 罗勇刚(Yonggang Luo) 29 Jul '11

29 Jul '11

Such as by using of Variadic Macro Data -- 此致礼罗勇刚 Yours sincerely, Yonggang Luo

2 2

[msm]exit pseudo state and event
by Takatoshi Kondo 29 Jul '11

29 Jul '11

Hello, Boost.Msm supports the UML2.0 feature "exit pseudo state". Here is a description about exit pseudo state in the document. > exit_pseudo_state > > Basic type for exit pseudo states. Exit pseudo states are an > predefined exit from a submachine and connect two transitions. > The first argument is the name of the event which will be > "thrown" out of the exit point. This event does not need to > be the same as the one sent by the inner region but must be > convertible from it. The second argument is needed if you > want your state (and all others used in a concrete state machine) > to inherit a basic type for logging or providing a common behavior. > > template<class Event,class Base = > default_base_state, { > } > class SMPtrPolicy = no_sm_ptr> > exit_pseudo_state { > } Why the 1st template parameter "Event" is needed? Consider the attached diagram "11_ExitPointEvent.png". IMHO, the Exit2 is typical usecase of exit pseudo state. Outgoing transition from exit pseudo state shouldn't have any events and guards. The point is how to divide the concerns. When we design the Sm1, we can depend only State1, State1::Exit1, State1::Exit2 and State2. And we shouldn't depend on which event triggers the transition to pseudo exit state. It's State1's concern. To implement that, I pass the "none" as 1st template parameter. namespace msmf = boost::msm::front; struct Exit2:public msm::front::exit_pseudo_state<msmf::none> {}; (See the attached file 11_ExitPointEvent.cpp) I think it is suitable for the default template parameter. The example in the Boost.Msm tutorial document, the usage of exit pseudo state is similar as Exit1 in "11_ExitPointEvent.png". The behavior that I understand is below. In State1 1. Event1 is occurred, 2. Transition to Exit1. 3. Event1 is converted to Event2 (Exit1's template argument). In Sm1 4. Dispatch Event2. 5. Transition to State2. (Entry, Exit action is omitted) Is that right? I'd like to know why such complicated mechanism is needed? Is the purpose to propagate the event parameter? Thanks, Takatoshi

3 17

Python-extension: Linker options
by Sergiy Nazarenko 29 Jul '11

29 Jul '11

Hi everyone! I'm begginers to use bjam and boost. I've built python-extension. I successfully compiled it by bjam. My Jamroot file like this: use-project boost : ../../.. ; project : requirements <library>/boost/python//boost_python ; python-extension myext : myext.cpp ; And I have custom shared library with extra functions . Now I'm trying to use extra functions in python library. My questions is how put linker options in bjam project? Something like this: -L/path/to/my/library/lib64/ -lmylib.0.1 If I append include options for a file, my MyLib.h is found but linker does not find library itself. I append like this: python-extension myext : myext.cpp <include>/path/to/my/library/include; I've tried to use following # <library-path>/path/to/my/library/lib64/ # <library-file>mylib.0.1.so but with these options my extension is not compiled. Cheers,

1 0

Lockfree review
by Phil Endecott 28 Jul '11

28 Jul '11

Dear All, Here is a quick review of the proposed Boost.Lockfree library. Utility ------- For some proposed libraries their utility is beyond doubt because they are already being used in some significant application. In contrast most GSoC projects are developed more in the "hope that they will be useful" without a motivating application. So we have to ask ourselves, does this library meet a need? To me, lock free algorithms and data structures have always seemed appealing at first sight but, apart from some trivial cases like counters, on close inspection they turn out to be too complicated to bother with. (They also lack required features, i.e. waiting for non-empty; I don't think I've ever written a producer-consumer application that didn't need the consumer to block on empty.) The author acknowledges that these structures will typically be slower than conventional implementations using mutexes, but claims that their benefit comes in terms of better worst-case latency. Specifically, if a thread is pre-empted while it holds a lock, another thread will have to wait until the first thread is re-scheduled and can unlock before it can itself lock. But this case is exactly the one that priority inversion is supposed to address: when the second thread tries to lock, the kernel immediately re-schedules the first thread. Yes, because of the kernel involvement this will probably still be slower than the lock-free approach, but perhaps not by much. It seems to me that the author should present benchmarks to demonstrate the actual worst-case latency difference between this code and a lock-based implementation. Design ------ I am happy with the design of the interface, as far as it goes; there are a few things that could be added though: - Debug modes that check the thread requirements. - Other combinations of single/multiple producer/consumer. Implementation -------------- I have looked only at the implementation of the ringbuffer class template. It lacks comments. There are some oddities like this: size_t ret = read_index - write_index - 1; if (write_index >= read_index) ret += max_size; return ret; Here, a negative value may be assigned to the unsigned size_t. I think this is actually safe, but it looks odd. I have not found any bugs. It looks like every call to enqueue() and dequeue() will access both the read and write indexes. Won't this cause poor performance due to cache issues? I would have been tempted to avoid this by keeping local 'available' counts: (PSEUDO_CODE) private: atomic<size_t> read_index_; atomic<size_t> write_index_; size_t read_available_; size_t write_available_; public: bool enqueue(...) { if (write_available_==0) { // In this case, we access read_index_ which is probably cached by the consumer thread, // which is expensive. But this is rare. write_available_ = (read_index_ + max_size - write_index_ - 1) % max_size; } if (!write_available_) return false; // full buffer[write_index_.load(memory_order_relaxed)] = data; write_index_.store((write_index_+1)%max_size); --write_available_; } // dequeue similarly... Documentation ------------- I'm not impressed by the documentation. It lacks rationale and information about the implementation. It has some formatting issues and typos (e.g. lose/loose). Platform requirements (i.e. the Boost.Atomic and/or std::atomic requirements and supported architectures) should be explained. The reference documentation involves more clicks than I would expect to reach the actual content. Some functions are marked as "for debugging only", e.g. the empty() and reset() [which should probably be called clear()] methods. It's not clear to me why these methods must be unsafe; for example, for the ringbuffer, I would expect the consumer thread to safely be able to call empty() and the producer to safely be able to call full() (which is not provided). Rationale for these restrictions (or relaxations of them) would be useful. - Did you try to use the library? With what compiler? Did you have any problems? I considered exercising the library on my ARM systems, but I realised that it requires 64-bit atomics; currently, Boost.Atomic only provides 32-bit atomics on ARM. (This raises the whole issue of the Boost.Atomic dependency. I'm presuming that Tim intends not to bundle a Boost.Atomic snapshot with the library if approved. If that changes, we really need another review.) - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A few hours reading the docs and code. - Are you knowledgeable about the problem domain? I know a certain amount about atomics and lock-based concurrent programming, but not much about lock-free data structures. - Please always state in your review, whether you think the library should be accepted as a Boost library! I think it should be accepted provided that: * The author demonstrates some measurable benefit over lock-based data structures. * The documentation is improved to describe the implementation and to provide rationale for design decisions. * The library is not added to Boost until Boost.Atomic has been reviewed and approved (or, available std::atomic implementations work with it). Regards, Phil.

2 1