diff options
Diffstat (limited to 'Master/xemtex/doc/ghostscript/C-style.htm')
| -rw-r--r-- | Master/xemtex/doc/ghostscript/C-style.htm | 1588 |
1 files changed, 1588 insertions, 0 deletions
diff --git a/Master/xemtex/doc/ghostscript/C-style.htm b/Master/xemtex/doc/ghostscript/C-style.htm new file mode 100644 index 00000000000..0e17e4d5e0e --- /dev/null +++ b/Master/xemtex/doc/ghostscript/C-style.htm @@ -0,0 +1,1588 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> +<html> +<head> +<title>Ghostscript C coding guidelines</title> +<!-- $Id: C-style.htm,v 1.21.2.11.2.5 2003/05/17 14:38:59 giles Exp $ --> +<!-- Originally: c-style.txt --> +<link rel="stylesheet" type="text/css" href="gs.css" title="Ghostscript Style"> +</head> + +<body> +<!-- [1.0 begin visible header] ============================================ --> + +<!-- [1.1 begin headline] ================================================== --> + +<h1>Ghostscript C coding guidelines</h1> + +<!-- [1.1 end headline] ==================================================== --> + +<!-- [1.2 begin table of contents] ========================================= --> + +<h2>Table of contents</h2> + +<blockquote><ul> +<li><a href="#Introduction">Introduction</a> +<li><a href="#C_language">C language do's and don'ts</a> +<ul> +<li>Preprocessor: + <a href="#Conditionals">Conditionals</a>, + <a href="#Macros">Macros</a>, + <a href="#Preprocessor_other">Other</a> +<li><a href="#Lexical_elements">Lexical elements</a> +<li><a href="#Scoping">Scoping</a> +<li>Data types: + <a href="#Scalars">Scalars</a>, + <a href="#Arrays">Arrays</a>, + <a href="#Typedefs">Typedefs</a>, + <a href="#Structures">Structures</a>, + <a href="#Unions">Unions</a> +<li><a href="#Expressions">Expressions</a> +<li><a href="#Statements">Statements</a> +<li><a href="#Procedures">Procedures</a> (prototypes and definitions) +<li><a href="#Standard_library">Standard library</a> +</ul> +<li><a href="#Language_extensions">Language extensions</a> +<li><a href="#Stylistic_conventions">Stylistic conventions</a> +<ul> +<li>Formatting: + <a href="#Indentation">Indentation</a>, + <a href="#Spaces">Spaces</a>, + <a href="#Parentheses">Parentheses</a> +<li><a href="#Preprocessor_style">Preprocessor</a> +<li><a href="#Naming">Naming</a> +<li><a href="#Types">Types</a> +<li><a href="#Procedures_style">Procedures</a>, +<li>Miscellany: + <a href="#Local_variables">Local variables</a>, + <a href="#Compiler_warnings">Compiler warnings</a> +</ul> +<li><a href="#File_structuring">File structuring and naming</a> +<ul> +<li><a href="#All_files">All files</a> +<li><a href="#Makefiles">Makefiles</a> +<li><a href="#General_C_code">General C Code</a> +<li><a href="#Headers">Headers (<b><tt>.h</tt></b> files)</a> +<li><a href="#Source">Source (<b><tt>.c</tt></b> files)</a> +</ul> +<li><a href="#Conventions">Ghostscript conventions</a> +<ul> +<li><a href="#Specific_names">Specific names</a>: + <a href="#code"><b><tt>code</tt></b></a>, + <a href="#status"><b><tt>status</tt></b></a> +<li><a href="#Structure_type_descriptors">Structure type descriptors</a> +<li><a href="#Objects">"Objects"</a> +<li><a href="#Error_handling">Error handling</a> +</ul> +</ul></blockquote> + +<!-- [1.2 end table of contents] =========================================== --> + +<!-- [1.3 begin hint] ====================================================== --> + +<p> +For other information, see the <a href="Readme.htm">Ghostscript +overview</a>. + +<!-- [1.3 end hint] ======================================================== --> + +<hr> + +<!-- [1.0 end visible header] ============================================== --> + +<!-- [2.0 begin contents] ================================================== --> + +<h2><a name="Introduction"></a>Introduction</h2> + +<p> +This document describes Ghostscript's C coding conventions. It is primarily +<em>prescriptive</em>, documenting what developers should do when writing +new code; the companion developer documentation (<a + href="Develop.htm">Develop.htm</a>) is primarily <em>descriptive</em>, +documenting the way things are. + +<p> +We encourage following the general language usage and stylistic rules for +any code that will be integrated with Ghostscript, even if the code doesn't +use Ghostscript's run-time facilities or have anything to do with +PostScript, PDF, or page description languages. Ghostscript itself follows +some additional conventions; these are documented separately under "<a +href="#Conventions">Ghostscript conventions</a>" below. + +<hr> + +<h2><a name="C_language"></a>C language do's and don'ts</h2> + +<p> +There are several different versions of the C language, and even of the ANSI +C standard. Ghostscript versions through 7.0 were designed to compile on +pre-ANSI compilers as well as on many compilers that implemented the ANSI +standard with varying faithfulness. Ghostscript versions since 7.0 do not +cater for pre-ANSI compilers: they must conform to the ANSI 1989 standard +(ANS X3.159-1989), with certain restrictions and a few conventional +additions. + +<h3>Preprocessor</h3> + +<h4><a name="Conditionals"></a>Conditionals</h4> + +Restrictions: + +<ul> + +<li>Don't assume that <b><tt>#if</tt></b> will treat undefined names as 0. +While the ANSI standard requires this, it may produce a warning. + +<li>In <b><tt>.c</tt></b> files, don't use preprocessor conditionals that +test for individual platforms or compilers. Use them only in header files +named xxx<b><tt>_.h</tt></b>. + +</ul> + +<h4><a name="Macros"></a>Macros</h4> + +<p> +Restrictions: + +<ul> + +<li>Don't redefine a macro, even with the same definition, without using +<b><tt>#undef</tt></b>. + +<li><b><tt>CAPITALIZE</tt></b> macro names unless there is a good reason not +to. + +<li>Don't use a macro call within a macro argument if the call expands to a +token sequence that includes any commas not within parentheses: this +produces different results depending on whether the compiler expands the +inner call before or after the argument is substituted into the macro body. +(The ANSI standard says that calls must be expanded after substitution, but +some compilers do it the other way.) + +<li>Don't use macro names, even inadvertently, in string constants. Some +compilers erroneously try to expand them. + +<li>Don't use macros to define shorthands for casted pointers. For +instance, avoid + +<blockquote><b><tt> +#define fdev ((gx_device_fubar *)dev) +</tt></b></blockquote> + +<p> +and instead use + +<blockquote><b><tt> +gx_device_fubar * const fdev = (gx_device_fubar *)dev; +</tt></b></blockquote> + +<p> +The use of <b><tt>const</tt></b> alerts the reader that this is effectively +a synonym. + +<li>If a macro generates anything larger than a single expression (that is, +one or more statements), surround it with <b><tt>BEGIN</tt></b> and +<b><tt>END</tt></b>. These work around the fact that simple statements and +compound statements in C can't be substituted for each other syntactically. + +</ul> + +<h3><a name="Preprocessor_other"></a>Other</h3> + +<p> +Restrictions: + +<ul> + +<li>Only use <b><tt>#pragma</tt></b> in files that are explicitly identified +as being platform-dependent. Many compilers complain if this is used at +all, and some complain if they don't recognize the specific pragma being +requested (both incorrect according to the ANSI standard). + +</ul> + +<h3><a name="Lexical_elements"></a>Lexical elements</h3> + +<p> +Do not use: + +<ul> + +<li>ANSI trigraphs (??x) +<li>Nested comments (/* /* */ */) (not ANSI compliant, but often accepted) +<li>Multi-character character constants ('abc') +<li>Wide-character character or string constants (L'x', L"x") + +</ul> + +<p> +Restrictions: + +<ul> + +<li>Procedure and static variable names must be 31 characters or less. + +<li>Externally visible procedure and variable names must be unique in the +first 23 characters. + +</ul> + +<h3><a name="Scoping"></a>Scoping (extern, static, ...)</h3> + +<p> +Do not use: + +<ul> + +<li><b><tt>register</tt></b> + +</ul> + +<p> +Restrictions: + +<ul> + +<li>Do not allow a global variable (constant) to have more than one +non-<b><tt>extern</tt></b> definition, even though some ANSI C compilers +allow this. Every global constant should have exactly one definition, in a +<b><tt>.c</tt></b> file, and preferably just one <b><tt>extern</tt></b> +declaration, in a header file. + +<li>Use <b><tt>private</tt></b> instead of <b><tt>static</tt></b> for +procedures and variables declared at the outermost scope of a file. This +allows making such constructs either visible or invisible to profilers by +changing a single <b><tt>#define</tt></b>. + +<li><b><tt>static</tt></b> or <b><tt>private</tt></b> variables must be +<b><tt>const</tt></b> and initialized: non-<b><tt>const</tt></b> statically +allocated variables are incompatible with reentrancy, and we're in the +process of eliminating all of them. + +<li>Do not use <b><tt>extern</tt></b> in <b><tt>.c</tt></b> files, only in +<b><tt>.h</tt></b> files, unless you have a very good reason for it (e.g., +as in <a href="../src/iconf.c">iconf.c</a>). There are too many such +<b><tt>extern</tt></b>s in the code now: we are eliminating them over time. + +<li>Do not declare the same name as both <b><tt>static</tt></b> +(<b><tt>private</tt></b>) and non-<b><tt>static</tt></b> within the same +compilation. (Some compilers complain, some do not.) This is especially a +problem for procedures: it is easy to declare a procedure as +<b><tt>private</tt></b> near the beginning of a file and accidentally not +declare it <b><tt>private</tt></b> where it is defined later in the file. + +<li>Even though the ANSI standard allows initialized external declarations +(<b><tt>extern int x = 0</tt></b>), don't use them. + +</ul> + +<h3><a name="Scalars"></a>Scalars</h3> + +<p> +Restrictions: + +<ul> + +<li>Avoid using <b><tt>char</tt></b>, except for <b><tt>char *</tt></b> +for a pointer to a string. Don't assume that <b><tt>char</tt></b> is +signed; also don't assume it is unsigned. + +<li>Never cast a <b><tt>float</tt></b> to a <b><tt>double</tt></b> +explicitly. ANSI compilers in their default mode do all floating point +computations in double precision, and handle such casts automatically. + +<li>Don't use <b><tt>long long</tt></b>: even though it is in the ANSI +standard, not all compilers support it. Use <b><tt>bits64</tt></b> instead +(see below under "<a href="#Language_extensions">Language extensions</a>"). + +<li>Don't assume anything about whether <b><tt>sizeof(long)</tt></b> is less +than, equal to, or greater than <b><tt>sizeof(ptr)</tt></b>. (However, you +can make such comparisons in preprocessor conditionals using +<b><tt>ARCH_SIZEOF_LONG</tt></b> and <b><tt>ARCH_SIZEOF_PTR</tt></b>.) + +</ul> + +<h3><a name="Arrays"></a>Arrays</h3> + +<p> +Restrictions: + +<ul> + +<li>Don't declare arrays of size 0. (The newer ANSI standard allows this, +but the older one doesn't.) + +<li>Don't declare an array of size 1 at the end of a structure to indicate +that a variable-size array follows. + +<li>Don't declare initialized <b><tt>auto</tt></b> arrays. + +</ul> + +<h3><a name="Typedefs"></a>Typedefs</h3> + +<p> +Restrictions: + +<ul> + +<li>Don't use <b><tt>typedef</tt></b> for function types, such as + +<blockquote> +<b><tt>typedef int proc_xyz_t(double, int *);</tt></b> +</blockquote> + +<p>Many compilers don't handle this correctly -- they will give errors, or +do the wrong thing, when declaring variables of type +<b><tt>proc_xyz_t</tt></b> and/or <b><tt>proc_xyz_t *</tt></b>. Instead, do +this: + +<blockquote> +<b><tt>#define PROC_XYZ(proc) int proc(double, int *)<br> +PROC_XYZ(some_proc); /* declare a procedure of this type */<br> +typedef PROC_XYZ((*proc_xyz_ptr_t)); /* define a type for procedure ptrs */<br> +<br> +proc_xyz_ptr_t pp; /* pointer to procedure */</tt></b> +</blockquote> + +<li>Don't redefine <b><tt>typedef</tt></b>'ed names, even with the same +definition. Some compilers complain about this, and the standard doesn't +allow it. + +</ul> + +<h3><a name="Structures"></a>Structures</h3> + +<p> +Restrictions: + +<li>Don't use anonymous structures if you can possibly avoid it, except +occasionally as components of other structures. Ideally, use the +<b><tt>struct</tt></b> keyword only for declaring named structure types, +like this: + +<blockquote> +<b><tt>typedef struct xxx_s {</tt></b><br> + ... members ...<br> +<b><tt>} xxx_t;</tt></b> +</blockquote> + +<li>Use <b><tt>struct</tt></b> only when declaring structure types, never +for referring to them (e.g., never declare a variable as type +<b><tt>struct xxx_s *</tt></b>). + +<li>Don't assume that the compiler will (or won't) insert padding in +structures to align members for best performance. To preserve alignment, +only declare structure members that are narrower than an <b><tt>int</tt></b> +if there will be a lot of instances of that structure in memory. For such +structures, insert <b><tt>byte</tt></b> and/or <b><tt>short</tt></b> padding +members as necessary to re-establish <b><tt>int</tt></b> alignment. + +<li>Don't declare initialized <b><tt>auto</tt></b> structures. + +</ul> + +<h3><a name="Unions"></a>Unions</h3> + +<p> +Restrictions: + +<ul> + +<li>Use unions only as components of structures, not as typedefs in their +own right. + +<li>Don't attempt to initialize unions: not all compilers support this, even +though it is in the 1989 ANSI standard. + +</ul> + +<h3><a name="Expressions"></a>Expressions</h3> + +<p> +Restrictions: + +<ul> + +<li>Don't assign a larger integer data type to a smaller one without a cast +(<b><tt>int_x = long_y</tt></b>). + +<li>It's OK to use the address of a structure or array element +(<b><tt>&p->e</tt></b>, <b><tt>&a[i]</tt></b>) locally, or pass it to a +procedure that won't store it, but don't store such an address in allocated +storage unless you're very sure of what you're doing. + +<li>Don't use conditional expressions with structure or union values. +(Pointers to structures or unions are OK.) + +<li>For calling a variable or parameter procedure, use +<b><tt>ptr->func(...)</tt></b>. Some old code uses explicit indirection, +<b><tt>(*ptr->func)(...)</tt></b>: don't use this in new code. + +<li>Don't write expressions that depend on order of evaluation, unless the +order is created explicitly by use of <b><tt>||</tt></b>, +<b><tt>&&</tt></b>, <b><tt>?:</tt></b>, <b><tt>,</tt></b>, or +function nesting (the arguments of a function must be evaluated before the +function is called). In particular, don't assume that the arguments of a +function will be evaluated left-to-right, or that the left side of an +assignment will be evaluated before the right. + +<li>Don't mix integer and enumerated types ad lib: treat enumerated types as +distinct from integer types, and use casts to convert between the two. +(Some compilers generate warnings if you do not do this.) + +</ul> + +<h3><a name="Statements"></a>Statements</h3> + +<p> +Restrictions: + +<ul> + +<li>If you use an expression as a statement, other than an assignment or a +function call with <b><tt>void</tt></b> return value, enclose it explicitly +in <b><tt>DISCARD()</tt></b>. + +<li>The type of the operand of a <b><tt>switch</tt></b> must match the type +of the case labels, whether the labels are <b><tt>int</tt></b>s or the +members of an <b><tt>enum</tt></b> type. (Use a cast if necessary.) + +<li>It is OK for one case of a switch to "fall through" into another (i.e., +for the statement just before a case label not to be a control transfer), +but a comment <b><tt>/* falls through */</tt></b> is +required. + +<li>If you are returning an error code specified explicitly (e.g., +<b><tt>return gs_error_rangecheck</tt></b> or +<b><tt>return e_rangecheck</tt></b>), use +<b><tt>return_error()</tt></b> rather than plain <b><tt>return</tt></b>. +However, if the program is simply propagating an error code generated +elsewhere, as opposed to generating the error, use <b><tt>return</tt></b> +(e.g., <b><tt>if (code < 0) return code</tt></b>). + +</ul> + +<h3><a name="Procedures"></a>Procedures</h3> + +<p> +Restrictions: + +<ul> + +<li>Provide a prototype for every procedure, and make sure the prototype is +available at every call site. If the procedure is local to a file +(<b><tt>private</tt></b>), the prototype should precede the procedure, in +the same file; if the procedure is global, the prototype should be in a +header file. + +<li>If a procedure parameter is itself a procedure, do list its parameter +types rather than just using <b><tt>()</tt></b>. For example, + +<blockquote><b><tt> +int foo(int (*callback)(int, int)); +</tt></b></blockquote> + +<p> +rather than just + +<blockquote><b><tt> +int foo(int (*callback)()); +</tt></b></blockquote> + +<li>Don't use the <b><tt>P</tt></b>* macros in new code. (See the +Procedures section of <a href="#Language_extensions">Language extensions</a> +below for more information.) + +<li>Always provide an explicit return type for procedures, in both the +prototype and the definition: don't rely on the implicit declaration as +<b><tt>int</tt></b>. + +<li>Don't use <b><tt>float</tt></b> as the return type of a procedure, +unless there's a special reason. Floating point hardware typically does +everything in double precision internally and has to do extra work to +convert between double and single precision. + +<li>Don't declare parameters as being of type <b><tt>float</tt></b>, +<b><tt>short</tt></b>, or <b><tt>char</tt></b>. If you do this and forget +to include the prototype at a call site, ANSI compilers will generate +incompatible calling sequences. Use <b><tt>floatp</tt></b> (a synonym for +<b><tt>double</tt></b>, mnemonic for "float parameter") instead of +<b><tt>float</tt></b>, and use <b><tt>int</tt></b> or <b><tt>uint</tt></b> +instead of <b><tt>short</tt></b> or <b><tt>char</tt></b>. + +</ul> + +<h3><a name="Standard_library"></a>Standard library</h3> + +<p> +Restrictions: + +<ul> + +<li>Only use library features that are documented in the established ANSI +standard (e.g., Harbison & Steele's book). Do not use procedures that are +"standards" promulgated by Microsoft (e.g., <b><tt>stricmp</tt></b>), or +originate in BSD Unix (e.g., <b><tt>strcasecmp</tt></b>), or were added in +later versions of the standard such as C 9X. + +<li>Do not use any features from <b><tt>stdio.h</tt></b> that assume the +existence of <b><tt>stdin</tt></b>, <b><tt>stdout</tt></b>, or +<b><tt>stderr</tt></b>. See <a href="../src/gsio.h">gsio.h</a> for the full +list. Instead, use <b><tt>gs_stdin</tt></b> et al. + +</ul> + +<hr> + +<h2><a name="Language_extensions"></a>Language extensions</h2> + +<h3>Scoping</h3> + +<dl> + +<dt><b><tt>inline</tt></b> + +<dd><b><tt>inline</tt></b> is available even if the compiler does not +support it. Be aware, however, that it may have no effect. In particular, +do not use <b><tt>inline</tt></b> in header files. Instead, use the +<b><tt>extern_inline</tt></b> facility described just below. + +<dt><b><tt>extern_inline</tt></b> + +<dd>Compilers that do support <b><tt>inline</tt></b> vary in how they decide +whether to (also) compile a closed-code copy of the procedure. Because of +this, putting an <b><tt>inline</tt></b> procedure in a header file may +produce multiple closed copies, causing duplicate name errors at link time. +<b><tt>extern_inline</tt></b> provides a safe way to put +<b><tt>inline</tt></b> procedures in header files, regardless of compiler. +Unfortunately, the only way we've found to make this fully portable involves +a fair amount of boilerplate. For details, please see <a +href="../src/stdpre.h">stdpre.h</a>. + +<dt><b><tt>private</tt></b> + +<dd><b>Use <tt>private</tt></b> instead of <b><tt>static</tt></b> for all +file-local procedures, and also for file-local variables defined at the +outermost level. However, use <b><tt>static</tt></b>, not +<b><tt>private</tt></b>, for variables defined within a procedure. + +<p> +<b><tt>private</tt></b> is normally #define'd as <b><tt>static</tt></b>. +However, it can also be #define'd as empty, which allows profilers to +measure all procedures, and 'nm' to list all interesting statically +allocated variables, not just public ones. + +</dl> + +<h3>Scalar types</h3> + +<dl> + +<dt><b><tt>bool, true, false</tt></b> + +<dd><b><tt>bool</tt></b> is intended as a Boolean type, with canonical +values <b><tt>true</tt></b> and <b><tt>false</tt></b>. In a more reasonable +language, such as Java, <b><tt>bool</tt></b> is an enumerated type requiring +an explicit cast to or from <b><tt>int</tt></b>; however, because C's +conditionals are defined as producing <b><tt>int</tt></b> values, we can't +even define <b><tt>bool</tt></b> as a C <b><tt>enum</tt></b> without +provoking compiler warnings. + +<p> +Even though <b><tt>bool</tt></b> is a synonym for <b><tt>int</tt></b>, treat +them as conceptually different types: + +<ul> +<li>Initialize or set <b><tt>bool</tt></b> variables to <b><tt>true</tt></b> +or <b><tt>false</tt></b>, not 0 or 1. +<li>Use the Boolean operators <b><tt>!</tt></b>, <b><tt>&&</tt></b>, +and <b><tt>||</tt></b> only with Booleans. Don't use the idiom +<b><tt>!!x</tt></b> to create a Boolean that is true iff <b><tt>x</tt></b> +!= 0: use <b><tt>x != 0</tt></b>. +<li>Use an explicit <b><tt>(int)</tt></b> cast to convert a Boolean to an +integer. +</ul> + +<dt><b><tt>byte, ushort, uint, ulong</tt></b> + +<dd>These types are simply shorthands for <b><tt>unsigned char, short, int, +long</tt></b>. + +<dt><b><tt>floatp</tt></b> + +<dd>This is a synonym for <b><tt>double</tt></b>. It should be used for, +and only for, procedure parameters that would otherwise be +<b><tt>float</tt></b>. (As noted above, procedure parameters should not be +declared as <b><tt>float</tt></b>.) + +<dt><b><tt>bits8, bits16, bits32</tt></b> + +<dd>These are unsigned integer types of the given width. Use them wherever +the actual width matters: do <em>not</em>, for example, use +<b><tt>short</tt></b> assuming that it is 16 bits wide. + +<dt><b><tt>bits64</tt></b> + +<dd><strong>****** NOT IMPLEMENTED YET ******</strong> +This is an unsigned 64-bit integer type, but it may not be available on all +platforms. Any code that uses this type should be surrounded by +<b><tt>#if ARCH_HAS_BITS64</tt></b>. + +</dl> + +<h3>Procedures</h3> + +<dl> + +<dt><b><tt>P0(), P1(p1), ..., P16(p1, ..., p16)</tt></b> [deprecated] + +<dd>Nearly all existing code uses these macros for the parameter lists of +procedure prototypes, e.g., +<b><tt>int proc(P2(int a, int b))</tt></b>, to provide +compatibility with pre-ANSI, a.k.a. "traditional" or "K & R", compilers. +Since only ANSI compilers are now supported, don't use these macros in new +code: use the ANSI standard syntax +<b><tt>int proc(int a, int b)</tt></b>. + +</dl> + +<hr> + +<h2><a name="Stylistic_conventions"></a>Stylistic conventions</h2> + +<p> +Ghostscript's coding rules cover not only the use of the language, but also +many stylistic issues like the choice of names and the use of whitespace. +The stylistic rules are meant to produce code that is easy to read. It's +important to observe them as much as possible in order to maintain a +consistent style, but if you find these rules getting in your way or +producing ugly-looking results once in a while, it's OK to break it. + +<h3><a name="Formatting"></a>Formatting</h3> + +<h4><a name="Indentation"></a>Indentation</h4> + +<p> +We've formatted all of our code using the GNU <b><tt>indent</tt></b> program. + +<blockquote><b><tt> +indent -bad -nbap -nsob -br -ce -cli4 -npcs -ncs \<br> + -i4 -di0 -psl -lp -lps somefile.c +</tt></b></blockquote> + +<p> +does a 98% accurate job of producing our preferred style. Unfortunately, +there are bugs in all versions of GNU <b><tt>indent</tt></b>, requiring +both pre- and post-processing of the code. The <b><tt>gsindent</tt></b> +script in the Ghostscript fileset contains the necessary workarounds. + +<p> +Put indentation points every 4 spaces, with 8 spaces = 1 tab stop. + +<p> +For assignments (including chain assignments), put the entire statement on +one line if it will fit; if not, break it after a <b><tt>=</tt></b> and +indent all the following lines. I.e., format like this: + +<blockquote> +var1 <b><tt>=</tt></b> value<b><tt>;</tt></b><br> +var1 <b><tt>=</tt></b> var2 <b><tt>=</tt></b> value<b><tt>;</tt></b><br> +var1 <b><tt>=</tt></b><br> + value<b><tt>;</tt></b><br> +var1 <b><tt>=</tt></b><br> + var2 <b><tt>=</tt></b> value<b><tt>;</tt></b><br> +var1 <b><tt>=</tt></b> var2 <b><tt>=</tt></b><br> + value<b><tt>;</tt></b> +</blockquote> + +<p> +But not like this: + +<blockquote> +var1 <b><tt>=</tt></b><br> +var2 <b><tt>=</tt></b> value<b><tt>;</tt></b> +</blockquote> + +<p> +Indent in-line blocks thus: + +<blockquote> +<b><tt>{</tt></b><br> + ... declarations ...<br> + {{ blank line if any declarations above }}<br> + ... statements ...<br> +<b><tt>}</tt></b> +</blockquote> + +<p> +Similarly, indent procedures thus: + +<blockquote> +return_type<br> +proc_name(... arguments ...)<br> +<b><tt>{</tt></b><br> + ... declarations ...<br> + {{ blank line if any declarations above }}<br> + ... statements ...<br> +<b><tt>}</tt></b> +</blockquote> + +<p> +If a control construct (<b><tt>if</tt></b>, <b><tt>do</tt></b>, +<b><tt>while</tt></b>, or <b><tt>for</tt></b>) has a one-line body, use +this: + +<blockquote> +... control construct ...<br> + ... subordinate simple statement ... +</blockquote> + +<p> +If it has a multi-line body, use this: + +<blockquote> +... control construct ... <b><tt>{</tt></b><br> + ... subordinate code ...<br> +<b><tt>}</tt></b> +</blockquote> + +<p> +If the subordinate code has declarations, see blocks above. + +<p> +For if-else statements, do this: + +<blockquote> +<b><tt>if (</tt></b> ...<b><tt> ) {</tt></b><br> + ... subordinate code ...<br> +<b><tt>} else if (</tt></b> ...<b><tt> ) {</tt></b><br> + ... subordinate code ...<br> +<b><tt>} else {</tt></b><br> + ... subordinate code ...<br> +<b><tt>}</tt></b> +</blockquote> + +<p> +When there are more than two alternatives, as in the example above, use the +above ("parallel") syntax rather than the following ("nested") syntax: + +<blockquote> +<b><tt>if (</tt></b> ...<b><tt> ) {</tt></b><br> + ... subordinate code ...<br> +<b><tt>} else {</tt></b><br> +<b><tt> if (</tt></b> ...<b><tt> ) {</tt></b><br> + ... subordinate code ...<br> +<b><tt> } else {</tt></b><br> + ... subordinate code ...<br> +<b><tt> }</tt></b><br> +<b><tt>}</tt></b> +</blockquote> + +<p> +Similarly, for do-while statements, do this: + +<blockquote> +<b><tt>do {</tt></b><br> + ... body ...<br> +<b><tt>} while (</tt></b> ... condition ... <b><tt>);</tt></b> +</blockquote> + +<h4><a name="Spaces"></a>Spaces</h4> + +<p> +Do put a space: +<ul> +<li>after every comma and semicolon, unless it ends a line; +<li>around every binary operator other than "<b><tt>-></tt></b>" and +"<b><tt>.</tt></b>", although you can omit the spaces around the innermost +operator in a nested expression if you like; +<li>on both sides of the parentheses of an <b><tt>if</tt></b>, <b><tt>for</tt></b>, or <b><tt>while</tt></b>. +</ul> + +<p> +Don't put a space: +<ul> +<li>at the end of a line; +<li>before a comma or semicolon; +<li>after unary prefix operators; +<li>before the parenthesis of a macro or procedure call. +</ul> + +<h4><a name="Parentheses"></a>Parentheses</h4> + +<p> +Parentheses are important in only a few places: + +<ul> +<li>Around the inner subexpressions in expressions that mix +<b><tt>&&</tt></b> and <b><tt>||</tt></b>, even if they are not +required by precedence, for example + +<blockquote><b><tt> +(xx && yy) || zz +</tt></b></blockquote> + +<li>Similarly around inner subexpressions in expressions that mix +<b><tt>&</tt></b>, <b><tt>|</tt></b>, or shifts, especially if mixing +these with other operators, for instance + +<blockquote><b><tt> +(x << 3) | (y >> 5) +</tt></b></blockquote> + +<li>In macro definitions around every use of an argument that logically +could be an expression, for example + +<blockquote><b><tt> +((x) * (x) + (y) * (y)) +</tt></b></blockquote> + +</ul> + +<p> +Anywhere else, given the choice, use fewer parentheses. + +<p> +For stylistic consistency with the existing Ghostscript code, put +parentheses around conditional expressions even if they aren't +syntactically required, unless you really dislike doing this. Note that +the parentheses should go around the entire expression, not the condition. +For instance, instead of + +<blockquote><b><tt> +hpgl_add_point_to_path(pgls, arccoord_x, arccoord_y,<br> + (pgls->g.pen_down) ? gs_lineto : gs_moveto); +</tt></b></blockquote> + +<p> +use + +<blockquote><b><tt> +hpgl_add_point_to_path(pgls, arccoord_x, arccoord_y,<br> + (pgls->g.pen_down ? gs_lineto : gs_moveto)); +</tt></b></blockquote> + +<h3><a name="Preprocessor_style"></a>Preprocessor</h3> + +<h4>Conditionals</h4> + +<p> +Using preprocessor conditionals can easily lead to unreadable code, since +the eye really wants to read linearly rather than having to parse the +conditionals just to figure out what code is relevant. It's OK to use +conditionals that have small scope and that don't change the structure or +logic of the program (typically, they select between different sets of +values depending on some configuration parameter), but where possible, break +up source modules rather than use conditionals that affect the structure or +logic. + +<h4>Macros</h4> + +<p> +Ghostscript code uses macros heavily to effectively extend the rather +weak abstraction capabilities of the C language, specifically in the area of +memory management and garbage collection: in order to read Ghostscript code +effectively, you simply have to learn some of these macros as though they +were part of the language. The current code also uses macros heavily for +other purposes, but we are trying to phase these out as rapidly as possible, +because they make the code harder to read and debug, and to use the +rules that follow consistently in new code. + +<p> +Define macros in the smallest scope you can manage (procedure, file, or +<b><tt>.h</tt></b> file), and <b><tt>#undef</tt></b> them at the end of +that scope: that way, someone reading the code can see the definitions +easily when reading the uses. If that isn't appropriate, define them in as +large a scope as possible, so that they effectively become part of the +language. This places an additional burden on the reader, but it can be +amortized over reading larger amounts of code. + +<p> +Try hard to use procedures instead of macros. Use "<b><tt>inline</tt></b>" +if you really think the extra speed is needed, but only within a +<b><tt>.c</tt></b> file: don't put inline procedures in <b><tt>.h</tt></b> +files, because most compilers don't honor "<b><tt>inline</tt></b>" and +you'll wind up with a copy of the procedure in every <b><tt>.c</tt></b> +file that includes the <b><tt>.h</tt></b> file. + +<p> +If you define a macro that looks like a procedure, make sure it will work +wherever a procedure will work. In particular, put parentheses around every +use of an argument within the macro body, so that the macro will parse +correctly if some of the arguments are expressions, and put parentheses +around the entire macro body. (This is still subject to the problem that an +argument may be evaluated more than once, but there is no way around this in +C, since C doesn't provide for local variables within expressions.) + +<p> +If you define macros for special loop control structures, make their uses +look somewhat like ordinary loops, for instance: + +<blockquote> +<b><tt>BEGIN_RECT(xx, yy) {</tt></b><br> + ... body indented one position ...<br> +<b><tt>} END_RECT(xx, yy);</tt></b> +</blockquote> + +<p> +If at all possible, don't use free variables in macros -- that is, variables +that aren't apparent as arguments of the macro. If you must use free +variables, list them all in a comment at the point where the macro is +defined. + +<h3><a name="Comments"></a>Comments</h3> + +<p> +The most important descriptive comments are ones in header files that +describe structures, including invariants; but every procedure or structure +declaration, or group of other declarations, should have a comment. Don't +spend a lot of time commenting executable code unless something unusual or +subtle is going on. + +<h3><a name="Naming"></a>Naming</h3> + +<p> +Use fully spelled-out English words in names, rather than contractions. +This is most important for procedure and macro names, global variables and +constants, values of <b><tt>#define</tt></b> and <b><tt>enum</tt></b>, +<b><tt>struct</tt></b> and other <b><tt>typedef</tt></b> names, and +structure member names, and for argument and variable names which have +uninformative types like <b><tt>int</tt></b>. It's not very important for +arguments or local variables of distinctive types, or for local index or +count variables. + +<p> +Avoid names that run English words together: +"<b><tt>hpgl_compute_arc_center</tt></b>" is better than +"<b><tt>hpgl_compute_arccenter</tt></b>". However, for terms drawn from +some predefined source, like the names of PostScript operators, use a term +in its well-known form (for instance, <b><tt>gs_setlinewidth</tt></b> +rather than <b><tt>gs_set_line_width</tt></b>). + +<p> +Procedures, variables, and structures visible outside a single +<b><tt>.c</tt></b> file should generally have prefixes that indicate what +subsystem they belong to (in the case of Ghostscript, <b><tt>gs_</tt></b> +or <b><tt>gx_</tt></b>). This rule isn't followed very consistently. + +<h3><a name="Types"></a>Types</h3> + +<p> +Many older structure names don't have <b><tt>_t</tt></b> on the end, but +this suffix should be used in all new code. (The <b><tt>_s</tt></b> +structure name is needed only to satisfy some debuggers. No code other than +the structure declaration should refer to it.) + +<p> +Declare structure types that contain pointers to other instances of +themselves like this: + +<blockquote> +<b><tt>typedef struct xxx_s xxx_t;</tt></b><br> +<b><tt>struct xxx_s {</tt></b><br> + ... members ...<br> + <b><tt>xxx_t *</tt></b>ptr_member_name;<br> + ... members ...<br> +<b><tt>};</tt></b> +</blockquote> + +<p> +If, to maintain data abstraction and avoid including otherwise unnecessary +header files, you find that you want the type <b><tt>xxx_t</tt></b> to be +available in a header file that doesn't include the definition of the +structure <b><tt>xxx_s</tt></b>, use this approach: + +<blockquote> +<b><tt>#ifndef xxx_DEFINED</tt></b><br> +<b><tt># define xxx_DEFINED</tt></b><br> +<b><tt>typedef struct xxx_s xxx_t;</tt></b><br> +<b><tt>#endif</tt></b><br> +<b><tt>struct xxx_s {</tt></b><br> + ... members ...<br> +<b><tt>};</tt></b> +</blockquote> + +<p> +You can then copy the first 4 lines in other header files. (Don't ever +include them in an executable code file.) + +<p> +Don't bother using <b><tt>const</tt></b> for anything other than with +pointers as described below. However, in those places where it is necessary +to cast a pointer of type <b><tt>const T *</tt></b> to type +<b><tt>T *</tt></b>, always include a comment that explains why you are +"breaking const". + +<h4>Pointers</h4> + +<p> +Use <b><tt>const</tt></b> for pointer referents (that is, +<b><tt>const T *</tt></b>) wherever possible and appropriate. + +<p> +If you find yourself wanting to use <b><tt>void *</tt></b>, try to +find an alternative using unions or (in the case of super- and subclasses) +casts, unless you're writing something like a memory manager that really +treats memory as opaque. + +<h3><a name="Procedures_style"></a>Procedures</h3> + +<p> +In general, don't create procedures that are private and only called from +one place. However, if a compound statement (especially an arm of a +conditional) is too long for the eye easily to match its enclosing braces +"<b><tt>{...}</tt></b>" -- that is, longer than 10 or 15 lines -- and it +doesn't use or set a lot of state held in outer local variables, it may be +more readable if you put it in a procedure. + +<h3>Miscellany</h3> + +<h4><a name="Local_variables"></a>Local variables</h4> + +<p> +Don't assign new values to procedure parameters. It makes debugging very +confusing when the parameter values printed for a procedure are not the +ones actually supplied by the caller. Instead use a separate local +variable initialized to the value of the parameter. + +<p> +If a local variable is only assigned a value once, assign it that value at +its declaration, if possible. For example, + +<blockquote> +<b><tt>int x = </tt></b>some expression <b><tt>;</tt></b> +</blockquote> + +<p> +rather than + +<blockquote> +<b><tt>int x;</tt></b><br> +...<br> +<b><tt>x = </tt></b> some expression <b><tt>;</tt></b> +</blockquote> + +<p> +Use a local pointer variable like this to "narrow" pointer types: + +<blockquote> +<b><tt>int</tt></b><br> +someproc(... <b><tt>gx_device *dev</tt></b> ...)<br> +<b><tt>{<br> + gx_device_printer *const pdev = (gx_device_printer *)dev;</tt></b><br> + ...<br> +<b><tt>}</tt></b> +</blockquote> + +<h4><a name="Compiler_warnings"></a>Compiler warnings</h4> + +<p> +The following section refers to the warnings produced by <b><tt>gcc</tt></b>: +your compiler may produce different ones. + +<p> +It's OK if compilation produces the following warnings: + +<ul> +<li><b><tt><name> might be used uninitialized in this function</tt></b> +<li><b><tt>cast discards `const' from pointer target type</tt></b> +</ul> + +<p> +The first of these often occurs because the compiler isn't aware of control +flow restrictions that guarantee the variable will be initialized before +use: if it occurs in new code, check the code carefully, but don't worry +about the message. The second is often unavoidable in code that initializes +or frees a structure that is otherwise <b><tt>const</tt></b> during its +lifetime. +<p> + +Do work hard to eliminate all warnings other than these, +since they often indicate the possible presence of coding errors. +In particular, get rid of warnings about parameter passing or +initialization that discards <b><tt>const</tt></b>, +by using explicit casts. + +<hr> + +<h2><a name="File_structuring"></a>File structuring</h2> + +<h3><a name="All_files"></a>All files</h3> + +<p> +Keep file names within the "8.3" format for portability: +<ul> +<li>Use only letters, digits, dash, and underscore in file names. +<li>Don't assume upper and lower case letters are distinct. +<li>Put no more than 8 characters before the ".", if any. +<li>If there is a ".", put between 1 and 3 characters after the ".". +</ul> + +<p> +For files other than documentation files, use only lower case letters +in the names; for HTML documentation files, capitalize the first letter. + +<p> +Every code file should start with comments containing + +<ol> +<li>a copyright notice, +<li>the name of the file in the form of an RCS Id: + +<blockquote><b><tt> +/*Id$: filename.ext $*/ +</tt></b></blockquote> + +<p> +(using the comment convention appropriate to the language of the file), and + +<li>a summary, no more than one line, of what the file contains. +</ol> + +<p> +If you create a file by copying the beginning of another file, be sure to +update the copyright year and change the file name. + +<h3><a name="Makefiles"></a>Makefiles</h3> + +<p> +Use the extension <b><tt>.mak</tt></b> for makefiles. + +<p> +For each + +<blockquote><b><tt> +#include "xxx.h" +</tt></b></blockquote> + +<p> +make sure there is a dependency on <b><tt>$(xxx_h)</tt></b> in the +makefile. If xxx ends with a "<b><tt>_</tt></b>", this rule still holds, +so that if you code + +<blockquote><b><tt> +#include "math_.h" +</tt></b></blockquote> + +<p> +the makefile must contain a dependency on "<b><tt>$(math__h)</tt></b>" +(note the two underscores "<b><tt>__</tt></b>"). + +<p> +List the dependencies bottom-to-top, like the <b><tt>#include</tt></b> +statements themselves; within each level, list them alphabetically. Do +this also with <b><tt>#include</tt></b> statements themselves whenever +possible (but sometimes there are inter-header dependencies that require +bending this rule). + +<p> +For compatibility with the build utilities on OpenVMS, always put a space +before the colon that separates the target(s) of a rule from the dependents. + +<h3><a name="General_C_code"></a>General C code</h3> + +<p> +List <b><tt>#include</tt></b> statements from "bottom" to "top", that is, +in the following order: + +<blockquote><ol> +<li>System includes (<b><tt>"xxx_.h"</tt></b>) +<li><b><tt>gs*.h</tt></b> +<li><b><tt>gx*.h</tt></b> (yes, <b><tt>gs</tt></b> and <b><tt>gx</tt></b> +are in the wrong order.) +<li><b><tt>s*.h</tt></b> +<li><b><tt>i*.h</tt></b> (or other interpreter headers that don't start +with "<b><tt>i</tt></b>") +</ol></blockquote> + +<h3><a name="Headers"></a>Headers (<b><tt>.h</tt></b> files)</h3> + +<p> +In header files, always use the following at the beginning of a header file +to prevent double inclusion: + +<blockquote> +{{ Copyright notice etc. }}<br><br> + +<b><tt>#ifndef </tt></b><filename><b><tt>_INCLUDED</tt></b><br> +<b><tt>#define </tt></b><filename><b><tt>_INCLUDED</tt></b><br><br> + +{{ The contents of the file }}<br><br> + +<b><tt>#endif /* </tt></b><filename><b><tt>_INCLUDED */</tt></b> +</blockquote> + +<p> +The header file is the first place that a reader goes for +information about procedures, structures, constants, etc., so ensure that +every procedure and structure has a comment that says what it does. Divide +procedures into meaningful groups set off by some distinguished form of +comment. + +<h3><a name="Source"></a>Source (<b><tt>.c</tt></b> files)</h3> + +<p> +After the initial comments, arrange C files in the following order: + +<blockquote><ol> +<li><b><tt>#include</tt></b> statements +<li>Exported data declarations +<li>Explicit externs (if necessary) +<li>Forward declarations of procedures +<li>Private data declarations +<li>Exported procedures +<li>Private procedures +</ol></blockquote> + +<p> +Be flexible about the order of the declarations if necessary to improve +readability. Many older files don't follow this order, often without good +reason. + +<hr> + +<h2><a name="Conventions"></a>Ghostscript conventions</h2> + +<h3><a name="Specific_names"></a>Specific names</h3> + +<p> +The Ghostscript code uses certain names consistently for certain kinds of +values. Some of the commonest and least obvious are these two: + +<h4><a name="code"></a><b><tt>code</tt></b></h4> + +<blockquote> +A value to be returned from a procedure: + +<table cellpadding=0 cellspacing=0> +<tr valign=top> <td align=right>< 0 + <td> + <td>An error code defined in +<a href="../src/gserrors.h">gserrors.h</a> +(or <a href="../src/errors.h">errors.h</a>) +<tr valign=top> <td align=right>0 + <td> + <td>Normal return +<tr valign=top> <td align=right>> 0 + <td> + <td>A non-standard but successful return (which must be documented, preferably with the procedure's prototype) +</table> + +</blockquote> + +<h4><a name="status"></a><b><tt>status</tt></b></h4> + +<blockquote> +A value returned from a stream procedure: + +<table cellpadding=0 cellspacing=0> +<tr valign=top> <td align=right>< 0 + <td> + <td>An exceptional condition as defined in +<a href="../src/scommon.h">scommon.h</a> +<tr valign=top> <td align=right>0 + <td> + <td>Normal return (or, from the "<b><tt>process</tt></b>" procedure, means that more input is needed) +<tr valign=top> <td align=right>1 + <td> + <td>More output space is needed (from the "<b><tt>process</tt></b>" procedure) +</table> +</blockquote> + +<h3><a name="Structure_type_descriptors"></a>Structure type descriptors</h3> + +<p> +The Ghostscript memory manager requires run-time type information for every +structure. (We don't document this in detail here: see the <a +href="Develop.htm#Structure_descriptors">Structure descriptors</a> section +of the developer documentation for details.) Putting the descriptor for a +structure next to the structure definition will help keep the two +consistent, so immediately after the definition of a structure +<b><tt>xxx_s</tt></b>, define its structure descriptor: + +<blockquote> +<b><tt>struct xxx_s {</tt></b><br> + ... members ...<br> +<b><tt>};</tt></b><br> +<b><tt>#define private_st_xxx() /* in </tt></b><filename><tt><b>.c */\</tt></b><br> +<b><tt> gs_private_st_</tt></b><whatever><b><tt>(st_xxx, xxx_t,\</tt></b><br> +<b><tt> "xxx_t", xxx_enum_ptrs, xxx_reloc_ptrs,\</tt></b><br> +<b><tt> </tt></b>... additional parameters as needed ...<b><tt>)</tt></b> +</blockquote> + +<p> +The file that implements operations on this structure +(<filename><b><tt>.c</tt></b>) should then include, near the +beginning, the line: + +<blockquote> +<b><tt>private_st_xxx();</tt></b> +</blockquote> + +<p> +In much existing code, structure descriptors are declared as +<b><tt>public</tt></b>, which allows clients to allocate instances of the +structure directly. We now consider this bad design. Instead, structure +descriptors should always be <b><tt>private</tt></b>; the implementation +file should provide one or more procedures for allocating instances, e.g., + +<blockquote> +<b><tt>xxx_t *gs_xxx_alloc(P1(gs_memory_t *mem));</tt></b> +</blockquote> + +<p> +If it is necessary to make a structure descriptor public, it should be +declared in its clients as + +<blockquote> +<b><tt>extern_st(st_xxx);</tt></b> +</blockquote> + +<h3><a name="Objects"></a>"Objects"</h3> + +<p> +Ghostscript makes heavy use of object-oriented constructs, including +analogues of classes, instances, subclassing, and class-associated +procedures. However, these constructs are implemented in C rather than C++, +for two reasons: + +<ul> + +<li>The first Ghostscript code was written in 1986, long before C++ was +codified or was well supported by tools. Even today, C++ tools rarely +support C++ as well as C tools support C. + +<li>C++ imposes its own implementations for virtual procedures, inheritance, +run-time type information, and (to some extent) memory management. +Ghostscript requires use of its own memory manager, and also sometimes +requires the ability to change the virtual procedures of an object +dynamically. + +</ul> + +<h4>Classes</h4> + +<p> +The source code representation of a class is simply a +<b><tt>typedef</tt></b> for a C <b><tt>struct</tt></b>. See <a +href="C-style.htm#Structures">Structures</a>, above, for details. + +<h4>Procedures</h4> + +<p> +Ghostscript has no special construct for non-virtual procedures associated +with a class. In some cases, the <b><tt>typedef</tt></b> for the class is +in a header file but the <b><tt>struct</tt></b> declaration is in the +implementation code file: this provides an extra level of opaqueness, since +clients then can't see the representation and must make all accesses through +procedures. You should use this approach in new code, if it doesn't +increase the size of the code too much or require procedure calls for very +heavily used accesses. + +<p> +Ghostscript uses three different approaches for storing and accessing +virtual procedures, plus a fourth one that is recommended but not currently +used. For exposition, we assume the class (type) is named +<b><tt>xxx_t</tt></b>, it has a virtual procedure +<b><tt>void (*virtu)(P1(xxx_t *))</tt></b>, and we have a variable +declared as <b><tt>xxx_t *pxx</tt></b>. + +<ol> + +<li>The procedures are stored in a separate, constant structure of type +<b><tt>xxx_procs</tt></b>, of which <b><tt>virtu</tt></b> is a member. The +structure definition of <b><tt>xxx_t</tt></b> includes a member defined as +<b><tt>const xxx_procs *procs</tt></b> (always named +<b><tt>procs</tt></b>). The construct for calling the virtual procedure is +<b><tt>pxx->procs->virtu(pxx)</tt></b>. + +<li>The procedures are defined in a structure of type +<b><tt>xxx_procs</tt></b> as above. The structure definition of +<b><tt>xxx_t</tt></b> includes a member defined as +<b><tt>xxx_procs procs</tt></b> (always named <b><tt>procs</tt></b>). +The construct for calling the virtual procedure is +<b><tt>pxx->procs.virtu(pxx)</tt></b>. + +<li>The procedures are not defined in a separate structure: each procedure +is a separate member of <b><tt>xxx_t</tt></b>. The construct for calling +the virtual procedure is <b><tt>pxx->virtu(pxx)</tt></b>. + +<li>The procedures are defined in a structure of type +<b><tt>xxx_procs</tt></b> as above. The structure definition of +<b><tt>xxx_t</tt></b> includes a member defined as +<b><tt>xxx_procs procs[1]</tt></b> (always named +<b><tt>procs</tt></b>). The construct for calling the virtual procedure is +again <b><tt>pxx->procs->virtu(pxx)</tt></b>. + +</ol> + +<p> +Note that in approach 1, the procedures are in a shared constant structure; +in approaches 2 - 4, they are in a per-instance structure that can be +changed dynamically, which is sometimes important. + +<p> +In the present Ghostscript code, approach 1 is most common, followed by 2 +and 3; 4 is not used at all. For new code, you should use 1 or 4: that way, +all virtual procedure calls have the same form, regardless of whether the +procedures are shared and constant or per-instance and mutable. + +<h4>Subclassing</h4> + +<p> +Ghostscript's class mechanism allows for subclasses that can add data +members, or can add procedure members if approach 1 or 3 (above) is used. +Since C doesn't support subclassing, we use a convention to accomplish it. +In the example below, <b><tt>gx_device</tt></b> is the root class; it has a +subclass <b><tt>gx_device_forward</tt></b>, which in turn has a subclass +<b><tt>gx_device_null</tt></b>. First we define a macro for all the members +of the root class, and the root class type. (As for structures in general, +classes need a structure descriptor, as discussed in <a +href="#Structures">Structures</a> above: we include these in the examples +below.) + +<blockquote><b><tt> +#define gx_device_common\<br> + type1 member1;\<br> + </tt></b>...<b><tt><br> + typeN memberN<br> +<br> +typedef struct gx_device_s {<br> + gx_device_common;<br> +} gx_device;<br> +<br> +#define private_st_gx_device() /* in gsdevice.c */\<br> + gs_private_st_</tt></b><whatever><b><tt>(st_gx_device, gx_device,\<br> + "gx_device", device_enum_ptrs, device_reloc_ptrs,\<br> + </tt></b>... additional parameters as needed ...<b><tt>)</tt></b> +</tt></b></blockquote> + +<p> +We then define a similar macro and type for the subclass. + +<blockquote><b><tt> +#define gx_device_forward_common\<br> + gx_device_common;\<br> + gx_device *target<br> +<br> +typedef struct gx_device_forward_s {<br> + gx_device_forward_common;<br> +} gx_device_forward;<br> +<br> +#define private_st_device_forward() /* in gsdevice.c */\<br> + gs_private_st_suffix_add1(st_device_forward, gx_device_forward,\<br> + "gx_device_forward", device_forward_enum_ptrs, device_forward_reloc_ptrs,\<br> + gx_device, target) +</tt></b></blockquote> + +<p> +Finally, we define a leaf class, which doesn't need a macro because we don't +currently subclass it. (We can create the macro later if needed, with no +changes anywhere else.) In this particular case, the leaf class has no +additional data members, but it could have some. + +<blockquote><b><tt> +typedef struct gx_device_null_s {<br> + gx_device_forward_common;<br> +};<br> +<br> +#define private_st_device_null() /* in gsdevice.c */\<br> + gs_private_st_suffix_add0_local(st_device_null, gx_device_null,\<br> + "gx_device_null", device_null_enum_ptrs, device_null_reloc_ptrs,\<br> + gx_device_forward) +</tt></b></blockquote> + +<p> +Note that the above example is <strong>not</strong> the actual definition of +the <b><tt>gx_device</tt></b> structure type: the actual type has some +additional complications because it has a finalization procedure. See <a +href="../src/gxdevcli.h">src/gxdevcli.h</a> for the details. + +<p> +If you add members to a root class (such as <b><tt>gx_device</tt></b> in +this example), or change existing members, do this in the +<b><tt>gx_device_common</tt></b> macro, not the <b><tt>gx_device</tt></b> +structure definition. Similarly, to change the +<b><tt>gx_device_forward</tt></b> class, modify the +<b><tt>gx_device_forward_common</tt></b> macro, not the structure +definition. Only change the structure definition if the class is a leaf +class (one with no <b><tt>_common</tt></b> macro and no possibility of +subclassing), like <b><tt>gx_device_null</tt></b>. + +<h3><a name="Error_handling"></a>Error handling</h3> + +<p> +Every caller should check for error returns and, in general, propagate them +to <b>its</b> callers. By convention, nearly every procedure returns an +<b><tt>int</tt></b> to indicate the outcome of the call: + +<blockquote><table cellpadding=0 cellspacing=0> +<tr valign=top> <td align=right>< 0 + <td> + <td>Error return +<tr valign=top> <td align=right>0 + <td> + <td>Normal return +<tr valign=top> <td align=right>> 0 + <td> + <td>Non-error return other than the normal case +</table></blockquote> + +<p> +To make a procedure generate an error and return it, as opposed to +propagating an error generated by a lower procedure, you should use + +<blockquote> +<b><tt>return_error(</tt></b><em>error_number</em><b><tt>);</tt></b> +</blockquote> + +<p> +Sometimes it is more convenient to generate the error in one place and +return it in another. In this case, you should use + +<blockquote> +<b><tt>code = gs_note_error(</tt></b><em>error_number</em><b><tt>);</tt></b><br> +...<br> +<b><tt>return code;</tt></b> +</blockquote> + +<p> +In executables built for debugging, the <b><tt>-E</tt></b> (or +<b><tt>-Z#</tt></b>) command line switch causes <b><tt>return_error</tt></b> +and <b><tt>gs_note_error</tt></b> to print the error number and the source +file and line: this is often helpful for identifying the original cause of +an error. + +<p> +See the file <a href="../src/gserrors.h">src/gserrors.h</a> for the error +return codes used by the graphics library, most of which correspond directly +to PostScript error conditions. + +<!-- [2.0 end contents] ==================================================== --> + +<!-- [3.0 begin visible trailer] =========================================== --> +<hr> + + +<p> +<small> +This software is provided AS-IS with no warranty, either express or +implied. + +This software is distributed under license and may not be copied, +modified or distributed except as expressly authorized under the terms +of the license contained in the file LICENSE in this distribution. +</small> + +<p> +<small>Copyright © 1996-2002 artofcode LLC. +All rights reserved.</small> + + +<p> +<small>Ghostscript version 7.07, 17 May 2003 + +<!-- [3.0 end visible trailer] ============================================= --> + +</body> +</html> |