Re: boost::function syntax

From: shyamemani (shyamemani_at_[hidden])
Date: 2003-08-26 13:56:49

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_at_[hidden], "Edward Diener" <eddielee_at_t...> 
wrote:
> 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 
the
> correct signature handle a callback or an event. Are you 
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.