Extensions
----------

Chapter 16 needs to be written.
Appendices A and B need to be written.


Modifications
-------------

- some terms are explained in sections *after* their first use.
These need to be tracked down and reordered.

- S2.1 to 2.3 will benefit from more examples. May need to clarify
the subject matter.

- Chap3 - many of the examples are pretty lame (eg, in S3.1) and
should be replaced by more realistic code.

- S6.3  - talk about "layered design", where higher level
abstractions are built upon lower-level components. Each layer
combines sets of functionalities from modules in the layer below
to form more powerful components. The lowest layers are quite
primitive functionalities (eg, wrap platform specific aspects,
etc). This is a great way to build very powerful and flexible
libraries.
    - emphasise "component-based design", and give pointer to
    Chapter 15 as examples of reusable components. Point also to
    the vector in Section 14.2.

- S9.5 - emphasise that realloc invalidates pointers (emphasise
also in the Vector examples in C11, C14)
    - perhaps put a comment in the source code relevant functions

- Chap11 - add more examples, rather than just struct Point.

- S11.3 - add an example of array notation. Eg,
    for (i = 0; i < nelems; ++i)
        printf("%d %d\n", pa[i].x, pa[i].y);

- S11.6 needs to be thoroughly revised:
  - more complete discussion of OO
  - discuss encapsulation and cohesion (eg, grouping related objects
  and functions, ensuring correct order-of-operations, hiding
  incidental complexity, etc)
  - note that hiding details is not to baffle the programmer, but to
  minimise dependencies in a program -- to decouple. Data hiding
  should *not* make the code more obscure. Should not be called
  'data hiding' but 'data isolation'. Key is isolating or decoupling.
    - Give example: a common objection of OO designs (in say Java or
    C++) is that the algorithm is obscured and hard to follow due to
    too-many layers (eg, large inheriance hierarchy). This is not a
    language fault but a design flaw where hiding replaces decoupling.
  - explain that C offers only a rudimentary form of OO, and
  OO-languages support eg, classes, inheritance, polymorphism, etc.
  - discuss synergy of functions, structures, file-modularity, opaque types, etc.
  - improve "Complex" example.
  - maybe add an arbitrary arithmetic example, which introduces opaque types
  - provide an example of how opaque types promote correct use by
  preventing clients from putting an object into an invalid state.

- S11.8 - for a variant array, can improve safety by wrapping in a function:
    VariantType create_int(int val);

- S12.1 - Most machines store negative values in 2’s-complement ->
Most machines store negative integers in 2’s-complement
  - Add footnote: integers^{There are several common forms for representing
  negative numbers in binary, such as ones-complement, twos-complement and
  sign-magnitude. On most modern machines, integers are represented in
  twos-complement and floating point numbers are sign-magnitude.

- Chap13 - needs small code examples of various file IO operations.
  - S13.2.4 - mention that must call fseek between alternate calls to
  fread and fwrite.

- S14.1.3 - change example union definition to be an "anonymous
union" (ie, has no variable name).

- S14.2 - add a section on advanced macros for creating a
template-like environment.

Ch15 - There is an adage "Data structures code", that is, once you
have what data your program operates on and how it should be
represented, the design of the code that works on it is almost
self-evident.