I have once again been foiled by brokenness in the JobCallback macro provided apparently for convenience generating Job based AsyncCalls.
This time I seem to have found the problem though. It stems from JobCalback requiring a Dialer+Job+method - with zero parameter objects accepted. If one attempts to use it with UnaryMemFunT<> the compile breaks with some fairly cryptic errors. The resolution to this is to use the asyncCall() template function directly which JobCallback was supposedly making easier. However, the asyncCall is not particularly hard to use in the first place and has lots of code examples to look at now. Give that JobCallback() is only usable (and used) by the NullaryMemFunT<> and where the CommCalls parameter hack/workaround means the parameters variable need not be provided to the dialer constructor. I am believing that this particualar macro is providing almost no benefit outside of CommCalls, so we should do one of the following: a) move it to the CommCalls.h header and rename it specific to that API to avoid others hitting the same confusion in future. b) remove JobCallback macro completely in favour of asyncCall. c) replace existing JobCallback with overloaded inline template equivalents to asyncCall() so that UnaryMemFunT parameter can be provided. I favour b or c. * b makes the code cleaner and more consistent regarding Call creation. * c offers the chance to hide lots of Unary/Nullary-MemFunT definitions inside the inline function via overloading. Opinions? Amos
