Boost logo

Boost Users :

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.


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