Boost logo

Boost :

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
> 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
> (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
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at