mirror of
https://gitlab.com/fbb-git/cppannotations
synced 2024-11-16 07:48:44 +01:00
Latex cleanup
git-svn-id: https://cppannotations.svn.sourceforge.net/svnroot/cppannotations/trunk@433 f6dd340e-d3f9-0310-b409-bdd246841980
This commit is contained in:
Frank B. Brokken
parent
f61c34b9c7
commit
6723551a46
29 changed files with 60 additions and 59 deletions
|
|
@ -3,7 +3,7 @@ recursive template meta programs. Two variadic template structs tt(Append) and
|
|||
tt(Prefix) and two specializations are all it takes.
|
||||
|
||||
Here are the declarations of the two variadic template structs:
|
||||
verbinsert(STRUCT)(advancedtemplates/examples/append.h)
|
||||
verbinsert(STRUCTS)(advancedtemplates/examples/append.h)
|
||||
|
||||
To append or prefix a new type to a typelist specializations expect a
|
||||
typelist and a type to add and simply define a new tt(TypeList) also including
|
||||
|
|
|
|||
|
|
@ -23,8 +23,8 @@ defined a specialization:
|
|||
std::cout << "This is the int-specialization\n";
|
||||
}
|
||||
)
|
||||
Since the compiler does not know whether a specialization of tt(member)
|
||||
will be in effect when tt(Derived<SomeType>::Derived) is called, it can't
|
||||
Since the compiler, when tt(Derived<SomeType>::Derived) is called, does
|
||||
not know whether a specialization of tt(member) will be in effect, it can't
|
||||
decide (when compiling tt(Derived<T>::Derived)) for what type to instantiate
|
||||
tt(member). It can't decide this when compiling tt(Derived<T>::Derived) as
|
||||
tt(member)'s call in tt(Derived::Derived) doesn't require a template type
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ tt(Erase)'s algorithm:
|
|||
it() If tt(TypeList)'s head matches tt(EraseType) tt(EraseAll) is also
|
||||
applied to the tt(TypeList)'s tail, thus removing all occurrences of
|
||||
tt(EraseType) from tt(TypeList):
|
||||
verbinsert(ALLTYPES)(advancedtemplates/examples/erase.h)
|
||||
verbinsert(ERASEALLTYPES)(advancedtemplates/examples/erase.h)
|
||||
it() In all other cases (i.e., tt(TypeList)'s head does em(not) match
|
||||
tt(EraseType)) tt(EraseAll) is applied to the tt(TypeList)'s tail.
|
||||
The returned tt(TypeList) consists of the original tt(TypeList)'s
|
||||
|
|
|
|||
|
|
@ -7,9 +7,9 @@ expects a tt(TypeList):
|
|||
declared. tt(EraseDup) structures define a type tt(List) representing the
|
||||
tt(TypeList) that they generate. tt(EraseDup) calls expect a tt(TypeList) as
|
||||
their template type parameters:
|
||||
verbinsert(ERASEDUP)(advancetemplates/examples/erase.h)
|
||||
verbinsert(ERASEDUP)(advancedtemplates/examples/erase.h)
|
||||
it() If the tt(TypeList) is empty it can be returned empty and we're done:
|
||||
verbinsert(ERASEDUPEMPTY)(advancetemplates/examples/erase.h)
|
||||
verbinsert(ERASEDUPEMPTY)(advancedtemplates/examples/erase.h)
|
||||
it() In all other cases
|
||||
itemization(
|
||||
it() tt(EraseDup) is first applied to the original tt(TypeList)'s
|
||||
|
|
@ -24,7 +24,7 @@ initial type to which the types of the tt(TypeList) produced by the previous
|
|||
step are appended.
|
||||
)
|
||||
This specialization is implemented like this:
|
||||
verbinsert(ERASEDUPHEAD)(advancetemplates/examples/erase.h)
|
||||
verbinsert(ERASEDUPHEAD)(advancedtemplates/examples/erase.h)
|
||||
)
|
||||
Here is an example showing how tt(EraseDup) can be used:
|
||||
verbinsert(ERASEDUP)(advancedtemplates/examples/erase.cc)
|
||||
|
|
@ -3,7 +3,7 @@
|
|||
|
||||
#include "typelist.h"
|
||||
|
||||
//STRUCTS
|
||||
//STRUCTS
|
||||
template <typename ... Types>
|
||||
struct Append;
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ struct TypeList
|
|||
enum { size = sizeof ... (Types) };
|
||||
};
|
||||
|
||||
//=VECTOR
|
||||
//VECTOR
|
||||
template <class Type>
|
||||
struct Vector: public std::vector<Type>
|
||||
{
|
||||
|
|
@ -52,7 +52,7 @@ struct TypeList
|
|||
};
|
||||
//=
|
||||
|
||||
//=MULTIBASEDONE
|
||||
//MULTIBASEDONE
|
||||
template <size_t nr>
|
||||
struct MultiBase<nr>
|
||||
{};
|
||||
|
|
|
|||
|
|
@ -12,12 +12,12 @@ pointers. tt(Derived const *) can be converted to tt(Base const *) if
|
|||
using the following trait class tt(LBaseRDerived). tt(LBaseRDerived) provides
|
||||
an enum tt(yes) which is 1 if the left type is a base class of the right type
|
||||
and both types are different:
|
||||
verbinsert(LBASERDERIVED)(advancedtemplates/examples/conversion.cc)
|
||||
verbinsert(LBASERDERIVED)(advancedtemplates/examples/conversion.h)
|
||||
|
||||
If code should not consider a class to be its own base class, then the
|
||||
trait class tt(LBaseRtrulyDerived) can be used to perform a strict test. This
|
||||
trait class adds a test for type-equality:
|
||||
verbinsert(LBASERTRUE)(advancedtemplates/examples/conversion.cc)
|
||||
verbinsert(LBASERTRUE)(advancedtemplates/examples/conversion.h)
|
||||
Example: the next statement displays tt(1: 0, 2: 1, 3: 0, 4: 1, 5: 0)
|
||||
when executed from a tt(main) function:
|
||||
verbinsert(INHERITANCE)(advancedtemplates/examples/conversion.cc)
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ tt(UWrap) types. Here is tt(MultiBase)'s generic class declaration:
|
|||
|
||||
Two specializations handle all possible tt(MultiBase) invocations. One
|
||||
specialization is a recursive template. This template handles the first type
|
||||
of tt(MultiBase)'s template parameter pack, and recursively uses itself to
|
||||
of tt(MultiBase)'s template parameter pack and recursively uses itself to
|
||||
handle the remaining types. The second specialization is invoked once the
|
||||
template parameter pack is exhausted and does nothing. Here is the definition
|
||||
of the latter specialization:
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ sect(Static data members)
|
|||
includefile(classtemplates/static)
|
||||
|
||||
lsubsect(DISTINGUISH)(Extended use of the keyword `typename')
|
||||
includefile(advancedtemplates/typename)
|
||||
includefile(classtemplates/typename)
|
||||
|
||||
sect(Specializing class templates for deviating types)
|
||||
includefile(classtemplates/specialization)
|
||||
|
|
|
|||
|
|
@ -63,8 +63,9 @@ class CirQue
|
|||
:
|
||||
d_size(0),
|
||||
d_maxSize(maxSize),
|
||||
d_data(maxSize == 0 ? 0 :
|
||||
static_cast<Data *>(operator new(maxSize * sizeof(Data)))),
|
||||
d_data(maxSize == 0 ? 0 :
|
||||
static_cast<Data *>(
|
||||
operator new(maxSize * sizeof(Data)))),
|
||||
d_front(d_data),
|
||||
d_back(d_data)
|
||||
{}
|
||||
|
|
|
|||
|
|
@ -18,9 +18,9 @@ first sight puzzling- error message like:
|
|||
)
|
||||
The error message is puzzling as it was the programmer's intention to
|
||||
declare a pointer to a type tt(Ambiguous) defined within the class template
|
||||
tt(Type). But the compiler, when confronted with tt(Type::Ambiguous) may
|
||||
interpret the statement in various ways. Clearly it cannot inspect tt(Type)
|
||||
itself trying to uncover tt(Type)'s true nature as tt(Type) is a template
|
||||
tt(Type). But the compiler, confronted with tt(Type::Ambiguous) may interpret
|
||||
the statement in various ways. Clearly it cannot inspect tt(Type) itself
|
||||
trying to uncover tt(Type)'s true nature as tt(Type) is a template
|
||||
type. Because of this tt(Type)'s actual definition isn't available yet.
|
||||
|
||||
The compiler is confronted with two possibilities: either
|
||||
|
|
|
|||
|
|
@ -58,7 +58,8 @@ includefile(concrete/bitwise)
|
|||
lsect(A2X)(A text to anything converter)
|
||||
includefile(concrete/a2x)
|
||||
|
||||
COMMENT(SUPERSEDED BY LAMBDA FUNCTIONS
|
||||
COMMENT(
|
||||
SUPERSEDED BY LAMBDA FUNCTIONS
|
||||
|
||||
lsect(STLWRAPPERS)(Wrappers for STL algorithms)
|
||||
includefile(concrete/wrappers)
|
||||
|
|
|
|||
|
|
@ -117,7 +117,6 @@ COMMENT( 19 )
|
|||
lchapter(GENERIC)(The STL Generic Algorithms)
|
||||
includefile(generic)
|
||||
|
||||
COMMENT(>>>>>>>>>>>>> NEXT <<<<<<<<<<<<<)
|
||||
COMMENT( 20 )
|
||||
lchapter(TEMPLATES)(Function Templates)
|
||||
includefile(functiontemplates)
|
||||
|
|
|
|||
|
|
@ -48,14 +48,14 @@ chapter ref(POLYMORPHISM). The example may be skipped, though, without
|
|||
loss of continuity.
|
||||
|
||||
A basic exception handling class can be constructed from which specific
|
||||
exception types are derived. Suppose we have a class tt(Exception),
|
||||
containing a member function tt(ExceptionType Exception::severity). This
|
||||
member function tells us (little wonder!) the severity of a thrown
|
||||
exception. It might be tt(Info, Notice, Warning, Error) or tt(Fatal). The
|
||||
information contained in the exception depends on its severity and is
|
||||
processed by a function tt(handle). In addition, all exceptions support a
|
||||
member function like ti(textMsg), returning textual information about the
|
||||
exception in a tt(string).
|
||||
exception types are derived. Suppose we have a class tt(Exception), having a
|
||||
member function tt(ExceptionType Exception::severity). This member function
|
||||
tells us (little wonder!) the severity of a thrown exception. It might be
|
||||
tt(Info, Notice, Warning, Error) or tt(Fatal). The information contained in
|
||||
the exception depends on its severity and is processed by a function
|
||||
tt(handle). In addition, all exceptions support a member function like
|
||||
ti(textMsg), returning textual information about the exception in a
|
||||
tt(string).
|
||||
|
||||
By defining a polymorphic function tt(handle) it can be made to behave
|
||||
differently, depending on the nature of a thrown exception, when called
|
||||
|
|
|
|||
|
|
@ -122,6 +122,6 @@ object. In situations like these the em(one-function-one-responsibility)
|
|||
i(rule of thumb) should be kept in mind: a function should have a single, well
|
||||
defined responsibility.
|
||||
|
||||
The preferred approach therefore is to retrieve tt(PersonDb)'s objects using a
|
||||
member like tt(Person const &at(size_t idx) const) and to erase an object
|
||||
using a separate member like tt(void PersonData::erase(size_t idx)).
|
||||
The preferred approach is to retrieve tt(PersonDb)'s objects using a member
|
||||
like tt(Person const &at(size_t idx) const) and to erase an object using a
|
||||
member like tt(void PersonData::erase(size_t idx)).
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ tt(Object::fun) defines a local tt(Object toThrow), that is
|
|||
thrown as an exception. The exception is caught
|
||||
in tt(main). But by then the object originally thrown doesn't exist anymore,
|
||||
and tt(main) received a copy:
|
||||
verbinsert(exceptions/examples/throw.cc)(PROG)
|
||||
verbinsert(PROG)(exceptions/examples/throw.cc)
|
||||
tt(Object)'s copy constructor is special in that it defines its name as
|
||||
tt(" (copy)") to which the other object's name is appended. This allow us to
|
||||
monitor the construction and destruction of objects more closely.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
In section ref(INSERTEXTRACT) the insertion operator of the class
|
||||
In section ref(EXTRACTORS) the insertion operator of the class
|
||||
tt(Person) (cf. section ref(ASSIGNMENT)) was implemented like this:
|
||||
verb(
|
||||
ostream &operator<<(ostream &out, Person const &person)
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Situations exist where the compiler is unable to infer that a reference rather
|
|||
than a value is passed to a template function. In the following example the
|
||||
template function tt(outer) receives tt(int x) as its argument and the
|
||||
compiler will dutifully infer that tt(Type) is tt(int):
|
||||
verbinsert(INT)(functiontemplates/examples/refwrapper.cc)
|
||||
verbinsert(INT)(functiontemplates/examples/refwrap.cc)
|
||||
Compilation will of course fail and the compiler nicely reports the
|
||||
inferred type, e.g.:
|
||||
verb(
|
||||
|
|
@ -14,7 +14,7 @@ example. The function tt(call) is a template expecting a function that takes
|
|||
an argument which is then itself modified, and a value to pass on to that
|
||||
function. Such a function is, e.g., tt(sqrtArg) expecting a reference to a
|
||||
tt(double), which is modified by calling tt(std::sqrt).
|
||||
verbinsert(DOUBLE)(functiontemplates/examples/refwrapper.cc)
|
||||
verbinsert(DOUBLE)(functiontemplates/examples/refwrap.cc)
|
||||
Assuming tt(double value = 3) then tt(call(sqrtArg, value)) will not modify
|
||||
tt(value) as the compiler infers tt(Arg) to be tt(double) and hence passes
|
||||
tt(value) by value.
|
||||
|
|
@ -29,6 +29,6 @@ The C++0x standard offers the ti(CHAR(r)ef(arg)) and ti(cref(arg))
|
|||
return it as a reference-typed argument. To actually change tt(value) it can
|
||||
be passed to tt(call) using tt(ref(value)) as shown in the following tt(main)
|
||||
function:
|
||||
verbinsert(MAIN)(functiontemplates/examples/refwrapper.cc)
|
||||
verbinsert(MAIN)(functiontemplates/examples/refwrap.cc)
|
||||
Before using reference wrappers the tthi(functional) header file must have
|
||||
been included.
|
||||
|
|
|
|||
|
|
@ -31,8 +31,7 @@ generic algorithms.
|
|||
|
||||
The tt(for_each) algorithm cannot directly be used (i.e., by passing
|
||||
tt(*this) as the function object argument) inside a member function to modify
|
||||
its own object as the tt(for_each) algorithm first creates its own copy of
|
||||
the passed function object. A em(wrapper class) whose constructor accepts a
|
||||
pointer or reference to the current object and possibly to one of its member
|
||||
functions solves this problem. In section ref(STLWRAPPERS) the construction
|
||||
of such wrapper classes is described.
|
||||
its own object as the tt(for_each) algorithm first creates its own copy of the
|
||||
passed function object. A emi(lambda function) or a em(wrapper class) whose
|
||||
constructor accepts a pointer or reference to the current object and possibly
|
||||
to one of its member functions solves this problem.
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ When tt(Second) uses virtual derivation its base class constructor is
|
|||
em(ignored) when tt(Second)'s constructor is called from tt(Third). Instead
|
||||
tt(Second) will by default call tt(First)'s default constructor. This is
|
||||
illustrated by the next example:
|
||||
verbinsert(CLASSES)(polymorhphism/examples/virtualinherit.cc)
|
||||
verbinsert(CLASSES)(polymorphism/examples/virtualinherit.cc)
|
||||
When constructing tt(Third) tt(First)'s default constructor is used by
|
||||
default. tt(Third)'s constructor, however, may overrule this default behavior
|
||||
by explicitly specifying the constructor to use. Since the tt(First) object
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
In chapter ref(IOStream) we encountered the class tt(fstream), one class
|
||||
In chapter ref(IOStreams) we encountered the class tt(fstream), one class
|
||||
offering features of tt(ifstream) and tt(ofstream). In chapter
|
||||
ref(INHERITANCE) we learned that a class may be derived from multiple base
|
||||
classes. Such a derived class inherits the properties of all its base
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
bf(C++) has traditionally offered the (deprecated by the C++0x standard) smart
|
||||
pointer class hi(auto_ptr)tt(std::auto_ptr<Type>). This class did not support
|
||||
emi(move semantics) although when one tt(auto_ptr) object was assigned to
|
||||
another, the right-hand object lost its information.
|
||||
The (now deprecated by the C++0x standard) smart pointer class
|
||||
hi(auto_ptr)tt(std::auto_ptr<Type>) has traditionally been offered by
|
||||
bf(C++). This class does not support emi(move semantics), but when an
|
||||
tt(auto_ptr) object is assigned to another, the right-hand object loses its
|
||||
information.
|
||||
|
||||
The class tt(unique_ptr) does not have tt(auto_ptr)'s drawbacks and
|
||||
consequently using tt(auto_ptr) is now deprecated. tt(Auto_ptrs) suffer from
|
||||
|
|
|
|||
|
|
@ -21,4 +21,4 @@ begin-iterator is em(not) mentioned with the default constructor.
|
|||
Using tt(back_inserter) and tt(istream_iterator) adaptors, all strings
|
||||
from a stream can easily be stored in a container. Example (using i(anonymous)
|
||||
tt(istream_iterator) adaptors):
|
||||
verbinclude(stl/cc/istreamiterator.cc)
|
||||
verbinclude(stl/examples/istreamiterator.cc)
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
The following standard distributions are currently available (an example
|
||||
showing their use is provided at the end of this section). The reader is
|
||||
referred to, e.g., lurl(http://en.wikipedia.org/wiki/Bernoulli_distribution)
|
||||
and comparable locations for more information about the distributions
|
||||
mentioned below.
|
||||
referred to web-locations like
|
||||
lurl(http://en.wikipedia.org/wiki/Bernoulli_distribution) for more information
|
||||
about the distributions mentioned below.
|
||||
|
||||
All distributions offer the following members (em(result_type) refers to
|
||||
the type name of the values returned by the distribution;
|
||||
|
|
|
|||
|
|
@ -22,9 +22,8 @@ point. Don't confuse the parentheses in the `tt(greater<string>())' argument
|
|||
with calling tt(operator()). When tt(operator()) is actually used inside
|
||||
tt(sort), it receives two arguments: two strings to compare for
|
||||
`greaterness'. Since tt(greater<string>::operator()) is defined i(inline), the
|
||||
call itself is not actually present in the above tt(sort) call. Rather,
|
||||
tt(sort), however, calls tt(string::operator>) through its call of
|
||||
tt(greater<string>::operator()).
|
||||
call itself is not actually present in the above tt(sort) call. Instead
|
||||
tt(sort) calls tt(string::operator>) through tt(greater<string>::operator()).
|
||||
|
||||
Now that we know that a constructor is passed as argument to (many) generic
|
||||
algorithms, we can design our own function objects. Assume we want to sort our
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
In addition to tt(unique_ptr) the C++0x standard offers a reference counting
|
||||
smart pointer: hi(shared_ptr)tt(std::shared_ptr<Type>).
|
||||
In addition to tt(unique_ptr) the C++0x standard offers
|
||||
hi(shared_ptr)tt(std::shared_ptr<Type>) which is a reference counting smart
|
||||
pointer.
|
||||
|
||||
The shared pointer will automatically destroy its contents once its reference
|
||||
count has decayed to zero.
|
||||
|
|
|
|||
|
|
@ -12,4 +12,4 @@ itself is not the pointer, its value em(can) be compared to tt(0). Example:
|
|||
if (!ip)
|
||||
cout << "0-pointer with a unique_ptr object\n";
|
||||
)
|
||||
Alternatively, the member ti(get) can be used (cf. section ref(UNIQUMEM)).
|
||||
Alternatively, the member ti(get) can be used (cf. section ref(UNIQUEMEM)).
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ were suggestions I received from various other readers of the bf(C++)
|
|||
annotations: all were processed in this release. The bf(C++) content matter of
|
||||
this release was not substantially modified, compared to version 6.2.2.
|
||||
it() Version 6.2.2 offers improved implementations of the configurable
|
||||
class templates (sections ref(WRAPONE) and ref(WRAPTWO)).
|
||||
class templates (removed in 8.1.0, superseded by lambda functions).
|
||||
it() Version 6.2.0 was released as an Annual Update, by the end of May,
|
||||
2005. Apart from the usual typo corrections several new sections
|
||||
were added and some were removed: in the Exception chapter (ref(EXCEPTIONS)) a
|
||||
|
|
|
|||
Loading…
Reference in a new issue