June 2010 - Boost-users - lists.preview.boost.org

dealing with template size definition macros
by Noah Roberts 24 Jun '10

24 Jun '10

I have written a class that uses named parameters in the constructor because there's like 10 parameters and too often you just want to replace one. Exactly the reason to use them in other words. Unfortunately, I also use the boost::signals2 library. It also apparently uses this library because I keep running into problems where BOOST_PARAMETER_MAX_ARITY has already been set. Even if I undefine it and redefine it to what I need I have problems when it says I've supplied too many template parameters. Wouldn't it be reasonable to expect that this value is undefined at the end of boost headers that use it? At least in 1.42, signals2 does not do so. What is a reasonable approach to dealing with conflicts like this? I've taken to just moving my include up the stack of includes whenever I run into the problem. -- http://crazyeddiecpp.blogspot.com/

1 0

[Boost serialization] non intrusive & derivated class
by agrosjea 24 Jun '10

24 Jun '10

Hello. I'm currently trying to integrate the boost::serialization lib into my project and I encounter some problems : - With the non intrusive version I just cannot get my derivated class to serialize properly. I'm getting the "Invalid XML tag name" error (see http://codepad.org/EYHfWxqN http://codepad.org/EYHfWxqN for a short code sample ) - Still with the non intrusive version, I really don't want to break my encapsulation with public attributes. So I wonder if I could use friend instead, but friend of what ?? (friend class boost::serialization::access doesnt seems to work) Thx for your help. -- View this message in context: http://old.nabble.com/-Boost-serialization--non-intrusive---derivated-class… Sent from the Boost - Users mailing list archive at Nabble.com.

4 9

Sign of gcd in rational.hpp
by Helmut Zeisel 24 Jun '10

24 Jun '10

The invariant check in rational.hpp assumes that the sign of gcd is positive: template <typename IntType> inline bool rational<IntType>::test_invariant() const { return ( this->den > int_type(0) ) && ( math::gcd(this->num, this->den) == int_type(1) ); } For built-in types, math::gcd is indeed specialized in such a way that it is always positive. For user defined IntType, math::gcd, however, does not ensure a special sign. Does this mean that the user has to specialize boost::math::gcd<IntType>? I did not find such an requirement in http://www.boost.org/doc/libs/1_43_0/libs/rational/rational.html#Integer%20… Or should this better be solved in rational.hpp, e.g. by adding some function abs(gcd) or some test is_unit(gcd)? Helmut -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

1 0

Providing a string-to-X feature
by John Dlugosz 24 Jun '10

24 Jun '10

Suppose I wanted to expose a "parse from string" feature for my data type. For discussion, I'll suppose it's a date/time type since everyone knows that and it illustrates the worst problems. What is the current thought on the "best practices" way to expose this? Maybe I'll start with a stream operator>>, and make sure it works with lexical_cast<X>(string). But, where do I add the extra options that tells it what to allow or assume when parsing? Dates for example might have different formats and it can recognize any legal format, but you can tell it to ignore some since that clashes with other input data. It contains spaces and trailing components are optional, so it doesn't know when to stop until it runs into something that doesn't fit. In some sense, that ought to be a constructor. But it should take any kind of string-like thing or stream, and the declaration might clash with other more normal constructors, so a purpose-named "take from human-readable form" is better. An earlier discussion touched on whether to use lexical_cast or a to_string function. This is the other direction, but might have similar issues. Only from_string doesn't seem to be as omni-present as an expectation. Any suggestions? --John (big footer ahead) TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

2 2

boost MPI user-defined datatype.
by Jack Bryan 24 Jun '10

24 Jun '10

Hi, all: Where can I find some boost.MPI example program about how to transfer user-defined datatype from one process to another process ? I cannot find it on boost.org and google. Any help is appreciated. thanks Jack June 22 2010 _________________________________________________________________ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

2 2

What is the bare minimum that needs to implemented for a Graph concept?
by W.P. McNeill 24 Jun '10

24 Jun '10

The concept checking code for the Graph concept seems to require more associated types than is called for by the documentation. According to "The Boost Graph Library" book by Siek et al. and documentation on the boost website ( http://www.boost.org/doc/libs/1_43_0/libs/graph/doc/Graph.html), the Graph concept needs just four associated types: vertex_descriptor, directed_category, edge_parallel_category, and traversal_category. I implemented the following bare-bones graph concept: #include <boost/graph/graph_concepts.hpp> struct ImplicitGraph { // Graph concept typedef size_t vertex_descriptor; typedef boost::undirected_tag directed_category; typedef boost::disallow_parallel_edge_tag edge_parallel_category; typedef boost::adjacency_graph_tag traversal_category; }; int main (int argc, char const *argv[]) { boost::function_requires< boost::GraphConcept<ImplicitGraph> >(); ImplicitGraph g; return 0; } However, when I try to build it I get the following errors from the concept checking code: graph_traits.hpp:30: error: no type named ‘edge_descriptor’ in ‘struct ImplicitGraph’ graph_traits.hpp:31: error: no type named ‘adjacency_iterator’ in ‘struct ImplicitGraph’ graph_traits.hpp:32: error: no type named ‘out_edge_iterator’ in ‘struct ImplicitGraph’ graph_traits.hpp:33: error: no type named ‘in_edge_iterator’ in ‘struct ImplicitGraph’ graph_traits.hpp:34: error: no type named ‘vertex_iterator’ in ‘struct ImplicitGraph’ graph_traits.hpp:35: error: no type named ‘edge_iterator’ in ‘struct ImplicitGraph’ graph_traits.hpp:41: error: no type named ‘vertices_size_type’ in ‘struct ImplicitGraph’ graph_traits.hpp:42: error: no type named ‘edges_size_type’ in ‘struct ImplicitGraph’ graph_traits.hpp:43: error: no type named ‘degree_size_type’ in ‘struct ImplicitGraph’ I would not expect the concept checker to give me these errors because these types are not part of the documented Graph concept. Also, the out_edge_iterator and in_edge_iterator don't make sense for the undirected graph I have defined here. Is the concept checking code out of sync with the documentation, or am I misunderstanding how concept checking works? This is Boost version 1.42 installed via Macports on OS X.

2 1

[TUPLE] n for an n-tuple
by Hossein Haeri 24 Jun '10

24 Jun '10

Dear all, Given an n-tuple t, is there any way to acquire n from t itself? I mean something like: tuple<int, float> t; size_t n = t.size();//n == 2 TIA, --Hossein

2 1

Re: [Boost-users] [RFC] Signals bound to phoenix functions
by Thomas Heller 24 Jun '10

24 Jun '10

On Thursday 24 June 2010 09:31:36 Thomas Heller wrote: > On Wednesday 23 June 2010 18:50:38 Ovanes Markarian wrote: > > Stephan, hi! > > > > please see my answer below. > > > > On Wed, Jun 23, 2010 at 5:42 PM, Stephan Menzel > > <stephan.menzel(a)gmail.com>wrote: > > > Unless I want to add something. Unfortunately I can't always take > > > wrap()s output but have to modify a little. In fact, my Queue needs to > > > be templatized as well, modifying the behaviour of the functor. I have > > > a template parameter "Calling". When it is true, another function > > > shall be called by the functor after the method was posted. Now I > > > wanted to do this by phoenix: > > > > > > template <bool Calling> > > > class Queue { > > > > > > template<typename Handler> > > > > > > void post(Handler n_handler) { > > > > > > m_iosrv.post(n_handler); > > > > > > }; > > > > > > ... > > > > > > template<typename SlotSignature, typename SlotFunction> > > > boost::signals2::connection > > > > > > connect(boost::signals2::signal<SlotSignature> &n_signal, SlotFunction > > > n_method) { > > > > > > return n_signal.connect( > > > > > > if_( CallingBack ) [ > > > > > > post(n_method) , > > > m_signal_callback() > > > > > > ] .else_ [ > > > > > > m_iosrv.wrap( n_method ) > > > > > > ] ); > > > > > > }; > > > > > > ... > > > > It is difficult to conclude smth from the code without having a > > self-containing example. But my assumption is that in the 'else'-branch > > your code does not generate a function object. As far as I can see in the > > 'if'-branch your code generates a function object using the the > > comma-operator (if that operator is overloaded in Phoenix), in the > > 'else'-branch you just have a normal function call, which is not lazy and > > does not return a function-object. > > Phoenix statements always return void. > What you want is: > phoenix::if_else( CallingBack, /* then functor */, /*else functor */ ) > > For reference: > http://www.boost.org/doc/libs/1_43_0/libs/spirit/phoenix/doc/html/phoenix/c > omposite.html#phoenix.composite.operator and > http://www.boost.org/doc/libs/1_43_0/libs/spirit/phoenix/doc/html/phoenix/c > omposite.html#phoenix.composite.statement (There is a note at the end of > that section, for the return value of phoenix statements) Sorry misunderstood your problem ... The correct answer is: post, m_signal_callback() and m_iosrv.wrap need to be lazy expressions. To achieve that for the first two, you can have a phoenix::function wrapper, for the last one, you can use phoenix::bind (which can be used for the first two as well).

2 1

Re: [Boost-users] ptrdiff_t
by yushang 24 Jun '10

24 Jun '10

Hi John, Thanks for your tips . I searched my system directory , found 2 cstddef files , one is in my VC directory and one is in boost compatibility directory . The latter do import ptrdiff_t into std namespace . It seems boost include the former . Should I copy boost's cstddef to my VC directory ? BTW I'm using WDK (Windows Driver Kit) , C compiler version is 15.00 and not ran bootstrap.bat ever. Many thanks > > This makes no sense to me, which VC++ version are you using, and what > compiler options? Boost.Array works just fine for me under VC++ and always > has. > > FYI, ptrdiff_t is defined in crtdefs.h and then imported into namespace std > in cstddef - at least it is in VC9. > > John.

2 1

[RFC] Signals bound to phoenix functions
by Stephan Menzel 24 Jun '10

24 Jun '10

G'day, I'd like to get your opinion on a problem that puzzles me for a while. Basically, I'm trying to do sort of a delayed signals2 notification mechanism. I have a class wrapped around ASIOs io_service object that I normally use as a thread multiplexer and function storage. Now in this case I want to use it without working threads so a current thread can process whatever handlers are in it. Which works fine but now I want to connect signals to it. I have several data classes that contain signals. These are to be connected to slots, but not directly. Instead, these slots are to be wrapped in little handlers and these handlers shall be put in the io_service object. So the signal's slot should not be executed straight away but by another thread that executes everything in the io_service. Now this strikes me as something that could be done nicely with phoenix. I want to use phoenix to create a little function that I can connect to the signal and that will do nothing more but post the handler into the io_service when the signal is triggered. I just can't figure out if that can actually work. Here's what I have so far (simplyfied). I try to illustrate on an example with a one-parameter slot. class Queue : public boost::noncopyable { public: template<typename Handler> void post(Handler n_handler) { m_iosrv.post(n_handler); } std::size_t process(boost::system::error_code & n_errcode) { return m_iosrv.poll(n_errcode); }; template<typename Slot> boost::signals2::connection connect(boost::signals2::signal<void()> &n_signal, Slot n_method) { return n_signal.connect(boost::bind(&CommandQueue::slotWrapper<Slot>, this, n_method)); }; template<typename Slot, typename T1> boost::signals2::connection connect(boost::signals2::signal<void(T1)>& n_signal, Slot n_method) { return n_signal.connect(boost::bind(&CommandQueue::slotWrapper<Slot, T1>, this, n_method, _1)); } // ... more to come with more parameters T2, T3..... private: template<typename Slot> void slotWrapper(Slot n_method) { post(n_method); } template<typename Slot, typename T1> void slotWrapper(Slot n_method, T1 t1) { boost::function<void(T1)> f(n_method); post(boost::bind(f, t1)); } // ... more to come with more parameters ... boost::asio::io_service m_iosrv; }; Now I can use this like this: struct testslot_one { void operator()(int n_arg) const { std::cout << "testslot 1: " << n_arg << std::endl; } }; main { Queue q; boost::signals2::signal<void (int)> sig1; struct testslot_one t1; q.connect(sig1, t1); // signal not yet executed but only the handler posted sig1(42); boost::system::error_code errc; // here we execute the accumulated signals q.process(errc); } Now this works OK so far but I have two problems: First of all, the standard use case will be to bind member functions and not seperate functors such as "testslot_one" in this example. Which is when the connect fails. For reasons unknown to me. But that must work. Second, I want to get rid of the "slotWrapper" functions and replace them by a phoenix expression. If that makes sense, which I'm not sure of. Also, I am not certain about the whole thing. Can a phoenix generated function actually serve this way? Just post the handler when the signal is triggered? Any opinions are appreciated! Cheers, Stephan

2 4