On Tuesday 26 August 2003 01:57 pm, shyamemani wrote:

I was reading the Herb Sutter's article Generalizing Observer in CUJ where he uses this functionlity to implement a generic call back. 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. But wouldn't this cause a maintainance problem? Using the call back interface defines the name of the function, it is easy to find the execution block for an event. Using this library it becomes a more of a coding convention than a compile time check.

In my experience it has not caused a maintenance problem, and in fact it often helps to decouple an operation from the code that reports the progress of the operation.

It may have removed the cost of virtual function call but I think the performance would be offset by the extra call to operator (). So though it is a very good feature of language, does it not open doors for more cost?

Sure, it could. Calling through a function<> object incurs some additional overhead, but it has its benefits. The cost of extra call to operator() (e.g., of a function object in stored in a function<>) is either negligible (if operator() does something real) or operator() will be inlined anyway (if operator() is small). FWIW, I've heard lots of concerns from those that might use that boost::function<> may be too slow, but never any complaints from users that it is in fact too slow. Doug

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" <eddielee@t...> wrote: the 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.

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.

On Tuesday 26 August 2003 07:36 pm, shyamemani wrote:

I hate writing code in mailing list but here is a sample of what I want to do. I have a tree data strucutre class which fires event and each event has some different parameters that are passed to it. What I want to illustrate is that by calling one register function I get access to three events. In boost.signal this would require that the client call the connect for each event. Is this a good application for this library?

Perhaps not. When you have multiple events going to a single listener from a single source, signal/slot mechanisms aren't as useful as the interface/listener paradigm you are already using. Signals might be appropriate if you had a single event that could be any of those three: enum NodeEvent { node_added, node_changed, node_deleted }; boost::signal<void (NodeEvent event, Node* node)> onNodeEvent; This may have some advantages over the iterface/listener approach you're using (for instance, the automatic disconnect when trackable objects are destructed or the ability to use Bind/Lambda), but it's very likely that Signals is not the right choice for this interface. Doug

shyamemani wrote:

So combining this response with your response to Edward regarding standardization of boost.signal, shouldn't this be a big concern, since the use-case which I illustrated is quite commonly used in event based systems?

No, it is not common to want to have a single event handler for events with different signatures. Or to register different event handlers for separate events all with one call. What you are doing is saying that you have these needs, and because a library doesn't fulfill them for you, let's have a language extension to solve your special case. The normal event-handler paradigm is that: 1) a single event handler handles a single event 2) an event may have more than one event handler 3) an event handler may handle more than one event, if and only if, the signature for the event handler is exactly the same for different events and there is a way of telling which one of the events has occurred in the event handler. When you want to go outside this basic paradigm, it is up to you to write code to do so, not for libraries to change merely to accomodate your needs. That doesn't mean you can't suggest additions to libraries which you feel are in the realm of event handling, but you must justify them as being worthwhile not just for you but for programmers in general. Or else create your own library to solve your own problem and perhaps others.

But if this can be ironed out I think providing it as a language extension is better because then C++ can become a language which has built-in semantics for use of the standard design patterns. And then we programmar's and designers can live happily ever after ....

Built-in semantics can be just as limiting, for your needs, as a library and provide no guarantee of happiness. In general, in a case where both a library and a language extension can provide the same solution to some programming paradigm in C++, the most important case for a language addition is, IMHO, ease of programming use. In general it is much better, because more flexible, to extend a language via libraries than adding language extensions. With all that said, having used a language extension for many years which provides event handling to C++, Borland's __closure, and most recently Microsoft's __event and __delegate extensions, I am very much for either adding Mr. Gregor's excellent Boost.Signals in some close form to the C++ standard library, or adding a language extension patterned after the Microsoft and/or Borland solutions to the C++ standard language. However, none of these solve your particular event programming model which I find a very weird and overly complicated design. There is no need in a good event-handler model, such as Boost.Signals, for handlers to derive from a class which represents the events to be handled. Nor do events to be handled need to be virtual. If you take a look at Boost.Signals, and study how it works, you will see that the event and the event handler are only dependent on the signature of the event to be handled, and nothing else really. As long as you have an appropriate signature to handle the event, you can bind to it with any appropriate handler, most particularly member functions of any object's class. I don't think you appreciate yet why this model is so superior to yours as far as ease of use is concerned. The whole idea of a good event-handler model is that the event be coupled as lightly as possible to the event's handlers. This is what Mr. Gregor achieves in his library and also what the Borland and Microsoft extensions also achieve in their own different ways. There is no need to enforce particular derivations or virtual functions in these models.

