On 1/16/07, Peter Dimov wrote:

Chris Uzdavinis wrote:

...

Can anyone tell me how to determine the arity of an arbitrary bind object? I have a generic function that receives a bind object, but so far I've been unable to detect at compile time how many arguments it takes. Am I overlooking something obvious?

No, there's no obvious way to determine the minimum arity of a bind object (its maximum arity is 9). What is the specific scenario? Does it have to be at compile time?

Hi, thanks for the feedback. I'll try to explain the situation without going overboard. I have several derived classes from an abstract base, each holding a boost::function object with a slightly different signature, namely, arity0 through arity N. When I instantiate one of these classes I pass an object that matches its signature in arity. To simplify creation of these objects, I have some overloaded functions, make_func(), which take a function (or member function ptr + object address) and instantiate the correct derived class to wrap it. My goal is to make the generator functions work when given a boost bind object. That is, I'd like to write a make_func() overload that accepts a template type T, and when T is a bind object, it uses some sort of MPL introspection to decide which derived class is required to hold this bind object, instanties it, and returns the pointer, just like all the other make_func generator functions do. Here's some stripped down and simplified code. The very last function is the one I don't know how to write. If only bind objects had a "min_arity" member constant.... :) class Function { public: typedef boost::shared_ptr<Function> Shptr; virtual ~Function() { } virtual std::string call() {error(0);} virtual std::string call(std::string const &) {error(1);} virtual int arity() const = 0; private: void error(int num_args) { std::ostringstream msg; msg << "Arity Error: expected " << arity() << "args, received " << num_args; throw std::runtime_error(msg.str()); } }; typedef boost::functionstd::string() Arity0_Func; typedef boost::function Arity1_Func; class Function_Impl_Arity0 : public Function { public: Function_Impl_Arity0(Arity0_Func f) : f_(f) { } virtual std::string call() { return f_(); } virtual int arity() const { return 0; } private: Arity0_Func f_; }; class Function_Impl_Arity1 : public Function { public: Function_Impl_Arity1(Arity1_Func f) : f_(f) { } virtual std::string call( std::string const & arg1) { return f_(arg1); } virtual int arity() const { return 1; } private: Arity1_Func f_; }; // ========== generator functions ========== // // Arity 0 // template <typename R> Function::Shptr make_func(R(*f)()) { return Function::Shptr( new Function_Impl_Arity0(Arity0_Func(f))); } template Function::Shptr make_func( R(C::*f)(), C * c ) { return Function::Shptr( new Function_Impl_Arity0(Arity0_Func( boost::bind(f, c)))); } // // Arity 1 // template Function::Shptr make_func(R (*f)(T1)) { return Function::Shptr( new Function_Impl_Arity1(Arity1_Func(f))); } template Function::Shptr make_func( R(C::*f)() const, C * c ) { return Function::Shptr( new Function_Impl_Arity0(Arity0_Func( boost::bind(f, c)))); } ////////////////////////////////////////////////// // Is this possible? ////////////////////////////////////////////////// template <typename BindT> Function::Shptr make_func( BindT binder) { // do I create Function_Impl_Arity0 // or Function_Impl_Arity1? How to decide? } So far I'm thinking that the caller is going to have to know the arity and pass that in as a non-template parameter, and then make a special flavor of make_func, with specializations for make_func<0> and make_func<1> to work with bind objects. While that will "work", I'd rather the compiler determine this rather than require the user to pass it in. Thanks!! Chris

Same example but at compile time. Of course the right solution is to have boost::bind have some sort of compile-time value. -----Original Message----- From: boost-users-bounces@lists.boost.org on behalf of Sohail Somani Sent: Tue 1/16/2007 3:23 PM To: boost-users@lists.boost.org; boost-users@lists.boost.org Subject: Re: [Boost-users] [Bind] arity of arbitrary object Hi, I've attached up something that seems to kind of maybe work in g++. Don't have access to any other compiler at the moment, so I can't tell you if it will work or if it is even conforming to standard. The solution only helps at runtime currently as I'm not exactly sure how to decompose the bind_t object at compile time (NOT a template guru). It uses boost bind internals as of 1.33.1. I'd appreciate if someone could warp this to somehow get the right information at compile time. Hope it helps! Sohail

-----Original Message----- From: boost-users-bounces@lists.boost.org on behalf of Peter Dimov Sent: Tue 1/16/2007 4:17 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [Bind] arity of arbitrary object Sohail Somani wrote:

Hi, I've attached up something that seems to kind of maybe work in g++. Don't have access to any other compiler at the moment, so I can't tell you if it will work or if it is even conforming to standard.

No, this doesn't quite work. It says that bind( f, _5 ) has arity 1, but the correct answer is 5. Similarly, it says that bind( f, 1, 2 ) has arity 2, while the correct answer is 0. You need something like (pseudocode) arity( _bi::bind_t ) :- max( arity( e ) ) for each e in L arity( X ) :- is_placeholder<X>::value This could be much easier with a bind that uses a fusion tuple as L. :-) -------------------- Ah, you're right! Could it still be made to work using the same idea? I'm actually not sure what the bind_t type looks like when you do bind(f,_5). With you on fusion tuple :-)

-----Original Message----- From: Sohail Somani Sent: Tue 1/16/2007 6:02 PM To: boost-users@lists.boost.org; boost-users@lists.boost.org Subject: RE: [Boost-users] [Bind] arity of arbitrary object -----Original Message----- From: boost-users-bounces@lists.boost.org on behalf of Peter Dimov No, this doesn't quite work. It says that bind( f, _5 ) has arity 1, but the correct answer is 5. Similarly, it says that bind( f, 1, 2 ) has arity 2, while the correct answer is 0. You need something like (pseudocode) arity( _bi::bind_t ) :- max( arity( e ) ) for each e in L arity( X ) :- is_placeholder<X>::value This could be much easier with a bind that uses a fusion tuple as L. :-) ------------ Ok so now the attached version doesn't have the issues which you pointed out. Is there a way (using mpl) to get the max element in a sequence? ------------ Argh, bind(f,1,2) has incomplete type. Will fix later :)

On 1/16/07, Sohail Somani wrote:

Ok the incomplete type was because there was no specialization of _bi::value<T> which occurs when the user actually supplies a value. Does this solve the problem then?

Thanks, that is pretty clever! I was, however, holding onto a little hope that the solution would have been a little easier or straight-forward. Utilizing implementation details like that makes me simultaneously smile and cringe. Watching this discussion unfold has been rather enlightening. My thanks to you and Peter. Any possibility that the Bind library could make this available as part of its documented interface, or were there reasons for its omission? Has anyone ever asked for this before? Chris

Chris Uzdavinis wrote:

On 1/16/07, Sohail Somani wrote:

...

Ok the incomplete type was because there was no specialization of _bi::value<T> which occurs when the user actually supplies a value. Does this solve the problem then?

Thanks, that is pretty clever! I was, however, holding onto a little hope that the solution would have been a little easier or straight-forward. Utilizing implementation details like that makes me simultaneously smile and cringe. Watching this discussion unfold has been rather enlightening. My thanks to you and Peter.

Any possibility that the Bind library could make this available as part of its documented interface, or were there reasons for its omission?

A proper way to provide this functionality would be to expose R,F,L as result_type (already done), function_type and argument_list_type, then make _bi::listN<> a conforming MPL (fusion?) sequence. One reason for not extending boost::bind further is that the extensions won't necessarily make their way into tr1::bind or std::bind. It's not clear whether this should stop us, of course.