Overload resolution & boost::bind
The program below contains a compile error. Following the program you will find the typical fix then my idea for a library that facilitates a syntactically prettier fix. #include <boost\bind.hpp> using namespace boost; struct C { void F(char, char){} void F(int, int){} void F(char, int){} void F(char){} }; int main() { C o; bind( C::F, // error: which C::F? &o, _1); } Typical solution: bind(static_cast<void (C::*)(char)>(C::F), &o, _1); And if you're a nice guy: typedef void (C::* OneCharOverload)(char); bind(static_cast<OneCharOverload>(C::F), &o, _1); Here's my idea. If we had these: template<typename TC, typename TR> TR (TC::* resolve_cast0(TR (TC::* Func)(void)))(void) { return Func; } template<typename TP, typename TC, typename TR> TR (TC::* resolve_cast1(TR (TC::* Func)(TP)))(TP) { return Func; } template<typename TP1, typename TP2, typename TC, typename TR> TR (TC::* resolve_cast2(TR (TC::* Func)(TP1, TP2)))(TP1, TP2) { return Func; } template<typename TP1, typename TP2, typename TP3, typename TC, typename TR> TR (TC::* resolve_cast3(TR (TC::* Func)(TP1, TP2, TP3))) (TP1, TP2, TP3) { return Func; } ...etc; the bind call would look like this: bind(resolve_cast1<char>(C::F), &o, _1); If I want to specify C::F(char, int): bind(resolve_cast2<char, int>(C::F), &o, _1, _2); If the struct looked like this: struct D { void F(char, char){} void F(char){} }; Things would be even nicer: If I want to specify D::F(char, char): bind( resolve_cast2(D::F), // Notice no template parameters specified. &o, _1, _2); If I want to specify D::F(char): bind(resolve_cast1(D::F), &o, _1); Benefits: - No ugly syntax due to specifying member function pointer type with static_cast. or - One less line of code due to no typedef. It would be nice to do this, but I can't find a way: If I want to specify C::F(char): bind( resolve_cast<char>(C::F), // Notice no number appended. &o, _1); If I want to call D::F(char, char): bind( resolve_cast<2>(D::F), // Notice no number appended. &o, _1); Is this worth the trouble? Has anyone seen this before? Is it possible to implement a form without a number appended? Is there a name better than resolve_cast? This was tested only in VC7.1.
<Arturo_Cuebas@bpmicro.com> wrote in message news:OF6215D845.F05336EF-ON86256EF3.005F9390-86256EF3.00613932@bpmicro.com...
The program below contains a compile error. Following the program you will find the typical fix then my idea for a library that facilitates a syntactically prettier fix.
<snip>
struct C { void F(char, char){} void F(int, int){} void F(char, int){} void F(char){} };
int main() { C o; bind( C::F, // error: which C::F? &o, _1); }
Typical solution:
bind(static_cast<void (C::*)(char)>(C::F), &o, _1);
<snip>
Here's my idea. If we had these:
<snip>
...etc; the bind call would look like this:
bind(resolve_cast1<char>(C::F), &o, _1);
<snip>
Is this worth the trouble?
I really like the idea. The main advantage is that you don't have to repeat the class name, which may be long. E.g. void (symmetric_filter_adapter_impl::*close) () = &symmetric_filter_adapter_impl::close;
Is it possible to implement a form without a number appended?
I can do it with this syntax: boost::resolve_cast<int()>(&C::g); boost::resolve_cast<int(int)>(&C::g); using function types as in Boost.Function. Your version would be the 'portable syntax'.
Is there a name better than resolve_cast?
Sounds okay to me.
This was tested only in VC7.1.
You need to add &'s to former member function pointers. Otherwise it looks okay to me. My version works on VC7.1, Como 4.3.3 and GCC 3.2. I'll post it if there's interest. Jonathan
Jonathan Turkanis wrote:
<Arturo_Cuebas@bpmicro.com> wrote in message news:OF6215D845.F05336EF-ON86256EF3.005F9390-86256EF3.00613932@bpmicro.com...
I can do it with this syntax:
boost::resolve_cast<int()>(&C::g); boost::resolve_cast<int(int)>(&C::g);
using function types as in Boost.Function. Your version would be the 'portable syntax'.
Is there a name better than resolve_cast?
Sounds okay to me.
This was tested only in VC7.1.
You need to add &'s to former member function pointers. Otherwise it looks okay to me. My version works on VC7.1, Como 4.3.3 and GCC 3.2. I'll post it if there's interest.
template<class F, class X> F X::* resolve_cast( F X::* pm ) { return pm; } looks like it ought to work. VC 7.1 doesn't like it, though. Neither does GCC 3.2.3. The online Comeau compiles it.
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:004101c4849c$b074dd70$0600a8c0@pdimov...
Jonathan Turkanis wrote:
<Arturo_Cuebas@bpmicro.com> wrote in message
news:OF6215D845.F05336EF-ON86256EF3.005F9390-86256EF3.00613932@bpmicro.com...
I can do it with this syntax:
boost::resolve_cast<int()>(&C::g); boost::resolve_cast<int(int)>(&C::g);
looks okay to me. My version works on VC7.1, Como 4.3.3 and GCC 3.2. I'll post it if there's interest.
template<class F, class X> F X::* resolve_cast( F X::* pm ) { return pm; }
Very cool.
looks like it ought to work. VC 7.1 doesn't like it, though. Neither does GCC 3.2.3.
:(
The online Comeau compiles it.
Intel 8.0 for windows, too. I fixed my version, which seems to be reasonably portable (it needs SFINAE and a certain amount of support for function types). It consists of an overload for each arity, the first of which looks something like this: template<typename Sig, typename C> [ typename result_type<Sig>::type (C::*)() ] resolve_cast( result_type<Sig>::type (C::*f)(), typename enable_if< Sig has arity 0 >::type* = 0) { return t; } Jonathan
Peter Dimov wrote:
Jonathan Turkanis wrote:
<Arturo_Cuebas@bpmicro.com> wrote in message news:OF6215D845.F05336EF-ON86256EF3.005F9390-86256EF3.00613932@bpmicro.com...
I can do it with this syntax:
boost::resolve_cast<int()>(&C::g); boost::resolve_cast<int(int)>(&C::g);
using function types as in Boost.Function. Your version would be the 'portable syntax'.
Is there a name better than resolve_cast?
Sounds okay to me.
This was tested only in VC7.1.
You need to add &'s to former member function pointers. Otherwise it looks okay to me. My version works on VC7.1, Como 4.3.3 and GCC 3.2. I'll post it if there's interest.
template<class F, class X> F X::* resolve_cast( F X::* pm ) { return pm; }
looks like it ought to work. VC 7.1 doesn't like it, though. Neither does GCC 3.2.3. The online Comeau compiles it. _______________________________________________
How about having two or three more functions: mem_fn1, mem_fn2, mem_fn3 When you want a certain overload, you specify those parameters that differenciate it from the other overloads, like: class X { 1 void f(char); 2 int f(int); 3 int f(int, int); 4 int f(int, long); 5 int f(int, int, int); 6 long f(int, char, long); }; mem_fn1<void>(&X::f); // selects 1 mem_fn2<any_param,any_param,int>(&X::f); // selects 3 mem_fn3<long>(&X::f); // selects 6 mem_fn3<int>(&X::f); // selects 5 Best, John -- John Torjo Freelancer -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.3beta released - check out splitter/simple_viewer, a File Explorer/Viewer all in about 200 lines of code! Professional Logging Solution for FREE -- http://www.torjo.com/code/logging.zip (logging - C++) -- http://www.torjo.com/logview/ (viewing/filtering - Win32) -- http://www.torjo.com/logbreak/ (debugging - Win32)
"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:cftqa2$rfo$1@sea.gmane.org...
I can do it with this syntax:
boost::resolve_cast<int()>(&C::g); boost::resolve_cast<int(int)>(&C::g);
Sorry, I have to withdraw this suggestion. :( I didn't test it enough. Maybe it can be done, but I don't have time to try now. Jonathan
Jonathan Turkanis wrote:
I can do it with this syntax:
boost::resolve_cast<int()>(&C::g); boost::resolve_cast<int(int)>(&C::g);
The nice thing about the original syntax was that you didn't have to specify the return type. Is it be possible to change this to something like this? boost::resolve_cast<_()>(&C::g); boost::resolve_cast<_(int)>(&C::g); So that the return type is just a placeholder. An alternative would be: boost::resolve<>::cast(&C::g); boost::resolve<int>::cast(&C::g); But maybe that's a bit too jumbled up. Daniel
"Daniel James" <daniel@calamity.org.uk> wrote in message news:4123372C.50805@calamity.org.uk...
Jonathan Turkanis wrote:
I can do it with this syntax:
boost::resolve_cast<int()>(&C::g); boost::resolve_cast<int(int)>(&C::g);
The nice thing about the original syntax was that you didn't have to specify the return type.
Yeah, I noticed this. :-( But I'd rather specify the return type than the arity.
Is it be possible to change this to something like this?
boost::resolve_cast<_()>(&C::g); boost::resolve_cast<_(int)>(&C::g);
So that the return type is just a placeholder.
Sure. But _ would presumably go in some namespace within boost, so it would be cumbersome to use. Maybe boost::resolve_cast<boost::irrelevant(int)>(&C::g); ;-)
An alternative would be:
boost::resolve<>::cast(&C::g); boost::resolve<int>::cast(&C::g);
But maybe that's a bit too jumbled up.
It looks a bit funny.
Daniel
_______________________________________________ Unsubscribe & other changes:
"Bronek Kozicki" <brok@rubikon.pl> wrote in message news:4123D497.6060801@rubikon.pl...
Daniel James wrote:
boost::resolve<>::cast(&C::g); boost::resolve<int>::cast(&C::g);
But maybe that's a bit too jumbled up.
Personally I think that it's nice and simple :)
I like it too, now. I think trying to see it as a casting operation made it look inelegent. How about a simple name change: boost::overload<int>::select(&C::g) or boost::overload<int>::resolve(&C::g) ? For overload resolution by arity one could write: boost::overload< by_arity<3> >::resolve(&C::g) but that's still a bit cumbersome. Jonathan
Jonathan Turkanis wrote:
For overload resolution by arity one could write:
boost::overload< by_arity<3> >::resolve(&C::g)
but that's still a bit cumbersome.
#include <boost/bind.hpp> struct V { int f(); int f(int); }; int main() { boost::bind( &V::f, _1 ); // V::f() boost::bind( &V::f, _1, _2 ); // V::f(int) } ;-)
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:000e01c48579$69233ab0$0600a8c0@pdimov...
Jonathan Turkanis wrote:
For overload resolution by arity one could write:
boost::overload< by_arity<3> >::resolve(&C::g)
but that's still a bit cumbersome.
int main() { boost::bind( &V::f, _1 ); // V::f() boost::bind( &V::f, _1, _2 ); // V::f(int) }
;-)
Yes, naturally. ;-) Jonathan
Jonathan Turkanis wrote:
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:000e01c48579$69233ab0$0600a8c0@pdimov...
Jonathan Turkanis wrote:
For overload resolution by arity one could write:
boost::overload< by_arity<3> >::resolve(&C::g)
but that's still a bit cumbersome.
int main() { boost::bind( &V::f, _1 ); // V::f() boost::bind( &V::f, _1, _2 ); // V::f(int) }
;-)
Yes, naturally. ;-)
Did you know that it already works? ;-)
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:002301c4857d$234e3270$0600a8c0@pdimov...
Jonathan Turkanis wrote:
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:000e01c48579$69233ab0$0600a8c0@pdimov...
Jonathan Turkanis wrote:
For overload resolution by arity one could write:
boost::overload< by_arity<3> >::resolve(&C::g)
but that's still a bit cumbersome.
int main() { boost::bind( &V::f, _1 ); // V::f() boost::bind( &V::f, _1, _2 ); // V::f(int) }
;-)
Yes, naturally. ;-)
Did you know that it already works? ;-)
Yes, naturally. ;-) Jonathan
"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:cg0tk6$98j$1@sea.gmane.org...
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:002301c4857d$234e3270$0600a8c0@pdimov...
Did you know that it already works? ;-)
Yes, naturally. ;-)
Jonathan
If I'm interpretting this correctly, this means that arity isn't an issue. In that case, maybe this implementation will work: template<typename P, typename C, typename R> boost::function<R (C *, P)> overload_select(R (C::* f)(P)) { return boost::bind(f, _1, _2); } template<typename P1, typename P2, typename C, typename R> boost::function<R (C *, P1, P2)> overload_select(R (C::* f)(P1, P2)) { return boost::bind(f, _1, _2, _3); } ...etc. And for free functions: template<typename P, typename R> boost::function<R (P)> overload_select(R (*f)(P)) { return boost::bind(f, _1); } template<typename P1, typename P2, typename R> boost::function<R (P1, P2)> overload_select(R (*f)(P1, P2)) { return boost::bind(f, _1, _2); } ...etc. This would break this: struct V { void f(void){} void f(char){} }; int main() { V o; bind(overload_select<void>(&V::f), &o); } But so what? Just do this: bind(&V::f, &o);
I realize interest in this has died. In spite of that, I'd like to throw one more thing out there to see if it generates any feedback and if not then this is the last you'll hear of this. Does anyone like this syntax?: overload_select<int, int, int>()(&V::f); This returns a boost::function because my compiler (VC7.1) generates an error if I try to define a member function of a class that looks like this: //P1, P2, & P3 are template parameters of the template class. template <typename R, typename C> R (C:: * operator() (R (C::* Func)(P1, P2, P3)))(P1, P2, P3) { return Func; }
<Arturo_Cuebas@bpmicro.com> wrote in message news:OF9B966D94.6BA485A4-ON86256EF9.0063B717-86256EF9.0068EC67@bpmicro.com...
I realize interest in this has died.
Just because there haven't been any messages in the last few days doesn't mean interest is dead. People are busy with other things. (Though it's probably safe to say that interest is not huge.)
In spite of that, I'd like to throw one more thing out there to see if it generates any feedback and if not then this is the last you'll hear of this.
Does anyone like this syntax?:
overload_select<int, int, int>()(&V::f);
I think '()' look's funny :() I think Daniel James had the best idea: boost::overload<int>::resolve(&V::f)
This returns a boost::function
because my compiler (VC7.1) generates an error if I try to define a member function of a class that looks
Too heavy-weight, I think. The other proposals probably have zero runtime overhead. like
this:
//P1, P2, & P3 are template parameters of the template class. template <typename R, typename C> R (C:: * operator() (R (C::* Func)(P1, P2, P3)))(P1, P2, P3) { return Func; }
What are P1, P2, P3 ... ? Sometimes you can sneak in complex return types like so template< ... > typename mpl::identity< [put messy stuff here] >::type f( ... ); Jonathan
BTW Jonathan, thanks for all your input.
I think '()' look's funny :()
Me too. Just throwing it out there.
I think Daniel James had the best idea:
boost::overload<int>::resolve(&V::f)
I've learned to like it.
[boost::function is] Too heavy-weight, I think. The other proposals probably have zero runtime overhead.
I thought this might be an issue. But it's a non-issue now because of the tip you gave me with mpl::identity. :)
What are P1, P2, P3 ... ?
The operator () definition that I showed is a member function of a class. P1, P2, & P3 are template params of the class. OTO: template<typename P1, typename P2, typename P3> struct overload_select { // operator () def here. }; OK. So now I'm thinking its final form would look something like: class Nothing{}; template<typename P1 = Nothing, typename P2 = Nothing, typename P3 = Nothing, typename P4 = Nothing, typename P5 = Nothing, typename P6 = Nothing, typename P7 = Nothing, typename P8 = Nothing, typename P9 = Nothing> struct overload { }; template<typename P1> struct overload<P1, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing> { template <typename R> static typename boost::mpl::identity<R (*)(P1)>::type select (R (* fp)(P1)) { return fp; } template <typename R, typename C> static typename boost::mpl::identity<R (C::*)(P1)>::type select (R (C::* fp)(P1)) { return fp; } }; // 8 more explicit specializations of overload here. This compiles and works on VC7.1 at least.
Arturo_Cuebas@bpmicro.com wrote:
I think Daniel James had the best idea:
boost::overload<int>::resolve(&V::f)
I've learned to like it.
I think I prefer your original style: boost::overload_resolve1<int>(&V::f) It looks more straight forward to me. But, I tend to use the portable style for boost::function, so I'm probably just used to it. Daniel
Arturo_Cuebas@bpmicro.com wrote:
I think Daniel James had the best idea:
boost::overload<int>::resolve(&V::f)
I've learned to like it.
I think I prefer your original style:
boost::overload_resolve1<int>(&V::f)
It looks more straight forward to me. But, I tend to use the
"Daniel James" <daniel@calamity.org.uk> wrote in message news:412B71E1.5050009@calamity.org.uk... portable
style for boost::function, so I'm probably just used to it.
We've come full circle then. When I see boost::overload_resolve2<int, char>(&V::f) it reminds me of the windows API functions that end in 'Ex'. I think 'what was wrong with the first version of overload_resolve'? Jonathan
When I see
boost::overload_resolve2<int, char>(&V::f)
it reminds me of the windows API functions that end in 'Ex'. I think 'what was wrong with the first version of overload_resolve'?
LOL
From best to worst IMO: overload_resolve2<int, char>(&V::f) overload2_resolve<int, char>(&V::f) overload<int, char>::resolve(&V::f) overload_resolve<int, char>()(&V::f) overload_resolve<argtypes<int, char> >(&V::f)
When I see
boost::overload_resolve2<int, char>(&V::f)
it reminds me of the windows API functions that end in 'Ex'. I
<Arturo_Cuebas@bpmicro.com> wrote in message news:OF1D166987.D055FE93-ON86256EFA.00733184-86256EFA.007453D4@bpmicro.com... think
'what was wrong with the first version of overload_resolve'?
LOL
From best to worst IMO: overload_resolve2<int, char>(&V::f)
I could learn to live with it. But I'd prefer resolve_overload2 -- it sounds more like a command.
overload2_resolve<int, char>(&V::f)
Looks to much like Food2Go :-)
overload<int, char>::resolve(&V::f)
As I said, I think I like this best.
overload_resolve<int, char>()(&V::f)
Look's funny. And are you sure there is no runtime penalty?
overload_resolve<argtypes<int, char> >(&V::f)
Too compilicated ... wait ... I suggested it. Still too complicated. Jonathan
overload_resolve2<int, char>(&V::f)
I could learn to live with it. But I'd prefer resolve_overload2 -- it sounds more like a command.
Yeah, I like that better too.
overload2_resolve<int, char>(&V::f)
Looks to much like Food2Go :-)
LOL
overload_resolve<int, char>()(&V::f)
Look's funny. And are you sure there is no runtime penalty?
No, I'm not sure. Is this worth officially "proposing"? It's so trivial and is useful so infrequently that I'm tempted to just finalize it, throw it into our utility header lib here at my work, stop wasting everyone's time, and forget about it.
<Arturo_Cuebas@bpmicro.com> wrote in message news:OFA376A8E0.659F2A6B-ON86256EFB.0051F414-86256EFB.00539597@bpmicro.com...
overload_resolve2<int, char>(&V::f)
I could learn to live with it. But I'd prefer resolve_overload2 -- it sounds more like a command.
Yeah, I like that better too.
overload2_resolve<int, char>(&V::f)
Looks to much like Food2Go :-)
LOL
overload_resolve<int, char>()(&V::f)
Look's funny. And are you sure there is no runtime penalty?
No, I'm not sure.
Is this worth officially "proposing"? It's so trivial and is useful so infrequently that I'm tempted to just finalize it, throw it into our utility header lib here at my work, stop wasting everyone's time, and forget about it.
I'd definitely use it! I've found myself using unique function names where it would be better to overload just to avoid the additional temporary function pointer clutter. Jeff F
<Arturo_Cuebas@bpmicro.com> wrote in message news:OFA376A8E0.659F2A6B-ON86256EFB.0051F414-86256EFB.00539597@bpmicro.com...
Is this worth officially "proposing"? It's so trivial and is useful so infrequently that I'm tempted to just finalize it, throw it into our utility header lib here at my work, stop wasting everyone's time, and forget about it.
I'd suggest writing writing a preliminary version, including documentation, and posting it at the yahoo files section (if it's not full). People who are interested can use it and determine whether it actually useful in practice. Jonathan
Arturo_Cuebas@bpmicro.com writes:
The program below contains a compile error. Following the program you will find the typical fix then my idea for a library that facilitates a syntactically prettier fix.
Maybe a good idea, but IMO the name resolve_cast is terrible. It could mean almost anything. This is something like member_function_cast_leaving_target_type_the_same. Maybe if you change the interface to accomodate regular functions you could call it select_overload. I don't buy the ideas that involve using function types as in select_overload<int(int)> because it requires specifying the return type, which is irrelevant. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote:
I don't buy the ideas that involve using function types as in
select_overload<int(int)>
because it requires specifying the return type, which is irrelevant.
Current pratice is to speficy the entire signature, including the (irrelevant) return type and the (redundant) class name. Arturo's suggestion gets rid of the return type and class name, but introduces the (irrelevant) arity. Using function types eliminates the class name but keeps the return type. So neither is quite right, althought I tend to prefer using function types. The essential information that needs to be supplied is just a typelist. So one could use whatever_cast< mpl::list<char> >(&P::f) but this would not make the significance of the typelist clear. So it might be natural to replace this with whatever_cast< arg_types<char> >(&P::f) or whatever_cast< arg_types(char) >(&P::f) Jonathan
"David Abrahams" <dave@boost-consulting.com> wrote:
I don't buy the ideas that involve using function types as in
select_overload<int(int)>
because it requires specifying the return type, which is irrelevant.
Current pratice is to speficy the entire signature, including the (irrelevant) return type and the (redundant) class name. Arturo's suggestion gets rid of the return type and class name, but introduces the (irrelevant) arity.
When overloads differ only in the number of parameters and not the parameter types, arity becomes the only thing that's relevant. That's why I thought the ideal use would look like this when that's the case: whatever_cast<1>(&P::f) And like this when it's not: whatever_cast<char>(&P::f) I doubt that's possible though. :(
Using function types eliminates the class name but keeps the return type. So neither is quite right, althought I tend to prefer using function types.
whatever_cast becomes more useful the further away we get from the static_cast form. IMO, the arity-specifying form is further away from that than the function-signature form. Consider that the return type can have a super-long name: whatever_cast <long_name_templatized_type<unsigned long, unsigned char> (char)> (&P::f)
The essential information that needs to be supplied is just a typelist. [snip]
Is it possible to implement whatever_cast in such a way that it mimics what mpl::list does - in its acceptance of a variable number of template parameters - but produces a function?
<Arturo_Cuebas@bpmicro.com> wrote in message:
Current pratice is to speficy the entire signature, including the (irrelevant) return type and the (redundant) class name. Arturo's suggestion gets rid of the return type and class name, but introduces the (irrelevant) arity.
When overloads differ only in the number of parameters and not the parameter types, arity becomes the only thing that's relevant. That's why I thought the ideal use would look like this when that's the case:
whatever_cast<1>(&P::f)
And like this when it's not:
whatever_cast<char>(&P::f)
I doubt that's possible though. :(
Right. You'd have to do something like this (switching to 'select_overload'): select_overload< mpl::int_<1> >(&P::f) which is pretty ugly. This formulation supports both flavors: select_overload< by_args<char, int> >(&P::f) select_overload< by_arity<3> >(&P::f) But the utility of select_overload as a space-saver is starting to dwindle.
static_cast form. IMO, the arity-specifying form is further away from that than the function-signature form. Consider that the return type can have a super-long name:
whatever_cast <long_name_templatized_type<unsigned long, unsigned char> (char)> (&P::f)
True, but in my personal experience this happen less often then long class names.
The essential information that needs to be supplied is just a typelist. [snip]
Is it possible to implement whatever_cast in such a way that it mimics what mpl::list does - in its acceptance of a variable number of template parameters - but produces a function?
Only if we had default template arguments for function templates. That's why Daniel mentioned boost::resolve<>::cast(&C::g); boost::resolve<int>::cast(&C::g); Jonathan
From: "Jonathan Turkanis" <technews@kangaroologic.com>
<Arturo_Cuebas@bpmicro.com> wrote in message:
When overloads differ only in the number of parameters and not the parameter types, arity becomes the only thing that's relevant. That's why I thought the ideal use would look like this when that's the case:
whatever_cast<1>(&P::f)
And like this when it's not:
whatever_cast<char>(&P::f)
I doubt that's possible though. :(
Right. You'd have to do something like this (switching to 'select_overload'):
select_overload< mpl::int_<1> >(&P::f)
which is pretty ugly. This formulation supports both flavors:
select_overload< by_args<char, int> >(&P::f)
select_overload< by_arity<3> >(&P::f)
Interesting.
But the utility of select_overload as a space-saver is starting to dwindle.
Maybe.
static_cast form. IMO, the arity-specifying form is further away from that than the function-signature form. Consider that the return type can have a super-long name:
whatever_cast <long_name_templatized_type<unsigned long, unsigned char> (char)> (&P::f)
True, but in my personal experience this happen less often then long class names.
What about when the return type is a typedef in the class with a long name or is unutterable? (The latter often happens with complicated metaprogramming expressions.) -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
"Rob Stewart" <stewart@sig.com> wrote in message:
From: "Jonathan Turkanis" <technews@kangaroologic.com>
<Arturo_Cuebas@bpmicro.com> wrote in message:
that than the function-signature form. Consider that the return type can have a super-long name:
whatever_cast <long_name_templatized_type<unsigned long, unsigned char> (char)> (&P::f)
True, but in my personal experience this happen less often then long class names.
What about when the return type is a typedef in the class with a long name or is unutterable? (The latter often happens with complicated metaprogramming expressions.)
Sure, I've written plenty of functions like that. I guess I don't bind them very often, for some reason. Anyway, I'm now convinced the return type should be dropped. Jonathan
Arturo_Cuebas@bpmicro.com writes:
[snip]
Is it possible to implement whatever_cast in such a way that it mimics what mpl::list does - in its acceptance of a variable number of template parameters - but produces a function?
It could be defined as a class template, and produce a function object. -- Jeremy Maitin-Shepard
participants (10)
-
Arturo_Cuebas＠bpmicro.com -
Bronek Kozicki -
Daniel James -
David Abrahams -
Jeff Flinn -
Jeremy Maitin-Shepard -
John Torjo -
Jonathan Turkanis -
Peter Dimov -
Rob Stewart