- Boost - lists.boost.org

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

sandbox or boost vault
by Sean Farrow 28 Jul '11

28 Jul '11

Hi: Given that the boost vault has been down for quite a few months, where are all new bosot libraries going for review, in the boost vault-with a different url, or in the boost sandbox in the svn repository? Any help appreciated. Regards Sean.

11 34

[Lockfree review] Meta-comments
by Phil Endecott 28 Jul '11

28 Jul '11

Dear all, I have a few meta comments about the Lockfree review and reviews in general: 1. I know a lot of people read this list via gmane.org. A bug in gmane.org means that when a message is posted to more than one list - for example, a review announcement sent to this list and announce@ - then it appears only in one, and follow-ups are lost. So gmane.org readers will have missed most of this review. Of course a valid answer would be "they should fix it", but considering how few reviews have been written recently I think we should do everything possible to increase discussion. I don't know if review managers get a "how to run your review" document, but assuming that they do, I suggest adding "please post separate announcements to each list, not one message to all". 2. I think every candidate library should have an online copy of its documentation. Again, I think this should be on the review manager's checklist. Yes, you could say that people should be able to download and unzip and/or build their own copy of the docs, but again, we need more reviews and we need to remove as many obstacles (real or imagined) as possible. (In the last review I asked "Where are the online docs?" and it turned out that they were available but I had missed them; oops. If I have once again missed them, oops again.) 3. This has already been discussed to some extent, but why are we reviewing this before Boost.Atomic? I think Boost.Atomic is an urgently-required library. What can we all do to help it get submitted and accepted as soon as possible? Regards, Phil.

8 19