mirror of
https://git.savannah.gnu.org/git/gperf.git
synced 2025-12-02 13:09:22 +00:00
Regenerated.
This commit is contained in:
Bruno Haible
683
doc/gperf_6.html
683
doc/gperf_6.html
@@ -1,291 +1,452 @@
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<!-- This HTML file has been created by texi2html 1.51
|
||||
from gperf.texi on 15 April 1998 -->
|
||||
from gperf.texi on 20 August 2000 -->
|
||||
|
||||
<TITLE>User's Guide to gperf - 3 High-Level Description of GNU gperf</TITLE>
|
||||
<TITLE>Perfect Hash Function Generator - 4 Invoking gperf</TITLE>
|
||||
</HEAD>
|
||||
<BODY>
|
||||
Go to the <A HREF="gperf_1.html">first</A>, <A HREF="gperf_5.html">previous</A>, <A HREF="gperf_7.html">next</A>, <A HREF="gperf_11.html">last</A> section, <A HREF="gperf_toc.html">table of contents</A>.
|
||||
<P><HR><P>
|
||||
|
||||
|
||||
<H1><A NAME="SEC8" HREF="gperf_toc.html#TOC8">3 High-Level Description of GNU <CODE>gperf</CODE></A></H1>
|
||||
<H1><A NAME="SEC14" HREF="gperf_toc.html#TOC14">4 Invoking <CODE>gperf</CODE></A></H1>
|
||||
|
||||
<P>
|
||||
The perfect hash function generator <CODE>gperf</CODE> reads a set of
|
||||
"keywords" from a <STRONG>keyfile</STRONG> (or from the standard input by
|
||||
default). It attempts to derive a perfect hashing function that
|
||||
recognizes a member of the <STRONG>static keyword set</STRONG> with at most a
|
||||
single probe into the lookup table. If <CODE>gperf</CODE> succeeds in
|
||||
generating such a function it produces a pair of C source code routines
|
||||
that perform hashing and table lookup recognition. All generated C code
|
||||
is directed to the standard output. Command-line options described
|
||||
below allow you to modify the input and output format to <CODE>gperf</CODE>.
|
||||
|
||||
</P>
|
||||
<P>
|
||||
By default, <CODE>gperf</CODE> attempts to produce time-efficient code, with
|
||||
less emphasis on efficient space utilization. However, several options
|
||||
exist that permit trading-off execution time for storage space and vice
|
||||
versa. In particular, expanding the generated table size produces a
|
||||
sparse search structure, generally yielding faster searches.
|
||||
Conversely, you can direct <CODE>gperf</CODE> to utilize a C <CODE>switch</CODE>
|
||||
statement scheme that minimizes data space storage size. Furthermore,
|
||||
using a C <CODE>switch</CODE> may actually speed up the keyword retrieval time
|
||||
somewhat. Actual results depend on your C compiler, of course.
|
||||
|
||||
</P>
|
||||
<P>
|
||||
In general, <CODE>gperf</CODE> assigns values to the characters it is using
|
||||
for hashing until some set of values gives each keyword a unique value.
|
||||
A helpful heuristic is that the larger the hash value range, the easier
|
||||
it is for <CODE>gperf</CODE> to find and generate a perfect hash function.
|
||||
Experimentation is the key to getting the most from <CODE>gperf</CODE>.
|
||||
|
||||
</P>
|
||||
|
||||
|
||||
<H2><A NAME="SEC9" HREF="gperf_toc.html#TOC9">3.1 Input Format to <CODE>gperf</CODE></A></H2>
|
||||
|
||||
<P>
|
||||
You can control the input keyfile format by varying certain command-line
|
||||
arguments, in particular the <SAMP>`-t'</SAMP> option. The input's appearance
|
||||
is similar to GNU utilities <CODE>flex</CODE> and <CODE>bison</CODE> (or UNIX
|
||||
utilities <CODE>lex</CODE> and <CODE>yacc</CODE>). Here's an outline of the general
|
||||
format:
|
||||
|
||||
</P>
|
||||
|
||||
<PRE>
|
||||
declarations
|
||||
%%
|
||||
keywords
|
||||
%%
|
||||
functions
|
||||
</PRE>
|
||||
|
||||
<P>
|
||||
<EM>Unlike</EM> <CODE>flex</CODE> or <CODE>bison</CODE>, all sections of <CODE>gperf</CODE>'s input
|
||||
are optional. The following sections describe the input format for each
|
||||
section.
|
||||
There are <EM>many</EM> options to <CODE>gperf</CODE>. They were added to make
|
||||
the program more convenient for use with real applications. "On-line"
|
||||
help is readily available via the <SAMP>`-h'</SAMP> option. Here is the
|
||||
complete list of options.
|
||||
|
||||
</P>
|
||||
|
||||
|
||||
|
||||
<H3><A NAME="SEC10" HREF="gperf_toc.html#TOC10">3.1.1 <CODE>struct</CODE> Declarations and C Code Inclusion</A></H3>
|
||||
<H2><A NAME="SEC15" HREF="gperf_toc.html#TOC15">4.1 Options that affect Interpretation of the Input File</A></H2>
|
||||
|
||||
<P>
|
||||
The keyword input file optionally contains a section for including
|
||||
arbitrary C declarations and definitions, as well as provisions for
|
||||
providing a user-supplied <CODE>struct</CODE>. If the <SAMP>`-t'</SAMP> option
|
||||
<EM>is</EM> enabled, you <EM>must</EM> provide a C <CODE>struct</CODE> as the last
|
||||
component in the declaration section from the keyfile file. The first
|
||||
field in this struct must be a <CODE>char *</CODE> identifier called <SAMP>`name'</SAMP>,
|
||||
although it is possible to modify this field's name with the <SAMP>`-K'</SAMP>
|
||||
option described below.
|
||||
|
||||
</P>
|
||||
<P>
|
||||
Here is simple example, using months of the year and their attributes as
|
||||
input:
|
||||
|
||||
</P>
|
||||
|
||||
<PRE>
|
||||
struct months { char *name; int number; int days; int leap_days; };
|
||||
%%
|
||||
january, 1, 31, 31
|
||||
february, 2, 28, 29
|
||||
march, 3, 31, 31
|
||||
april, 4, 30, 30
|
||||
may, 5, 31, 31
|
||||
june, 6, 30, 30
|
||||
july, 7, 31, 31
|
||||
august, 8, 31, 31
|
||||
september, 9, 30, 30
|
||||
october, 10, 31, 31
|
||||
november, 11, 30, 30
|
||||
december, 12, 31, 31
|
||||
</PRE>
|
||||
|
||||
<P>
|
||||
Separating the <CODE>struct</CODE> declaration from the list of key words and
|
||||
other fields are a pair of consecutive percent signs, <CODE>%%</CODE>,
|
||||
appearing left justified in the first column, as in the UNIX utility
|
||||
<CODE>lex</CODE>.
|
||||
|
||||
</P>
|
||||
<P>
|
||||
Using a syntax similar to GNU utilities <CODE>flex</CODE> and <CODE>bison</CODE>, it
|
||||
is possible to directly include C source text and comments verbatim into
|
||||
the generated output file. This is accomplished by enclosing the region
|
||||
inside left-justified surrounding <CODE>%{</CODE>, <CODE>%}</CODE> pairs. Here is
|
||||
an input fragment based on the previous example that illustrates this
|
||||
feature:
|
||||
|
||||
</P>
|
||||
|
||||
<PRE>
|
||||
%{
|
||||
#include <assert.h>
|
||||
/* This section of code is inserted directly into the output. */
|
||||
int return_month_days (struct months *months, int is_leap_year);
|
||||
%}
|
||||
struct months { char *name; int number; int days; int leap_days; };
|
||||
%%
|
||||
january, 1, 31, 31
|
||||
february, 2, 28, 29
|
||||
march, 3, 31, 31
|
||||
...
|
||||
</PRE>
|
||||
|
||||
<P>
|
||||
It is possible to omit the declaration section entirely. In this case
|
||||
the keyfile begins directly with the first keyword line, e.g.:
|
||||
|
||||
</P>
|
||||
|
||||
<PRE>
|
||||
january, 1, 31, 31
|
||||
february, 2, 28, 29
|
||||
march, 3, 31, 31
|
||||
april, 4, 30, 30
|
||||
...
|
||||
</PRE>
|
||||
|
||||
|
||||
|
||||
<H3><A NAME="SEC11" HREF="gperf_toc.html#TOC11">3.1.2 Format for Keyword Entries</A></H3>
|
||||
|
||||
<P>
|
||||
The second keyfile format section contains lines of keywords and any
|
||||
associated attributes you might supply. A line beginning with <SAMP>`#'</SAMP>
|
||||
in the first column is considered a comment. Everything following the
|
||||
<SAMP>`#'</SAMP> is ignored, up to and including the following newline.
|
||||
|
||||
</P>
|
||||
<P>
|
||||
The first field of each non-comment line is always the key itself. It
|
||||
should be given as a simple name, i.e., without surrounding
|
||||
string quotation marks, and be left-justified flush against the first
|
||||
column. In this context, a "field" is considered to extend up to, but
|
||||
not include, the first blank, comma, or newline. Here is a simple
|
||||
example taken from a partial list of C reserved words:
|
||||
|
||||
</P>
|
||||
|
||||
<PRE>
|
||||
# These are a few C reserved words, see the c.<CODE>gperf</CODE> file
|
||||
# for a complete list of ANSI C reserved words.
|
||||
unsigned
|
||||
sizeof
|
||||
switch
|
||||
signed
|
||||
if
|
||||
default
|
||||
for
|
||||
while
|
||||
return
|
||||
</PRE>
|
||||
|
||||
<P>
|
||||
Note that unlike <CODE>flex</CODE> or <CODE>bison</CODE> the first <CODE>%%</CODE> marker
|
||||
may be elided if the declaration section is empty.
|
||||
|
||||
</P>
|
||||
<P>
|
||||
Additional fields may optionally follow the leading keyword. Fields
|
||||
should be separated by commas, and terminate at the end of line. What
|
||||
these fields mean is entirely up to you; they are used to initialize the
|
||||
elements of the user-defined <CODE>struct</CODE> provided by you in the
|
||||
declaration section. If the <SAMP>`-t'</SAMP> option is <EM>not</EM> enabled
|
||||
these fields are simply ignored. All previous examples except the last
|
||||
one contain keyword attributes.
|
||||
|
||||
</P>
|
||||
|
||||
|
||||
<H3><A NAME="SEC12" HREF="gperf_toc.html#TOC12">3.1.3 Including Additional C Functions</A></H3>
|
||||
|
||||
<P>
|
||||
The optional third section also corresponds closely with conventions
|
||||
found in <CODE>flex</CODE> and <CODE>bison</CODE>. All text in this section,
|
||||
starting at the final <CODE>%%</CODE> and extending to the end of the input
|
||||
file, is included verbatim into the generated output file. Naturally,
|
||||
it is your responsibility to ensure that the code contained in this
|
||||
section is valid C.
|
||||
|
||||
</P>
|
||||
|
||||
|
||||
<H2><A NAME="SEC13" HREF="gperf_toc.html#TOC13">3.2 Output Format for Generated C Code with <CODE>gperf</CODE></A></H2>
|
||||
|
||||
<P>
|
||||
Several options control how the generated C code appears on the standard
|
||||
output. Two C function are generated. They are called <CODE>hash</CODE> and
|
||||
<CODE>in_word_set</CODE>, although you may modify the name for
|
||||
<CODE>in_word_set</CODE> with a command-line option. Both functions require
|
||||
two arguments, a string, <CODE>char *</CODE> <VAR>str</VAR>, and a length
|
||||
parameter, <CODE>int</CODE> <VAR>len</VAR>. Their default function prototypes are
|
||||
as follows:
|
||||
|
||||
</P>
|
||||
|
||||
<PRE>
|
||||
static int hash (char *str, int len);
|
||||
int in_word_set (char *str, int len);
|
||||
</PRE>
|
||||
|
||||
<P>
|
||||
By default, the generated <CODE>hash</CODE> function returns an integer value
|
||||
created by adding <VAR>len</VAR> to several user-specified <VAR>str</VAR> key
|
||||
positions indexed into an <STRONG>associated values</STRONG> table stored in a
|
||||
local static array. The associated values table is constructed
|
||||
internally by <CODE>gperf</CODE> and later output as a static local C array called
|
||||
<VAR>hash_table</VAR>; its meaning and properties are described below.
|
||||
See section <A HREF="gperf_10.html#SEC22">7 Implementation Details of GNU <CODE>gperf</CODE></A>. The relevant key positions are specified via the
|
||||
<SAMP>`-k'</SAMP> option when running <CODE>gperf</CODE>, as detailed in the <EM>Options</EM>
|
||||
section below. See section <A HREF="gperf_7.html#SEC14">4 Options to the <CODE>gperf</CODE> Utility</A>.
|
||||
|
||||
</P>
|
||||
<P>
|
||||
Two options, <SAMP>`-g'</SAMP> (assume you are compiling with GNU C and its
|
||||
<CODE>inline</CODE> feature) and <SAMP>`-a'</SAMP> (assume ANSI C-style function
|
||||
prototypes), alter the content of both the generated <CODE>hash</CODE> and
|
||||
<CODE>in_word_set</CODE> routines. However, function <CODE>in_word_set</CODE> may
|
||||
be modified more extensively, in response to your option settings. The
|
||||
options that affect the <CODE>in_word_set</CODE> structure are:
|
||||
|
||||
</P>
|
||||
|
||||
<UL>
|
||||
<DL COMPACT>
|
||||
|
||||
<DT><SAMP>`-e <VAR>keyword-delimiter-list</VAR>'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--delimiters=<VAR>keyword-delimiter-list</VAR>'</SAMP>
|
||||
<DD>
|
||||
<A NAME="IDX16"></A>
|
||||
Allows the user to provide a string containing delimiters used to
|
||||
separate keywords from their attributes. The default is ",\n". This
|
||||
option is essential if you want to use keywords that have embedded
|
||||
commas or newlines. One useful trick is to use -e'TAB', where TAB is
|
||||
the literal tab character.
|
||||
|
||||
<DT><SAMP>`-t'</SAMP>
|
||||
<DD>
|
||||
Make use of the user-defined <CODE>struct</CODE>.
|
||||
|
||||
<DT><SAMP>`-S <VAR>total switch statements</VAR>'</SAMP>
|
||||
<DT><SAMP>`--struct-type'</SAMP>
|
||||
<DD>
|
||||
Generate 1 or more C <CODE>switch</CODE> statement rather than use a large,
|
||||
(and potentially sparse) static array. Although the exact time and
|
||||
space savings of this approach vary according to your C compiler's
|
||||
degree of optimization, this method often results in smaller and faster
|
||||
code.
|
||||
Allows you to include a <CODE>struct</CODE> type declaration for generated
|
||||
code. Any text before a pair of consecutive <SAMP>`%%'</SAMP> is considered
|
||||
part of the type declaration. Keywords and additional fields may follow
|
||||
this, one group of fields per line. A set of examples for generating
|
||||
perfect hash tables and functions for Ada, C, C++, Pascal, Modula 2,
|
||||
Modula 3 and JavaScript reserved words are distributed with this release.
|
||||
</DL>
|
||||
|
||||
|
||||
|
||||
<H2><A NAME="SEC16" HREF="gperf_toc.html#TOC16">4.2 Options to specify the Language for the Output Code</A></H2>
|
||||
|
||||
<DL COMPACT>
|
||||
|
||||
<DT><SAMP>`-L <VAR>generated-language-name</VAR>'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--language=<VAR>generated-language-name</VAR>'</SAMP>
|
||||
<DD>
|
||||
Instructs <CODE>gperf</CODE> to generate code in the language specified by the
|
||||
option's argument. Languages handled are currently:
|
||||
|
||||
<DL COMPACT>
|
||||
|
||||
<DT><SAMP>`KR-C'</SAMP>
|
||||
<DD>
|
||||
Old-style K&R C. This language is understood by old-style C compilers and
|
||||
ANSI C compilers, but ANSI C compilers may flag warnings (or even errors)
|
||||
because of lacking <SAMP>`const'</SAMP>.
|
||||
|
||||
<DT><SAMP>`C'</SAMP>
|
||||
<DD>
|
||||
Common C. This language is understood by ANSI C compilers, and also by
|
||||
old-style C compilers, provided that you <CODE>#define const</CODE> to empty
|
||||
for compilers which don't know about this keyword.
|
||||
|
||||
<DT><SAMP>`ANSI-C'</SAMP>
|
||||
<DD>
|
||||
ANSI C. This language is understood by ANSI C compilers and C++ compilers.
|
||||
|
||||
<DT><SAMP>`C++'</SAMP>
|
||||
<DD>
|
||||
C++. This language is understood by C++ compilers.
|
||||
</DL>
|
||||
|
||||
The default is C.
|
||||
|
||||
<DT><SAMP>`-a'</SAMP>
|
||||
<DD>
|
||||
This option is supported for compatibility with previous releases of
|
||||
<CODE>gperf</CODE>. It does not do anything.
|
||||
|
||||
<DT><SAMP>`-g'</SAMP>
|
||||
<DD>
|
||||
This option is supported for compatibility with previous releases of
|
||||
<CODE>gperf</CODE>. It does not do anything.
|
||||
</DL>
|
||||
|
||||
|
||||
|
||||
<H2><A NAME="SEC17" HREF="gperf_toc.html#TOC17">4.3 Options for fine tuning Details in the Output Code</A></H2>
|
||||
|
||||
<DL COMPACT>
|
||||
|
||||
<DT><SAMP>`-K <VAR>key-name</VAR>'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--slot-name=<VAR>key-name</VAR>'</SAMP>
|
||||
<DD>
|
||||
<A NAME="IDX17"></A>
|
||||
This option is only useful when option <SAMP>`-t'</SAMP> has been given.
|
||||
By default, the program assumes the structure component identifier for
|
||||
the keyword is <SAMP>`name'</SAMP>. This option allows an arbitrary choice of
|
||||
identifier for this component, although it still must occur as the first
|
||||
field in your supplied <CODE>struct</CODE>.
|
||||
|
||||
<DT><SAMP>`-F <VAR>initializers</VAR>'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--initializer-suffix=<VAR>initializers</VAR>'</SAMP>
|
||||
<DD>
|
||||
<A NAME="IDX18"></A>
|
||||
This option is only useful when option <SAMP>`-t'</SAMP> has been given.
|
||||
It permits to specify initializers for the structure members following
|
||||
<VAR>key name</VAR> in empty hash table entries. The list of initializers
|
||||
should start with a comma. By default, the emitted code will
|
||||
zero-initialize structure members following <VAR>key name</VAR>.
|
||||
|
||||
<DT><SAMP>`-H <VAR>hash-function-name</VAR>'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--hash-fn-name=<VAR>hash-function-name</VAR>'</SAMP>
|
||||
<DD>
|
||||
Allows you to specify the name for the generated hash function. Default
|
||||
name is <SAMP>`hash'</SAMP>. This option permits the use of two hash tables in
|
||||
the same file.
|
||||
|
||||
<DT><SAMP>`-N <VAR>lookup-function-name</VAR>'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--lookup-fn-name=<VAR>lookup-function-name</VAR>'</SAMP>
|
||||
<DD>
|
||||
Allows you to specify the name for the generated lookup function.
|
||||
Default name is <SAMP>`in_word_set'</SAMP>. This option permits completely
|
||||
automatic generation of perfect hash functions, especially when multiple
|
||||
generated hash functions are used in the same application.
|
||||
|
||||
<DT><SAMP>`-Z <VAR>class-name</VAR>'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--class-name=<VAR>class-name</VAR>'</SAMP>
|
||||
<DD>
|
||||
<A NAME="IDX19"></A>
|
||||
This option is only useful when option <SAMP>`-L C++'</SAMP> has been given. It
|
||||
allows you to specify the name of generated C++ class. Default name is
|
||||
<CODE>Perfect_Hash</CODE>.
|
||||
|
||||
<DT><SAMP>`-7'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--seven-bit'</SAMP>
|
||||
<DD>
|
||||
This option specifies that all strings that will be passed as arguments
|
||||
to the generated hash function and the generated lookup function will
|
||||
solely consist of 7-bit ASCII characters (characters in the range 0..127).
|
||||
(Note that the ANSI C functions <CODE>isalnum</CODE> and <CODE>isgraph</CODE> do
|
||||
<EM>not</EM> guarantee that a character is in this range. Only an explicit
|
||||
test like <SAMP>`c >= 'A' && c <= 'Z''</SAMP> guarantees this.) This was the
|
||||
default in versions of <CODE>gperf</CODE> earlier than 2.7; now the default is
|
||||
to assume 8-bit characters.
|
||||
|
||||
<DT><SAMP>`-c'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--compare-strncmp'</SAMP>
|
||||
<DD>
|
||||
Generates C code that uses the <CODE>strncmp</CODE> function to perform
|
||||
string comparisons. The default action is to use <CODE>strcmp</CODE>.
|
||||
|
||||
<DT><SAMP>`-C'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--readonly-tables'</SAMP>
|
||||
<DD>
|
||||
Makes the contents of all generated lookup tables constant, i.e.,
|
||||
"readonly". Many compilers can generate more efficient code for this
|
||||
by putting the tables in readonly memory.
|
||||
|
||||
<DT><SAMP>`-E'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--enum'</SAMP>
|
||||
<DD>
|
||||
Define constant values using an enum local to the lookup function rather
|
||||
than with #defines. This also means that different lookup functions can
|
||||
reside in the same file. Thanks to James Clark <CODE><jjc@ai.mit.edu></CODE>.
|
||||
|
||||
<DT><SAMP>`-I'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--includes'</SAMP>
|
||||
<DD>
|
||||
Include the necessary system include file, <CODE><string.h></CODE>, at the
|
||||
beginning of the code. By default, this is not done; the user must
|
||||
include this header file himself to allow compilation of the code.
|
||||
|
||||
<DT><SAMP>`-G'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--global'</SAMP>
|
||||
<DD>
|
||||
Generate the static table of keywords as a static global variable,
|
||||
rather than hiding it inside of the lookup function (which is the
|
||||
default behavior).
|
||||
|
||||
<DT><SAMP>`-W <VAR>hash-table-array-name</VAR>'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--word-array-name=<VAR>hash-table-array-name</VAR>'</SAMP>
|
||||
<DD>
|
||||
<A NAME="IDX20"></A>
|
||||
Allows you to specify the name for the generated array containing the
|
||||
hash table. Default name is <SAMP>`wordlist'</SAMP>. This option permits the
|
||||
use of two hash tables in the same file, even when the option <SAMP>`-G'</SAMP>
|
||||
is given.
|
||||
|
||||
<DT><SAMP>`-S <VAR>total-switch-statements</VAR>'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--switch=<VAR>total-switch-statements</VAR>'</SAMP>
|
||||
<DD>
|
||||
<A NAME="IDX21"></A>
|
||||
Causes the generated C code to use a <CODE>switch</CODE> statement scheme,
|
||||
rather than an array lookup table. This can lead to a reduction in both
|
||||
time and space requirements for some keyfiles. The argument to this
|
||||
option determines how many <CODE>switch</CODE> statements are generated. A
|
||||
value of 1 generates 1 <CODE>switch</CODE> containing all the elements, a
|
||||
value of 2 generates 2 tables with 1/2 the elements in each
|
||||
<CODE>switch</CODE>, etc. This is useful since many C compilers cannot
|
||||
correctly generate code for large <CODE>switch</CODE> statements. This option
|
||||
was inspired in part by Keith Bostic's original C program.
|
||||
|
||||
<DT><SAMP>`-T'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--omit-struct-type'</SAMP>
|
||||
<DD>
|
||||
Prevents the transfer of the type declaration to the output file. Use
|
||||
this option if the type is already defined elsewhere.
|
||||
|
||||
<DT><SAMP>`-p'</SAMP>
|
||||
<DD>
|
||||
This option is supported for compatibility with previous releases of
|
||||
<CODE>gperf</CODE>. It does not do anything.
|
||||
</DL>
|
||||
|
||||
|
||||
|
||||
<H2><A NAME="SEC18" HREF="gperf_toc.html#TOC18">4.4 Options for changing the Algorithms employed by <CODE>gperf</CODE></A></H2>
|
||||
|
||||
<DL COMPACT>
|
||||
|
||||
<DT><SAMP>`-k <VAR>keys</VAR>'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--key-positions=<VAR>keys</VAR>'</SAMP>
|
||||
<DD>
|
||||
Allows selection of the character key positions used in the keywords'
|
||||
hash function. The allowable choices range between 1-126, inclusive.
|
||||
The positions are separated by commas, e.g., <SAMP>`-k 9,4,13,14'</SAMP>;
|
||||
ranges may be used, e.g., <SAMP>`-k 2-7'</SAMP>; and positions may occur
|
||||
in any order. Furthermore, the meta-character '*' causes the generated
|
||||
hash function to consider <STRONG>all</STRONG> character positions in each key,
|
||||
whereas '$' instructs the hash function to use the "final character"
|
||||
of a key (this is the only way to use a character position greater than
|
||||
126, incidentally).
|
||||
|
||||
For instance, the option <SAMP>`-k 1,2,4,6-10,'$''</SAMP> generates a hash
|
||||
function that considers positions 1,2,4,6,7,8,9,10, plus the last
|
||||
character in each key (which may differ for each key, obviously). Keys
|
||||
with length less than the indicated key positions work properly, since
|
||||
selected key positions exceeding the key length are simply not
|
||||
referenced in the hash function.
|
||||
|
||||
<DT><SAMP>`-l'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--compare-strlen'</SAMP>
|
||||
<DD>
|
||||
Compare key lengths before trying a string comparison. This might cut
|
||||
down on the number of string comparisons made during the lookup, since
|
||||
keys with different lengths are never compared via <CODE>strcmp</CODE>.
|
||||
However, using <SAMP>`-l'</SAMP> might greatly increase the size of the
|
||||
generated C code if the lookup table range is large (which implies that
|
||||
the switch option <SAMP>`-S'</SAMP> is not enabled), since the length table
|
||||
contains as many elements as there are entries in the lookup table.
|
||||
This option is mandatory for binary comparisons (see section <A HREF="gperf_5.html#SEC13">3.3 Use of NUL characters</A>).
|
||||
|
||||
<DT><SAMP>`-D'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--duplicates'</SAMP>
|
||||
<DD>
|
||||
<A NAME="IDX22"></A>
|
||||
Handle keywords whose key position sets hash to duplicate values.
|
||||
Duplicate hash values occur for two reasons:
|
||||
|
||||
|
||||
<UL>
|
||||
<LI>
|
||||
|
||||
Since <CODE>gperf</CODE> does not backtrack it is possible for it to process
|
||||
all your input keywords without finding a unique mapping for each word.
|
||||
However, frequently only a very small number of duplicates occur, and
|
||||
the majority of keys still require one probe into the table.
|
||||
|
||||
<LI>
|
||||
|
||||
Sometimes a set of keys may have the same names, but possess different
|
||||
attributes. With the -D option <CODE>gperf</CODE> treats all these keys as
|
||||
part of an equivalence class and generates a perfect hash function with
|
||||
multiple comparisons for duplicate keys. It is up to you to completely
|
||||
disambiguate the keywords by modifying the generated C code. However,
|
||||
<CODE>gperf</CODE> helps you out by organizing the output.
|
||||
</UL>
|
||||
|
||||
<P>
|
||||
If the <SAMP>`-t'</SAMP> and <SAMP>`-S'</SAMP> options are omitted, the
|
||||
default action is to generate a <CODE>char *</CODE> array containing the keys,
|
||||
together with additional null strings used for padding the array. By
|
||||
experimenting with the various input and output options, and timing the
|
||||
resulting C code, you can determine the best option choices for
|
||||
different keyword set characteristics.
|
||||
Option <SAMP>`-D'</SAMP> is extremely useful for certain large or highly
|
||||
redundant keyword sets, e.g., assembler instruction opcodes.
|
||||
Using this option usually means that the generated hash function is no
|
||||
longer perfect. On the other hand, it permits <CODE>gperf</CODE> to work on
|
||||
keyword sets that it otherwise could not handle.
|
||||
|
||||
<DT><SAMP>`-f <VAR>iteration-amount</VAR>'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--fast=<VAR>iteration-amount</VAR>'</SAMP>
|
||||
<DD>
|
||||
Generate the perfect hash function "fast". This decreases
|
||||
<CODE>gperf</CODE>'s running time at the cost of minimizing generated
|
||||
table-size. The iteration amount represents the number of times to
|
||||
iterate when resolving a collision. `0' means iterate by the number of
|
||||
keywords. This option is probably most useful when used in conjunction
|
||||
with options <SAMP>`-D'</SAMP> and/or <SAMP>`-S'</SAMP> for <EM>large</EM> keyword sets.
|
||||
|
||||
<DT><SAMP>`-i <VAR>initial-value</VAR>'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--initial-asso=<VAR>initial-value</VAR>'</SAMP>
|
||||
<DD>
|
||||
Provides an initial <VAR>value</VAR> for the associate values array. Default
|
||||
is 0. Increasing the initial value helps inflate the final table size,
|
||||
possibly leading to more time efficient keyword lookups. Note that this
|
||||
option is not particularly useful when <SAMP>`-S'</SAMP> is used. Also,
|
||||
<SAMP>`-i'</SAMP> is overridden when the <SAMP>`-r'</SAMP> option is used.
|
||||
|
||||
<DT><SAMP>`-j <VAR>jump-value</VAR>'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--jump=<VAR>jump-value</VAR>'</SAMP>
|
||||
<DD>
|
||||
<A NAME="IDX23"></A>
|
||||
Affects the "jump value", i.e., how far to advance the associated
|
||||
character value upon collisions. <VAR>Jump-value</VAR> is rounded up to an
|
||||
odd number, the default is 5. If the <VAR>jump-value</VAR> is 0 <CODE>gperf</CODE>
|
||||
jumps by random amounts.
|
||||
|
||||
<DT><SAMP>`-n'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--no-strlen'</SAMP>
|
||||
<DD>
|
||||
Instructs the generator not to include the length of a keyword when
|
||||
computing its hash value. This may save a few assembly instructions in
|
||||
the generated lookup table.
|
||||
|
||||
<DT><SAMP>`-o'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--occurrence-sort'</SAMP>
|
||||
<DD>
|
||||
Reorders the keywords by sorting the keywords so that frequently
|
||||
occuring key position set components appear first. A second reordering
|
||||
pass follows so that keys with "already determined values" are placed
|
||||
towards the front of the keylist. This may decrease the time required
|
||||
to generate a perfect hash function for many keyword sets, and also
|
||||
produce more minimal perfect hash functions. The reason for this is
|
||||
that the reordering helps prune the search time by handling inevitable
|
||||
collisions early in the search process. On the other hand, if the
|
||||
number of keywords is <EM>very</EM> large using <SAMP>`-o'</SAMP> may
|
||||
<EM>increase</EM> <CODE>gperf</CODE>'s execution time, since collisions will
|
||||
begin earlier and continue throughout the remainder of keyword
|
||||
processing. See Cichelli's paper from the January 1980 Communications
|
||||
of the ACM for details.
|
||||
|
||||
<DT><SAMP>`-r'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--random'</SAMP>
|
||||
<DD>
|
||||
Utilizes randomness to initialize the associated values table. This
|
||||
frequently generates solutions faster than using deterministic
|
||||
initialization (which starts all associated values at 0). Furthermore,
|
||||
using the randomization option generally increases the size of the
|
||||
table. If <CODE>gperf</CODE> has difficultly with a certain keyword set try using
|
||||
<SAMP>`-r'</SAMP> or <SAMP>`-D'</SAMP>.
|
||||
|
||||
<DT><SAMP>`-s <VAR>size-multiple</VAR>'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--size-multiple=<VAR>size-multiple</VAR>'</SAMP>
|
||||
<DD>
|
||||
Affects the size of the generated hash table. The numeric argument for
|
||||
this option indicates "how many times larger or smaller" the maximum
|
||||
associated value range should be, in relationship to the number of keys.
|
||||
If the <VAR>size-multiple</VAR> is negative the maximum associated value is
|
||||
calculated by <EM>dividing</EM> it into the total number of keys. For
|
||||
example, a value of 3 means "allow the maximum associated value to be
|
||||
about 3 times larger than the number of input keys".
|
||||
|
||||
Conversely, a value of -3 means "allow the maximum associated value to
|
||||
be about 3 times smaller than the number of input keys". Negative
|
||||
values are useful for limiting the overall size of the generated hash
|
||||
table, though this usually increases the number of duplicate hash
|
||||
values.
|
||||
|
||||
If `generate switch' option <SAMP>`-S'</SAMP> is <EM>not</EM> enabled, the maximum
|
||||
associated value influences the static array table size, and a larger
|
||||
table should decrease the time required for an unsuccessful search, at
|
||||
the expense of extra table space.
|
||||
|
||||
The default value is 1, thus the default maximum associated value about
|
||||
the same size as the number of keys (for efficiency, the maximum
|
||||
associated value is always rounded up to a power of 2). The actual
|
||||
table size may vary somewhat, since this technique is essentially a
|
||||
heuristic. In particular, setting this value too high slows down
|
||||
<CODE>gperf</CODE>'s runtime, since it must search through a much larger range
|
||||
of values. Judicious use of the <SAMP>`-f'</SAMP> option helps alleviate this
|
||||
overhead, however.
|
||||
</DL>
|
||||
|
||||
|
||||
|
||||
<H2><A NAME="SEC19" HREF="gperf_toc.html#TOC19">4.5 Informative Output</A></H2>
|
||||
|
||||
<DL COMPACT>
|
||||
|
||||
<DT><SAMP>`-h'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--help'</SAMP>
|
||||
<DD>
|
||||
Prints a short summary on the meaning of each program option. Aborts
|
||||
further program execution.
|
||||
|
||||
<DT><SAMP>`-v'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--version'</SAMP>
|
||||
<DD>
|
||||
Prints out the current version number.
|
||||
|
||||
<DT><SAMP>`-d'</SAMP>
|
||||
<DD>
|
||||
<DT><SAMP>`--debug'</SAMP>
|
||||
<DD>
|
||||
Enables the debugging option. This produces verbose diagnostics to
|
||||
"standard error" when <CODE>gperf</CODE> is executing. It is useful both for
|
||||
maintaining the program and for determining whether a given set of
|
||||
options is actually speeding up the search for a solution. Some useful
|
||||
information is dumped at the end of the program when the <SAMP>`-d'</SAMP>
|
||||
option is enabled.
|
||||
</DL>
|
||||
|
||||
</P>
|
||||
<P><HR><P>
|
||||
Go to the <A HREF="gperf_1.html">first</A>, <A HREF="gperf_5.html">previous</A>, <A HREF="gperf_7.html">next</A>, <A HREF="gperf_11.html">last</A> section, <A HREF="gperf_toc.html">table of contents</A>.
|
||||
</BODY>
|
||||
|
||||
Reference in New Issue
Block a user