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.