|
![](/i/fill.gif) |
Chambers wrote:
> Aren't Callback functions often used in places where it's not easy to
> just change one thing and recompile? I would think that many parts of
> the codebase would depend on that specific function signature being the
> way it is.
I would think if you have a callback routine that actually uses the third
parameter, passing the right thing would be necessary each time, but you'd
also have that information each time. I.e., you wouldn't be invoking the
callback that depended on which controller was invoking it if it wasn't
actually coming from the controller. Since the other routines didn't use
that third parameter, they could get a dummy value there everywhere they're
called from a context where the new parameter doesn't make sense.
I can see situations where that would be difficult to resolve, but you
wouldn't be able to resolve it by passing the integer in cast to void* in
those cases either. I.e., given that they solved the problem by sometimes
(i.e., conditionally) passing the value as the wrong type and then
extracting it where appropriate, it doesn't seem like it's the sort of
problem that would be hard to solve by adding a new variable of the right
type (modulo performance problems and/or lacking some source code, of course).
If they were using a language where functions can have default arguments,
this would the canonical example of "a good place to use that." :-)
--
Darren New, San Diego CA, USA (PST)
Understanding the structure of the universe
via religion is like understanding the
structure of computers via Tron.
Post a reply to this message
|
![](/i/fill.gif) |