Re: Why Jam?

From: danl_miller (danl_miller_at_[hidden])
Date: 2002-02-26 10:37:27

--- In boost_at_y..., Braden McDaniel <braden_at_e...> wrote:
> On Tue, 2002-02-26 at 06:48, Peter Dimov wrote:
> > _If_ you have a specific problem with Boost.Bind, or
Boost.SmartPtr, _then_
> > I will have to start offering solutions. ;-)
> 
> You seem to content to try to focus this discussion on Boost
libraries
> that consist only of headers. The problem is bigger than that, and
so is
> this discussion.

  I have noticed this tendency as well.  By artificially limiting this
topic (or any other Boost topic for that matter) to
header-only/compile-time-only libraries, artificially constrains Boost
contributors to design libraries which are
headers-only/compile-time-only, which would artificially constrain
Boost contributors to templates, file-scope constant integral &
real-number types, #defines, enumerations, inline functions, and any
other of the narrow set of C++ language constructs which do not
allocate storage.  Such an artificial limitation is an unacceptable
constraint in library interface design.

  Indeed, even if the artificial limiting of this topic does not
strictly constrain Boost developers to header-only/compile-time-only
libraries, this preference toward compile-time-only libraries in an
attempt to define away a few build complications could easily cause an
unfortunate peer-pressure toward compile-time-only libraries when a
canonical linked (non-header-only) library is more
appropriate/optimum.

  For example, when designing a linked-list class, the public
interface is considered best in many contexts to be strongly typed, as
is permitted via modeling the linked-list via a class template.  But
the internal implementation could fall into one of two broad
categories:
  1) strongly typed as well, implemented by class templates & function
templates throughout
  2) weakly-typed (or non-typed), implemented by casts to and from
void* as described in Stroustrup's _Design & evolution of C++_.

  The linked-list implemented via the #1 strongly-typed
templates-throughout choice may tend to cause greater
template-specialization bloat, resulting in larger executable size.

  The linked-list implemented via the #2 weakly/non-typed choice would
naturally eventually come down to one copy of a fixed-size set of
nontemplate/canonical functions (instead of the
one-copy-per-template-specialization which caused the bloat in choice
#1).

  Thus using canonical/nontemplate/nonparameterized functions/classes
at the core of the internal implementation of a library whose
interface is 100% templates/parameterized may benefit immensely from a
non-header-only/linked implementation.  Any constraint, bias, or
peer-pressure toward header-only/compile-time-only library
implementations can erode this essential form of optimization. 
(Template-specialization bloat is the #1 criticism against the use of
templates and thus this criticism must be headed, lest the library be
perceived/stigmatized in industrial usage as being too
ivory-tower/naive/100%-template-oriented and thus shunned for bloat
reasons.)

  Therefore, let us all follow Braden McDaniel's request to not
constrain these build-to-develop & build-to-execute topics by
discussing from merely a header-only/compile-time-only perspective.

  (The terms "build-to-develop" & "build-to-execute" were defined in
the following posts.  If the readers along this thread have not read
that thread, I highly recommend reading that thread.)

  http://groups.yahoo.com/group/boost/message/26040
  http://groups.yahoo.com/group/boost/message/26058