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
        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 :-)



--- In Boost-Users_at_[hidden], "Edward Diener" <eddielee_at_t...>
> 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
> > CUJ where he uses this functionlity to implement a generic call
> > back.
> I alread mentioned to Mr. Sutter that boost::function,boost::bind,
> boost::signals does everything he does manually in his article, and
> 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
> > 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
> > 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
> > ().
> 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
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
> 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
> 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, kalb at, bjorn.karlsson at, gregod at, wekempf at