Re: boost::function syntax

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-08-26 13:37:00

shyamemani wrote:
> Thanks Douglar and Rainer for your response....I tried tracing the
> production filled my trashcan with parse trees sketches but had to
> give up.
>
>    I was reading the Herb Sutter's article Generalizing Observer in
> CUJ where he uses this functionlity to implement a generic call
> back.

I alread mentioned to Mr. Sutter that boost::function,boost::bind, and
boost::signals does everything he does manually in his article, and he
acknowledged it.

>  But I have some issues:
>     By using this library we can eliminate the function name
> dependency introduced by using a call back interface and can call
> any function which matches the signature.

That's what you want to do. The caller should never have to know a name, and
never does in a callback interface. Perhaps you are referring to a
particular class name in standard C++ member function pointer callbacks.

>  But wouldn't this cause a
> maintainance problem?

Why ?

>  Using the call back interface defines the
> name of the function, it is easy to find the execution block for an
> event.

That's what documentation is about, not good programming.

>  Using this library it becomes a more of a coding convention
> than a compile time check.

There is nothing coding conventional about binding a member function to
boost::function, other than ease of use for which I am only too glad to
employ.

>     It may have removed the cost of virtual function call but I
> think the performance would be offset by the extra call to operator
> ().

Terrible <g>. Are you really serious to believe that the cost of one more
indirection is too high for the ability of having any function with the
correct signature handle a callback or an event. Are you programming on an
8080 or 6809 still ?

> So though it is a very good feature of language, does it not
> open doors for more cost?

If the extra indirection is too costly for you, don't use it. I find it a
pleasure to have any member function of any class, with the correct
signature, able to handle a boost::function callback or a boost::signals
event, and to design callbacks and events in this easy style. The sheer ease
of that dwarfs the incredibly little I pay in speed because of a single
extra indirection each time. I think you have to be a bit strange to even
consider this as "more cost" when you design your program.