Re: boost::function syntax

From: shyamemani (shyamemani_at_[hidden])
Date: 2003-08-26 18:36:59

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<TreeEvent*> 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_at_[hidden], "Edward Diener" <eddielee_at_t...> 
wrote:
> 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.