Boost logo

Boost :

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

"Greg Colvin" <greg_at_[hidden]> wrote in message
> [...]
> 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,

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


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