next_inactive up previous
Aspell Devel Docs
Copyright (c) 2002
Kevin Atkinson
kevina@gnu.org
Contents
* Notes
* Copyright
* 1 Style Guidelines
* 2 C++ Standard Library
* 3 Templates
* 4 Error Handling
* 5 Source Code Layout
* 6 Strings
* 7 Smart Pointers
* 8 I/O
* 9 Config Class
* 10 Filter Interface
* 11 Data Structures
* 12 Mk-Src Script
* 13 GNU Free Documentation License
* About this document ...
Notes
This manual is designed for those who which to developer Aspell. It is
currently very sketchy. However, it should improve over time. The latest
version of this document can be found at http://savannah.gnu.org/download/
aspell/manual/devel/devel.html.
The eventual goal is to convert this manual into Texinfo. However, since I
do not have the time to learn Texinfo right now, I decided to use
something I am already conferable with. Once someone goes through the
trouble of converting it into Texinfo I will maintain the Texinfo version.
Copyright
Copyright (c) 2002 Kevin Atkinson. Permission is granted to copy,
distribute and/or modify this document under the terms of the GNU Free
Documentation License, Version 1.1 or any later version published by the
Free Software Foundation; with no Invariant Sections, no Front-Cover
Texts. and no Back-Cover Texts. A copy of the license is included in the
section entitled "GNU Free Documentation License".
1 Style Guidelines
As far as coding styles go I am really not that picky. The important thing
is to stay consistent. However, please what ever you do, do not indent
with more than 4 characters as I find indenting with more than that
extremely difficult to read as most of the code ends up on the right side
of the window.
2 C++ Standard Library
The C++ Standard library is not used directly except under very specific
circumstances. The string class and the STL is used indirectly though
wrapper classes and all I/O is done using the standard C library with
light right helper classes to make using C I/O a bit more C++ like.
However the new, new[], delete and delete[] operates are used to allocated
memory when appropriate.
3 Templates
Templates are used in Aspell when there is a clear advantage to doing so.
When ever you use templates please use them carefully and try very hard
not to create code bloat by generating a lot of unnecessary, and duplicate
code.
4 Error Handling
Exceptions are not used in Aspell as I find them more trouble than they
are worth. Instead an alternate method of error handling is used which is
based around the PosibErr class. PosibErr is a special Error handling
device that will make sure that an error is properly handled. It is
defined in "posib_err.hpp". PosibErr is expected to be used as the
return type of the function It will automatically convert to the "normal"
return type however if the normal returned type is accessed and there is
an "unhandled" error condition it will abort It will also abort if the
object is destroyed with an "unhandled" error condition. This includes
ignoring the return type of a function returning an error condition. An
error condition is handled by simply checking for the presence of an
error, calling ignore, or taking ownership of the error.
The PosibErr class is used extensively though out Aspell. Please refer to
the Aspell source for examples of using PosibErr until better
documentation is written.
5 Source Code Layout
common/
Common code used by all parts of Aspell
lib/
Library code used only by the actual Aspell library
data/
Data files used by Aspell
modules/
Aspell modules which are eventually meant to be pluggable
speller/
default/
Main speller Module.
filter/
tokenizer/
auto/
Scripts and data files to automatically generate code used by Aspell
interface/
Header files and such that external programs should use when in order
to use the Aspell library.
cc/
The external "C" interface that programs should be using when
they wish to use Aspell.
prog/
Actual programs based on the Aspell library. The main "aspell"
utility is included here.
scripts/
Misc. scripts used by Aspell
manual/
examples/
Example programs demonstrating the use of the Aspell library
6 Strings
6.1 String
The String class provided the same functionally of the C++ string except
for fewer constructors. It also inherits OStream so that you can write to
it with the "<<" operator. It is defined in "string.hpp".
6.2 ParmString
ParmString is a special string class that is designed to be used as a
parameter for a function that is expecting a string. It is defined in
"parm_sting.hpp". It will allow either a "const char *" or "String"
class to be passed in. It will automatically convert to a "const char *".
The string can also be accesses via the "str" method. Usage example:
void foo(ParmString s1, ParmString s2) {
const char * str0 = s1;
unsigned int size0 = s2.size()
if (s1 == s2 || s2 == "bar") {
...
}
}
...
String s1 = "...";
foo(s1);
const char * s2 = "...";
foo(s2);
This class should be used when a string is being passed in as a parameter.
It is faster than using "const String SPMamp;" (as that will create an
unnecessary temporary when a const char * is passed in), and is less
annoying than using "const char *" (as it doesn't require the c_str()
method to be used when a String is passed in).
6.3 CharVector
A character vector is basically a Vector<char> but it has a few additional
methods for dealing with strings which Vector does not provide. It, like
String, is also inherits OStream so that you can write to it with the
"<<" operator. It is defined in "char_vector.hpp". Use it when ever
you need a string which is guaranteed to be in a continuous block of
memory which you can write to.
7 Smart Pointers
Smart pointers are used extensively in Aspell to avoid simplify memory
management tasks and to avoid memory leaks.
7.1 CopyPtr
The CopyPtr class makes a deep copy of an object when ever it is copied.
The CopyPtr class is defined in "copy_ptr.hpp". This header should be
included where ever CopyPtr is used. The complete definition of the object
CopyPtr is pointing to does not need to be defined at this point. The
implementation is defined in "copy_ptr-t.hpp". The implementation header
file should be included at a point in your code where the class CopyPtr is
pointing to is completely defined.
7.2 ClonePtr
ClonePtr is like copy pointer except the clone() method is used instead of
the copy constructor to make copies of an object. If is defined in
"clone_ptr.hpp" and implemented in "clone_ptr-t.hpp".
7.3 StackPtr
A StackPtr is designed to be used when ever the only pointer to a new
object allocated with new is on the stack. It is similar to the standard
C++ auto_ptr but the semantics are a bit different. It is defined in
"stack_ptr.hpp" unlike CopyPtr of ClonePtr it is defined and implemented
in this header file.
7.4 GenericCopyPtr
A generalized version of CopyPtr and ClonePtr which the two are based on.
It is defined in "generic_copy_ptr.hpp" and implemented in
"generic_copy_ptr-t.hpp".
8 I/O
Aspell does not use C++ I/O classes and function in any way since they do
not provide a way to get at the underlying file number and can often be
slower than the highly tuned C I/O functions found in the standard C
library. However, some light weight wrapper classes are provided so that
standard C I/O can be used in a more C++ like way.
8.1 IStream/OStream
These two base classes mimic some of the functionally of the C++
functionally of the corresponding classes. They are defined in
"istream.hpp" and "ostream.hpp" respectfully. They are however based
on standard C I/O and are not proper C++ streams.
8.2 FStream
Defined in "fstream.hpp"
8.3 Standard Streams
CIN/COUT/CERR. Defined in "iostream.hpp".
9 Config Class
The Config class is used to hold configuration information. It has a set
of keys which it will except. Inserting or even trying to look at a key
that it does not know will produce an error. It is defined in "common/
config.hpp"
10 Filter Interface
10.1 Overview
In Aspell there are 5 types of filters:
1. Decoders which take input in some standard format such as iso8859-1 or
UTF-8 and convert it into a string of FilterChars.
2. Decoding filters which manipulates a string of FilterChars by decoding
the text is some way such as converting SGML character into its
Unicode value.
3. True filters which manipulates a string of FilterChars to make it more
suitable for spell checking. These filers generally blank out text
which should not be spell checked
4. Encoding filters which manipulates a string of FilterChars by encoding
the text is some way such as converting certain Unicode characters to
SGML characters.
5. Encoders which take a string of FilterChars and convert into a
standard format such as iso8859-1 or UTF-8
Which types of filters are used depends on the situation
1. When decoding words for spell checking:
+ The decoder to convert from a standard format
+ The decoding filter to perform high level decoding if necessary
+ The encoder to convert into an internal format used by the speller
module
* When checking a document
+ The decoder to convert from a standard format
+ The decoding filter to perform high level decoding if necessary
+ A true filter to filter out parts of the document which should not
be spell checked
+ The encoder to convert into an internal format used by the speller
module
1. When encoding words such as those returned for suggestions:
+ The decoder to convert from the internal format used by the
speller module
+ The encoding filter to perform high level encodings if necessary
+ The encoder to convert into a standard format
A FilterChar is a struct defined in "common/filter_char.hpp" which
contains two members, a character, and a width. Its purpose is to keep
track of the width of the character in the original format. This is
important because when a misspelled word is found the exact location of
the word needs to be returned to the application so that it can highlight
it for the user. For example if the filters translated this:
Mr. foo said "I hate my namme".
to this
Mr. foo said "I hate my namme".
without keeping track of the original width of the characters the
application will likely highlight "e my " as the misspelling because the
spell checker will return 25 as the offset instead of 30. However with
keeping track of the width using FilterChar the spell checker will now
that the real position it 30 since the quote is really 6 characters wide.
In particular the text will be annotated something like the following:
1111111111111611111111111111161
Mr. foo said "I hate my namme".
The standard encoder and decoder filters are defined in "common/
convert.cpp". There should generally not be any need to deal with them so
they will not be discussed here. The other three filters, the encoding
filter, the true filter, and the decoding filter, are all defined the
exact same way; they are inherited from the IndividualFilter class.
10.2 Adding a New Filter
To add a new filter create a new file in the modules/filter directory, the
file should be a C++ file and end in ".cpp". The file should contain a
new filter class inherited from IndividualFilter, a function to return a
new filter, and an optional KeyInfo array for adding options to control
the behavior of the filter. The file then needs to be added to Makefile.am
so that the build system knows about the filter and lib/new_filter.cpp
must be modified so that Aspell knows about the filter.
10.3 IndividualFilter class
All filters are required to inherit from the IndividualFilter class found
in "indiv_filter.hpp". See that file for more details and the other
filter modules for examples of how it is used.
10.4 Constructor Function
After the class is created a function must to created which will return a
new filter allocated with new. The function must have the following
prototype:
IndividualFilter * new_«filter_name»
Filters are defined in groups where each group contains an encoding filter
, a true filter, and a decoding filter. Only one of them is required to be
defined, however they all need a separate constructor function.
10.5 Config Options
A filter group may have any number of options associated with it as long
as they all start with the filter name. See the TEX and SGML filter for
examples of what to do and "config.hpp" for the definition of the
KeyInfo struct.
10.6 Makefile Modifications
After the new file is created simply add the file to the
"libaspell_filter_standard_la_SOURCES" line in "modules/filter/
Makefile.am" so that the build system knows about it.
10.7 New_filter Modifications
Finally modify "lib/new_filter.cpp" so that Aspell knows about the new
filter. Follow the example there for the other filter modules. The
filter_modules array should only be modified if there your filter has
config options.
11 Data Structures
When ever possible you should try to use on of the data structures
available. If the data structures do not provide enough functionally for
your needs you should consider enhancing them rather than written
something from scratch.
11.1 Vector
The vector class is defined in "vector.hpp" and works the same way as
the standard STL vector does except that it doesn't have as many
constructors.
11.2 BasicList
BasicList is a simple list structure which can either be implemented as a
singly or doubly linked list. It is defined in "basic_list.hpp".
11.3 StringMap
StringMap is a associative array for strings. You should try to use this
when ever possible to avoid code bloat. It is defined in
"string_map.hpp"
11.4 Hash Tables
Several hash tables are provided when StringMap is not appropriate. These
hash tables provide a hash_set, hash_multiset, hash_map and hash_multimap
which are very similar to SGI STL's implementation with a few exceptions.
It is defined in "hash.hpp"
11.5 BlockSList
BlockSList provided a pool of nodes which can be used for singly linked
lists. It is defined in "block_slist.hpp".
12 Mk-Src Script
A good deal of interface code is automatically generated by the
"mk-src.pl" Perl script. I am doing it this way to avoid having to write
a lot of relative code for the C++ interface. This should also make adding
interface for other languages a lot less tedious and will allow the
interface to automatically take advantage of new Aspell functionality as
it is made available. The "mk-src.pl" script uses "mk-src.in" as its
input.
12.1 mk-src.in
The format of mk-src.in is as follows:
The following charaters are literals: { } / '\ ' \n = >
<items>
<items> := (<item>\n)+
<items> := <category>:\ <name> {\n<details>\n} | <<tab>><details>
<details> := <options>\n /\n <items>
<options> := (<option>\n)*
<option> := <key> [=> <value>]
<<tab>> means everything should be indented by one tab
See MkSrc::Info for a description of the categorys and options
12.2 MkSrc::Info
%info
The info array contains information on how to process the info in
mk-src.pl. It has the following layout
<catagory> => options => []
groups => [] # if undef than anything is accepted
creates_type => "" # the object will create a new type
# as specified
proc => <impl type> => sub {}
where $<$impl type$>$ is one of:
cc: for "aspell.h" header file
cxx: for C++ interface implemented on top of cc interface
native: for creation of header files used internally by aspell
impl: for defination of functions declared in cc interface.
the definations use the native hedaer files
native_impl: for implementations of stuff declared in the native
header files
each proc sub should take the following argv
$data: a subtree of $master_data
$accum:
$<$options$>$ is one of:
desc: description of the object
prefix:
posib err: the method may return an error condition
c func:
const: the method is a const member
c only: only include in the external interface
c impl headers: extra headers that need to be included in the C impl
c impl: use this as the c impl instead of the default
cxx impl: use this as the cxx impl instead of the default
returns alt type: the constructor returns some type other than
the object from which it is a member of
no native: do not attemt to create a native implementation
treat as object: treat as a object rather than a pointer
The %info structure is initialized as follows:
our %info =
(
root => {
options => [],
groups => ['methods', 'group']},
methods => {
# methods is a collection of methods which will be inserted into
# a class after some simple substation rules. A $ will be
# replaced with name of the class.
options => ['strip', 'prefix', 'c impl headers'],
groups => undef},
group => {
# a group is a colection of objects which should be grouped together
# this generally means they will be in the same source file
options => ['no native'],
groups => ['enum', 'struct', 'union', 'func', 'class', 'errors']},
enum => {
# basic C enum
options => ['desc', 'prefix'],
creates_type => 'enum'},
struct => {
# basic c struct
options => ['desc', 'treat as object'],
groups => undef,
creates_type => 'struct',},
union => {
# basic C union
options => ['desc', 'treat as object'],
groups => undef,
creates_type => 'union'},
class => {
# C++ class
options => ['c impl headers'],
groups => undef,
creates_type => 'class'},
errors => {}, # possible errors
method => {
# A class method
options => ['desc', 'posib err', 'c func', 'const',
'c only', 'c impl', 'cxx impl'],
groups => undef},
constructor => {
# A class constructor
options => ['returns alt type', 'c impl', 'desc'],
groups => 'types'},
destructor => {
# A class destructor
options => [],
groups => undef},
);
In addition to the categories listed above a "methods" catagory by be
specified in under the class category. A "methods" catagory is created for
each methods group under the name "$<$methods name$>$ methods" When groups
is undefined a type name may be specified in place of a category
%types
types contains a master list of all types. This includes basic types and
ones created in mk-src.in. The basic types include:
'void', 'bool', 'pointer', 'double',
'string', 'encoded string', 'string obj',
'char', 'unsigned char',
'short', 'unsigned short',
'int', 'unsigned int',
'long', 'unsigned long'
%methods
%methods is used for holding the "methods" information
12.3 MkSrc::Util
This module contains various useful utility functions:
false
Returns 0.
true
Returns 1.
cmap EXPR LIST
Apply EXPR to each item in LIST and than concatenate the result into a
string
one_of STR LIST
Returns true if LIST contains at least one of STR.
to_upper STR
Convert STR to all uppercase and substitute spaces with underscores.
to_lower STR
Convert STR to all lowercase and substitute spaces with underscores.
to_mixed STR
Convert STR to mixed case where each new word startes with a uppercase
letter. For example "feed me" would become "FeedMe".
12.4 MkSrc::Read
read
Read in "mk-src.in" and returns a data structure which has the
following format:
<tree>
<tree> := <options>
data => <tree>
where each tree represents an entry in mk-src.in.
The following two options are always provided:
name: the name of the entry
type: the catagory or type name
Additional options are the same as specified in %info
12.5 MKSrc::Create
create_cc_file PARMS
Create a source file.
Required Parms: type, dir, name, data
Boolean Parms: header, cxx
Optional Parms: namespace (required if cxx), pre_ext, accum
create_file FILENAME DATA
Writes DATA to FILENAME but only if DATA differs from the content of
the file and the string:
Automatically generated file.
is present in the existing file if it already exists.
12.6 Code Generation Modes
The code generation modes are currently one of the following:
cc: Mode used to create types suitable for C interface
cc_cxx: Like cc but typenames don't have a leading Aspell prefix
cxx: Mode used to create types suitable for CXX interface
native: Mode in which types are suitable for the internal implementation
native_no_err: Like Native but with out PosibErr return types
12.7 MkSrc::CcHelper
Helper functions used by interface generation code:
to_c_return_type ITEM
.
c_error_cond ITEM
.
make_func NAME @TYPES PARMS ; %ACCUM
Creates a function prototype
Parms can be any of:
mode: code generation mode
call_func NAME @TYPES PARMS ; %ACCUM
Return a string to call a func. Will prefix the function with return
if the functions returns a non-void type;
Parms can be any of:
mode: code generation mode
to_type_name ITEM PARMS ; %ACCUM
Converts item into a type name.
Parms can be any of:
mode: code generation mode
use_type: include the actual type
use_name: include the name on the type
pos: either "return" or "other"
make_desc DESC ; LEVEL
Make a C comment out of DESC optionally indenting it LEVEL spaces.
make_c_method CLASS ITEM PARMS ; %ACCUM
Create the phototype for a C method which is really a function.
Parms is any of:
mode: code generation mode
no_aspell: if true do not include aspell in the name
this_name: name for the paramater representing the current object
call_c_method CLASS ITEM PARMS ; %ACCUM
Like make_c_method but instead returns the appropriate string to call
the function. If the function returns a non-void type the string will
be prefixed with a return statement.
form_c_method CLASS ITEM PARMS ; %ACCUM
Like make_c_method except that it returns the array:
($func, $data, $parms, $accum)
which is suitable for passing into make_func. It will return an empty
array if it can not make a method from ITEM.
make_cxx_method ITEM PARMS ; %ACCUM
Create the phototype for a C++ method.
Parms is one of:
mode: code generation mode
13 GNU Free Documentation License
Version 1.1, March 2000
Copyright © 2000 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Preamble
The purpose of this License is to make a manual, textbook, or other
written document "free" in the sense of freedom: to assure everyone the
effective freedom to copy and redistribute it, with or without modifying
it, either commercially or noncommercially. Secondarily, this License
preserves for the author and publisher a way to get credit for their work,
while not being considered responsible for modifications made by others.
This License is a kind of "copyleft", which means that derivative works
of the document must themselves be free in the same sense. It complements
the GNU General Public License, which is a copyleft license designed for
free software.
We have designed this License in order to use it for manuals for free
software, because free software needs free documentation: a free program
should come with manuals providing the same freedoms that the software
does. But this License is not limited to software manuals; it can be used
for any textual work, regardless of subject matter or whether it is
published as a printed book. We recommend this License principally for
works whose purpose is instruction or reference.
13.1 Applicability and Definitions
This License applies to any manual or other work that contains a notice
placed by the copyright holder saying it can be distributed under the
terms of this License. The "Document", below, refers to any such manual
or work. Any member of the public is a licensee, and is addressed as
"you".
A "Modified Version" of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with modifications
and/or translated into another language.
A "Secondary Section" is a named appendix or a front-matter section of
the Document that deals exclusively with the relationship of the
publishers or authors of the Document to the Document's overall subject
(or to related matters) and contains nothing that could fall directly
within that overall subject. (For example, if the Document is in part a
textbook of mathematics, a Secondary Section may not explain any
mathematics.) The relationship could be a matter of historical connection
with the subject or with related matters, or of legal, commercial,
philosophical, ethical or political position regarding them.
The "Invariant Sections" are certain Secondary Sections whose titles are
designated, as being those of Invariant Sections, in the notice that says
that the Document is released under this License.
The "Cover Texts" are certain short passages of text that are listed, as
Front-Cover Texts or Back-Cover Texts, in the notice that says that the
Document is released under this License.
A "Transparent" copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the general
public, whose contents can be viewed and edited directly and
straightforwardly with generic text editors or (for images composed of
pixels) generic paint programs or (for drawings) some widely available
drawing editor, and that is suitable for input to text formatters or for
automatic translation to a variety of formats suitable for input to text
formatters. A copy made in an otherwise Transparent file format whose
markup has been designed to thwart or discourage subsequent modification
by readers is not Transparent. A copy that is not "Transparent" is
called "Opaque".
Examples of suitable formats for Transparent copies include plain ASCII
without markup, Texinfo input format, LATEX input format, SGML or XML
using a publicly available DTD, and standard-conforming simple HTML
designed for human modification. Opaque formats include PostScript, PDF,
proprietary formats that can be read and edited only by proprietary word
processors, SGML or XML for which the DTD and/or processing tools are not
generally available, and the machine-generated HTML produced by some word
processors for output purposes only.
The "Title Page" means, for a printed book, the title page itself, plus
such following pages as are needed to hold, legibly, the material this
License requires to appear in the title page. For works in formats which
do not have any title page as such, "Title Page" means the text near the
most prominent appearance of the work's title, preceding the beginning of
the body of the text.
13.2 Verbatim Copying
You may copy and distribute the Document in any medium, either
commercially or noncommercially, provided that this License, the copyright
notices, and the license notice saying this License applies to the
Document are reproduced in all copies, and that you add no other
conditions whatsoever to those of this License. You may not use technical
measures to obstruct or control the reading or further copying of the
copies you make or distribute. However, you may accept compensation in
exchange for copies. If you distribute a large enough number of copies you
must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you
may publicly display copies.
13.3 Copying in Quantity
If you publish printed copies of the Document numbering more than 100, and
the Document's license notice requires Cover Texts, you must enclose the
copies in covers that carry, clearly and legibly, all these Cover Texts:
Front-Cover Texts on the front cover, and Back-Cover Texts on the back
cover. Both covers must also clearly and legibly identify you as the
publisher of these copies. The front cover must present the full title
with all words of the title equally prominent and visible. You may add
other material on the covers in addition. Copying with changes limited to
the covers, as long as they preserve the title of the Document and satisfy
these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly,
you should put the first ones listed (as many as fit reasonably) on the
actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more
than 100, you must either include a machine-readable Transparent copy
along with each Opaque copy, or state in or with each Opaque copy a
publicly-accessible computer-network location containing a complete
Transparent copy of the Document, free of added material, which the
general network-using public has access to download anonymously at no
charge using public-standard network protocols. If you use the latter
option, you must take reasonably prudent steps, when you begin
distribution of Opaque copies in quantity, to ensure that this Transparent
copy will remain thus accessible at the stated location until at least one
year after the last time you distribute an Opaque copy (directly or
through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the
Document well before redistributing any large number of copies, to give
them a chance to provide you with an updated version of the Document.
13.4 Modifications
You may copy and distribute a Modified Version of the Document under the
conditions of sections 2 and 3 above, provided that you release the
Modified Version under precisely this License, with the Modified Version
filling the role of the Document, thus licensing distribution and
modification of the Modified Version to whoever possesses a copy of it. In
addition, you must do these things in the Modified Version:
* Use in the Title Page (and on the covers, if any) a title distinct
from that of the Document, and from those of previous versions (which
should, if there were any, be listed in the History section of the
Document). You may use the same title as a previous version if the
original publisher of that version gives permission.
* List on the Title Page, as authors, one or more persons or entities
responsible for authorship of the modifications in the Modified
Version, together with at least five of the principal authors of the
Document (all of its principal authors, if it has less than five).
* State on the Title page the name of the publisher of the Modified
Version, as the publisher.
* Preserve all the copyright notices of the Document.
* Add an appropriate copyright notice for your modifications adjacent to
the other copyright notices.
* Include, immediately after the copyright notices, a license notice
giving the public permission to use the Modified Version under the
terms of this License, in the form shown in the Addendum below.
* Preserve in that license notice the full lists of Invariant Sections
and required Cover Texts given in the Document's license notice.
* Include an unaltered copy of this License.
* Preserve the section entitled "History", and its title, and add to
it an item stating at least the title, year, new authors, and
publisher of the Modified Version as given on the Title Page. If there
is no section entitled "History" in the Document, create one stating
the title, year, authors, and publisher of the Document as given on
its Title Page, then add an item describing the Modified Version as
stated in the previous sentence.
* Preserve the network location, if any, given in the Document for
public access to a Transparent copy of the Document, and likewise the
network locations given in the Document for previous versions it was
based on. These may be placed in the "History" section. You may omit
a network location for a work that was published at least four years
before the Document itself, or if the original publisher of the
version it refers to gives permission.
* In any section entitled "Acknowledgements" or "Dedications",
preserve the section's title, and preserve in the section all the
substance and tone of each of the contributor acknowledgements and/or
dedications given therein.
* Preserve all the Invariant Sections of the Document, unaltered in
their text and in their titles. Section numbers or the equivalent are
not considered part of the section titles.
* Delete any section entitled "Endorsements". Such a section may not
be included in the Modified Version.
* Do not retitle any existing section as "Endorsements" or to conflict
in title with any Invariant Section.
If the Modified Version includes new front-matter sections or appendices
that qualify as Secondary Sections and contain no material copied from the
Document, you may at your option designate some or all of these sections
as invariant. To do this, add their titles to the list of Invariant
Sections in the Modified Version's license notice. These titles must be
distinct from any other section titles.
You may add a section entitled "Endorsements", provided it contains
nothing but endorsements of your Modified Version by various parties - for
example, statements of peer review or that the text has been approved by
an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a
passage of up to 25 words as a Back-Cover Text, to the end of the list of
Cover Texts in the Modified Version. Only one passage of Front-Cover Text
and one of Back-Cover Text may be added by (or through arrangements made
by) any one entity. If the Document already includes a cover text for the
same cover, previously added by you or by arrangement made by the same
entity you are acting on behalf of, you may not add another; but you may
replace the old one, on explicit permission from the previous publisher
that added the old one.
The author(s) and publisher(s) of the Document do not by this License give
permission to use their names for publicity for or to assert or imply
endorsement of any Modified Version.
13.5 Combining Documents
You may combine the Document with other documents released under this
License, under the terms defined in section 4 above for modified versions,
provided that you include in the combination all of the Invariant Sections
of all of the original documents, unmodified, and list them all as
Invariant Sections of your combined work in its license notice.
The combined work need only contain one copy of this License, and multiple
identical Invariant Sections may be replaced with a single copy. If there
are multiple Invariant Sections with the same name but different contents,
make the title of each such section unique by adding at the end of it, in
parentheses, the name of the original author or publisher of that section
if known, or else a unique number. Make the same adjustment to the section
titles in the list of Invariant Sections in the license notice of the
combined work.
In the combination, you must combine any sections entitled "History" in
the various original documents, forming one section entitled "History";
likewise combine any sections entitled "Acknowledgements", and any
sections entitled "Dedications". You must delete all sections entitled
"Endorsements."
13.6 Collections of Documents
You may make a collection consisting of the Document and other documents
released under this License, and replace the individual copies of this
License in the various documents with a single copy that is included in
the collection, provided that you follow the rules of this License for
verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute
it individually under this License, provided you insert a copy of this
License into the extracted document, and follow this License in all other
respects regarding verbatim copying of that document.
13.7 Aggregation With Independent Works
A compilation of the Document or its derivatives with other separate and
independent documents or works, in or on a volume of a storage or
distribution medium, does not as a whole count as a Modified Version of
the Document, provided no compilation copyright is claimed for the
compilation. Such a compilation is called an "aggregate", and this
License does not apply to the other self-contained works thus compiled
with the Document, on account of their being thus compiled, if they are
not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies
of the Document, then if the Document is less than one quarter of the
entire aggregate, the Document's Cover Texts may be placed on covers that
surround only the Document within the aggregate. Otherwise they must
appear on covers around the whole aggregate.
13.8 Translation
Translation is considered a kind of modification, so you may distribute
translations of the Document under the terms of section 4. Replacing
Invariant Sections with translations requires special permission from
their copyright holders, but you may include translations of some or all
Invariant Sections in addition to the original versions of these Invariant
Sections. You may include a translation of this License provided that you
also include the original English version of this License. In case of a
disagreement between the translation and the original English version of
this License, the original English version will prevail.
13.9 Termination
You may not copy, modify, sublicense, or distribute the Document except as
expressly provided for under this License. Any other attempt to copy,
modify, sublicense or distribute the Document is void, and will
automatically terminate your rights under this License. However, parties
who have received copies, or rights, from you under this License will not
have their licenses terminated so long as such parties remain in full
compliance.
13.10 Future Revisions of This License
The Free Software Foundation may publish new, revised versions of the GNU
Free Documentation License from time to time. Such new versions will be
similar in spirit to the present version, but may differ in detail to
address new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If
the Document specifies that a particular numbered version of this License
"or any later version" applies to it, you have the option of following the
terms and conditions either of that specified version or of any later
version that has been published (not as a draft) by the Free Software
Foundation. If the Document does not specify a version number of this
License, you may choose any version ever published (not as a draft) by the
Free Software Foundation.
ADDENDUM: How to use this License for your documents
To use this License in a document you have written, include a copy of the
License in the document and put the following copyright and license
notices just after the title page:
Copyright © YEAR YOUR NAME. Permission is granted to copy, distribute
and/or modify this document under the terms of the GNU Free
Documentation License, Version 1.1 or any later version published by
the Free Software Foundation; with the Invariant Sections being LIST
THEIR TITLES, with the Front-Cover Texts being LIST, and with the
Back-Cover Texts being LIST. A copy of the license is included in the
section entitled "GNU Free Documentation License".
If you have no Invariant Sections, write "with no Invariant Sections"
instead of saying which ones are invariant. If you have no Front-Cover
Texts, write "no Front-Cover Texts" instead of "Front-Cover Texts being
LIST"; likewise for Back-Cover Texts.
If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of free
software license, such as the GNU General Public License, to permit their
use in free software.
About this document ...
Aspell Devel Docs
This document was generated using the LaTeX2HTML translator Version 2002
(1.62)
Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning
Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department,
Macquarie University, Sydney.
The command line arguments were:
latex2html -split 3 -toc_depth 3 -dir dev-html -long_titles 2 -local_icons
-show_section_numbers devel.tex
The translation was initiated by Kevin Atkinson on 2002-11-04
--------------------------------------------------------------------------
* Contents
* Notes
* Copyright
* 1 Style Guidelines
* 2 C++ Standard Library
* 3 Templates
* 4 Error Handling
* 5 Source Code Layout
* 6 Strings
+ 6.1 String
+ 6.2 ParmString
+ 6.3 CharVector
* 7 Smart Pointers
+ 7.1 CopyPtr
+ 7.2 ClonePtr
+ 7.3 StackPtr
+ 7.4 GenericCopyPtr
* 8 I/O
+ 8.1 IStream/OStream
+ 8.2 FStream
+ 8.3 Standard Streams
* 9 Config Class
* 10 Filter Interface
+ 10.1 Overview
+ 10.2 Adding a New Filter
+ 10.3 IndividualFilter class
+ 10.4 Constructor Function
+ 10.5 Config Options
+ 10.6 Makefile Modifications
+ 10.7 New_filter Modifications
* 11 Data Structures
+ 11.1 Vector
+ 11.2 BasicList
+ 11.3 StringMap
+ 11.4 Hash Tables
+ 11.5 BlockSList
* 12 Mk-Src Script
+ 12.1 mk-src.in
+ 12.2 MkSrc::Info
o %info
o %types
o %methods
+ 12.3 MkSrc::Util
+ 12.4 MkSrc::Read
+ 12.5 MKSrc::Create
+ 12.6 Code Generation Modes
+ 12.7 MkSrc::CcHelper
* 13 GNU Free Documentation License
+ Preamble
+ 13.1 Applicability and Definitions
+ 13.2 Verbatim Copying
+ 13.3 Copying in Quantity
+ 13.4 Modifications
+ 13.5 Combining Documents
+ 13.6 Collections of Documents
+ 13.7 Aggregation With Independent Works
+ 13.8 Translation
+ 13.9 Termination
+ 13.10 Future Revisions of This License
+ ADDENDUM: How to use this License for your documents
* About this document ...
--------------------------------------------------------------------------
next_inactive up previous
Kevin Atkinson 2002-11-04