Re: [boost] Re: Re: the boost::signal sample crashes

From: Douglas Gregor (gregod_at_[hidden])
Date: 2003-08-05 00:36:52

----- Original Message ----- 
From: "E. Gladyshev" <egladysh_at_[hidden]>
> > > IMHO, boost needs to get rid of any possibility of
> > > this to happen.  Why does boost::signal() need a
> > > DLL/LIB in the first place?  Would not be just the
> > .h
> > > file enough?
> > >
> >
> > It could be put in a .h, but there is a lot of code
> > in the library and
> > it makes sense to have it built as a .lib.
>
> I think that it doesn't make sense if we have all
> these problems that you are talking about below. If
> the user wants to speed the compile-time up, he/she
> can always create a simple wrapper around the standard
> signal.h.

It's not just compile time, it's also the size of the generated code.
std::multimap instances tend to be huge on many platforms, and a typical
program that uses signals/slots tends to have many instantiations of
boost::signal<...> in it Sure, it would be possible to put everything into
header files, but now we're paying the cost of instantiating them in every
single translation unit.

> I am really worried about the road the boost comunity
> has choosen just to reduce the compile time.

Compile time is a huge problem for many programs. Sure, it doesn't matter
much with a 100 or 1000-line sample program, but get past 10k lines of
application code (not including the tens of thousands of lines brought in by
including Boost/C++ standard library headers) and your edit-compile-debug
turnaround time becomes unbearable. This is a real problem on real,
industrial code bases, and we have to deal with this problem.

> Please
> let the user to reduce the compile time (making his
> custom wrappers) any way he/she likes it.
> I want to be
> able to just include a .h file w/o having to verify
> that my program won't break from time to time because
> of some .lib/.h conflicts enforced on me by boost
> developers.

As I see it, it's a simple matter of economics. Say we can shave 15 minutes
off the required build time for project X by moving some Boost code into a .
lib. How many compiles will it take before the effort of creating/using that
.lib pays off? Two or three, perhaps, assuming it doesn't take more than 45
minutes to read the Boost.Build documentation to build the library for the
system? Sure, we could make it easier to build/link the libraries, e.g., on
Windows, and we're working on that, but even with the current
less-than-perfect state of affairs it is worth the effort.

Custom wrappers are fine, but again they cost time to create and maintain.
This cost is per-instantiation vs. the per-library cost of using a .lib.

> On the side note: this boost road already lead to the
> fact that the boost::thread library is not up-to-date
> anymore. Win32 supports two threading models that can
> be used in one application at the same time.
> boost::thread doesn't allow it.

The Boost.Threads library defines its own threading model and implements it
on several platforms. If two distinct threading models are useful with the
Boost.Threads model, then it can be extended to support that model. Windows'
two threading models aren't the only threading models out there, and one
thing that Boost.Threads brings to the table is a threading model that is
consistent across all platforms. How portable would a program that relies on
two coexisting Win32 threading models be?

> I think if we
> continue down this road, boost will be in a big
> trouble becoming a true industry standard (at least
> for some of its components).

Businesses are run by economics, and experience shows that refactoring code
into compiled libraries saves time.

> IMHO boost::signals should be in a .h file completely.
> I can always reduce the compile time myself if I need
> to.
>
> Eugene

I'm not opposed to providing an option to include all code into headers
(e.g., a BOOST_SIGNALS_NO_LIB macro akin to the RegEx macro), and clearly
where there are cases with problems stemming from the DLL/user code split
(e.g., pointers allocated in the DLL and freed in user code) I'll fix the
library, but I don't expect to see Boost moving toward putting more code
into headers in the future.

    Doug