📄 doc_introduction.html
字号:
<!DOCTYPE HTML PUBLIC "-//Netscape Comm. Corp.//DTD HTML//EN"><HTML><HEAD> <!-- SGI_COMMENT COSMOCREATE --> <!-- SGI_COMMENT VERSION NUMBER="1.0" --> <TITLE>How to use the STL documentation</TITLE></HEAD><BODY TEXT="#000000" LINK="#006600" ALINK="#003300" VLINK="#7C7F87" BGCOLOR="#FFFFFF"><A HREF="/"><IMG SRC="/images/common/sgilogo_small.gif" ALT="SGI Logo" WIDTH="80" HEIGHT="72" BORDER="0"></A><P><!--end header--><CENTER><H1 ALIGN="CENTER">How to use the STL documentation</H1></CENTER><P>This site documents all of the components (classes, functions, and concepts) in the SGI Standard Template Library. Each page describes a single component, and also includes links to related components. </P><P>This documentation assumes a general familiarity with C++, especially with C++ templates. Additionally, you should read <A HREF="stl_introduction.html">Introduction to the Standard Template Library</A> before proceeding to the pages that describe individual components: the introductory page defines several terms that are used throughout the documentation.</P><H2>Classification of STL components</H2><P>The STL components are divided into six broad categories on the basis of functionality: <I>Containers</I>, <I>Iterators</I>, <I>Algorithms</I>, <I>Function Objects</I>, <I>Utilities</I>, and <I>Allocators</I>; these categories are defined in the <A HREF="stl_introduction.html">Introduction</A>, and the <A HREF="table_of_contents.html">Table of Contents</A> is organized according to them. </P><P>The STL documentation contains two indices. One of them, the <A HREF="stl_index.html">Main Index</A>, lists all components in alphabetical order. The other, the <A HREF="stl_index_cat.html">Divided Index</A>, contains a separate alphabetical listing for each category. The Divided Index includes one category that is not present in the Table of Contents: <I>Adaptors</I>. An adaptor is a class or a function that transforms one interface into a different one. The reason that adaptors don't appear in the Table of Contents is that no component is merely an adaptor, but always an adaptor and something else; <TT><A href="stack.html">stack</A></TT>, for example, is a container and an adaptor. Accordingly, <TT><A href="stack.html">stack</A></TT> appears in two different places in the Divided Index. There are several other components that appear in the Divided Index in more than one place. </P><P>The STL documentation classifies components in two ways.<OL> <LI><i>Categories</i> are a classification by functionality. The categories are: <UL> <LI>Container <LI>Iterator <LI>Algorithm <LI>Function Object <LI>Utility <LI>Adaptor <LI>Allocator. </UL> <LI><i>Component types</i> are a structural classification: one based on what kind of C++ entity (if any) a component is. The component types are: <UL> <LI>Type (<i>i.e.</i> a <TT>struct</TT> or <TT>class</TT>) <LI>Function <LI>Concept (as defined in the <A HREF="stl_introduction.html">Introduction</A>). </UL></OL></P><P>These two classification schemes are independent, and each of them applies to every STL component; <TT><A href="Vector.html">vector</A></TT>, for example, is a <I>type</I> whose category is <I>Containers</I>, and <B><A href="ForwardIterator.html">Forward Iterator</A></B> is a <I>concept</I> whose category is <I>Iterators</I>. </P><P>Both of these classification schemes appear at the top of every page that documents an STL component. The upper left corner identifies the the component's category as <I>Containers</I>,<I> Iterators</I>, <I>Algorithms</I>, <I>Function Objects</I>, <I>Utilities</I>, <I>Adaptors</I>, or <I>Allocators</I>, and the upper right corner identifies the component as a <I>type</I>, a <I>function</I>, or a <I>concept</I>. </P><H2>Using the STL documentation</H2><P>The STL is a <I>generic</I> library: almost every class and function is a template. Accordingly, one of the most important purposes of the STL documentation is to provide a clear description of which types may be used to instantiate those templates. As described in the <A HREF="stl_introduction.html">Introduction</A>, a <I>concept </I>is a generic set of requirements that a type must satisfy: a type is said to be a <I>model of</I> a concept if it satisfies all of that concept's requirements. </P><P>Concepts are used very heavily in the STL documentation, both because they directly express type requirements, and because they are a tool for organizing types conceptually. (For example, the fact that <TT><A href="ostream_iterator.html">ostream_iterator</A></TT>and <TT><A href="insert_iterator.html">insert_iterator</A></TT> are both models of <B><A href="OutputIterator.html">Output Iterator</A></B> is an important statement about what those two classes have in common.) Concepts are used for the documentation of both <I>types</I> and <I>functions</I>.</P><H3>The format of a <I>concept </I>page</H3><P>A page that documents a <I>concept</I> has the following sections. </P><UL> <LI> <B>Summary:</B> A description of the concept's purpose. <LI> <B>Refinement of:</B> A list of other concepts that this concept <I>refines</I>, with links to those concepts. <LI> <B>Associated types:</B> A concept is a set of requirements on some type. Frequently, however, some of those requirements involve some other type. For example, one of the<B> <A href="UnaryFunction.html">Unary Function</A></B> requirements is that a <B><A href="UnaryFunction.html">Unary Function</A></B> must have an <I>argument type</I>; if <TT>F</TT> is a type that models <B><A href="UnaryFunction.html">Unary Function</A></B> and <TT>f</TT> is an object of type <TT>F</TT>, then, in the expression <TT>f(x)</TT>, <TT>x</TT> must be of <TT>F</TT>'s argument type. If a concept does have any such associated types, then they are defined in this section. <LI> <B>Notation</B>: The next three sections, <B>definitions</B>, <B>valid expressions</B>, and <B>expression semantics</B>, present expressions involving types that model the concept being defined. This section defines the meaning of the variables and identifiers used in those expressions. <LI> <B>Definitions</B>: Some concepts, such as <B><A href="LessThanComparable.html">LessThan Comparable</A></B>, use specialized terminology. If a concept requires any such terminology, it is defined in this section. <LI> <B>Valid Expressions</B>: A type that models a concept is required to support certain operations. In most cases, it doesn't make sense to describe this in terms of specific functions or member functions: it doesn't make any difference, for example, whether a type that models <B><A href="InputIterator.html">Input Iterator</A></B> uses a global function or a member function to provide <TT>operator++</TT>. This section lists the expressions that a type modeling this concept must support. It includes any special requirements (if any) on the types of the expression's operands, and the expression's return type (if any). <LI> <B>Expression Semantics:</B> The previous section, <B>valid expressions</B>, lists which expressions involving a type must be supported; it doesn't, however, define the meaning of those expressions. This section does: it lists the semantics, preconditions, and postconditions for the expressions defined in the previous section. <LI> <B>Complexity Guarantees</B>: In some cases, the run-time complexity of certain operations is an important part of a concept's requirements. For example, one of the most significant distinctions between a <B><A href="BidirectionalIterator.html">Bidirectional Iterator</A></B> and a <B><A href="RandomAccessIterator.html">Random Access Iterator</A></B> is that, for random access iterators, expressions like <TT>p + n</TT> take constant time. Any such requirements on run-time complexity are listed in this section. <LI>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -