Re: boost::function syntax

26 Aug 2003

      ...
Douglas Gregor wrote:
...
On Tuesday 26 August 2003 02:56 pm, shyamemani wrote:
...
When I mentioned the performance cost I was comparing two
...
...
...
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
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?

     In deisgn like this, the programmar knows exactly which function 
to look for when an event is fired.  Hence it is easy to find the 
execution block.  Since the compiler looks for the pure virtual 
functions it enforces that these be implemented.  In boost::function 
or boost.signal the name of the function is not fixed hence takes 
more work.

class TreeEvent
{
public:
     virtual void node_added(Node* _node) = 0;
     virtual void node_deleted(const char* _path) = 0;
     virtual void node_accessed(Node* _node,int _change) = 0;
};

class Tree
{
     /* some variables*/
    std:: set listeners; /*set used to ensure unique 
listeners*/
public:
      void register(TreeEvent* _listen); /*add to listener set*/
      void unregister(TreeEvent* _listen); /*remove from listener 
set*/
      void add_node(const char* _path,Node* _node)
       {
	/* do something
	iterate through event set and call node_added function.*/
       }
      /* similar implementation for remove_node and get_node calling
	node_deleted and node_accessed functions on each element in 
the listeners set */
};

class MyClient : public TreeEvent
{
   /* some other stuff */
  /* implement pure virtual functions */
};

int main()
{
       Tree mytree; 
       /*...lot of stuff for tree creation...*/
       MyClient _client;
      /* this one call gives me access to all the events */
      mytree.register(&_client);
      /* other things */
}

the class MyClient now gets all the events and can do what it wants 
in response to these events.

Shyam

--- In Boost-Users@yahoogroups.com, "Edward Diener"  
wrote:
programming
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.