impl type
is one of:
Copyright (c) 2002
Kevin Atkinson
kevina@gnu.org
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 (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".
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.
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.
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.
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.
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''.
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:
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.
Smart pointers are used extensively in Aspell to avoid simplify memory management tasks and to avoid memory leaks.
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.
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''.
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.
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''.
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.
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.
Defined in ``fstream.hpp''
CIN/COUT/CERR. Defined in ``iostream.hpp''.
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''
In Aspell there are 5 types of filters:
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.
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.
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:
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.
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.
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.
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.
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.
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''.
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''
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''
BlockSList provided a pool of nodes which can be used for singly linked lists. It is defined in ``block_slist.hpp''.
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.
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
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 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 is used for holding the "methods" information
This module contains various useful utility functions:
Returns 0.
Returns 1.
Apply EXPR to each item in LIST and than concatenate the result into a string
Returns true if LIST contains at least one of STR.
Convert STR to all uppercase and substitute spaces with underscores.
Convert STR to all lowercase and substitute spaces with underscores.
Convert STR to mixed case where each new word startes with a uppercase letter. For example "feed me" would become "FeedMe".
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
Create a source file.
Required Parms: type, dir, name, data Boolean Parms: header, cxx Optional Parms: namespace (required if cxx), pre_ext, accum
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.
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
Helper functions used by interface generation code:
.
.
Creates a function prototype
Parms can be any of:
mode: code generation mode
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
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 a C comment out of DESC optionally indenting it LEVEL spaces.
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
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.
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.
Create the phototype for a C++ method.
Parms is one of:
mode: code generation mode
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.
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.
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.
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.
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.
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:
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.
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.''
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.
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.
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.
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.
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.
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.
This document was generated using the LaTeX2HTML translator Version 2002-2-1 (1.70)
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 2003-10-11