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
correct signature handle a callback or an event. Are you
When I mentioned the performance cost I was comparing two programming
techniques. a) Using call back interfaces and b) using
boost::functions. As Douglas mentioned that if the operator is
inlined, the performance of boost::function will be better since
virtual functions cannot be inlined by the compiler and I agree with
him.
But with interfaces I can define multiple functions in it and
register to recieve multiple events. Use of this in boost::function
would require calling register multiple times. I think I am
considering wrong application of the library.
I am willing to be a believer just show me the light :-)
Thanks,
Shyam
--- In Boost-Users@yahoogroups.com, "Edward Diener"
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.