shyamemani wrote:

--- In Boost-Users@yahoogroups.com, "Edward Diener" <eddielee@t...> wrote:

...

shyamemani wrote:

...

No, it is not common to want to have a single event handler for events with different signatures. Or to register different event handlers for separate events all with one call. What you are doing is saying that you have these needs, and because a library doesn't fulfill them for you, let's have a language extension to solve your special case.

The normal event-handler paradigm is that:

1) a single event handler handles a single event 2) an event may have more than one event handler

The callback interface I wrote previously follows both these rules, since a event is handled by one function in the interface the single event and single handler rule is satisfied. The collection of interface pointers in the event source takes care of rules 2. Registering an interface pointer is equivalent to creating <n> boost::function instances (where n is number of functions defined in the interface) and passing them different member function pointers of the same class.

That's fine and there is nothing in general wrong with what you are doing here.

...

3) an event handler may handle more than one event, if and only if, the signature for the event handler is exactly the same for different events and there is a way of telling which one of the events has occurred in the event handler.

In the condition when one event handler, handles more than one events, the call back interface is much better implementaion since it calls the correct function using the v-table instead of the hand-coded switch case statement (or some other conditional expression) in the handler.

My criticism is the need to make the client handler derive from the class with the virtual event calls. This is too much coupling to me for a general system. For your specific needs it might be fine. I have no general objection to an event handler which then calls the real events however it wants, through virtual functions if you like. Nor do I have a general objection to registering multiple handlers, from within your own code, at the same time. But when you want to insist that a system must use your own paradigms for your complicated event and event-handling needs, I say that this should not be the purpose of a general purpose event handling design submitted as part of the C++ standard library.

I do not doubt the power of boost::function and boost::signal libraries but one cannot dismiss the proven paradigm of call back interfaces.

I don't know what you mean here. Boost::function implements a callback interface.

Especially in scenarios where events have to be marshalled accross process or network boundaries. In that case since the cost of marshalling is high and only one register function call would be prefered to receive all pertinent events. Also the event parameters have to be tuned to minimize marshalling and are optimized the common use case scenarios of the events.

Then it is up to you to write your own library to deal with marshalling issues. An easy solution would be to create a proxy on the server side ( where Boost::Signals resides ) that works the way you like and minimizes traffic.

A digression: the microsoft __delegate keyword generates code that uses "reflection" and special CLR tags to call the correct function :( and hence it cannot be used with unmanaged c++ code. So though it may provide a similar construct for events handling it is not as powerful and generalized as boost::functions.

I agree, except that it is powerful in its own right in .NET programming.

Douglas Gregor wrote:

On Tuesday 26 August 2003 05:41 pm, Edward Diener wrote:

...

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 ?

Yes, there's a reason: Signals isn't ready for standardization. It hasn't been around long enough for us to be sure we have the right interface, nor is it small enough that we can say "yep, that's the right interface." More specifically, there are some parts of the interface that I don't believe are entirely correct, including:

1) Combiners and the slot_call_iterator: I think the interface is correct (although the implementation is very complex), but we can't say for sure that it was worth the effort.

