Re: Callbacks Again

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-20 11:02:45

--- In boost_at_[hidden], Karl Nelson <kenelson_at_e...> wrote:
> [error generation]
> VC++ is always a limiting factor.  I had to jump through a hell
> of a lot of huddles to get my code to work there and some of the 
> template formulations still cause random errors.  I hope that
> someday everyone here comes to realize how worthless that 
> sorry excuse for a compiler is and boycots it.

Anyone that's tried to use VC++ for template programming that goes 
beyond "hello world" knows that it's template support sucks and would 
love to boycot it.  However, most people have little choice here.

> So lets look at another minor issue.  That is the virtuals tables.  
> I benchmarked your callbacks against SigC 1.1 slots for binary size.
> I implemented 21 functors like this
> 
> struct func_float_int_int
> {
>   float operator()(int a, int b) { return float(a*b); }
> };
> 
> for combinations of float, int, and double.  In then made one
> callback for each functor, set it and called it.  The
> resulting binary was 430k debug and 30K striped.  Most of the space 
was 
> nothing but almost wothless typeinfo functions.  
> 
>  00000094 W boost::detail::functor_callback<func_int_int_int, int, 
int, int, boost::detail::Unused> type_info function
> 
> SigC 1.1 formulation on similar test was 90k debug and 17.4k 
striped. 
> (done with static linking though much of is sharable in a library) 
> This difference came because SigC didn't use the virtual table to 
launch the
> callback but instead a function pointer.  However, I don't believe
> a similar technique is possible in your code.
> 
> This raise the problem I expressed before, that if you use a large 
> number of functor types it can eat a lot in binary size.  It doesn't
> look to extreme for your library, but you should test with 
> reasonable numbers of callbacks and functors to see how much it 
scales.
> I only optomized SigC because gtk-- used several hundred which
> would have added 2M to the library binary size in typeinfo and
> similar stuff.

The size is important, but not at expense of standards compliance or 
useability, so some evaluation is in order.  (Note:  I'm not 
suggesting that libsigc++ hasn't already evaluated this stuff, only 
that I'm not aware of it.)

Bill Kempf