%
%   $Id: ref.tex,v 1.52 2005/03/13 00:31:55 michael Exp $
%   This file is part of the FPC documentation.
%   Copyright (C) 1997, by Michael Van Canneyt
%
%   The FPC documentation is free text; you can redistribute it and/or
%   modify it under the terms of the GNU Library General Public License as
%   published by the Free Software Foundation; either version 2 of the
%   License, or (at your option) any later version.
%
%   The FPC Documentation is distributed in the hope that it will be useful,
%   but WITHOUT ANY WARRANTY; without even the implied warranty of
%   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
%   Library General Public License for more details.
%
%   You should have received a copy of the GNU Library General Public
%   License along with the FPC documentation; see the file COPYING.LIB.  If not,
%   write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
%   Boston, MA 02111-1307, USA.
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Preamble.
\input{preamble.inc}
\begin{latexonly}
  \ifpdf
    \hypersetup{
           pdfauthor={Michael Van Canneyt},
           pdftitle={Free Pascal Language Reference Guide},
           pdfsubject={Free Pascal Reference guide},
           pdfkeywords={Free Pascal, Language}
           }
  \fi
\end{latexonly}

%
% Settings
%
\makeindex
%
% Syntax style
%
\usepackage{syntax}
\input{syntax/diagram.tex}
%
% Start of document.
%
\begin{document}
\title{Free Pascal\\ Reference guide}
\docdescription{Reference guide for Free Pascal, version \fpcversion}
\docversion{3.2.2}
\input{date.inc}
\author{Micha\"el Van Canneyt}
\maketitle
\tableofcontents
\newpage
\listoftables
\newpage


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Introduction
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% About this guide
\section*{About this guide}
This document serves as the reference for the Pascal language as implemented
by the \fpc compiler. It describes all Pascal constructs supported by
\fpc, and lists all supported data types. It does not, however, give a
detailed explanation of the Pascal language: it is not a tutorial.
The aim is to list which Pascal constructs are supported, and to show
where the \fpc implementation differs from the \tp or \delphi
implementations.

The \tp and \delphi Pascal compilers introduced various features in the
Pascal language. The Free Pascal compiler emulates these compilers in the
appropriate mode of the compiler: certain features are available only
if the compiler is switched to the appropriate mode. When required for
a certain feature, the use of the \var{-M} command-line switch or
\var{\{\$MODE \}} directive will be indicated in the text. More information
about the various modes can be found in the user's manual and the
programmer's manual.

Earlier versions of this document also contained the reference documentation
of the \file{system} unit and \file{objpas} unit. This has been moved to the
RTL reference guide.

\subsection*{Notations}
Throughout this document, we will refer to functions, types and variables
with \var{typewriter} font. Files are referred to with a sans font:
\file{filename}.

\subsection*{Syntax diagrams}
All elements of the Pascal language are explained in \index{Syntax diagrams}syntax diagrams.
Syntax diagrams are like flow charts. Reading a syntax diagram means getting
from the left side to the right side, following the arrows.
When the right side of a syntax diagram is reached, and it ends with a single
arrow, this means the syntax diagram is continued on the next line. If
the line ends on two arrows pointing to each other, then the diagram is
ended.

Syntactical elements are written like this
\begin{mysyntdiag}
\synt{syntactical\ elements\ are\ like\ this}
\end{mysyntdiag}
Keywords which must be typed exactly as in the diagram:
\begin{mysyntdiag}
\lit*{keywords\ are\ like\ this}
\end{mysyntdiag}
When something can be repeated, there is an arrow around it:
\begin{mysyntdiag}
\begin{rep}[b] \synt{this\ can\ be\ repeated} \\ \end{rep}
\end{mysyntdiag}
When there are different possibilities, they are listed in rows:
\begin{mysyntdiag}
\begin{stack}
\synt{First\ possibility} \\
\synt{Second\ possibility}
\end{stack}
\end{mysyntdiag}
Note, that one of the possibilities can be empty:
\begin{mysyntdiag}
\begin{stack}\\
\synt{First\ possibility} \\
\synt{Second\ possibility}
\end{stack}
\end{mysyntdiag}
This means that both the first or second possibility are optional.
Of course, all these elements can be combined and nested.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% About the pascal language
\section*{About the Pascal language}
The language Pascal was originally designed by Niklaus Wirth around 1970.
It has evolved significantly since that day, with a lot of contributions
by the various compiler constructors (Notably: Borland). The basic elements
have been kept throughout the years:
\begin{itemize}
\item Easy syntax, rather verbose, yet easy to read. Ideal for teaching.
\item Strongly typed.
\item Procedural.
\item Case insensitive.
\item Allows nested procedures.
\item Easy input/output routines built-in.
\end{itemize}

The \tp and \delphi Pascal compilers introduced various features in the
Pascal language, most notably easier string handling and object orientedness.
The Free Pascal compiler initially emulated most of \tp and later on
\delphi. It emulates these compilers in the appropriate mode of the compiler:
certain features are available only if the compiler is switched to the appropriate
mode. When required for a certain feature, the use of the \var{-M} command-line
switch or \var{\{\$MODE \}} directive will be indicated in the text. More information
about the various modes can be found in the user's manual and the
programmer's manual.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% The Pascal language

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Pascal Tokens}
\index{Tokens}
Tokens are the basic lexical building blocks of source code: they are the
``words'' of the language: characters are combined into tokens according to
the rules of the programming language. There are five classes of tokens:
\begin{description}
\item[reserved words] These are words which have a fixed meaning in the
language. They cannot be changed or redefined.
\item[identifiers] These are names of symbols that the programmer defines.
They can be changed and re-used. They are subject to the scope rules of the
language.
\item[operators] These are usually symbols for mathematical or other
operations: +, -, * and so on.
\item[separators] This is usually white-space.
\item[constants] Numerical or character constants are used to denote actual
values in the source code, such as 1 (integer constant) or 2.3 (float
constant) or ``String constant'' (a string: a piece of text).
\end{description}

In this chapter we describe all the Pascal reserved words, as well as the
various ways to denote strings, numbers, identifiers etc.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Symbols
\section{Symbols}
\index{Symbols}\index{Tokens!Symbols}
Free Pascal allows all characters, digits and some special character symbols
in a Pascal source file.
\input{syntax/symbol.syn}
The following characters have a special meaning:
\begin{verbatim}
' + - * / = < > [ ] . , ( ) : ^ @ { } $ # & %
\end{verbatim}
and the following character pairs too:
\begin{verbatim}
<< >> ** <> >< <= >= := += -= *= /= (* *) (. .) //
\end{verbatim}
When used in a range specifier, the character pair \var{(.} is equivalent to
the left square bracket \var{[}. Likewise, the character pair \var{.)} is
equivalent to the right square bracket \var{]}.
When used for comment delimiters, the character pair \var{(*} is equivalent
to the  left brace \var{\{} and the character pair \var{*)} is equivalent
to the right brace \var{\}}.
These character pairs retain their normal meaning in string expressions.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Comments
\section{Comments}
\index{Comments}\index{Tokens!Comments}\keywordlink{Comment}
Comments are pieces of the source code which are completely discarded by the
compiler. They exist only for the benefit of the programmer, so he can
explain certain pieces of code. For the compiler, it is as if the comments
were not present.

The following piece of code demonstrates a comment:
\begin{verbatim}

(* My beautiful function returns an interesting result *)
Function Beautiful : Integer;

\end{verbatim}
The use of \var{(*} and \var{*)} as comment delimiters dates from the very
first days of the Pascal language. It has been replaced mostly by the
use of \var{\{} and \var{\}} as comment delimiters, as in the following
example:
\begin{verbatim}

{ My beautiful function returns an interesting result }
Function Beautiful : Integer;

\end{verbatim}
The comment can also span multiple lines:
\begin{verbatim}

{
   My beautiful function returns an interesting result,
   but only if the argument A is less than B.
}
Function Beautiful (A,B : Integer): Integer;
\end{verbatim}
Single line comments can also be made with the \var{//} delimiter:
\begin{verbatim}

// My beautiful function returns an interesting result
Function Beautiful : Integer;

\end{verbatim}
The comment extends from the // character till the end of the line.
This kind of comment was introduced by Borland in the Delphi Pascal
compiler.

\fpc supports the use of nested comments. The following constructs are valid
comments:
\begin{verbatim}
(* This is an old style comment *)
{  This is a Turbo Pascal comment }
// This is a Delphi comment. All is ignored till the end of the line.
\end{verbatim}
The following are valid ways of nesting comments:
\begin{verbatim}
{ Comment 1 (* comment 2 *) }
(* Comment 1 { comment 2 } *)
{ comment 1 // Comment 2 }
(* comment 1 // Comment 2 *)
// comment 1 (* comment 2 *)
// comment 1 { comment 2 }
\end{verbatim}
The last two comments {\em must} be on one line. The following two will give
errors:
\begin{verbatim}
 // Valid comment { No longer valid comment !!
    }
\end{verbatim}
and
\begin{verbatim}
 // Valid comment (* No longer valid comment !!
    *)
\end{verbatim}
The compiler will react with a ``invalid character'' error when it encounters
such constructs, regardless of the \var{-Mtp} switch.

\begin{remark}
In \var{TP} and \var{Delphi} mode, nested comments are not allowed, for
maximum compatibility with existing code for those compilers.
\end{remark}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Reserved words
\section{Reserved words}
\index{Reserved words}\index{Tokens!Reserved words}
Reserved words are part of the Pascal language, and as such, cannot be redefined
by the programmer. Throughout the syntax diagrams they will be denoted using
a {\sffamily\bfseries bold} typeface. Pascal is not case sensitive so the compiler
will accept any combination of upper or lower case letters for reserved words.

We make a distinction between \tp and \delphi reserved words. In \var{TP} mode,
only the \tp reserved words are recognized, but the \delphi ones can be redefined.
By default, \fpc recognizes the \delphi reserved words.

\subsection{Turbo Pascal reserved words}
\index{Reserved words!Turbo Pascal}
The following keywords exist in \tp mode
\begin{multicols}{4}
\begin{verbatim}
absolute
and
array
asm
begin
case
const
constructor
destructor
div
do
downto
else
end
file
for
function
goto
if
implementation
in
inherited
inline
interface
label
mod
nil
not
object
of
operator
or
packed
procedure
program
record
reintroduce
repeat
self
set
shl
shr
string
then
to
type
unit
until
uses
var
while
with
xor
\end{verbatim}
\end{multicols}

\subsection{Object Pascal reserved words}
\index{Reserved words!Delphi}
The reserved words of Object Pascal (used in \var{Delphi} or \var{Objfpc} mode)
are the same as the \tp ones, with the following additional keywords:
\begin{multicols}{4}
\begin{verbatim}
as
class
dispinterface
except
exports
finalization
finally
initialization
inline
is
library
on
out
packed
property
raise
resourcestring
threadvar
try
\end{verbatim}
\end{multicols}

\subsection{Modifiers}
\index{Modifiers}\index{Reserved words!Modifiers}
The following is a list of all modifiers. They are not exactly reserved
words in the sense that they can be used as identifiers, but in specific
places, they have a special meaning for the compiler, i.\,e., the compiler
considers them as part of the Pascal language.
\begin{multicols}{4}
\begin{verbatim}
absolute
abstract
alias
assembler
bitpacked
break
cdecl
continue
cppdecl
cvar
default
deprecated
dynamic
enumerator
experimental
export
external
far
far16
forward
generic
helper
implements
index
interrupt
iocheck
local
message
name
near
nodefault
noreturn
nostackframe
oldfpccall
otherwise
overload
override
pascal
platform
private
protected
public
published
read
register
reintroduce
result
safecall
saveregisters
softfloat
specialize
static
stdcall
stored
strict
unaligned
unimplemented
varargs
virtual
winapi
write
\end{verbatim}
\end{multicols}
\begin{remark}
Predefined types such as \var{Byte}, \var{Boolean} and constants
such as \var{maxint} are {\em not} reserved words. They are
identifiers, declared in the system unit. This means that these types
can be redefined in other units. The programmer is however not
encouraged to do this, as it will cause a lot of confusion.
\end{remark}

\begin{remark}
As of version 2.5.1 it is possible to use reserved words as identifiers by escaping them with a
\& sign. This means that the following is possible
\begin{verbatim}
var
  &var : integer;

begin
  &var:=1;
  Writeln(&var);
end.
\end{verbatim}
however, it is not recommended to use this feature in new code, as it makes code less readable.
It is mainly intended to fix old code when the list of reserved words changes and encompasses a
word that was not yet reserved (See also \sees{identifiers}).
\end{remark}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Identifiers
\section{Identifiers}
\label{se:identifiers}
\index{Identifiers}\index{Tokens!Identifiers}
Identifiers denote programmer defined names for specific constants, types,
variables, procedures and functions, units, and programs. All programmer
defined names in the source code~-- excluding reserved words~-- are designated as
identifiers.

Identifiers consist of between 1 and 127 significant characters (letters, digits and
the underscore character), of which the first must be a letter (a--z or A--Z),
or an underscore (\var{\_}).
The following diagram gives the basic syntax for identifiers.
\input{syntax/identifier.syn}
Like Pascal reserved words, identifiers are case insensitive, that is, both
\begin{verbatim}
  myprocedure;
\end{verbatim}
and
\begin{verbatim}
 MyProcedure;
\end{verbatim}
refer to the same procedure.

\begin{remark}
As of version 2.5.1 it is possible to specify a reserved word as an identifier by
prepending it with an ampersand (\&). This means that the following is possible:
\begin{verbatim}
program testdo;

procedure &do;

begin
end;

begin
  &do;
end.
\end{verbatim}
The reserved word \var{do} is used as an identifier for the declaration as
well as the invocation of the procedure \var{do}.
\end{remark}

\section{Hint directives}
\index{Hint directives}\index{Directives!Hint}
Most identifiers (constants, variables, functions or methods, properties) can have a
hint directive appended to their definition:

\input{syntax/hintdirective.syn}
Whenever an identifier marked with a hint directive is  later encountered by
the compiler, then a warning will be displayed, corresponding to the
specified hint.
\begin{description}
\item[deprecated] The use of this identifier is deprecated, use an
alternative instead. The deprecated keyword can be followed by a string
constant with a message. The compiler will show this message whenever the
identifier is encountered. \keywordlink{deprecated}
\item[experimental] The use of this identifier is experimental: this can be
used to flag new features that should be used with caution.
\keywordlink{experimental}
\item[platform] This is a platform-dependent identifier: it may not be
defined on all platforms. \keywordlink{platform}
\item[unimplemented] This should be used on functions and procedures only.
It should be used to signal that a particular feature has not yet been
implemented. \keywordlink{unimplemented}
\end{description}

The following are examples:
\begin{verbatim}
Const
  AConst = 12 deprecated;

var
  p : integer platform;

Function Something : Integer; experimental;

begin
  Something:=P+AConst;
end;

begin
  Something;
end.
\end{verbatim}
This would result in the following output:
\begin{verbatim}
testhd.pp(11,15) Warning: Symbol "p" is not portable
testhd.pp(11,22) Warning: Symbol "AConst" is deprecated
testhd.pp(15,3) Warning: Symbol "Something" is experimental
\end{verbatim}

Hint directives can follow all kinds of identifiers:
units, constants, types, variables, functions, procedures and methods.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Numbers
\section{Numbers}
\index{Numbers}\index{Tokens!Numbers}\index{Numbers!Real}\keywordlink{numbers}
Numbers are by default denoted in decimal notation.
Real (or decimal) numbers are written using engineering or scientific
notation (e.\,g. \var{0.314E1}).

For integer type constants, \fpc supports four formats:
\begin{enumerate}
\item Normal, decimal format (base 10). This is the standard
format.\index{Numbers!Decimal}
\item Hexadecimal format (base 16), in the same way as \tp does.
To specify a constant value in hexadecimal format, prepend it with a dollar
sign (\var{\$}). Thus, the hexadecimal \var{\$FF} equals 255 decimal.
Note that case is insignificant when using hexadecimal constants.\index{Numbers!Hexadecimal}
\item As of version 1.0.7, Octal format (base 8) is also supported.
To specify a constant in octal format, prepend it with an ampersand (\&).
For instance 15 is specified in octal notation as
\var{\&17}.\index{Numbers!Octal}
\item Binary notation (base 2). A binary number can be specified
by preceding it with a percent sign (\var{\%}). Thus, \var{255} can be
specified in binary notation as \var{\%11111111}.\index{Numbers!Binary}
\end{enumerate}
The following diagrams show the syntax for numbers.
\input{syntax/numbers.syn}


\begin{remark}
Octal and Binary notation are not supported in \var{TP} or \var{Delphi}
compatibility mode.
\end{remark}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Labels
\section{Labels}
\index{Labels} \keywordlink{label}
A label is a name for a location in the source code to which can be
jumped to from another location with a \var{goto} statement. A Label is a
standard identifier or a digit sequence.
\keywordlink{label}
\input{syntax/label.syn}
\begin{remark}
The \var{-Sg} or \var{-Mtp} switches must be specified before
labels can be used. By default, \fpc doesn't support \var{label} and
\var{goto} statements. The \var{\{\$GOTO ON\}} directive can also be used
to allow use of labels and the goto statement.
\end{remark}
The following are examples of valid labels:
\begin{verbatim}
Label
  123,
  abc;
\end{verbatim}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Character strings
\section{Character strings}
\index{String}\index{Constants!String}\index{Tokens!Strings}
A character string (or string for short) is a sequence of zero or more
characters (byte sized), enclosed in single quotes, and on a single
line of the program source code: no literal carriage return or linefeed
characters can appear in the string.

A character set with nothing between the quotes (\var{'{}'}) is an empty string.
\input{syntax/string.syn}
The string consists of standard, 8-bit ASCII characters or Unicode (normally
UTF-8 encoded) characters. The \var{control string} can be used to specify
characters which cannot be typed on a keyboard, such as \var{\#27} for
the escape character.

The single quote character can be embedded in the string by typing it twice.
The C construct of escaping characters in the string (using a backslash)
is not supported in Pascal.

The following are valid string constants:
\begin{verbatim}
  'This is a pascal string'
  ''
  'a'
  'A tabulator character: '#9' is easy to embed'
\end{verbatim}
The following is an invalid string:
\begin{verbatim}
  'the string starts here
   and continues here'
\end{verbatim}
The above string must be typed as:
\begin{verbatim}
  'the string starts here'#13#10'   and continues here'
\end{verbatim}
or
\begin{verbatim}
  'the string starts here'#10'   and continues here'
\end{verbatim}
on unices (including Mac OS X), and as
\begin{verbatim}
  'the string starts here'#13'   and continues here'
\end{verbatim}
on a classic Mac-like operating system.

It is possible to use other character sets in strings: in that case the
codepage of the source file must be specified with the \var{\{\$CODEPAGE XXX\}}
directive or with the \var{-Fc} command line option for the compiler. In that
case the characters in a string will be interpreted as characters from the
specified codepage.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Constants
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Constants}
\index{Constants} \keywordlink{const}
Just as in \tp, \fpc supports both ordinary and typed constants. They are
declared in a constant declaration block in a unit, program or class, function or
procedure declaration (\sees{blocks}).

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Ordinary constants
\section{Ordinary constants}
\index{Constants!Ordinary} \keywordlink{const}
Ordinary constants declarations are constructed using an identifier name
followed by an ``='' token, and followed by an optional expression consisting
of legal combinations of numbers, characters, boolean values or enumerated
values as appropriate. The following syntax diagram shows how to construct
a legal declaration of an ordinary constant.

\input{syntax/const.syn}

The compiler must be able to evaluate the expression in a constant
declaration at compile time.  This means that most of the functions
in the Run-Time library cannot be used in a constant
declaration.\index{Operators}
Operators such as \var{+, -, *, /, not, and, or, div, mod, ord, chr,
sizeof, pi, int, trunc, round, frac, odd} can be used, however.
For more information on expressions, see \seec{Expressions}.

When a previously declared ordinary constant is used in the code, the compiler will insert
the actual value of the constant instead of the constant name. That is, the
following two pieces of code are entirely equivalent:

\begin{verbatim}
Const
  One = 1;

begin
  Writeln(One);
end.
\end{verbatim}
The above will produce the same code as if one had written:
\begin{verbatim}
begin
  Writeln(1);
end.
\end{verbatim}

Only constants of the following types can be declared:

\begin{itemize}
\item Ordinal types
\item Set types
\item Pointer types (but the only allowed value is \var{Nil}).
\item Real types
\item \var{Char},
\item \var{String}
\end{itemize}
\index{Constants!String}

The following are all valid constant declarations:
\begin{verbatim}
Const
  e = 2.7182818;  { Real type constant. }
  a = 2;          { Ordinal (Integer) type constant. }
  c = '4';        { Character type constant. }
  s = 'This is a constant string'; {String type constant.}
  sc = chr(32)
  ls = SizeOf(Longint);
  P = Nil;
  Ss = [1,2];
\end{verbatim}
Assigning a value to an ordinary constant is not permitted.
Thus, given the previous declaration, the following will result
in a compiler error:
\begin{verbatim}
  s := 'some other string';
\end{verbatim}
For string constants, the type of the string is dependent on some compiler
switches. If a specific type is desired, a typed constant should be used,
as explained in the following section.

Prior to version 1.9, \fpc did not correctly support 64-bit constants. As
of version 1.9, 64-bit constants can be specified.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Typed constants
\section{Typed constants}
\label{se:typedconstants}
\index{Constants!Typed}\index{Variables!Initialized}
Sometimes it is necessary to specify the type of a constant, for instance
for constants of complex structures (defined later in the manual).
Their definition is quite simple.

\input{syntax/tconst.syn}

Contrary to ordinary constants, a value can be assigned to them at
run-time.  This is an old concept from \tp, which has been
replaced with  support for initialized variables: For a detailed
description, see \sees{initializedvars}.

Support for assigning values to typed constants is controlled by the
\var{\{\$J\}} directive: it can be switched off, but is on by default
(for \tp compatibility). Initialized variables are always allowed.

\begin{remark}
It should be stressed that typed constants are automatically initialized at program start.
This is also true for \emph{local} typed constants and initialized variables.
Local typed constants are also initialized at program start. If their value was
changed during previous invocations of the function, they will retain their
changed value, i.\,e. they are not initialized each time the function is invoked.
\end{remark}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% resource strings
\section{Resource strings}
\label{se:resourcestring}\index{Resourcestring}\index{Const}\index{Const!String}\keywordlink{resourcestring}
A special kind of constant declaration block is the \var{Resourcestring}
block. Resourcestring declarations are much like constant string
declarations: resource strings act as constant strings, but they
can be localized by means of a set of special routines in the
\file{objpas} unit. A resource string declaration block
is only allowed in the \var{Delphi} or \var{Objfpc} modes.

The following is an example of a resourcestring definition:
\begin{verbatim}
Resourcestring

  FileMenu = '&File...';
  EditMenu = '&Edit...';
\end{verbatim}
All string constants defined in the resourcestring section are stored
in special tables. The strings in these tables can be manipulated
at runtime with some special mechanisms in the \file{objpas} unit.

Semantically, the strings act like ordinary constants; It is not allowed
to assign values to them (except through the special mechanisms in the
\file{objpas} unit). However, they can be used in assignments or expressions as
ordinary string constants. The main use of the resourcestring section is
to provide an easy means of internationalization.

More on the subject of resourcestrings can be found in the \progref, and
in the \file{objpas} unit reference.

\begin{remark}
Note that a resource string which is given as an expression will not change if
the parts of the expression are changed:
\begin{verbatim}
resourcestring
  Part1 = 'First part of a long string.';
  Part2 = 'Second part of a long string.';
  Sentence = Part1+' '+Part2;
\end{verbatim}
If the localization routines translate \var{Part1} and \var{Part2}, the
\var{Sentence} constant will not be translated automatically: it has a
separate entry in the resource string tables, and must therefore be
translated separately. The above construct simply says that the
initial value of \var{Sentence} equals \var{Part1+' '+Part2}.
\end{remark}

\begin{remark}
Likewise, when using resource strings in a constant array, only the initial
values of the resource strings will be used in the array: when the
individual constants are translated, the elements in the array will retain
their original value.
\begin{verbatim}
resourcestring
  Yes = 'Yes.';
  No = 'No.';

Var
  YesNo : Array[Boolean] of string = (No,Yes);
  B : Boolean;

begin
  Writeln(YesNo[B]);
end.
\end{verbatim}
This will print ``Yes.'' or ``No.'' depending on the value of B, even if the
constants Yes and No have been localized by some localization mechanism.
\end{remark}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Types
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Types}
\index{Types}
All variables have a type. \fpc supports the same basic types as \tp, with
some extra types from \delphi as well as some of its own.

The programmer can declare his own types, which is in essence defining an identifier
that can be used to denote this custom type when declaring variables further
in the source code.\index{Type}\keywordlink{type} Declaring a type happens
in a \var{Type} block (\sees{blocks}), which is a collection of type declarations, separated
by semicolons:
\input{syntax/typedecl.syn}
There are eight major kinds of types:
\input{syntax/type.syn}
Each of these cases will be examined separately.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Base types
\section{Base types}
\index{Types!Base}
The base or simple types of \fpc are the \delphi types.
We will discuss each type separately.
\input{syntax/typesim.syn}
\subsection{Ordinal types}
\index{Types!Ordinal}
With the exception of floating point value types, all base types are ordinal
types. Ordinal types have the following characteristics:
\begin{enumerate}
\item Ordinal types are countable and ordered, i.\,e. it is, in principle,
possible to start counting them one by one, in a specified order.
This property allows the operation of functions as \var{Inc}, \var{Ord},
\var{Dec}
on ordinal types to be defined.
\item Ordinal values have a smallest possible value. Trying to apply the
\var{Pred} function on the smallest possible value will generate a range
check error if range checking is enabled.
\item Ordinal values have a largest possible value. Trying to apply the
\var{Succ} function on the largest possible value will generate a range
check error if range checking is enabled.
\end{enumerate}

\begin{remark}
\var{Int64} and \var{QWord} are considered ordinal types on 64-bit CPUs. On 32-bit types
they have some of the characteristics of ordinals, but they cannot be used
e.\,g. in for loops.
\end{remark}

\subsubsection{Integers}
\index{Types!Integer}
\keywordlink{Integer}    
\keywordlink{Shortint}
\keywordlink{SmallInt}   
\keywordlink{Longint}
\keywordlink{Longword}
\keywordlink{Int64}
\keywordlink{Byte}	 
\keywordlink{Word}
\keywordlink{Cardinal}   
\keywordlink{QWord}
\keywordlink{ByteBool}
\keywordlink{WordBool}
\keywordlink{LongBool}
\keywordlink{QWordBool}   
A list of predefined integer types is presented in \seet{integerstyp}.

%\index{Keyword!Integer}
%
\begin{table}[ht]
\caption{Predefined integer types}
\label{tab:integerstyp}
\begin{center}
\begin{tabular}{l}
%\begin{FPCltable}{l}{Predefined integer types}{integerstyp}
Name\\ \hline
Integer \\
Shortint \\
SmallInt \\
Longint \\
Longword \\
Int64 \\
Byte \\
Word \\
Cardinal \\
QWord \\
ByteBool \\
WordBool \\
LongBool \\
QWordBool \\ \hline
\end{tabular}
\end{center}
\end{table}
%\end{FPCltable}
The integer types, and their ranges and sizes, that are predefined in
\fpc are listed in \seet{integersranges}. Please note that
the \var{qword} and \var{int64} types are not true ordinals, so
some Pascal constructs will not work with these two integer types.

\begin{FPCltable}{lcr}{Predefined integer types}{integersranges}
Type & Range & Size in bytes \\ \hline
Byte & 0 .. 255 & 1 \\
Shortint & -128 .. 127 & 1\\
Smallint & -32768 .. 32767 & 2\\
Word & 0 .. 65535 & 2 \\
Integer & either smallint or longint & size 2 or 4 \\
Cardinal & longword  & 4 \\
Longint & -2147483648 .. 2147483647 & 4\\
Longword & 0 .. 4294967295 & 4 \\
Int64 & -9223372036854775808 .. 9223372036854775807 & 8 \\
QWord & 0 .. 18446744073709551615 & 8 \\ \hline
\end{FPCltable}

The \var{integer} type is an alias to the smallint type in the default\keywordlink{integer}
\fpc mode. It is an alias for the longint type in either Delphi or ObjFPC
mode. The \var{cardinal} type is currently always mapped to the
longword type.

\begin{remark}
The compiler decides on the type of an integer constant based on the value:
An integer constant gets the smallest possible signed type. The first match
in \seet{integerconsttypemapping} is used.
\begin{FPCltable}{rl}{Integer constant type mapping}{integerconsttypemapping}
Range &  Type \\ \hline
-128..127 & Shortint \\
128..255 & Byte \\
-32768..32767 & Smallint \\
32768..65535 & Word \\
-2147483648..2147483647 & longint \\
2147483648..4294967295 & Cardinal (longword) \\
-9223372036854775808 .. 9223372036854775807 & Int64 \\ \hline
\end{FPCltable}
That means constants in the range -128..127 are mapped to shortint,
constants in range 128..255 are mapped to byte, etc.
Constants in the range 2147483647..high(cardinal) are parsed as cardinals,
and all decimal constants which do not fit either of the above ranges are parsed
as 64-bit integer constants.
\end{remark}

\begin{remark}
In newer Delphi versions, the \var{longint} type is platform and CPU dependent.
This is not so in FPC, where longint is 32-bit on all platforms.
\end{remark}

%  This IS NOT TRUE, this is a 32-bit compiler, so the integer type
% will always be the same independently the CPU type.
%This is summarized in \seet{integer32type} for 32-bit processors
%(such as Intel 80x86, Motorola 680x0, PowerPC 32-bit, SPARC v7, MIPS32), and
%in \seet{integer64type} for 64-bit processors (such as Alpha AXP,
%SPARC v9 or later, Intel Itanium, MIPS64).

%\begin{FPCltable}{lcr}{\var{Integer} type mapping for 32-bit processors}{integer32type}
%Compiler mode & Range & Size in bytes \\ \hline
%<default> & -32768 .. 32767 & 2\\
%tp & -32768 .. 32767 & 2\\
%Delphi    & -2147483648 .. 2147483647 & 4\\
%ObjFPC    & -2147483648 .. 2147483647 & 4\\
%\end{FPCltable}

%\begin{FPCltable}{lcr}{\var{Integer} type mapping for 64-bit processors}{integer64type}
%Compiler mode & Range & Size in bytes \\ \hline
%<default> & -32768 .. 32767 & 2\\
%tp & -32768 .. 32767 & 2\\
%Delphi    & -9223372036854775808 .. 9223372036854775807 & 8 \\
%ObjFPC   &  -9223372036854775808 .. 9223372036854775807 & 8 \\
%\end{FPCltable}

As a pascal compiler, \fpc does automatic type conversion and upgrading
in expressions where different kinds of integer types are used:
\begin{enumerate}
\item Every platform has a ``native'' integer size, depending on whether the
platform is 8-bit, 16-bit, 32-bit or 64-bit. E.\,g. on AVR this is 8-bit.
\item Every integer smaller than the ``native'' size is promoted to a signed
version of the ``native'' size. Integers equal to the ``native'' size keep their
signedness.
\item The result of binary arithmetic operators (+, -, *, etc.) is determined
in the following way:
\begin{enumerate}
\item If at least one of the operands is larger than the native integer size,
the result is chosen to be the smallest type that encompasses the ranges of
the types of both operands. This means that mixing an unsigned with a
smaller or equal in size signed will produce a signed type that is larger
than both of them.
\item If both operands have the same signedness, the result is the same
type as them. The only exception is subtracting ($-$): in the case of unsigned~$-$~unsigned
subtracting produces a signed result in FPC (as in Delphi, but not in TP7).
\item Mixing signed and unsigned operands of the ``native'' int size produces
a larger signed result. This means that mixing longint and longword on
32-bit platforms will produce an int64. Similarly, mixing byte and shortint on
8-bit platforms (AVR) will produce a smallint.
\end{enumerate}
\end{enumerate}

%
%
\subsubsection{Boolean types}
\index{Types!Boolean}\index{Boolean}\index{Type!Compatibility}
\fpc supports the \var{Boolean} type, with its two predefined possible
values \var{True} and \var{False}. These are the only two values that can be
assigned to a \var{Boolean} type. Of course, any expression that resolves
to a \var{boolean} value, can also be assigned to a boolean type.
\begin{FPCltable}{lll}{Boolean types}{booleantypes}
Name & Size & Ord(True) \\ \hline
Boolean & 1 & 1 \\
Boolean16 & 2 & 1 \\
Boolean32 & 4 & 1 \\
Boolean64 & 8 & 1 \\
ByteBool & 1 & Any nonzero value \\
WordBool & 2 & Any nonzero value \\
LongBool & 4 & Any nonzero value \\
QWordBool & 8 & Any nonzero value \\ \hline
\end{FPCltable}
In addition to the simple \var{Boolean} type, the additional  \var{Boolean16}, \var{Boolean32} and \var{Boolean64}
types exist. These are in fact integer types, which are assignment-compatible with the simple boolean
type. As an integer, the values for \var{True} and \var{False} are 1 and 0.
This can be used to interface with C code that defines a boolean of this size
with values 0 and 1.

To make interfacing with C even easier, \fpc also supports the
\var{ByteBool}, \var{WordBool}, \var{LongBool} and \var{QWordBool} types.
These are of type \var{Byte}, \var{Word}, \var{Longint} or \var{Int64}, but are
again assignment compatible with a \var{Boolean}.
The only difference with the \var{Boolean16/32/64} types is in what values
are considered true or false: The value \var{False} is equivalent to 0 (zero)
and any nonzero value is considered \var{True} when converting to a boolean value.
A boolean value of \var{True} is converted to \var{Not(0)} in case it is assigned to a
variable of type \var{ByteBool}, \var{WordBool}, \var{LongBool} or
\var{QWordBool}.

Assuming \var{B} to be of type \var{Boolean}, the following are valid
assignments:
\begin{verbatim}
 B := True;
 B := False;
 B := 1<>2;  { Results in B := True }
\end{verbatim}
Boolean expressions are also used in conditions.

\begin{remark}
In \fpc, boolean expressions are by default always evaluated in such a
way that when the result is known, the rest of the expression will no longer
be evaluated: this is called short-cut boolean evaluation.

In the following example, the function \var{Func} will never be called,
which may have strange side-effects.
\begin{verbatim}
 ...
 B := False;
 A := B and Func;
\end{verbatim}
Here \var{Func} is a function which returns a \var{Boolean} type.

This behavior is controllable by the \var{\{\$B \}} compiler directive.
\end{remark}

\subsubsection{Enumeration types}
\index{Types!Enumeration}
Enumeration types are supported in \fpc. On top of the \tp
implementation, \fpc allows also a C-style extension of the
enumeration type, where a value is assigned to a particular element of
the enumeration list.
\input{syntax/typeenum.syn}
(see \seec{Expressions} for how to use expressions)
When using assigned enumerated types, the assigned elements must be in
ascending numerical order in the list, or the compiler will complain.
The expressions used in assigned enumerated elements must be known at
compile time.
So the following is a correct enumerated type declaration:
\begin{verbatim}
Type
  Direction = ( North, East, South, West );
\end{verbatim}
A C-style enumeration type looks as follows:
\begin{verbatim}
Type
  EnumType = (one, two, three, forty := 40,fortyone);
\end{verbatim}
or you can use
\begin{verbatim}
Type
  EnumType = (one, two, three, forty = 40,fortyone);
\end{verbatim}
The latter notation is mandatory in mode \var{DELPHI}.

As a result, the ordinal number of \var{forty} is \var{40}, and not \var{3},
as it would be when the \var{':= 40'} wasn't present.
The ordinal value of \var{fortyone} is then {41}, and not \var{4}, as it
would be when the assignment wasn't present. After an assignment in an
enumerated definition the compiler adds 1 to the assigned value to assign to
the next enumerated value.

When specifying such an enumeration type, it is important to keep in mind
that the enumerated elements should be kept in ascending order. The
following will produce a compiler error:
\begin{verbatim}
Type
  EnumType = (one, two, three, forty := 40, thirty := 30);
\end{verbatim}
It is necessary to keep \var{forty} and \var{thirty} in the correct order.
When using enumeration types it is important to keep the following points
in mind:
\begin{enumerate}
\item The \var{Pred} and \var{Succ} functions cannot be used on
this kind of enumeration types. Trying to do this anyhow will result in a
compiler error.
\item Enumeration types are stored using a default, independent of the
actual number of values: the compiler does not try to optimize for space.
This behavior can be changed with the \var{\{\$PACKENUM n\}} compiler
directive, which tells the compiler the minimal number of bytes to be
used for enumeration types.
For instance
\begin{verbatim}
Type
{$PACKENUM 4}
  LargeEnum = ( BigOne, BigTwo, BigThree );
{$PACKENUM 1}
  SmallEnum = ( one, two, three );
Var S : SmallEnum;
    L : LargeEnum;
begin
  WriteLn ('Small enum : ',SizeOf(S));
  WriteLn ('Large enum : ',SizeOf(L));
end.
\end{verbatim}
will, when run, print the following:
\begin{verbatim}
Small enum : 1
Large enum : 4
\end{verbatim}
\end{enumerate}
More information can be found in the \progref, in the compiler directives
section.
%
%
\subsubsection{Subrange types}
\index{Types!Subrange}
A subrange type is a range of values from an ordinal type (the {\em host}
type). To define a subrange type, one must specify its limiting values:
the highest and lowest value of the type.
\input{syntax/typesubr.syn}
Some of the predefined \var{integer} types are defined as subrange types:
\begin{verbatim}
Type
  Longint  = $80000000..$7fffffff;
  Integer  = -32768..32767;
  shortint = -128..127;  
  byte     = 0..255;
  Word     = 0..65535;
\end{verbatim}
Subrange types of enumeration types can also be defined:
\begin{verbatim}
Type
  Days = (monday,tuesday,wednesday,thursday,friday,
          saturday,sunday);
  WorkDays = monday .. friday;
  WeekEnd = Saturday .. Sunday;
\end{verbatim}

%
\subsubsection{Character types}
\index{Types!Char}
A character type is also an ordinal type: characters are ordered, can be
counted. There are 2 character types:
\begin{description}
\item[AnsiChar] This is a 1-byte character. 
The interpretation of the character depends on the codepage.
\item[WideChar] This is a 2-byte character. The interpretation of the
character depends on the codepage.
\end{description}
Characters can be used in a loop, one can use \var{prev} and \var{succ} on
it, as well as \var{ord}.

For more information on characters, see \sees{charactertypes}.

%
%
%
\subsection{Real types}
\index{Types!Real}
\fpc uses the math coprocessor (or emulation) for all its floating-point
calculations. The \var{Real} native type is processor dependent,
but it is either a \var{Single} or a \var{Double}. Only the IEEE floating point types are
supported, and these depend on the target processor and emulation options.
The true \tp compatible types are listed in
\seet{Reals}.\index{Real}\index{Single}\index{Double}\index{Extended}\index{Comp}\index{Currency}
\keywordlink{Real}\keywordlink{Single}\keywordlink{Double}\keywordlink{Extended}\keywordlink{Comp}\keywordlink{Currency}
\begin{FPCltable}{lccr}{Supported Real types}{Reals}
Type & Range & Significant digits & Size \\ \hline
Real & platform dependant & ??? & 4 or 8 \\
Single & 1.5E-45 .. 3.4E38 & 7--8 & 4 \\
Double & 5.0E-324 .. 1.7E308 & 15--16 & 8 \\
Extended & 1.9E-4932 .. 1.1E4932 & 19--20 & 10\\
Comp & -2E64+1 .. 2E63-1 & 19--20 & 8  \\
Currency & -922337203685477.5808 .. 922337203685477.5807 & 19--20 & 8 \\
\end{FPCltable}
The \var{Comp} type is, in effect, a 64-bit integer and is not available
on all target platforms. To get more information on the supported types
for each platform, refer to the \progref.

The currency type is a fixed-point real data type which is internally used
as an 64-bit integer type (automatically scaled with a factor 10000), this
minimizes rounding errors. This type should be used with care: when used in
expressions using e.g. multiplication, the evaluation of the expression may
go wrong (losing precision) if intermediate results fall outside the currency range. 

Note that not all float types are available on all platforms. The
\var{single} float type is the only one guaranteed to be available on all
platforms that have floating point support (so e.g. AVR does not have it). 
The \var{double} type is available on all platforms with coprocessor, 
and the \var{extended} type is available on all Intel x86 processors,
except on the Windows 64-bit platform.  More details on availability can be
found in the \progref.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Character types
\section{Character types}
\label{se:charactertypes}
\index{Types!Char}
\subsection{Char or AnsiChar}
\index{Char} \keywordlink{char}
\fpc supports the type \var{Char}. A \var{Char} is exactly 1 byte in
size, and contains one ASCII character.

A character constant can be specified by enclosing the character in single
quotes, as follows: \var{'a'} or \var{'A'} are both character constants.

A character can also be specified by its character
value (commonly an ASCII code), by preceding the ordinal value with the
number symbol (\#). For example specifying \var{\#65} would be the same as \var{'A'}.

Also, the caret character (\verb+^+) can be used in combination with a letter to
specify a character with ASCII value less than 27. Thus \verb+^G+ equals
\var{\#7}~$-$ G is the seventh letter in the alphabet. The compiler is rather
sloppy about the characters it allows after the caret, but in general one
should assume only letters.

When the single quote character must be represented, it should be typed
two times successively, thus \var{'{}'{}'{}'} represents the single quote character.

To distinguish \var{Char} from \var{WideChar}, the system unit also defines
the \var{AnsiChar} type, which is the same as the char type. In future
versions of FPC, the \var{Char} type may become an alias for either \var{WideChar}
or \var{AnsiChar}.

\subsection{WideChar}
\index{WideChar} \keywordlink{widechar}
\fpc supports the type \var{WideChar}. A \var{WideChar} is exactly 2 bytes in
size, and contains one UNICODE character in UTF-16 encoding.

A unicode character can be specified by its character value
(an UTF-16 code), by preceding the ordinal value with the number symbol (\#).

A normal ansi (1-byte) character literal can also be used for a widechar,
the compiler will automatically convert it to a 2-byte UTF-16 character.

The following defines some greek characters (phi, omega):
\begin{verbatim}
Const
  C3 : widechar = #$03A8;
  C4 : widechar = #$03A9;
\end{verbatim}
The same can be accomplished by typecasting a word to widechar:
\begin{verbatim}
Const
  C3 : widechar = widechar($03A8);
  C4 : widechar = widechar($03A9);
\end{verbatim}

\subsection{Other character types}
\fpc defines some other character types in the system unit such as
\var{UCS2Char}, \var{UCS4Char}, \var{UniCodeChar}.
However, no special support for these character types exists, they have been
defined for Delphi compatibility only.

\subsection{Single-byte String types}
\index{Types!String} \keywordlink{String}\index{String!Single-byte string}
\fpc supports the \var{String} type as it is defined in \tp:
a sequence of single-byte characters with an optional size specification.
It also supports ansistrings (with unlimited length) and codepage information\footnote{As of version 3.0 of \fpc} as in Delphi.

To declare a variable as a string, use the following type specification:
\input{syntax/sstring.syn}
If there is a size specifier (using square brackets), then its maximum value~-- indicating the maximum
size of the string~-- is 255. If there is a codepage specifier, (using round brackets) it indicates an
ansistring with associated code page information.

The meaning of a string declaration statement without size and code page indication is
interpreted differently depending on the \var{\{\$H\}} switch:
\begin{verbatim}
var
  A : String;
\end{verbatim}
If no size and code page indication indication is present, the above declaration can declare
an ansistring or a short string.

Whatever the actual type, single byte strings can be used interchangeably.
The compiler always takes care of the necessary type conversions.
Note, however, that the result of an expression that contains ansistrings and short strings will always be an ansistring.

\subsubsection{Short strings}
\index{Shortstring}\index{Types!ShortString} \keywordlink{ShortString}\index{String!ShortString}
A string declaration declares a short string in the following cases:
\begin{enumerate}
\item If the \var{\$H} switch is off: \var{\{\$H-\}}, the string declaration will always be a short string declaration.
\item If the switch is on \var{\{\$H+\}}, and there is a maximum length (the size) specifier, the declaration is a short
string declaration.
\end{enumerate}
Short strings are always assumed to use the system code page.
The predefined type \var{ShortString} is defined as a string of size 255:
\begin{verbatim}
 ShortString = String[255];
\end{verbatim}
If the size of the string is not specified, \var{255} is taken as a default.
The actual length of the string can be obtained with the
\var{Length} standard runtime routine.
For example in
\begin{verbatim}
{$H-}

Type
  NameString = String[10];
  StreetString = String;
\end{verbatim}
\var{NameString} can contain a maximum of 10 characters. While
\var{StreetString} can contain up to 255 characters.

\begin{remark}
Short strings have a maximum length of 255 characters: when specifying a
maximum length, the maximum length may not exceed 255. If a length larger
than 255 is attempted, then the compiler will give an error message:
\begin{verbatim}
Error: string length must be a value from 1 to 255
\end{verbatim}

For short strings, the length is stored in the character at index 0. Old
\tp code relies on this, and it is implemented similarly in Free Pascal.

Despite this, to write portable code, it is best to set the length of a
shortstring  with the \var{SetLength} call, and to retrieve
it with the \var{Length} call.  These functions will always work, whatever
the internal representation of the shortstrings or other strings in use:
this allows easy switching between the various string types.
\end{remark}

\subsubsection{Ansistrings}
\index{Ansistring}\index{Types!Ansistring}\index{Types!Reference counted}\index{CodePage}\index{String!CodePage}\index{String!Ansistring}
\keywordlink{AnsiString}
Ansistrings are strings that have no length limit, and have a code page associated with
them\footnote{codepage was introduced in version 3.0 of \fpc}.
They are reference counted and are guaranteed to be null terminated.

Internally, an ansistring is treated as a pointer: the actual content of the string is stored on the heap, as much
memory as needed to store the string content is allocated.

If no codepage is given in the declaration, the system codepage is assumed.
What codepage this is, is determined by the \var{DefaultSystemCodePage} constant in the system unit.

This is all handled transparently, i.\,e. they can be manipulated as a normal
short string. Ansistrings can be defined using the predefined \var{AnsiString}
type or using the \var{string} keyword in mode \var{\{\$H+\}}.

\begin{remark}
The null-termination does not mean that null characters (char(0) or \#0)
cannot be used: the null-termination is not used internally, but is there for
convenience when dealing with external routines that expect a
null-terminated string (as most C routines do).
\end{remark}

If the \var{\{\$H\}} switch is on, then a string definition using the
regular \var{String} keyword that doesn't contain a length specifier,
will be regarded as an ansistring as well. If a length specifier is present,
a short string will be used, regardless of the \var{\{\$H\}} setting.

\keywordlink{nil}
If the string is empty (\var{'{}'}), then the internal pointer representation
of the string pointer is \var{Nil}. If the string is not empty, then the
pointer points to a structure in heap memory.

The internal representation as a pointer, and the automatic null-termination
make it possible to typecast\index{Typecast} an ansistring to a pchar. If the string is empty
(so the pointer is \var{Nil}) then the compiler makes sure that the typecast
pchar will point to a null byte.

Assigning one ansistring to another doesn't involve moving the actual
string. A statement
\begin{verbatim}
  S2:=S1;
\end{verbatim}
results in the reference count of \var{S2} being decreased with 1,
The reference count of \var{S1} is increased by 1, and finally \var{S1}
(as a pointer) is copied to \var{S2}. This is a significant speed-up in
the code.

If the reference count of a string reaches zero, then the memory occupied
by the string is deallocated automatically, and the pointer is set to
\var{Nil}, so no memory leaks arise.

When an ansistring is declared, the \fpc compiler initially
allocates just memory for a pointer, not more. This pointer is guaranteed
to be \var{Nil}, meaning that the string is initially empty. This is
true for local and global ansistrings or ansistrings that are part of a
structure (arrays, records or objects).

\begin{remark}
Note that a function result in this regard is considered equivalent to a \var{var}
parameter and hence will not be initialized to \var{Nil}. As a consequence
it may point to a legitimate non-\var{Nil} ansistring when the function
begins.
\end{remark}

This  does introduce an overhead. For instance, declaring
\begin{verbatim}
Var
  A : Array[1..100000] of string;
\end{verbatim}
Will copy the value \var{Nil} 100,000 times into \var{A}.
When \var{A} goes out of scope\index{Scope}, then the reference
count of the 100,000 strings will be decreased by 1 for each
of these strings. All this happens invisible to the programmer,
but when considering performance issues, this is important.

Memory for the string content will be allocated only when the string is
assigned a value. If the string goes out of scope, then its reference
count is automatically  decreased by 1. If the reference count reaches
zero, the memory reserved for the string is released.

If a value is assigned to a character of a string that has a reference count
greater than 1, such as in the following
statements:
\begin{verbatim}
  S:=T;  { reference count for S and T is now 2 }
  S[I]:='@';
\end{verbatim}
then a copy of the string is created before the assignment. This is known
as {\em copy-on-write} semantics. It is possible to force a string to have
reference count equal to 1 with the \var{UniqueString} call:
\begin{verbatim}
  S:=T;
  R:=T; // Reference count of T is at least 3
  UniqueString(T);
  // Reference count of T is guaranteed 1
\end{verbatim}
It's recommended to do this e.\,g. when typecasting an ansistring to a PChar var
and passing it to a C routine that modifies the string.

The \var{Length} function must be used to get the length of an
ansistring: the length is not stored at character 0 of the ansistring.
The construct
\begin{verbatim}
 L:=ord(S[0]);
\end{verbatim}
which was valid for \tp shortstrings, is no longer correct for
Ansistrings. The compiler will warn if such a construct is encountered.


To set the length of an ansistring, the \var{SetLength} function must be used.
Constant ansistrings have a reference count of \var{-1} and are treated specially,
The same remark as for \var{Length} must be given: The construct
\begin{verbatim}
  L:=12;
  S[0]:=Char(L);
\end{verbatim}
which was valid for \tp shortstrings, is no longer correct for
Ansistrings. The compiler will warn if such a construct is encountered.

Ansistrings are converted to short strings by the compiler if needed,
this means that the use of ansistrings and short strings can be mixed
without problems.

Ansistrings can be typecast\index{Typecast} to \var{PChar} or \var{Pointer} types:
\index{Types!PChar}\index{PChar}
\begin{verbatim}
Var P : Pointer;
    PC : PChar;
    S : AnsiString;

begin
  S :='This is an ansistring';
  PC:=Pchar(S);
  P :=Pointer(S);
\end{verbatim}
There is a difference between the two typecasts. When an empty
ansistring is typecast to a pointer, the pointer will be \var{Nil}. If an
empty ansistring is typecast to a \var{PChar}, then the result will be a pointer to a
zero byte (an empty string).

The result of such a typecast must be used with care. In general, it is best
to consider the result of such a typecast as read-only, i.\,e. only suitable for
passing to a procedure that needs a constant pchar argument.

It is therefore {\em not} advisable to typecast one of the following:
\begin{enumerate}
\item Expressions.
\item Strings that have reference count larger than 1.
In this case you should call \var{Uniquestring} to ensure the
string has reference count 1.
\end{enumerate}

\subsubsection{Code page conversions}
\index{CodePage}\index{CodePage!Conversion}\index{Types!Reference counted}\index{String!Codepage}
\keywordlink{Rawbytestring}
Since strings have code page information associated with them, it is important to know which code page a string uses:
\begin{itemize}
\item Short strings always use the system code page.
\item Plain ansistrings use the system code page.
\item Single byte strings with declared code page use that code page.
\item The \var{RawBytestring} type has no code page information associated with it.
\item Constant strings have the code page of the source file.
If none is specified the system codepage is used (CP\_ACP).\\
See \progref, \{\$CODEPAGE \} directive.
\end{itemize}
This code page is called the declared code page.

The compiler will convert the code page of strings as needed: When assigning a string,
the actual codepage of the source string will be converted to the declared code
page of the target string if the declared source and target code pages are different.

If a string with a declared page \var{SOURCE\_CP} assigned to a string with
declared code page \var{DEST\_CP}, in a file with code page \var{CODE_CP} then
the following describes the mechanism:

\begin{itemize}
\item if (\var{SOURCE\_CP}=\var{CP\_NONE}) or (\var{DEST\_CP} =
\var{CP\_NONE}), see RawByteString.
\item if (\var{CODE\_CP} <> \var{CP\_ACP}), then if (\var{DEST\_CP} =
\var{CP\_ACP}) and (\var{SOURCE\_CP} = \var{CODE\_CP}) or vice versa, no conversion will
occur, even if at run time \var{DefaultSystemCodePage} has a different value from
\var{SOURCE\_CP}. \\
The reason for this ``(\var{CODE\_CP} <>\var{CP\_ACP})'' condition is backward compatibility with previous FPC versions:
While they did not support \var{AnsiStrings} with arbitrary code pages, they did
always reinterpret \var{AnsiStrings} according to the current value of the system
code page. \\
Otherwise,
\item if (\var{SOURCE\_CP} <> \var{DEST\_CP}), the string data will be converted from
codepage \var{SOURCE\_CP} to codepage  \var{DEST\_CP} before assignment, whereby
\var{CP\_ACP} will be
interpreted as the current value of \var{DefaultSystemCodePage}. Otherwise,
\item if (\var{SOURCE\_CP} = \var{DEST\_CP}), no codepage conversion will be performed.
\end{itemize}
These rules mean that it is perfectly possible for an \var{AnsiString} variable to
get a code page that differs from its declared code page.
E.\,g. in the third case \var{SOURCE\_CP} could be \var{CP\_ACP}, while after the
assignment it may have a dynamic code page equal to \var{DefaultSystemCodePage}.

Note: as mentioned above, whether or not a potential code page conversion
happens only depends on the declared code pages of the involved strings.
This means that if you assign one AnsiString(X) to another AnsiString(X) and the
former's dynamic code was different from X, the string data will not be
converted to code page X by the assignment.

All this means that in the following code:
\begin{verbatim}
{$h+}
uses sysutils;

Type
  TString1 = Type String(1252);
  TString2 = Type String(1251);

Var
  A : TString1;
  B : TString2;

begin
  A:='123'+'345'+intToStr(123);
  B:=A;
  Writeln('B: "',B,'" : ',StringRefCount(B),' -> ',StringCodePage(B));
  Writeln('A: "',A,'" : ',StringRefCount(A),' -> ',StringCodePage(A));
end.
\end{verbatim}
This will print:
\begin{verbatim}
B: "123345123" : 1 -> 1251
A: "123345123" : 1 -> 1252
\end{verbatim}
During the assignment of \var{A} to \var{B}, the contents of string \var{A}
is converted to the codepage of string \var{B}.
Note that if a code page conversion takes place, the reference count mechanism is not used:
a new string will be allocated.

This automated conversion of code pages can slow down the code seriously, so care must be
taken to see to it that the code page conversions are limited to a minimum.



The code page of a string can be set explicitly using the \var{SetCodePage} routine of the system unit.
Calling this routine will convert the value of a string to the requested code page.

\begin{remark}
Code page conversions can result in loss of data: if a certain character cannot be represented in the target
code page, the output for that character is undefined.
\end{remark}

\begin{remark}
When a string whose static code page equals the source file code page, to anything with
code page CP\_ACP (i.\,e., a plain ansistring, shortstring, or pchar), no conversion will
be performed either.
No code page conversion is done when
s can result in loss of data: if a certain character cannot be represented in the target
code page, the output for that character is undefined.
\end{remark}

\begin{remark}
Code page support requires quite some helper routines, these are implemented in the unicodestring manager.
On windows, the system routines are used for this. On Unices, the \var{cwstring} unit can be used to link
to the C library and use the C library conversion support.
Alternatively, the \var{fpwidestring} unit contains a unicodestring manager implemented natively in Object Pascal.
\end{remark}


\subsubsection{RawByteString}
\index{Rawbytestring}\index{Types!Rawbytestring}\index{Types!Reference counted}\index{String!RawByteString}
\keywordlink{Rawbytestring}
The predefined \var{RawByteString} type is an ansistring string type without codepage information (\var{CP\_NONE}):
\begin{verbatim}
Type
  RawByteString = type ansistring(CP_NONE);
\end{verbatim}
It is treated specially in the sense that if the conversion routines encounter \var{CP\_NONE} in a
source or target string, no code page conversion is performed, the code page of the source string is preserved.

For this reason, most single-byte string routines in the system and sysutils units use the \var{RawByteString} type.

\subsubsection{UTF8String}
\index{UTF8String}\index{Types!UTF8String}\index{Types!UnicodeString}\index{String!UTF8String}
\keywordlink{UTF8String}
Single-byte code page strings can only store the characters available in that code page.
Characters that are not present in the code page, cannot be represented by that string.
The UTF-8 unicode encoding is an encoding that can be used with single-byte strings:
The ASCII characters (ordinal value <128) in this encoding map exactly to the CP_ACP encoding.
This fact is used to define a single byte string type that can contain all characters:
\begin{verbatim}
Type
  UTF8String = type AnsiString(CP_UTF8);
\end{verbatim}
The \var{UTF8string} string type can be used to represent all Unicode characters. This power comes as a price, though.
Since a unicode character may require several bytes to be represented in the UTF-8 encoding, there are two points to take
care of when using UTF8String:
\begin{enumerate}
\item The character index~-- which retrieves a byte-sized char at a certain position~-- must be used with care: the expression
\var{S[i]} will not necessarily be a valid character for a string \var{S} of type \var{UTF8String}.
\item The byte length of the string is not equal to the number of characters in the string.
The standard function \var{length} cannot be used to get the character length, it will always return the byte length.
\end{enumerate}
For all other code pages, the number of characters in a single-byte code page string is equal to the byte length of the string.


\subsection{Multi-byte String types}
\index{String!Multi-byte}
For multi-byte string types, the basic character has a size of at least 2.
This means it can be used to store a unicode character in UTF16 or UCS2 encoding.

\subsubsection{UnicodeStrings}
\index{Unicodestring}\index{Types!UnicodeString}\index{Types!Reference counted}\index{String!UnicodeString}
\keywordlink{UnicodeString}
Unicodestrings (used to represent unicode character strings) are implemented in much
the same way as ansistrings: reference counted, null-terminated arrays, only they
are implemented as arrays of \var{WideChars} instead of regular \var{Chars}.
A \var{WideChar} is a two-byte character (an element of a DBCS: Double Byte
Character Set). Mostly the same rules apply for \var{UnicodeStrings} as for
\var{AnsiStrings}. The compiler transparently converts UnicodeStrings to
AnsiStrings and vice versa. \index{Ansistring}

Similarly to the typecast\index{Typecast} of an Ansistring to a \var{PChar} null-terminated
\index{PChar}\index{PUnicodeChar} array of characters, a UnicodeString can be converted to a
\var{PUnicodeChar} null-terminated array of characters. Note that the
\var{PUnicodeChar} array is terminated by 2 null bytes instead of
1, so a typecast to a pchar is not automatic.

The compiler itself provides no support for any conversion from Unicode to
ansistrings or vice versa. The \file{system} unit has a unicodestring manager
record, which can be initialized with some OS-specific unicode handling
routines. For more information, see the \file{system} unit reference.

A unicode string literal can be constructed in a similar manner as a widechar:
\begin{verbatim}
Const
  ws2: unicodestring = 'phi omega : '#$03A8' '#$03A9;
\end{verbatim}


\subsubsection{WideStrings}
\index{Widestring}\index{Types!Widestring}\index{String!WideString}
\keywordlink{Widestring}
The \var{Widestring} type (used to represent unicode character strings in COM applications)
is implemented in much the same way as \var{Unicodestring} on Windows, and on other
platforms, they are simply the same type. If interaction with COM is not required,
the \var{UnicodeString} type should be used.

On Windows, unlike \var{UnicodeString}, the \var{WideString} type is \emph{not} reference counted,
and are allocated with a special windows function which allows them to be used for OLE automation.
This means they are implemented as null-terminated arrays of \var{WideChars} instead of regular \var{Chars}.
\var{WideString} obeys the same rules as for \var{UnicodeStrings}.
Similar to unicodestrings, the compiler transparenty converts WideStrings
to AnsiStrings and vice versa. \index{Ansistring}

For typecasting and conversion, the same rules apply as for the \var{UnicodeString} type.

Note that on windows, because a \var{WideString} string is allocated using a special windows function, the
memory layout differs from \var{UnicodeString}. The length for instance is stored in bytes rather than characters.

% Constant strings
\subsection{Constant strings}
\index{Constants!String}\index{String!Constant}
To specify a constant string, it must be enclosed in single-quotes, just
as a \var{Char} type, only now more than one character is allowed.
Given that \var{S} is of type \var{String}, the following are valid assignments:
\begin{verbatim}
S := 'This is a string.';
S := 'One'+', Two'+', Three';
S := 'This isn't difficult!';
S := 'This is a weird character : '#145' !';
\end{verbatim}
As can be seen, the single quote character is represented by 2 single-quote
characters next to each other. Strange characters can be specified by their
character value (usually an ASCII code).
The example shows also that two strings can be added. The resulting string is
just the concatenation of the first with the second string, without spaces in
between them. Strings can not be subtracted, however.

Whether the constant string is stored as an ansistring or a short string
depends on the settings of the \var{\{\$H\}} switch.


% PChar
\subsection{PChar~-- Null terminated strings}
\index{Types!PChar}\index{Types!Pointer} \keywordlink{PChar}
\fpc supports the Delphi implementation of the \var{PChar} type. \var{PChar}
is defined as a pointer to a \var{Char} type, but allows additional
operations.
The \var{PChar} type can be understood best as the Pascal equivalent of a
C-style null-terminated string, i.\,e. a variable of type \var{PChar} is a
pointer that points to an array of type \var{Char}, which is ended by a
null-character (\var{\#0}).
\fpc supports initializing of \var{PChar} typed constants, or a direct
assignment. For example, the following pieces of code are equivalent:
\begin{verbatim}
program one;
var P : PChar;
begin
  P := 'This is a null-terminated string.';
  WriteLn (P);
end.
\end{verbatim}
Results in the same as
\begin{verbatim}
program two;
const P : PChar = 'This is a null-terminated string.';
begin
  WriteLn (P);
end.
\end{verbatim}
These examples also show that it is possible to write {\em the contents} of
the string to a file of type \var{Text}.
The \seestrings unit contains procedures and functions that manipulate the
\var{PChar} type as in the standard C library.
Since it is equivalent to a pointer to a type \var{Char} variable, it  is
also possible to do the following:
\begin{verbatim}
Program three;
Var S : String[30];
    P : PChar;
begin
  S := 'This is a null-terminated string.'#0;
  P := @S[1];
  WriteLn (P);
end.
\end{verbatim}
This will have the same result as the previous two examples.
Null-terminated strings cannot be added as normal Pascal
strings. If two \var{PChar} strings must be concatenated; the functions from
the unit \seestrings must be used.

However, it is possible to do some pointer arithmetic. The \index{Operators}
operators \var{+} and \var{-} can be used to do operations on \var{PChar} pointers.
In \seet{PCharMath}, \var{P} and \var{Q} are of type \var{PChar}, and
\var{I} is of type \var{Longint}.
\begin{FPCltable}{lr}{\var{PChar} pointer arithmetic}{PCharMath}
Operation & Result \\ \hline
\var{P + I} & Adds \var{I} to the address pointed to by \var{P}. \\
\var{I + P} & Adds \var{I} to the address pointed to by \var{P}. \\
\var{P - I} & Subtracts \var{I} from the address pointed to by \var{P}. \\
\var{P - Q} & Returns, as an integer, the distance between two addresses \\
 & (or the number of characters between \var{P} and \var{Q}) \\
\hline
\end{FPCltable}

% String sizes
\subsection{String sizes}
The memory occupied by a string depends on the string type. Some string
types allocate the string data in memory on the heap, others have the string
data on the stack. Table \seet{StringSizes} summarizes the memory usage of
the various string types for the various string types. In the table, the following symbolic constants are used:
\begin{enumerate}
\item \var{L} is the actual length of the string.
\item \var{HS} depends on the version of \fpc, but is 16 bytes as
of \fpc 2.7.1.
\item \var{UHS} size is 8 bytes for all versions of \fpc.
\item On Windows, \var{WHS} size is 4 bytes for all versions of \fpc. On all other platforms,
\var{WHS} equals \var{UHS} because the \var{WideString} type equals the \var{UnicodeString} type.
\end{enumerate}



\begin{FPCltable}{lll}{String memory sizes}{StringSizes}
String type & Stack size & heap size \\ \hline
Shortstring & Declared length + 1 & 0 \\
Ansistring  & Pointer size & L + 1 + HS  \\
Widestring  & Pointer size & 2*(L + 1) + WHS \\
UnicodeString  & Pointer size & 2*(L + 1) + UHS \\
Pchar & Pointer size & L+1 \\
\hline
\end{FPCltable}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Structured Types
\section{Structured Types}
\index{Types!Structured}
A structured type is a type that can hold multiple values in one variable.
Structured types can be nested to unlimited levels.
\input{syntax/typestru.syn}
Unlike Delphi, \fpc does not support the keyword \var{Packed} for all
structured types.  In the following sections each of the possible
structured types is discussed. It will be mentioned when a type supports
the \var{packed} keyword.
%
%
\subsubsection{Packed structured types}
When a structured type is declared, no assumptions should be made about
the internal position of the elements in the type. The compiler will lay
out  the elements of the structure in memory as it thinks will be most
suitable. That is, the order of the elements will be kept, but the location
of the elements are not guaranteed, and is partially governed by the \var{\$PACKRECORDS}
directive (this directive is explained in the \progref).

\keywordlink{packed} \keywordlink{bitpacked}
However, \fpc allows controlling the layout with the \var{Packed} and
\var{Bitpacked} keywords. The meaning of these words depends on the context:
\begin{description}
\item[Bitpacked] In this case, the compiler will attempt to align ordinal
types on bit boundaries, as explained below.
\item[Packed] The meaning of the \var{Packed} keyword depends on the
situation:
\begin{enumerate}
\item In \var{MACPAS} mode, it is equivalent to the \var{Bitpacked} keyword.
\item In other modes, with the \var{\$BITPACKING} directive set to \var{ON},
it is also equivalent to the \var{Bitpacked} keyword.
\item In other modes, with the \var{\$BITPACKING} directive set to \var{OFF},
it signifies normal packing on byte boundaries.
\end{enumerate}
Packing on byte boundaries means that each new element of a structured type
starts on a byte boundary.
\end{description}

The byte packing mechanism is simple: the compiler aligns each element of
the structure on the first available byte boundary, even if the size of the
previous element (small enumerated types, subrange types) is less than a
byte.

When using the bit packing mechanism, the compiler calculates for each
ordinal type how many bits are needed to store it. The next ordinal type
is then stored on the next free bit. Non-ordinal types~-- which include but
are not limited to~-- sets, floats, strings, (bitpacked) records, (bitpacked)
arrays, pointers, classes, objects, and procedural variables, are stored
on the first available byte boundary.

Note that the internals of the bitpacking are opaque: they can change
at any time in the future. What is more: the internal packing depends
on the endianness of the platform for which the compilation is done,
and no conversion between platforms are possible. This makes bitpacked
structures unsuitable for storing on disk or transport over networks.
The format is however the same as the one used by the GNU Pascal
Compiler, and the \fpc team aims to retain this compatibility in the future.

There are some more restrictions to elements of bitpacked structures:
\begin{itemize}
\item The address cannot be retrieved, unless the bit size is a multiple of
8 and the element happens to be stored on a byte boundary.
\item An element of a bitpacked structure cannot be used as a var parameter,
unless the bit size is a multiple of 8 and the element happens to be stored
on a byte boundary.
\end{itemize}

To determine the size of an element in a bitpacked structure, there is the
\var{BitSizeOf} function. It returns the size~-- in bits~-- of the element.
For other types or elements of structures which are not bitpacked, this will
simply return the size in bytes multiplied by 8, i.\,e., the return value is
then the same as \var{8*SizeOf}.

The size of bitpacked records and arrays is limited:
\begin{itemize}
\item On 32 bit systems the maximal size is $2^{29}$ bytes (512 MB).
\item On 64 bit systems the maximal size is $2^{61}$ bytes.
\end{itemize}
The reason is that the offset of an element must be calculated with
the maximum integer size of the system.

%
\subsection{Arrays}
\index{Types!Array}\index{Array}
\fpc supports arrays as in \tp. Multi-dimensional arrays and (bit)packed
arrays are also supported, as well as the dynamic arrays of \delphi:
\input{syntax/typearr.syn}
%
\subsubsection{Static arrays}
\index{Types!Array}\index{Array!Static}\keywordlink{array} \keywordlink{of}
When the range of the array is included in the array definition, it is
called a static array. Trying to access an element with an index that is
outside the declared range will generate a run-time error (if range checking
is on).  The following is an example of a valid array declaration:
\begin{verbatim}
Type
  RealArray = Array [1..100] of Real;
\end{verbatim}
Valid indexes for accessing an element of the array are between 1 and 100,
where the borders 1 and 100 are included.
As in \tp, if the array component type is in itself an array, it is
possible to combine the two arrays into one multi-dimensional array. The
following declaration:
\begin{verbatim}
Type
   APoints = array[1..100] of Array[1..3] of Real;
\end{verbatim}
is equivalent to the declaration:
\begin{verbatim}
Type
   APoints = array[1..100,1..3] of Real;
\end{verbatim}
The functions \var{High} and \var{Low} return the high and low bounds of
the leftmost index type of the array. In the above case, this would be 100
and 1. You should use them whenever possible, since it improves maintainability
of your code. The use of both functions is just as efficient as using
constants, because they are evaluated at compile time.

When static array-type variables are assigned to each other, the contents of the
whole array is copied. This is also true for multi-dimensional arrays:
\begin{verbatim}
program testarray1;

Type
  TA = Array[0..9,0..9] of Integer;

var
  A,B : TA;
  I,J : Integer;
begin
  For I:=0 to 9 do
    For J:=0 to 9 do
      A[I,J]:=I*J;
  For I:=0 to 9 do
    begin
    For J:=0 to 9 do
      Write(A[I,J]:2,' ');
    Writeln;
    end;
  B:=A;
  Writeln;
  For I:=0 to 9 do
    For J:=0 to 9 do
      A[9-I,9-J]:=I*J;
  For I:=0 to 9 do
    begin
    For J:=0 to 9 do
      Write(B[I,J]:2,' ');
    Writeln;
    end;
end.
\end{verbatim}
The output of this program will be two identical matrices.

\subsubsection{Dynamic arrays}
\index{Types!Array}\index{Array!Dynamic}\index{Types!Reference counted}
As of version 1.1, \fpc also knows dynamic arrays: In that case the array
range is omitted, as in the following example:
\begin{verbatim}
Type
  TByteArray = Array of Byte;
\end{verbatim}
When declaring a variable of a dynamic array type, the initial length of the
array is zero. The actual length of the array must be set with the standard
\var{SetLength} function, which will allocate the necessary memory to contain
the array elements on the heap.

The following example will set the length to 1000:
\begin{verbatim}
Var
  A : TByteArray;

begin
  SetLength(A,1000);
\end{verbatim}
After a call to \var{SetLength}, valid array indexes are 0 to 999: the array
index is always zero-based.

\var{SetLength} can also be used for multi-dimensional arrays. The following example will create
a ``rectangular'' array:
\begin{verbatim}
Var
  A : Array of TByteArray;

begin
  SetLength(A,10,100);
\end{verbatim}
After a call to \var{SetLength}, valid array indexes are 0 to 9 for the
first dimension, and 0 to 99 for the second dimension.

In difference with static multi-dimensional arrays, dynamic arrays do not
need to be ``rectangular'', i.\,e. the various elements can have different
lengths:
\begin{verbatim}
var
  a: array of array of array of LongInt;
  i, j, k: LongInt;
begin
  SetLength(a, 10, 5);
  SetLength(a[5], 3);

  for i := Low(a) to High(a) do
    for j := Low(a[i]) to High(a[i]) do begin
      SetLength(a[i, j], i * 10 + j);
      for k := Low(a[i, j]) to High(a[i, j]) do
        a[i, j, k] := i * 10000 + j * 100 + k;
    end;

  for i := Low(a) to High(a) do begin
    for j := Low(a[i]) to High(a[i]) do begin
      for k := Low(a[i, j]) to High(a[i, j]) do
        Writeln(a[i, j, k]);
      Writeln('-------');
    end;
    Writeln('=======');
  end;
end.
\end{verbatim}

Note that the length of the array is set in elements, not in bytes of
allocated memory (although these may be the same). The amount of
memory allocated is the size of the array multiplied by the size of
1 element in the array. The memory will be disposed of at the exit of the
current procedure or function.

It is also possible to resize the array: in that case, as much of the
elements in the array as will fit in the new size, will be kept. The array
can be resized to zero, which effectively resets the variable.

At all times, trying to access an element of the array with an index
that is not in the current length of the array will generate a run-time
error.

Dynamic arrays are reference counted: assignment of one dynamic array-type
variable to another will let both variables point to the same array.
Contrary to ansistrings, an assignment to an element of one array will
be reflected in the other: there is no copy-on-write. Consider the following
example:
\begin{verbatim}
Var
  A,B : TByteArray;

begin
  SetLength(A,10);
  A[0]:=33;
  B:=A;
  A[0]:=31;
\end{verbatim}
After the second assignment, the first element in B will also contain 31.

It can also be seen from the output of the following example:
\begin{verbatim}
program testarray1;

Type
  TA = Array of array of Integer;

var
  A,B : TA;
  I,J : Integer;
begin
  Setlength(A,10,10);
  For I:=0 to 9 do
    For J:=0 to 9 do
      A[I,J]:=I*J;
  For I:=0 to 9 do
    begin
    For J:=0 to 9 do
      Write(A[I,J]:2,' ');
    Writeln;
    end;
  B:=A;
  Writeln;
  For I:=0 to 9 do
    For J:=0 to 9 do
      A[9-I,9-J]:=I*J;
  For I:=0 to 9 do
    begin
    For J:=0 to 9 do
      Write(B[I,J]:2,' ');
    Writeln;
    end;
end.
\end{verbatim}
The output of this program will be a matrix of numbers, and then the same matrix, mirrored.

\index{Types!Reference counted}
As remarked earlier, dynamic arrays are reference counted: if in one of the previous examples A
goes out of \index{Scope} scope and B does not, then the array is not yet disposed of: the
reference count of A (and B) is decreased with 1. As soon as the reference
count reaches zero the memory, allocated for the contents of the array, is disposed of.

The \var{SetLength} call will make sure the reference count of the returned
array is 1, that is, if two dynamic array variables were pointing to the same
memory they will no longer do so after the setlength call:
\begin{verbatim}
program testunique;

Type
  TA = array of Integer;

var
  A,B : TA;
  I : Integer;

begin
  Setlength(A,10);
  For I:=0 to 9 do
    A[I]:=I;
  B:=A;
  SetLength(B,6);
  A[0]:=123;
  For I:=0 to 5 do
    Writeln(B[I]);
end.
\end{verbatim}

It is also possible to copy and/or resize the array with the standard
\var{Copy} function, which acts as the copy function for strings:
\begin{verbatim}
program testarray3;

Type
  TA = array of Integer;

var
  A,B : TA;
  I : Integer;

begin
  Setlength(A,10);
  For I:=0 to 9 do
      A[I]:=I;
  B:=Copy(A,3,6);
  For I:=0 to 5 do
    Writeln(B[I]);
end.
\end{verbatim}
The \var{Copy} function will copy six elements of the array to a new array.
Starting at the element at index 3 (i.\,e. the fourth element) of the array.

The \var{Length} function will return the number of elements in the array.
The \var{Low} function on a dynamic array will always return 0, and the
\var{High} function will return the value \var{Length-1}, i.\,e., the value of the
highest allowed array index.

\subsubsection{Dynamic array Type compatibility}
\index{Type!Compatibility}
Object Pascal is a strictly typed language. Two technically distinct types are sometimes considered assignment compatible
(i.\,e. a value of one type can be assigned to a variable of another type) under certain circumstances.
Dynamic arrays are considered assignment compatible when they use the same element type.
That means that the following will compile:
\begin{verbatim}
{$mode objfpc}

Type
  TA = Array of Integer;
  TB = Array of Integer;

Var
  A : TA;
  B : TB;

begin
  SetLength(A,1);
  A[0]:=1;
  B:=A;
end.
\end{verbatim}
But the following will not, even though the integer and word types are assignment compatible:
\begin{verbatim}
{$mode objfpc}

Type
  TA = Array of Word;
  TB = Array of Integer;

Var
  A : TA;
  B : TB;

begin
  SetLength(A,1);
  A[0]:=1;
  B:=A;
end.
\end{verbatim}

\subsubsection{Dynamic array constructor}
\index{Types!Constructor}\index{Array!Constructor}\index{Array constructor}
As of version 3.0 of \fpc, Dynamic array types have a constructor. This is intrinsic, the compiler provides it.
Up to version 2.6.4, the only way to initialize a dynamic array was as follows:
\begin{verbatim}
Type
  TIntegerArray = Array of Integer;

var
  A : TIntegerArray;

begin
  SetLength(A,3);
  A[0]:=1;
  A[1]:=2;
  A[3]:=3;
  Writeln(Length(A));
end.
\end{verbatim}
As of version 3.0 of \fpc, an dynamic array can be initialized using a constructor-like syntax.
The constructor is called \var{Create}, and accepts as parameters a variable number of parameters of the element type of the array type.
This means the above initialization can now be done as:
\begin{verbatim}
Type
  TIntegerArray = Array of Integer;

var
  A : TIntegerArray;

begin
  A:=TIntegerArray.Create(1,2,3);
  Writeln(Length(A));
end.
\end{verbatim}
Note that this will not work for dynamic arrays for which no type was created. That is, the following will not work:
\begin{verbatim}
var
  A : Array of Integer;

begin
  A:=Array of Integer.Create(1,2,3);
  Writeln(Length(A));
end.
\end{verbatim}
This approach also works recursively for multi-dimensional arrays:
\begin{verbatim}
Type
  TIntegerArray = Array of Integer;
  TIntegerArrayArray = Array of TIntegerArray;

var
  A : TIntegerArrayArray;

begin
  A:=TIntegerArrayArray.Create(TIntegerArray.Create(1,2,3),
                               TIntegerArray.Create(4,5,6),
                               TIntegerArray.Create(7,8,9));
  Writeln('Length ',length(A));
end.
\end{verbatim}
However, since it is a constructor (code is run at run-time) it is not possible to use this in an initialized variable syntax.
That is, the following will not work:
\begin{verbatim}
Type
  TIntegerArray = Array of Integer;

var
  A : TIntegerArray = TIntegerArray.Create(1,2,3);

begin
  Writeln('Length ',length(A));
end.
\end{verbatim}

\subsubsection{Dynamic array constant expressions}
As of version 3.2 of the compiler, an array can be constructed using an
array expression in an explicit assignment or in an initialized variable.
However, the expression is different. In an assignment statement, it
resembles a set expression, in an initializd variable, the same syntax as
for a constant array of fixed length must be used:
\begin{verbatim}
Type
  TIntegerArray = Array of Integer;

var
  A : TIntegerArray = (1,2,3);
  B : TIntegerArray;

begin
  B:=[3,4,5];
end.
\end{verbatim}


\subsubsection{Packing and unpacking an array}
Arrays can be packed and bitpacked. Two array types which have the same index
type and element type, but which are differently packed are not assignment
compatible.

However, it is possible to convert a normal array to a bitpacked array with the
\var{pack} routine. The reverse operation is possible as well; a bitpacked
array can be converted to a normally packed array using the \var{unpack}
routine, as in the following example:
\begin{verbatim}
Var
  foo : array [ 'a'..'f' ] of Boolean
    = ( false, false, true, false, false, false );
  bar : bitpacked array [ 42..47 ] of Boolean;
  baz : array [ '0'..'5' ] of Boolean;

begin
  pack(foo,'a',bar);
  unpack(bar,baz,'0');
end.
\end{verbatim}
More information about the \var{pack} and \var{unpack} routines can be found in the
\file{system} unit reference.

%
\subsection{Record types}
\index{Record}\index{Types!Record}\index{Fields}\keywordlink{record}
\fpc supports fixed records and records with variant parts.
The syntax diagram for a record type is
\input{syntax/typerec.syn}
\index{Packed} So the following are valid record type declarations:
\begin{verbatim}
Type
  Point = Record
          X,Y,Z : Real;
          end;
  RPoint = Record
          Case Boolean of
          False : (X,Y,Z : Real);
          True : (R,theta,phi : Real);
          end;
  BetterRPoint = Record
          Case UsePolar : Boolean of
          False : (X,Y,Z : Real);
          True : (R,theta,phi : Real);
          end;
\end{verbatim}
The variant part must be last in the record. The optional identifier in the
case statement serves to access the tag field value, which otherwise would
be invisible to the programmer. It can be used to see which variant is
active at a certain time\footnote{However, it is up to the programmer to maintain
this field.}. In effect, it introduces a new field in the record.
\begin{remark}
It is possible to nest variant parts, as in:
\begin{verbatim}
Type
  MyRec = Record
          X : Longint;
          Case byte of
            2 : (Y : Longint;
                 case byte of
                 3 : (Z : Longint);
                 );
          end;
\end{verbatim}
\end{remark}

\subsubsection{Record layout and size}

The layout and size of a record is influenced by five aspects:
\begin{itemize}
\item The size of its fields.
\item The alignment requirements of the types of the fields, which are
platform-dependent. Note that the alignment requirements of a type
inside a record may be different from those of a separate variable of
that type. Additionally, the location of a field inside a record may
also influence its type's alignment requirements.
\item The currently active \var{\{\$ALIGN N\}} or \var{\{\$PACKRECORDS
N\}} setting (these settings override each other, so the last one
specified is the active one; note that these directives to not accept
exactly the same arguments, see the programmer's manual for more
information).
\item The currently active \var{\{\$CODEALIGN RECORDMIN=X\}} setting.
\item The currently active \var{\{\$CODEALIGN RECORDMAX=X\}} setting.
\end{itemize}

The layout and size of variant parts in records is determined by
replacing them with a field whose type is a record with as first element
a field of the tag field type {\em if an identifier was declared for
this tag field}, followed by the elements of the biggest variant.

Field \var{F2}'s offset in a record is equal to the sum of the previous
field \var{F1}'s offset and \var{F1}'s size, rounded up to a multiple of
\var{F2}'s required alignment. This required alignment is calculated as
follows:
\begin{itemize}
\item The required alignment is set to the default alignment of the
field's type, possibly adjusted based on the fact that this type occurs
in a record and on the field's location in the record.
\item If the required alignment is smaller than the currently active
\var{\{\$CODEALIGN RECORDMIN=X\}} setting, it is changed to this \var{X}
value.
\item If the currently active \var{\{\$ALIGN N\}} or
\var{\{\$PACKRECORDS N\}} setting is
  \begin{itemize}
  \item a numerical value: if the required alignment is larger than
  \var{N}, it is changed to \var{N}. I.\,e., if \var{N} is 1, all fields
  will be placed right after each other.
  \item \var{RESET} or \var{DEFAULT}: the resulting required alignment
  is target dependent.
  \item \var{C}: the required alignment is adjusted according to the
  rules specified in the official ABI for the current platform.
  \item \var{POWER}/\var{POWERPC}, \var{MAC68K}: the alignment value's
  adjustment is determined by following the official ABI rules for
  resp.\ the (Classic) Macintosh PowerPC or Macintosh 680x0 platforms.
  \end{itemize}
\end{itemize}

The size of a record is equal to the sum of the record's last field's
offset and this field's size, rounded up to a multiple of the record's
required alignment. The record's required alignment is calculated as
follows:
\begin{itemize}
  \item The required alignment is set to the alignment of the record's
  field with the largest alignment, as determined while laying out the
  record.
  \item If the current \var{\{\$ALIGN N\}} or \var{\{\$PACKRECORDS
  N\}} setting is different from \var{C} and the required alignment is
  larger than than the currently active \var{\{\$CODEALIGN
  RECORDMAX=X\}}, the required alignment is changed to \var{X}.
  \item If the current \var{\{\$ALIGN N\}} or \var{\{\$PACKRECORDS
  N\}} setting is equal to \var{C}, the required alignment is determined
  by following the official ABI rules.
\end{itemize}

\subsubsection{Remarks and examples}

\fpc also supports a ``packed record'', which is a record where all the
elements are byte-aligned. As a result, the two following declarations
are equivalent:
\begin{verbatim}
     {$PackRecords 1}
     Trec2 = Record
       A : Byte;
       B : Word;
       end;
     {$PackRecords default}
\end{verbatim}
and
\begin{verbatim}
     Trec2 = Packed Record
       A : Byte;
       B : Word;
       end;
\end{verbatim}
Note the \var{\{\$PackRecords Default\}} after the first declaration to
restore the default setting!

Given the platform-dependent nature of how records are laid out in
memory, the only way to ensure a compatible layout across platforms
(assuming that all fields are declared using a type with the same
meaning across these same platforms) is by using \var{\{\$PACKRECORDS
1\}}.

In particular, if a typed file with records, produced by a \tp program,
must be read, then chances are that attempting to read that file
correctly will fail. The reason is that \fpc{}'s default
\var{\{\$PACKRECORDS N\}} setting is not necessarily compatible with
\tp{}'s. It can be changed to \var{\{\$PACKRECORDS 1\}} or
\var{\{\$PACKRECORDS 2\}} depending on the setting used in the \tp
program that create the file (although it may still fail with
\var{\{\$PACKRECORDS 2\}} due to different type alignment requirements
between 16 bit MSDOS and your current platform).

The same remark goes for \delphi{}: exchanging data is only guaranteed
to be possible if both the producer and consumer use a packed record, or
if they are on the same platform and use the same \var{\{\$PACKRECORDS
X\}} setting.


%
\subsection{Set types}
\index{Set}\index{Types!Set}\keywordlink{set}
\fpc supports the set types as in \tp. The prototype of a set
declaration is:
\input{syntax/typeset.syn}
Each of the elements of \var{SetType} must be of type \var{TargetType}.
\var{TargetType} can be any ordinal type with a range between \var{0} and
\var{255}. A set can contain at most \var{256} elements.
The following are valid set declaration:
\begin{verbatim}
Type
  Junk = Set of Char;
  Days = (Mon, Tue, Wed, Thu, Fri, Sat, Sun);

Var
  WorkDays : Set of days;
\end{verbatim}
Given these declarations, the following assignment is legal:
\begin{verbatim}
WorkDays := [Mon, Tue, Wed, Thu, Fri];
\end{verbatim}

Several operations can be done on sets: taking unions or differences, adding
or removing elements, comparisons. These are documented in
\sees{setoperators}

How the compiler stores sets depends on the mode and can be controlled with
a directive. For more information, see the programmer's guide.


%
%
\subsection{File types}
\index{File}\index{Text}\index{Types!File}\keywordlink{file}
File types are types that store a sequence of some base type, which can be
any type except another file type. It can contain (in principle) an infinite
number of elements.
File types are used commonly to store data on disk. However, nothing prevents the programmer,
from writing a file driver that stores its data for instance in memory.

Here is the type declaration for a file type:
\input{syntax/typefil.syn}
If no type identifier is given, then the file is an untyped file; it can be
considered as equivalent to a file of bytes. Untyped files require special
commands to act on them (see \var{Blockread}, \var{Blockwrite}).
The following declaration declares a file of records:
\begin{verbatim}
Type
  Point = Record
    X,Y,Z : real;
    end;
  PointFile = File of Point;
\end{verbatim}
Internally, files are represented by the \var{FileRec} record, which is
declared in the \file{Dos} or \file{SysUtils} units.

\keywordlink{Text}
A special file type is the \var{Text} file type, represented by the
\var{TextRec} record. A file of type \var{Text} uses special input-output
routines. The default \var{Input}, \var{Output} and \var{StdErr} file
types are defined in the system unit: they are all of type \var{Text}, and
are opened by the system unit initialization code.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Pointers
\section{Pointers}
\index{Pointer}\index{Types!Pointer}\keywordlink{pointer}
\fpc supports the use of pointers. A variable of the pointer type
contains an address in memory, where the data of another variable may be
stored. A pointer type can be defined as follows:
\input{syntax/typepoin.syn}
As can be seen from this diagram, pointers are typed, which means that
they point to a particular kind of data. The type of this data must be
known at compile time.

Dereferencing the pointer (denoted by adding \var{\^{}} after the variable
name) behaves then like a variable. This variable has the type declared in
the pointer declaration, and the variable is stored in the address that is
pointed to by the pointer variable.
Consider the following example:
\begin{verbatim}
Program pointers;
type
  Buffer = String[255];
  BufPtr = ^Buffer;
Var B  : Buffer;
    BP : BufPtr;
    PP : Pointer;
etc..
\end{verbatim}
In this example, \var{BP} {\em is a pointer to} a \var{Buffer} type; while \var{B}
{\em is} a variable of type \var{Buffer}. \var{B} takes 256 bytes memory,
and \var{BP} only takes 4 (or 8) bytes of memory: enough memory to store an
address.

The expression
\begin{verbatim}
 BP^
\end{verbatim}
is known as the dereferencing of \var{BP}. The result is of type \var{Buffer}, so
\begin{verbatim}
 BP^[23]
\end{verbatim}
Denotes the 23rd character in the string pointed to by \var{BP}.
\begin{remark} \fpc treats pointers much the same way as C does. This means
that a pointer to some type can be treated as being an array of this type.

From this point of view, the pointer then points to the zeroeth element of this array.
Thus the following pointer declaration
\begin{verbatim}
Var p : ^Longint;
\end{verbatim}
can be considered equivalent to the following array declaration:
\begin{verbatim}
Var p : array[0..Infinity] of Longint;
\end{verbatim}
The difference is that the former declaration allocates memory for the
pointer only (not for the array), and the second declaration allocates
memory for the entire array. If the former is used, the memory must be
allocated manually, using the \var{Getmem} function.
The reference \var{P\^{}} is then the same as \var{p[0]}. The following program
illustrates this maybe more clear:
\begin{verbatim}
program PointerArray;
var i : Longint;
    p : ^Longint;
    pp : array[0..100] of Longint;
begin
  for i := 0 to 100 do pp[i] := i; { Fill array }
  p := @pp[0];                     { Let p point to pp }
  for i := 0 to 100 do
    if p[i]<>pp[i] then
      WriteLn ('Ohoh, problem !')
end.
\end{verbatim}
\end{remark}
\fpc supports pointer arithmetic as C does. This means that, if \var{P} is a
typed pointer, the instructions
\begin{verbatim}
Inc(P);
Dec(P);
\end{verbatim}
will increase, respectively decrease the address the pointer points to
with the size of the type \var{P} is a pointer to. For example
\begin{verbatim}
Var P : ^Longint;
...
 Inc (p);
\end{verbatim}
will increase \var{P} by 4, because 4 is the size of a longint. If the
pointer is untyped, a size of 1 byte is assumed (i.\,e. as if the pointer were
a pointer to a byte: \var{\^{}byte}.)

Normal arithmetic operators \index{Operators} on pointers can also be used,
that is, the following are valid pointer arithmetic operations:
\begin{verbatim}
var  p1,p2 : ^Longint;
     L : Longint;
begin
  P1 := @P2;
  P2 := @L;
  L := P1-P2;
  P1 := P1-4;
  P2 := P2+4;
end.
\end{verbatim}
Here, the value that is added or subtracted {\em is } multiplied by the
size of the type the pointer points to. In the previous
example \var{P1} will be decremented by 16 bytes, and
\var{P2} will be incremented by 16.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Forward type declarations
\section{Forward type declarations}
\index{Forward}\index{Types!Forward declaration}
Programs often need to maintain a linked list of records. Each record then
contains a pointer to the next record (and possibly to the previous record
as well). For type safety, it is best to define this pointer as a typed
pointer, so the next record can be allocated on the heap using the \var{New}
call. In order to do so, the record should be defined something like this:
\begin{verbatim}
Type
  TListItem = Record
    Data : Integer;
    Next : ^TListItem;
  end;
\end{verbatim}
When trying to compile this, the compiler will complain that the
\var{TListItem} type is not yet defined when it encounters the \var{Next}
declaration: This is correct, as the definition is still being parsed.

To be able to have the \var{Next} element as a typed pointer, a ``Forward
type declaration'' must be introduced:
\begin{verbatim}
Type
  PListItem = ^TListItem;
  TListItem = Record
    Data : Integer;
    Next : PTListItem;
  end;
\end{verbatim}
When the compiler encounters a typed pointer declaration where the
referenced type is not yet known, it postpones resolving the reference till
later. The pointer definition is a ``Forward type declaration''.

The referenced type should be introduced later in the same \var{Type} block.
No other block may come between the definition of the pointer type and the referenced type.
Indeed, even the word \var{Type} itself may not re-appear: in effect it
would start a new type-block, causing the compiler to resolve all pending
declarations in the current block.

In most cases, the definition of the referenced type will follow immediately
after the definition of the pointer type, as shown in the above listing.
The forward defined type can be used in any type definition following its
declaration.

Note that a forward type declaration is only possible with pointer types and
classes, not with other types.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Procedural types
\section{Procedural types}
\index{Procedure}\index{Types!Procedural}\index{Procedural}
\fpc has support for procedural types, although it differs a little from
the \tp or \delphi implementation of them. The type declaration remains the
same, as can be seen in the following syntax diagram:
\input{syntax/typeproc.syn}
For a description of formal parameter lists, see \seec{Procedures}.
The two following examples are valid type declarations:
\begin{verbatim}
Type TOneArg = Procedure (Var X : integer);
     TNoArg = Function : Real;
var proc : TOneArg;
    func : TNoArg;
\end{verbatim}
One can assign the following values to a procedural type variable:
\begin{enumerate}
\item \var{Nil}, for both normal procedure pointers and method pointers.
\item A variable reference of a procedural type, i.\,e. another variable of
the same type.
\item A global procedure or function address, with matching function or
procedure header and calling convention.
\item A method address.
\end{enumerate}
Given these declarations, the following assignments are valid:
\begin{verbatim}
Procedure printit (Var X : Integer);
begin
  WriteLn (x);
end;
...
Proc := @printit;
Func := @Pi;
\end{verbatim}
From this example, the difference with \tp is clear: In Turbo
Pascal it isn't necessary to use the address operator (\var{@})
when assigning a procedural type variable, whereas in \fpc it is required.
In case the \var{-MDelphi} or \var{-MTP} switches are used, the address
operator can be dropped.
\begin{remark} The modifiers concerning the calling conventions
must be the same as the declaration;
i.\,e. the following code would give an error:
\begin{verbatim}
Type TOneArgCcall = Procedure (Var X : integer);cdecl;
var proc : TOneArgCcall;
Procedure printit (Var X : Integer);
begin
  WriteLn (x);
end;
begin
Proc := @printit;
end.
\end{verbatim}
Because the \var{TOneArgCcall} type is a procedure that uses the cdecl
calling convention.
\end{remark}

In case the \var{is nested} modified is added, then the procedural variable
can be used with nested procedures. This requires that the sources be
compiled in macpas or ISO mode, or that the \var{nestedprocvars} modeswitch
be activated:
\begin{verbatim}
{$modeswitch nestedprocvars}
program tmaclocalprocparam3;

type
  tnestedprocvar = procedure is nested;

var
  tempp: tnestedprocvar;

procedure p1( pp: tnestedprocvar);
begin
  tempp:=pp;
  tempp
end;

procedure p2( pp: tnestedprocvar);
var
  localpp: tnestedprocvar;
begin
  localpp:=pp;
  p1( localpp)
end;

procedure n;
begin
  writeln( 'calling through n')
end;

procedure q;

var qi: longint;

  procedure r;
  begin
    if qi = 1 then
      writeln( 'success for r')
    else
      begin
      writeln( 'fail');
      halt( 1)
    end
  end;

begin
  qi:= 1;
  p1( @r);
  p2( @r);
  p1( @n);
  p2( @n);
end;

begin
  q;
end.
\end{verbatim}

In case one wishes to assign methods of a class to a variable of procedural
type, the procedural type must be declared with the \var{of object}
modifier.

The two following examples are valid type declarations for method
procedural variables (also known as event handlers because of their use in GUI design):
\begin{verbatim}
Type TOneArg = Procedure (Var X : integer) of object;
     TNoArg = Function : Real of object;
var
  oproc : TOneArg;
  ofunc : TNoArg;
\end{verbatim}
A method of the correct signature can be assigned to these functions. When
called, \var{Self} will be pointing to the instance of the object that was
used to assign the method procedure.

The following object methods can be assigned to \var{oproc} and \var{ofunc}:
\begin{verbatim}
Type
  TMyObject = Class(TObject)
    Procedure DoX (Var X : integer);
    Function DoY: Real;
  end;

Var
  M : TMyObject;

begin
  oproc:=@M.DoX;
  ofunc:=@M.DOY;
end;
\end{verbatim}
When calling \var{oproc} and \var{ofunc}, \var{Self} will equal \var{M}.

This mechanism is sometimes called \var{Delegation}.

\begin{remark}
When comparing two variables of type method, only the method's address is compared,
not the instance pointer. That means that the following program will print \var{True}:
\begin{verbatim}
Type
  TSomeMethod = Procedure  of object;

  TMyObject = Class(TObject)
    Procedure DoSomething;
  end;

Procedure TMyObject.DoSomething;

begin
  Writeln('In DoSomething');
end;

var
  X,Y : TMyObject;
  P1,P2 : TSomeMethod;

begin
  X:=TMyObject.Create;
  Y:=TMyObject.Create;
  P1:=@X.DoSomething;
  P2:=@Y.DoSomething;
  Writeln('Same method : ',P1=P2);
end.
\end{verbatim}
If both pointers must be compared, a typecast to \var{TMethod} must be done, and
both pointers should be compared. \var{TMethod} is defined in the system
unit as follows:
\begin{verbatim}
TMethod = record
  Code : CodePointer;
  Data : Pointer;
end;
\end{verbatim}
The following program will therefore print False:
\begin{verbatim}
Type
  TSomeMethod = Procedure  of object;

  TMyObject = Class(TObject)
    Procedure DoSomething;
  end;

Procedure TMyObject.DoSomething;

begin
  Writeln('In DoSomething');
end;

var
  X,Y : TMyObject;
  P1,P2 : TMethod;

begin
  X:=TMyObject.Create;
  Y:=TMyObject.Create;
  P1:=TMethod(@X.DoSomething);
  P2:=TMethod(@Y.DoSomething);
  Writeln('Same method : ',(P1.Data=P2.Data) and (P1.Code=P1.Code));
end.
\end{verbatim}
\end{remark}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Variant types
\section{Variant types}
\index{Variant}\index{Types!Variant} \keywordlink{variant}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Definition
\subsection{Definition}
As of version 1.1, FPC has support for variants. For maximum variant support
it is recommended to add the \file{variants} unit to the uses clause of every
unit that uses variants in some way: the \file{variants} unit contains support for
examining and transforming variants other than the default support offered
by the \file{System} or \var{ObjPas} units.

The type of a value stored in a variant is only determined at runtime:
it depends what has been assigned to the variant. Almost any simple type
can be assigned to variants: ordinal types, string types, int64 types.

Structured types such as sets, records, arrays, files, objects and classes
are not assignment-compatible with a variant, as well as pointers.
Interfaces and COM or CORBA objects can be assigned to a
variant (basically because they are simply a pointer).\index{Interfaces}\index{COM}\index{CORBA}

This means that the following assignments are valid:
\begin{verbatim}
Type
  TMyEnum = (One,Two,Three);

Var
  V : Variant;
  I : Integer;
  B : Byte;
  W : Word;
  Q : Int64;
  E : Extended;
  D : Double;
  En : TMyEnum;
  AS : AnsiString;
  WS : WideString;

begin
  V:=I;
  V:=B;
  V:=W;
  V:=Q;
  V:=E;
  V:=En;
  V:=D;
  V:=AS;
  V:=WS;
end;
\end{verbatim}
And of course vice-versa as well.

A variant can hold an array of values: All elements in the array have
the\index{array} same type (but can be of type ``variant''). For a variant
that contains an array, the variant can be indexed:
\begin{verbatim}
Program testv;

uses variants;

Var
  A : Variant;
  I : integer;

begin
  A:=VarArrayCreate([1,10],varInteger);
  For I:=1 to 10 do
    A[I]:=I;
end.
\end{verbatim}
For the explanation of \var{VarArrayCreate}, see \unitsref.

Note that when the array contains a string, this is not considered an ``array
of characters'', and so the variant cannot be indexed to retrieve a character
at a certain position in the string.


\subsection{Variants in assignments and expressions}
As can be seen from the definition above, most simple types can be assigned
to a variant. Likewise, a variant can be assigned to a simple type: If
possible, the value of the variant will be converted to the type that is
being assigned to. This may fail: Assigning a variant containing a string
to an integer will fail unless the string represents a valid integer. In the
following example, the first assignment will work, the second will fail:
\begin{verbatim}
program testv3;

uses Variants;

Var
  V : Variant;
  I : Integer;

begin
  V:='100';
  I:=V;
  Writeln('I : ',I);
  V:='Something else';
  I:=V;
  Writeln('I : ',I);
end.
\end{verbatim}
The first assignment will work, but the second will not, as \var{Something else}
cannot be converted to a valid integer value. An \var{EConvertError} exception
will be the result.

The result of an expression involving a variant will be of type variant again,
but this can be assigned to a variable of a different type~-- if the result
can be converted to a variable of this type.

Note that expressions involving variants take more time to be evaluated, and
should therefore be used with caution. If a lot of calculations need to be
made, it is best to avoid the use of variants.

When considering implicit type conversions (e.\,g. byte to integer, integer to
double, char to string) the compiler will ignore variants unless a variant
appears explicitly in the expression.

\subsection{Variants and interfaces}
\index{Interfaces}
\begin{remark}
Dispatch interface support for variants is currently broken in the compiler.
\end{remark}

Variants can contain a reference to an interface~-- a normal interface
(descending from \var{IInterface}) or a dispatchinterface (descending
from \var{IDispatch}). Variants containing a reference to a dispatch
interface can be used to control the object behind it: the compiler will use
late binding to perform the call to the dispatch interface: there will be no
run-time checking of the function names and parameters or arguments given to
the functions. The result type is also not checked. The compiler will simply
insert code to make the dispatch call and retrieve the result.

This means basically, that you can do the following on Windows:
\begin{verbatim}
Var
  W : Variant;
  V : String;

begin
  W:=CreateOleObject('Word.Application');
  V:=W.Application.Version;
  Writeln('Installed version of MS Word is : ',V);
end;
\end{verbatim}
The line
\begin{verbatim}
  V:=W.Application.Version;
\end{verbatim}
is executed by inserting the necessary code to query the dispatch interface
stored in the variant \var{W}, and execute the call if the needed dispatch
information is found.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Type aliases
\section{Type aliases}
Type aliases are a way to give another name to a type, but can also be used
to create real new types. Which of the two depends on the way the type alias
is defined:
\input{syntax/typealias.syn}
The first case is just a means to give another name to a type:
\begin{verbatim}
Type
  MyInteger = Integer;
\end{verbatim}
This creates a new name to refer to the \var{Integer} type, but does not create an
actual new type. That is, two variables:
\begin{verbatim}
Var
  A : MyInteger;
  B : Integer;
\end{verbatim}
Will actually have the same type from the point of view of the compiler
(namely: \var{Integer}).

The above presents a way to make types platform independent, by only using the
alias types, and then defining these types for each platform individually.
Any programmer who then uses these custom types doesn't have to worry
about the underlying type size: it is opaque to him. It also allows to use shortcut names
for fully qualified type names. e.\,g. define \var{system.longint} as
\var{Olongint} and then redefine \var{longint}.

The alias is frequently seen to re-expose a type:
\begin{verbatim}
Unit A;

Interface

Uses B;

Type
  MyType = B.MyType;
\end{verbatim}
This construction is often seen after some refactoring, when moving some
declarations from unit \var{A} to unit \var{B}, to preserve backwards compatibility
of the interface of unit \var{A}.

The second case is slightly more subtle:
\begin{verbatim}
Type
  MyInteger = Type Integer;
\end{verbatim}
This not only creates a new name to refer to the \var{Integer} type, but
actually creates a new type. That is, two variables:
\begin{verbatim}
Var
  A : MyInteger;
  B :  Integer;
\end{verbatim}
Will not have the same type from the point of view of the compiler. However,
these two types will be assignment compatible.\index{Type!Compatibility}
That means that an assignment
\begin{verbatim}
  A:=B;
\end{verbatim}
will work.

The difference can be seen when examining type information:
\begin{verbatim}
If TypeInfo(MyInteger)<>TypeInfo(Integer) then
  Writeln('MyInteger and Integer are different types');
\end{verbatim}
The compiler function \var{TypeInfo} returns a pointer to the type
information in the binary. Since the two types \var{MyInteger} and
\var{Integer} are different, they will generate different type
information blocks, and the pointers will differ.

There are three consequences of having different types:
\begin{enumerate}
\item That they have different typeinfo, hence different RTTI (Run-Time Type Information).
\item They can be used in function overloads, that is
\begin{verbatim}
Procedure MyProc(A : MyInteger); overload;
Procedure MyProc(A : Integer); overload;
\end{verbatim}
will work. This will not work with a simple type alias.
\item They can be used in operator overloads, that is
\begin{verbatim}
Operator +(A,B : MyInteger) : MyInteger;
\end{verbatim}
will work too.
\end{enumerate}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Managed types
\section{Managed types}
\label{se:managedtypes}
By default, pascal types are unmanaged. That means that variables must be
explicitly initialized, finalized, memory allocated and so on.
However, in Object Pascal, several types are managed, which means that the
compiler initializes and finalizes variables of this type: this is necessary,
for instance for reference counted data types.

The following types are managed:
\begin{description}
\item[AnsiString] They are initialized  to \var{Nil}.
\item[UnicodeString] They are initialized  to \var{Nil}.
\item[WideString] They are initialized  to \var{Nil}.
\item[Interface] They are initialized  to \var{Nil}.
\item[Dynamic arrays] They are initialized  to \var{Nil}.
\end{description}
And any record or array whose elements contain managed types.

Class instances containing managed types are also initialized, but the class
instance pointer itself is not.

Variables of managed types will also be finalized: this means, in general, that their
reference count will be decreased at the latest at the end of the current scope.

\begin{remark}
Note that no assumption should be made about the exact time of this
finalization. All that is guaranteed that they are finalized when they go
out of scope.
\end{remark}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Variables
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Variables}
\index{Variables}\index{Variable}\index{Var}\keywordlink{var}
\label{ch:Variables}
\section{Definition}
Variables are explicitly named memory locations with a certain type. When
assigning values to variables, the \fpc compiler generates machine code
to move the value to the memory location reserved for this variable. Where
this variable is stored depends on where it is declared:

\begin{itemize}
\item Global variables are variables declared in a unit or program, but not
inside a procedure or function. They are stored in fixed memory locations,
and are available during the whole execution time of the program.
\item Local variables are declared inside a procedure or function. Their
value is stored on the program stack, i.\,e. not at fixed locations.
\end{itemize}

The \fpc compiler handles the allocation of these memory locations
transparently, although this location can be influenced in the declaration.

The \fpc compiler also handles reading values from or writing values to
the variables transparently. But even this can be explicitly handled by the
programmer when using properties.

Variables must be explicitly declared when they are needed. No memory is
allocated unless a variable is declared. Using a variable identifier (for
instance, a loop variable) which is not declared first, is an error which
will be reported by the compiler.

\section{Declaration}
The variables must be declared in a variable declaration block of a unit
or a procedure or function (\sees{blocks}). It looks as follows:\index{Var}
\input{syntax/vardecl.syn}

\keywordlink{cvar} \keywordlink{public}
This means that the following are valid variable declarations:
\keywordlink{absolute} \keywordlink{export}
\begin{verbatim}
Var
  curterm1 : integer;

  curterm2 : integer; cvar;
  curterm3 : integer; cvar; external;

  curterm4 : integer; external name 'curterm3';
  curterm5 : integer; external 'libc' name 'curterm9';

  curterm6 : integer absolute curterm1;

  curterm7 : integer; cvar;  export;
  curterm8 : integer; cvar;  public;
  curterm9 : integer; export name 'me';
  curterm10 : integer; public name 'ma';

  curterm11 : integer = 1 ;
\end{verbatim}
\index{external}

The difference between these declarations is as follows:
\begin{enumerate}
\item The first form (\var{curterm1}) defines a regular variable. The
compiler manages everything by itself.
\item The second form (\var{curterm2}) declares also a regular variable,
but specifies that the assembler name for this variable equals the name
of the variable as written in the source.
\item The third form (\var{curterm3}) declares a variable which is located
externally: the compiler will assume memory is located elsewhere, and that
the assembler name of this location is specified by the name of the
variable, as written in the source. The name may not be specified.
\item The fourth form is completely equivalent to the third, it declares a
variable which is stored externally, and explicitly gives the assembler
name of the location. If \var{cvar} is not used, the name must be specified.
\item The fifth form is a variant of the fourth form, only the name of the
library in which the memory is reserved is specified as well.
\item The sixth form declares a variable (\var{curterm6}), and tells the compiler that it is
stored in the same location as another variable (\var{curterm1}).
\item The seventh form declares a variable (\var{curterm7}), and tells the
compiler that the assembler label of this variable should be the name of the
variable (case sensitive) and must be made public. i.\,e. it can be
referenced from other object files.
\item The eighth form (\var{curterm8}) is equivalent to the seventh: ``public''
is an alias for ``export''.
\item The ninth and tenth form are equivalent: they specify the assembler
name of the variable.
\item the eleventh form declares a variable (\var{curterm11}) and
initializes it with a value (1 in the above case).
\end{enumerate}
Note that assembler names must be unique. It's not possible to declare or
export two variables with the same assembler name. In particular, do not
attempt to export variables with a public name that starts with \var{FPC\_};
the compiler uses some internal system routines with this name.



\section{Scope}
\index{Scope}
Variables, just as any identifier, obey the general rules of scope.
In addition, initialized variables are initialized when they enter scope:
\begin{itemize}
\item Global initialized variables are initialized once, when the program starts.
\item Local initialized variables are initialized each time the procedure is
entered.
\end{itemize}
Note that the behavior for local initialized variables is different from
the one of a local typed constant. A local typed constant behaves like a
global initialized variable.

\section{Initialized variables}
\label{se:initializedvars}\index{Variables!Initialized}
By default, simple variables in Pascal are not initialized after their declaration.
Any assumption that they contain 0 or any other default value is erroneous:
They can contain rubbish. To remedy this, the concept of initialized variables
exists. The difference with normal variables is that their declaration includes
an initial value, as can be seen in the diagram in the previous section.

\begin{remark}
2 exceptions to this rule exist:
\begin{enumerate}
\item Managed types are an exception to this rule: Managed types are always
initialized with a default value: in general this means setting the reference
count to zero, or setting the pointer value of the type to \var{Nil}.
See \sees{managedtypes}
\item Global variables are initialized with the equivalent of zero.
\end{enumerate}
\end{remark}

Note that the behavior of zeroing out certain variables can result in invalid
content for variables:
\begin{verbatim}
Type
  TWeekDays =
    (monday,tuesday,wednesday,thursday,friday,saturday,sunday);
  TWeekend = saturday..sunday;

var
  W : TWeekend;

begin
  Writeln(W);
end.
\end{verbatim}
The above will result, when run, in an error:
\begin{verbatim}
Runtime error 107 at $000000000040024A
$000000000040024A
$000000000042BF70
$00000000004001D2
\end{verbatim}
Therefore is is {\em Highly recommended} to always initialize variables
before using them.

This can be easily done in the declaration of the variables.
Given the declaration:
\begin{verbatim}
Var
  S : String = 'This is an initialized string';
\end{verbatim}
The value of the variable following will be initialized with the provided
value. The following is an even better way of doing this:
\begin{verbatim}
Const
  SDefault = 'This is an initialized string';

Var
  S : String = SDefault;
\end{verbatim}
Initialization is often used to initialize arrays and records. For arrays,
the initialized elements must be specified, surrounded by round brackets, and
separated by commas. The number of initialized elements must be exactly the
same as the number of elements in the declaration of the type.
As an example:
\begin{verbatim}
Var
  tt : array [1..3] of string[20] = ('ikke', 'gij', 'hij');
  ti : array [1..3] of Longint = (1,2,3);
\end{verbatim}
For constant records, each element of the record that you wish to initialize
must be specified in the form \var{Field: Value}, separated by semicolons, 
and surrounded by round brackets.\index{Record!Constant}. You can omit
fields that you don't wish to initialize, in fact you can skip all fields.
If you skip fields, the compiler will emit a warning.

As an example:
\begin{verbatim}
Type
  Point = record
    X,Y : Real
    end;
Var
  Origin : Point = (X:0.0; Y:0.0);
  Partial : Point = (X:0.0);
  Empty : Point = ();
\end{verbatim}
The above declarations will result in the following warnings:
\begin{verbatim}
iv.pp(7,27) Warning: Some fields coming after "X" were not initialized
iv.pp(8,20) Warning: Some fields coming after "" were not initialized
\end{verbatim}

The order of the fields in a constant record needs to be the same as in the type
declaration, otherwise a compile-time error will occur. 

\begin{remark}
It should be stressed that initialized variables are initialized when they
come into scope, in difference with typed constants, which are initialized
at program start.
This is also true for {\em local} initialized variables. Local initialized
variables are initialized whenever the routine is called. Any changes that
occurred in the previous invocation of the routine will be undone, because
they are again initialized.
\end{remark}

\begin{remark}
Care should be taken when using initialized pointer types such as \var{PChars}.
In the following examples, \var{S} is a pointer, pointing to a block of constant
(read-only) program data.
Assigning a character in the string will therefore not work. Assigning \var{S} itself will
of course work. The first routine will give an error, the second not:
\begin{verbatim}
procedure foo1;
var
  s: PChar = 'PChar';
begin
  s[0] := 'a';
end;

procedure foo2;
var
  s: PChar;
begin
  s := 'PChar';
  s[0] := 'a';
end;
\end{verbatim}
\end{remark}

\section{Initializing variables using default}
\label{se:initusingdefault}\index{Variables!Initialized}
Some variables must be initialized because they contain managed types.
For variables that are declared in the \var{var}  section of a function or in the main program, this happens automatically.
For variables that are allocated on the heap, this is not necessarily the case.

For this, the compiler contains the \var{Default} intrinsic. This function accepts a type identifier as the argument,
and will return a correctly initialized variable of that type. In essence, it will zero out the whole variable.

The following gives an example of its use:
\begin{verbatim}
type
  TRecord = record
    i: LongInt;
    s: AnsiString;
  end;

var
  i: LongInt;
  o: TObject;
  r: TRecord;
begin
  i := Default(LongInt); // 0
  o := Default(TObject); // Nil
  r := Default(TRecord); // ( i: 0; s: '')
end.
\end{verbatim}
The case where a variable is allocated on the heap, is more interesting:
\begin{verbatim}
type
  TRecord = record
    i: LongInt;
    s: AnsiString;
  end;

var
  i: ^LongInt;
  o: ^TObject;
  r: ^TRecord;
begin
  i:=GetMem(SizeOf(Longint));
  i^ := Default(LongInt); // 0
  o:=GetMem(SizeOf(TObject));
  o^ := Default(TObject); // Nil
  r:=GetMem(SizeOf(TRecord));
  r^ := Default(TRecord); // ( i: 0; s: '')
end.
\end{verbatim}
It works for all types, except the various file types (or complex types containing a file type).

\begin{remark}
\begin{itemize}
\item
For generics, the use of \var{Default} is especially useful, since the type of a variable may not
be known during the declaration of a generic. For more information \sees{genericdefault}.
\item
Function results are available as a \var{Result} identifier, and as such
resemble variables. They are not variables, but are treated as passed-by-reference
parameters. They are therefore not initialized.
\end{itemize}
\end{remark}

\section{Thread Variables}
\index{Thread Variables}\index{Threadvar}\keywordlink{threadvar}
For a program which uses threads, the variables can be really global, i.\,e. the same for all
threads, or thread-local: this means that each thread gets a copy of the variable.
Local variables (defined inside a procedure) are always thread-local. Global
variables are normally the same for all threads. A global variable can be
declared thread-local by replacing the \var{var} keyword at the start of the
variable declaration block with \var{Threadvar}:
\begin{verbatim}
Threadvar
  IOResult : Integer;
\end{verbatim}
If no threads are used, the variable behaves as an ordinary variable.
If threads are used then a copy is made
for each thread (including the main thread). Note that the copy is
made with the original value  of the variable, {\em not} with the
value of the variable at the time the thread is started.

Threadvars should be used sparingly: There is an overhead for retrieving
or setting the variable's value. If possible at all, consider using local
variables; they are always faster than thread variables.

Threads are not enabled by default. For more information about programming
threads, see the chapter on threads in the \progref.

\section{Properties}
\index{Properties}\keywordlink{property}
A global block can declare properties, just as they could be defined in a
class. The difference is that the global property does not need a class
instance: there is only one instance of this property. Other than that, a
global property behaves like a class property. The read/write specifiers for
the global property must also be regular procedures, not methods.

The concept of a global property is specific to \fpc, and does not exist in
Delphi. \var{ObjFPC} mode is required to work with properties.

The concept of a global property can be used to ``hide'' the location of the
value, or to calculate the value on the fly, or to check the values which
are written to the property.

The declaration is as follows:
\input{syntax/propvar.syn}

The following is an example:
\begin{verbatim}
{$mode objfpc}
unit testprop;

Interface

Function GetMyInt : Integer;
Procedure SetMyInt(Value : Integer);

Property
  MyProp : Integer Read GetMyInt Write SetMyInt;

Implementation

Uses sysutils;

Var
  FMyInt : Integer;

Function GetMyInt : Integer;

begin
  Result:=FMyInt;
end;

Procedure SetMyInt(Value : Integer);

begin
  If ((Value mod 2)=1) then
    Raise Exception.Create('MyProp can only contain even value');
  FMyInt:=Value;
end;

end.
\end{verbatim}
The read/write specifiers can be hidden by declaring them in another unit
which must be in the \var{uses} clause of the unit. This can be used to hide
the read/write access specifiers for programmers, just as if they were in a
\var{private} section of a class (discussed below). For the previous
example, this could look as follows:
\begin{verbatim}
{$mode objfpc}
unit testrw;

Interface

Function GetMyInt : Integer;
Procedure SetMyInt(Value : Integer);

Implementation

Uses sysutils;

Var
  FMyInt : Integer;

Function GetMyInt : Integer;

begin
  Result:=FMyInt;
end;

Procedure SetMyInt(Value : Integer);

begin
  If ((Value mod 2)=1) then
    Raise Exception.Create('Only even values are allowed');
  FMyInt:=Value;
end;

end.
\end{verbatim}
The unit \file{testprop} would then look like:
\begin{verbatim}
{$mode objfpc}
unit testprop;

Interface

uses testrw;

Property
  MyProp : Integer Read GetMyInt Write SetMyInt;

Implementation

end.
\end{verbatim}
More information about properties can be found in \seec{Classes}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Objects
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Objects}
\label{ch:Objects}
\index{Objects}\index{Types!Object}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Declaration
\section{Declaration}
\fpc supports object oriented programming. In fact, most  of the compiler is
written using objects. Here we present some technical questions regarding
object oriented programming in \fpc.

Objects should be treated as a special kind of record. The record contains
all the fields that are declared in the objects definition, and pointers
to the methods that are associated to the objects' type.

An object is declared just as a record would be declared; except that
now, procedures and functions can be declared as if they were part of the record.
Objects can ``inherit'' fields and methods from ``parent'' objects. This means
that these fields and methods can be used as if they were included in the
objects declared as a ``child'' object.

Furthermore, a concept of visibility \index{Visibility} is introduced:
fields, procedures and functions can be declared as \var{public},
\var{protected} or
\var{private}. By default, fields and methods are \var{public}, and
are exported outside the current unit.
\index{Visibility!Public}\index{Visibility!Private}

Fields or methods that are declared \var{private} are only accessible
in the current unit: their scope is limited to the implementation of the
current unit.\index{Scope}

The prototype declaration of an object is as follows:
\index{object}\keywordlink{object}
\input{syntax/typeobj.syn}
As can be seen, any visibility block can be specified multiple times, as
often as needed..\index{private}\index{public}

The following is a valid definition of an object:
\begin{verbatim}
Type
  TObj = object
  Private
    Caption : ShortString;
  Public
    Constructor init;
    Destructor done;
    Procedure SetCaption (AValue : String);
    Function GetCaption : String;
  end;
\end{verbatim}
It contains a constructor/destructor pair, and a method to get and set a
caption. The \var{Caption} field is private to the object: it cannot be accessed
outside the unit in which \var{TObj} is declared.

\begin{remark}
In MacPas mode, the \var{Object} keyword is replaced by the \var{class}
keyword for compatibility with other pascal compilers available on the Mac.
That means that objects cannot be used in MacPas mode.
\end{remark}
\begin{remark}\index{Packed}
\fpc also supports the packed object. This is the same as an object, only
the elements (fields) of the object are byte-aligned, just as in the packed
record.
The declaration of a packed object is similar to the declaration
of a packed record:
\begin{verbatim}
Type
  TObj = packed object
   Constructor init;
   ...
   end;
  Pobj = ^TObj;
Var PP : Pobj;
\end{verbatim}
Similarly, the \var{\{\$PackRecords \}} directive acts on objects as well.
\end{remark}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Abstract and sealed
\section{Abstract and sealed objects}
\index{Objects, abstract}\index{Objects, sealed}\index{abstract}\index{sealed}

An object can be declared as sealed. In that case, it is not possible to declare a descendent
object. The compiler will return an error if it encounters a declaration of a descendent:
\begin{verbatim} 
Type  
  TMyClass = object Sealed  
    x : integer;  
  end;  
 
  TMyClass2 = object(TMyClass)  
    Y : Integer;  
  end;  
 
begin  
end.
\end{verbatim} 

This will result in the following error:
\begin{verbatim} 
Error: Cannot create a descendant of the sealed class "TMyClass"
\end{verbatim} 

An abstract class is a class that cannot be used directly. 
Instead, a descendent class must always be used. 
However, for Delphi compatibility, the compiler ignores this directive.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Fields
\section{Fields}
\index{Fields}
Object Fields are like record fields. They are accessed in the same way as
a record field would be accessed: by using a qualified identifier. Given the
following declaration:
\begin{verbatim}
Type TAnObject = Object
       AField : Longint;
       Procedure AMethod;
       end;
Var AnObject : TAnObject;
\end{verbatim}
then the following would be a valid assignment:
\begin{verbatim}
  AnObject.AField := 0;
\end{verbatim}
Inside methods, fields can be accessed using the short identifier:
\begin{verbatim}
Procedure TAnObject.AMethod;
begin
  ...
  AField := 0;
  ...
end;
\end{verbatim}
Or, one can use the \var{self} identifier. The \var{self} identifier refers
to the current instance of the object:
\begin{verbatim}
Procedure TAnObject.AMethod;
begin
  ...
  Self.AField := 0;
  ...
end;
\end{verbatim}
One cannot access fields that are in a private or protected sections of an object from
outside the objects' methods. If this is attempted anyway, the compiler will complain about
an unknown identifier.

It is also possible to use the \var{with} statement with an object instance,
just as with a record:
\begin{verbatim}
With AnObject do
  begin
  Afield := 12;
  AMethod;
  end;
\end{verbatim}
In this example, between the \var{begin} and \var{end}, it is as if
\var{AnObject} was prepended to the \var{Afield} and \var{Amethod}
identifiers. More about this in \sees{With}.

\section{Class or Static fields}
\keywordlink{static}
An object can contain class or static fields: these fields are global to the object type,
and act like global variables, but are known only in the scope of the object.
The difference between static and class variables is purely the mode in which they work:
The \var{static} keyword will always work, the \var{class} keyword will need \var{\{\$MODE DELPHI\}}  or \var{\{\$MODE OBJFPC\}}.

They can be referenced from within the objects methods, but can also be referenced from
outside the object by providing the fully qualified name.

For instance, the output of the following program:
\begin{verbatim}
{$mode objfpc}
type
  cl=object
    l : longint; static;
    class var v : integer;
  end;

var
  cl1,cl2 : cl;

begin
  Writeln('Static');
  cl1.l:=2;
  writeln(cl2.l);
  cl2.l:=3;
  writeln(cl1.l);
  Writeln(cl.l);
  Writeln('Class');
  cl1.v:=4;
  writeln(cl2.v);
  cl2.v:=5;
  writeln(cl1.v);
  Writeln(cl.v);
end.
\end{verbatim}
will be the following
\begin{verbatim}
Static
2
3
3
Class
4
5
5
\end{verbatim}
Note that the last line of code references the object type itself (\var{cl}),
and not an instance of the object (\var{cl1} or \var{cl2}).


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Constructors and destructors
\section{Constructors and destructors }
\index{Constructor}\index{Destructor} \keywordlink{constructor}
\keywordlink{destructor}
\index{Virtual}
\label{se:constructdestruct}
As can be seen in the syntax diagram for an object declaration, \fpc supports
constructors and destructors. The programmer is responsible for calling the
constructor and the destructor explicitly when using objects.

The declaration of a constructor or destructor is as follows:
\input{syntax/construct.syn}
A constructor/destructor pair is {\em required} if the object uses virtual methods.\index{Virtual}
The reason is that for an object with virtual methods, some internal
housekeeping must be done: this housekeeping is done by the
constructor\footnote{A pointer to the VMT must be set up.}.

In the declaration of the object type, a simple identifier should be used
for the name of the constructor or destructor. When the constructor or destructor
is implemented, a qualified method identifier should be used,
i.\,e. an identifier of the form \var{objectidentifier.methodidentifier}.

\fpc supports also the extended syntax of the \var{New} and \var{Dispose}
procedures. In case a dynamic variable of an object type must be allocated
the constructor's name can be specified in the call to \var{New}.
The \var{New} is implemented as a function which returns a pointer to the
instantiated object. Consider the following declarations:
\begin{verbatim}
Type
  TObj = object;
   Constructor init;
   ...
   end;
  Pobj = ^TObj;
Var PP : Pobj;
\end{verbatim}
Then the following three calls are equivalent:
\begin{verbatim}
 pp := new (Pobj,Init);
\end{verbatim}
and
\begin{verbatim}
  new(pp,init);
\end{verbatim}
and also
\begin{verbatim}
  new (pp);
  pp^.init;
\end{verbatim}
In the last case, the compiler will issue a warning that the
extended syntax of \var{new} and \var{dispose} must be used to generate instances of an
object. It is possible to ignore this warning, but it's better programming practice to
use the extended syntax to create instances of an object.
Similarly, the \var{Dispose} procedure accepts the name of a destructor. The
destructor will then be called, before removing the object from the heap.

In view of the compiler warning remark, the following chapter presents the
Delphi approach to object-oriented programming, and may be considered a
more natural way of object-oriented programming.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Methods
\section{Methods}
\index{Methods}
Object methods are just like ordinary procedures or functions, only they
have an implicit extra parameter: \var{self}. Self points to the object
with which the method was invoked.\index{Self}
When implementing methods, the fully qualified identifier must be given
in the function header. When declaring methods, a normal identifier must be
given.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Method declaration
\subsection{Declaration}
The declaration of a method is much like a normal function or procedure
declaration, with some additional specifiers, as can be seen from the
following diagram, which is part of the object declaration:
\input{syntax/omethods.syn}
from the point of view of declarations, \var{Method definitions} are
normal function or procedure declarations.
Contrary to TP and Delphi, fields can be declared after methods in the same
block, i.\,e. the following will generate an error when compiling with Delphi
or \tp, but not with FPC:
\begin{verbatim}
Type
  MyObj = Object
    Field : Longint;
    Procedure Doit;
  end;
\end{verbatim}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Method invocation
\subsection{Method invocation}
Methods are called just as normal procedures are called, only they have an
object instance identifier prepended to them (see also \seec{Statements}).
To determine which method is called, it is necessary to know the type of
the method. We treat the different types in what follows.

\subsubsection{Normal static methods}
\index{Methods!Static}
Normal (static) methods are methods that have been declared without a \var{abstract}
or \var{virtual} keyword. When calling a static method, the declared (i.\,e.
compile time) method of the object is used.
For example, consider the following declarations:
\begin{verbatim}
Type
  TParent = Object
    ...
    procedure Doit;
    ...
    end;
  PParent = ^TParent;
  TChild = Object(TParent)
    ...
    procedure Doit;
    ...
    end;
  PChild = ^TChild;
\end{verbatim}
As it is visible, both the parent and child objects have a method called
\var{Doit}. Consider now the following declarations and calls:
\begin{verbatim}
Var
  ParentA,ParentB : PParent;
  Child           : PChild;

begin
   ParentA := New(PParent,Init);
   ParentB := New(PChild,Init);
   Child := New(PChild,Init);
   ParentA^.Doit;
   ParentB^.Doit;
   Child^.Doit;
\end{verbatim}
Of the three invocations of \var{Doit}, only the last one will call
\var{TChild.Doit}, the other two calls will call \var{TParent.Doit}.
This is because for static methods, the compiler determines at compile
time which method should be called. Since \var{ParentB} is of type
\var{TParent}, the compiler decides that it must be called with
\var{TParent.Doit}, even though it will be created as a \var{TChild}.
There may be times when the method that is actually called should
depend on the actual type of the object at run-time. If so, the method
cannot be a static method, but must be a virtual method.

\subsubsection{Virtual methods}
\index{Virtual}\index{Methods!Virtual}\keywordlink{virtual}
To remedy the situation in the previous section, \var{virtual} methods are
created. This is simply done by appending the method declaration with the
\var{virtual} modifier. The descendent object can then override the method
with a new implementation by re-declaring the method (with the same
parameter list) using the \var{virtual} keyword.

Going back to the previous example, consider the following alternative
declaration:
\begin{verbatim}
Type
  TParent = Object
    ...
    procedure Doit;virtual;
    ...
    end;
  PParent = ^TParent;
  TChild = Object(TParent)
    ...
    procedure Doit;virtual;
    ...
    end;
  PChild = ^TChild;
\end{verbatim}
As it is visible, both the parent and child objects have a method called
\var{Doit}. Consider now the following declarations and calls:
\begin{verbatim}
Var
  ParentA,ParentB : PParent;
  Child           : PChild;

begin
   ParentA := New(PParent,Init);
   ParentB := New(PChild,Init);
   Child := New(PChild,Init);
   ParentA^.Doit;
   ParentB^.Doit;
   Child^.Doit;
\end{verbatim}
Now, different methods will be called, depending on the actual run-time type
of the object. For \var{ParentA}, nothing changes, since it is created as
a \var{TParent} instance. For \var{Child}, the situation also doesn't
change: it is again created as an instance of \var{TChild}.

For \var{ParentB} however, the situation does change: Even though it was
declared as a \var{TParent}, it is created as an instance of \var{TChild}.
Now, when the program runs, before calling \var{Doit}, the program
checks what the actual type of \var{ParentB} is, and only then decides which
method must be called. Seeing that \var{ParentB} is of type \var{TChild},
\var{TChild.Doit} will be called. The code for this run-time checking of the actual type of an object is
inserted by the compiler at compile time.

The \var{TChild.Doit} is said to {\em override} the
\var{TParent.Doit}.\index{override} \index{inherited} \keywordlink{override}
\keywordlink{inherited}
It is possible to access the \var{TParent.Doit} from within the
var{TChild.Doit}, with the \var{inherited} keyword:
\begin{verbatim}
Procedure TChild.Doit;
begin
  inherited Doit;
  ...
end;
\end{verbatim}
In the above example, when \var{TChild.Doit} is called, the first thing it
does is call \var{TParent.Doit}.  The inherited keyword cannot be used in
static methods, only on virtual methods.

To be able to do this, the compiler keeps~-- per object type~-- a table with
virtual methods: the VMT (Virtual Method Table). This is simply a table
with pointers to each of the virtual methods: each virtual method has its
fixed location in this table (an index). The compiler uses this table to
look up the actual method that must be used. When a descendent object
overrides a method, the entry of the parent method is overwritten in the
VMT. More information about the VMT can be found in \progref.

As remarked earlier, objects that have a VMT must be initialized with a
constructor: the object variable must be initialized with a pointer to
the VMT of the actual type that it was created with.

%
\subsubsection{Abstract methods}
\index{Abstract}\index{Methods!Abstract}\index{Methods!Virtual}\keywordlink{abstract}
An abstract method is a special kind of virtual method. A method that is
declared \var{abstract} does not have an implementation for this method.
It is up to inherited objects to override and implement this method.

From this it follows that a method can not be abstract if it is not virtual
(this can be seen from the syntax diagram). A second consequence is that
an instance of an object that has an abstract method cannot be created
directly.

The reason is obvious: there is no method where the compiler could jump to!
A method that is declared \var{abstract} does not have an implementation for
this method. It is up to inherited objects to override and implement this
method. Continuing our example, take a look at this:
\begin{verbatim}
Type
  TParent = Object
    ...
    procedure Doit;virtual;abstract;
    ...
    end;
  PParent=^TParent;
  TChild = Object(TParent)
    ...
    procedure Doit;virtual;
    ...
    end;
  PChild = ^TChild;
\end{verbatim}
As it is visible, both the parent and child objects have a method called
\var{Doit}. Consider now the following declarations and calls:
\begin{verbatim}
Var
  ParentA,ParentB : PParent;
  Child           : PChild;

begin
   ParentA := New(PParent,Init);
   ParentB := New(PChild,Init);
   Child := New(PChild,Init);
   ParentA^.Doit;
   ParentB^.Doit;
   Child^.Doit;
\end{verbatim}
First of all, Line 3 will generate a compiler error, stating that one cannot
generate instances of objects with abstract methods: The compiler has
detected that \var{PParent} points to an object which has an abstract
method. Commenting line 3 would allow compilation of the program.
\begin{remark}
If an abstract method is overridden, the parent method cannot be called
with \var{inherited}, since there is no parent method; The compiler
will detect this, and complain about it, like this:
\begin{verbatim}
testo.pp(32,3) Error: Abstract methods can't be called directly
\end{verbatim}
If, through some mechanism, an abstract method is called at run-time,
then a run-time error will occur. (run-time error 211, to be precise)
\end{remark}

\subsubsection{Class or static methods}
Class methods or methods declared with the \var{static} directive are
methods that are global to the object type. When called, the implicit
``self'' pointer is not available. This means that normal methods cannot
be called, and none of the fields of an object can be accessed.
Class variables can be used, however.

Class or static methods are regular methods, they can be assigned to a procedural variable.

The following program demonstrates all this. The commented-out statements will not compile.
\begin{verbatim}
{$APPTYPE CONSOLE}
{$IFDEF FPC}{$MODE DELPHI}{$H+}{$ENDIF}
type
  TTest = object
    const Epsylon = 100;
    var f : integer;
    class var cv1,cv2:integer;
    procedure myproc;
    class procedure testproc;
    class procedure testproc2;static;
    procedure testproc3; static;
  end;

  procedure TTest.myproc;
  begin
    cv1:=0;
    f:=1;
  end;

  class procedure TTest.Testproc;
  begin
    cv1:=1;
    // f:=1;
  end;

  class procedure TTest.Testproc2;
  begin
    cv1:=2;
    // f:=1;
  end;

  procedure TTest.Testproc3;
  begin
    cv1:=3;
    // f:=1;
  end;


Var
  P : Procedure;

begin
  P:=@TTest.Myproc;
  P:=@TTest.Testproc;
  P:=@TTest.Testproc2;
  P:=@TTest.Testproc3;
end.
\end{verbatim}
Uncommenting one of the commented statements and trying to compile the resulting code will result in a compiler error:
\begin{verbatim}
ocv.pp(32,6) Error: Only class methods, class properties and
  class variables can be accessed in class methods
\end{verbatim}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Visibility
\section{Visibility}
\index{Visibility}\index{Scope}\index{Private}\index{Protected}\index{Public}
For objects, three visibility specifiers exist: \var{private}, \var{protected} and
\var{public}. If a visibility specifier is not specified, \var{public}
is assumed.
Both methods and fields can be hidden from a programmer by putting them
in a \var{private} section. The exact visibility rule is as follows:
\begin{description}
\item [Private\ ] All fields and methods that are in a \var{private} block,
can  only be accessed in the module (i.\,e. unit or program) that contains
the object definition.\keywordlink{private}
They can be accessed from inside the object's methods or from outside them
e.\,g. from other objects' methods, or global functions.
\item [Protected\ ] Is the same as \var{Private}, except that the members of
a \var{Protected} section are also accessible to descendent types, even if
they are implemented in other modules.\keywordlink{private}
\item [Public\ ] fields and methods are always accessible, from everywhere.
Fields and methods in a \var{public} section behave as though they were part
of an ordinary \var{record} type.\keywordlink{public}
\end{description}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Classes
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Classes}
\label{ch:Classes}\index{Classes}\index{Types!Class}\keywordlink{class}
In the Delphi approach to Object Oriented Programming, everything revolves
around  the concept of ``Classes''.  A class can be seen as a pointer to an
object, or a pointer to a record, with methods associated with it.

The difference between objects and classes is mainly that an object
is allocated on the stack, as an ordinary record would be, and that
classes are always allocated on the heap. In the following example:
\begin{verbatim}
Var
  A : TSomeObject; // an Object
  B : TSomeClass;  // a Class
\end{verbatim}
The main difference is that the variable \var{A} will take up as much
space on the stack as the size of the object (\var{TSomeObject}). The
variable \var{B}, on the other hand, will always take just the size of
a pointer on the stack. The actual class data is on the heap.

From this, a second difference follows: a class must {\em always} be initialized
through its constructor, whereas for an object, this is not necessary.
Calling the constructor allocates the necessary memory on the heap for the
class instance data.

\begin{remark}
In earlier versions of \fpc it was necessary, in order to use classes,
to put the \file{objpas} unit in the uses clause of a unit or program.
{\em This is no longer needed} as of version 0.99.12. As of this version,
the unit will be loaded automatically when the \var{-MObjfpc} or
\var{-MDelphi}  options are specified, or their corresponding directives are
used:
\begin{verbatim}
{$mode objfpc}
{$mode delphi}
\end{verbatim}
In fact, the compiler will give a warning if it encounters the
\file{objpas} unit in a uses clause.
\end{remark}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Class definitions
\section{Class definitions}
The prototype declaration of a class is as follows:\index{Class}
\input{syntax/typeclas.syn}

\begin{remark}
In MacPas mode, the \var{Object} keyword is replaced by the \var{class}
keyword for compatibility with other pascal compilers available on the Mac.
That means that in MacPas mode, the reserved word ``class'' in the above
diagram may be replaced by the reserved word ``object''.
\end{remark}

In a class declaration, as many visibility blocks as needed can be used:
the various blocks can be repeated, and there is no special order in
which they must appear.

Methods are normal function or procedure declarations.
As can be seen, the declaration of a class is almost identical to the
declaration of an object. The real difference between objects and classes
is in the way they are created (see further in this chapter).

The visibility of the different sections is as follows:\index{Scope}
\begin{description}
\item [Private\ ] \index{Private}\index{Visibility!Private} All fields and methods that are in a \var{private} block, can
only be accessed in the module (i.\,e. unit) that contains the class definition.
They can be accessed from inside the classes' methods or from outside them
(e.\,g. from other classes' methods)\keywordlink{private}
\item [Strict Private\ ] \index{Private!strict}\index{Visibility!Strict Private} All fields and methods that are in a
\var{strict private} block, can only be accessed from methods of the class
itself. Other classes or descendent classes (even in the same unit) cannot
access strict private members.  \keywordlink{strict}
\item [Protected\ ] \index{Protected}\index{Visibility!Protected}%
Is the same as \var{Private}, except that the members of
a \var{Protected} section are also accessible to descendent types, even if
they are implemented in other modules.\keywordlink{protected}
\item [Strict Protected\ ] \index{Protected}\index{Visibility!Strict Protected}%
Is the same as \var{Protected}, except that the members of
a \var{Protected} section are also accessible to other classes implemented in the
same unit. \var{Strict protected} members are only visible to descendent
classes, not to other classes in the same unit. \keywordlink{strict protected}
\item [Public\ ] \index{Public}\index{Visibility!Public} sections are always
accessible.\keywordlink{public}
\item [Published\ ] \index{Published}\index{Visibility!Published} From a
language perspective, this is the same as a \var{Public} section, but the compiler generates also type
information that is needed for automatic streaming of these classes if the compiler is in the
\var{\{\$M+\}} state. Fields defined in a \var{published} section must be of class type.
Array properties cannot be in a \var{published} section.\keywordlink{published}
\end{description}
In the syntax diagram, it can be seen that a class can list implemented
interfaces. This feature will be discussed in the next chapter.

Classes can contain \var{Class} methods: these are functions that do not
require an instance. The \var{Self} identifier is valid in such methods,
but refers to the class pointer (the VMT).

\begin{remark}
Like with functions and pointer types, sometimes a forward definition of a
class is needed. A class forward definition is simply the name of the class,
with the keyword \var{Class}, as in the following example:
\begin{verbatim}
Type
  TClassB = Class;
  TClassA = Class
    B : TClassB;
  end;

  TClassB = Class
   A : TClassA;
  end;
\end{verbatim}
When using a class forward definition, the class must be defined in the same
unit, in the same section (interface/implementation). It must not
necessarily be defined in the same type section.
\end{remark}

It is also possible to define class reference types:
\input{syntax/classref.syn}
Class reference types are used to create instances of a certain class, which
is not yet known at compile time, but which is specified at run time.
Essentially, a variable of a class reference type contains a pointer to the
definition of the specified class. This can be used to construct an instance
of the class corresponding to the definition, or to check inheritance.
The following example shows how it works:
\begin{verbatim}
Type
  TComponentClass = Class of TComponent;

Function CreateComponent(AClass: TComponentClass;
                         AOwner: TComponent): TComponent;

begin
  // ...
  Result:=AClass.Create(AOwner);
  // ...
end;
\end{verbatim}
This function can be passed a class reference of any class that descends
from \var{TComponent}. The following is a valid call:
\begin{verbatim}
Var
  C : TComponent;

begin
  C:=CreateComponent(TEdit,Form1);
end;
\end{verbatim}
On return of the \var{CreateComponent} function, \var{C} will contain an
instance of the class \var{TEdit}. Note that the following call will fail to
compile:
\begin{verbatim}
Var
  C : TComponent;

begin
  C:=CreateComponent(TStream,Form1);
end;
\end{verbatim}
because \var{TStream} does not descend from \var{TComponent}, and
\var{AClass} refers to a \var{TComponent} class. The compiler can
(and will) check this at compile time, and will produce an error.

References to classes can also be used to check inheritance:
\begin{verbatim}
  TMinClass = Class of TMyClass;
  TMaxClass = Class of TMyClassChild;

Function CheckObjectBetween(Instance : TObject) : boolean;

begin
  If not (Instance is TMinClass)
     or ((Instance is TMaxClass)
          and (Instance.ClassType<>TMaxClass)) then
    Raise Exception.Create(SomeError)
end;
\end{verbatim}
The above example will raise an exception if the passed instance
is not a descendent of \var{TMinClass} or a descendent of \var{TMaxClass}.

More about instantiating a class can be found in \sees{classinstantiation}.

\section{Abstract and sealed classes}
A class can be declared as \var{sealed}. In that case, it is not possible to
declare a descendent class. The compiler will return an error if it
encounters a declaration of a descendent:
\begin{verbatim}
{$mode objfpc}
{$h+}

Type
  TMyClass = Class Sealed
    x : integer;
  end;

  TMyClass2 = Class(TMyClass)
    Y : Integer;
  end;

begin
end.
\end{verbatim}
This will result in the following error:
\begin{verbatim}
Error: Cannot create a descendant of the sealed class "TMyClass"
\end{verbatim}

An abstract class is a class that cannot be instantiated directly. Instead,
a descendent class must always be instantiated.
However, for Delphi compatibility, the compiler ignores this directive.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Normal and static fields
\section{Normal and static fields}
\label{se:classfields}.
Classes can have fields. Depending on how they are defined, fields hold data specific to
an instance of a class or to the class as a whole. Whatever the way they were defined,
fields observe the rules of visibility just like any other member of the class.

\subsection{Normal fields/variables}
There are two ways to declare a normal field.
The first one is the classical way, similar to a definition in an object:

\begin{verbatim}
{$mode objfpc}
type
  cl=class
    l : longint;
  end;
var
  cl1,cl2 : cl;
begin
  cl1:=cl.create;
  cl2:=cl.create;
  cl1.l:=2;
  writeln(cl1.l);
  writeln(cl2.l);
end.
\end{verbatim}
will be the following
\begin{verbatim}
2
0
\end{verbatim}
The example demonstrates that values of fields are initialized with zero (or the equivalent of zero for non ordinal types:
empty string, empty array and so on).

The second way to declare a field (only available in more recent versions of \fpc) is using a \var{var} block:
\begin{verbatim}
{$mode objfpc}
type
  cl=class
  var
    l : longint;
  end;
\end{verbatim}
This definition is completely equivalent to the previous definition.

\begin{remark}
As of version 3.0 of the compiler, the compiler can re-order the fields in memory if this leads to better alignment and smaller instances.
That means that in an instance, the fields do not necessarily appear in the same order as in the declaration. RTTI generated for a class
will reflect this change.
\end{remark}


\subsection{Class fields/variables}
Similar to objects, a class can contain static fields or class variables:
these fields or variables are global to the class, and act like global
variables, but are known only as part of the class. They can be referenced
 from within the classes' methods, but can also be
referenced from outside the class by providing the fully qualified name.

Again, there are two ways to define class variables. The first one is equivalent
to the way it is done in objects, using a static modifier:

For instance, the output of the following program is the same as the output for
the version using an object:
\begin{verbatim}
{$mode objfpc}
type
  cl=class
    l : longint;static;
  end;
var
  cl1,cl2 : cl;
begin
  cl1:=cl.create;
  cl2:=cl.create;
  cl1.l:=2;
  writeln(cl2.l);
  cl2.l:=3;
  writeln(cl1.l);
  Writeln(cl.l);
end.
\end{verbatim}
The output of this will be the following:
\begin{verbatim}
2
3
3
\end{verbatim}
Note that the last line of code references the class type itself (\var{cl}),
and not an instance of the class (\var{cl1} or \var{cl2}).

In addition to the static field approach, in classes, a \var{Class Var} can be used.
Similar to the way a field can be defined in a variable block, a class variable can
be declared in a class var block:
\begin{verbatim}
{$mode objfpc}
type
  cl=class
  class var
    l : longint;
  end;
\end{verbatim}
This definition is equivalent to the previous one.

Note that a class variable is tied to a specific class. Descendent classes
will refer to the same instance, unless the variable is redeclared.
The following program demonstrates this:
\begin{verbatim}
{$mode objfpc}
type
  TA = class // base type
    class var CODE: integer;
  end;
  TB = class(TA);
  TC = class(TA);

begin
  TA.Code:=0;
  TB.Code:=1;
  TC.Code:=2;
  Writeln(Ta.Code:2,Tb.Code:2,Tc.code:2);
end.
\end{verbatim}
The output of this program is:
\begin{verbatim}
 2 2 2
\end{verbatim}
Because it is tied to a class, it can be overridden in delphi mode:
\begin{verbatim}
$mode delphi}
type
  TA = class // base type
    class var CODE: integer;
  end;
  TB = class(TA)
    Class var code : integer;
  end;
  TC = class(TA)
    Class var code : integer;
  end;

begin
  TA.Code:=0;
  TB.Code:=1;
  TC.Code:=2;
  Writeln(Ta.Code:2,Tb.Code:2,Tc.code:2);
end.
\end{verbatim}
It will print the following:
\begin{verbatim}
 0 1 2
\end{verbatim}
However, in OBJFPC mode it will not compile, and will give a duplicate
identifier error.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Class instantiation
\section{Class instantiation}
\label{se:classinstantiation}
\index{Constructor}\keywordlink{constructor}
Classes must be created using one of their constructors (there can be
multiple constructors). Remember that a class is a pointer to an object on
the heap. When a variable of some class is declared, the compiler just
allocates room for this pointer, not the entire object. The constructor of
a class returns a pointer to an initialized instance of the object on the
heap. So, to initialize an instance of some class, one would do the following:
\begin{verbatim}
  ClassVar := ClassType.ConstructorName;
\end{verbatim}
The extended syntax of \var{new} and \var{dispose} can {\em not} be used to
instantiate and destroy class instances:
That construct is reserved for use with objects only.
Calling the constructor will provoke a call to the virtual class method
\var{NewInstance}, which, in its default implementation, calls \var{GetMem}, to allocate
enough space to hold the class instance data, and then zeroes out the memory.

After that, the constructor's code is executed.
The constructor has a pointer to its data, in \var{Self}.

\begin{remark}
\begin{itemize}
\index{Packed}
\item The \var{\{\$PackRecords \}} directive also affects classes,
i.\,e. the alignment in memory of the different fields depends on the
value of  the \var{\{\$PackRecords \}} directive.
\item Just as for objects and records, a packed class can be declared.
This has the same effect as on an object, or record, namely that the
elements are aligned on 1-byte boundaries, i.\,e. as close as possible.
\item \var{SizeOf(class)} will return the same as \var{SizeOf(Pointer)},
since a class is a pointer to an object. To get the size of the class
instance data, use the \var{TObject.InstanceSize} method.
\item If an exception happens during an the execution of a constructor,
the destructor will be called automatically.
\end{itemize}
\end{remark}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Class destruction
\section{Class destruction}
\index{Destructor}\keywordlink{Destructor}
Class instances must be destroyed using the destructor. In difference with
the constructor, there is no choice in destructors: the destructor {\em must}
have the name \var{Destroy}, it {\em must}  override the \var{Destroy} destructor
declared in \var{TObject}, cannot have arguments, and the inherited destructor
must always be called.

\var{Destroy} will call \var{FreeInstance}, which, in its default implementation,
calls \var{FreeMem} to release the memory occupied by the instance.

To avoid calling a destructor on a \var{Nil} instance, it is best to call
the \var{Free} method of \var{TObject}. This method will check if \var{Self} is not \var{Nil},
and if so, then it calls \var{Destroy}. If \var{Self} equals \var{Nil}, it
will just exit.

Destroying an instance does not remove or Nil a reference to an instance:
\begin{verbatim}
Var
  A : TComponent;

begin
  A:=TComponent.Create;
  A.Name:='MyComponent';
  A.Free;
  Writeln('A is still assigned: ',Assigned(A));
end.
\end{verbatim}
After the call to \var{Free}, the variable A will not be \var{Nil}, the
output of this program will be:
\begin{verbatim}
A is still assigned: TRUE
\end{verbatim}
To make sure that the variable \var{A} is cleared after the destructor was called,
the function \var{FreeAndNil} from the \file{SysUtils} unit can be used. It
will call \var{Free} and will then write \var{Nil} in the object pointer (\var{A}
in the above example):
\begin{verbatim}
Var
  A : TComponent;

begin
  A:=TComponent.Create;
  A.Name:='MyComponent';
  FreeAndNil(A);
  Writeln('A is still assigned: ',Assigned(A));
end.
\end{verbatim}
After the call to \var{FreeAndNil}, the variable \var{A} will contain \var{Nil}, the
output of this program will be:
\begin{verbatim}
A is still assigned: FALSE
\end{verbatim}

\begin{remark}
if an exception happens during an the execution of a constructor,
the destructor will be called automatically.
\end{remark}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Methods
\section{Methods}
\index{Methods}
\subsection{Declaration}
Declaration of methods in classes follows the same rules as method
declarations in objects:
\input{syntax/cmethods.syn}
The only differences are the \var{override}, \var{reintroduce} and
\var{message} directives.

\subsection{Invocation}
Method invocation for classes is no different than for objects. The
following is a valid method invocation:
\begin{verbatim}
Var  AnObject : TAnObject;
begin
  AnObject := TAnObject.Create;
  ANobject.AMethod;
\end{verbatim}


\subsection{Virtual methods}
\index{Methods!Virtual}\index{Virtual}
Classes have virtual methods, just as objects do. There is however a
difference between the two. For objects, it is sufficient to redeclare the
same method in a descendent object with the keyword \var{virtual} to
override it. For classes, the situation is different: virtual methods
{\em must} be overridden with the \var{override} keyword. Failing to do so,
will start a {\em new} batch of virtual methods, hiding the previous
one.  The \var{Inherited} keyword will not jump to the inherited method, if
\var{Virtual} was used.

The following code is {\em wrong}:
\begin{verbatim}
Type
  ObjParent = Class
    Procedure MyProc; virtual;
  end;
  ObjChild  = Class(ObjPArent)
    Procedure MyProc; virtual;
  end;
\end{verbatim}
The compiler will produce a warning:
\begin{verbatim}
Warning: An inherited method is hidden by OBJCHILD.MYPROC
\end{verbatim}
The compiler will compile it, but using \var{Inherited} can\index{Inherited}
produce strange effects.

The correct declaration is as follows:
\begin{verbatim}
Type
  ObjParent = Class
    Procedure MyProc; virtual;
  end;
  ObjChild  = Class(ObjPArent)
    Procedure MyProc; override;
  end;
\end{verbatim}
This will compile and run without warnings or errors.\index{Override}

If the virtual method should really be replaced with a method with the
same name, then the \var{reintroduce} keyword can be used:\index{reintroduce}
\keywordlink{reintroduce}
\begin{verbatim}
Type
  ObjParent = Class
    Procedure MyProc; virtual;
  end;
  ObjChild  = Class(ObjPArent)
    Procedure MyProc; reintroduce;
  end;
\end{verbatim}
This new method is no longer virtual.

To be able to do this, the compiler keeps~-- per class type~-- a table with
virtual methods: the VMT (Virtual Method Table). This is simply a table
with pointers to each of the virtual methods: each virtual method has its
fixed location in this table (an index). The compiler uses this table to
look up the actual method that must be used at runtime. When a descendent object
overrides a method, the entry of the parent method is overwritten in the
VMT. More information about the VMT can be found in \progref.

\begin{remark}\keywordlink{dynamic}
The keyword ``virtual'' can be replaced with the ``dynamic'' keyword: dynamic
methods behave the same as virtual methods. Unlike in Delphi, in FPC the
implementation of dynamic methods is equal to the implementation of virtual
methods.
\end{remark}

\subsection{Class methods}
\index{Class}\index{Methods!Class}
Class methods are identified by the keyword \var{Class} in front of the
procedure or function declaration, as in the following example:
\begin{verbatim}
  Class Function ClassName : String;
\end{verbatim}
Class methods are methods that do not have an instance (i.\,e.\ Self does not
point to a class instance) but which follow the scoping and inheritance
rules of a class. They can be used to return information about the current
class, for instance for registration or use in a class factory. Since no
instance is available, no information available in instances can be used.

Class methods can be called from inside a regular method, but can also be called
using a class identifier:
\begin{verbatim}
Var
  AClass : TClass; // AClass is of type "type of class"

begin
  ..
  if CompareText(AClass.ClassName,'TCOMPONENT')=0 then
  ...

\end{verbatim}
But calling them from an instance is also possible:
\begin{verbatim}
Var
  MyClass : TObject;

begin
  ..
  if MyClass.ClassNameis('TCOMPONENT') then
  ...
\end{verbatim}
The reverse is not possible: Inside a class method, the \var{Self} identifier
points to the VMT\index{Self} table of the class. No fields, properties or
regular methods are available inside a class method. Accessing a regular
property or method will result in a compiler error.

Note that class methods can be virtual, and can be overridden.

Class methods can be used as read or write specifiers for a regular property,
but naturally, this property will have the same value for all instances of the
class, since there is no instance available in the class method.\index{Property}

\subsection{Class constructors and destructors}
A class constructor or destructor can also be created. They serve to instantiate some class variables or class properties which must be initialized before a class can be used.
These constructors are called automatically at program startup: The constructor is called before the initialization section of the unit it is declared in, the destructor is
called after the finalisation section of the unit it is declared in.

There are some caveats when using class destructors/constructors:
\begin{itemize}
\item There may be only one constructor per class. The name is arbitrary, but it can not have parameters.
\item There may be only one destructor per class. The name is arbitrary, but it can not have parameters.
\item Neither constructor nor destructor can be virtual.
\item The class constructor/destructor is called irrespective of the use of the class: even if a class is never used, the constructor and destructor are called anyway.
\item There is no guaranteed order in which the class constructors or destructors are called.
For nested classes, the only guaranteed order is that the constructors of
nested classes are called after the constructor of the encompassing class is
called, and for the destructors the opposite order is used.
\end{itemize}

The following program:

\begin{verbatim}
{$mode objfpc}
{$h+}

Type
  TA = Class(TObject)
  Private
    Function GetA : Integer;
    Procedure SetA(AValue : integer);

  public
    Class Constructor create;
    Class Destructor destroy;
    Property A : Integer Read GetA Write SetA;
  end;

{Class} Function TA.GetA : Integer;

begin
  Result:=-1;
end;

{Class} Procedure TA.SetA(AValue : integer);

begin
  //
end;

Class Constructor TA.Create;

begin
  Writeln('Class constructor TA');
end;

Class Destructor TA.Destroy;

begin
  Writeln('Class destructor TA');

end;

Var
  A : TA;

begin
end.
\end{verbatim}
Will, when run, output the following:
\begin{verbatim}
Class constructor TA
Class destructor TA
\end{verbatim}


\subsection{Static class methods}
\index{Methods!Static}\index{Static class methods}
FPC knows static class methods in classes: these are class methods that have the
\var{Static} keyword at the end. These methods behave completely like regular
procedures or functions. This means that:
\begin{itemize}
\item They do not have a \var{Self} parameter. As a result, they cannot access properties or fields or regular methods.
\item They cannot be virtual.
\item They can be assigned to regular procedural variables.
\end{itemize}
Their use is mainly to include the method in the namespace of the class as
opposed to having the procedure in the namespace of the unit.
Note that they do have access to all class variables, types etc, meaning something like this is possible:
\begin{verbatim}
 {$mode objfpc}
{$h+}

Type
  TA = Class(TObject)
  Private
    class var myprivatea : integer;
  public
    class Function GetA : Integer;  static;
    class Procedure SetA(AValue : Integer); static;
  end;

Class Function TA.GetA : Integer;

begin
  Result:=myprivateA;
end;

Class Procedure TA.SetA(AValue : integer);

begin
  myprivateA:=AValue;
end;


begin
  TA.SetA(123);
  Writeln(TA.MyPrivateA);
end.
\end{verbatim}
Which will output \var{123}, when run.

In the implementation of a static class method, the \var{Self} identifier is
not available. The method behaves as if \var{Self} is hardcoded to the
declared class, not the actual class with which it was called. In regular
class methods, \var{Self} contains the Actual class for which the method was
called.  The following example makes this clear:
\begin{verbatim}
Type
  TA = Class
    Class procedure DoIt; virtual;
    Class Procedure DoitStatic; static;
  end;

  TB = CLass(TA)
    Class procedure DoIt; override;
  end;


Class procedure TA.DOit;

begin
  Writeln('TA.Doit : ',Self.ClassName);
end;

Class procedure TA.DOitStatic;

begin
  Doit;
  Writeln('TA.DoitStatic : ',ClassName);
end;

Class procedure TB.DoIt;

begin
  Inherited;
  Writeln('TB.Doit : ',Self.ClassName);
end;

begin
  Writeln('Through static method:');
  TB.DoItStatic;
  Writeln('Through class method:');
  TB.Doit;
end.
\end{verbatim}
When run, this example will print:
\begin{verbatim}
Through static method:
TA.Doit : TA
TA.DoitStatic : TA
Through class method:
TA.Doit : TB
TB.Doit : TB
\end{verbatim}
For the static class method, even though it was called using \var{TB}, the class
(\var{Self}, if it were available) is set to \var{TA}, the class in which the
static method was defined.
For the class method, the class is set to the actual class used to call the method
(\var{TB}).

\subsection{Message methods}
\index{Methods!Message}
New in classes are \var{message} methods. Pointers to message methods are
stored in a special table, together with the integer or string constant that
they were declared with. They are primarily intended to ease programming of
callback functions in several \var{GUI} toolkits, such as \var{Win32} or
\var{GTK}. In difference with Delphi, \fpc also accepts strings as message
identifiers. Message methods are always virtual.
\index{Virtual}\index{message} \keywordlink{message}

As can be seen in the class declaration diagram, message methods are
declared with a \var{Message} keyword, followed by an integer constant
expression.

Additionally, they can take only one var argument (typed or not):\index{Message}
\begin{verbatim}
 Procedure TMyObject.MyHandler(Var Msg); Message 1;
\end{verbatim}
The method implementation of a message function is not different from an
ordinary method. It is also possible to call a message method directly,
but this should not be done. Instead, the \var{TObject.Dispatch} method
should be used.\index{Dispatch} Message methods are automatically virtual,
i.\,e. they can be overridden in descendent classes.

The \var{TObject.Dispatch} method can be used to call a
\var{message}\index{Message}
handler. It is declared in the \file{system} unit and will accept a var
parameter  which must have at the first position a cardinal with the
message ID that should be called. For example:
\begin{verbatim}
Type
  TMsg = Record
    MSGID : Cardinal;
    Data : Pointer;
Var
  Msg : TMSg;

MyObject.Dispatch (Msg);
\end{verbatim}
In this example, the \var{Dispatch} method will look at the object and all
its ancestors (starting at the object, and searching up the inheritance
class tree), to see if a message method with message \var{MSGID} has been
declared. If such a method is found, it is called, and passed the
\var{Msg} parameter.

If no such method is found, \var{DefaultHandler} is called.
\var{DefaultHandler} is a virtual method of \var{TObject} that doesn't do
anything, but which can be overridden to provide any processing that might be
needed. \var{DefaultHandler} is declared as follows:
\begin{verbatim}
   procedure DefaultHandler(var message);virtual;
\end{verbatim}

In addition to the message method with a \var{Integer} identifier,
\fpc also supports a message method with a string identifier:
\begin{verbatim}
 Procedure TMyObject.MyStrHandler(Var Msg); Message 'OnClick';
\end{verbatim}
The working of the string message handler is the same as the ordinary
integer message handler:

The \var{TObject.DispatchStr} \index{DispatchStr} method can be used to call a \var{message}
handler. It is declared in the \file{system} unit and will accept one parameter
which must have at the first position a short string with the message ID that
should be called. For example:
\begin{verbatim}
Type
  TMsg = Record
    MsgStr : String[10]; // Arbitrary length up to 255 characters.
    Data : Pointer;
Var
  Msg : TMSg;

MyObject.DispatchStr (Msg);
\end{verbatim}
In this example, the \var{DispatchStr} method will look at the object and
all its ancestors (starting at the object, and searching up the inheritance
class tree), to see if a message method with message \var{MsgStr} has been
declared. If such a method is found, it is called, and passed the
\var{Msg} parameter.

If no such method is found, \var{DefaultHandlerStr} is called.
\var{DefaultHandlerStr} is a virtual method of \var{TObject} that doesn't do
anything, but which can be overridden to provide any processing that might be
needed. \var{DefaultHandlerStr} is declared as follows:
\begin{verbatim}
   procedure DefaultHandlerStr(var message);virtual;
\end{verbatim}

\subsection{Using inherited}
In an overridden virtual method, it is often necessary to call the parent
class' implementation of the virtual method. This can be  done with the
\var{inherited} keyword. Likewise, the \var{inherited} keyword can be used
to call any method of the parent class.

The first case is the simplest:
\begin{verbatim}
Type
  TMyClass = Class(TComponent)
    Constructor Create(AOwner : TComponent); override;
  end;

Constructor TMyClass.Create(AOwner : TComponent);

begin
  Inherited;
  // Do more things
end;
\end{verbatim}
In the above example, the \var{Inherited} statement will call \var{Create}
of \var{TComponent}, passing it \var{AOwner} as a parameter: the same
parameters that were passed to the current method will be passed to the
parent's method. They must not be specified again: if none are specified,
the compiler will pass the same arguments as the ones received.

If no inherited method with the same name exists, the \var{Inherited} will have
no effect in this case. The presence of \var{Inherited} in this form can thus
be interpreted as ``call the overridden method if it exists''.

The second case is slightly more complicated:
\begin{verbatim}
Type
  TMyClass = Class(TComponent)
    Constructor Create(AOwner : TComponent); override;
    Constructor CreateNew(AOwner : TComponent; DoExtra : Boolean);
  end;

Constructor TMyClass.Create(AOwner : TComponent);
begin
  Inherited;
end;

Constructor TMyClass.CreateNew(AOwner : TComponent; DoExtra : Boolean);
begin
  Inherited Create(AOwner);
  // Do stuff
end;
\end{verbatim}
The \var{CreateNew} method will first call \var{TComponent.Create} and
will pass it \var{AOwner} as a parameter. It will not call
\var{TMyClass.Create}.

If no method with the given name exists in parent classes, the compiler will
give an error.

Although the examples were given using constructors, the use of
\var{inherited} is not restricted to constructors, it can be used
for any procedure or function or destructor as well.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Properties
\section{Properties}
\index{Properties}\keywordlink{property}
\subsection{Definition}
Classes can contain properties as part of their fields list. A property
acts like a normal field, i.\,e. its value can be retrieved or set, but it
allows to redirect the access of the field through functions and
procedures. They provide a means to associate an action with an assignment
of or a reading from a class ``field''. This allows e.\,g. checking that a
value is valid when assigning, or, when reading, it allows to construct the
value on the fly. Moreover, properties can be read-only or write only.
The prototype declaration of a property is as follows:\index{Property}
\input{syntax/property.syn}

A \var{read specifier} \index{Read} is either the name of a field that contains the
property, or the name of a method function that has the same return type as
the property type. In the case of a simple type, this
function must not accept an argument. In case of an array property, the
function must accept a single argument of the same type as the index.
In case of an indexed property, it must accept a integer as an argument.

A \var{read specifier} is optional, making the property write-only.
Note that class methods cannot be used as read specifiers.

A \var{write specifier} \index{Write} is optional: If there is no \var{write specifier}, the
property is read-only. A write specifier is either the name of a field, or
the name of a method procedure that accepts as a sole argument a variable of
the same type as the property. In case of an array property, the procedure
must accept two arguments: the first argument must have the same type as the
index, the second argument must be of the same type as the property.
Similarly, in case of an indexed property, the first parameter must be an integer.

The section \index{Private}\index{Published} (\var{private}, \var{published})
in which the specified function or procedure resides is irrelevant. Usually,
however, this will be a protected or private method.

For example, given the following declaration:
\begin{verbatim}
Type
  MyClass = Class
    Private
    Field1 : Longint;
    Field2 : Longint;
    Field3 : Longint;
    Procedure  Sety (value : Longint);
    Function Gety : Longint;
    Function Getz : Longint;
    Public
    Property X : Longint Read Field1 write Field2;
    Property Y : Longint Read GetY Write Sety;
    Property Z : Longint Read GetZ;
    end;

Var
  MyClass : TMyClass;
\end{verbatim}
The following are valid statements:
\begin{verbatim}
WriteLn ('X : ',MyClass.X);
WriteLn ('Y : ',MyClass.Y);
WriteLn ('Z : ',MyClass.Z);
MyClass.X := 0;
MyClass.Y := 0;
\end{verbatim}
But the following would generate an error:
\begin{verbatim}
MyClass.Z := 0;
\end{verbatim}
because Z is a read-only property.

What happens in the above statements is that when a value needs to be read,
the compiler inserts a call to the various \var{getNNN} methods of the
object, and the result of this call is used. When an assignment is made,
the compiler passes the value that must be assigned as a parameter to
the various \var{setNNN} methods.

Because of this mechanism, properties cannot be passed as var arguments to a
function or procedure, since there is no known address of the property (at
least, not always).\index{Parameters!Var}

\subsection{Indexed properties}
\index{Properties!Indexed}\keywordlink{index}
If the property definition contains an index, \index{index} then the read and write
specifiers must be a function and a procedure. Moreover, these functions
require an additional parameter : An integer parameter. This allows to read
or write several properties with the same function. For this, the properties
must have the same type.
The following is an example of a property with an index:
\begin{verbatim}
{$mode objfpc}
Type
  TPoint = Class(TObject)
  Private
    FX,FY : Longint;
    Function GetCoord (Index : Integer): Longint;
    Procedure SetCoord (Index : Integer; Value : longint);
  Public
    Property X : Longint index 1 read GetCoord Write SetCoord;
    Property Y : Longint index 2 read GetCoord Write SetCoord;
    Property Coords[Index : Integer]:Longint Read GetCoord;
  end;

Procedure TPoint.SetCoord (Index : Integer; Value : Longint);
begin
  Case Index of
   1 : FX := Value;
   2 : FY := Value;
  end;
end;

Function TPoint.GetCoord (INdex : Integer) : Longint;
begin
  Case Index of
   1 : Result := FX;
   2 : Result := FY;
  end;
end;

Var
  P : TPoint;

begin
  P := TPoint.create;
  P.X := 2;
  P.Y := 3;
  With P do
    WriteLn ('X=',X,' Y=',Y);
end.
\end{verbatim}
When the compiler encounters an assignment to \var{X}, then \var{SetCoord}
is called with as first parameter the index (1 in the above case) and with
as a second parameter the value to be set.
Conversely, when reading the value of \var{X}, the compiler calls
\var{GetCoord} and passes it index 1.
Indexes can only be integer values.

\subsection{Array properties}
Array properties also exist.\index{Properties!Array} These are properties that accept an
index, just as an array does. The index can be one-dimensional, or multi-dimensional.
In difference with normal (static or dynamic) arrays, the index of an array property
doesn't have to be an ordinal type, but can be any type.

A \var{read specifier} for an array property is the name method function
that has the same return type as the property type.
The function must accept as a sole argument a variable of the same type as
the index type. For an array property, one cannot specify fields as \var{read
specifiers}.

A \var{write specifier} for an array property is the name of a method
procedure that accepts two arguments: the first argument has the same
type as the index, and the second argument is a parameter of the same
type as the property type.
As an example, see the following declaration:
\begin{verbatim}
Type
  TIntList = Class
  Private
    Function GetInt (I : Longint) : longint;
    Function GetAsString (A : String) : String;
    Procedure SetInt (I : Longint; Value : Longint;);
    Procedure SetAsString (A : String; Value : String);
  Public
    Property Items [i : Longint] : Longint Read GetInt
                                           Write SetInt;
    Property StrItems [S : String] : String Read GetAsString
                                            Write SetAsstring;
  end;

Var
  AIntList : TIntList;
\end{verbatim}
Then the following statements would be valid:
\begin{verbatim}
AIntList.Items[26] := 1;
AIntList.StrItems['twenty-five'] := 'zero';
WriteLn ('Item 26 : ',AIntList.Items[26]);
WriteLn ('Item 25 : ',AIntList.StrItems['twenty-five']);
\end{verbatim}
While the following statements would generate errors:
\begin{verbatim}
AIntList.Items['twenty-five'] := 1;
AIntList.StrItems[26] := 'zero';
\end{verbatim}
Because the index types are wrong.

Array properties can be multi-dimensional:
\begin{verbatim}
Type
  TGrid = Class
  Private
    Function GetCell (I,J : Longint) : String;
    Procedure SetCell (I,J : Longint; Value : String);
  Public
    Property Cellcs [Row,Col : Longint] : String Read GetCell
                                            Write SetCell;
  end;
\end{verbatim}
If there are N dimensions, then the types of the first N arguments of the getter and
setter must correspond to the types of the N index specifiers in the array property definition.


\subsection{Default properties}
Array properties can be declared as \var{default} properties. This means that
it is not necessary to specify the property name when assigning or reading
it. In the previous example, if the definition of the items property would
have been
\begin{verbatim}
 Property Items[i : Longint]: Longint Read GetInt
                                      Write SetInt; Default;
\end{verbatim}
Then the assignment
\begin{verbatim}
AIntList.Items[26] := 1;
\end{verbatim}
Would be equivalent to the following abbreviation.
\begin{verbatim}
AIntList[26] := 1;
\end{verbatim}
Only one default property per class is allowed, but descendent classes
can redeclare the default property.

\subsection{Published properties}
Classes compiled in the \var{\{\$M+\}} state (such as \var{TPersistent} from
the \file{classes} unit) can have a published section. For methods, fields
and properties in the \var{Published} section, the compiler generates RTTI
information (Run Time Type Information), which can be used to query the
defined methods, fields and properties in the published section(s). The
\var{typinfo} unit contains the necessary routines to query this
information, and this unit is used in the streaming system in FPC in the
classes unit.

The RTTI is generated regardless of what the read and write specifiers are:
fields, functions/procedures or indexed functions/procedures.

Only class-typed fields can be published. For properties, any simple property
whose size is less than or equal to a pointer, can be declared published:
floats, integers, sets (with less than 32 distinct elements), enumerated,
classes or dynamic arrays (not array properties).

Although run-time type information is available for other types, these types cannot
be used for a property or field definition in a published section. The
information is present to describe for example arguments of procedures or functions.

\subsection{Storage information}
The compiler offers two specifiers to control whether a property is streamed
using a streaming mechanism, such as the one implemented in the classes
unit. These specifiers write extra information to the generated RTTI, which
is later used in the streaming system:

\begin{enumerate}
\item The {\em stored} specifier.
\item The {\em default} specifier and its counterpart {\em nodefault}.
\end{enumerate}
These two specifiers are both evaluated to decide whether a property must be
streamed.

The argument to the \var{stored} specifier should be either a boolean constant,
a boolean field of the class, or a parameterless function which returns a boolean
result. If the argument of the stored specifier evaluates to \var{False},
the property will not be streamed.

\begin{remark}
Absence of a \var{stored} specifier is equivalent to \var{stored True}.
\end{remark}

If the evaluation of \var{Stored} resulted in \var{True}, the default for a
property is considered:

The \var{default} specifier can be specified for ordinal types and sets.
Properties that have as value this default value, will not be written to
the stream by the streaming system, even if \var{Stored} is \var{True}.
The default value is stored in the RTTI that is generated for the class.

String, floating-point and pointer properties have implicit \var{default}
value of empty string, 0 or nil, respectively.
Ordinal and set properties have no implicit \var{default} value.

The \var{nodefault} specifier must be used to indicate
that a property has no default value. The effect is that the value of this
property is always written to the stream when streaming the property, if
stored is \var{True}.

\begin{remark}
\begin{enumerate}
\item When the class is instantiated, the default value is not automatically
applied to the property, it is the responsibility of the programmer to do
this in the constructor of the class.
\item The value -2147483648 cannot be used as a default value, as it is used
internally to denote \var{nodefault}.
\item It is not possible to specify a default for array properties.
\item It is not possible to specify the \var{Stored} directive for array properties.
\item All storage specifiers can be overridden in descendent classes.
\begin{verbatim}
property Test stored False;
\end{verbatim}
\item The \var{nodefault} specifier can be used to override the implicit
\var{default} specifier of string, floating-point and pointer properties.
\item The streaming mechanism described here is the one implemented in the
\file{classes} unit of the RTL. Other streaming mechanisms can be
implemented, and they can use the RTTI information in a different way.
\end{enumerate}
\end{remark}

\subsection{Overriding and redeclaring properties}
Properties can be both overridden and redeclared in descendent classes.

Property {\em redeclaration} takes action if the property type is declared, otherwise it is property {\em override}.
The only difference is that property {\em override} replaces or extends the inherited modifiers with the new modifiers,
whereas property {\em redeclaration} hides all inherited modifiers that are not present in the redeclaration.
The type of the redeclared property does not have to be the same as the parent''s class property type.

The example below demonstrates the difference between property {\em override} and {\em redeclaration}.
\begin{verbatim}
type
  TAncestor = class
  private
    FP1 : Integer;
  public
    property P: integer Read FP1 write FP1;
  end;

  TP1 = class(TAncestor)
  public
    // property override
    property P default 1;
  end;

  TPReadOnly = class(TAncestor)
  public
    // property redeclaration
    property P: integer Read FP1;
  end;
\end{verbatim}

\var{TP1} extends \var{property P} with a default value, \var{TPReadOnly} redeclares \var{property P} as read-only.

\begin{remark}
\var{TP1} should set the default value of \var{P} to \var{1} in its constructor.
\end{remark}

In case of both property {\em redeclaration} and property {\em override}, the access
to the getter and setter is always static.
I.e. property {\em override} acts only on the RTTI of the object and is not to be confused with method override.

The keyword ``inherited'' \index{inherited} can be used to refer to the parent
definition of the property. For example consider the following code:
\begin{verbatim}
type
  TAncestor = class
  private
    FP1 : Integer;
  public
    property P: integer Read FP1 write FP1;
  end;

  TClassA = class(TAncestor)
  private
    procedure SetP(const AValue: char);
    function getP : Char;
  public
    constructor Create;
    property P: char Read GetP write SetP;
  end;

procedure TClassA.SetP(const AValue: char);

begin
  Inherited P:=Ord(AValue);
end;

procedure TClassA.GetP : char;

begin
  Result:=Char((Inherited P) and $FF);
end;
\end{verbatim}
TClassA redefines \var{P} as a character property instead of an integer
property, but uses the parent''s \var{P} property to store the value.

Care must be taken when using virtual get/set routines for a property:
setting the inherited property still observes the normal rules of inheritance
for methods. Consider the following example:
\begin{verbatim}
type
  TAncestor = class
  private
    procedure SetP1(const AValue: integer); virtual;
  public
    property P: integer write SetP1;
  end;

  TClassA = class(TAncestor)
  private
    procedure SetP1(const AValue: integer); override;
    procedure SetP2(const AValue: char);
  public
    constructor Create;
    property P: char write SetP2;
  end;

constructor TClassA.Create;
begin
  inherited P:=3;
end;
\end{verbatim}
In this case, when setting the inherited property \var{P}, the
implementation \var{TClassA.SetP1} will be called, because the
\var{SetP1} method is overridden.

If the parent class implementation of \var{SetP1} must be called,
then this must be called explicitly:
\begin{verbatim}
constructor TClassA.Create;
begin
  inherited SetP1(3);
end;
\end{verbatim}

The redeclared ancestor properties are also available from inside and outside
the descendant object with a direct cast to the ancestor:
\begin{verbatim}
function GetP(const AClassA: TClassA): Integer;
begin
  Result := TAncestor(AClassA).P;
end;
\end{verbatim}

\section{Class properties}
Class properties are very much like global property definitions. They are
associated with the class, not with an instance of the class.

A consequence of this is that the storage for the property value must be a
class var, not a regular field or variable of the class: normal fields or
variables are stored in an instance of the class.

Class properties can have a getter and setter method like regular
properties, but these must be static methods of the class.

That means that the following contains a valid class property definition:
\begin{verbatim}
TA = Class(TObject)
Private
  class var myprivatea : integer;
  class Function GetB : Integer;  static;
  class Procedure SetA(AValue : Integer); static;
  class Procedure SetB(AValue : Integer); static;
public
  Class property MyA : Integer Read MyPrivateA Write SetA;
  Class property MyA : Integer Read GetB Write SetB;
end;
\end{verbatim}
The reason for the requirement is that a class property is associated to
the particular class in which it is defined, but not to descendent classes.
Since class methods can be virtual, this would allow descendent classes
to override the method, making them unsuitable for class property access.



% Nested types
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Nested types, constants and variables}
A class definition can contain a type section, const section and a variable section.
The type and constant sections act as a regular type section as found in a unit or
method/function/procedure implementation. The variables act as regular fields of the
class, unless they are in a \var{class var} section, in which case they act as if they
were defined at the unit level, within the namespace of the class (\sees{classfields}).

However, the visibility of these sections does play a role: private and protected
(strict or not) constants, types and variables can only be used as far as their
visibility allows.

Public types can be used outside the class, by their full name:
\begin{verbatim}
type
  TA = Class(TObject)
  Public
    Type TEnum = (a,b,c);
    Class Function DoSomething : TEnum;
  end;

Class Function TA.DoSomething : TEnum;

begin
  Result:=a;
end;

var
  E : TA.TEnum;

begin
  E:=TA.DoSomething;
end.
\end{verbatim}
Whereas
\begin{verbatim}
type
  TA = Class(TObject)
  Strict Private
    Type TEnum = (a,b,c);
  Public
    Class Function DoSomething : TEnum;
  end;

Class Function TA.DoSomething : TEnum;

begin
  Result:=a;
end;

var
  E : TA.TEnum;

begin
  E:=TA.DoSomething;
end.
\end{verbatim}
Will not compile and will return an error:
\begin{verbatim}
tt.pp(20,10) Error: identifier idents no member "TEnum"
\end{verbatim}

Note that for writeable constants, the same rules apply as for class
variables with regard to scope and overriding in descendents:
\begin{verbatim}
{$mode delphi}{$J+}
type
  TA = class // base type
    const CODE: integer = 99;
  end;
  TB = class(TA);
  TC = class(TA);

begin
  TA.Code:=0;
  TB.Code:=1;
  TC.Code:=2;
  Writeln(Ta.Code:2,Tb.Code:2,Tc.code:2);
end.
\end{verbatim}
Will write
\begin{verbatim}
 2 2 2
\end{verbatim}
But
\begin{verbatim}
{$mode delphi}{$J+}
type
  TA = class // base type
    const CODE: integer = -99;
  end;
  TB = class(TA)
    const code : integer = -98;
  end;
  TC = class(TA)
    Const code : integer = -97;
  end;

begin
  TA.Code:=0;
  TB.Code:=1;
  TC.Code:=2;
  Writeln(Ta.Code:2,Tb.Code:2,Tc.code:2);
end.
\end{verbatim}
Will write
\begin{verbatim}
 0 1 2
\end{verbatim}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Interfaces
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Interfaces}
\label{ch:Interfaces}\index{Interfaces}
\section{Definition}
As of version 1.1, FPC supports interfaces. Interfaces are an
alternative to multiple inheritance (where a class can have multiple
parent classes) as implemented for instance in C++.  An interface is
basically a named set of methods and properties: a class that
{\em implements} the interface provides {\em all} the methods as
they are enumerated in the Interface definition. It is not possible for a
class to implement only part of the interface: it is all or nothing.

Interfaces can also be ordered in a hierarchy, exactly as classes:
an interface definition that inherits from another interface definition
contains all the methods from the parent interface, as well as the methods
explicitly named in the interface definition. A class implementing an
interface must then implement all members of the interface as well as the
methods of the parent interface(s).

An interface can be uniquely identified by a GUID. GUID is an acronym for
Globally Unique Identifier, a 128-bit integer guaranteed always to be
unique\footnote{In theory, of course.}. Especially on Windows systems,
the GUID of an interface can and must be used when using COM.

The definition of an Interface has the following
form:\index{interface}\keywordlink{interface}
\input{syntax/typeintf.syn}
Along with this definition the following must be noted:
\begin{itemize}
\item Interfaces can only be used in \var{DELPHI} mode or in \var{OBJFPC}
mode.
\item There are no visibility specifiers. All members are public (indeed,
it would make little sense to make them private or
protected).\index{Visibility}
\item The properties declared in an interface can only have methods as read and
write specifiers.
\item There are no constructors or destructors. Instances of interfaces
cannot be created directly: instead, an instance of a class implementing
the interface must be created.
\item Only calling convention modifiers may be present in the definition of
a method. Modifiers as \var{virtual}, \var{abstract} or \var{dynamic}, and
hence also \var{override} cannot be present in the interface
definition.
\end{itemize}
The following are examples of interfaces:
\begin{verbatim}
IUnknown = interface ['{00000000-0000-0000-C000-000000000046}']
  function QueryInterface(const iid : tguid;out obj) : longint;
  function _AddRef : longint;
  function _Release : longint;
end;
IInterface = IUnknown;

IMyInterface = Interface
  Function MyFunc : Integer;
  Function MySecondFunc : Integer;
end;
\end{verbatim}
As can be seen, the GUID identifying the interface is optional.

\section{Interface identification: A GUID}
An interface can be identified by a GUID. This is a 128-bit number, which is
represented in a text representation (a string literal):
\begin{verbatim}
['{HHHHHHHH-HHHH-HHHH-HHHH-HHHHHHHHHHHH}']
\end{verbatim}
Each \var{H} character represents a hexadecimal number (0--9, A--F). The format
contains 8-4-4-4-12 numbers. A GUID can also be represented by the following
record, defined in the \file{objpas} unit (included automatically when in
\var{DELPHI} or \var{OBJFPC} mode):
\begin{verbatim}
PGuid = ^TGuid;
TGuid = packed record
   case integer of
      1 : (
           Data1 : DWord;
           Data2 : word;
           Data3 : word;
           Data4 : array[0..7] of byte;
          );
      2 : (
           D1 : DWord;
           D2 : word;
           D3 : word;
           D4 : array[0..7] of byte;
          );
      3 : ( { uuid fields according to RFC4122 }
           time_low : dword;
           time_mid : word;
           time_hi_and_version : word;
           clock_seq_hi_and_reserved : byte;
           clock_seq_low : byte;
           node : array[0..5] of byte;
           );
end;
\end{verbatim}
A constant of type TGUID can be specified using a string literal:
\begin{verbatim}
{$mode objfpc}
program testuid;

Const
  MyGUID : TGUID = '{10101010-1010-0101-1001-110110110110}';

begin
end.
\end{verbatim}
Normally, the GUIDs are only used in Windows, when using COM interfaces.
More on this in the next section.

\section{Interface implementations}
\index{Interfaces!Implementations}
When a class implements an interface, it should implement all methods of the
interface. If a method of an interface is not implemented, then the compiler
will give an error. For example:
\begin{verbatim}
Type
  IMyInterface = Interface
    Function MyFunc : Integer;
    Function MySecondFunc : Integer;
  end;

  TMyClass = Class(TInterfacedObject,IMyInterface)
    Function MyFunc : Integer;
    Function MyOtherFunc : Integer;
  end;

Function TMyClass.MyFunc : Integer;

begin
  Result:=23;
end;

Function TMyClass.MyOtherFunc : Integer;

begin
  Result:=24;
end;
\end{verbatim}
will result in a compiler error:
\begin{verbatim}
Error: No matching implementation for interface method
"IMyInterface.MySecondFunc:LongInt" found
\end{verbatim}

Normally, the names of the methods that implement an interface, must
equal the names of the methods in the interface definition. The compiler
will look for matching methods in all visible methods: the methods of the
class, and in parent classes methods with visibility protected or higher. 

However, it is possible to provide aliases for methods that make up an
interface: that is, the compiler can be told that a method of an interface
is implemented by an existing method with a different name.
This is done as follows:
\begin{verbatim}
Type
  IMyInterface = Interface
    Function MyFunc : Integer;
  end;

  TMyClass = Class(TInterfacedObject,IMyInterface)
    Function MyOtherFunction : Integer;
    Function IMyInterface.MyFunc = MyOtherFunction;
  end;
\end{verbatim}
This declaration tells the compiler that the \var{MyFunc} method of
the \var{IMyInterface} interface is implemented in the \var{MyOtherFunction}
method of the \var{TMyClass} class.

\section{Interface inheritance}
It is possible to let one interface be a descendent from another interface:
\begin{verbatim}
IParentInterface = interface
  ['{0F78D56E-85A6-4024-98D7-720D7C7B9573}']
  procedure Foo;
end;

IChildInterface = interface(IParentInterface)
  ['{1AB2EB85-6843-462E-8CE4-32ECC065011E}']
  procedure Bar;
end;
\end{verbatim}
\var{IChildInterface} will have two methods: \var{foo} and \var{bar}.
Any class implementing this interface will therefore need to implement both interfaces:
\begin{verbatim}
TImplementor = class(TInterfacedObject, IChildInterface)
public
  procedure Foo;
  procedure Bar;
end;

procedure TImplementor.Foo;
begin

end;

procedure TImplementor.Bar;
begin

end;
\end{verbatim}

Note that when a class declares a child interface, it can be assigned to a variable with the child interface.
Given the above declarations, the following will compile:
\begin{verbatim}
var
  Child: IChildInterface;

begin
  Child := TImplementor.Create;
\end{verbatim}
But this does not imply that it automatically also is assignment compatible with a variable with the type of parent interface. The following will not compile:
\begin{verbatim}
var
  Parent: IParentInterface;

begin
  Parent := TImplementor.Create;
\end{verbatim}
To make this compile, it is necessary to declare the class as:
\begin{verbatim}
TImplementor = class(TInterfacedObject,
                     IParentInterface,
                     IChildInterface)
public
  procedure Foo;
  procedure Bar;
end;
\end{verbatim}
The reason for this is that although the class actually implements the methods of \var{IParentInterface}, the compiler checks only actually declared interfaces when checking assignment compatibility: all declared interfaces are put in a table and only the contents of this table is checked.

The same check is performed at runtime: the compiler generates a table of all interfaces a class declares, and this table is checked at runtime. That means that although the following will compile if only \var{IChildInterface} is declared:
\begin{verbatim}
 ParentImplementorInstance := (TImplementor.Create as IParentInterface);
\end{verbatim}
it will still fail with a run-time error:
\begin{verbatim}
home:~> ./ti
An unhandled exception occurred at $0000000000411A27:
EInvalidCast: Invalid type cast
$0000000000411A27
\end{verbatim}

\section{Interface delegation}
Sometimes, the methods of an interface are implemented by a helper (or
delegate) object, or the class instance has obtained an interface pointer for
this interface and that should be used. This can be for instance when an
interface must be added to a series of totally unrelated classes: the needed
interface functionality is added to a separate class, and each of these
classes uses an instance of the helper class to implement the functionality.

In such a case, it is possible to instruct the compiler that the interface
is not implemented by the object itself, but actually resides in a helper
class or interface. This can be done with the \var{implements} property modifier.

If the class has a pointer to the desired interface, the following will
instruct the compiler that when the \var{IMyInterface} interface is
requested, it should use the reference in the field:
\begin{verbatim}
type
  IMyInterface = interface
    procedure P1;
  end;

  TMyClass = class(TInterfacedObject, IMyInterface)
  private
    FMyInterface: IMyInterface; // interface type
  public
    property MyInterface: IMyInterface
       read FMyInterface implements IMyInterface;
  end;
\end{verbatim}
The interface should not necessarily be in a field, any read identifier can
be used.

If the interface is implemented by a delegate object, (a helper object that
actually implements the interface) then it can be used as well with the
\var{implements} keyword:
\begin{verbatim}
{$interfaces corba}
type
  IMyInterface = interface
    procedure P1;
  end;

  // NOTE: Interface must be specified here
  TDelegateClass = class(TObject, IMyInterface)
  private
    procedure P1;
  end;

  TMyClass = class(TInterfacedObject, IMyInterface)
  private
    FMyInterface: TDelegateClass; // class type
    property MyInterface: TDelegateClass
      read FMyInterface implements IMyInterface;
  end;
\end{verbatim}
Note that in difference with Delphi, the delegate class must explicitly
specify the interface: the compiler will not search for the methods in the
delegate class, it will simply check if the delegate class implements the
specified interface.

It is possible to implement multiple interfaces using a single delegated
object:
\begin{verbatim}
{$interfaces corba}
type
  IMyInterface = interface
    procedure P1;
  end;
  IMyInterface1 = interface
    procedure P2;
  end;

  // NOTE: Interface must be specified here
  TDelegateClass = class(TObject, IMyInterface,IMyInterface1)
  private
    procedure P1;
    procedure P2;
  end;

  TMyClass = class(TInterfacedObject, IMyInterface, IMyInterface1)
  private
    FMyInterface: TDelegateClass; // class type
    property MyInterface: TDelegateClass
      read FMyInterface implements IMyInterface,IMyInterface1;
  end;
\end{verbatim}

It is not possible to mix method resolution and interface delegation.
That means, it is not possible to implement part of an interface through
method resolution and implement part of the interface through delegation.
The following attempts to implement \var{IMyInterface} partly through method
resolution (P1), and partly through delegation. The compiler will not accept
the following code:
\begin{verbatim}
{$interfaces corba}
type
  IMyInterface = interface
    procedure P1;
    procedure P2;
  end;


  TMyClass = class(TInterfacedObject, IMyInterface)
    FI : IMyInterface;
  protected
    procedure IMyInterface.P1 = MyP1;
    procedure MyP1;
    property MyInterface: IMyInterface  read FI implements IMyInterface;
  end;
\end{verbatim}
The compiler will throw an error:
\begin{verbatim}
Error: Interface "IMyInterface" can't be delegated by "TMyClass",
it already has method resolutions
\end{verbatim}

However, it is possible to implement one interface through method
resolution, and another through delegation:
\begin{verbatim}
{$interfaces corba}
type
  IMyInterface = interface
    procedure P1;
  end;

  IMyInterface2 = interface
    procedure P2;
  end;

  TMyClass = class(TInterfacedObject,
                   IMyInterface, IMyInterface2)
    FI2 : IMyInterface2;
  protected
    procedure IMyInterface.P1 = MyP1;
    procedure MyP1;
  public
    property MyInterface: IMyInterface2
       read FI2 implements IMyInterface2;
  end;
\end{verbatim}

Note that interface delegation can be used to specify that a class
implements parent interfaces:
\begin{verbatim}
IGMGetFileName = interface(IUnknown)
  ['{D3ECCB42-A563-4cc4-B375-79931031ECBA}']
  function GetFileName: String; stdcall;
  property FileName: String read GetFileName;
end;

IGMGetSetFileName = Interface(IGMGetFileName)
  ['{ECFB879F-86F6-41a3-A685-0C899A2B5BCA}']
  procedure SetFileName(const Value: String); stdcall;
  property FileName: String read GetFileName write SetFileName;
end;

TIntfDelegator = class(TInterfacedObject, IGMGetFileName, IGMGetSetFileName)
 protected
  FGetSetFileName: IGMGetSetFileName;
 public
  constructor Create;
  destructor Destroy; override;
  property Implementor: IGMGetSetFileName read FGetSetFileName
    implements IGMGetFileName, IGMGetSetFileName;
end;
\end{verbatim}

\section{Interfaces and COM}
\index{COM}\index{Interfaces!COM}
When using interfaces on Windows which should be available to the COM
subsystem, the calling convention should be \var{stdcall}~-- this is not the
default \fpc calling convention, so it should be specified explicitly.

COM does not know properties. It only knows methods. So when specifying
property definitions as part of an interface definition, be aware that the
properties will only be known in the \fpc compiled program: other Windows
programs will not be aware of the property definitions.

\section{CORBA and other Interfaces}
\index{CORBA}\index{COM}\index{Interfaces!CORBA}
COM is not the only architecture where interfaces are used. CORBA knows
interfaces, UNO (the OpenOffice API) uses interfaces, and Java as well.
These languages do not know the \var{IUnknown} interface used as the basis of
all interfaces in COM. It would therefore be a bad idea if an interface
automatically descended from \var{IUnknown} if no parent interface was
specified. Therefore, a directive \var{\{\$INTERFACES\}} was introduced in
 \fpc: it specifies what the parent interface is of an interface, declared
without parent. More information about this directive can be found in the
\progref.

Note that COM interfaces are by default reference counted, because they
descend from \var{IUnknown}.\index{Types!Reference counted}

Corba interfaces are identified by a simple string so they are assignment
compatible with strings and not with \var{TGUID}. The compiler does not do
any automatic reference counting for the CORBA interfaces, so the programmer
is responsible for any reference bookkeeping.

\section{Reference counting}
All COM interfaces use reference counting.  This means that whenever an
interface is assigned to a variable, its reference count is updated.
Whenever the variable goes out of scope, the reference count is
automatically decreased. When the reference count reaches zero, usually the
instance of the class that implements the interface, is freed.

Care must be taken with this mechanism. The compiler may or may not create
temporary variables when evaluating expressions, and assign the interface
to a temporary variable, and only then assign the temporary variable to
the actual result variable. No assumptions should be made about the number
of temporary variables or the time when they are finalized~-- this may
(and indeed does) differ from the way other compilers (e.\,g.\ Delphi) handle
expressions with interfaces. E.\,g. a type cast is also an expression:
\begin{verbatim}
Var
  B : AClass;

begin
  // ...
  AInterface(B.Intf).testproc;
  // ...
end;
\end{verbatim}
Assume the interface \var{intf} is reference counted. When the compiler
evaluates \var{B.Intf}, it creates a temporary variable. This variable may be
released only when the procedure exits: it is therefore invalid to e.\,g.
free the instance \var{B} prior to the exit of the procedure, since when the
temporary variable is finalized, it will attempt to free \var{B} again.

Additionally, function results may point to a non-nil valid COM interface on
entry: this is because the function result is treated as a var parameter.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Generics
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Generics}
\label{ch:generics}
\index{Generics}\index{Type!Generics}
\section{Introduction}
\label{se:genericsintroduction}
Generics are templates for generating other types. These can be classes, objects, interfaces and even functions, arrays, records.
It is a concept that comes from C++, where it is deeply integrated in the language.
As of version 2.2, Free Pascal also officially has support for templates or Generics.
They are implemented as a kind of macro which is stored in the unit files that the compiler generates,
and which is replayed as soon as a generic class is specialized.

Creating and using generics is a 2-phase process.
\begin{enumerate}
\item The definition of the generic is defined as a new type:
this is a code template, a macro which can be replayed by the compiler
at a later stage.
\item A generic type is specialized: this defines a second type,
which is a specific implementation of the generic type: the compiler
replays the macro which was stored when the generic type was defined.
\end{enumerate}
There are several units distributed with free pascal that implement generic
containers and classes. For example the \file{fgl} unit.

\section{Generic type definition}
A generic type definition is much like a type definition, with the exception that it contains a list of placeholders for types,
as can be seen in the following syntax diagram:
\input{syntax/generic.syn}
\index{generic}\index{Type!Generics}\keywordlink{generic} 
For classes, objects, procedural types and extended records, the generic
type declaration should be followed by a type implementation.
It is the same as a normal class implementation with a single exception,
namely that any identifier with the same name as one of the template
identifiers must be a type identifier.

So, the generic type declaration is much like a normal type declaration, except that there is an as yet unknown type present.
The unknown types are listed in the placeholder list, and they are unknown until the class is specialized.

The following is a valid generic class definition:
\begin{verbatim}
Type
  generic TList<_T>=class(TObject)
  Public
    type
       TCompareFunc = function(const Item1, Item2: _T): Integer;
    var
      data : _T;
    procedure Add(item: _T);
    procedure Sort(compare: TCompareFunc);
  end;
\end{verbatim}
This class could be followed by an implementation as follows:
\begin{verbatim}
procedure TList.Add(item: _T);
begin
  data:=item;
end;

procedure TList.Sort(compare: TCompareFunc);
begin
  if compare(data, 20) <= 0 then
    halt(1);
end;
\end{verbatim}
There are some noteworthy things about this declaration and implementation:
\begin{enumerate}
\item There is a single placeholder \var{\_T}. It will be substituted by a
type identifier when the generic class is specialized. The identifier
\var{\_T} may not be used for anything else than a type placeholder.
This means that the following would be invalid:
\begin{verbatim}
procedure TList.Sort(compare: TCompareFunc);

Var
  _t : integer;

begin
  // do something.
end;
\end{verbatim}
\item The local type block contains a single type \var{TCompareFunc}. Note
that the actual type is not yet known inside the generic class definition:
the definition contains a reference to the placeholder \var{\_T}. All other
identifier references must be known when the generic class is defined, {\em not}
when the generic class is specialized.
\item The local variable block is equivalent to the following:
\begin{verbatim}
  generic TList<_T>=class(TObject)
  Public
    type
       TCompareFunc = function(const Item1, Item2: _T): Integer;
  Public
    data : _T;
    procedure Add(item: _T);
    procedure Sort(compare: TCompareFunc);
  end;
\end{verbatim}
\item Note that the type parameter names in declaration and implementation must be the
same.
\end{enumerate}

Not only generic classes can be defined, but also other types:
\begin{verbatim}
{$mode objfpc}
{$INTERFACES CORBA}
type

  generic PlanarCoordinate<t> = record
    x,y : t;
  end;

  TScreenCoordinate = specialize PLanarCoordinate<word>;
  TDiscreteCoordinate = specialize PlanarCoordinate<integer>;
  TRealCoordinate = specialize PlanarCoordinate<extended>;

  generic TDistanceFunction<t> = function (x,y : t) : Extended of object;

  TScreenDistance = specialize TDistanceFunction<word>;
  TDiscreteDistance = specialize TDistanceFunction<integer>;
  TRealDistance = specialize TDistanceFunction<Extended>;

  generic TArray<t> = array of t;

  TMyIntegerArray = specialize TArray<integer>;

  generic IList<_T> = Interface
    Function GetItem(AIndex : Integer) : _T;
    Procedure SetItem(AIndex : Integer; AValue : _T);
    Function GetCount : Integer;
    Property Items [AIndex : Integer] : _T Read GetItem Write SetItem;
    Property Count : Integer Read GetCount;
  end;

  generic TList<_T>=class(TObject, specialize IList<_T>)
  public type
    TCompareFunc = function(const Item1, Item2: _T): Integer;
    Function GetItem(AIndex : Integer) : _T;
    Procedure SetItem(AIndex : Integer; AValue : _T);
    Function GetCount : Integer;
  Public
     data : _T;
     procedure Add(item: _T);
     procedure Sort(compare: TCompareFunc);
  end;

  generic TPointSet<t> = array of specialize PlanarCoordinate<t>;

  TScreenPointSet = specialize TPointSet<word>;
  TDiscretePointSet =  specialize TPointSet<integer>;
  TRealPointSet = specialize TPointSet<extended>;
\end{verbatim}

\begin{remark}
A word on visibility: the template types \var{T} or \var{\_T} are available as strict private types.
That means that the types are not available in the descendent classes, unless they are made available
through some protected or private mechanism, as in the following example:
\begin{verbatim}
  generic TList<_T>=class(TObject)
  public type
    TItemType = _T;
  end;
\end{verbatim}
\end{remark}

\section{Generic type specialization}
Once a generic type is defined, it can be used to generate other types:
this is like replaying the definition of the types, with the template
placeholders filled in with actual type definitions.

This can be done in any \var{Type} definition block. The specialized type
looks as follows:
\input{syntax/specialize.syn}
\index{specialize}\index{Type!Specializing}\keywordlink{specialize} 
Which is a very simple definition. Given the declaration of \var{TList} in
the previous section, the following would be a valid type definition:
\begin{verbatim}
Type
  TPointerList = specialize TList<Pointer>;
  TIntegerList = specialize TList<Integer>;
\end{verbatim}
As of version 3.0 of Free Pascal, the specialize keyword can also be used in a variable declaration:
\begin{verbatim}
Var
  P : specialize TList<Pointer>;
\end{verbatim}
The \var{specialize} keyword is part of the specialized type, so when using
fully qualified names, the specialize keyword must be after the unit name
and parent type names.

The type in the specialize statement must be known, except in another generic type definition.
Given the two generic class definitions:
\begin{verbatim}
type
  Generic TMyFirstType<T1> = Class(TMyObject);
  Generic TMySecondType<T2> = Class(TMyOtherObject);
\end{verbatim}
Then the following specialization is not valid:
\begin{verbatim}
type
  TMySpecialType = specialize TMySecondType<TMyFirstType>;
\end{verbatim}
because the type \var{TMyFirstType} is a generic type, and thus not fully defined.  The compiler will complain:
\begin{verbatim}
Error: Generics cannot be used as parameters when specializing generics
\end{verbatim}

However, the following is allowed:
\begin{verbatim}
type
  TA = specialize TMyFirstType<Atype>;
  TB = specialize TMySecondType<TA>;
\end{verbatim}
because \var{TA} is already fully defined when \var{TB} is specialized.

However, the \var{specialize} keyword can be used in another generic type definition as shown in the example above:
\begin{verbatim}
  generic TList<_T>=class(TObject, specialize IList<_T>)
\end{verbatim}
and
\begin{verbatim}
  generic TPointSet<t> = array of specialize PlanarCoordinate<t>;
\end{verbatim}
In these definitions, the specialization is only performed when the generic type itself is specialized,
and at that time, the types are known.

\begin{remark}
It is not possible to make a forward definition of a class which is a specialization
of a generic, i.e. the following will not compile:
\begin{verbatim}
  TMyClass = Class;

  // Other declarations

  TMyClass = specialize TList<T>;
\end{verbatim}
\end{remark}


\section{Generic type restrictions}
\index{Type!Restrictions}\index{Generics!Type Restrictions}
The diagram in \sees{genericsintroduction} shows that the type template list can have extra specifiers for the types.
This is especially useful for object types: if the template type must descend from a certain class, then this can be
specified in the template list:
\begin{verbatim}
{$mode objfpc}
{$h+}
uses sysutils, classes;

Type
  generic TList<_T : TComponent> = class(TObject)
  public
    Type TCompareFunc = function(const Item1, Item2: _T): Integer;
  Public
    data : _T;
    procedure Add(item: _T);
    procedure Sort(compare: TCompareFunc);
 end;
\end{verbatim}
Given the above definition, the following will compile:
\begin{verbatim}
TPersistentList = specialize TList<TComponent>;
\end{verbatim}
But this will not compile
\begin{verbatim}
TPersistentList = specialize TList<TPersistent>;
\end{verbatim}
The compiler will return an error:
\begin{verbatim}
Error: Incompatible types: got "TPersistent" expected "TComponent"
\end{verbatim}
Multiple types can be grouped together:
\begin{verbatim}
Type
  generic TList<Key1,Key2 : TComponent; Value1 : TObject> = class(TObject)
\end{verbatim}

Additionally, it is possible to specify more than one type identifier for class and interface type restrictions.
If a class is specified, then the type used for the template must be equal to or descend from the indicated type:
\begin{verbatim}
Type
  generic TList<T: TComponent, IEnumerable> = class(TObject)
\end{verbatim}
A class used to specialize \var{T} must descend from \var{TComponent} and must implement \var{IEnumerable}.

If an interface is specified, then the template type must implement at least this interface, but it can also be a descendent interface from this interface:
\begin{verbatim}
Type
  generic TGenList<T: IEnumerable> = class(TObject)

  IMyEnum = Interface (IEnumerable)
    Procedure DoMy;
  end;

  TList = specialize TGenList<IMyEnum>;
  TSomeList = Specialize TGenList<TList>;
\end{verbatim}

Multiple interfaces can be specified, in that case the class type must implement all listed interfaces:
It is possible to mix one class name with several interface names.

If no type restrictions are in effect, the compiler will assume that template types are {\em not} assignment compatible.

This is specially important when the generic class contains overloaded methods. Given the following generic type declaration:
\begin{verbatim}
type
  generic TTest<T1, T2> = class
    procedure Test(aArg: LongInt);
    procedure Test(aArg: T1);
    procedure Test(aArg: T2);
  end;
\end{verbatim}
Specializing the above will compile if \var{T1} and \var{T2} are of two different types and neither is also \var{LongInt}.
The following will compile:
\begin{verbatim}
T1 = specialize TTest<String, TObject>;
\end{verbatim}
But the following two will not compile:
\begin{verbatim}
T2 = specialize TTest<String, String>;
\end{verbatim}
or
\begin{verbatim}
T2 = specialize TTest<String, Longint>;
\end{verbatim}

\section{Delphi compatibility}
\index{Delphi!Compatibility}
FPC's generics support is implemented somewhat different from Delphi. In this section the main differences are highlighted.

\subsection{Syntax elements}
\index{Delphi!Syntax}
The syntax shown in the syntax diagrams is the syntax required in the ObjFPC mode of the compiler.
However, in Delphi mode, the \var{specialize} and \var{generic} keywords must not be used, as shown in the following example:
\begin{verbatim}
Type
  TTest<T> = Class(TObject)
  Private
    FObj : T;
  Public
    Property Obj : T Read FObj Write FObj;
  end;

  TIntegerTest = TTest<Integer>;
\end{verbatim}
In difference with Mode Objfpc, the template type names must be repeated in method definitions.
\begin{verbatim}
Type
  TTest<T> = Class(TObject)
  Private
    FObj : T;
  Public
    Procedure DoIt;
    Property Obj : T Read FObj Write FObj;
  end;

Procedure TTest<T>.DoIt;

begin
end;
\end{verbatim}
This requirement is directly related to the generic type overload capability mentioned in the next section.

\subsection{Record type restrictions}
In Delphi mode, the \var{record} type restrictions will also allow the use of simple types:
\begin{verbatim}
Type
  TList<_T : record> = class(TObject)
  public
    Type TCompareFunc = function(const Item1, Item2: _T): Integer;
  Public
    data : _T;
    procedure Add(item: _T);
    procedure Sort(compare: TCompareFunc);
 end;

TIntList = TList<Integer>;
\end{verbatim}
The restriction is enforced when specializing the type. That means that the
mode active when specializing a type determines whether a simple type can be
used or not: if the restriction to record was compiled using ObjFPC mode,
code written in Delphi mode can specialize it with a simple type anyway.

for example:
\begin{verbatim}
unit tg;

interface

{$mode objfpc}

Type
  generic TList<_T : record> = class(TObject)
  public
    Type TCompareFunc = function(const Item1, Item2: _T): Integer;
  Public
    data : _T;
    procedure Add(item: _T);
    procedure Sort(compare: TCompareFunc);
 end;

implementation

generic procedure TList<_T>.Add(item: _T);

begin

end;

generic  procedure TList<_T>.Sort(compare: TCompareFunc);

begin
end;

end.
\end{verbatim}
can be used in \{\$MODE Delphi\} for:
\begin{verbatim}
{$mode delphi}
uses tg;

Type
  TIntList = TList<Integer>;
begin
end.
\end{verbatim}


\subsection{Type overloads}
\index{Type!Type overloads}\index{Generics!Overloads}\index{Delphi!Type overloads}
Delphi mode allows generic type overloads. This means that it is possible to declare the same generic class
with different template type lists. The following declarations are therefore possible:
\begin{verbatim}
Type
  TTest<T> = Class(TObject)
  Private
    FObj : T;
  Public
    Property Obj : T Read FObj Write FObj;
  end;

  TTest<T,S> = Class(TObject)
  Private
    FObj1 : T;
    FObj2 : S;
  Public
    Property Obj1 : T Read FObj1 Write FObj1;
    Property Obj2 : S Read FObj2 Write FObj2;
  end;
\end{verbatim}

\subsection{Name space considerations}
In Delphi mode, the generics do not interfere with the namespace for variables, this means that the following will also compile:
\begin{verbatim}
Type
  TTest<T> = Class(TObject)
  Private
    FObj : T;
  Public
    Property Obj : T Read FObj Write FObj;
  end;

Var
  TTest : Integer;
\end{verbatim}
However, this does not work for constants and functions.

\section{Type compatibility}
\index{Type!Compatibility}
Whenever a generic class is specialized, this results in a new, distinct type.
These types are assignment compatible if the same template types are used.

Take the following generic definition:
\begin{verbatim}
{$mode objfpc}
unit ua;

interface

type
  Generic TMyClass<T> = Class(TObject)
    Procedure DoSomething(A : T; B : INteger);
  end;

Implementation

Procedure TMyClass.DoSomething(A : T; B : Integer);

begin
  // Some code.
end;

end.
\end{verbatim}
And the following specializations:
\begin{verbatim}
{$mode objfpc}
unit ub;

interface

uses ua;

Type
  TB = Specialize TMyClass<string>;

implementation

end.
\end{verbatim}
the following specializations is identical, but appears in a different unit:
\begin{verbatim}
{$mode objfpc}
unit uc;

interface

uses ua;

Type
  TB = Specialize TMyClass<string>;

implementation

end.
\end{verbatim}
The following will then compile:
\begin{verbatim}
{$mode objfpc}
unit ud;

interface

uses ua,ub,uc;

Var
  B : ub.TB;
  C : uc.TB;

implementation

begin
  B:=C;
end.
\end{verbatim}
The types ub.TB and  uc.TB are assignment compatible.
It does not matter that the types are defined in different units. They could
be defined in the same unit as well:
\begin{verbatim}
{$mode objfpc}
unit ue;

interface

uses ua;

Type
  TB = Specialize TMyClass<string>;
  TC = Specialize TMyClass<string>;


Var
  B : TB;
  C : TC;

implementation

begin
  B:=C;
end.
\end{verbatim}
Each specialization of a generic class with the same types as parameters is a new,
distinct type, but these types are assignment compatible if the template types used to specialize them are equal.

If the specialization is with a different template type, the types are still distinct, but no longer assignment
compatible. i.\,e. the following will not compile:
\begin{verbatim}
{$mode objfpc}
unit uf;

interface

uses ua;

Type
  TB = Specialize TMyClass<string>;
  TC = Specialize TMyClass<integer>;


Var
  B : TB;
  C : TC;

implementation

begin
  B:=C;
end.
\end{verbatim}
When compiling, an error will result:
\begin{verbatim}
Error: Incompatible types: got "TMyClass<System.LongInt>"
                           expected "TMyClass<System.ShortString>"
\end{verbatim}

\section{Using the default intrinsic}
\label{se:genericdefault}
When writing generic routines, sometimes a variable must be initialized whose type is not known during the declaration of the generic.
This is where the \var{Default} intrinsic (\sees{initusingdefault}) also comes into play. Given the following generic declaration:
\begin{verbatim}
type
  generic TTest<T> = class
    procedure Test;
  end;
\end{verbatim}
The following code will correctly initialize the variable \var{myt} during specialization:
\begin{verbatim}
procedure TTest.Test;
var
  myt: T;
begin
  // will have the correct Default if class is specialized
  myt := Default(T);
end;
\end{verbatim}

\section{A word about scope}
It should be stressed that all identifiers other than the template placeholders
should be known when the generic class is declared. At the same time,
nothing can be assumed about the template type (unless a restriction is
placed on it).

This works in several ways.

In the absence of type restrictions, the generic code cannot make
assumptions about the template type \var{T}. Consider the following unit:

\begin{verbatim}
unit ts;

interface
{$modeswitch advancedrecords}

type
  PListEl = ^TListEl;
  TListEl = packed record
    Prev, Next: PListEl;
  end;


implementation

type
  generic LstEnumerator<T> = record
  private
    lst, lst_save: T;
  public
    constructor Create(const Value: T);
    function MoveNext: boolean;
  end;

function LstEnumerator.MoveNext: boolean;
begin
  Result:=lst <> nil;
  if Result then
    lst:=lst^.next;
end;

constructor LstEnumerator.Create(const Value: T);
begin
  lst:= Value;
  lst_save := nil;
end;


Type
 TMyListEnum = specialize LstEnumerator<TListEl>;

end.
\end{verbatim}
The compiler will throw an error because when it compiles the generic
definition, it cannot verify that
\begin{verbatim}
   lst:=lst^.next;
\end{verbatim}
is correct. \var{lst} is of type \var{T}, but the compiler does not (yet)
know what \var{T} is, and hence cannot know it has a field \var{next}.

This problem can be solved with type restrictions:
\begin{verbatim}
unit ts;
{$mode delphi}
interface

type
  TListEl = class
    Prev, Next: TListEl;
  end;

  TMyRecord1 = Class(TListEl)
    MyField : String;
  end;

  TMyRecord2 = Class(TListEl)
    MyInteger : Integer;
  end;

implementation

type
  TLstEnumerator<T : TListEl> = class
  private
    lst, lst_save: T;
  public
    constructor Create(const Value: T);
    function MoveNext: boolean;
  end;

function TLstEnumerator<T>.MoveNext: boolean;
begin
  Result:=lst <> T(nil);
  if Result then
    lst:=T(lst.next);
end;

constructor TLstEnumerator<t>.Create(const Value: T);
begin
  lst:= Value;
  lst_save := T(nil);
end;


Type
 TMyRecord1Enum = TLstEnumerator<TMyRecord1>;
 TMyRecord2Enum = TLstEnumerator<TMyRecord2>;
\end{verbatim}
Here, the compiler knows that \var{lst} is at least of type TListEl, and
hence contains members \var{Prev} and \var{Next}.

Beside the template type, all other types used in the generic declaration must be
known.
This means that a type identifier with the same name must exist.
The following unit will produce an error:
\begin{verbatim}
{$mode objfpc}
unit myunit;

interface

type
  Generic TMyClass<T> = Class(TObject)
    Procedure DoSomething(A : T; B : TSomeType);
  end;

Type
  TSomeType = Integer;
  TSomeTypeClass = specialize TMyClass<TSomeType>;

Implementation

Procedure TMyClass.DoSomething(A : T; B : TSomeType);

begin
  // Some code.
end;

end.
\end{verbatim}
The above code will result in an error, because the type \var{TSomeType} is
not known when the declaration is parsed:
\begin{verbatim}
home: >fpc myunit.pp
myunit.pp(8,47) Error: Identifier not found "TSomeType"
myunit.pp(11,1) Fatal: There were 1 errors compiling module, stopping
\end{verbatim}

A second way in which this is visible, is the following. Assume a unit
\begin{verbatim}
{$mode objfpc}
unit mya;

interface

type
  Generic TMyClass<T> = Class(TObject)
    Procedure DoSomething(A : T);
  end;


Implementation

Procedure DoLocalThings;

begin
  Writeln('mya.DoLocalThings');
end;


Procedure TMyClass.DoSomething(A : T);

begin
  DoLocalThings;
end;

end.
\end{verbatim}
The compiler will not allow to compile this unit, since the \var{DoLocalThings} function will not be visible when the generic type is specialized:
\begin{verbatim}
Error: Global Generic template references static symtable
\end{verbatim}
Now, if the unit is modified, and the \var{DoLocalThings} function  is moved to the interface section, the unit will compile.
When using this generic in a program:
\begin{verbatim}
{$mode objfpc}
program myb;

uses mya;

procedure DoLocalThings;

begin
  Writeln('myb.DoLocalThings');
end;

Type
  TB = specialize TMyClass<Integer>;

Var
  B : TB;

begin
  B:=TB.Create;
  B.DoSomething(1);
end.
\end{verbatim}
Despite the fact that generics act as a macro which is replayed at specialization time, the reference to \var{DoLocalThings} is resolved
when \var{TMyClass} is defined, not when TB is defined. This means that the output of the program is:
\begin{verbatim}
home: >fpc -S2 myb.pp
home: >myb
mya.DoLocalThings
\end{verbatim}
This behavior is dictated by safety and necessity:
\begin{enumerate}
\item A programmer specializing a class has no way of knowing which local
procedures are used, so he cannot accidentally ``override'' it.
\item A programmer specializing a class has no way of knowing which local
procedures are used, so he cannot implement it either, since he does not
know the parameters.
\item If implementation procedures are used as in the example above, they
cannot be referenced from outside the unit. They could be in another unit
altogether, and the programmer has no way of knowing he should include them
before specializing his class.
\end{enumerate}

\section{Operator overloading and generics}
Operator overloading (\seec{operatoroverloading}) and  generics are closely related.
Imagine a generic class that has the following definition:
\begin{verbatim}
{$mode objfpc}
unit mya;

interface

type
  Generic TMyClass<T> = Class(TObject)
    Function Add(A,B : T) : T;
  end;

Implementation

Function TMyClass.Add(A,B : T) : T;

begin
  Result:=A+B;
end;

end.
\end{verbatim}
When the compiler replays the generics macro, the addition must be possible.
For a specialization like this:
\begin{verbatim}
TMyIntegerClass = specialize TMyClass<integer>;
\end{verbatim}
This is not a problem, as the \var{Add} method would become:
\begin{verbatim}
Procedure TMyIntegerClass.Add(A,B : Integer) : Integer;

begin
  Result:=A+B;
end;
\end{verbatim}
The compiler knows how to add two integers, so this code will compile without
problems. But the following code:
\begin{verbatim}
Type
  TComplex = record
   Re,Im : Double;
  end;

Type
  TMyIntegerClass = specialize TMyClass<TComplex>;
\end{verbatim}
Will not compile, unless the addition of two \var{TComplex} types is defined.
This can be done using record operators:
\begin{verbatim}
{$modeswitch advancedrecords}
uses mya;

Type
  TComplex = record
     Re,Im : Double;
     class operator +(a,b : TComplex) : TComplex;
  end;

class operator TComplex.+ (a,b : TComplex) : TComplex;

begin
  Result.re:=A.re+B.re;
  Result.im:=A.im+B.im;
end;


Type
  TMyComplexClass = specialize TMyClass<TComplex>;

begin
  // Code here
end.
\end{verbatim}
Currently, due to an implementation restriction, it will not work using a global operator, i.\,e. the following does not work yet:
\begin{verbatim}
uses mya;

Type
  TComplex = record
     Re,Im : Double;
  end;

operator + (a,b : TComplex) : TComplex;

begin
  Result.re:=A.re+B.re;
  Result.im:=A.im+B.im;
end;

Type
  TMyComplexClass = specialize TMyClass<TComplex>;

begin
  // Code here
end.
\end{verbatim}
Support for this construct is expected in a future version of Free Pascal.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Extended Records
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Extended records}
\label{ch:ExtendedRecords}
\index{Extended records}\index{Types!Extended record}

% Definition
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Definition}
Extended records are in many ways equivalent to objects and to a lesser
extent to classes: they are records which have methods associated with
them, and properties. Like objects, when defined as a variable they are
allocated on the stack. They do not need to have a constructor.
Extended records have limitations over objects and classes in that they
do not allow inheritance and polymorphism. It is impossible to create a
descendant record of a record\footnote{although it can be enhanced using record
helpers, more about this in the chapter on record helpers.}.

Why then introduce extended records ? They were introduced by Delphi
2005 to support one of the features introduced by .NET. Delphi deprecated
the old TP style of objects, and re-introduced the features of .NET as
extended records. Free Pascal aims to be Delphi
compatible, so extended records are allowed in Free Pascal as well,
but only in Delphi mode.

If extended records are desired in ObjFPC mode, then a mode switch must be
used:
\begin{verbatim}
{$mode objfpc}
{$modeswitch advancedrecords}
\end{verbatim}

Compatibility is not the only reason for introducing extended records.
There are some practical reasons for using methods or properties in records:
\begin{enumerate}
\item It is more in line with an object-oriented approach to programming:
the type also contains any methods that work on it.
\item In contrast with a procedural approach, putting all operations that
work on a record in the record itself, allows an IDE to show the available
methods on the record when it is displaying code completion options.
\end{enumerate}

Defining an extended record is much like defining an object or class:
\input{syntax/typeerec.syn}
Some of the restrictions when compared to classes or objects are
obvious from the syntax diagram:
\begin{itemize}
\item No inheritance of records.
\item No published and protected section exists.
\item Constructors or destructors cannot be defined.
\item Class methods (if one can name them so) require the \var{static} keyword.
\item Methods cannot be virtual or abstract~-- this is a consequence
of the fact that there is no inheritance.
\end{itemize}
Other than that the definition much resembles that of a class or object,
except that operators can be defined in an extended record.

\begin{remark}
In the case of a variant record, the \var{Case} keyword implicitly starts a
\var{var} section, meaning class variables or methods are not allowed in the
variant part of the record.
\end{remark}


The following are few examples of valid extended record definitions:
\begin{verbatim}
TTest1 = record
  a : integer;
  function Test(aRecurse: Boolean): Integer;
end;

TTest2 = record
private
  A,b : integer;
public
  procedure setA(AValue : integer);
  property SafeA : Integer Read A Write SetA;
end;

TTest3 = packed record
private
  fA,fb : byte;
  procedure setA(AValue : Integer);
  function geta : integer;
public
  property A : Integer Read GetA Write SetA;
end;

TTest4 = record
 private
   a : Integer;
 protected
   function getp : integer;
 public
   b : string;
   procedure setp (aValue : integer);
   property p : integer read Getp Write SetP;
 public
 case x : integer of
   1 : (Q : string[10]);
   2 : (S : String[10]);
 end;
\end{verbatim}
Note that it is possible to specify a visibility for the members of the
record. This is particularly useful for example when creating an interface
to a C library: the actual fields can be declared hidden, and more ``pascal''
like properties can be exposed which act as the actual fields.
The \var{TTest3} record definition shows that the \var{packed} directive can
be used in extended records. Extended records have the same memory layout as
their regular counterparts: the methods and properties are not part of the
record structure in memory.

The \var{TTest4} record definition in the above examples shows that the
extended record still has the ability to define a variant part. As with the
regular record, the variant part must come last. It cannot contain methods.

\section{Extended record enumerators}
Extended records can have an enumerator. To this end, a function returning
an enumerator record must be defined in the extended record:
\begin{verbatim}
{$mode objfpc}
{$modeswitch advancedrecords}
type
  TIntArray = array[0..3] of Integer;

  TEnumerator = record
  private
    FIndex: Integer;
    FArray: TIntArray;
    function GetCurrent: Integer;
  public
    function MoveNext: Boolean;
    property Current: Integer read GetCurrent;
  end;

  TMyArray = record
    F: array[0..3] of Integer;
    function GetEnumerator: TEnumerator;
  end;

function TEnumerator.MoveNext: Boolean;
begin
  inc(FIndex);
  Result := FIndex < Length(FArray);
end;

function TEnumerator.GetCurrent: Integer;
begin
  Result := FArray[FIndex];
end;

function TMyArray.GetEnumerator: TEnumerator;
begin
  Result.FArray := F;
  Result.FIndex := -1;
end;
\end{verbatim}
After these definitions, the following code will compile and enumerate all
elements in F:
\begin{verbatim}
var
  Arr: TMyArray;
  I: Integer;
begin
  for I in Arr do
    WriteLn(I);
end.
\end{verbatim}
The same effect can be achieved with the enumerator operator:
\begin{verbatim}
{$mode objfpc}
{$modeswitch advancedrecords}
type
  TIntArray = array[0..3] of Integer;

  TEnumerator = record
  private
    FIndex: Integer;
    FArray: TIntArray;
    function GetCurrent: Integer;
  public
    function MoveNext: Boolean;
    property Current: Integer read GetCurrent;
  end;

  TMyArray = record
    F: array[0..3] of Integer;
  end;

function TEnumerator.MoveNext: Boolean;
begin
  inc(FIndex);
  Result := FIndex < Length(FArray);
end;

function TEnumerator.GetCurrent: Integer;
begin
  Result := FArray[FIndex];
end;

operator Enumerator(const A: TMyArray): TEnumerator;
begin
  Result.FArray := A.F;
  Result.FIndex := -1;
end;
\end{verbatim}
This will allow the code to run as well.

\section{Record operators}
Operator overloading is treated in detail in the chapter on operator overloading \seec{operatoroverloading}.
However, since Delphi implemented operator overloading as part of advanced
records, a few words need to be said about it here. 

As can be seen in the syntax diagram for extended records, FPC supports the Delphi syntax for operators on extended
records. This syntax is available in both \var{ObjFPC} and \var{Delphi} mode.

In \var{objfpc} mode, the operators must be defined with their symbolic
names, just as regular operator overloads:
\begin{verbatim}
{$mode objfpc}
{$modeswitch advancedrecords}

Type
  TComplex = record
    Re,Im : Double;
    class operator +(a,b : TComplex) : TComplex;
  end;

class operator TComplex.+ (a,b : TComplex) : TComplex;
begin
  Result.re:=A.re+B.re;
  Result.im:=A.im+B.im;
end;
\end{verbatim}
The operators work just as they would if they were defined using the regular FPC syntax for
operators, but this syntax is of course limited to record types.
Note that they have the \var{class} keyword prefixed, and have the record type
name prepended in the implementation.


As indicated above, in \var{ObjFPC} mode, the operators must be indicated with their symbol names. 
By contrast, in \var{Delphi} mode, the names of the operators can also be used, similar to the syntax in Delphi:
\begin{verbatim}
{$mode delphi}
Type
  TComplex = record
    Re,Im : Double;
    class operator add(a,b : TComplex) : TComplex;
  end;

class operator TComplex.add (a,b : TComplex) : TComplex;
begin
  Result.re:=A.re+B.re;
  Result.im:=A.im+B.im;
end;
\end{verbatim}
This is of course because the syntax must be compatible with Delphi.

Below is a table that links the symbolic operator names to the plain-text
name. Note that some FPC operators do not have an equivalent usin a Delphi
name.

\begin{FPCltable}{cl}{Operator names}{operatornames}
Symbol & Name \\ \hline
\var{+} & add or positive \\
\var{-} & subtract or negative \\
\var{*} & multiply \\
\var{/} & divide \\
\var{**} & (no equivalent) \\
\var{><} & (no equivalent) \\
\var{=} & equal \\
\var{<} & lessthan \\
\var{<=} & lessthanorequal \\
\var{>} & greaterthan \\
\var{>=} & greaterthanorequal \\
\var{<>} & notequal \\
\var{:=} & implicit \\
\var{in} & in \\
\var{shr} & rightshift \\
\var{shl} & leftshift \\
\var{div} & intdivide \\
\var{mod} & modulus \\
\var{and} & bitwiseand or logicaland \\
\var{or} & bitwiseor or logicalor \\
\var{xor} & bitwisexor \\
\var{not} & logicalnot \\
\end{FPCltable}

For example, the power operator (**) can be used in \var{Delphi} mode using its
symbolic name:
\begin{verbatim}
{$mode delphi}  
{$modeswitch advancedrecords}  
 
Type  
  TComplex = record  
    Re,Im : Double;  
    class operator **(a,b : TComplex) : TComplex;  
  end;  
 
class operator TComplex.** (a,b : TComplex) : TComplex;  
begin  
  Result.re:=-B.re;  
  Result.im:=-B.im;  
end; 

Var
  a,b : TComplex;
begin
  a:=a**b;
end.
\end{verbatim}
More information on operator overloading can be found in the chapter on
operator overloading \seec{operatoroverloading}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Class helpers
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Class, Record and Type helpers}
\label{ch:ClassHelpers}
\index{Class helpers}\index{Types!Class helpers}%
\index{Record helpers}\index{Types!Record helpers}\index{Types!Type helpers}
\index{Type!Helpers}
\keywordlink{helper}

% Definition
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Definition}
Class, record and type helpers can be used to add methods to an existing class,
record or simple type, without making a derivation of the class or re-declaring the record.

For a record or a simple type, the type helper acts as if record or the simple type
is a class, and methods are declared for it. Inside the methods, \var{Self} will refer
to the value of the record or simple type.

For classes, the effect is like inserting a method in the method table of the class.
If the helper declaration is in the current scope of the code, then the
methods and properties of the helper can be used as if they were part of the
class declaration for the class or record that the helper extends.

The syntax diagram for a class, record or type helper is presented below:
\input{syntax/helper.syn}
The diagram shows that a helper definition looks very much like a regular
class definition. It simply declares some extra constructors, methods, properties and fields
for a class: the class, record or simple type for which the helper is an extension is indicated
after the \var{for} keyword.

Since an enumerator for a class is obtained through a regular method,
class helpers can also be used to override the enumerators for the class.

As can be seen from the syntax diagram, it is possible to create descendants of helpers:
the helpers can form a hierarchy of their own, allowing to override methods of a
parent helper. They also have visibility specifiers, just like records and
classes.

As in an instance of the class, the \var{Self} identifier in a method of a
class helper refers to the class instance (not the helper instance). For a
record, it refers to the record.

The following is a simple class helper for the \var{TObject} class, which provides
an alternate version of the standard \var{ToString} method.
\begin{verbatim}
TObjectHelper = class helper for TObject
  function AsString(const aFormat: String): String;
end;

function TObjectHelper.AsString(const aFormat: String): String;
begin
  Result := Format(aFormat, [ToString]);
end;

var
  o: TObject;
begin
  Writeln(o.AsString('The object''s name is %s'));
end.
\end{verbatim}

\begin{remark}
The \var{helper} modifier is only a modifier just after the \var{class} or
\var{record} keywords. That means that the first member of a class or record
cannot be named \var{helper}. A member of a class or record can be called
\var{helper}, it just cannot be the first one, unless it is escaped with a
\var{\&}, as for all identifiers that match a keyword.
\end{remark}

\begin{remark}
Support for type helpers requires the use of Delphi mode or the use of a
\var{typehelpers} modeswitch in other modes:
\begin{verbatim}
{$MODESWITCH TYPEHELPERS}
\end{verbatim}
\end{remark}

\begin{remark}
Support for record helpers requires the use of Delphi mode or the use of a
\var{advancedrecords} modeswitch in other modes:
\begin{verbatim}
{$MODESWITCH ADVANCEDRECORDS}
\end{verbatim}
\end{remark}

\section{Restrictions on class helpers}
It is not possible to extend a class with any method or property. There are
some restrictions on the possibilities:
\begin{itemize}
\item Destructors or class destructors are not allowed.
\item Class constructors are not allowed.
%\item Record helpers cannot implement constructors.
\item Class helpers cannot descend from record helpers, and cannot extend record types.
\item Field definitions are not allowed. Neither are class fields.
\item Properties that refer to a field are not allowed. This is in fact a
consequence of the previous item.
\item Abstract methods are not allowed.
\item Virtual methods of the class cannot be overridden. They can be hidden
by giving them the same name or they can be overloaded using the
\var{overload} directive.
\item Unlike for regular procedures or methods, the \var{overload} specifier must
be explicitly used when overloading methods from a class in a class helper.
If overload is not used, the extended type's method is hidden by the helper method
(as for regular classes).
\end{itemize}
The following modifies the previous example by overloading the \var{ToString}
method:
\begin{verbatim}
TObjectHelper = class helper for TObject
  function ToString(const aFormat: String): String; overload;
end;

function TObjectHelper.ToString(const aFormat: String): String;
begin
  Result := Format(aFormat, [ToString]);
end;

var
  o: TObject;
begin
  Writeln(o.ToString('The object''s name is %s'));
end.
\end{verbatim}

\section{Restrictions on record helpers}
Records do not offer the same possibilities as classes do. This reflects on
the possibilities when creating record helpers. Below the restrictions on
record helpers are enumerated:
\begin{itemize}
\item A record helper cannot be used to extend a class. The following will
fail:
\begin{verbatim}
TTestHelper = record helper for TObject
end;
\end{verbatim}
\item Inside a helper's declaration the methods/fields of the extended record
can't be accessed in e.\,g. a property definition. They can be accessed in the
implementation, of course. This means that the following will not compile:
\begin{verbatim}
TTest = record
  Test: Integer;
end;

TTestHelper = record helper for TTest
  property AccessTest: Integer read Test;
end;
\end{verbatim}
\item Record helpers can only access public fields (in case an extended
record with visibility specifiers is used).
\item Inheritance of record helpers is only allowed in ObjFPC mode; In
Delphi mode, it is not allowed.
\item Record helpers can only descend from other record helpers, not from
class helpers.
\item Unlike class helpers, a descendent record helper must extend the same
record type.
\item In Delphi mode, it is not possible to call the extended record's
method using \var{inherited}. It is possible to do so in ObjFPC mode. The
following code needs ObjFPC mode to compile:
\begin{verbatim}
type
  TTest = record
    function Test(aRecurse: Boolean): Integer;
  end;

  TTestHelper = record helper for TTest
    function Test(aRecurse: Boolean): Integer;
  end;

function TTest.Test(aRecurse: Boolean): Integer;
begin
  Result := 1;
end;

function TTestHelper.Test(aRecurse: Boolean): Integer;
begin
  if aRecurse then
    Result := inherited Test(False)
  else
    Result := 2;
end;
\end{verbatim}
\end{itemize}

\section{Considerations for (simple) type helpers}
For simple types, the rules are pretty much the same as for records, plus there are some extra requirements:
\begin{itemize}
\item Support for type helpers needs to be activated using the modeswitch typehelpers:
\begin{verbatim}
{$modeswitch typehelpers}
\end{verbatim}
This modeswitch is enabled by default only in mode Delphi and DelphiUnicode.
\item In Delphi (and DelphiUnicode) mode, for stricter Delphi compatibility, the record helpers must be used instead
of a type helper.
\item The modes ObjFPC and MacPas use type helper, but the modeswitch TypeHelpers must be used.
\item The following types are not supported:
\begin{itemize}
\item All file types (\var{Text}, \var{file of ...})
\item Procedural variables
\item Types like records, classes, Objective C classes, C++ classes, objects and interfaces are forbidden as well,
the class helper must be used for classes. That means that for instance, the following will fail:
\begin{verbatim}
TTestHelper = type helper for TObject
end;
\end{verbatim}
\end{itemize}
This of course means that all other simple types are supported.
\item Type helpers can implement constructors.
\item Inheritance of record helpers is only allowed in ObjFPC mode; In Delphi mode, it is not allowed.
\item Type helpers can only descend from other type helpers, not from class or record helpers.
\item A descendent type helper must extend the same type.
\end{itemize}
The following gives an idea of the possibilities:
\begin{verbatim}
{$mode objfpc}
{$modeswitch typehelpers}

type
 TLongIntHelper = type helper for LongInt
   constructor create(AValue: LongInt);
   class procedure Test; static;
   procedure DoPrint;
 end;

constructor TLongIntHelper.create(AValue: LongInt);

begin
  Self:=Avalue;
  DoPrint;
end;

class procedure TLongIntHelper.Test;

begin
   Writeln('Test');
end;

procedure TLongIntHelper.DoPrint;

begin
   Writeln('Value :',Self);
end;

var
  i: LongInt;
begin
  I:=123;
  i.Test;
  $12345678.Test;
  LongInt.Test;
  I:=123;
  i.DoPrint;
  $12345678.DoPrint;
end.
\end{verbatim}

\section{A note on scope and lifetime for record and type helpers}
For classes, the lifetime of an instance of a class is explicitly managed by
the programmer. It is therefore clear what the \var{Self} parameter means and when it is valid.

Records and other simple types are allocated on the stack, which means they go out
of scope when the function, procedure or method in which they are used, exits.

Combined with the fact that helper methods are type compatible to class methods,
and can therefore be used as event handlers, this can lead to surprising situations:
The data pointer in a helper method is set to the address of the variable.

Consider the following example:
\begin{verbatim}
{$mode objfpc}
{$modeswitch typehelpers}
uses
  Classes;

type
  TInt32Helper = type helper for Int32
    procedure Foo(Sender: TObject);
  end;

procedure TInt32Helper.Foo(Sender: TObject);
begin
  Writeln(Self);
end;

var
  i: Int32 = 10;
  m: TNotifyEvent;
begin
  m := @i.Foo;
  WriteLn('Data : ',PtrUInt(TMethod(m).Data));
  m(nil);
end.
\end{verbatim}
This will print something like (the actual value for data may differ):
\begin{verbatim}
Data : 6848896
10
\end{verbatim}
The variable \var{i} is still in scope when \var{m} is called.

But changing the code to
\begin{verbatim}
{$mode objfpc}
{$modeswitch typehelpers}
uses
  Classes;

type
  TInt32Helper = type helper for Int32
    procedure Foo(Sender: TObject);
  end;

procedure TInt32Helper.Foo(Sender: TObject);
begin
  Writeln(Self);
end;

Function GetHandler  :TNotifyEvent;

var
  i: Int32 = 10;

begin
  Result:=@i.foo;
end;

Var
  m: TNotifyEvent;
begin
  m := GetHandler;
  WriteLn(PtrUInt(TMethod(m).Data));
  m(nil);
end.
\end{verbatim}
The output will be:
\begin{verbatim}
140727246638796
0
\end{verbatim}
The actual output will depend on the architecture, but the point is that \var{i} is no longer in scope,
making the output of its value meaningless, and possibly even leading to access violations and program crashes.

\section{Inheritance}
As noted in the previous section, it is possible to create descendants of
helper classes. Since only the last helper class in the current scope can
be used, it is necessary to descend a helper class from another one if
methods of both helpers must be used. More on this in a subsequent section.

A descendent of a class helper can extend a different class than its
parent. The following is a valid class helper for \var{TMyObject}:
\begin{verbatim}
TObjectHelper = class helper for TObject
  procedure SomeMethod;
end;

TMyObject = class(TObject)
end;

TMyObjectHelper = class helper(TObjectHelper) for TMyObject
  procedure SomeOtherMethod;
end;
\end{verbatim}
The \var{TMyObjectHelper} extends \var{TObjectHelper}, but does not extend
the \var{TObject} class, it only extends the \var{TMyObject} class.

Since records know no inheritance, it is obvious that descendants of record
helpers can only extend the same record.

\begin{remark}
For maximum delphi compatibility, it is impossible to create descendants of record helpers
in Delphi mode.
\end{remark}

\section{Usage}
Once a helper class is defined, its methods can be used whenever the helper
class is in scope. This means that if it is defined in a separate unit, then
this unit should be in the uses clause wherever the methods of the helper
class are used.

Consider the following unit:
\begin{verbatim}
{$mode objfpc}
{$h+}
unit oha;

interface

Type
  TObjectHelper = class helper for TObject
    function AsString(const aFormat: String): String;
  end;

implementation

uses sysutils;

function TObjectHelper.AsString(const aFormat: String): String;

begin
  Result := Format(aFormat, [ToString]);
end;

end.
\end{verbatim}
Then the following will compile:
\begin{verbatim}
Program Example113;

uses oha;

{ Program to demonstrate the class helper scope. }

Var
  o : TObject;

begin
  O:=TObject.Create;
  Writeln(O.AsString('O as a string : %s'));
end.
\end{verbatim}
But, if a second unit (ohb) is created:
\begin{verbatim}
{$mode objfpc}
{$h+}
unit ohb;

interface

Type
  TAObjectHelper = class helper for TObject
    function MemoryLocation: String;
  end;

implementation

uses sysutils;

function TAObjectHelper.MemoryLocation: String;

begin
  Result := format('%p',[pointer(Self)]);
end;

end.
\end{verbatim}
And is added after the first unit in the uses clause:
\begin{verbatim}
Program Example113;

uses oha,ohb;

{ Program to demonstrate the class helper scope. }

Var
  o : TObject;

begin
  O:=TObject.Create;
  Writeln(O.AsString('O as a string : %s'));
  Writeln(O.MemoryLocation);
end.
\end{verbatim}
Then the compiler will complain that it does not know the method ``AsString''.
This is because the compiler stops looking for class helpers as soon as the
first class helper is encountered. Since the \var{ohb} unit comes last in
the uses clause, the compiler will only use \var{TAObjectHelper} as the class
helper.

The solution is to re-implement unit ohb:
\begin{verbatim}
{$mode objfpc}
{$h+}
unit ohc;

interface

uses oha;

Type
  TAObjectHelper = class helper(TObjectHelper) for TObject
    function MemoryLocation: String;
  end;

implementation

uses sysutils;

function TAObjectHelper.MemoryLocation: String;

begin
  Result := format('%p',[pointer(Self)]);
end;

end.
\end{verbatim}
And after replacing unit \var{ohb} with \var{ohc}, the example program will
compile and function as expected.

Note that it is not enough to include a unit with a class helper once in a
project; The unit must be included whenever the class helper is needed.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Objective Pascal classes
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Objective-Pascal Classes}
\label{ch:ObjectivePascal}
\index{Objective-Pascal}\index{Objective-Pascal Classes}

% Introduction
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Introduction}
The preferred programming language to access Mac OS X system frameworks is
Objective-C. In order to fully realize the potential offered by system
interfaces written in that language, a variant of Object Pascal
exists in the Free Pascal compiler that tries to offer the same
functionality as Objective-C. This variant is called Objective-Pascal.

The compiler has mode switches to enable the use of these Objective-C-related
constructs. There are two kinds of Objective-C language features, discerned by
a version number: Objective-C 1.0 and Objective-C 2.0.

The Objective-C 1.0 language features can be enabled by adding a modeswitch
to the source file:
\begin{verbatim}
{$modeswitch objectivec1}
\end{verbatim}
or by using the \var{-Mobjectivec1} command line switch of the compiler.

The Objective-C 2.0 language features can be enabled using a similar
modewitch:
\begin{verbatim}
{$modeswitch objectivec2}
\end{verbatim}
or the command-line option \var{-Mobjectivec2}.

The Objective-C 2.0 language features are a superset of the Objective-C 1.0
language features, and therefore the latter switch automatically implies the
former. Programs using Objective-C 2.0 language features will only work on
Mac OS X 10.5 and later.

The fact that objective-C features are enabled using mode switches rather than
actual syntax modes, means they can be used in combination with every general
syntax mode (fpc, objfpc, tp, delphi, macpas). Note that a \var{\{\$Mode \}}
directive switch will reset the mode switches, so the \var{\{\$modeswitch \}}
statement should be located after it.

% Syntax
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Objective-Pascal class declarations}
\keywordlink{objcclass}
Objective-C or -Pascal classes are declared much as Object Pascal classes are
declared, but they use the \var{objcclass} keyword:
\input{syntax/objclass.syn}
As can be seen, the syntax is roughly equivalent to Object Pascal syntax, with some
extensions.

In order to use Objective-C classes, an external modifier exists: this
indicates to the compiler that the class is implemented in an external object
file or library, and that the definition is meant for import purposes.
The following is an example of an external Objective-C class definition:
\begin{verbatim}
NSView = objcclass external(NSResponder)
private
  _subview  : id;
public
  function initWithFrame(rect : NSRect): id;
     message 'initWithFrame:';
  procedure addSubview(aview: NSView);
     message 'addSubview:';
  procedure setAutoresizingMask(mask: NSUInteger);
     message 'setAutoresizingMask:';
  procedure setAutoresizesSubviews(flag: LongBool);
     message 'setAutoresizesSubviews:';
  procedure drawRect(dirtyRect: NSRect);
     message 'drawRect:';
end;
\end{verbatim}
As can be seen, the class definition is not so different from an Object
Pascal class definition; Only the message directive is more prominently
present: each Objective-C or Objective-Pascal method must have a message
name associated with it. In the above example, no external name was
specified for the class definition, meaning that the Pascal identifier is
used as the name for the Objective-C class. However, since Objective-C is not so
strict in its naming conventions, sometimes an alias must be created for an
Objective-C class name that doesn't obey the Pascal identifier rules.

The following example defines an Objective-C class which is implemented in
Pascal:
\begin{verbatim}
MyView = objcclass(NSView)
public
  data : Integer;
  procedure customMessage(dirtyRect: NSRect);
    message 'customMessage';
  procedure drawRect(dirtyRect: NSRect); override;
end;
\end{verbatim}
The absence of the \var{external} keyword tells the compiler that the
methods must be implemented later in the source file: it will be treated
much like a regular object pascal class. Note the presence of the
\var{override} directive: in Objective-C, all methods are virtual. In Object
Pascal, overriding a virtual method must be done through the \var{override}
directive. This has been extended to \var{Objective-C} classes: it allows
the compiler to verify the correctness of the definition.

Unless the class is implementing the method of a protocol (more about this
in a subsequent section), one of \var{message} or \var{override} is
expected: all methods are virtual, and either a new method is started (or
re-introduced), or an existing is overridden. Only in the case of a method
that is part of a protocol, the method can be defined without \var{message}
or \var{override}.


Note that the Objective-C class declaration may or may not specify a parent class.
In Object Pascal, omitting a parent class will automatically make the
new class a descendant of \var{TObject}. In Objective-C, this is not the
case: the new class will be a new root class. However, Objective-C does
have a class which fulfills the function of generic root class:
\var{NSObject}, which can be considered the equivalent of \var{TObject}
in Object Pascal. It has other root classes, but in general,
Objective-Pascal classes should descend from \var{NSObject}. If a new
root class is constructed anyway, it must implement the
\var{NSObjectProtocol}~-- just as the \var{NSObject} class itself does.

Finally, Objective-Pascal classes can have properties, but these properties
are only usable in Pascal code: the compiler currently does not export the
properties in a way that makes them usable from Objective-C.

% Formal declarations
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Formal declaration}
Object Pascal has the concept of Forward declarations. Objective-C takes
this concept a bit further: it allows to declare a class which is defined in
another unit. This has been dubbed ``Formal declaration'' in Objective-Pascal.
Looking at the syntax diagram, the following is a valid declaration:
\begin{verbatim}
MyExternalClass = objcclass external;
\end{verbatim}
This is a formal declaration. It tells the compiler that
\var{MyExternalClass} is an Objective-C class type, but that there is no
declaration of the class members. The type can be used in the remainder of
the unit, but its use is restricted to storage allocation (in a field or
method parameter definition) and assignment (much like a pointer).

As soon as the class definition is encountered, the compiler can enforce
type compatibility.

The following unit uses a formal declaration:
\begin{verbatim}
unit ContainerClass;

{$mode objfpc}
{$modeswitch objectivec1}

interface

type
  MyItemClass = objcclass external;

  MyContainerClass = objcclass
    private
     item: MyItemClass;
    public
     function getItem: MyItemClass; message 'getItem';
  end;

implementation

function MyContainerClass.getItem: MyItemClass;
begin
  result:=item; // Assignment is OK.
end;

end.
\end{verbatim}
A second unit can contain the actual class declaration:
\begin{verbatim}
unit ItemClass;

{$mode objfpc}
{$modeswitch objectivec1}

interface

type
  MyItemClass = objcclass(NSObject)
  private
    content : longint;
  public
    function initWithContent(c: longint): MyItemClass;
       message 'initWithContent:';
     function getContent: longint;
       message 'getContent';
  end;

implementation

function MyItemClass.initWithContent(c: longint):
   MyItemClass;
begin
  content:=c;
  result:=self;
end;

function MyItemClass.getContent: longint;
begin
  result:=content;
end;

end.
\end{verbatim}
If both units are used in a program, the compiler knows what the class is
and can verify the correctness of some assignments:
\begin{verbatim}
Program test;

{$mode objfpc}
{$modeswitch objectivec1}

uses
  ItemClass, ContainerClass;

var
  c: MyContainerClass;
  l: longint;
begin
  c:=MyContainerClass.alloc.init;
  l:=c.getItem.getContent;
end.
\end{verbatim}

% Objective-C class instantiation
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Allocating and de-allocating Instances}
The syntax diagram of Objective-C classes shows that the notion of
constructor and destructor is not supported in Objective-C. New instances
are created in a 2-step process:
\begin{enumerate}
\item Call the ``alloc'' method (send an ``alloc'' message): This is a class method
of \var{NSObject}, and returns a pointer to memory for the new instance.
The use of \var{alloc} is a convention in Objective-C.
\item Send an ``initXXX'' message. By convention, all classes have one or more
``InitXXX'' methods that initializes all fields in the instance. This method
will return the final instance pointer, which may be \var{Nil}.
\end{enumerate}
The following code demonstrates this:
\begin{verbatim}
var
  obj: NSObject;
begin
  // First allocate the memory.
  obj:=NSObject.alloc;
  // Next, initialise.
  obj:=obj.init;
  // Always check the result !!
  if (Obj=Nil) then
    // Some error;
\end{verbatim}
By convention, the \var{initXXX} method will return \var{Nil} if
initialization of some fields failed, so it is imperative that the result of
the function is tested.

Similarly, no privileged destructor exists; By convention, the \var{dealloc} method
fulfills the cleanup of the instances. This method can be overridden to
perform any cleanup necessary. Like \var{Destroy}, it should never be called directly,
instead, the \var{release} method should be called instead: All instances in
Objective-C are reference counted, and \var{release} will only call
\var{dealloc} if the reference count reaches zero.

% Protocol definitions
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Protocol definitions}
In Objective-C, protocols play the role that interfaces play in Object
Pascal, but there are some differences:
\begin{itemize}
\item Protocol methods can be marked optional, i.\,e. the class implementing
the protocol can decide not to implement these methods.
\item Protocols can inherit from multiple  other protocols.
\end{itemize}

Objective-C classes can indicate which protocols they implement in the class
definition, as could be seen in the syntax diagram for Objective-C classes.

The following diagram shows how to declare a protocol. It starts with the
\var{objcprotocol} keyword:
\keywordlink{objcprotocol}
\input{syntax/typeprot.syn}
As in the case of Objective-Pascal classes, the \var{external} specifier tells
the compiler that the declaration is an import of a protocol defined
elsewhere. For methods, almost the same rules apply as for methods in
the Objective-Pascal class declarations. The exception is that message
specifiers must be present.

The \var{required} and \var{optional} specifiers before a series of
method declarations are optional. If none is specified, \var{required} is
assumed. The following is a definition of a protocol:
\begin{verbatim}
type
  MyProtocol = objccprotocol
    // default is required
    procedure aRequiredMethod;
      message 'aRequiredMethod';
  optional
    procedure anOptionalMethodWithPara(para: longint);
      message 'anOptionalMethodWithPara:';
    procedure anotherOptionalMethod;
      message 'anotherOptionalMethod';
  required
    function aSecondRequiredMethod: longint;
      message 'aSecondRequiredMethod';
  end;

  MyClassImplementingProtocol = objcclass(NSObject,MyProtocol)
    procedure aRequiredMethod;
    procedure anOptionalMethodWithPara(para: longint);
    function aSecondRequiredMethod: longint;
  end;
\end{verbatim}
Note that in the class declaration, the message specifier was omitted.
The compiler (and runtime) can deduce it from the protocol definition.

% Categories
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Categories}
Similar to class helpers in Object Pascal, Objective-C has Categories.
Categories allow to extend classes without actually creating a descendant of
these classes. However, Objective-C categories provide more functionality
than a class helper:
\begin{enumerate}
\item In Object Pascal, only one helper class can be in scope (the last one).
In Objective-C, multiple categories can be in scope at the same time for
a particular class.
\item In Object Pascal, a helper method cannot change an existing method
present in the original class (but it can hide a method). In Objective-C, a category can also
replace existing methods in another class rather than only add new ones.
Since all methods are virtual in Objective-C, this also means that this
method changes for all classes that inherit from the class in which the
method was replaced (unless they override it).
\item Object Pascal helpers cannot be used to add interfaces to existing
classes. By contrast, an Objective-C category can also implement protocols.
\end{enumerate}

The definition of an objective-C class closely resembles a protocol
definition, and is started with the \var{objccategory} keyword:
\keywordlink{objcategory}
\input{syntax/typecat.syn}
Note again the possibility of an alias for externally defined categories:
Objective-C 2.0 allows an empty category name. Note that the
\var{reintroduce} modifier must be used if an existing method is being replaced
rather than that a new method is being added.

When replacing a method, calling ``inherited'' will not call the original
method of the class, but instead will call the parent class' implementation
of the method.

The following is an example of a category definition:
\begin{verbatim}
MyProtocol = objcprotocol
  procedure protocolmethod; message 'protocolmethod';
end;

MyCategory = objccategory(NSObject,MyProtocol)
  function hash: cuint; reintroduce;
  procedure protocolmethod; // from MyProtocol.
  class procedure newmethod; message 'newmethod';
end;
\end{verbatim}
Note that this declaration replaces the \var{Hash} method of every class
that descends from \var{NSObject} (unless it specifically overrides it).

% Name scope
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Name scope and Identifiers}
In Object Pascal, each identifier must be unique in its namespace: the unit.
In Objective-C, this need not be the case and each type identifier must be
unique among its kind: classes, protocols, categories, fields or methods.
This is shown in the definitions of the basic protocol and class of
Objective-C: Both protocol and class are called \var{NSObject}.

When importing Objective-C classes and protocols, the Objective-Pascal
names of these types must conform to the Object Pascal rules, and therefore
must have distinct names. Likewise, names that are valid identifiers in
Objective-C may be reserved words in Object Pascal. They also must be
renamed when imported.

To make this possible, the \var{External} and ``message'' modifiers allow
to specify a name: this is the name of the type or method as it exists
in Objective-C:
\begin{verbatim}
NSObjectProtocol = objcprotocol external name 'NSObject'
  function _class: pobjc_class; message name 'class';
end;

NSObject = objcclass external (NSObjectProtocol)
  function _class: pobjc_class;
  class function classClass: pobjc_class; message 'class';
end;
\end{verbatim}

% Selectors
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Selectors}
A Selector in Objective-C can be seen as an equivalent to a procedural type
in Object Pascal.

In difference with the procedural type, Objective-C has only one selector type:
\var{SEL}. It is defined in the \var{objc} unit~-- which is automatically
included in the uses clause of any unit compiled with the \var{objectivec1}
modeswitch.

To assign a value to a variable of type \var{SEL}, the \var{objcselector}
method must be used: \keywordlink{objcselector}
\begin{verbatim}
{$modeswitch objectivec1}
var
  a: SEL;
begin
  a:=objcselector('initiWithWidth:andHeight:');
  a:=objcselector('myMethod');
end.
\end{verbatim}
The \var{objc} unit contains methods to manipulate and use the selector.

% The ID type
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{The \var{id} type}
The \var{id} type is special in Objective-C/Pascal. It is much like the pointer
type in Object Pascal, except that it is a real class. It is assignment-compatible
with instances of every \var{objcclass} and \var{objcprotocol} type, in two
directions:
\begin{enumerate}
\item variables of any \var{objcclass}/\var{objcprotocol} type can be
assigned to a variable of the type \var{id}.
\item variables of type \var{id} can be assigned to variables of any particular
\var{objcclass}/\var{objcprotocol} type.
\end{enumerate}
No explicit typecast is required for either of these assignments.

Additionally, any Objective-C method declared in an \var{objcclass} or
\var{objccategory} that is in scope can be called when using an
\var{id}-typed variable.

If, at run time, the actual \var{objcclass} instance stored in the
\var{id}-typed variable does not respond to the sent message, the
program will terminate with a run time error: much like the dispatch
mechanism for variants under MS-Windows.

When there are multiple methods with the same Pascal identifier, the
compiler will use the standard overload resolution logic to pick the most
appropriate method. In this process, it will behave as if all
\var{objcclass}/\var{objccategory} methods in scope have been declared as global
procedures/functions with the \var{overload} specifier. Likewise, the compiler
will print an error if it cannot determine which overloaded method to call.

In such cases, a list of all methods that could be used to implement the call
will be printed as a hint.

To resolve the error, an explicit type cast must be used to tell the compiler
which objcclass type contains the needed method.

% Enumerating
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Enumeration in Objective-C classes}
Fast enumeration in Objective-C is a construct which allows to enumerate
the elements in a Cocoa container class in a generic way. It is implemented
using a \var{for-in} loop in Objective-C.

This has been translated to Objective-Pascal using the existing \var{for-in}
loop mechanism. Therefore, the feature behaves identically in both languages.
Note that it requires the Objective-C 2.0 mode switch to be activated.

The following is an example of the use of for-in:
\begin{verbatim}
{$mode delphi}
{$modeswitch objectivec2}

uses
  CocoaAll;

var
  arr: NSMutableArray;
  element: NSString;
  pool: NSAutoreleasePool;
  i: longint;
begin
  pool:=NSAutoreleasePool.alloc.init;
  arr:=NSMutableArray.arrayWithObjects(
    NSSTR('One'),
    NSSTR('Two'),
    NSSTR('Three'),
    NSSTR('Four'),
    NSSTR('Five'),
    NSSTR('Six'),
    NSSTR('Seven'),
    nil);

  i:=0;
  for element in arr do
    begin
      inc(i);
      if i=2 then
        continue;
      if i=5 then
        break;
      if i in [2,5..10] then
        halt(1);
      NSLog(NSSTR('element: %@'),element);
    end;
  pool.release;
end.
\end{verbatim}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Expressions
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Expressions}
\label{ch:Expressions}
\index{Expressions}
Expressions occur in assignment statements or in tests.

Expressions are built of two components: operators and their operands.
Most operators are binary, i.\,e. require two operands. Binary operators
occur always between the operands (as in \var{X/Y}). Few
operators are unary, i.\,e. require only one operand. A unary operator
occurs always before the operand, as in \var{-X}.

An expression resolves into a value of a certain type. The resulting
type is determined by the types of the values in the expression and
the operators in the expression.

When using multiple operands in an expression, the precedence rules of
\seet{OperatorPrecedence} are used.\index{Operators}
\begin{FPCltable}{lll}{Precedence of operators}{OperatorPrecedence}
Operator & Precedence & Category \\ \hline
\var{Not}, unary \var{+}, unary \var{-}, \var{@}, \var{**} & Highest (first) & Unary operators, power \\
\var{*}, \var{/}, \var{div}, \var{mod}, \var{and}, \var{shl}, \var{shr}, \var{as}, \var{<{}<}, \var{>{}>} & Second & Multiplying operators \\
\var{+}, \var{-}, \var{or}, \var{xor}, \var{><} & Third & Adding operators \\
\var{=}, \var{<>}, \var{<}, \var{>}, \var{<=}, \var{>=}, \var{in}, \var{is} & Lowest (Last) & relational operators \\
\hline
\end{FPCltable}

When determining the precedence, the compiler uses the following rules:
\begin{enumerate}
\item In operations with unequal precedences the operands belong to the
operator with the highest precedence. For example, in \var{5*3+7}, the
multiplication is higher in precedence than the addition, so it is
ievaluated first. The result would be 22.
\item If parentheses are used in an expression, their contents is evaluated
first. Thus, \var {5*(3+7)} would result in 50.
\item Otherwise, binary operators of the same precedence are left-associative.
\var{5 * 3 div 7} will evaluate to 2 and not 0.
\end{enumerate}

\begin{remark}
The order in which expressions of the same precedence are evaluated is not
guaranteed to be left-to-right. In general, no assumptions on which subexpression
is evaluated first should be made in such a case.

The compiler will decide which subexpression to evaluate first based on
optimization rules. Thus, in the following expression:
\begin{verbatim}
  a := g(3) + f(2);
\end{verbatim}
\var{f(2)} may be executed before \var{g(3)}. This behavior is distinctly
different from \delphi{} or \tp{}.

If one expression {\em must} be executed before the other, it is necessary
to split up the statement using temporary results:
\begin{verbatim}
  e1 := g(3);
  a  := e1 + f(2);
\end{verbatim}

A notable exception to this behavior is the evaluation of boolean expressions: 
if short-circuit boolean evaluation is enabled (the default) then the
compiler will evaluate from left to right, but will still respect
precedence, i.\,e. in parts with equal precedence the left operand will always
be evaluated before the right one. Thus, the following example:
\begin{verbatim}
  True or True and False
\end{verbatim}
will evaluate to \var{True}, because it is equivalent to
\begin{verbatim}
  True or (True and False)
\end{verbatim}
\end{remark}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Expression syntax
\section{Expression syntax}
An expression applies relational operators to simple expressions. Simple
expressions are a series of terms (what a term is, is explained below), joined by
adding operators.
\input{syntax/expsimpl.syn}
The following are valid expressions:
\begin{verbatim}
GraphResult<>grError
(DoItToday=Yes) and (DoItTomorrow=No);
Day in Weekend
\end{verbatim}
And here are some simple expressions:
\begin{verbatim}
A + B
-Pi
ToBe or NotToBe
\end{verbatim}
Terms consist of factors, connected by multiplication operators.
\input{syntax/expterm.syn}
Here are some valid terms:
\begin{verbatim}
2 * Pi
A Div B
(DoItToday=Yes) and (DoItTomorrow=No);
\end{verbatim}
Factors are all other constructions:
\input{syntax/expfact.syn}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Function calls
\section{Function calls}
Function calls are part of expressions (although, using extended syntax,
they can be statements too). They are constructed as follows:
\input{syntax/fcall.syn}
The \synt{variable reference} must be a procedural type variable reference.
A method designator can only be used inside the method of an object. A
qualified method designator can be used outside object methods too.
The function that will get called is the function with a declared parameter
list that matches the actual parameter list. This means that
\begin{enumerate}
\item The number of actual parameters must equal the number of declared
parameters (unless default parameter values are used).
\item The types of the parameters must be compatible. For variable
reference parameters, the parameter types must be exactly the same.
\end{enumerate}
If no matching function is found, then the compiler will generate an error.
Which error depends~-- among other things~-- on whether the function is overloaded
or not: i.\,e. multiple functions with the same name, but different parameter
lists.

There are cases when the compiler will not execute the function call in an
expression. This is the case when assigning a value to a procedural
type variable, as in the following example in Delphi or Turbo Pascal mode:
\begin{verbatim}
Type
  FuncType = Function: Integer;
Var A : Integer;
Function AddOne : Integer;
begin
  A := A+1;
  AddOne := A;
end;
Var F : FuncType;
    N : Integer;
begin
  A := 0;
  F := AddOne; { Assign AddOne to F, Don't call AddOne}
  N := AddOne; { N := 1 !!}
end.
\end{verbatim}
In the above listing, the assignment to \var{F} will not cause the function
\var{AddOne} to be called. The assignment to \var{N}, however, will call
\var{AddOne}.

Sometimes, the call is desired, for instance in recursion
in that case, the call must be forced. This can be done by adding the
parenthesis to the function name:
\begin{verbatim}
function rd : char;

var
  c : char;

begin
  read(c);
  if (c='\') then
    c:=rd();
  rd:=c;
end;

var ch : char;

begin
   ch:=rd;
   writeln(ch);
end.
\end{verbatim}
The above will read a character and print it. If the input is a backslash, a
second character is read.

A problem with this syntax is the following construction:
\begin{verbatim}
If F = AddOne Then
  DoSomethingHorrible;
\end{verbatim}
Should the compiler compare the addresses of \var{F} and \var{AddOne},
or should it call both functions, and compare the result? In \var{fpc} and
\var{objfpc} mode this is solved by considering a procedural variable as
equivalent to a pointer. Thus the compiler will give a type mismatch error,
since \var{AddOne} is considered a call to a function with integer result,
and \var{F} is a pointer.

How then, should one check whether \var{F} points to the function
\var{AddOne}? To do this, one should use the address operator \var{@}:
\begin{verbatim}
If F = @AddOne Then
  WriteLn ('Functions are equal');
\end{verbatim}
The left hand side of the boolean expression is an address. The right hand
side also, and so the compiler compares two addresses.
How to compare the values that both functions return ? By adding an empty
parameter list:
\begin{verbatim}
  If F()=Addone then
    WriteLn ('Functions return same values ');
\end{verbatim}
Remark that this last behavior is not compatible with \delphi syntax.
Switching on \var{Delphi} mode will allow you to use \delphi syntax.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Set constructors
\section{Set constructors}
\index{Constructor}
When a set-type constant must be entered in an expression, a
set constructor must be given. In essence this is the same thing as when a
type is defined, only there is no identifier to identify the set with.
A set constructor is a comma separated list of expressions, enclosed in
square brackets.
\input{syntax/setconst.syn}
All set groups and set elements must be of the same ordinal type.
The empty set is denoted by \var{[]}, and it can be assigned to any type of
set. A set group with a range  \var{[A..Z]} makes all values in the range a
set element.
The following are valid set constructors:
\begin{verbatim}
[today,tomorrow]
[Monday..Friday,Sunday]
[ 2, 3*2, 6*2, 9*2 ]
['A'..'Z','a'..'z','0'..'9']
\end{verbatim}
\begin{remark}
If the first range specifier has a bigger ordinal value than
the second, the resulting set will be empty, e.\,g., \var{['Z'..'A']}
denotes an empty set. One should be careful when denoting a range.
\end{remark}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Value typecasts
\section{Value typecasts}
\index{Typecast}\index{Typecast!Value}\index{Type!Compatibility}

Sometimes it is necessary to change the type of an expression, or a part of
the expression, to be able to be assignment compatible. This is done through
a value typecast. The syntax diagram for a value typecast is as follows:
\input{syntax/tcast.syn}
Value typecasts cannot be used on the left side of assignments, as variable
typecasts.
Here are some valid typecasts:
\begin{verbatim}
Byte('A')
Char(48)
boolean(1)
longint(@Buffer)
\end{verbatim}
In general, the type size of the expression and the size of the type cast
must be the same. However, for ordinal types (byte, char, word, boolean,
enumerates) this is not so, they can be used interchangeably.
That is, the following will work, although the sizes do not match.
\begin{verbatim}
Integer('A');
Char(4875);
boolean(100);
Word(@Buffer);
\end{verbatim}
This is compatible with \delphi or \tp behavior.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Variable typecasts
\section{Variable typecasts}
\index{Typecast}\index{Typecast!Variable}
A variable can be considered a single factor in an expression. It can
therefore be typecast as well. A variable can be typecast to any type,
provided the type has the same size as the original variable.

It is a bad idea to typecast integer types to real types and vice versa.
It's better to rely on type assignment compatibility and using some of the
standard type changing functions.

Note that variable typecasts can occur on either side of an assignment,
i.\,e. the following are both valid typecasts:
\begin{verbatim}
Var
  C : Char;
  B : Byte;

begin
  B:=Byte(C);
  Char(B):=C;
end;
\end{verbatim}
Pointer variables can be typecast to procedural types, but not
to method pointers.

A typecast is an expression of the given type, which means the
typecast can be followed by a qualifier:
\begin{verbatim}
Type
  TWordRec = Packed Record
    L,H : Byte;
  end;

Var
  P : Pointer;
  W : Word;
  S : String;

begin
  TWordRec(W).L:=$FF;
  TWordRec(W).H:=0;
  S:=TObject(P).ClassName;
\end{verbatim}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% aligned typecasts
\section{Unaligned typecasts}
\index{Typecast}\index{Typecast!Unaligned}
A special typecast is the \var{Unaligned} typecast of a variable or
expression. This is not a real typecast, but is rather a hint for the
compiler that the expression may be misaligned (i.\,e. not on an aligned
memory address). Some processors do not allow direct access to misaligned
data structures, and therefore must access the data byte per byte.

Typecasting an expression with the unaligned keyword signals the compiler
that it should access the data byte per byte.

Note that the compiler assumes that access to all fields/elements of
packed data structures is unaligned.

Example:
\begin{verbatim}
program me;

Var
  A : packed Array[1..20] of Byte;
  I : LongInt;

begin
  For I:=1 to 20 do
    A[I]:=I;
  I:=PInteger(Unaligned(@A[13]))^;
end.
\end{verbatim}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% The @ operator
\section{The @ operator}
\index{Operators}\index{Address}\index{Type!Compatibility}

The address operator \var{@} returns the address of a variable, procedure
or function. It is used as follows:
\input{syntax/address.syn}
The \var{@} operator returns a typed pointer if the \var{\$T} switch is on.
If the \var{\$T} switch is off then the address operator returns an untyped
pointer, which is assignment compatible with all pointer types. The type of
the pointer is \var{\^{}T}, where \var{T} is the type of the variable
reference.
For example, the following will compile
\begin{verbatim}
Program tcast;
{$T-} { @ returns untyped pointer }

Type art = Array[1..100] of byte;
Var Buffer : longint;
    PLargeBuffer : ^art;

begin
 PLargeBuffer := @Buffer;
end.
\end{verbatim}
Changing the \var{\{\$T-\}} to \var{\{\$T+\}} will prevent the compiler from
compiling this. It will give a type mismatch error.

By default, the address operator returns an untyped pointer: applying
the address operator to a function, method, or procedure identifier
will give a pointer to the entry point of that function.
The result is an untyped pointer.

This means that the following will work:
\begin{verbatim}
Procedure MyProc;

begin
end;

Var
  P : PChar;

begin
  P:=@MyProc;
end;
\end{verbatim}
By default, the address operator must be used if a value must be assigned
to a procedural type variable. This behavior can be avoided by using the
\var{-Mtp} or \var{-MDelphi} switches, which result in a more compatible
\delphi or \tp syntax.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Operators
\section{Operators}
\index{Operators}
Operators can be classified according to the type of expression they
operate on. We will discuss them type by type.
%
\subsection{Arithmetic operators}
\index{Operators!Arithmetic}
Arithmetic operators occur in arithmetic operations, i.\,e. in expressions
that contain integers or reals. There are two kinds of operators: Binary and
unary arithmetic operators.
Binary operators are listed in \seet{binaroperators}, unary operators are
listed in \seet{unaroperators}.
\begin{FPCltable}{ll}{Binary arithmetic operators}{binaroperators}
Operator  & Operation \\ \hline
\var{+}   & Addition \\
\var{-}   & Subtraction \\
\var{*}   & Multiplication \\
\var{**}  & Exponentiation \\
\var{/}   & Division \\
\var{Div} & Integer division \\
\var{Mod} & Remainder \\ \hline
\end{FPCltable}
With the exception of \var{Div} and \var{Mod}, which accept only integer
expressions as operands, all operators accept real and integer expressions as
operands.

\begin{remark}
The exponentiation operator (\var{**}) is available for overloading
(\seec{operatoroverloading}),
but is not defined on any of the standard Pascal types (floats and/or integers).
\end{remark}

For binary operators, the result type will be integer if both operands are
integer type expressions. If one of the operands is a real type expression,
then the result is real.

As an exception, division (\var{/}) results always in real values.
\index{Operators!Unary}
\begin{FPCltable}{ll}{Unary arithmetic operators}{unaroperators}
Operator & Operation \\ \hline
\var{+} & Sign identity\\
\var{-} & Sign inversion \\ \hline
\end{FPCltable}

For unary operators, the result type is always equal to the expression type.
The division (\var{/}) and \var{Mod} operator will cause run-time errors if
the second argument is zero.

The sign of the result of a \var{Mod} operator is the same as the sign of
the left side operand of the \var{Mod} operator. In fact, the \var{Mod}
operator is equivalent to the following operation:
\begin{verbatim}
  I mod J = I - (I div J) * J
\end{verbatim}
But it executes faster than the right hand side expression.
%
\subsection{Logical operators}
\index{Operators!Logical} \keywordlink{not} \keywordlink{and}
\keywordlink{or} \keywordlink{xor} \keywordlink{shl} \keywordlink{shr}
Logical operators act on the individual bits of ordinal expressions.
Logical operators require operands that are of an integer type, and produce
an integer type result. The possible logical operators are listed in
\seet{logicoperations}.
\begin{FPCltable}{ll}{Logical operators}{logicoperations}
Operator & Operation \\ \hline
\var{not} & Bitwise negation (unary) \\
\var{and} & Bitwise and \\
\var{or}  & Bitwise or \\
\var{xor} & Bitwise xor \\
\var{shl} & Bitwise shift to the left \\
\var{shr} & Bitwise shift to the right \\ \hline
\var{<{}<} & Bitwise shift to the left (same as shl)\\
\var{>{}>} & Bitwise shift to the right (same as shr) \\ \hline
\end{FPCltable}
The following are valid logical expressions:
\begin{verbatim}
A shr 1  { same as A div 2, but faster}
Not 1    { equals -2 }
Not 0    { equals -1 }
Not -1   { equals 0  }
B shl 2  { same as B * 4 for integers }
1 or 2   { equals 3 }
3 xor 1  { equals 2 }
\end{verbatim}
%
\subsection{Boolean operators}
\index{Operators!Boolean}
Boolean operators can be considered as logical operations on a type with 1 bit
size. Therefore the \var{shl} and \var{shr} operations have little sense.
Boolean operators can only have boolean type operands, and the resulting
type is always boolean. The possible operators are listed in
\seet{booleanoperators}
\begin{FPCltable}{ll}{Boolean operators}{booleanoperators}
Operator & Operation \\ \hline
\var{not} & logical negation (unary) \\
\var{and} & logical and \\
\var{or}  & logical or \\
\var{xor} & logical xor \\ \hline
\end{FPCltable}
\begin{remark} By default, boolean expressions are evaluated with short-circuit
evaluation. This means that from the moment the result of the complete
expression is known, evaluation is stopped and the result is returned.
For instance, in the following expression:
\begin{verbatim}
 B := True or MaybeTrue;
\end{verbatim}
The compiler will never look at the value of \var{MaybeTrue}, since it is
obvious that the expression will always be \var{True}. As a result of this
strategy, if \var{MaybeTrue} is a function, it will not get called !
(This can have surprising effects when used in conjunction with properties)
\end{remark}
%
\subsection{String operators}
\index{Operators!String}
There is only one string operator: \var{+}. Its action is to concatenate
the contents of the two strings (or characters) it acts on.
One cannot use \var{+} to concatenate null-terminated (\var{PChar}) strings.
The following are valid string operations:
\begin{verbatim}
  'This is ' + 'VERY ' + 'easy !'
  Dirname+'\'
\end{verbatim}
The following is not:
\begin{verbatim}
Var
  Dirname : PChar;
...
  Dirname := Dirname+'\';
\end{verbatim}
Because \var{Dirname} is a null-terminated string.

Note that if all strings in a string expressions are short strings, the
resulting string is also a short string. Thus, a truncation may occur:
there is no automatic upscaling to ansistring.

If all strings in a string expression are ansistrings, then the result is an
ansistring.

If the expression contains a mix of ansistrings and shortstrings, the result
is an ansistring.

The value of the \var{\{\$H\}} switch can be used to control the type of
constant strings; by default, they are short strings (and thus limited to
255 characters).

%
\subsection{Dynamic array operators}
\index{Operators!Dynamic arrays}
There is only one dynamic array operator: \var{+}. This operator is
available in Delphi mode, but must be enabled explicily using the modeswitch
arrayoperators in objfpc mode:
\begin{verbatim}
{$mode objfpc}
{$modeswitch arrayoperators}
\end{verbatim}
When enabled, its action is similar to
the concation for strings: to concatenate the contents of the two arrays it acts on.
The array element type must of course be identical for both arrays, i.e. the
following will work:
\begin{verbatim}
{$mode objfpc}
{$modeswitch arrayoperators}
var
  a,b, c : array of byte;

begin
  a:=[0,1,2];
  b:=[3,4,5];
  c:=a+b;
  writeln('C has ',length(c),' elements');
\end{verbatim}
But the following will not work:
\begin{verbatim}
{$mode objfpc}
{$modeswitch arrayoperators}

var
  b, c : array of byte;
  a : array of integer;

begin
  a:=[0,1,2];
  b:=[3,4,5];
  c:=a+b;
  writeln('C has ',length(c),' elements');
\end{verbatim}
The compiler will give an error when compiling this code.

%
\subsection{Set operators}
\label{se:setoperators}
\index{Operators!Set}
The following operations on sets can be performed with operators:
union, difference, symmetric difference, inclusion and intersection.
Elements can be added or removed from the set with the \var{Include} or
\var{Exclude} operators. The operators needed for this are listed
in \seet{setoperators}.
\keywordlink{in}
\begin{FPCltable}{ll}{Set operators}{setoperators}
Operator & Action \\ \hline
\var{+} & Union \\
\var{-} & Difference \\
\var{*} & Intersection \\
\var{$><$} & Symmetric difference \\
\var{$<=$} & Contains \\
\var{$>=$} & Left hand side set is a superset of the one on the right \\
\var{include} & include an element in the set\\
\var{exclude} & exclude an element from the set\\
\var{in} & check whether an element is in a set\\ \hline
\end{FPCltable}
The set type of the operands must be the same, or an error will be
generated by the compiler.

The following program gives some valid examples of set operations:
\begin{verbatim}
Type
  Day = (mon,tue,wed,thu,fri,sat,sun);
  Days = set of Day;

Procedure PrintDays(W : Days);
Const
  DayNames : array [Day] of String[3]
           = ('mon','tue','wed','thu',
              'fri','sat','sun');
Var
  D : Day;
  S : String;
begin
  S:='';
  For D:=Mon to Sun do
    if D in W then
      begin
      If (S<>'') then S:=S+',';
      S:=S+DayNames[D];
      end;
  Writeln('[',S,']');
end;

Const
  WorkWeek = [mon,tue,wed,thu,fri];
  WeekEnd = [sat,sun];

Var
  W : Days;

begin
   W:=[mon,tue]+[wed,thu,fri]; // equals [mon,tue,wed,thu,fri]
   PrintDays(W);
   W:=[mon,tue,wed]-[wed];     // equals [mon,tue]
   PrintDays(W);
   W:=[mon,tue,wed]-[wed,thu];     // also equals [mon,tue]
   PrintDays(W);
   W:=[mon,tue,wed]*[wed,thu,fri]; // equals [wed]
   PrintDays(W);
   W:=[mon,tue,wed]><[wed,thu,fri]; // equals [mon,tue,thu,fri]
   PrintDays(W);
   if [mon,tue]<=WorkWeek then
     Writeln('Must work on monday and tuesday');
   if Weekend>=[sun] then
     Writeln('Can rest on sunday');
end.
\end{verbatim}
As can be seen, the union is equivalent to a binary OR, while the
intersection is equivalent to a binary AND, and the symmetric difference
equals a XOR operation.

The \var{Include} and \var{Exclude} operations are equivalent to a union
or a difference with a set of one element. Thus,
\begin{verbatim}
  Include(W,wed);
\end{verbatim}
is equivalent to
\begin{verbatim}
  W:=W+[wed];
\end{verbatim}
and
\begin{verbatim}
  Exclude(W,wed);
\end{verbatim}
is equivalent to
\begin{verbatim}
  W:=W-[wed];
\end{verbatim}

The \var{In} operation results in a \var{True} if the left operand
(an element) is included of the right operand (a set), the result
will be \var{False} otherwise.

%
\subsection{Relational operators}
\index{Operators!Relational}
The relational operators are listed in \seet{relationoperators}
\begin{FPCltable}{ll}{Relational operators}{relationoperators}
Operator & Action \\ \hline
\var{=} & Equal \\
\var{<>} & Not equal \\
\var{<} & Strictly less than\\
\var{>} & Strictly greater than\\
\var{<=} & Less than or equal \\
\var{>=} & Greater than or equal \\
\var{in} & Element of \\ \hline
\end{FPCltable}
Normally, left and right operands must be of the same type. There are some
notable exceptions, where the compiler can handle mixed expressions:
\begin{enumerate}
\item Integer and real types can be mixed in relational expressions.
\item If the operator is overloaded, and an overloaded version exists whose
arguments types match the types in the expression.
\item Short-, Ansi- and widestring types can be mixed.
\end{enumerate}
Comparing strings is done on the basis of their character code representation.

When comparing pointers, the addresses to which they point are compared.
This also is true for \var{PChar} type pointers. To compare the strings
the \var{PChar} point to, the \var{StrComp} function
from the \file{strings} unit must be used.
The \var{in} returns \var{True} if the left operand (which must have the same
ordinal type as the set type, and which must be in the range 0..255) is an
element of the set which is the right operand, otherwise it returns \var{False}.

\subsection{Class operators}
Class operators are slightly different from the operators above in the sense
that they can only be used in class expressions which return a class. There
are only two class operators, as can be seen in \seet{classoperators}.
\keywordlink{as} \keywordlink{is}
\begin{FPCltable}{ll}{Class operators}{classoperators}
Operator & Action \\ \hline
\var{is} & Checks class type \\
\var{as} & Conditional typecast \\
\end{FPCltable}
An expression containing the \var{is} operator results in a boolean type.
The \var{is} operator can only be used with a class reference or a class
instance. The usage of this operator is as follows:
\begin{verbatim}
 Object is Class
\end{verbatim}
This expression is completely equivalent to
\begin{verbatim}
 Object.InheritsFrom(Class)
\end{verbatim}
If \var{Object} is \var{Nil}, \var{False} will be returned.

The following are examples:
\begin{verbatim}
Var
  A : TObject;
  B : TClass;

begin
  if A is TComponent then ;
  If A is B then;
end;
\end{verbatim}

The \var{as} operator performs a conditional typecast. It results in an
expression that has the type of the class:
\begin{verbatim}
  Object as Class
\end{verbatim}
This is equivalent to the following statements:
\begin{verbatim}
  If Object=Nil then
    Result:=Nil
  else if Object is Class then
    Result:=Class(Object)
  else
    Raise Exception.Create(SErrInvalidTypeCast);
\end{verbatim}
Note that if the object is \var{nil}, the \var{as} operator does not
generate an exception.

The following are some examples of the use of the \var{as} operator:
\begin{verbatim}
Var
  C : TComponent;
  O : TObject;

begin
  (C as TEdit).Text:='Some text';
  C:=O as TComponent;
end;
\end{verbatim}

The \var{as} and \var{is} operators also work on interfaces (both COM and
CORBA). They can be used to check whether an interface also implements another interface as in
the following example:
\begin{verbatim}
{$mode objfpc}

uses
  SysUtils;

type
  IMyInterface1 = interface
    ['{DD70E7BB-51E8-45C3-8CE8-5F5188E19255}']
    procedure Bar;
  end;

  IMyInterface2 = interface
    ['{7E5B86C4-4BC5-40E6-A0DF-D27DBF77BCA0}']
    procedure Foo;
  end;

  TMyObject = class(TInterfacedObject, IMyInterface1, IMyInterface2)
    procedure Bar;
    procedure Foo;
  end;

procedure TMyObject.Bar;
begin

end;

procedure TMyObject.Foo;
begin

end;

var
  i: IMyInterface1;
begin
  i := TMyObject.Create;
  i.Bar;
  Writeln(BoolToStr(i is IMyInterface2, True)); // prints true
  Writeln(BoolToStr(i is IDispatch, True)); // prints false
  (i as IMyInterface2).Foo;
end.
\end{verbatim}

Additionally, the \var{is} operator can be used to check if a class
implements an interface, and the \var{as} operator can be used to typecast an
interface back to the class:
\begin{verbatim}
{$mode objfpc}
var
  i: IMyInterface;
begin
  i := TMyObject.Create;
  Writeln(BoolToStr(i is TMyObject,True)); // prints true
  Writeln(BoolToStr(i is TObject,True)); // prints true
  Writeln(BoolToStr(i is TAggregatedObject,True)); // prints false
  (i as TMyObject).Foo;
end.
\end{verbatim}
Although the interfaces must be COM interfaces, the typecast back to a
class will only work if the interface comes from an Object Pascal class.
It will not work on interfaces obtained from the system by COM.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Statements
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Statements}
\label{ch:Statements}\index{Statements}
The heart of each algorithm are the actions it takes. These actions are
contained in the statements of a program or unit. Each statement can be
labeled and jumped to (within certain limits) with \var{Goto} statements.
This can be seen in the following syntax diagram:
\input{syntax/statement.syn}
A label can be an identifier or an integer digit.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Simple statements
\section{Simple statements}
\index{Statements!Simple}
A simple statement cannot be decomposed in separate statements. There are
basically four kinds of simple statements:
\input{syntax/simstate.syn}
Of these statements, the {\em raise statement} will be explained in the
chapter on Exceptions (\seec{Exceptions})

\subsection{Assignments}
\index{Statements!Assignment}
Assignments give a value to a variable, replacing any previous value the
variable might have had:
\input{syntax/assign.syn}
In addition to the standard Pascal assignment operator (\var{:=}), which
simply replaces the value of the variable with the value resulting from the
expression on the right of the \var{:=} operator, \fpc
supports some C-style constructions. All available constructs are listed in
\seet{assignments}.
\begin{FPCltable}{lr}{Allowed C constructs in \fpc}{assignments}
Assignment & Result \\ \hline
a += b & Adds \var{b} to \var{a}, and stores the result in \var{a}.\\
a -= b & Subtracts \var{b} from \var{a}, and stores the result in
\var{a}. \\
a *= b & Multiplies \var{a} with \var{b}, and stores the result in
\var{a}. \\
a /= b & Divides \var{a} through \var{b}, and stores the result in
\var{a}. \\ \hline
\end{FPCltable}

For these constructs to work, the \var{-Sc} command-line switch must
be specified.

\begin{remark}
These constructions are just for typing convenience, they
don't generate different code.
Here are some examples of valid assignment statements:
\begin{verbatim}
X := X+Y;
X+=Y;      { Same as X := X+Y, needs -Sc command line switch}
X/=2;      { Same as X := X/2, needs -Sc command line switch}
Done := False;
Weather := Good;
MyPi := 4* Tan(1);
\end{verbatim}
\end{remark}

Keeping in mind that the dereferencing of a typed pointer results
in a variable of the type the pointer points to, the following are
also valid assignments:
\begin{verbatim}
Var
  L : ^Longint;
  P : PPChar;

begin
  L^:=3;
  P^^:='A';
\end{verbatim}
Note the double dereferencing in the second assignment.
\subsection{Procedure statements}
\index{Statements!Procedure}
Procedure statements are calls to subroutines. There are
different possibilities for procedure calls:
\begin{itemize}
\item A normal procedure call.
\item An object method call (fully qualified or not).
\item Or even a call to a procedural type variable.
\end{itemize}
All types are present in the following diagram:
\input{syntax/procedure.syn}
The \fpc compiler will look for a procedure with the same name as given in
the procedure statement, and with a declared parameter list that matches the
actual parameter list.
The following are valid procedure statements:
\begin{verbatim}
Usage;
WriteLn('Pascal is an easy language !');
Doit();
\end{verbatim}
\begin{remark}
When looking for a function that matches the parameter list of the call,
the parameter types should be assignment-compatible for value and const
parameters, and should match exactly for parameters that are passed by
reference.
\end{remark}

\subsection{Goto statements}
\index{Statements!Goto}\keywordlink{goto}
\fpc supports the \var{goto} jump statement. Its prototype syntax is
\input{syntax/goto.syn}
When using \var{goto} statements, the following must be kept in mind:
\begin{enumerate}
\item The jump label must be defined in the same block as the \var{Goto}
statement.
\item Jumping from outside a loop to the inside of a loop or vice versa can
 have strange effects.
\item To be able to use the \var{Goto} statement, the \var{-Sg} compiler
switch must be used, or \var{\{\$GOTO ON\}} must be used.
\end{enumerate}
\begin{remark}
In iso or macpas mode, or with the modeswitch ``nonlocalgoto'', the compiler
will also allow non-local gotos.
\end{remark}
\var{Goto} statements are considered bad practice and should be avoided as
much as possible. It is always possible to replace a \var{goto} statement by a
construction that doesn't need a \var{goto}, although this construction may
not be as clear as a goto statement.
For instance, the following is an allowed goto statement:
\begin{verbatim}
label
  jumpto;
...
Jumpto :
  Statement;
...
Goto jumpto;
...
\end{verbatim}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Structured statements
\section{Structured statements}
\index{Statements!Structured}
Structured statements can be broken into smaller simple statements, which
should be executed repeatedly, conditionally  or sequentially:
\input{syntax/struct.syn}
Conditional statements come in two flavors:
\input{syntax/conditio.syn}
Repetitive statements come in four flavors:
\input{syntax/repetiti.syn}
The following sections deal with each of these statements.

\subsection{Compound statements}
\index{Statements!Compound}
\keywordlink{begin} \keywordlink{end}
Compound statements are a group of statements, separated by semicolons,
that are surrounded by the keywords \var{Begin} and \var{End}. The
last statement~-- before the \var{End} keyword~-- doesn't need to be followed by a semicolon, although it is
allowed. A compound statement is a way of grouping statements together,
executing the statements sequentially. They are treated as one statement
in cases where Pascal syntax expects one statement, such as in
\var{if...then...else} statements.
\input{syntax/compound.syn}

\subsection{The \var{Case} statement}
\index{Statements!Case}\index{Case}\keywordlink{case}
\fpc supports the \var{case} statement. Its syntax diagram is
\input{syntax/case.syn}
The constants appearing in the various case parts must be known at
compile-time, and can be of the following types: enumeration types,
Ordinal types (including chars) or string types.
The case expression must be also of this type, or a compiler error
will occur. All case constants must have the same type.

The compiler will evaluate the case expression. If one of the case
constants' value matches the value of the expression, the statement that follows
this constant is executed. After that, the program continues after the final
\var{end}. \keywordlink{else} \keywordlink{otherwise}

If none of the case constants match the expression value, the statement
list after the \var{else} \index{else} or \var{otherwise}\index{otherwise}
keyword is executed. This can be an empty statement list.
If no else part is present, and no case constant matches the expression
value, program flow continues after the final \var{end}.

The case statements can be compound statements (i.\,e. a \var{Begin..End}
block), but for the else case multiple statements are allowed (as can be
seen in the syntax diagram). You may enclose them in an extra \var{Begin..End} 
block, but it is not necessary.

\begin{remark}
Contrary to \tp, duplicate case labels are not
allowed in \fpc, so the following code will generate an error when
compiling:
\begin{verbatim}
Var i : integer;
...
Case i of
 3 : DoSomething;
 1..5 : DoSomethingElse;
end;
\end{verbatim}
The compiler will generate a \var{Duplicate case label} error when compiling
this, because the 3 also appears (implicitly) in the range \var{1..5}. This
is similar to Delphi syntax.
\end{remark}
The following are valid case statements:
\begin{verbatim}
Case C of
 'a' : WriteLn ('A pressed');
 'b' : WriteLn ('B pressed');
 'c' : WriteLn ('C pressed');
else
  WriteLn ('unknown letter pressed : ',C);
end;
\end{verbatim}
Or
\begin{verbatim}
Case C of
 'a','e','i','o','u' : WriteLn ('vowel pressed');
 'y' : WriteLn ('This one depends on the language');
else
  WriteLn ('Consonant pressed');
end;
\end{verbatim}
\begin{verbatim}
Case Number of
 1..10   : WriteLn ('Small number');
 11..100 : WriteLn ('Normal, medium number');
else
 WriteLn ('HUGE number');
end;
\end{verbatim}
The \var{else} clause can contain multiple statements:
\begin{verbatim}
Case Number of
 1..10   : WriteLn ('Small number');
 11..100 : WriteLn ('Normal, medium number');
else
  WriteLn ('HUGE number');
  Writeln('How did we get this much ?');
end;
\end{verbatim}
\fpc allows the use of strings as case labels, and in that case the case
variable must also be a string. When using string types, the case variable
and the various labels are compared in a case-sensitive way.
\begin{verbatim}
Case lowercase(OS) of
 'windows',
 'dos'   : WriteLn ('Microsoft platform);
 'macos',
 'darwin' : Writeln('Apple platform');
 'linux',
 'freebsd',
 'netbsd' : Writeln('Community platform');
else
  WriteLn ('Other platform');
end;
\end{verbatim}
The case with strings is equivalent to a series of \var{if then else}
statements, no optimizations are performed.

However, ranges are allowed, and are the equivalent of an
\begin{verbatim}
if (value>=beginrange) and (value<=endrange) then
  begin
  end;
\end{verbatim}

\subsection{The \var{If..then..else} statement}
\index{Statements!if}\index{If}\index{then}\index{else}\keywordlink{if}\keywordlink{then}\keywordlink{else}
The \var{If .. then .. else..} prototype syntax is
\input{syntax/ifthen.syn}
The expression between the \var{if} and \var{then} keywords must have a
\var{Boolean} result type. If the expression evaluates to \var{True} then the
statement following the \var{then} keyword is executed.

If the expression evaluates to \var{False}, then the statement following
the \var{else} keyword is executed, if it is present.

Some points to note:
\begin{itemize}
\item
Be aware of the fact that the boolean expression by default will be
short-cut evaluated, meaning that the evaluation will be stopped at
the point where the  outcome is known with certainty.
\item
Also, before the \var {else} keyword, no semicolon (\var{;}) is allowed,
but all statements can be compound statements.
\item
In nested \var{If.. then .. else} constructs, some ambiguity may arise as
to which  \var{else} statement pairs with which \var{if} statement. The rule
is that the \var{else} keyword matches the first \var{if} keyword
(searching backwards) not already matched by an \var{else} keyword.
\end{itemize}
For example:
\begin{verbatim}
If exp1 Then
  If exp2 then
    Stat1
else
  stat2;
\end{verbatim}
Despite its appearance, the statement is syntactically equivalent to
\begin{verbatim}
If exp1 Then
   begin
   If exp2 then
      Stat1
   else
      stat2
   end;
\end{verbatim}
and not to
\begin{verbatim}
{ NOT EQUIVALENT }
If exp1 Then
   begin
   If exp2 then
      Stat1
   end
else
   stat2;
\end{verbatim}
If it is this latter construct which is needed, the \var{begin} and \var{end}
keywords must be present. When in doubt, it is better to add them.

The following is a valid statement:
\begin{verbatim}
If Today in [Monday..Friday] then
  WriteLn ('Must work harder')
else
  WriteLn ('Take a day off.');
\end{verbatim}

\subsection{The \var{For..to/downto..do} statement}
\index{Statements!For}\index{Statements!Loop}\index{For}\index{For!to}\index{For!downto}
\keywordlink{for}\keywordlink{do}\keywordlink{downto}
\fpc supports the \var{For} loop construction. A \var{for} loop is used in case
one wants to calculate something a fixed number of times.
The prototype syntax is as follows:
\input{syntax/for.syn}
Here, \var{Statement} can be a compound statement.
When the \var{For} statement is encountered, the control variable is initialized with
the initial value, and is compared with the final value.
What happens next depends on whether \var{to} or \var{downto} is used:
\begin{enumerate}
\item In the case \var{To} is used, if the initial value is larger than the final
value then \var{Statement} will never be executed.
\item In the case \var{DownTo} is used, if the initial value is less than the final
value then \var{Statement} will never be executed.
\end{enumerate}
After this check, the statement after \var{Do} is executed. After the
execution of the statement, the control variable is increased or decreased
by 1, depending on whether \var{To} or \var{Downto} is used.
The control variable must be an ordinal type, no other
types can be used as counters in a loop.

\begin{remark}
\begin{itemize}
\item \fpc always calculates the upper bound exactly once before initializing
the counter variable with the initial value.
\item It is not allowed to change (i.\,e. assign a value to) the value of a
loop variable inside the loop.
\item The value of the loop variable is undefined after a loop has completed or if a loop is not executed at all. 
However, if the loop was terminated prematurely with an exception or a \var{break} or \var{goto} statement, 
the loop variable retains the value it had when the loop was exited.
\item For nested procedures, a loop variable must be a local variable.
If you declare a loop variable outside the nested procedure where the loop is, the compiler will
complain. It is however allowed to use a global variable in a procedure.
\item The compiler does not expliticly forbid jumping with a \var{goto} statement into a for loop block, 
but doing so will result in unpredictable behaviour. 
\end{itemize}
\end{remark}

The following are valid loops:
\begin{verbatim}
For Day := Monday to Friday do Work;
For I := 100 downto 1 do
  WriteLn ('Counting down : ',i);
For I := 1 to 7*dwarfs do KissDwarf(i);
\end{verbatim}
The following will generate an error:
\begin{verbatim}
For I:=0 to 100 do
  begin
  DoSomething;
  I:=I*2;
  end;
\end{verbatim}
because the loop variable \var{I} cannot be assigned to inside the loop.

The following will also generate an error:
\begin{verbatim}
program test;

{$ifdef fpc}
{$mode delphi}
{$h+}
{$endif}

procedure Proc;
var
  i: integer;
  procedure Nested;

  begin
    for i := 1 to 2 do ;
  end;

begin
end;

begin
end.
\end{verbatim}
because the variable \var{I} is not defined in \var{Nested} and it's not
a global variable either.

But the following will compile:
\begin{verbatim}
program test;

{$ifdef fpc}
{$mode delphi}
{$h+}
{$endif}

var
  i: integer;

procedure Nested;

begin
  for i := 1 to 2 do ;
end;

begin
end.
\end{verbatim}


If the statement is a compound statement, then the \var{Break} and
\var{Continue} system routines can be used to jump to the end or just
after the end of the \var{For} statement. Note that \var{Break} and
\var{Continue} are not reserved words and therefore can be overloaded.

\subsection{The \var{For..in..do} statement}
\label{se:forin}\index{Statements!For}\index{Statements!Loop}\index{For}\index{For!in}
\keywordlink{forin}\keywordlink{do}
As of version 2.4.2, \fpc supports the \var{For..in} loop construction. A
\var{for..in} loop is used in case one wants to calculate something a fixed number of times
with an enumerable loop variable. The prototype syntax is as follows:
\input{syntax/forin.syn}
Here, \var{Statement} can be a compound statement. The enumerable must be an
expression that consists of a fixed number of elements: the loop variable
will be made equal to each of the elements in turn and the statement following the
\var{do} keyword will be executed.

The enumerable expression can be one of five cases:
\begin{enumerate}
\item An enumeration type identifier. The loop will then be over all
elements of the enumeration type. The control variable must be of the
enumeration type.
\item A set value. The loop will then be over all elements in the set, the
control variable must be of the base type of the set.
\item An array value. The loop will be over all elements in the array, and
the control variable must have the same type as an element in the array.
As a special case, a string is regarded as an array of characters.
\item An enumerable class, object, or extended record instance. This is an instance of any
structured type that supports the \var{IEnumerator} and \var{IEnumerable} interfaces.
In this case, the control variable's type must equal the type of the
\var{IEnumerator.GetCurrent} return value.
\item Any type for which an \var{enumerator} operator is defined. The
\var{enumerator} operator must return a structured type that implements the
\var{IEnumerator} interface. The type of the control variable's type
must equal the type of the enumerator's \var{GetCurrent} return
value type.
\end{enumerate}

The simplest case of the \var{for..in} loop is using an enumerated type:
\begin{verbatim}
Type
  TWeekDay = (monday, tuesday, wednesday, thursday,
              friday,saturday,sunday);

Var
  d : TWeekday;

begin
  for d in TWeekday do
    writeln(d);
end.
\end{verbatim}
This will print all week days to the screen.

The above \var{for..in} construct is equivalent to the following
\var{for..to} construct:
\begin{verbatim}
Type
  TWeekDay = (monday, tuesday, wednesday, thursday,
              friday,saturday,sunday);

Var
  d : TWeekday;

begin
  for d:=Low(TWeekday) to High(TWeekday) do
    writeln(d);
end.
\end{verbatim}

A second case of \var{for..in} loop is when the enumerable expression is a set,
and then the loop will be executed once for each element in the set:
\begin{verbatim}
Type
  TWeekDay = (monday, tuesday, wednesday, thursday,
              friday,saturday,sunday);

Var
  Week : set of TWeekDay
       = [monday, tuesday, wednesday, thursday, friday];
  d : TWeekday;

begin
  for d in Week do
    writeln(d);
end.
\end{verbatim}
This will print the names of the week days to the screen. Note that the
variable \var{d} is of the same type as the base type of the set.

The above \var{for..in} construct is equivalent to the following
\var{for..to} construct:
\begin{verbatim}
Type
  TWeekDay = (monday, tuesday, wednesday, thursday,
              friday,saturday,sunday);

Var
  Week : set of TWeekDay
       = [monday, tuesday, wednesday, thursday, friday];

  d : TWeekday;

begin
  for d:=Low(TWeekday) to High(TWeekday) do
    if d in Week then
      writeln(d);
end.
\end{verbatim}

The third possibility for a \var{for..in} loop is when the enumerable expression
is an array:
\begin{verbatim}
var
  a : Array[1..7] of string
    = ('monday','tuesday','wednesday','thursday',
       'friday','saturday','sunday');

Var
  S : String;

begin
  For s in a do
    Writeln(s);
end.
\end{verbatim}
This will also print all days in the week, and is equivalent to
\begin{verbatim}
var
  a : Array[1..7] of string
    = ('monday','tuesday','wednesday','thursday',
       'friday','saturday','sunday');

Var
  i : integer;

begin
  for i:=Low(a) to high(a) do
    Writeln(a[i]);
end.
\end{verbatim}
A \var{string} type is equivalent to an \var{array of char}, and therefore
a string can be used in a \var{for..in} loop. The following will
print all letters in the alphabet, each letter on a line:
\begin{verbatim}
Var
  c : char;

begin
 for c in 'abcdefghijklmnopqrstuvwxyz' do
   writeln(c);
end.
\end{verbatim}

Note that multi-dimensional arrays are also supported:
\begin{verbatim}
uses
  SysUtils;

type
  TTestStringArray = array[0..10] of String;

Var
  TwoD : array[0..3] of TTestStringArray;

var
  i,j : integer;
  S : String;
begin
  for i:=0 to 3 do
    for j:=0 to 10 do
      TwoD[i,J]:=Format('%.2dx%.2d',[i,j]);
  for S in twod do
    Writeln(S);
end.
\end{verbatim}
This will loop over all dimensions from left to right.

The fourth possibility for a \var{for..in} loop is using classes. A class can implement the
\var{IEnumerable} interface, which is defined as
follows:
\begin{verbatim}
IEnumerable = interface(IInterface)
  function GetEnumerator: IEnumerator;
end;
\end{verbatim}
The actual return type of the \var{GetEnumerator} must not necessarily be an
\var{IEnumerator} interface, instead, it can be a class which implements the methods
of \var{IEnumerator}:
\begin{verbatim}
IEnumerator = interface(IInterface)
  function GetCurrent: TObject;
  function MoveNext: Boolean;
  procedure Reset;
  property Current: TObject read GetCurrent;
end;
\end{verbatim}
The \var{Current} property and the \var{MoveNext} method must be present in
the class returned by the \var{GetEnumerator} method. The actual type of the
\var{Current} property need not be a \var{TObject}. When encountering a
\var{for..in} loop with a class instance as the ``in'' operand, the compiler will
check each of the following conditions:
\begin{itemize}
\item Whether the class in the enumerable expression implements a method
\var{GetEnumerator}
\item Whether the result of \var{GetEnumerator} is a class with the
following method:
\begin{verbatim}
Function MoveNext : Boolean
\end{verbatim}
\item Whether the result of \var{GetEnumerator} is a class with the
following read-only property:
\begin{verbatim}
Property Current : AType;
\end{verbatim}
The type of the property must match the type of the control variable of the
\var{for..in} loop.
\end{itemize}
Neither the \var{IEnumerator} nor the \var{IEnumerable} interfaces must
actually be declared by the enumerable class: the compiler will detect
whether these interfaces are present using the above checks. The interfaces
are only defined for Delphi compatibility and are not used internally.
(it would also be impossible to enforce their correctness).

The \file{Classes} unit contains a number of classes that are enumerable:
\begin{description}
\item[TFPList] Enumerates all pointers in the list.
\item[TList] Enumerates all pointers in the list.
\item[TCollection] Enumerates all items in the collection.
\item[TStringList] Enumerates all strings in the list.
\item[TComponent] Enumerates all child components owned by the component.
\end{description}
Thus, the following code will also print all days in the week:
\begin{verbatim}
{$mode objfpc}
uses classes;

Var
  Days : TStrings;
  D : String;

begin
  Days:=TStringList.Create;
  try
    Days.Add('Monday');
    Days.Add('Tuesday');
    Days.Add('Wednesday');
    Days.Add('Thursday');
    Days.Add('Friday');
    Days.Add('Saturday');
    Days.Add('Sunday');
    For D in Days do
      Writeln(D);
  Finally
    Days.Free;
  end;
end.
\end{verbatim}
Note that the compiler enforces type safety: declaring \var{D} as an integer will
result in a compiler error:
\begin{verbatim}
testsl.pp(20,9) Error: Incompatible types: got "AnsiString" expected "LongInt"
\end{verbatim}

The above code is equivalent to the following:
\begin{verbatim}
{$mode objfpc}
uses classes;

Var
  Days : TStrings;
  D : String;
  E : TStringsEnumerator;

begin
  Days:=TStringList.Create;
  try
    Days.Add('Monday');
    Days.Add('Tuesday');
    Days.Add('Wednesday');
    Days.Add('Thursday');
    Days.Add('Friday');
    Days.Add('Saturday');
    Days.Add('Sunday');
    E:=Days.getEnumerator;
    try
      While E.MoveNext do
        begin
        D:=E.Current;
        Writeln(D);
        end;
    Finally
      E.Free;
    end;
  Finally
    Days.Free;
  end;
end.
\end{verbatim}
Both programs will output the same result.

The fifth and last possibility to use a \var{for..in} loop can be used to
enumerate almost any type, using the \var{enumerator} operator.
The \var{enumerator} operator must return a class that has the same
signature as the \var{IEnumerator} approach above. The following code will
define an enumerator for the \var{Integer} type:
\begin{verbatim}
Type


TEvenEnumerator = Class
  FCurrent : Integer;
  FMax : Integer;
  Function MoveNext : Boolean;
  Property Current : Integer Read FCurrent;
end;

Function TEvenEnumerator.MoveNext : Boolean;

begin
  FCurrent:=FCurrent+2;
  Result:=FCurrent<=FMax;
end;

operator enumerator(i : integer) : TEvenEnumerator;

begin
  Result:=TEvenEnumerator.Create;
  Result.FMax:=i;
end;

var
  I : Integer;
  m : Integer = 4;

begin
  For I in M do
    Writeln(i);
end.
\end{verbatim}
The loop will print all nonzero even numbers smaller or equal to the
enumerable. (2 and 4 in the case of the example).

Care must be taken when defining enumerator operators: the compiler will
find and use the first available enumerator operator for the enumerable
expression. For classes this also means that the \var{GetEnumerator} method
is not even considered. The following code will define an enumerator
operator which extracts the object from a stringlist:
\begin{verbatim}
{$mode objfpc}
uses classes;

Type
  TDayObject = Class
    DayOfWeek : Integer;
    Constructor Create(ADayOfWeek : Integer);
  end;

  TObjectEnumerator = Class
    FList : TStrings;
    FIndex : Integer;
    Function GetCurrent : TDayObject;
    Function MoveNext: boolean;
    Property Current : TDayObject Read GetCurrent;
  end;

Constructor TDayObject.Create(ADayOfWeek : Integer);

begin
  DayOfWeek:=ADayOfWeek;
end;

Function TObjectEnumerator.GetCurrent : TDayObject;
begin
  Result:=FList.Objects[Findex] as TDayObject;
end;

Function TObjectEnumerator.MoveNext: boolean;

begin
  Inc(FIndex);
  Result:=(FIndex<FList.Count);
end;

operator enumerator (s : TStrings) : TObjectEnumerator;

begin
  Result:=TObjectEnumerator.Create;
  Result.Flist:=S;
  Result.FIndex:=-1;
end;

Var
  Days : TStrings;
  D : String;
  O : TdayObject;

begin
  Days:=TStringList.Create;
  try
    Days.AddObject('Monday',TDayObject.Create(1));
    Days.AddObject('Tuesday',TDayObject.Create(2));
    Days.AddObject('Wednesday',TDayObject.Create(3));
    Days.AddObject('Thursday',TDayObject.Create(4));
    Days.AddObject('Friday',TDayObject.Create(5));
    Days.AddObject('Saturday',TDayObject.Create(6));
    Days.AddObject('Sunday',TDayObject.Create(7));
    For O in Days do
      Writeln(O.DayOfWeek);
  Finally
    Days.Free;
  end;
end.
\end{verbatim}
The above code will print the day of the week for each day in the week.

If a class is not enumerable, the compiler will report an error when it is
encountered in a \var{for...in} loop.

\begin{remark}
Like the \var{for..to} loop, it is not allowed to change (i.\,e. assign a value to) the value of a
loop control variable inside the loop.
\end{remark}

\subsection{The \var{Repeat..until} statement}
\index{Statements!Repeat}\index{Statements!Loop}\index{Repeat}
\keywordlink{repeat} \keywordlink{until}
The \var{repeat} statement is used to execute a statement until a certain
condition is reached. The statement will be executed at least once.
The prototype syntax of the \var{Repeat..until} statement is
\input{syntax/repeat.syn}
This will execute the statements between \var{repeat} and \var{until} up to
the moment when \var{Expression}\index{Expression} evaluates to \var{True}.
Since the \var{expression} is evaluated {\em after} the execution of the
statements, they are executed at least once.

Be aware of the fact that the boolean expression \var{Expression} will be
short-cut evaluated by default, meaning that the evaluation will be stopped
at the point where the outcome is known with certainty.

The following are valid \var{repeat} statements
\begin{verbatim}
repeat
  WriteLn ('I =',i);
  I := I+2;
until I>100;

repeat
 X := X/2
until x<10e-3;
\end{verbatim}
Note that the last statement before the \var{until} keyword does not need
a terminating semicolon, but it is allowed.

The \var{Break} and \var{Continue} system routines can be used to jump to
the end or just after the end of the \var{repeat .. until} statement.
Note that \var{Break} and \var{Continue} are not reserved words and
therefore can be overloaded.

\subsection{The \var{While..do} statement}
\index{Statements!While}\index{Statements!Loop}\index{While} \keywordlink{while}
A \var{while} statement is used to execute a statement as long as a certain
condition holds. In difference with the \var{repeat} loop, this may imply
that the statement is never executed.

The prototype syntax of the \var{While..do} statement is
\input{syntax/while.syn}
This will execute \var{Statement} as long as \var{Expression} evaluates
to\index{Expression}\var{True}. Since \var{Expression} is evaluated {\em before} the execution
of \var{Statement}, it is possible that \var{Statement} isn't executed at
all. \var{Statement} can be a compound statement.

Be aware of the fact that the boolean expression \var{Expression} will be
short-cut evaluated by default, meaning that the evaluation will be stopped
at the point where the outcome is known with certainty.

The following are valid \var{while} statements:
\begin{verbatim}
I := I+2;
while i<=100 do
  begin
  WriteLn ('I =',i);
  I := I+2;
  end;
X := X/2;
while x>=10e-3 do
  X := X/2;
\end{verbatim}
They correspond to the example loops for the \var{repeat} statements.

If the statement is a compound statement, then  the \var{Break} and
\var{Continue} reserved words can be used to jump to the end or just
after the end of the \var{While} statement.
Note that \var{Break} and \var{Continue} are not reserved words and
therefore can be overloaded.

\subsection{The \var{With} statement}
\label{se:With}\index{With}\index{Statements!With} \keywordlink{with}
The \var{with} statement serves to access the elements of a record
or object or class, without having to specify the element's name each time.
The syntax for a \var{with} statement is
\input{syntax/with.syn}
The variable reference must be a variable of a record, object or class type.
In the \var{with} statement, any variable reference, or method reference is
checked to see if it is a field or method of the record or object or class.
If so, then that field is accessed, or that method is called.
Given the declaration:
\begin{verbatim}
Type
  Passenger = Record
    Name : String[30];
    Flight : String[10];
  end;

Var
  TheCustomer : Passenger;
\end{verbatim}
The following statements are completely equivalent:
\begin{verbatim}
TheCustomer.Name := 'Michael';
TheCustomer.Flight := 'PS901';
\end{verbatim}
and
\begin{verbatim}
With TheCustomer do
  begin
  Name := 'Michael';
  Flight := 'PS901';
  end;
\end{verbatim}
The statement
\begin{verbatim}
With A,B,C,D do Statement;
\end{verbatim}
is equivalent to
\begin{verbatim}
With A do
 With B do
  With C do
   With D do Statement;
\end{verbatim}
This also is a clear example of the fact that the variables are tried {\em last
to first}, i.\,e., when the compiler encounters a variable reference, it will
first check if it is a field or method of the last variable. If not, then it
will check the last-but-one, and so on.
The following example shows this;
\begin{verbatim}
Program testw;
Type AR = record
      X,Y : Longint;
     end;
     PAR = ^Ar;

Var S,T : Ar;
begin
  S.X := 1;S.Y := 1;
  T.X := 2;T.Y := 2;
  With S,T do
    WriteLn (X,' ',Y);
end.
\end{verbatim}
The output of this program is
\begin{verbatim}
2 2
\end{verbatim}
Showing thus that the \var{X,Y} in the \var{WriteLn} statement match the
\var{T} record variable.

\begin{remark}
When using a \var{With} statement with a pointer, or a class, it is not
permitted to change the pointer or the class in the \var{With} block.
With the definitions of the previous example, the following illustrates
what it is about:
\begin{verbatim}
Var p : PAR;

begin
  With P^ do
   begin
   // Do some operations
   P:=OtherP;
   X:=0.0;  // Wrong X will be used !!
   end;
\end{verbatim}
The reason the pointer cannot be changed is that the address is stored
by the compiler in a temporary register. Changing the pointer won't change
the temporary address. The same is true for classes.
\end{remark}

\subsection{Exception Statements}
\index{Statements!Exception}
\fpc supports exceptions. Exceptions provide a convenient way to
program error and error-recovery mechanisms, and are
closely related to classes.
Exception support is explained in \seec{Exceptions}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Assembler statements
\section{Assembler statements}
\index{Statements!Assembler}\index{Asm}\index{Assembler}
An assembler statement allows to insert assembler code right in the
Pascal code.
\input{syntax/statasm.syn}
More information about assembler blocks can be found in the \progref.
The register list is used to indicate the registers that are modified by an
assembler statement in the assembler block. The compiler stores certain results in the
registers. If the registers are modified in an assembler statement, the compiler
should, sometimes, be told about it. The registers are denoted with their
Intel names for the I386 processor, i.\,e., \var{'EAX'}, \var{'ESI'} etc...
As an example, consider the following assembler code:
\begin{verbatim}
asm
  Movl $1,%ebx
  Movl $0,%eax
  addl %eax,%ebx
end ['EAX','EBX'];
\end{verbatim}
This will tell the compiler that it should save and restore the contents of
the \var{EAX} and \var{EBX} registers when it encounters this asm statement.

\fpc supports various styles of assembler syntax. By default, \var{AT\&T}
syntax is assumed for the 80386 and compatibles platform.
The default assembler style can be changed with the \var{\{\$asmmode xxx\}}
switch in the code, or the \var{-R} command-line option. More about this can
be found in the \progref.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Using functions and procedures.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Using functions and procedures}
\label{ch:Procedures}\index{Functions}\index{Procedures}
\fpc supports the use of functions and procedures. It supports
\begin{itemize}
\item Function overloading, i.\,e. functions with the same name but different
parameter lists.
\item \var{Const} parameters.
\item Open arrays (i.\,e. arrays without bounds).
\item Variable number of arguments as in C.
\item Return-like construct as in C, through the \var{Exit} keyword.
\end{itemize}

\begin{remark} In many of the subsequent paragraphs the words \var{procedure}
and \var{function} will be used interchangeably. The statements made are
valid for both, except when indicated otherwise.
\end{remark}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Procedure declaration
\section{Procedure declaration}
A procedure declaration defines an identifier and associates it with a
block of code. The procedure can then be called with a procedure statement.
\input{syntax/procedur.syn}
See \sees{Parameters} for the list of parameters.\index{Procedure}
\keywordlink{procedure}
A procedure declaration that is followed by a block implements the action of
the procedure in that block.
The following is a valid procedure:
\begin{verbatim}
Procedure DoSomething (Para : String);
begin
  Writeln ('Got parameter : ',Para);
  Writeln ('Parameter in upper case : ',Upper(Para));
end;
\end{verbatim}
Note that it is possible that a procedure calls itself.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Function declaration
\section{Function declaration}
\keywordlink{function}
A function declaration defines an identifier and associates it with a
block of code. The block of code will return a result.
The function can then be called inside an expression, or with a procedure
statement, if extended syntax is on.
\input{syntax/function.syn}
\index{Function}The result type of a function can be any previously declared type.
contrary to Turbo Pascal, where only simple types could be returned.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Function results
\section{Function results}
The result of a function can be set by setting the result variable:
this can be the function identifier or, (only in \var{ObjFPC} or \var{Delphi} mode)
the special \var{Result} identifier:
\begin{verbatim}
Function MyFunction : Integer;

begin
  MyFunction:=12; // Return 12
end;
\end{verbatim}
In \var{Delphi} or \var{ObjFPC} mode, the above can also be coded as:
\begin{verbatim}
Function MyFunction : Integer;

begin
  Result:=12;
end;
\end{verbatim}
As an extension to \delphi syntax, the \var{ObjFPC} mode also supports a special
extension of the \var{Exit} procedure:
\begin{verbatim}
Function MyFunction : Integer;

begin
  Exit(12);
end;
\end{verbatim}
The \var{Exit} call sets the result of the function and jumps to the final
\var{End} of the function declaration block. It can be seen as the equivalent
of the C \var{return} instruction.

\begin{remark}
Function results are treated as pass-by-reference parameters.
That is especially important for managed types:
The function result may be non-nil on entry, and set to a valid instance of the type.
\end{remark}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Parameter lists
\section{Parameter lists}
\label{se:Parameters}\index{Parameters}
When arguments must be passed to a function or procedure, these parameters
must be declared in the formal parameter list of that function or procedure.
The parameter list is a declaration of identifiers that can be referred to
only in that procedure or function's block.
\input{syntax/params.syn}
Constant parameters, out parameters and variable parameters can also be \var{untyped}
parameters if they have no type
identifier.\index{Parameters!Untypes}\index{Parameters!Constant}\index{Parameters!Var}

As of version 1.1, \fpc supports default values for both constant parameters
and value parameters, but only for simple types. The compiler must be in
\var{OBJFPC} or \var{DELPHI} mode to accept default values.

\subsection{Value parameters}
Value parameters are declared as follows:\index{Parameters!Value}
\input{syntax/paramval.syn}
When parameters are declared as value parameters, the procedure gets {\em
a copy} of the parameters that the calling statement passes. Any modifications
to these parameters are purely local to the procedure's block, and do not
propagate back to the calling block.

A block that wishes to call a procedure with value parameters must pass
assignment compatible parameters to the procedure\index{Type!Compatibility}.
This means that the types
should not match exactly, but can be converted to the actual parameter
types. This conversion code is inserted by the compiler itself.

Care must be taken when using value parameters: value parameters makes heavy
use of the stack, especially when using large parameters. The total size of
all parameters in the formal parameter list should be below 32K for
portability's sake (the Intel version limits this to 64K).

Open arrays can be passed as value parameters. See \sees{openarray} for
more information on using open arrays.

For a parameter of a  simple type (i.\,e. not a structured type), a default
value can be specified. This can be an untyped constant. If the function
call omits the parameter, the default value will be passed on to the
function. For dynamic arrays or other types that can be considered as
equivalent to a pointer, the only possible default value is \var{Nil}.

The following example will print 20 on the screen:
\begin{verbatim}
program testp;

Const
  MyConst = 20;

Procedure MyRealFunc(I : Integer = MyConst);

begin
  Writeln('Function received : ',I);
end;

begin
  MyRealFunc;
end.
\end{verbatim}

\subsection{Variable parameters}
\label{se:varparams}\index{Parameters!Var}\keywordlink{var}
Variable parameters are declared as follows:
\input{syntax/paramvar.syn}
When parameters are declared as variable parameters, the procedure or
function accesses immediately the variable that the calling block passed in
its parameter list. The procedure gets a pointer to the variable that was
passed, and uses this pointer to access the variable's value.
From this, it follows that any changes made to the parameter, will
propagate back to the calling block. This mechanism can be used to pass
values back in procedures.
Because of this, the calling block must pass a parameter of {\em exactly}
the same type as the declared parameter's type. If it does not, the compiler
will generate an error.

Variable and constant parameters can be untyped. In that case the variable has no type,
and hence is incompatible with all other types. However, the address operator
can be used on it, or it can be passed to a function that has also an
untyped parameter. If an untyped parameter is used in an assignment,
or a value must be assigned to it, a typecast must be used.

File type variables must always be passed as variable parameters.

Open arrays can be passed as variable parameters. See \sees{openarray} for
more information on using open arrays.

\begin{remark}
\begin{itemize}
\item Note that default values are not supported for variable parameters. This
would make little sense since it defeats the purpose of being able to pass a
value back to the caller.
\item A function result is internally treated as a variable parameter, and
may have a non-zero (or non-nil) initial value. This is especially important
for managed types.
\end{itemize}
\end{remark}



\subsection{Out parameters}
\label{se:outparams}\index{Parameters!Out}\keywordlink{out}
Out parameters  (output parameters) are declared as follows:
\input{syntax/paramout.syn}
The purpose of an \var{out} parameter is to pass values back to the calling
routine: the variable is passed by reference. The initial value of the
parameter on function entry is discarded, and should not be used.

If a variable must be used to pass a value to a function and retrieve data
from the function, then a variable parameter must be used. If only a value
must be retrieved, a \var{out} parameter can be used.

Needless to say, default values are not supported for \var{out} parameters.

The difference of \var{out} parameters and parameters by reference is very small
(however, see below for managed types):
the former gives the compiler more information about what happens to the
arguments when passed to the procedure: it knows that the variable does not
have to be initialized prior to the call. The following example illustrates
this:
\begin{verbatim}
Procedure DoA(Var A : Integer);

begin
  A:=2;
  Writeln('A is ',A);
end;

Procedure DoB(Out B : Integer);

begin
  B:=2;
  Writeln('B is ',B);
end;

Var
  C,D : Integer;

begin
  DoA(C);
  DoB(D);
end.
\end{verbatim}
Both procedures \var{DoA} and \var{DoB} do practically the same. But
\var{DoB}'s declaration gives more information to the compiler, allowing
it to detect that \var{D} does not have to initialized before \var{DoB}
is called. Since the parameter \var{A} in \var{DoA} can receive a value as
well as return one, the compiler notices that \var{C} was not initialized
prior to the call to \var{DoA}:
\begin{verbatim}
home: >fpc -S2 -vwhn testo.pp
testo.pp(19,8) Hint: Variable "C" does not seem to be initialized
\end{verbatim}
This shows that it is better to use \var{out} parameters when the parameter
is used only to return a value.

\begin{remark}
\var{Out} parameters are only supported in \var{Delphi} and \var{ObjFPC} mode. For the other
modes, \var{out} is a valid identifier.
\end{remark}

\begin{remark}
For managed types (reference counted types), using \var{Out} parameters incurs some overhead:
the compiler must be sure that the value is correctly initialized (i.\,e. has a reference count
of zero (0)). This initialization is normally done by the caller.
\end{remark}



%
\subsection{Constant parameters}\index{Parameters!Constant}\keywordlink{const}
In addition to variable parameters and value parameters \fpc also supports
Constant parameters. A constant parameter can be specified as follows:
\input{syntax/paramcon.syn}
Specifying a parameter as Constant is giving the compiler a hint that the
contents of the parameter will not be changed by the called routine. This
allows the compiler to perform optimizations which it could not do otherwise,
and also to perform certain checks on the code inside the routine: namely,
it can forbid assignments to the parameter.
Furthermore a const parameter cannot be passed on to another
function that requires a variable parameter: the compiler can check this as
well.
The main use for this is reducing the stack size, hence improving
performance, and still retaining the semantics of passing by value...

\begin{remark}
Contrary to Delphi, no assumptions should be made about how const parameters
are passed to the underlying routine. In particular, the assumption that
parameters with large size are passed by reference is not correct. For this
the \var{constref} parameter type should be used, which is available as of
version 2.5.1 of the compiler.

An exception is the \var{stdcall} calling convention: for compatibility with
COM standards, large const parameters are passed by reference.
\end{remark}

\begin{remark}
Note that specifying \var{const} is a contract between the programmer and the
compiler. It is the programmer who tells the compiler that the contents of
the const parameter will not be changed when the routine is executed, it is
{\em not} the compiler who tells the programmer that the parameter will not be
changed.

This is particularly important and visible when using refcounted types.
For such types, the (invisible) incrementing and decrementing of any reference
count is omitted when \var{const} is used. Doing so often allows the compiler
to omit invisible try/finally frames for these routines.

As a side effect, the following code will produce not the expected output:
\begin{verbatim}
Var
  S : String = 'Something';

Procedure DoIt(Const T : String);

begin
  S:='Something else';
  Writeln(T);
end;

begin
  DoIt(S);
end.
\end{verbatim}
Will write
\begin{verbatim}
Something else
\end{verbatim}
This behavior is by design.
\end{remark}

Constant parameters can also be untyped. See \sees{varparams} for more
information about untyped parameters.

As for value parameters, constant parameters can get default values.

Open arrays can be passed as constant parameters. See \sees{openarray} for
more information on using open arrays.

\subsection{Open array parameters}
\index{Parameters!Open Array}\index{Array}
\label{se:openarray}
\fpc supports the passing of open arrays, i.\,e. a procedure can be declared
with an array of unspecified length as a parameter, as in Delphi.
Open array parameters can be accessed in the procedure or function as an
array that is declared with starting index 0, and last element
index \var{High(parameter)}.
For example, the parameter
\begin{verbatim}
Row : Array of Integer;
\end{verbatim}
would be equivalent to
\begin{verbatim}
Row : Array[0..N-1] of Integer;
\end{verbatim}
Where  \var{N} would be the actual size of the array that is passed to the
function. \var{N-1} can be calculated as \var{High(Row)}.

Specifically, if an empty array is passed, then \var{High(Parameter)} returns -1,
while \var{low(Parameter)} returns 0.

Open parameters can be passed by value, by reference or as a constant
parameter. In the latter cases the procedure receives a pointer to the
actual array. In the former case, it receives a copy of the array.
In a function or procedure, open arrays can only be passed to functions which
are also declared with open arrays as parameters, {\em not} to functions or
procedures which accept arrays of fixed length.
The following is an example of a function using an open array:
\begin{verbatim}
Function Average (Row : Array of integer) : Real;
Var I : longint;
    Temp : Real;
begin
  Temp := Row[0];
  For I := 1 to High(Row) do
    Temp := Temp + Row[i];
  Average := Temp / (High(Row)+1);
end;
\end{verbatim}

As of FPC 2.2, it is also possible to pass partial arrays to a function that
accepts an open array. This can be done by specifying the range of the array
which should be passed to the open array.

Given the declaration
\begin{verbatim}
Var
  A : Array[1..100];
\end{verbatim}
the following call will compute and print the average of the 100 numbers:
\begin{verbatim}
  Writeln('Average of 100 numbers: ',Average(A));
\end{verbatim}
But the following will compute and print the average of the first and second
half:
\begin{verbatim}
  Writeln('Average of first 50 numbers: ',Average(A[1..50]));
  Writeln('Average of last  50 numbers: ',Average(A[51..100]));
\end{verbatim}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% The array of const construct
\subsection{Array of const}
\index{Parameters!Open Array}\index{Array}\index{Array!Of const}
In Object Pascal or Delphi mode, \fpc supports the \var{Array of Const}
construction to pass parameters to a subroutine.

This is a special case of the \var{Open array} construction, where it is
allowed to pass any expression in an array to a function or procedure.
The expression must have a simple result type: structures cannot be passed
as an argument. This means that all ordinal, float or string types can be
passed, as well as pointers, classes and interfaces (since the latter two
are actually pointers).

The elements of the \var{array of const} are converted to a special variant record:
\begin{verbatim}
Type
  PVarRec = ^TVarRec;
  TVarRec = record
     case VType : Ptrint of
       vtInteger    : (VInteger: Longint);
       vtBoolean    : (VBoolean: Boolean);
       vtChar       : (VChar: Char);
       vtWideChar   : (VWideChar: WideChar);
       vtExtended   : (VExtended: PExtended);
       vtString     : (VString: PShortString);
       vtPointer    : (VPointer: Pointer);
       vtPChar      : (VPChar: PChar);
       vtObject     : (VObject: TObject);
       vtClass      : (VClass: TClass);
       vtPWideChar  : (VPWideChar: PWideChar);
       vtAnsiString : (VAnsiString: Pointer);
       vtCurrency   : (VCurrency: PCurrency);
       vtVariant    : (VVariant: PVariant);
       vtInterface  : (VInterface: Pointer);
       vtWideString : (VWideString: Pointer);
       vtInt64      : (VInt64: PInt64);
       vtQWord      : (VQWord: PQWord);
   end;
\end{verbatim}
Therefore, inside the procedure body, the \var{array of const} argument is equivalent to
an open array of \var{TVarRec}:
\begin{verbatim}
Procedure Testit (Args: Array of const);

Var I : longint;

begin
  If High(Args)<0 then
    begin
    Writeln ('No aguments');
    exit;
    end;
  Writeln ('Got ',High(Args)+1,' arguments :');
  For i:=0 to High(Args) do
    begin
    write ('Argument ',i,' has type ');
    case Args[i].vtype of
      vtinteger    :
        Writeln ('Integer, Value :',args[i].vinteger);
      vtboolean    :
        Writeln ('Boolean, Value :',args[i].vboolean);
      vtchar       :
        Writeln ('Char, value : ',args[i].vchar);
      vtextended   :
        Writeln ('Extended, value : ',args[i].VExtended^);
      vtString     :
        Writeln ('ShortString, value :',args[i].VString^);
      vtPointer    :
        Writeln ('Pointer, value : ',Longint(Args[i].VPointer));
      vtPChar      :
        Writeln ('PChar, value : ',Args[i].VPChar);
      vtObject     :
        Writeln ('Object, name : ',Args[i].VObject.Classname);
      vtClass      :
        Writeln ('Class reference, name :',Args[i].VClass.Classname);
      vtAnsiString :
        Writeln ('AnsiString, value :',AnsiString(Args[I].VAnsiString);
    else
        Writeln ('(Unknown) : ',args[i].vtype);
    end;
    end;
end;
\end{verbatim}
In code, it is possible to pass an arbitrary array of elements
to this procedure:
\begin{verbatim}
  S:='Ansistring 1';
  T:='AnsiString 2';
  Testit ([]);
  Testit ([1,2]);
  Testit (['A','B']);
  Testit ([TRUE,FALSE,TRUE]);
  Testit (['String','Another string']);
  Testit ([S,T])  ;
  Testit ([P1,P2]);
  Testit ([@testit,Nil]);
  Testit ([ObjA,ObjB]);
  Testit ([1.234,1.234]);
  TestIt ([AClass]);
\end{verbatim}

If the procedure is declared with the \var{cdecl} modifier, then the
compiler will pass the array as a C compiler would pass it. This, in effect,
emulates the C construct of a variable number of arguments, as the following
example will show:
\begin{verbatim}
program testaocc;
{$mode objfpc}

Const
  P : PChar = 'example';
  Fmt : PChar =
        'This %s uses printf to print numbers (%d) and strings.'#10;

// Declaration of standard C function printf:
procedure printf (fm : pchar; args : array of const);cdecl; external 'c';

begin
 printf(Fmt,[P,123]);
end.
\end{verbatim}
\begin{remark}
Note that this is not true for Delphi, so code relying on this feature
will not be portable.
\end{remark}

\begin{remark}
Note that there is no support for \var{DWord} (or cardinal) arguments in \var{array of const}.
They are converted to \var{vtInteger}/\var{vtLongint}.
This is for Delphi compatibility, and the compiler will ignore any resulting range checks
when in mode Delphi.
\end{remark}

\subsection{Untyped parameters}
\index{Parameters!Untyped}
Variable, Out and constant parameters can be untyped. In that case the variable has no type
in the procedure of function, and hence is incompatible with all other
types: The compiler simply passes the address of the passed variable to the
routine, so all that is available in the called routine is an address, with
no type information attached to it. This is also true for const parameters. 

Using an analogy
\begin{verbatim}
procedure Something(const Data; Len: cint);
\end{verbatim}
Is equivalent to the following C/C++ declaration:
\begin{verbatim}
void Something(void* Data; int Len);
\end{verbatim}
This means pretty much all that one can do in the routine is use the address operator
or pass the argument to another function that has also an untyped parameter. 

Inside a routine with an untyped parameter, if the untyped parameter is used in an 
expression, or a value must be assigned to it a typecast must always be used. 

The following example shows this:
\begin{verbatim}
{$mode objfpc}
uses types;

procedure doit(const d);

begin
  Writeln('As integer: ',PInteger(@D)^);
  Writeln('As Byte   : ',PByte(@D)^);
end;

Var
  D : Integer;

begin
  D:=$0FFFFFF0;
  DoIt(D);
end.
\end{verbatim}
This will write:
\begin{verbatim}
As integer: 268435440
As Byte   : 240
\end{verbatim}

Note that because an address is needed, no constant expressions can be
passed to the function or procedure, i.\,e. given the above definition, 
the following will not work:
\begin{verbatim}
 DoIt($0FFFFFF0);
\end{verbatim}
This will result in the following error:
\begin{verbatim}
Error: Variable identifier expected
\end{verbatim}



\subsection{Managed types and reference counts}
\index{Parameters!Reference counted}
Some types (Unicodestring, Ansistring, interfaces, dynamic arrays) are
treated somewhat specially by the compiler: the data has a reference count
which is increased or decreased depending on how many reference to the data
exists.

The qualifiers for parameters in function or procedure calls influence
what happens to the reference count of the managed types:
\begin{itemize}
\item nothing (pass by value): the reference count of the parameter is increased
on entry and decreased on exit.
\item \var{out}: the reference count of the value that is passed in is decreased by 1,
 and the variable that's passed into the procedure is initialized to ``empty''
(usually \var{Nil}, but that is an implementation detail which should not
be relied on).
\item \var{var} nothing happens to the reference count. A reference to the original
 variable is passed in, and changing it or reading it has exactly the same effect as changing/reading the original variable.
\item \var{const} this case is slightly tricky. Nothing happens to the reference
count because you can pass non-values here.
In particular, you can pass a class implementing an interface rather than the interface itself
which can cause the class to be freed unexpectedly.
\end{itemize}

\begin{remark}
The function result is internally treated as a var parameter to the
function, and the same rules as for var parameters apply.
\end{remark}

The following example demonstrates the dangers:
\begin{verbatim}
{$mode objfpc}

Type
  ITest = Interface
    Procedure DoTest(ACount : Integer);
  end;

  TTest = Class(TInterfacedObject,ITest)
    Procedure DoTest(ACount : Integer);
    Destructor destroy; override;
  end;

Destructor TTest.Destroy;

begin
  Writeln('Destroy called');
end;

Procedure TTest.DoTest(ACount : Integer);

begin
  Writeln('Test ',ACount,' : ref count: ',RefCount);
end;

procedure DoIt1(x: ITest; ACount : Integer);

begin
  // Reference count is increased
  x.DoTest(ACount);
  // And decreased
end;

procedure DoIt2(const x: ITest; ACount : Integer);

begin
  // No change to reference count.
  x.DoTest(ACount);
end;

Procedure Test1;

var
  y: ITest;
begin
  y := TTest.Create;
  // Ref. count is 1 at this point.
  y.DoTest(1);
  // Calling DoIT will increase reference count and decrease on exit.
  DoIt1(y,2);
  // Reference count is still one.
  y.DoTest(3);
end;

Procedure Test2;

var
  Y : TTest;
begin
  Y := TTest.Create; // no count on the object yet
  // Ref. count is 0 at this point.
  y.DoTest(3);
  // Ref count will remain zero.
  DoIt2(y,4);
  Y.DoTest(5);
  Y.Free;
end;

Procedure Test3;

var
  Y : TTest;
begin
  Y := TTest.Create; // no count on the object yet
  // Ref. count is 0 at this point.
  y.DoTest(6);
  // Ref count will remain zero.
  DoIt1(y,7);
  y.DoTest(8);
end;


begin
  Test1;
  Test2;
  Test3;
end.
\end{verbatim}
The output of this example is:
\begin{verbatim}
Test 1 : ref count: 1
Test 2 : ref count: 2
Test 3 : ref count: 1
Destroy called
Test 3 : ref count: 0
Test 4 : ref count: 0
Test 5 : ref count: 0
Destroy called
Test 6 : ref count: 0
Test 7 : ref count: 1
Destroy called
Test 8 : ref count: 0
\end{verbatim}
As can be seen, in test3, the reference count is decreased from 1 to 0 at
the end of the DoIt call, causing the instance to be freed before the call
returns.

The following small program demonstrates the reference counts used in strings:
\begin{verbatim}
{$mode objfpc}
{$H+}

// Auxiliary function to extract reference count.
function SRefCount(P : Pointer) : integer;

Type
  PAnsiRec = ^TAnsiRec;
  TAnsiRec = Record
    CodePage    : TSystemCodePage;
    ElementSize : Word;
  {$ifdef CPU64}
  { align fields  }
    Dummy       : DWord;
  {$endif CPU64}
    Ref         : SizeInt;
    Len         : SizeInt;
  end;


begin
  if P=Nil then
    Result:=0
  else
    Result:=PAnsiRec(P-SizeOf(TAnsiRec))^.Ref;
end;

Procedure ByVar(Var S : string);

begin
  Writeln('By var, ref count : ',SRefCount(Pointer(S)));
end;

Procedure ByConst(Const S : string);

begin
  Writeln('Const, ref count : ',SRefCount(Pointer(S)));
end;

Procedure ByVal(S : string);

begin
  Writeln('Value, ref count : ',SRefCount(Pointer(S)));
end;

Function FunctionResult(Var S : String) : String;

begin
  Writeln('Function argument, ref count : ',SRefCount(Pointer(S)));
  Writeln('Function result, ref count : ',SRefCount(Pointer(Result)));
end;

Var
  S,T : String;

begin
  S:='Some string';
  Writeln('Constant       : ',SrefCount(Pointer(S)));
  UniqueString(S);
  Writeln('Unique         : ',SRefCount(Pointer(S)));
  T:=S;
  Writeln('After Assign   : ',SRefCount(Pointer(S)));
  ByVar(S);
  ByConst(S);
  ByVal(S);
  UniqueString(S);
  T:=FunctionResult(S);
  Writeln('After function : ',SRefCount(Pointer(S)));
end.
\end{verbatim}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Function overloading
\section{Function overloading}
\index{Functions!Overloaded}
Function overloading simply means that the same function is defined more
than once, but each time with a different formal parameter list.
The parameter lists must differ at least in one of its elements type.
When the compiler encounters a function call, it will look at the function
parameters to decide which one of the defined functions it should call.
This can be useful when the same function must be defined for different
types. 

For example, in a hypothetical RTL, the  \var{Random} procedure could be defined as:
\begin{verbatim}
Random(Max : Longint);
Random(Max : Double);
Random(Max,Ofsset : Longint);
\end{verbatim}
When the compiler encounters a call to the \var{Random} function, it will first search
which function it should use. It therefore checks the parameters in a
function call, and looks if there is a function definition which matches the
specified parameter list. If the compiler finds such a function, a call is
inserted to that function. If no such function is found, a compiler error is
generated.

Functions that have a \var{cdecl} modifier cannot be overloaded.
(Technically, because this modifier prevents the mangling of
the function name by the compiler).

Prior to version 1.9 of the compiler, the overloaded functions needed to be
in the same unit. Now the compiler will continue searching in other units if
it doesn't find a matching version of an overloaded function in one unit,
and if the \var{overload} keyword is present.

If the \var{overload} keyword is not present, then all overloaded versions
must reside in the same unit, and if it concerns methods part of a class,
they must be in the same class, i.\,e. the compiler will not look for
overloaded methods in parent classes if the \var{overload} keyword was not
specified.

\begin{remark}
Note that if you redefine (and overload) compiler internal functions, the
original compiler functions are no longer available. This is for instance
the case with \var{Inc()} and \var{Dec()}
\end{remark}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% forward declared functions
\section{Forward declared functions}
\index{Functions!Forward}\index{Forward} \keywordlink{forward}
A function can be declared without having it followed by its implementation,
by having it followed by the \var{forward} procedure. The effective
implementation of that function must follow later in the module.
The function can be used after a \var{forward} declaration as if it had been
implemented already.
The following is an example of a forward declaration.
\begin{verbatim}
Program testforward;
Procedure First (n : longint); forward;
Procedure Second;
begin
  WriteLn ('In second. Calling first...');
  First (1);
end;
Procedure First (n : longint);
begin
  WriteLn ('First received : ',n);
end;
begin
  Second;
end.
\end{verbatim}
A function can be forward declared only once.
Likewise, in units, it is not allowed to have a forward declared function
of a function that has been declared in the interface part. The interface
declaration counts as a \var{forward} declaration.
The following unit will give an error when compiled:
\begin{verbatim}
Unit testforward;
interface
Procedure First (n : longint);
Procedure Second;
implementation
Procedure First (n : longint); forward;
Procedure Second;
begin
  WriteLn ('In second. Calling first...');
  First (1);
end;
Procedure First (n : longint);
begin
  WriteLn ('First received : ',n);
end;
end.
\end{verbatim}
Reversely, functions declared in the interface section cannot be declared
forward in the implementation section. Logically, since they already have
been declared.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% External functions
\section{External functions}
\label{se:external}\index{External}\index{Functions!External}\keywordlink{external}
The \var{external} modifier can be used to declare a function that resides in
an external object file. It allows to use the function in some code, and at
linking time, the object file containing the implementation of the function
or procedure must be linked in.
\input{syntax/external.syn}
It replaces, in effect, the function or procedure code block.
As an example:
\begin{verbatim}
program CmodDemo;
{$Linklib c}
Const P : PChar = 'This is fun !';
Function strlen (P : PChar) : Longint; cdecl; external;
begin
  WriteLn ('Length of (',p,') : ',strlen(p))
end.
\end{verbatim}
\begin{remark}
The parameters in the declaration of the \var{external} function
should match exactly the ones in the declaration in the object file.
\end{remark}
If the \var{external} modifier is followed by a string constant:
\begin{verbatim}
external 'lname';
\end{verbatim}
Then this tells the compiler that the function resides in library
``lname''. The compiler will then automatically link this library to
the program.

The name that the function has in the library can also be specified:
\begin{verbatim}
external 'lname' name 'Fname';
\end{verbatim}
\index{name}This tells the compiler that the function resides in library ``lname'',
but with name ``Fname''. The compiler will then automatically link this
library to the program, and use the correct name for the function.
Under \windows and \ostwo, the following form can also be used:
\begin{verbatim}
external 'lname' Index Ind;
\end{verbatim}
\index{index}This tells the compiler that the function resides in library ``lname'',
but with index \var{Ind}. The compiler will then automatically
link this library to the program, and use the correct index for the
function.

Finally, the external directive can be used to specify the external name
of the function:
\begin{verbatim}
external name 'Fname';
{$L myfunc.o}
\end{verbatim}
\index{external}%
This tells the compiler that the function has the name ``Fname''. The
correct library or object file (in this case myfunc.o) must still be linked,
ensuring that the function ``Fname'' is indeed included in the linking stage.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Assembler functions
\section{Assembler functions}
\index{Assembler}\index{Functions!Assembler}\keywordlink{assembler}
Functions and procedures can be completely implemented in assembly
language. To indicate this, use the \var{assembler} keyword:
\input{syntax/asm.syn}
Contrary to Delphi, the assembler keyword must be present to indicate an
assembler function.
For more information about assembler functions, see the chapter on using
assembler in the \progref.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Modifiers
\section{Modifiers}
\index{Modifiers}\index{Functions!Modifiers}
A function or procedure declaration can contain modifiers. Here we list the
various possibilities:
\input{syntax/modifiers.syn}
\fpc doesn't support all \tp modifiers (although it parses them for
compatibility), but does support a number of additional modifiers.
They are used mainly for assembler and reference to C object files.

\subsection{alias}
\label{se:alias}
\index{Alias}\index{Modifiers!Alias}\keywordlink{alias}
The \var{alias} modifier allows the programmer to specify a different name for a
procedure or function. This is mostly useful for referring to this procedure
from assembly language constructs or from another object file. As an example,
consider the following program:
\begin{verbatim}
Program Aliases;

Procedure Printit;[public, alias:'DOIT'];
begin
  WriteLn ('In Printit (alias : "DOIT")');
end;


Procedure myprint; external name 'DOIT';

begin

asm
  call myprint
end;

end.
\end{verbatim}
\begin{remark} The specified alias is inserted straight into the assembly
code, thus it is case sensitive.
\end{remark}
The \var{alias} modifier does not make the symbol public to other modules,
unless the routine is also declared in the interface part of a unit, or
the \var{public} modifier is used to force it as public. Consider the
following:
\begin{verbatim}

unit testalias;

interface

procedure testroutine;

implementation

procedure testroutine;alias:'ARoutine';
begin
  WriteLn('Hello world');
end;

end.
\end{verbatim}
This will make the routine \var{testroutine} available publicly to
external object files under the label name \var{ARoutine}.

\begin{remark}
The \var{alias} directive is considered deprecated. Please use the
\var{public name} directive. See \sees{public}.
\end{remark}

\subsection{cdecl}
\label{se:cdecl}\index{cdecl}\index{Modifiers!cdecl}\keywordlink{cdecl}
The \var{cdecl} modifier can be used to declare a function that uses a C
type calling convention. This must be used when accessing functions residing in
an object file generated by standard C compilers, but must also be used for
Pascal functions that are to be used as callbacks for C libraries.

The \var{cdecl} modifier allows to use C function in the code.
For external C functions, the object file containing the \var{C}
implementation of the function or procedure must be linked in.
As an example:
\begin{verbatim}
program CmodDemo;
{$LINKLIB c}
Const P : PChar = 'This is fun !';
Function StrLen(P: PChar): Longint;cdecl; external name 'strlen';
begin
  WriteLn ('Length of (',p,') : ',StrLen(p));
end.
\end{verbatim}
When compiling this, and linking to the C-library, the \var{strlen} function
can be called throughout the program. The \var{external} directive tells
the compiler that the function resides in an external object file or library
with the ``strlen'' name (see \ref{se:external}).
\begin{remark}
The parameters in our declaration of the \var{C} function should
match exactly the ones in the declaration in \var{C}.
\end{remark}

For functions that are not external, but which are declared using
\var{cdecl}, no external linking is needed. These functions have some
restrictions, for instance the \var{array of const} construct can not be
used (due the way this uses the stack). On the other hand, the
\var{cdecl} modifier allows these functions to be used as callbacks for
routines written in C, as the latter expect the ``cdecl'' calling convention.


\subsection{cppdecl}
\label{se:cppdecl}\index{cppdecl}\index{Modifiers!cppdecl}\keywordlink{cppdecl}
The \var{cppdecl} modifier can be used to declare a function that uses a C++
type calling convention. This must be used when accessing functions residing in
an object file generated by standard C++ compilers, but must also be used for
Pascal functions that are to be used as callbacks for C++ libraries.

Note that linking to C++ support is experimental at best, so this should be used with
extreme care.

\subsection{export}\keywordlink{export}
\index{export}\index{Modifiers!export}
The \var{export} modifier is used to export names when creating a shared library
or an executable program. This means that the symbol will be publicly
available, and can be imported from other programs. For more information
on this modifier, consult the section on ``Making libraries''
in the \progref.

\subsection{hardfloat}\keywordlink{hardfloat}
\index{hardfloat}\index{Modifiers!hardfloat}
The \var{hardfloat} modifier is used to indicate that the compiler must
use a calling convention that passes certain floating point parameters in VFP registers.
(Used on ARM only)

\subsection{inline}\keywordlink{inline}
\index{inline}\index{Modifiers!inline}
\label{se:inline}
Procedures that are declared \var{inline} are copied to the places where they
are called. This has the effect that there is no actual procedure call,
the code of the procedure is just copied to where the procedure is needed,
this results in faster execution speed if the function or procedure is
used a lot. It is obvious that inlining large functions does not make sense.

By default, \var{inline} procedures are not allowed. Inline code must be enabled
using the command-line switch \var{-Si} or \var{\{\$inline on\}}
directive.

\begin{remark}
\begin{enumerate}
\item \var{inline} is only a hint for the compiler. This does {\em not}
automatically mean that all calls are inlined; sometimes the compiler
may decide that a function simply cannot be inlined, or that a particular call
to the function cannot be inlined. If so, the compiler will emit a warning.
\item In old versions of \fpc, inline code was {\em not} exported from a unit. This
meant that when calling an inline procedure from another unit, a normal procedure
call will be performed. Only inside units, \var{Inline} procedures are really inlined.
As of version 2.0.2, inline works across units.
\item Recursive inline functions are not allowed. i.\,e. an inline function
that calls itself is not allowed.
\end{enumerate}
\end{remark}

\subsection{interrupt}
\label{se:interrupt}\index{interrupt}\index{Modifiers!interrupt}\keywordlink{interrupt}
The \var{interrupt} keyword is used to declare a routine which will
be used as an interrupt handler. On entry to this routine, all the registers
will be saved and on exit, all registers will be restored
and an interrupt or trap return will be executed (instead of the normal return
from subroutine instruction).

On platforms where a return from interrupt does not exist, the normal exit
code of routines will be done instead. For more information on the generated
code, consult the \progref.

\subsection{iocheck}
\label{se:iocheck}\index{iocheck}\index{Modifiers!iocheck}\keywordlink{iocheck}
The \var{iocheck} keyword is used to declare a routine which causes
generation of I/O result checking code within a \var{\{\$IOCHECKS ON\}}
block whenever it is called.

The result is that if a call to this procedure is generated, the compiler will
insert I/O checking code if the call is within a \var{\{\$IOCHECKS ON\}} block.

This modifier is intended for RTL internal routines, not for use in
application code.

\subsection{local}
\label{se:local}\index{local}\index{Modifiers!local}\keywordlink{local}
The \var{local} modifier allows the compiler to optimize the function: a local
function cannot be in the interface section of a unit: it is always in the
implementation section of the unit. From this it follows that the function
cannot be exported from a library.

On Linux, the local directive results in some optimizations. On Windows, it
has no effect. It was introduced for Kylix compatibility.

\subsection{MS\_ABI\_Default}\keywordlink{MS\_ABI\_Default}
\index{MS\_ABI\_Default}\index{Modifiers!MS\_ABI\_Default}
The \var{MS\_ABI\_Default} modifier is used to indicate that the compiler must
use the Microsoft version of the x86-64 calling convention. This is the default
calling convention Win64, and is only supported on x86-64.


\subsection{MS\_ABI\_CDecl}\keywordlink{MS\_ABI\_CDecl}
\index{MS\_ABI\_CDecl}\index{Modifiers!MS\_ABI\_CDecl}
The \var{MS\_ABI\_CDecl} modifier is used to indicate that the compiler must
use the Microsoft version of the x86-64 calling convention, with the
exception that 'array of const' are interpreted as cdecl varargs parameters,
instead of the regular pascal array of const.




\subsection{MWPascal}\keywordlink{MWPascal}
\index{MWPascal}\index{Modifiers!MWPascal}
The \var{MWPascal} modifier is used to indicate that the compiler must
use the Metrowerks Pascal calling convention. This calling convention behaves the same as
cdecl, except that const record parameters are passed by reference
instead of by value. Supported on all platforms.



\subsection{noreturn}
\label{se:noreturn}\index{noreturn}\index{Modifiers!noreturn}\keywordlink{noreturn}
The \var{noreturn} modifier can be used to tell the compiler the procedure
does not return. This information can used by the compiler to avoid emitting
warnings about uninitialized variables or results not being set.

In the following example, the compiler will not emit a warning that the
result may not be set in function \var{f}:
\begin{verbatim}
procedure do_halt;noreturn;
begin
  halt(1);
end;

function f(i : integer) : integer ;

begin
  if (i<0)  then
    do_halt
  else
    result:=i;
end;
\end{verbatim}

\subsection{nostackframe}
\label{se:nostackframe}\index{nostackframe}\index{Modifiers!nostackframe}\keywordlink{nostackframe}
The \var{nostackframe} modifier can be used to tell the compiler it should
not generate a stack frame for this procedure or function. By default, a
stack frame is always generated for each procedure or function, but the compiler
will omit it if it can.

For asm routines (pure assembler) this directive can be used to omit generating a
stack frame.

One should be extremely careful when using this modifier: most procedures or
functions need a stack frame. Particularly for debugging they are needed.

\subsection{overload}
\label{se:overload}\index{overload}\index{Modifiers!overload}\keywordlink{overload}
The \var{overload} modifier tells the compiler that this function is
overloaded. It is mainly for \delphi compatibility, as in \fpc, all
functions and procedures can be overloaded without this modifier.

There is only one case where the \var{overload} modifier is mandatory:
if a function must be overloaded that resides in another unit. Both
functions must be declared with the \var{overload} modifier: the
\var{overload} modifier tells the compiler that it should continue
looking for overloaded versions in other units.

The following example illustrates this. Take the first unit:
\begin{verbatim}
unit ua;

interface

procedure DoIt(A : String); overload;

implementation

procedure DoIt(A : String);

begin
  Writeln('ua.DoIt received ',A)
end;

end.
\end{verbatim}
And a second unit, which contains an overloaded version:
\begin{verbatim}
unit ub;

interface

procedure DoIt(A : Integer); overload;

implementation

procedure DoIt(A : integer);

begin
  Writeln('ub.DoIt received ',A)
end;

end.
\end{verbatim}
And the following program, which uses both units:
\begin{verbatim}
program uab;

uses ua,ub;

begin
  DoIt('Some string');
end.
\end{verbatim}
When the compiler starts looking for the declaration of \var{DoIt}, it will
find one in the \file{ub} unit. Without the \var{overload} directive, the
compiler would give an argument mismatch error:
\begin{verbatim}
home: >fpc uab.pp
uab.pp(6,21) Error: Incompatible type for arg no. 1:
Got "Constant String", expected "SmallInt"
\end{verbatim}
With the \var{overload} directive in place at both locations, the compiler
knows it must continue searching for an overloaded version with matching
parameter list. Note that {\em both} declarations must have the
\var{overload} modifier specified; it is not enough to have the modifier in
unit \file{ub}. This is to prevent unwanted overloading: the programmer who
implemented the \var{ua} unit must mark the procedure as fit for overloading.

%
%
\subsection{pascal}
\label{se:pascal}\index{pascal}\index{Modifiers!pascal}\keywordlink{pascal}
The \var{pascal} modifier can be used to declare a function that uses the
classic Pascal type calling convention (passing parameters from left to right).
For more information on the Pascal calling convention, consult the \progref.

\subsection{public}
\label{se:public}\index{Modifiers!public}\index{public}\keywordlink{public}
The \var{Public} keyword is used to declare a function globally in a unit.
This is useful if the function should not be accessible from the unit
file (i.\,e. another unit/program using the unit doesn't see the function),
but must be accessible from the object file. As an example:
\begin{verbatim}
Unit someunit;
interface
Function First : Real;
Implementation
Function First : Real;
begin
  First := 0;
end;
Function Second : Real; [Public];
begin
  Second := 1;
end;
end.
\end{verbatim}
If another program or unit uses this unit, it will not be able to use the
function \var{Second}, since it isn't declared in the interface part.
However, it will be possible to access the function \var{Second} at the
assembly-language level, by using its mangled name (see the \progref).

The \var{public} modifier can also be followed by a \var{name} directive to
specify the assembler name, as follows:
\begin{verbatim}
Unit someunit;
interface
Function First : Real;
Implementation
Function First : Real;
begin
  First := 0;
end;
Function Second : Real; Public name 'second';
begin
  Second := 1;
end;
end.
\end{verbatim}
The assembler symbol as specified by the ``public name'' directive will
be ``second'', in all lowercase letters.

\subsection{register}
\label{se:register}\index{register}\index{Modifiers!register}\keywordlink{register}
The \var{register} keyword is used for compatibility with Delphi.
In version 1.0.x of the compiler, this directive has no effect on the
generated code. As of the 1.9.X versions, this directive is supported.
For the Intel i386 platform, the first three arguments are passed in registers EAX, EDX and ECX.
For other platforms, this keyword has no effect, the default platform ABI calling
convention is used. In general, the use of this directive is not
recommended, unless you know what you're doing.

\subsection{safecall}
\index{safecall}\index{Modifiers!safecall}\keywordlink{savecall}
The \var{safecall} modifier ressembles closely the \var{stdcall} modifier.
It sends parameters from right to left on the stack. Additionally, the
called procedure saves and restores all registers.

More information about this modifier can be found in the \progref, in the
section on the calling mechanism and the chapter on linking.

\subsection{saveregisters}
\index{saveregisters}\index{Modifiers!saveregisters}\keywordlink{saveregisters}
The \var{saveregisters} modifier tells the compiler that all CPU registers should be
saved prior to calling this routine. Which CPU registers are saved, depends
entirely on the CPU.

\subsection{softfloat}
\index{softfloat}\index{Modifiers!softfloat}\keywordlink{softfloat}
The \var{softfloat}  modifier makes sense only on the ARM architecture.
Tells the compiler to se the (platform-specific) calling convention for passing floating
point values when software-emulated floating point support is active.
(Not supported on all platforms: currently only ARM).


\subsection{stdcall}
\index{stdcall}\index{Modifiers!stdcall}\keywordlink{stdcall}
The \var{stdcall} modifier pushes the parameters from right to left on the stack,
it also aligns all the parameters to a default alignment.

More information about this modifier can be found in the \progref, in the
section on the calling mechanism and the chapter on linking.

\subsection{SYSV\_ABI\_Default}\keywordlink{SYSV\_ABI\_Default}
\index{SYSV\_ABI\_Default}\index{Modifiers!SYSV\_ABI\_Default}
The \var{SYS\_ABI\_Default} modifier is used to indicate that the compiler must
use the x86-64-specific calling convention that conforms to the System V AMD64
ABI
This is the default calling convention all x86-64 platforms except Win64, 
and is only supported on x86-64.


\subsection{SYSV\_ABI\_CDecl}\keywordlink{SYSV\_ABI\_CDecl}
\index{SYSV\_ABI\_CDecl}\index{Modifiers!SYSV\_ABI\_CDecl}
The \var{SYSV\_ABI\_CDecl} modifier is used to indicate that the compiler must
use the x86-64-specific calling convention that conforms to the System V AMD64
ABI, with the exception that 'array of const' are interpreted as cdecl varargs parameters,
instead of the regular pascal array of const.

\subsection{VectorCall}\keywordlink{VectorCall}
\index{VectorCall}\index{Modifiers!VectorCall}
The \var{VectorCall} modifier is used to indicate that the compiler must
use vector call calling convention. This is a variant of the
\var{MS\_ABI\_Default} calling convention that passes certain
floating point parameters in vector registers. only supported on
on x86-64 CPUs.

\subsection{varargs}
\index{varargs}\index{Modifiers!varargs}\keywordlink{varargs}
This modifier can only be used together with the \var{cdecl} modifier, for
external C procedures. It indicates that the procedure accepts a variable
number of arguments after the last declared variable. These arguments are
passed on without any type checking. It is equivalent to using the
\var{array of const} construction for \var{cdecl} procedures, without having
to declare the \var{array of const}. The square brackets around the variable
arguments do not need to be used when this form of declaration is used.

The following declarations are two ways of referring to the same function
in the C library:
\begin{verbatim}
Function PrintF1(fmt : pchar); cdecl; varargs;
                               external 'c' name 'printf';
Function PrintF2(fmt : pchar; Args : Array of const); cdecl;
                               external 'c' name 'printf';
\end{verbatim}
But they must be called differently:
\begin{verbatim}
PrintF1('%d %d\n',1,1);
PrintF2('%d %d\n',[1,1]);
\end{verbatim}

\subsection{winapi}
\index{winapi}\index{Modifiers!winapi}\keywordlink{winapi}
This modifier allows you to specify the native calling conventions for the
current platform: the compiler will then select the correct calling convention
depending on the OS architecture: stdcall on windows-i386 and cdecl on all other
platforms.

The following example demonstrates this:
\begin{verbatim}
function libusb_init(var ctx:plibusb_context):integer;winapi;external libusb1;
\end{verbatim}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Unsupported Turbo Pascal modifiers
\section{Unsupported Turbo Pascal modifiers}
\index{Modifiers}\keywordlink{far}\keywordlink{near}
The modifiers that exist in \tp, but aren't supported by \fpc, are
listed in \seet{Modifs}.
\begin{FPCltable}{lr}{Unsupported modifiers}{Modifs}
Modifier & Why not supported ? \\ \hline
Near & \fpc is a 32-bit compiler.\\
Far & \fpc is a 32-bit compiler. \\
\end{FPCltable}
The compiler will give a warning when it encounters these modifiers, but
will otherwise completely ignore them.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Operator overloading
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Operator overloading}
\label{ch:operatoroverloading}
\index{overloading!operators}
\section{Introduction}
\fpc supports operator overloading. This means that it is possible to
define the action of some operators on self-defined types, and thus allow
the use of these types in mathematical expressions.

In addition, operator overloading can be used for some special actions
that are strictly speaking not operators in the mathematical sense of the word.
This is true for the procedures \var{Inc} and \var{Dec} (which are usable as
a procedure only) and for implicit and explicit assignment (\var{:=} and typecasting).
The enumerator operator (to define an enumerable series for a type) is also
part of this class of operators.

Defining the action of an operator is much like the definition of a
function or procedure, only there are some restrictions on the possible
definitions, as will be shown in the subsequent.

Operator overloading is, in essence, a powerful notational tool;
but it is also not more than that, since the same results can be
obtained with regular function calls. When using operator overloading,
it is important to keep in mind that some implicit rules may produce
some unexpected results. This will be indicated.

There are 2 ways to declare operator overloads. The first way is the
original way as implemented in Free Pascal, and is the most powerful.
It is discussed in this chapter. There is also a second way, which can only
be implemented for Advanced (or extended) records, it is discussed in the
chapter on extended records.

\section{Operator declarations}
\index{operators}
To define the action of an operator is much like defining a function:
\input{syntax/operator.syn}
The parameter list for a comparison operator or an arithmetic operator
must always contain two parameters, with the exception of the unary minus or
plus, where only one parameter is needed. The result type of the comparison
operator(s) must be \var{Boolean}.



User-defined simple types can be used for operators, as well as records and arrays.
There are some limitations on operator overloading:
\begin{itemize}
\item This way of declaring operators is only supported in \var{ObjFPC} and
\var{FPC} modes.
\item It is not possible to define operators on classes. 
\item The + and - operators cannot be defined on enumerated types. 
\item When the \var{ArrayOperators} modeswitch is in effect:
\begin{verbatim}
{$modeSwitch ArrayOperators}
\end{verbatim} 
then the + operator cannot be overloaded on dynamic arrays, because it is handled internally
by the compiler.
\end{itemize}

\begin{remark}
When compiling in \var{Objfpc} mode, the result identifier may be dropped. 
The result can then be accessed through the standard \var{Result} symbol.

If the result identifier is dropped and the compiler is not in one
of these modes, a syntax error will occur.
\end{remark}


The statement block contains the necessary statements to determine the
result of the operation. It can contain arbitrary large pieces of code;
it is executed whenever the operation is encountered in some expression.
The result of the statement block must always be defined; error conditions
are not checked by the compiler, and the code must take care of all possible
cases, throwing a run-time error if some error condition is encountered.

In the following, the three types of operator definitions will be examined.
As an example, throughout this chapter the following type will be used to
define overloaded operators on:
\begin{verbatim}
type
  complex = record
    re : real;
    im : real;
  end;
\end{verbatim}
This type will be used in all examples.

The sources of the Run-Time Library contain two units that heavily use
operator overloading:
\begin{description}
\item[ucomplex] This unit contains a complete calculus for complex numbers.
\item[matrix] This unit contains a complete calculus for matrices.
\end{description}

\section{Assignment operators}
\index{Operators!Assignment}\keywordlink{operator}
The assignment operator defines the action of a assignment of one type of
variable to another. The result type must match the type of the variable
at the left of the assignment statement, the single parameter to the
assignment operator must have the same type as the expression at the
right of the assignment operator.

This system can be used to declare a new type, and define an assignment for
that type. For instance, to be able to assign a newly defined type ``Complex''
\begin{verbatim}
Var
  C,Z : Complex; // New type complex

begin
  Z:=C;  // assignments between complex types.
end;
\end{verbatim}
The following assignment operator would have to be defined:
\begin{verbatim}
Operator := (C : Complex) z : complex;
\end{verbatim}

To be able to assign a real type to a complex type as follows:
\begin{verbatim}
var
  R : real;
  C : complex;

begin
  C:=R;
end;
\end{verbatim}
the following assignment operator must be defined:
\begin{verbatim}
Operator := (r : real) z : complex;
\end{verbatim}
As can be seen from this statement, it defines the action of the operator
\var{:=} with at the right a real expression, and at the left a complex
expression.

An example implementation of this could be as follows:
\begin{verbatim}
operator := (r : real) z : complex;

begin
  z.re:=r;
  z.im:=0.0;
end;
\end{verbatim}
As can be seen in the example, the result identifier (\var{z} in this case)
is used to store the result of the assignment. When compiling in \var{Delphi} mode
or \var{ObjFPC} mode, the use of the special identifier \var{Result} is also
allowed, and can be substituted for the \var{z}, so the above would be
equivalent to
\begin{verbatim}
operator := (r : real) z : complex;

begin
  Result.re:=r;
  Result.im:=0.0;
end;
\end{verbatim}

The assignment operator is also used to convert types from one type to
another. The compiler will consider all overloaded assignment operators
till it finds one that matches the types of the left hand and right hand
expressions. If no such operator is found, a ``type mismatch'' error
is given.

\begin{remark}
The assignment operator is not commutative; the compiler will never reverse
the role of the two arguments. In other words, given the above definition of
the assignment operator, the following is {\em not} possible:
\begin{verbatim}
var
  R : real;
  C : complex;

begin
  R:=C;
end;
\end{verbatim}
If the reverse assignment should be possible then the assignment operator
must be defined for that as well.
(This is not so for reals and complex numbers.)
\end{remark}

\begin{remark}
The assignment operator is also used in implicit type conversions. This can
have unwanted effects. Consider the following definitions:
\begin{verbatim}
operator := (r : real) z : complex;
function exp(c : complex) : complex;
\end{verbatim}
Then the following assignment will give a type mismatch:
\begin{verbatim}
Var
  r1,r2 : real;

begin
  r1:=exp(r2);
end;
\end{verbatim}
The mismatch occurs because the compiler will encounter the definition of the \var{exp} function
with the complex argument. It implicitly converts \var{r2} to a complex, so it can
use the above \var{exp} function. The result of this function is a complex,
which cannot be assigned to \var{r1}, so the compiler will give a ``type mismatch''
error. The compiler will not look further for another \var{exp} which has
the correct arguments.

It is possible to avoid this particular problem by specifying
\begin{verbatim}
  r1:=system.exp(r2);
\end{verbatim}
\end{remark}

When doing an explicit typecast, the compiler will attempt an implicit conversion
if an assignment operator is present. That means that
\begin{verbatim}
Var
  R1 : T1;
  R2 : T2;

begin
  R2:=T2(R1);
\end{verbatim}
Will be handled by an operator
\begin{verbatim}
Operator := (aRight: T1) Res: T2;
\end{verbatim}
However, an \var{Explicit} operator can be defined, and then it will be
used instead when the compiler encounters a typecast.

The reverse is not true: In a regular assignment, the compiler will not
consider explicit assignment operators.

Given the following definitions:
\begin{verbatim}
uses
  sysutils;

type
  TTest1 = record
    f: LongInt;
  end;
  TTest2 = record
    f: String;
  end;
  TTest3 = record
    f: Boolean;
  end;
\end{verbatim}
It is possible to create assignment operators:
\begin{verbatim}
operator := (aRight: TTest1) Res: TTest2;
begin
  Writeln('Implicit TTest1 => TTest2');
  Res.f := IntToStr(aRight.f);
end;

operator := (aRight: TTest1) Res: TTest3;
begin
  Writeln('Implicit TTest1 => TTest3');
  Res.f := aRight.f <> 0;
end;
\end{verbatim}
But one can also define typecasting operators:
\begin{verbatim}
operator Explicit(aRight: TTest2) Res: TTest1;
begin
  Writeln('Explicit TTest2 => TTest1');
  Res.f := StrToIntDef(aRight.f, 0);
end;

operator Explicit(aRight: TTest1) Res: TTest3;
begin
  Writeln('Explicit TTest1 => TTest3');
  Res.f := aRight.f <> 0;
end;
\end{verbatim}
Thus, the following code
\begin{verbatim}
var
  t1: TTest1;
  t2: TTest2;
  t3: TTest3;
begin
  t1.f := 42;
  // Implicit
  t2 := t1;
  // theoretically explicit, but implicit op will be used,
  // because no explicit operator is defined
  t2 := TTest2(t1);
  // the following would not compile,
  // no assignment operator defined (explicit one won't be used here)
  //t1 := t2;
  // Explicit
  t1 := TTest1(t2);
  // first explicit (TTest2 => TTest1) then implicit (TTest1 => TTest3)
  t3 := TTest1(t2);
  // Implicit
  t3 := t1;
  // explicit
  t3 := TTest3(t1);
end.
\end{verbatim}
will produce the following output:
\begin{verbatim}
Implicit TTest1 => TTest2
Implicit TTest1 => TTest2
Explicit TTest2 => TTest1
Explicit TTest2 => TTest1
Implicit TTest1 => TTest3
Implicit TTest1 => TTest3
Explicit TTest1 => TTest3
\end{verbatim}

\section{Arithmetic operators}
\index{Operators!Arithmetic}\index{Operators!Binary}
Arithmetic operators define the action of a binary operator. Possible
operations are:
\begin{description}
\item[multiplication] To multiply two types, the \var{*} multiplication
operator must be overloaded.
\item[division] To divide two types, the \var{/} division
operator must be overloaded.
\item[addition] To add two types, the \var{+} addition
operator must be overloaded. Note that the \var{+} can not be used for
dynamic arrays, as this is an internal compiler operation for array
concatenation (see also the modeswitch ARRAYOPERATORS).
\item[subtraction] To subtract two types, the \var{-} subtraction
operator must be overloaded.
\item[exponentiation] To exponentiate two types, the \var{**} exponentiation
operator must be overloaded.
\item[Unary minus] is used to take the negative of the argument following
it.
\item[Symmetric Difference] To take the symmetric difference of 2
structures, the \var{><} operator must be overloaded.
\end{description}

The definition of an arithmetic operator takes two parameters, except for
unary minus, which needs only one parameter. The first parameter must be of
the type that occurs at the left of the operator, the second parameter must
be of the type that is at the right of the arithmetic operator. The result
type must match the type that results after the arithmetic operation.

To compile an expression as
\begin{verbatim}
var
  R : real;
  C,Z : complex;

begin
  C:=R*Z;
end;
\end{verbatim}
One needs a definition of the multiplication operator as:
\begin{verbatim}
Operator * (r : real; z1 : complex) z : complex;

begin
  z.re := z1.re * r;
  z.im := z1.im * r;
end;
\end{verbatim}
As can be seen, the first operator is a real, and the second is
a complex. The result type is complex.

Multiplication and addition of reals and complexes are commutative
operations. The compiler, however, has no notion of this fact so even
if a multiplication between a real and a complex is defined, the
compiler will not use that definition when it encounters a complex
and a real (in that order). It is necessary to define both operations.

So, given the above definition of the multiplication,
the compiler will not accept the following statement:
\begin{verbatim}
var
  R : real;
  C,Z : complex;

begin
  C:=Z*R;
end;
\end{verbatim}
Since the types of \var{Z} and \var{R} don't match the types in the
operator definition.

The reason for this behavior is that it is possible that a multiplication
is not always commutative. E.\,g. the multiplication of a \var{(n,m)} with a
\var{(m,n)} matrix will result in a \var{(n,n)} matrix, while the
multiplication of a \var{(m,n)} with a \var{(n,m)} matrix is a \var{(m,m)}
matrix, which needn't be the same in all cases.

\section{Comparison operator}
\index{Operators!Comparison}
The comparison operator can be overloaded to compare two different types
or to compare two equal types that are not basic types. If the operands
are not simple types, the result type of a comparison operator need not
always be a boolean, but then they cannot be used in an \var{if}, \var{repeat} or \var{while} statement.

The comparison operators that can be overloaded are:
\begin{description}
\item[equal to] (=) To determine if two variables are equal.
\item[unequal to] ($<>$) To determine if two variables are different.
\item[less than] ($<$) To determine if one variable is less than another.
\item[greater than] ($>$) To determine if one variable is greater than another.
\item[greater than or equal to] ($>=$) To determine if one variable is greater than
or equal to another.
\item[less than or equal to] ($<=$) To determine if one variable is greater
than or equal to another.
\end{description}

If there is no separate operator for {\em unequal to} ($<>$), then, to evaluate a
statement that contains the {\em unequal to} operator, the compiler uses the
{\em equal to} operator (=), and negates the result. The opposite is not
true: if no ``equal to'' but an ``unequal to'' operator exists, the compiler
will not use it to evaluate an expression containing the equal (=) operator.

As an example, the following operator allows to compare two complex
numbers:
\begin{verbatim}
operator = (z1, z2 : complex) b : boolean;
\end{verbatim}
the above definition allows comparisons of the following form:
\begin{verbatim}
Var
  C1,C2 : Complex;

begin
  If C1=C2 then
    Writeln('C1 and C2 are equal');
end;
\end{verbatim}

The comparison operator definition needs two parameters, with the types that
the operator is meant to compare. Here also, the compiler doesn't apply
commutativity: if the two types are different, then it is necessary to
define two comparison operators.

In the case of complex numbers, it is, for instance necessary to define
2 comparisons: one with the complex type first, and one with the real type
first.

Given the definitions
\begin{verbatim}
operator = (z1 : complex;r : real) b : boolean;
operator = (r : real; z1 : complex) b : boolean;
\end{verbatim}
the following two comparisons are possible:
\begin{verbatim}
Var
  R,S : Real;
  C : Complex;

begin
  If (C=R) or (S=C) then
   Writeln ('Ok');
end;
\end{verbatim}
Note that the order of the real and complex type in the two comparisons
is reversed.

The following example shows that the result type does not need to be a boolean:
\begin{verbatim}
Type
  TMyRec = record a,b : integer; end;

operator = (x,y : TMyRec) r : string;

begin
  if (x.a=y.a) and (x.b=y.b) then
    R:='equal'
  else
    R:='differ';
end;

var
  x,y : TMyRec;

begin
  x.a:=1;
  y.a:=1;
  Writeln(x=y);
  x.a:=2;
  y.a:=3;
  Writeln(x=y);
end.
\end{verbatim}
When executed, this example will print
\begin{verbatim}
equal
differ
\end{verbatim}
obviously, a statement as
\begin{verbatim}
if (x=y) then
  writeln('Equal');
\end{verbatim}
Will not compile, since the if statement needs a boolean check:
\begin{verbatim}
Error: Incompatible types: got "ShortString" expected "Boolean"
\end{verbatim}

% In Operator
\section{In operator}
As of version 2.6 of Free pascal, the \var{In} operator can be overloaded as well.
The first argument of the in operator must be the operand on the left of the
\var{in} keyword.
The following overloads the in operator for records:
\begin{verbatim}

{$mode objfpc}{$H+}

type
  TMyRec = record A: Integer end;

operator in (const A: Integer; const B: TMyRec): boolean;
begin
  Result := A = B.A;
end;

var
  R: TMyRec;
begin
  R.A := 10;
  Writeln(1 in R); // false
  Writeln(10 in R); // true
end.
\end{verbatim}
The \var{in} operator can also be overloaded for other types than ordinal
types, as in the following example:
\begin{verbatim}
{$mode objfpc}{$H+}

type
  TMyRec = record A: Integer end;

operator in (const A: TMyRec; const B: TMyRec): boolean;
begin
  Result := A.A = B.A;
end;

var
  S,R: TMyRec;
begin
  R.A := 10;
  S.A:=1;
  Writeln(S in R); // false
  Writeln(R in R); // true
end.
\end{verbatim}

\section{Logical operators}
Logical operators \var{and}, \var{or}, \var{xor} and \var{not} can be overloaded.
These operators are normally used on simple types in two different ways:
\begin{enumerate}
\item As boolean operators, in which case the result is a boolean (except for \var{not})
\item As bitwise operators, in which case the result is an ordinal type.
\end{enumerate}

When overloading these operators, the result type is not restricted. This means you can define the operators as boolean logic operators:
\begin{verbatim}
Type
  Rec = record
    a,b : Boolean;
  end;

Operator and (r1,r2 : Rec) z : boolean;

begin
  z:=(R1.a and R2.a) or (R1.b and r2.b);
end;

Operator or (r1,r2 : Rec) z : Boolean;

begin
  z:=(R1.a or R2.a) and (R1.b or r2.b)
end;

Operator xor (r1,r2 : Rec) z : Boolean;

begin
  z:=(R1.a xor R2.a) and (R1.b xor r2.b)
end;

Operator not (r1 : Rec) z : rec;

begin
  z.A:=not R1.a;
  z.B:=not R1.b;
end;


var
r1,r2 : Rec;

begin
  Writeln(r1 and r2);
  Writeln(r1 or r2);
  Writeln(r1 xor r2);
  Writeln((not r1).a);
end.
\end{verbatim}

But it is also possible to have different return types:

\begin{verbatim}
Operator and (r1,r2 : Rec) z : string;

begin
  Str(Ord((R1.a and R2.a) or (R1.b and r2.b)),Z);
end;
\end{verbatim}

The compiler will always check the return type to determine the final type of an expression,
and assignments will be checked for type safety.

\section{Inc/Dec operators}
The \var{Inc} and \var{Dec} procedures are~-- for optimization purposes~-- compiler intrinsics. They can be
overridden in the usual manner by declaring a procedure:

\begin{verbatim}
procedure Inc(var s : String);

begin
  Inc(S,'.');
end;

procedure Inc(var s : String; T : String);

begin
 S:=S+T;
end;
\end{verbatim}

But because they are compiler intrinsics, they can also be implemented as
operators for custom types:
\begin{verbatim}
operator Inc (s,T : String) : z : string;

begin
  Z:=S+T;
end;
\end{verbatim}

\section{The enumerator operator}
The enumerator operator can be used to define an enumerator for any type.
It must return a class, object, or extended record that has the same signature as the IEnumerator interface.
Note that this operator is not recognized by the compiler under the Delphi syntax mode.

The following code will define an enumerator for the Integer type:
\begin{verbatim}
Type
  TEvenEnumerator = Class
    FCurrent : Integer;
    FMax : Integer;
    Function MoveNext : Boolean;
    Property Current : Integer Read FCurrent;
  end;

Function TEvenEnumerator.MoveNext : Boolean;

begin
  FCurrent:=FCurrent+2;
  Result:=FCurrent<=FMax;
end;

operator enumerator(i : integer) : TEvenEnumerator;

begin
  Result:=TEvenEnumerator.Create;
  Result.FMax:=i;
end;

var
  I : Integer;
  m : Integer = 4;

begin
  For I in M do
    Writeln(i);
end.
\end{verbatim}

The loop will print all nonzero even numbers smaller or equal to the enumerable. (2 and 4 in the case of the example).

More about enumerators and the enumerator operator can be found in the
\sees{forin}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Programs, Units, Blocks
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Programs, units, blocks}
A Pascal program can consist of modules called \var{units}. A unit can be used
to group pieces of code together, or to give someone code without giving
the sources.
Both programs and units consist of code blocks, which are mixtures of
statements, procedures, and variable or type declarations.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Programs
\section{Programs}
\index{program}\index{uses}\keywordlink{program}\keywordlink{uses}
A Pascal program consists of the program header, followed possibly by a
``uses'' clause, and a block.
\input{syntax/program.syn}
The program header is provided for backwards compatibility, and is ignored
by the compiler.

The uses clause serves to identify all units that are needed by the program.
All identifiers which are declared in the interface section of the units
in the uses clause are added to the known identifiers of the program.
The system unit doesn't have to be in this list, since it is always loaded
by the compiler.

The order in which the units appear is significant, it determines in
which order they are initialized. Units are initialized in the same order
as they appear in the uses clause. Identifiers are searched in the opposite
order, i.\,e. when the compiler searches for an identifier, then it looks
first in the last unit in the uses clause, then the last but one, and so on.
This is important in case two units declare different types with the same
identifier.

The compiler will look for compiled versions or source versions of all
units in the uses clause in the unit search path. If the unit filename was
explicitly mentioned using the \var{in} keyword, the source is taken from
the filename specified:
\begin{verbatim}
program programb;

uses unita in '..\unita.pp';
\end{verbatim}
\file{unita} is searched in the parent directory of the current working
directory of the compiler. You can add a \var{\{\$UNITPATH ..\}} directive
to make sure that the unit will be found no matter where the compiler's
current working directory is.


When the compiler looks for unit files, it adds the extension \file{.ppu}
to the name of the unit. On \linux and in operating systems where filenames
are case sensitive  when looking for a unit, the following mechanism is
used:
\begin{enumerate}
\item The unit is first looked for in the original case.
\item The unit is looked for in all-lowercase letters.
\item The unit is looked for in all-uppercase letters.
\end{enumerate}
Additionally, If a unit name is longer than 8 characters, the compiler
will first look for a unit name with this length, and then it will
truncate the name to 8 characters and look for it again.
For compatibility reasons, this is also true on platforms that
support long file names.

Note that the above search is performed in each directory in the search
path.

The program block contains the statements that will be executed when the
program is started. Note that these statements need not necessarily be the
first statements that are executed: the initialization code of the units
may also contain statements that are executed prior to the program code.

The structure of a program block is discussed below.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Units
\section{Units}
\index{unit}\keywordlink{unit}
A unit contains a set of declarations, procedures and functions that can be
used by a program or another unit.
The syntax for a unit is as follows:
\input{syntax/unit.syn}
As can be seen from the syntax diagram, a unit always consists of a
interface and an implementation part. Optionally, there is an initialization
block and a finalization block, containing code that will be executed when
the program is started, and when the program stops, respectively.

\keywordlink{interface}\keywordlink{implementation}
Both the interface part or implementation part can be empty, but the
keywords \var{Interface} and \var{implementation} must be specified.
The following is a completely valid unit;
\begin{verbatim}
unit a;

interface

implementation

end.
\end{verbatim}

The interface part declares all identifiers that must be exported from the
unit. This can be constant, type or variable identifiers, and also procedure
or function identifier declarations.  The interface part cannot contain code
that is executed: only declarations are allowed. The following is a valid
interface part:
\begin{verbatim}
unit a;

interface

uses b;

Function MyFunction : SomeBType;

Implementation
\end{verbatim}
The type \var{SomeBType} is defined in unit \var{b}.

All functions and methods that are declared in the interface part must
be implemented in the implementation part of the unit, except for
declarations of external functions or procedures. If a declared method
or function is not implemented in the implementation part, the compiler
will give an error, for example the following:
\begin{verbatim}
unit unita;

interface

Function MyFunction : Integer;

implementation

end.
\end{verbatim}
Will result in the following error:
\begin{verbatim}
unita.pp(5,10) Error: Forward declaration not solved "MyFunction:SmallInt;"
\end{verbatim}

The implementation part is primarily intended for the implementation of the
functions and procedures declared in the interface part. However, it can
also contain declarations of its own: the declarations inside the
implementation part are {\em not} accessible outside the unit.

The initialization and finalization part of a unit are optional.

The initialization block is used to initialize certain variables or
execute code that is necessary for the correct functioning of the unit.
The initialization parts of the units
are executed in the order that the compiler loaded the units when compiling
a program. They are executed before the first statement of the program is
executed.

The finalization part of the units are executed in the reverse order of the
initialization execution. They are used for instance to clean up any resources
allocated in the initialization part  of the unit, or during the lifetime of
the program. The finalization part is always executed in the case of a
normal program termination: whether it is because the final \var{end} is
reached in the program code or because a \var{Halt} instruction was executed
somewhere.

In case the program stops during the execution of the initialization blocks
of one of the units, only the units that were already initialized will be
finalized.
\keywordlink{initialization}\keywordlink{finalization}
Note that in difference with Delphi, in Free Pascal a \var{finalization} block can be
present without an \var{Initialization} block. That means the following will
compile in Free Pascal, but not in Delphi.
\begin{verbatim}
Finalization
  CleanupUnit;
end.
\end{verbatim}
An initialization section by itself (i.\,e. without finalization) may simply be
replaced by a statement block. That is, the following:
\begin{verbatim}
Initialization
  InitializeUnit;
end.
\end{verbatim}
is completely equivalent to
\begin{verbatim}
Begin
  InitializeUnit;
end.
\end{verbatim}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Units
\section{Namespaces: Dotted Units}
As can be seen in the syntax diagram for a unit, a unit name can contain dots.
This means that the units can be organized in namespaces.

So, the following is a correct unit declaration:
\begin{verbatim}
unit a.b;

interface

Function C : integer;

implementation

Function C : integer;

begin
  Result:=1;
end;

end.
\end{verbatim}
The unit can be used as follows:
\begin{verbatim}
program d;

uses a.b;

begin
  Writeln(c);
end.
\end{verbatim}
When resolving symbols, unit scopes always take precedence over symbols inside units.

Given the following units:
\begin{verbatim}
unit myunit;

interface

var
  test: record
    a: longint;
  end;

implementation

initialization
  test.a:=2;
end.
\end{verbatim}
and
\begin{verbatim}
unit myunit.test;

interface

var
  a: longint;

implementation

initialization
  a:=1;
end.
\end{verbatim}
The following program will resolve \var{myunit.test.a} to the variable \var{a} in unit \var{myunit.test}:
\begin{verbatim}
uses
   myunit, myunit.test;

begin
  Writeln('myunit.test.a : ',myunit.test.a);
end.
\end{verbatim}
So it will print:
\begin{verbatim}
myunit.test.a : 1
\end{verbatim}
Reversing the order of the units will not change this:
\begin{verbatim}
uses
   myunit.test, myunit;

begin
  Writeln('myunit.test.a : ',myunit.test.a);
end.
\end{verbatim}
will also print
\begin{verbatim}
myunit.test.a : 1
\end{verbatim}
Similarly, the following program will resolve \var{myunit.test.a} to the variable \var{a} in unit \var{myunit.test}:
\begin{verbatim}
uses
   myunit.test, myunit;

begin
  Writeln('a : ',a);
end.
\end{verbatim}
it will print:
\begin{verbatim}
a : 1
\end{verbatim}
Similarly, the following program will resolve \var{test.a} to the variable \var{test.a} in unit \var{myunit}:
\begin{verbatim}
uses
   myunit.test, myunit;

begin
  Writeln('test.a : ',test.a);
end.
\end{verbatim}
will print
\begin{verbatim}
test.a : 2
\end{verbatim}

\section{Unit dependencies}
When a program uses a unit (say \file{unitA}) and this units uses a second
unit, say \file{unitB}, then the program depends indirectly also on
\var{unitB}. This means that the compiler must have access to \file{unitB} when
trying to compile the program. If the unit is not present at compile time,
an error occurs.

Note that the identifiers from a unit on which a program depends indirectly,
are not accessible to the program. To have access to the identifiers of a
unit, the unit must be in the uses clause of the program or unit where the
identifiers are needed.

Units can be mutually dependent, that is, they can reference each other in
their uses clauses. This is allowed, on the condition that at least one of
the references is in the implementation section of the unit. This also holds
for indirect mutually dependent units.

If it is possible to start from one interface uses clause of a unit, and to return
there via uses clauses of interfaces only, then there is circular unit
dependence, and the compiler will generate an error.
For example, the following is not allowed:
\begin{verbatim}
Unit UnitA;
interface
Uses UnitB;
implementation
end.

Unit UnitB
interface
Uses UnitA;
implementation
end.
\end{verbatim}
But this is allowed:
\begin{verbatim}
Unit UnitA;
interface
Uses UnitB;
implementation
end.
Unit UnitB
implementation
Uses UnitA;
end.
\end{verbatim}
Because \file{UnitB} uses \file{UnitA} only in its implementation section.

In general, it is a bad idea to have unit interdependencies, even if it is
only in implementation sections.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Blocks
\section{Blocks}
\label{se:blocks}
\index{block}
Units and programs are made of blocks. A block is made of declarations of
labels, constants, types, variables and functions or procedures. Blocks can
be nested in certain ways, i.\,e., a procedure or function declaration can
have blocks in themselves.
A block looks like the following:
\input{syntax/block.syn}
Labels that can be used to identify statements in a block are declared in
the label declaration part of that block. Each label can only identify one
statement.

Constants that are to be used only in one block should be declared in that
block's constant declaration part.

Variables that are to be used only in one block should be declared in that
block's variable declaration part.

Types that are to be used only in one block should be declared in that
block's type declaration part.

Lastly, functions and procedures that will be used in that block can be
declared in the procedure/function declaration part.

These four declaration parts can be intermixed, there is no required order
other than that you cannot use (or refer to) identifiers that have not
yet been declared.

After the different declaration parts comes the statement part. This
contains any actions that the block should execute. All identifiers
declared before the statement part can be used in that statement part.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Scope
\section{Scope}
\index{Scope}
Identifiers are valid from the point of their declaration until the end of
the block in which the declaration occurred. The range where the identifier
is known is the {\em scope} of the identifier. The exact scope of an
identifier depends on the way it was defined.
\subsection{Block scope}
\index{Scope!block}
The {\em scope} of a variable declared in the declaration part of a block,
is valid from the point of declaration until the end of the block.
If a block contains a second block, in which the identifier is
redeclared, then inside this block, the second declaration will be valid.
Upon leaving the inner block, the first declaration is valid again.
Consider the following example:
\begin{verbatim}
Program Demo;
Var X : Real;
{ X is real variable }
Procedure NewDeclaration
Var X : Integer;  { Redeclare X as integer}
begin
 // X := 1.234; {would give an error when trying to compile}
 X := 10; { Correct assignment}
end;
{ From here on, X is Real again}
begin
 X := 2.468;
end.
\end{verbatim}
In this example, inside the procedure, \var{X} denotes an integer variable.
It has its own storage space, independent of the variable \var{X} outside
the procedure.

\subsection{Record scope}
\index{Scope!record}
The field identifiers inside a record definition are valid in the following
places:
\begin{enumerate}
\item To the end of the record definition.
\item Field designators of a variable of the given record type.
\item Identifiers inside a \var{With} statement that operates on a variable
of the given record type.
\end{enumerate}

\subsection{Class scope}
\index{Scope!Class}
A component identifier (one of the items in the class' component list)
is valid in the following places:
\begin{enumerate}
\item From the point of declaration to the end of the class definition.
\item In all descendent types of this class, unless it is in the private
part of the class declaration.
\item In all method declaration blocks of this class and descendent classes.
\item In a \var{With} statement that operators on a variable of the given class's
definition.
\end{enumerate}
Note that method designators are also considered identifiers.
\subsection{Unit scope}
\index{Scope!unit}\index{unit}
All identifiers in the interface part of a unit are valid from the point of
declaration, until the end of the unit. Furthermore, the identifiers are
known in programs or units that have the unit in their uses clause.

Identifiers from indirectly dependent units are {\em not} available.
Identifiers declared in the implementation part of a unit are valid from the
point of declaration to the end of the unit.

The \file{system} unit is automatically used in all units and programs.
Its identifiers are therefore always known, in each Pascal program, library
or unit.

The rules of unit scope imply that an identifier of a unit can be redefined.
To have access to an identifier of another unit that was redeclared in
the current unit, precede it with that other units name, as in the following
example:
\begin{verbatim}
unit unitA;
interface
Type
  MyType = Real;
implementation
end.
Program prog;
Uses UnitA;

{ Redeclaration of MyType}
Type MyType = Integer;
Var A : Mytype;      { Will be Integer }
    B : UnitA.MyType { Will be real }
begin
end.
\end{verbatim}
This is especially useful when redeclaring the system unit's identifiers.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Libraries
\section{Libraries}
\index{Libraries}\index{library} \keywordlink{library}

\fpc supports making of dynamic libraries (DLLs under Win32 and \ostwo) through
the use of the \var{Library} keyword.

A Library is just like a unit or a program:
\input{syntax/library.syn}

By default, functions and procedures that are declared and implemented in
library are not available to a programmer that wishes to use this library.

In order to make functions or procedures available from the library,
they must be exported in an exports clause:

\input{syntax/exports.syn}

Under Win32, an index clause can be added to an exports entry.
An index entry must be a positive number larger or equal than 1, and less
than \var{MaxInt}.

Optionally, an exports entry can have a name specifier. If present, the name
specifier gives the exact name (case sensitive) by which the function will
be exported from the library.

If neither of these constructs is present, the functions or procedures
are exported with the exact names as specified in the exports clause.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Exceptions
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Exceptions}
\label{ch:Exceptions}\index{Exceptions}\index{Exception}
Exceptions provide a convenient way to program error and error-recovery
mechanisms, and are closely related to classes.
Exception support is based on three constructs:
\begin{description}
\item [Raise\ ] statements. To raise an exception. This is usually done to signal an
error condition.\index{Exceptions!Raising} It is however also usable to
abort execution and immediately return to a well-known point in the
executable.
\item [Try ... Except\ ] blocks. These block serve to catch exceptions
raised within the scope of the block, and to provide exception-recovery
code.\index{Exceptions!Catching}
\item [Try ... Finally\ ] blocks. These block serve to force code to be
executed irrespective of an exception occurrence or not. They generally
serve to clean up memory or close files in case an exception occurs.
The compiler generates many implicit \var{Try ... Finally} blocks around
procedure, to force memory consistency.
\end{description}

\begin{remark}
Because exceptions use classes, you need one of the object pascal modes to
be able to use them:
\begin{verbatim}
{$MODE OBJFPC}
\end{verbatim}
Or
\begin{verbatim}
{$MODE DELPHI}
\end{verbatim}
\end{remark}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% The raise statement
\section{The raise statement}
\index{Raise}\index{Exceptions!Raising}
\keywordlink{raise}
The \var{raise} statement is as follows:
\input{syntax/raise.syn}
This statement will raise an exception. If it is specified, the exception
instance must be an initialized instance of any class, which is the raise
type. The exception address and frame are optional. If they are not specified,
the compiler will provide the address by itself. If the exception instance is omitted,
then the current exception is re-raised. This construct can only be used
in an exception handling block (see further).

\begin{remark} Control {\em never} returns after an exception block. The
control is transferred to the first \var{try...finally} or
\var{try...except} statement that is encountered when unwinding the stack.
If no such statement is found, the \fpc Run-Time Library will generate a
run-time error 217 (see also \sees{exceptclasses}). The exception address
will be printed by the default exception handling routines.
\end{remark}

As an example: The following division checks whether the denominator is
zero, and if so, raises an exception of type \var{EDivException}
\begin{verbatim}
Type EDivException = Class(Exception);
Function DoDiv (X,Y : Longint) : Integer;
begin
  If Y=0 then
    Raise EDivException.Create ('Division by Zero would occur');
  Result := X Div Y;
end;
\end{verbatim}
The class \var{Exception} is defined in the \file{Sysutils} unit of the rtl.
(\sees{exceptclasses})

\begin{remark}
Although the \var{Exception} class is used as the base class for exceptions
throughout the code, this is just an unwritten agreement: the class can
be of any type, and need not be a descendent of the \var{Exception} class.

Of course, most code depends on the unwritten agreement that an exception
class descends from \var{Exception}.
\end{remark}

The following code shows how to omit an error reporting routine from the
stack shown in the exception handler:
\begin{verbatim}
{$mode objfpc}
uses sysutils;

procedure error(Const msg : string);

begin
  raise exception.create(Msg) at
    get_caller_addr(get_frame),
    get_caller_frame(get_frame);
end;

procedure test2;

begin
  error('Error');
end;

begin
  test2;
end.
\end{verbatim}
The program, when run, will show a backtrace as follows:
\begin{verbatim}
An unhandled exception occurred at $00000000004002D3 :
Exception : Error
  $00000000004002D3 line 15 of testme.pp
  $00000000004002E6 line 19 of testme.pp
\end{verbatim}
Line 15 is in procedure \var{Test2}, not in \var{Error}, which actually raised the exception.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% The try...except statement
\section{The try...except statement}
\index{except}\index{Exceptions!Catching}
\keywordlink{try} \keywordlink{except} \keywordlink{on} \keywordlink{do}
A \var{try...except} exception handling block is of the following form:
\input{syntax/try.syn}
If no exception is raised during the execution of the \var{statement list},
then all statements in the list will be executed sequentially, and the
except block will be skipped, transferring program flow to the statement
after the final \var{end}.

If an exception occurs during the execution of the \var{statement list}, the
program flow will be transferred to the except block. Statements in the
statement list between the place where the exception was raised and the
exception block are ignored.

In the exception handling block, the type of the exception is checked,
and if there is an exception handler where the class type matches the
exception object type, or is a parent type of
the exception object type, then the statement following the corresponding
\var{Do} will be executed. The first matching type is used. After the
\var{Do} block was executed, the program continues after the \var{End}
statement.

The identifier in an exception handling statement is optional, and declares
an exception object. It can be used to manipulate the exception object in
the exception handling code. The scope of this declaration is the statement
block following the \var{Do} keyword.

If none of the \var{On} handlers matches the exception object type, then the
statement list after \var{else} is executed. If no such list is
found, then the exception is automatically re-raised. This process allows
to nest \var{try...except} blocks.

If, on the other hand, the exception was caught, then the exception object is
destroyed at the end of the exception handling block, before program flow
continues. The exception is destroyed through a call to the object's
\var{Destroy} destructor.

As an example, given the previous declaration of the \var{DoDiv} function,
consider the following
\begin{verbatim}
Try
  Z := DoDiv (X,Y);
Except
  On EDivException do Z := 0;
end;
\end{verbatim}
If \var{Y} happens to be zero, then the DoDiv function code will raise an
exception. When this happens, program flow is transferred to the except
statement, where the Exception handler will set the value of \var{Z} to
zero. If no exception is raised, then program flow continues past the last
\var{end} statement.
To allow error recovery, the \var{Try ... Finally} block is supported.
A \var{Try...Finally} block ensures that the statements following the
\var{Finally} keyword are guaranteed to be executed, even if an exception
occurs.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% The try...finally statement
\section{The try...finally statement}
\index{finally}\index{try}\index{Exceptions!Handling}
\keywordlink{try} \keywordlink{finally}

A \var{Try..Finally} statement has the following form:
\input{syntax/finally.syn}
If no exception occurs inside the \var{statement List}, then the program
runs as if the \var{Try}, \var{Finally} and \var{End} keywords were not
present, unless an \var{exit} command is given: an exit command first
executes all statements in the finally blocks before actually exiting.

If, however, an exception occurs, the program flow is immediately
transferred from the point where the exception was raised to the first
statement of the \var{Finally statements}.

All statements after the finally keyword will be executed, and then
the exception will be automatically re-raised. Any statements between the
place where the exception was raised and the first statement of the
\var{Finally Statements} are skipped.

As an example consider the following routine:
\begin{verbatim}
Procedure Doit (Name : string);
Var F : Text;
begin
  Assign (F,Name);
  Rewrite (name);
  Try
    ... File handling ...
  Finally
    Close(F);
  end;
end;
\end{verbatim}
If during the execution of the file handling an exception occurs, then
program flow will continue at the \var{close(F)} statement, skipping any
file operations that might follow between the place where the exception
was raised, and the \var{Close} statement.
If no exception occurred, all file operations will be executed, and the file
will be closed at the end.

Note that an \var{Exit} statement enclosed by a \var{try .. finally} block,
will still execute the finally block. Reusing the previous example:
\begin{verbatim}
Procedure Doit (Name : string);
Var
  F : Text;
  B : Boolean;
begin
  B:=False;
  Assign (F,Name);
  Rewrite (name);
  Try
    // ... File handling ...
    if B then
      exit; // Stop processing prematurely
    // More file handling
  Finally
    Close(F);
  end;
end;
\end{verbatim}
The file will still be closed, even if the processing ends prematurely using
the \var{Exit} statement.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Exception handling nesting
\section{Exception handling nesting}
\index{finally}\index{except}\index{try}\index{Exceptions!Handling}
It is possible to nest \var{Try...Except} blocks with \var{Try...Finally}
blocks. Program flow will be done according to a \var{lifo} (last in, first
out) principle: The code of the last encountered \var{Try...Except} or
 \var{Try...Finally} block will be executed first. If the exception is not
caught, or it was a finally statement, program flow will be transferred to
the last-but-one block, {\em ad infinitum}.

If an exception occurs, and there is no exception handler present which
handles this exception, then a run-time error 217 will be generated.
When using the \file{SysUtils} unit, a default handler is installed which will show the exception object message, and the
address where the exception occurred, after which the program will exit with
a \var{Halt} instruction.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Exception classes
\section{Exception classes}
\index{Exceptions!Classes}
\label{se:exceptclasses}
The \file{sysutils} unit contains a great deal of exception handling.
It defines the base exception class, \var{Exception}
\begin{verbatim}
Exception = class(TObject)
private
  fmessage : string;
  fhelpcontext : longint;
public
  constructor create(const msg : string);
  constructor createres(indent : longint);
  property helpcontext : longint read fhelpcontext write fhelpcontext;
  property message : string read fmessage write fmessage;
end;
ExceptClass = Class of Exception;
\end{verbatim}
And uses this declaration to define quite a number of exceptions, for
instance:
\begin{verbatim}
{ mathematical exceptions }
EIntError = class(Exception);
EDivByZero = class(EIntError);
ERangeError = class(EIntError);
EIntOverflow = class(EIntError);
EMathError = class(Exception);
\end{verbatim}
The \file{SysUtils} unit also installs an exception handler. If an exception is
unhandled by any exception handling block, this handler is called by the
Run-Time library. Basically, it prints the exception address, and it prints
the message of the Exception object, and exits with an exit code of 217.
If the exception object is not a descendent object of the \var{Exception}
object, then the class name is printed instead of the exception message.

It is recommended to use the \var{Exception} object or a descendant class
for all \var{raise} statements, since then the message
field of the exception object can be used.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Using Assembler
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Using assembler}
\index{Assembler}
\fpc supports the use of assembler in code, but not inline
assembler macros.  To have more information on the processor
specific assembler syntax and its limitations, see the \progref.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Assembler statements
\section{Assembler statements }
\index{Statements!Assembler}  \keywordlink{asm}
The following is an example of assembler inclusion in Pascal code.
\begin{verbatim}
 ...
 Statements;
 ...
 Asm
   the asm code here
   ...
 end;
 ...
 Statements;
\end{verbatim}
The assembler instructions between the \var{Asm} and \var{end} keywords will
be inserted in the assembler generated by the compiler.
Conditionals can be used in assembler code, the compiler will recognize them,
and treat them as any other conditionals.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Assembler procedures and functions
\section{Assembler procedures and functions}
\index{Functions!Assembler}  \keywordlink{assembler}
Assembler procedures and functions are declared using the
\var{Assembler} directive.  This permits the code generator to make a number
of code generation optimizations.

The code generator does not generate any stack frame (entry and exit
code for the routine) if it contains no local variables and no
parameters. In the case of functions, ordinal values must be returned
in the accumulator. In the case of floating point values, these depend
on the target processor and emulation options.


%
% The index.
%
\printindex
\end{document}
