drdobbs-interview.html

这个帮助文档就不需要解释了

<P>
     I don't think that would be quite right for in-memory data
structures, but this is something that needs to be done. The same
interfaces defined by STL need to be implemented with other data
structures---skip lists, splay trees, half-balanced trees, and so
on.  It's a major research activity that needs to be done because
STL provides us with a framework where we can compare the
performance of these structures.  The interface is fixed.  The
basic complexity requirements are fixed.  Now we can have
meaningful experiments comparing different data structures to
each other.  There were a lot of people from the data structure
community coming up with all kinds of data structures for that
kind of interface.  I hope that they would implement them as
generic data structures within the STL framework.
</P>





<P>
<B>
Are compiler vendors working with you to implement STL into their
products?
</B>
</P>



<P>
     Yes.  I get a lot of calls from compiler vendors. Pete
Becker of Borland was extremely helpful.  He helped by writing
some code so that we could implement allocators for all the
memory models of Borland compilers.  Symantec is going to release
an STL implementation for their Macintosh compiler.  Edison
Design Group has been very helpful.  We have had a lot of support
from most compiler vendors.
</P>




<P>
<B>
STL includes templates that support memory models of 16-bit MS-DOS compilers. With the current emphasis on 32-bit, flat model
compilers and operating systems, do you think that the memory-model orientation will continue to be valid?
</B>
</P>





<P>
     Irrespective of Intel architecture, memory model is an
object, which encapsulates the information about what is a
pointer, what are the integer size and difference types
associated with this pointer, what is the reference type
associated with this pointer, and so on.  Abstracting that is
important if we introduce other kinds of memory such as
persistent memory, shared memory, and so on.  A nice feature of
STL is that the only place that mentions the machine-related
types in STL---something that refers to real pointer, real
reference---is encapsulated within roughly 16 lines of code.
Everything else, all the containers, all the algorithms, are
built abstractly without mentioning anything which relates to the
machine.  From the point of view of portability, all the
machine-specific things which relate to the notion of address, pointer,
and so on, are encapsulated within a tiny, well-understood
mechanism. Allocators, however, are not essential to STL, not as
essential as the decomposition of fundamental data structures and
algorithms.
</P>




<P>
<B>
The ANSI/ISO C Standards committee treated platform-specific
issues such as memory models as implementation details and did
not attempt to codify them. Will the C++ committee be taking a
different view of these issues?  If so, why?
</B>
</P>





<P>
     I think that STL is ahead of the C++ standard from the point
of view of memory models.  But there is a significant difference
between C and C++.  C++ has constructors and operator new, which
deal with memory model and which are part of the language.  It
might be important now to look at generalizing things like
operator new to be able to take allocators the way STL containers
take allocators.  It is not as important now as it was before STL
was accepted, because STL data structures will eliminate the
majority of the needs for using new.  Most people should not
allocate arrays because STL does an effective job in doing so.  I
never need to use new in my code, and I pay great attention to
efficiency.  The code tends to be more efficient than if I were
to use new.  With the acceptance of STL, new will sort of fade
away.  STL also solves the problem of deleting because, for
example, in the case of a vector, the destructor will destroy it
on the exit from the block.  You don't need to worry about
releasing the storage as you do when you use new.  STL can
dramatically minimize the demand for garbage collection.
Disciplined use of containers allows you to do whatever you need
to do without automatic memory management.  The STL constructors
and destructors do allocation properly.
</P>





<P>
<B>
The C++ Standard Library subcommittee is defining standard
namespaces and conventions for exception handling.  Will STL
classes have namespaces and throw exceptions?
</B>
</P>



<P>
     Yes they will.  Members of the committee are dealing with
that, and they are doing a great job.
</P>





<P>
<B>
How different from the current STL definition will the eventual
standard definition be?  Will the committee influence changes or
is the design under tighter control?
</B>
</P>



<P>
     It seems to be a consensus that there should not be any
major changes to STL.
</P>



<P>
<B>
How can programmers gain an early experience with STL in
anticipation of it becoming a standard?
</B>
</P>



<P>
     They can download the STL header files from
<tt>butler.hpl.hp.com</tt> under <tt>/stl</tt> and use it with Borland or IBM
compiler, or with any other compiler powerful enough to handle
STL   The only way to learn some style of programming is by
programming. They need to look at examples and write programs in
this style.
</P>



<P>
<B>
You are collaborating with P.J. (Bill) Plauger to write a book
about STL. What will be the emphasis of the book and when is it
scheduled to be published?
</B>
</P>





<P>
     It is scheduled to be published in the summer of 1995 and is
going to be an annotated STL implementation.  It will be similar
to Bill's books on the Standard C Library and the Draft Standard
C++ Library.  He is taking the lead on the book, which will serve
as a standard reference document on the use of the STL. I hope to
write a paper with Bjarne that will address language/library
interactions in the context of C++/STL. It might lead to another
book.
</P>

<P>
    A lot more work needs to be done.  For STL to become a
success, people should do research experimenting with this style
of programming.  More books and articles need to be written
explaining how to program in this style.  Courses need to be
developed.  Tutorials need to be written.  Tools need to be built
which help people navigate through libraries.  STL is a framework
and it would be nice to have a tool with which to browse through
this framework.
</P>





<P>
<B>
What is the relationship between generic programming and 
object-oriented programming?
</B>
</P>



<P>
     In one sense, generic programming is a natural continuation
of the fundamental ideas of object-oriented programming---separating
 the interface and implementation and polymorphic
