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
Received on Sat Jul 19 2014 - 02:21:15 MDT
This archive was generated by hypermail 2.2.0 : Sun Jul 20 2014 - 12:00:11 MDT