[boost] Re: Traits-based design and ODR

From: David B. Held (dheld_at_[hidden])
Date: 2002-05-02 13:37:21

"Greg Colvin" <greg_at_[hidden]> wrote in message
news:5.1.0.14.0.20020502104307.02ad0560_at_GMMAIL...
> [...]
> But the Standard Library, traditionally, is not so much a
> framework as a collection of utilities.  The framework is the
> language itself, which provides the richest possible design
> space.  This explains much of my reluctance to embrace a
> policy-based smart pointer framework for the Standard
> Library. Boost is another story.
>
> For example, consider the venerable low-level IO calls --
> fopen, fclose, fread, and so on.  They represent a hard-coded
> set of decisions about how to do portable, efficient, IO.  They
> are one point in a much richer space, but not just any point.
> They suffice for most purposes, and access to the rest of the
> design space is left to less portable mechanism, like direct uses
> of OS-specific IO mechanisms.  You could imagine a policy-
> based framework for low-level IO, with choices of buffering,
> flushing, blocking, file-mapping, and so on.  You could even
> implement it with C.  But would that have been a better choice
> for C, or C++?
> [...]

Greg, you obviously have a lot of experience, so take what I
say with a grain of salt.  But it seems to me that the f*() stdio
interface is a legacy of C.  A good legacy, no doubt, for the
reasons you mention.  But now we have iostreams, and not
only are they a part of the Standard Library, they are also a
"framework" in the way Loki is (sort of).  That is, they are
designed to be extended and customized by the user.  The
allocators in the standard containers are simply a policy, no?
Even the STL portion of the Standard Library is compile-
time customizable with specializations of std::less, std::swap,
etc.

It seems to me that the power of the Standard Library, and
of modern C++ in general, is in choice.  The fact that the
user has so many options to choose for various situations is
why I think it's such a successful language.  With shared_ptr,
the choices are mainly hardwired into the type.  I don't know
any other Standard Library types that do so much auto-
detection and runtime configuration.  To that extent, it seems
like Loki::SmartPtr is closer to the spirit of the SCL.

Don't get me wrong.  I think it's pretty clever the way
shared_ptr does its business.  And I can see how it can be
extended in various ways.  But many of those ways are under
the control of the library authors/maintainers.  I get the
impression that the future of C++ is in generic programming,
which I read as: "more choice for the user", and it seems
that Loki::SmartPtr is a solid step in that direction.  As a
stepping stone, we can leverage all the hard work and design
that has been put into shared_ptr by using a SmartPtr
emulation of shared_ptr with all the same interface and
behaviour.

Dave