behavior of the components.  However, there is a radical
difference.  Object-oriented programming emphasizes the syntax of
linguistic elements of the program construction.  You have to use
inheritance, you have to use classes, you have to use objects,
objects send messages.  Generic programming does not start with
the notion of whether you use inheritance or you don't use
inheritance.  It starts with an attempt to classify or produce a
taxonomy of what kinds of things are there and how they behave.
That is, what does it mean that two things are equal?  What is
the right way to define equality?  Not just actions of equality.
You can analyze equality deeper and discover that there is a
generic notion of equality wherein two objects are equal if their
parts, or at least their essential parts are equal.  We can have
a generic recipe for an equality operation.  We can discuss what
kinds of objects there are.  There are sequences.  There are
operations on sequences.  What are the semantics of these
operations?  What types of sequences from the point of view of
complexity tradeoffs should we offer the user?  What kinds of
algorithms are there on sequences?  What kind of different
sorting functions do we need? And only after we develop that,
after we have the conceptual taxonomy of the components, do we
address the issue of how to implement them.  Do we use templates?
Do we use inheritance?  Do we use macros?  What kind of language
technology do we use?  The fundamental idea of generic
programming is to classify abstract software components and their
behavior and come up with a standard taxonomy.  The starting
point is with real, efficient algorithms and data structures and
not with the language. Of course, it is always embodied in the
language.  You cannot have generic programming outside of a
language.  STL is done in C++.  You could implement it in Ada.
You could implement it in other languages.  They would be
slightly different, but there are some fundamental things that
would be there.  Binary search has to be everywhere.  Sort has to
be everywhere.  That's what people do.  There will be some
modification on the semantics of the containers, slight
modifications imposed by the language.  In some languages you can
use inheritance more, in some languages you have to use
templates.  But the fundamental difference is precisely that
generic programming starts with semantics and semantic
decomposition.  For example, we decide that we need a component
called <tt>swap</tt>.  Then we figure out how this particular component
will work in different languages.  The emphasis is on the
semantics and semantic classification, while object-orientedness,
especially as it has evolved, places a much stronger emphasis,
and, I think, too much of an emphasis, on precisely how to
develop things, that is, using class hierarchies.  OOP tells you
how to build class hierarchies, but it doesn't tell you what
should be inside those class hierarchies.
</P>





<P>
<B>
What do you see as the future of STL and generic programming?
</B>
</P>



<P>
     I mentioned before the dream of programmers having standard
repositories of abstract components with interfaces that are well
understood and that conform to common paradigms.  To do that
there needs to be a lot more effort to develop the scientific
underpinnings of this style of programming.  STL starts it to
some degree by classifying the semantics of some fundamental
components.  We need to work more on that.  The goal is to
transform software engineering from a craft to an engineering
discipline. It needs a taxonomy of fundamental concepts and some
laws that govern those concepts, which are well understood, which
can be taught, which every programmer knows even if he cannot
state them correctly.  Many people know arithmetic even if they
never heard of commutativity.  Everybody who graduated from high
school knows that 2+5 is equal to 5+2.  Not all of them know that
it is a commutative property of addition.  I hope that most
programmers will learn the fundamental semantic properties of
fundamental operations.  What does assignment mean?  What does
equality mean?  How to construct data structures.
</P>

<P>
     At present C++ is the best vehicle for this style of
programming.  I have tried different languages and I think that
C++ allows this marvelous combination of abstractness and
efficiency.  However, I think that it is possible to design a
language based on C and on many of the insights that C++ brought
into the world, a language which is more suitable to this style
of programming, which lacks some of the deficiencies of C++, in
particular its enormous size.  STL deals with things called
concepts.  What is an iterator?  Not a class.  Not a type.  It is
a concept. (Or, if we want to be more formal, it is what Bourbaki
calls a structure type, what logicians call a theory, or what
type theory people call a sort.) It is something which doesn't
have a linguistic incarnation in C++.  But it could.  You could
have a language where you could talk about concepts, refine them,
and then finally form them in a very programmatic kind of way
into classes.  (There are, of course, languages that deal with
sorts, but they are not of much use if you want to sort.) We
could have a language where we could define something called
forward iterator, which is just defined as a concept in STL---it
doesn't have a C++ incarnation.  Then we can refine forward
iterator into bidirectional iterator.  Then random iterator can
be refined from that.  It is possible to design a language which
would enable even far greater ease for this style of programming.
I am fully convinced that it has to be as efficient and as close
to the machine as are C and C++.  And I do believe that it is
possible to construct a language that allows close approximation
to the machine on the one hand and has the ability to deal with
very abstract entities on the other hand.  I think that
abstractness can be even greater than it is in C++ without
creating a gap between underlying machines.  I think that generic
programming can influence language research and that we will have
practical languages, which are easy to use and are well suited
for that style of programming.  From that you can deduce what I
am planning to work on next.
</P>

<Address>
Copyright &copy; 1995 <A href="http://www.ddj.com">Dr. Dobb's Journal</A>
</Address>

<!--start footer--> 
<HR SIZE="6">
<A href="http://www.sgi.com/"><IMG SRC="surf.gif" HEIGHT="54" WIDTH="54" 
        ALT="[Silicon Surf]"></A>
<A HREF="index.html"><IMG SRC="stl_home.gif" 
        HEIGHT="54" WIDTH="54" ALT="[STL Home]"></A>
<BR>
<FONT SIZE="-2">
<A href="http://www.sgi.com/Misc/sgi_info.html" TARGET="_top">Copyright &copy; 
1996 Silicon Graphics, Inc.</A> All Rights Reserved.</FONT>
<FONT SIZE="-3"><a href="http://www.sgi.com/Misc/external.list.html" TARGET="_top">TrademarkInformation</A>
</FONT>
<P>
</BODY>
</HTML>