Boost logo

Boost Users :

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-08-26 16:41:03


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.


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net