\} \-\\
\}
\end{prog}
-Save it as @"greeter.sod", and run
+Save it as @|greeter.sod|, and run
\begin{prog}
sod --gc --gh greeter
\end{prog}
-This will create files @"greeter.c" and @"greeter.h" in the current
+This will create files @|greeter.c| and @|greeter.h| in the current
directory. Here's how we might use such a simple thing.
\begin{prog}
\#include "greeter.h" \\+
and I'm sure you'll appreciate the benefits of using Sod already -- mostly to
do with finger exercise. Trust me, it gets more useful.
-The @".sod" file was almost comprehensible. There are two important parts to
+The @|.sod| file was almost comprehensible. There are two important parts to
it (after the comment which tells Emacs how to cope with it).
-The first part consists of the two @"code" stanzas. Both of them define
-gobbets of raw C code to copy into output files. The first one, @"code~:
-c"~\ldots, says that
+The first part consists of the two @|code| stanzas. Both of them define
+gobbets of raw C code to copy into output files. The first one, @|code~:
+c|~\ldots, says that
\begin{prog}
\#include "greeter.h"
\end{prog}
\#include <sod/sod.h>
\end{prog}
needs to appear in the header file @|greeter.h|. The generated C files need
-to get declarations for external types and functions (e.g., @"FILE" and
-@"fputs") from somewhere, and the generated @".c" file will need the
-declarations from the corresponding @".h" file. Sod takes a very simple
+to get declarations for external types and functions (e.g., @|FILE| and
+@|fputs|) from somewhere, and the generated @|.c| file will need the
+declarations from the corresponding @|.h| file. Sod takes a very simple
approach to all of this: it expects you, the programmer, to deal with it.
-The basic syntax for @"code" stanzas is
+The basic syntax for @|code| stanzas is
\begin{prog}
code @<file-label>: @<section> \{ \\ \ind
@<code> \-\\
\}
\end{prog}
-The @<file-label> is either @"c" or @"h", and says which output file the code
+The @<file-label> is either @|c| or @|h|, and says which output file the code
wants to be written to. The @<section> is a name which explains where in the
-output file to place the code. The @"includes" section is the usual choice:
+output file to place the code. The @|includes| section is the usual choice:
it's the `right' place for @`\#include' directives and similar declarations.
The remaining part, the `meat' of the file, defines a class called
-@"greeter". The class can respond to a single message, named @"greet", and
+@|greeter|. The class can respond to a single message, named @|greet|, and
in response, it writes a traditional greeting to the file passed in with the
message.
\begin{prog}
struct Greeter__ilayout g_obj;
\end{prog}
-allocates space for an instance of class @"Greeter". We're not going to use
+allocates space for an instance of class @|Greeter|. We're not going to use
this space directly. Instead, we do this frightening looking thing.
\begin{prog}
Greeter *g = Greeter__class@->cls.init(\&g_obj);
\end{prog}
-Taking it slowly: @"Greeter__class" is a pointer to the object that
-represents our class @"Greeter". This object contains a member, named
-@"cls.init", which points to a function whose job is to turn uninitialized
+Taking it slowly: @|Greeter__class| is a pointer to the object that
+represents our class @|Greeter|. This object contains a member, named
+@|cls.init|, which points to a function whose job is to turn uninitialized
storage space into working instances of the class. It returns a pointer to
the instance, which we use in preference to grovelling about in the
-@"ilayout" structure.
+@|ilayout| structure.
Having done this, we `send the instance a message':
\begin{prog}
g@->_vt@->greeter.greet(g, stdout);
\end{prog}
This looks horrific, and seems to repeat itself quite unnecessarily. The
-first @"g" is the recipient of our `message'. The second is indeed a copy of
+first @|g| is the recipient of our `message'. The second is indeed a copy of
the first: we have to tell it who it is. (Sod doesn't extend C's syntax, so
this is the sort of thing we just have to put up with.) The lowercase
-@"greeter" is our class's `nickname': we didn't choose one explicitly, so Sod
+@|greeter| is our class's `nickname': we didn't choose one explicitly, so Sod
picked one by forcing the classname to lowercase.
%%%----- That's all, folks --------------------------------------------------
~mdw / sod / blobdiff