mirror of
https://gitlab.com/fbb-git/cppannotations
synced 2024-11-16 07:48:44 +01:00
fixed typos
This commit is contained in:
parent
eda2cb0380
commit
adac2cda2e
22 changed files with 36 additions and 31 deletions
|
@ -12,8 +12,8 @@ To create the kindle version:
|
|||
* createhtml kindle
|
||||
* xd 1h
|
||||
|
||||
* edit ./cplusplus.opf to reflect the latest version, maybe add a new
|
||||
chapter.
|
||||
* edit ./cplusplus.opf to update the latest version and date, and
|
||||
maybe add a new chapter.
|
||||
|
||||
* do:
|
||||
../tmp/kindlegen/kindlegen -gif cplusplus.opf |& tee /tmp/out
|
||||
|
@ -23,8 +23,9 @@ To create the kindle version:
|
|||
* Follow the instructions at
|
||||
https://kdp.amazon.com/self-publishing/dashboard
|
||||
|
||||
Select: `Book actions' for uploading the latest version:
|
||||
Select: `Book actions' (lower right) for uploading the latest version:
|
||||
|
||||
- Click on the elipses (...)
|
||||
- Click on C++ Annotations
|
||||
- Edit the version
|
||||
- Click Browse to go to the location where the .mobi file is and
|
||||
|
|
|
@ -2,10 +2,14 @@
|
|||
<package unique-identifier="uid">
|
||||
<metadata>
|
||||
<dc-metadata xmlns:dc="http://purl.org/metadata/dublin_core" xmlns:oebpackage="http://openebook.org/namespaces/oeb-package/1.0/">
|
||||
<dc:Title>C++ Annotations Version 10.6.0</dc:Title>
|
||||
<dc:Title>C++ Annotations Version 10.8.0</dc:Title>
|
||||
<dc:Language>en-us</dc:Language>
|
||||
<dc:Identifier id="uid">EA989A949A</dc:Identifier>
|
||||
<dc:Creator>Frank B. Brokken</dc:Creator><dc:Publisher>The University of Groningen</dc:Publisher><dc:Identifier scheme="ISBN">9036704707</dc:Identifier><dc:Subject BASICCode="COM000000">Computing, Internet</dc:Subject><dc:Date>01/10/2013</dc:Date></dc-metadata>
|
||||
<dc:Creator>Frank B. Brokken</dc:Creator><dc:Publisher>The University
|
||||
of Groningen</dc:Publisher><dc:Identifier
|
||||
scheme="ISBN">9036704707</dc:Identifier><dc:Subject
|
||||
BASICCode="COM000000">Computing, Internet</dc:Subject><dc:Date>June 8, 2017
|
||||
</dc:Date></dc-metadata>
|
||||
<x-metadata>
|
||||
<output encoding="Windows-1252"/>
|
||||
<EmbeddedCover>annotations.gif</EmbeddedCover>
|
||||
|
|
|
@ -62,7 +62,7 @@ functions they are considered constant as they merely exist for passing the
|
|||
information of (class type) objects to those functions. This way, they cannot
|
||||
be modified, nor may their non-const member functions be used. Of course, a
|
||||
tt(const_cast) could be used to cast away the const reference's constness, but
|
||||
that's considered bad practive on behalf of the function receiving the
|
||||
that's considered bad practice on behalf of the function receiving the
|
||||
anonymous objects. Also, any modification to the anonymous object is lost once
|
||||
the function returns as the anonymous object ceases to exist after calling the
|
||||
function. These anonymous objects used to initialize const references should
|
||||
|
|
|
@ -38,7 +38,7 @@ modification. Except for constructors and the destructor (cf. chapter
|
|||
ref(MEMORY)) only const member functions can be used with (plain, references
|
||||
or pointers to) tt(const) objects.
|
||||
|
||||
Const objects are frequently encounterd as tt(const &) parameters of
|
||||
Const objects are frequently encountered as tt(const &) parameters of
|
||||
functions. Inside such functions only the object's const members may be
|
||||
used. Here is an example:
|
||||
verb(
|
||||
|
|
|
@ -69,7 +69,7 @@ tt(++s_nObjects) can be an initial value.
|
|||
Note that the data member initializations are recognized by the compiler,
|
||||
and are applied to its implementation of the default constructor. In fact, all
|
||||
constructors will apply the data member initializations, unless explicitly
|
||||
initialized otherwise. E.g., the move-constructor may now be implented like
|
||||
initialized otherwise. E.g., the move-constructor may now be implemented like
|
||||
this:
|
||||
verb(
|
||||
Container(Container &&tmp)
|
||||
|
|
|
@ -51,7 +51,7 @@ semantic value types are used: int-values, names, and vectors of
|
|||
arguments. Other types could easily be used as well: doubles, complex
|
||||
numbers, sets; you name it.
|
||||
|
||||
Our semantic value must accomodate all of these different types, and must
|
||||
Our semantic value must accommodate all of these different types, and must
|
||||
also allow us to determine the actual type that's stored in a semantic value
|
||||
in cases where we cannot deduct the actual type merely from the syntax (which
|
||||
happens, e.g., for the various semantic value types that may be contained in
|
||||
|
|
|
@ -26,7 +26,7 @@ simply defines an tt(INT) value 0.
|
|||
Here is tt(Semantic)'s interface:
|
||||
verbinclude(-a unrestricted/semantic/semantic.h)
|
||||
|
||||
tt(Semantic) objects are as big as required to accomodate all its
|
||||
tt(Semantic) objects are as big as required to accommodate all its
|
||||
variants. However, as tt(Semantic) is a union, its constructors and destructor
|
||||
cannot predefine or destroy all of its variants. Rather, it must pick the
|
||||
appropriate field based on the tt(pair)'s tt(first) field. For tt(int) values
|
||||
|
|
|
@ -79,7 +79,7 @@ function.
|
|||
|
||||
The definition or declaration (either or not containing tt(const)) should
|
||||
always be read from the variable or function identifier back to the type
|
||||
indentifier:
|
||||
identifier:
|
||||
quote(
|
||||
``Buf is a const pointer to const characters''
|
||||
)
|
||||
|
@ -128,7 +128,7 @@ an (as yet unmatched) closing parenthesis.
|
|||
eit() return to the point where you started reading, and read backwards
|
||||
until you reach the beginning of the declaration or a matching opening
|
||||
parenthesis.
|
||||
eit() If you reached an opening parenthese, continue at step 2 beyond the
|
||||
eit() If you reached an opening parenthesis, continue at step 2 beyond the
|
||||
parenthesis where you previously stopped.
|
||||
)
|
||||
Let's apply this recipe to the following (by itself irrelevant) complex
|
||||
|
|
|
@ -24,7 +24,7 @@ char16_t else mutable requires try
|
|||
it() The ti(export) keyword is no longer actively used by bf(C++), but it
|
||||
is kept as a keyword, reserved for future use.
|
||||
it() Since the i(C++17) standard the keyword ti(register) is no longer
|
||||
used, but it remains a reserved identifer. In other words, definitions
|
||||
used, but it remains a reserved identifier. In other words, definitions
|
||||
like verb(
|
||||
register int index;
|
||||
)
|
||||
|
|
|
@ -56,7 +56,7 @@ inefficient if you have an array of tt(BigStruct) elements:
|
|||
};
|
||||
)
|
||||
Inefficient, because you don't need to make copies of the array's
|
||||
elements. Instead, use refences to elements:
|
||||
elements. Instead, use references to elements:
|
||||
verb(
|
||||
BigStruct data[100]; // assume properly initialized elsewhere
|
||||
|
||||
|
|
|
@ -88,7 +88,7 @@ if the function is passed an anonymous value.
|
|||
replaced by tt(void receive(int value)), though. When confronted with the
|
||||
choice between a value parameter and a reference parameter (either lvalue or
|
||||
rvalue) it cannot make a decision and reports an ambiguity. In practical
|
||||
contexts this is not a problem. Rvalue refences were added to the language in
|
||||
contexts this is not a problem. Rvalue references were added to the language in
|
||||
order to be able to distinguish the two forms of references: named values
|
||||
(for which lvalue references are used) and anonymous values (for which
|
||||
rvalue references are used).
|
||||
|
@ -96,7 +96,7 @@ rvalue references are used).
|
|||
It is this distinction that allows the implementation of
|
||||
emi(move semantics) and emi(perfect forwarding). At this point the concept of
|
||||
emi(move semantics) cannot yet fully be discussed (but see section ref(MOVE)
|
||||
for a more thorough discussusion) but it is very well possible to illustrate
|
||||
for a more thorough discussion) but it is very well possible to illustrate
|
||||
the underlying ideas.
|
||||
|
||||
Consider the situation where a function returns a tt(struct Data) containing a
|
||||
|
|
|
@ -1,14 +1,14 @@
|
|||
This section can safely be skipped without loss of continuity.
|
||||
|
||||
In the context of the class tt(shared_ptr), which is covered in section
|
||||
ref(SHAREDPTR), several more new-style casts are availble. Actual coverage of
|
||||
ref(SHAREDPTR), several more new-style casts are available. Actual coverage of
|
||||
these specialized casts is postponed until section ref(SHAREDCAST).
|
||||
|
||||
These specialized casts are:
|
||||
itemization(
|
||||
itt(static_pointer_cast), returning a tt(shared_ptr) to the base-class
|
||||
section of a derived class object;
|
||||
itt(const_pointer_cast), returing a tt(shared_ptr) to a non-const object
|
||||
itt(const_pointer_cast), returning a tt(shared_ptr) to a non-const object
|
||||
from a tt(shared_ptr) to a constant object;
|
||||
itt(dynamic_pointer_cast), returning a tt(shared_ptr) to a derived class
|
||||
object from a tt(shared_ptr) to a base class object.
|
||||
|
|
|
@ -3,7 +3,7 @@ type that is promoted by bi(POSIX) as a typename to be used for non-negative
|
|||
integral values answering questions like `how much' and `how many', in which
|
||||
case it should be used instead of ti(unsigned int). It is not a specific
|
||||
bf(C++) type, but also available in, e.g., bf(C). Usually it is defined
|
||||
implictly when a (any) system header file is included. The header file
|
||||
implicitly when a (any) system header file is included. The header file
|
||||
`officially' defining tt(size_t) in the context of bf(C++) is ti(cstddef).
|
||||
|
||||
Using tt(size_t) has the advantage of being a em(conceptual) type, rather than
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
The ti(wchar_t) type is an extension of the tt(char) built-in type, to accomodate
|
||||
The ti(wchar_t) type is an extension of the tt(char) built-in type, to accommodate
|
||||
em(wide) character values (but see also the next section). The tt(g++)
|
||||
compiler reports tt(sizeof(wchar_t)) as 4, which easily accomodates all 65,536
|
||||
compiler reports tt(sizeof(wchar_t)) as 4, which easily accommodates all 65,536
|
||||
different em(Unicode) character values.
|
||||
|
||||
Note that bf(Java)'s tt(char) data type is somewhat comparable to bf(C++)'s
|
||||
|
|
|
@ -30,7 +30,7 @@ inviting me;
|
|||
it() Expenses for basic lodging, while the lectures take place, should
|
||||
also be taken care of by the organization inviting me;
|
||||
it() The lectures can be organized yearly between june and (including)
|
||||
september;
|
||||
September;
|
||||
it() In close cooperation with the interested organization the
|
||||
actual topics to be presented and the duration and intensity
|
||||
of the course will be determined;
|
||||
|
|
|
@ -1,9 +1,9 @@
|
|||
The original version of the bf(C++) Annotations was written by Frank Brokken
|
||||
and Karel Kubat in Dutch using tt(LaTeX). After some time, Karel rewrote the
|
||||
text and converted the guide to a more suitable format and (of course) to
|
||||
English in september 1994.
|
||||
English in September 1994.
|
||||
|
||||
The first version of the guide appeared on the net in october 1994. By then it
|
||||
The first version of the guide appeared on the net in October 1994. By then it
|
||||
was converted to tt(SGML).
|
||||
|
||||
Gradually new chapters were added, and the contents were modified and further
|
||||
|
|
|
@ -210,7 +210,7 @@ bf(Handling whitespace and flushing streams)
|
|||
(manipulator inserting a newline character and flushing the
|
||||
stream. Often flushing the stream is not required and doing so would
|
||||
needlessly slow down I/O processing. Consequently, using tt(endl) should be
|
||||
avoided (in favor of inserting tt('\n')) unless flusing the stream is
|
||||
avoided (in favor of inserting tt('\n')) unless flushing the stream is
|
||||
explicitly intended. Note that streams are automatically flushed when the
|
||||
program terminates or when a stream is `tied' to another stream (cf. tt(tie)
|
||||
in section ref(IOS)). Example:
|
||||
|
@ -251,7 +251,7 @@ cin >> value; // skips initial blanks
|
|||
(the stream for which this flag is set flushes its buffer after
|
||||
every output operation Often flushing a stream is not required and doing so
|
||||
would needlessly slow down I/O processing. Consequently, setting tt(unitbuf)
|
||||
should be avoided unless flusing the stream is explicitly intended. Note that
|
||||
should be avoided unless flushing the stream is explicitly intended. Note that
|
||||
streams are automatically flushed when the program terminates or when a stream
|
||||
is `tied' to another stream (cf. tt(tie) in section ref(IOS)). Complementary
|
||||
flag: tt(ios::nounitbuf). Manipulators: tt(std::unitbuf),
|
||||
|
|
|
@ -18,7 +18,7 @@ The chapters of the bf(C++) Annotations cover the following topics:
|
|||
linkit(OVERLOADING)(Give your own meaning to operators)
|
||||
linkit(CONTAINERS)(Abstract Containers to put stuff into)
|
||||
linkit(INHERITANCE)(Building classes upon classes: setting up class
|
||||
hierarcies)
|
||||
hierarchies)
|
||||
linkit(POLYMORPHISM)(Changing the behavior of member functions
|
||||
accessed through base class pointers)
|
||||
linkit(Friends)(Gaining access to private parts: friend functions and
|
||||
|
|
|
@ -39,7 +39,7 @@ determined which member function will actually be called.
|
|||
In bf(C++) late binding is em(not) the default way functions are called. By
|
||||
default emi(static binding) (or emi(early binding)) is used. With static
|
||||
binding the functions that are called are determined by the compiler, merely
|
||||
using the class types of objects, object pointers or object refences.
|
||||
using the class types of objects, object pointers or object references.
|
||||
|
||||
Late binding is an inherently different (and slightly slower) process as it is
|
||||
decided at i(run-time), rather than at i(compile-time) what function is going
|
||||
|
|
|
@ -60,7 +60,7 @@ the member function as a reference parameter.
|
|||
Note that hi(static inline member functions)
|
||||
static member functions can be defined as inline
|
||||
hi(inline: static members) functions.
|
||||
it() at 2 a relatively long array is defined to be able to accomodate
|
||||
it() at 2 a relatively long array is defined to be able to accommodate
|
||||
long paths. Alternatively, a tt(string) or a pointer to dynamic memory could
|
||||
be used.
|
||||
it() at 3 a (possibly longer, but not too long) new pathname is stored in
|
||||
|
|
|
@ -104,7 +104,7 @@ otherwise.
|
|||
argument[object.copy(argument, string::npos)] = 0;
|
||||
)
|
||||
Of course, the programmer should make sure that tt(argument)'s size is
|
||||
large enough to accomodate the additional 0-byte.)
|
||||
large enough to accommodate the additional 0-byte.)
|
||||
ithtq(crbegin)(string::const_reverse_iterator crbegin())
|
||||
(a tt(const_reverse_iterator) referring to the last character of the
|
||||
current string object is returned.)
|
||||
|
|
Loading…
Reference in a new issue