The complex implementation shouldn't be a bar to it being used. It provides a means of handling all return values as the signal sees fit. I think it is brilliant. It's a slightly complicated issue for the designer of the event and not the event handlers, who just return the appropriate value, and that is how things should be.

2) Slot ordering, groups, and naming: I'm pretty sure we have this wrong, but I don't know what's better. Most applications could do with a simple linked list of slots, that are called in the order they are connected; a few more apps would benefit from the ability to connect to the front or back of the list; but there don't seem to be many apps that actually need the ordering & naming that Signals provides.

I agree that this could be provided with a different general purpose mechanism for determining the order in which signals are called. If I think of anything brilliant myself, or even mildly interesting <g>, I will convey it to you.

3) Trackability: there's a general tracking interface here that would be really useful, but I haven't had the time to pull it out.

Yes, it seems that requiring a class to be derived from a particular class to be trackable might be too much coupling. But it works and should be little problem considering C++'s multiple derivation ability. I can't think of a better way offhand to do it. Somehow the object which contains the slot must tell the signal whether it is still alive or not.

4) Multithreading: this isn't much of a concern for the standard right now, but without a solid multithreaded implementation I don't want to try to standardize the interface for fear that it may not allow a good multithreaded implementation.

I don't see how Boost.Signals can or should take into account multi-threading issues, but I am sure you have thought long and hard about this regarding situations of which I have no awareness. I have a gut feeling that multi-threading issues must be solved by either a separate C++ library, like Boost.Threads, or by the language itself, and should not be the domain of every other implementation.

...

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.

I agree that it would be very useful to have a common event handling interface, although I firmly believe it should come in the form of a library and not via a language extension. I'll be happy to propose Signals when I think we've hammered out the existing problems.

I hope you do. C++ needs to move more solidly into the present paradigms of programming, and event handling as a language/library interface has become, at least for me, almost ubiquitous with effective modern day programming practices. Of course I also like the "property" idea, in the property/method/event programming model, but I have found it is fruitless to argue with others about it since the resistance to syntactical sugar, no matter how elegant it may be, is ingrained in most C++ programmers. But events serve a much deeper purpose which makes programming itself much easier and clearer.

Peter Dimov wrote:

Douglas Gregor wrote:

...

3) Trackability: there's a general tracking interface here that would be really useful, but I haven't had the time to pull it out.

I think I mentioned this before: one alternative tracking model is to catch bad_weak_ptr and autodisconnect.

Doesn't this require the end-user to wrap their trackable object, which has an event handling member function, in a smart pointer if they want to be automatically tracked ? If so, it provides an alternative trackable model to the derivation one in the current Boost.Signals library but with its own downside. The major one would be that the object must be dynamically allocated. Whereas in the current implementation this is not necessary. The plus side is that it would no longer be necessary to derive from a particular base class in order to be trackable. So there are definite tradeoffs both ways. If the library were willing to live with and create multiple means that the object be trackable, which I see as perfectly viable and in the spririt of C++, I would say it should create your choice also.

Douglas Gregor wrote:

On Wednesday 27 August 2003 04:51 pm, Edward Diener wrote:

...

If so, it provides an alternative trackable model to the derivation one in the current Boost.Signals library but with its own downside. The major one would be that the object must be dynamically allocated. Whereas in the current implementation this is not necessary. The plus side is that it would no longer be necessary to derive from a particular base class in order to be trackable. So there are definite tradeoffs both ways. If the library were willing to live with and create multiple means that the object be trackable, which I see as perfectly viable and in the spririt of C++, I would say it should create your choice also.

I've had plans to support something like what Peter suggests for a while (he suggested it a while ago <g>), but unfortunately it's a little more complicated than just catching bad_weak_ptr because of the slot_call_iterator. You actually have to figure out what weak_ptrs are sitting around and check if they can be locked ahead of time.

I didn't mean to say that it should be done, no matter how difficult it might be, only that if it were easily doable it might be a good addition to Boost.Signals as an alternative way of tracking objects.