intro.html

this is a mirrored site c-faq. thought might need offline

is available
on the Internet
via anonymous ftp from aw.com
in directory
cseng/authors/summit/cfaq
(see also <a href="../resources/booksrcs.html">question 18.12</a>).


</p><p>To underscore certain points,
it has unfortunately been necessary
to include a few code fragments
which are examples
of things <em>not</em> to do.
In the answers,
such code fragments are marked
with an explicit comment like <TT>/* WRONG */</TT>
to remind you not to emulate them.
(Code fragments in questions are not usually so marked;
it should be obvious that the code fragments in questions are suspect,
as the question is usually ``Why doesn't this work?'')
</p><H3>Organization</H3>

<p>As was already mentioned,
this book's questions are based on real questions asked by real people,
and real-world questions do not always fall into neat hierarchies.
Many questions touch on several topics:
what seems to be a memory allocation problem
may actually reflect an improper declaration.
(Several questions
which straddle chapter boundaries
appear in both chapters,
to make them easier to find.)
In any case,
this is not a book you have to read through sequentially:
use the table of contents,
the list of questions beginning on page xxx,
the index,
and the cross-references between questions
to find the topics that are of interest to you.

(And, if you have some free time,
you may find yourself
reading through sequentially anyway;
perhaps you'll encounter
the answer
to a question you hadn't thought to ask yet.)
</p><p>Usually,
before you can start writing code
you have to declare your data structures,
so <a href="../decl/index.html">chapter 1</a> starts out
by 
talking about declaration and initialization.
C's structure, union, and enumeration types are complicated enough
that they deserve a chapter of their own;
<a href="../struct/index.html">chapter 2</a> discusses

how they are declared and used.
</p><p>Most of the work of a program is carried out by expression 
statements,
which are the subject of <a href="../expr/index.html">chapter 3</a>.
</p><p>Chapters 4 through
7
discuss the bane of many a beginning C programmer: pointers.
<a href="../ptrs/index.html">Chapter 4</a> covers pointers in general,
<a href="../null/index.html">chapter 5</a>
focuses on
the special case
of null pointers,
<a href="../aryptr/index.html">chapter 6</a>
describes
the relationship between pointers and arrays,
and
<a href="../malloc/index.html">chapter 7</a>
explores
what is often the <em>real</em> problem when pointers are misbehaving:
the underlying memory allocation.
</p><p>
Almost all C programs manipulate characters and strings,
but these types are implemented at a low level by the language.
The programmer is often responsible for managing these types correctly;
some questions which come up while doing so are collected in 
<a href="../charstring/index.html">chapter 8</a>.
Similarly,
C does not have a formal Boolean type;
<a href="../bool/index.html">chapter 9</a>
briefly
discusses C's Boolean expressions
and the appropriate ways of implementing a user-defined Boolean type,
if desired.
</p><p>The C preprocessor
(the part of the compiler responsible for handling 
<TT>#include</TT> and <TT>#define</TT> directives, and in fact all 
lines beginning with <TT>#</TT>)
is distinct enough
that it almost represents a separate language,
and
is covered in its own chapter,
<a href="../cpp/index.html">chapter 10</a>.
</p><p>The ANSI C Standardization committee (X3J11),
in the process of clarifying C's definition
and making it palatable to the world,
introduced a number of new features
and made a few significant changes.
Questions specific to ANSI/ISO Standard C
are collected in <a href="../ansi/index.html">chapter 11</a>.
If you had experience with pre-ANSI C
(also called ``K&amp;R'' or ``Classic'' C),
you will find <a href="../ansi/index.html">chapter 11</a>
to be a useful introduction to the differences.
If you are comfortably using ANSI C,

on the other hand,
the distinction between pre-ANSI and ANSI features may

not be interesting.
In any case,
all of the questions in <a href="../ansi/index.html">chapter 11</a>
which also relate to other topics
(declarations, the C preprocessor, library functions, etc.)
also appear in
or are otherwise cross-referenced from
those other chapters.
</p><p>C's definition is relatively Spartan in part because many 
features are not built in to the language,
but are accessed via

library functions.
The most important of these
are the ``Standard I/O'' or ``stdio'' functions,
which are discussed in <a href="../stdio/index.html">chapter 12</a>.
Other library functions are covered in <a href="../lib/index.html">chapter 13</a>.
</p><p>Chapters <a href="../fp/index.html">14</a> and <a href="../varargs/index.html">15</a>
discuss
two
more
advanced topics:
floating point and variable-length argument lists.
Floating-point computations tend to be tricky no matter what 
system or language you're using;
<a href="../fp/index.html">chapter 14</a> outlines
a few general floating point issues and a few which are specific to C.
The possibility that a function can accept a varying number of arguments,

though perhaps arguably
unnecessary or dangerous,
is occasionally convenient and is central to
C's <TT>printf</TT> function;
techniques for dealing with variable-length argument lists
are discussed in <a href="../varargs/index.html">chapter 15</a>.
</p><p>Hiding in <a href="../strangeprob/index.html">chapter 16</a>
are some questions which you may want to jump to first
if you're already comfortable with most of the preceding material:
they concern
the occasional
strange problems and
mysterious bugs
which
crop up in a program
and
can be
agonizingly
frustrating to track down.

</p><p>When there are two or more equally ``correct'' ways
of writing a program
(and there usually are),
one may be preferable based on subjective criteria having to do 
with more than whether

the code simply compiles and runs correctly.
<a href="../style/index.html">Chapter 17</a> discusses a few of 
these ephemeral issues of programming style.
</p><p>You can't build C programs in isolation:
you need a compiler,
and you may need
some
additional
documentation,
source
code,
or
tools.
<a href="../resources/index.html">Chapter 18</a> discusses
some available
tools and resources,
including <TT>lint</TT>,
a nearly forgotten but
once
indispensable tool
for checking certain 
aspects of program correctness and portability.
</p><p>As mentioned,
the C language does not specify everything you necessarily need
to get a real program working.
Questions such as
``How do I read one character without waiting for the RETURN key?''
and
``How do I find the size of a file?''
are extremely common,
but
C does not define the answers;
these operations depend on the facilities provided by the 
underlying operating system.

<a href="../osdep/index.html">Chapter 19</a>
presents a number of these questions
along with brief
answers for popular operating systems.
</p><p>Finally,
<a href="../misc/index.html">chapter 20</a>
collects the miscellaneous questions that don't fit 
anywhere else:
bit manipulation,
efficiency,
algorithms,
C's relationship to other languages,
and a few
trivia questions.
(The introduction to <a href="../misc/index.html">chapter 20</a>
contains a slightly more detailed breakdown of its disparate 

contents.)
</p><p>To close this introduction,
here are
two preliminary questions,
not so much about C,
but more about this book:
</p><p>
Q:
Why should I buy this book,
if it's available for free on the net?
</p><p>A:
This book contains over
three

times as much material as does 
the version that's posted to comp.lang.c.
and
in spite of the advantages of electronic documentation,
it really can be easier to deal with this amount of information 
in a printed form.
(You'd spend a lot of time downloading this much information 
from the net and printing it,
and the typography wouldn't be as pretty, either.)
</p><p>
Q:
How do you pronounce ``FAQ''?
</p><p>A:
I pronounce it ``eff ay kyoo,''

and this was, I believe,
the original pronunciation when FAQ lists
were first ``invented.''
Many people now pronounce
it ``fack,''
which is nicely evocative of the word ``fact.''
I'd pronounce the plural, as in the title of this book,
``eff ay kyooze'',
but many people pronounce it like ``fax.''
None of these pronunciations are
strictly right or wrong;
``FAQ'' is a new term,
and popular usage plays a certain role
in shaping any term's evolution.
</p><p>(It's equally imponderable, by the way,
whether ``FAQ'' refers to the question alone,
or to the question plus its answer,
or to the whole list of questions and answers.)
</p><p>But now,
on with the real questions!
</p><hr>
<hr>
<p>
</p>
</body>

<!-- Mirrored from c-faq.com/book/intro.html by HTTrack Website Copier/3.x [XR&CO'2008], Sat, 14 Mar 2009 07:59:10 GMT -->
</html>