通讯编程

开发平台：
Visual C++

Interp.3：源码内容
							'"
'" Copyright (c) 1989-1993 The Regents of the University of California.
'" Copyright (c) 1994-1996 Sun Microsystems, Inc.
'"
'" See the file "license.terms" for information on usage and redistribution
'" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
'" 
'" RCS: @(#) $Id: Interp.3,v 1.3 2000/04/14 23:01:51 hobbs Exp $
'" 
.so man.macros
.TH Tcl_Interp 3 7.5 Tcl "Tcl Library Procedures"
.BS
.SH NAME
Tcl_Interp - client-visible fields of interpreter structures
.SH SYNOPSIS
.nf
fB#include <tcl.h>fR
.sp
typedef struct {
	char *fIresultfR;
	Tcl_FreeProc *fIfreeProcfR;
	int fIerrorLinefR;
} Tcl_Interp;
typedef void Tcl_FreeProc(char *fIblockPtrfR);
.BE
.SH DESCRIPTION
.PP
The fBTcl_CreateInterpfR procedure returns a pointer to a Tcl_Interp
structure.  This pointer is then passed into other Tcl procedures
to process commands in the interpreter and perform other operations
on the interpreter.  Interpreter structures contain many many fields
that are used by Tcl, but only three that may be accessed by
clients:  fIresultfR, fIfreeProcfR, and fIerrorLinefR.
.PP
The fIresultfR and fIfreeProcfR fields are used to return
results or error messages from commands.
This information is returned by command procedures back to fBTcl_EvalfR,
and by fBTcl_EvalfR back to its callers.
The fIresultfR field points to the string that represents the
result or error message, and the fIfreeProcfR field tells how
to dispose of the storage for the string when it isn't needed anymore.
The easiest way for command procedures to manipulate these
fields is to call procedures like fBTcl_SetResultfR
or fBTcl_AppendResultfR;  they
will hide all the details of managing the fields.
The description below is for those procedures that manipulate the
fields directly.
.PP
Whenever a command procedure returns, it must ensure
that the fIresultfR field of its interpreter points to the string
being returned by the command.
The fIresultfR field must always point to a valid string.
If a command wishes to return no result then fIinterp->resultfR
should point to an empty string.
Normally, results are assumed to be statically allocated,
which means that the contents will not change before the next time
fBTcl_EvalfR is called or some other command procedure is invoked.
.VS
In this case, the fIfreeProcfR field must be zero.
Alternatively, a command procedure may dynamically
allocate its return value (e.g. using fBTcl_AllocfR)
and store a pointer to it in fIinterp->resultfR.
In this case, the command procedure must also set fIinterp->freeProcfR
to the address of a procedure that can free the value, or fBTCL_DYNAMICfR
if the storage was allocated directly by Tcl or by a call to
fBTcl_AllocfR. 
.VE
If fIinterp->freeProcfR is non-zero, then Tcl will call fIfreeProcfR
to free the space pointed to by fIinterp->resultfR before it
invokes the next command.
If a client procedure overwrites fIinterp->resultfR when
fIinterp->freeProcfR is non-zero, then it is responsible for calling
fIfreeProcfR to free the old fIinterp->resultfR (the fBTcl_FreeResultfR
macro should be used for this purpose).
.PP
fIFreeProcfR should have arguments and result that match the
fBTcl_FreeProcfR declaration above:  it receives a single
argument which is a pointer to the result value to free.
.VS
In most applications fBTCL_DYNAMICfR is the only non-zero value ever
used for fIfreeProcfR.
.VE
However, an application may store a different procedure address
in fIfreeProcfR in order to use an alternate memory allocator
or in order to do other cleanup when the result memory is freed.
.PP
As part of processing each command, fBTcl_EvalfR initializes
fIinterp->resultfR
and fIinterp->freeProcfR just before calling the command procedure for
the command.  The fIfreeProcfR field will be initialized to zero,
and fIinterp->resultfR will point to an empty string.  Commands that
do not return any value can simply leave the fields alone.
Furthermore, the empty string pointed to by fIresultfR is actually
part of an array of fBTCL_RESULT_SIZEfR characters (approximately 200).
If a command wishes to return a short string, it can simply copy
it to the area pointed to by fIinterp->resultfR.  Or, it can use
the sprintf procedure to generate a short result string at the location
pointed to by fIinterp->resultfR.
.PP
It is a general convention in Tcl-based applications that the result
of an interpreter is normally in the initialized state described
in the previous paragraph.
Procedures that manipulate an interpreter's result (e.g. by
returning an error) will generally assume that the result
has been initialized when the procedure is called.
If such a procedure is to be called after the result has been
changed, then fBTcl_ResetResultfR should be called first to
reset the result to its initialized state.  The direct use of
fIinterp->resultfR is strongly deprecated (see fBTcl_SetResultfR).
.PP
The fIerrorLinefR
field is valid only after fBTcl_EvalfR returns
a fBTCL_ERRORfR return code.  In this situation the fIerrorLinefR
field identifies the line number of the command being executed when
the error occurred.  The line numbers are relative to the command
being executed:  1 means the first line of the command passed to
fBTcl_EvalfR, 2 means the second line, and so on.
The fIerrorLinefR field is typically used in conjunction with
fBTcl_AddErrorInfofR to report information about where an error
occurred.
fIErrorLinefR should not normally be modified except by fBTcl_EvalfR.
.SH KEYWORDS
free, initialized, interpreter, malloc, result

						