Douglas Gregor wrote:
On Tuesday 26 August 2003 02:56 pm, shyamemani wrote:
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.
I think we have a little communication confusion, and I think it's my fault. What do you mean by "call back interfaces"? Function pointers? Hardcoded calls to particular routines? Or are by "interfaces" are you talking about something akin to Java's interfaces?
Calling through a boost::function will incur essentially the same overhead as calling through a virtual function.
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.
boost::function doesn't support multiple events. That's why we have Boost.Signals built on top of boost::function.
This has reminded to ask you: Is there a reason Boost.Signals wasn't submitted for TR1 approval other than the worked involved doing so by writing up the necessary submittal form ? I would very much like to see the C++ standard library adopt a common event handling interface, whether through a library such as yours or an extension to the language ( such as Borland's __closure pointer ). Handling events in a common way, and especially allowing both events and handlers ( signals and slots ) to be free of specific class limitations, will move C++ much closer to a modern paradigm which I find invaluable in using the language.