1 | '\" |
---|
2 | '\" Copyright (c) 1996-1997 Sun Microsystems, Inc. |
---|
3 | '\" |
---|
4 | '\" See the file "license.terms" for information on usage and redistribution |
---|
5 | '\" of this file, and for a DISCLAIMER OF ALL WARRANTIES. |
---|
6 | '\" |
---|
7 | '\" RCS: @(#) $Id: Object.3,v 1.18 2007/12/13 15:22:31 dgp Exp $ |
---|
8 | '\" |
---|
9 | .so man.macros |
---|
10 | .TH Tcl_Obj 3 8.5 Tcl "Tcl Library Procedures" |
---|
11 | .BS |
---|
12 | .SH NAME |
---|
13 | Tcl_NewObj, Tcl_DuplicateObj, Tcl_IncrRefCount, Tcl_DecrRefCount, Tcl_IsShared, Tcl_InvalidateStringRep \- manipulate Tcl objects |
---|
14 | .SH SYNOPSIS |
---|
15 | .nf |
---|
16 | \fB#include <tcl.h>\fR |
---|
17 | .sp |
---|
18 | Tcl_Obj * |
---|
19 | \fBTcl_NewObj\fR() |
---|
20 | .sp |
---|
21 | Tcl_Obj * |
---|
22 | \fBTcl_DuplicateObj\fR(\fIobjPtr\fR) |
---|
23 | .sp |
---|
24 | \fBTcl_IncrRefCount\fR(\fIobjPtr\fR) |
---|
25 | .sp |
---|
26 | \fBTcl_DecrRefCount\fR(\fIobjPtr\fR) |
---|
27 | .sp |
---|
28 | int |
---|
29 | \fBTcl_IsShared\fR(\fIobjPtr\fR) |
---|
30 | .sp |
---|
31 | \fBTcl_InvalidateStringRep\fR(\fIobjPtr\fR) |
---|
32 | .SH ARGUMENTS |
---|
33 | .AS Tcl_Obj *objPtr |
---|
34 | .AP Tcl_Obj *objPtr in |
---|
35 | Points to an object; |
---|
36 | must have been the result of a previous call to \fBTcl_NewObj\fR. |
---|
37 | .BE |
---|
38 | |
---|
39 | .SH INTRODUCTION |
---|
40 | .PP |
---|
41 | This man page presents an overview of Tcl objects and how they are used. |
---|
42 | It also describes generic procedures for managing Tcl objects. |
---|
43 | These procedures are used to create and copy objects, |
---|
44 | and increment and decrement the count of references (pointers) to objects. |
---|
45 | The procedures are used in conjunction with ones |
---|
46 | that operate on specific types of objects such as |
---|
47 | \fBTcl_GetIntFromObj\fR and \fBTcl_ListObjAppendElement\fR. |
---|
48 | The individual procedures are described along with the data structures |
---|
49 | they manipulate. |
---|
50 | .PP |
---|
51 | Tcl's \fIdual-ported\fR objects provide a general-purpose mechanism |
---|
52 | for storing and exchanging Tcl values. |
---|
53 | They largely replace the use of strings in Tcl. |
---|
54 | For example, they are used to store variable values, |
---|
55 | command arguments, command results, and scripts. |
---|
56 | Tcl objects behave like strings but also hold an internal representation |
---|
57 | that can be manipulated more efficiently. |
---|
58 | For example, a Tcl list is now represented as an object |
---|
59 | that holds the list's string representation |
---|
60 | as well as an array of pointers to the objects for each list element. |
---|
61 | Dual-ported objects avoid most runtime type conversions. |
---|
62 | They also improve the speed of many operations |
---|
63 | since an appropriate representation is immediately available. |
---|
64 | The compiler itself uses Tcl objects to |
---|
65 | cache the instruction bytecodes resulting from compiling scripts. |
---|
66 | .PP |
---|
67 | The two representations are a cache of each other and are computed lazily. |
---|
68 | That is, each representation is only computed when necessary, |
---|
69 | it is computed from the other representation, |
---|
70 | and, once computed, it is saved. |
---|
71 | In addition, a change in one representation invalidates the other one. |
---|
72 | As an example, a Tcl program doing integer calculations can |
---|
73 | operate directly on a variable's internal machine integer |
---|
74 | representation without having to constantly convert |
---|
75 | between integers and strings. |
---|
76 | Only when it needs a string representing the variable's value, |
---|
77 | say to print it, |
---|
78 | will the program regenerate the string representation from the integer. |
---|
79 | Although objects contain an internal representation, |
---|
80 | their semantics are defined in terms of strings: |
---|
81 | an up-to-date string can always be obtained, |
---|
82 | and any change to the object will be reflected in that string |
---|
83 | when the object's string representation is fetched. |
---|
84 | Because of this representation invalidation and regeneration, |
---|
85 | it is dangerous for extension writers to access |
---|
86 | \fBTcl_Obj\fR fields directly. |
---|
87 | It is better to access Tcl_Obj information using |
---|
88 | procedures like \fBTcl_GetStringFromObj\fR and \fBTcl_GetString\fR. |
---|
89 | .PP |
---|
90 | Objects are allocated on the heap |
---|
91 | and are referenced using a pointer to their \fBTcl_Obj\fR structure. |
---|
92 | Objects are shared as much as possible. |
---|
93 | This significantly reduces storage requirements |
---|
94 | because some objects such as long lists are very large. |
---|
95 | Also, most Tcl values are only read and never modified. |
---|
96 | This is especially true for procedure arguments, |
---|
97 | which can be shared between the caller and the called procedure. |
---|
98 | Assignment and argument binding is done by |
---|
99 | simply assigning a pointer to the value. |
---|
100 | Reference counting is used to determine when it is safe to |
---|
101 | reclaim an object's storage. |
---|
102 | .PP |
---|
103 | Tcl objects are typed. |
---|
104 | An object's internal representation is controlled by its type. |
---|
105 | Seven types are predefined in the Tcl core |
---|
106 | including integer, double, list, and bytecode. |
---|
107 | Extension writers can extend the set of types |
---|
108 | by using the procedure \fBTcl_RegisterObjType\fR . |
---|
109 | .SH "THE TCL_OBJ STRUCTURE" |
---|
110 | .PP |
---|
111 | Each Tcl object is represented by a \fBTcl_Obj\fR structure |
---|
112 | which is defined as follows. |
---|
113 | .CS |
---|
114 | typedef struct Tcl_Obj { |
---|
115 | int \fIrefCount\fR; |
---|
116 | char *\fIbytes\fR; |
---|
117 | int \fIlength\fR; |
---|
118 | Tcl_ObjType *\fItypePtr\fR; |
---|
119 | union { |
---|
120 | long \fIlongValue\fR; |
---|
121 | double \fIdoubleValue\fR; |
---|
122 | void *\fIotherValuePtr\fR; |
---|
123 | Tcl_WideInt \fIwideValue\fR; |
---|
124 | struct { |
---|
125 | void *\fIptr1\fR; |
---|
126 | void *\fIptr2\fR; |
---|
127 | } \fItwoPtrValue\fR; |
---|
128 | struct { |
---|
129 | void *\fIptr\fR; |
---|
130 | unsigned long \fIvalue\fR; |
---|
131 | } \fIptrAndLongRep\fR; |
---|
132 | } \fIinternalRep\fR; |
---|
133 | } Tcl_Obj; |
---|
134 | .CE |
---|
135 | The \fIbytes\fR and the \fIlength\fR members together hold |
---|
136 | an object's UTF-8 string representation, |
---|
137 | which is a \fIcounted string\fR not containing null bytes (UTF-8 null |
---|
138 | characters should be encoded as a two byte sequence: 192, 128.) |
---|
139 | \fIbytes\fR points to the first byte of the string representation. |
---|
140 | The \fIlength\fR member gives the number of bytes. |
---|
141 | The byte array must always have a null byte after the last data byte, |
---|
142 | at offset \fIlength\fR; |
---|
143 | this allows string representations |
---|
144 | to be treated as conventional null-terminated C strings. |
---|
145 | C programs use \fBTcl_GetStringFromObj\fR and \fBTcl_GetString\fR to get |
---|
146 | an object's string representation. |
---|
147 | If \fIbytes\fR is NULL, |
---|
148 | the string representation is invalid. |
---|
149 | .PP |
---|
150 | An object's type manages its internal representation. |
---|
151 | The member \fItypePtr\fR points to the Tcl_ObjType structure |
---|
152 | that describes the type. |
---|
153 | If \fItypePtr\fR is NULL, |
---|
154 | the internal representation is invalid. |
---|
155 | .PP |
---|
156 | The \fIinternalRep\fR union member holds |
---|
157 | an object's internal representation. |
---|
158 | This is either a (long) integer, a double-precision floating-point number, |
---|
159 | a pointer to a value containing additional information |
---|
160 | needed by the object's type to represent the object, a Tcl_WideInt |
---|
161 | integer, two arbitrary pointers, or a pair made up of an unsigned long |
---|
162 | integer and a pointer. |
---|
163 | .PP |
---|
164 | The \fIrefCount\fR member is used to tell when it is safe to free |
---|
165 | an object's storage. |
---|
166 | It holds the count of active references to the object. |
---|
167 | Maintaining the correct reference count is a key responsibility |
---|
168 | of extension writers. |
---|
169 | Reference counting is discussed below |
---|
170 | in the section \fBSTORAGE MANAGEMENT OF OBJECTS\fR. |
---|
171 | .PP |
---|
172 | Although extension writers can directly access |
---|
173 | the members of a Tcl_Obj structure, |
---|
174 | it is much better to use the appropriate procedures and macros. |
---|
175 | For example, extension writers should never |
---|
176 | read or update \fIrefCount\fR directly; |
---|
177 | they should use macros such as |
---|
178 | \fBTcl_IncrRefCount\fR and \fBTcl_IsShared\fR instead. |
---|
179 | .PP |
---|
180 | A key property of Tcl objects is that they hold two representations. |
---|
181 | An object typically starts out containing only a string representation: |
---|
182 | it is untyped and has a NULL \fItypePtr\fR. |
---|
183 | An object containing an empty string or a copy of a specified string |
---|
184 | is created using \fBTcl_NewObj\fR or \fBTcl_NewStringObj\fR respectively. |
---|
185 | An object's string value is gotten with |
---|
186 | \fBTcl_GetStringFromObj\fR or \fBTcl_GetString\fR |
---|
187 | and changed with \fBTcl_SetStringObj\fR. |
---|
188 | If the object is later passed to a procedure like \fBTcl_GetIntFromObj\fR |
---|
189 | that requires a specific internal representation, |
---|
190 | the procedure will create one and set the object's \fItypePtr\fR. |
---|
191 | The internal representation is computed from the string representation. |
---|
192 | An object's two representations are duals of each other: |
---|
193 | changes made to one are reflected in the other. |
---|
194 | For example, \fBTcl_ListObjReplace\fR will modify an object's |
---|
195 | internal representation and the next call to \fBTcl_GetStringFromObj\fR |
---|
196 | or \fBTcl_GetString\fR will reflect that change. |
---|
197 | .PP |
---|
198 | Representations are recomputed lazily for efficiency. |
---|
199 | A change to one representation made by a procedure |
---|
200 | such as \fBTcl_ListObjReplace\fR is not reflected immediately |
---|
201 | in the other representation. |
---|
202 | Instead, the other representation is marked invalid |
---|
203 | so that it is only regenerated if it is needed later. |
---|
204 | Most C programmers never have to be concerned with how this is done |
---|
205 | and simply use procedures such as \fBTcl_GetBooleanFromObj\fR or |
---|
206 | \fBTcl_ListObjIndex\fR. |
---|
207 | Programmers that implement their own object types |
---|
208 | must check for invalid representations |
---|
209 | and mark representations invalid when necessary. |
---|
210 | The procedure \fBTcl_InvalidateStringRep\fR is used |
---|
211 | to mark an object's string representation invalid and to |
---|
212 | free any storage associated with the old string representation. |
---|
213 | .PP |
---|
214 | Objects usually remain one type over their life, |
---|
215 | but occasionally an object must be converted from one type to another. |
---|
216 | For example, a C program might build up a string in an object |
---|
217 | with repeated calls to \fBTcl_AppendToObj\fR, |
---|
218 | and then call \fBTcl_ListObjIndex\fR to extract a list element from |
---|
219 | the object. |
---|
220 | The same object holding the same string value |
---|
221 | can have several different internal representations |
---|
222 | at different times. |
---|
223 | Extension writers can also force an object to be converted from one type |
---|
224 | to another using the \fBTcl_ConvertToType\fR procedure. |
---|
225 | Only programmers that create new object types need to be concerned |
---|
226 | about how this is done. |
---|
227 | A procedure defined as part of the object type's implementation |
---|
228 | creates a new internal representation for an object |
---|
229 | and changes its \fItypePtr\fR. |
---|
230 | See the man page for \fBTcl_RegisterObjType\fR |
---|
231 | to see how to create a new object type. |
---|
232 | .SH "EXAMPLE OF THE LIFETIME OF AN OBJECT" |
---|
233 | .PP |
---|
234 | As an example of the lifetime of an object, |
---|
235 | consider the following sequence of commands: |
---|
236 | .CS |
---|
237 | \fBset x 123\fR |
---|
238 | .CE |
---|
239 | This assigns to \fIx\fR an untyped object whose |
---|
240 | \fIbytes\fR member points to \fB123\fR and \fIlength\fR member contains 3. |
---|
241 | The object's \fItypePtr\fR member is NULL. |
---|
242 | .CS |
---|
243 | \fBputs "x is $x"\fR |
---|
244 | .CE |
---|
245 | \fIx\fR's string representation is valid (since \fIbytes\fR is non-NULL) |
---|
246 | and is fetched for the command. |
---|
247 | .CS |
---|
248 | \fBincr x\fR |
---|
249 | .CE |
---|
250 | The \fBincr\fR command first gets an integer from \fIx\fR's object |
---|
251 | by calling \fBTcl_GetIntFromObj\fR. |
---|
252 | This procedure checks whether the object is already an integer object. |
---|
253 | Since it is not, it converts the object |
---|
254 | by setting the object's \fIinternalRep.longValue\fR member |
---|
255 | to the integer \fB123\fR |
---|
256 | and setting the object's \fItypePtr\fR |
---|
257 | to point to the integer Tcl_ObjType structure. |
---|
258 | Both representations are now valid. |
---|
259 | \fBincr\fR increments the object's integer internal representation |
---|
260 | then invalidates its string representation |
---|
261 | (by calling \fBTcl_InvalidateStringRep\fR) |
---|
262 | since the string representation |
---|
263 | no longer corresponds to the internal representation. |
---|
264 | .CS |
---|
265 | \fBputs "x is now $x"\fR |
---|
266 | .CE |
---|
267 | The string representation of \fIx\fR's object is needed |
---|
268 | and is recomputed. |
---|
269 | The string representation is now \fB124\fR |
---|
270 | and both representations are again valid. |
---|
271 | .SH "STORAGE MANAGEMENT OF OBJECTS" |
---|
272 | .PP |
---|
273 | Tcl objects are allocated on the heap and are shared as much as possible |
---|
274 | to reduce storage requirements. |
---|
275 | Reference counting is used to determine when an object is |
---|
276 | no longer needed and can safely be freed. |
---|
277 | An object just created by \fBTcl_NewObj\fR or \fBTcl_NewStringObj\fR |
---|
278 | has \fIrefCount\fR 0. |
---|
279 | The macro \fBTcl_IncrRefCount\fR increments the reference count |
---|
280 | when a new reference to the object is created. |
---|
281 | The macro \fBTcl_DecrRefCount\fR decrements the count |
---|
282 | when a reference is no longer needed and, |
---|
283 | if the object's reference count drops to zero, frees its storage. |
---|
284 | An object shared by different code or data structures has |
---|
285 | \fIrefCount\fR greater than 1. |
---|
286 | Incrementing an object's reference count ensures that |
---|
287 | it will not be freed too early or have its value change accidentally. |
---|
288 | .PP |
---|
289 | As an example, the bytecode interpreter shares argument objects |
---|
290 | between calling and called Tcl procedures to avoid having to copy objects. |
---|
291 | It assigns the call's argument objects to the procedure's |
---|
292 | formal parameter variables. |
---|
293 | In doing so, it calls \fBTcl_IncrRefCount\fR to increment |
---|
294 | the reference count of each argument since there is now a new |
---|
295 | reference to it from the formal parameter. |
---|
296 | When the called procedure returns, |
---|
297 | the interpreter calls \fBTcl_DecrRefCount\fR to decrement |
---|
298 | each argument's reference count. |
---|
299 | When an object's reference count drops less than or equal to zero, |
---|
300 | \fBTcl_DecrRefCount\fR reclaims its storage. |
---|
301 | Most command procedures do not have to be concerned about |
---|
302 | reference counting since they use an object's value immediately |
---|
303 | and do not retain a pointer to the object after they return. |
---|
304 | However, if they do retain a pointer to an object in a data structure, |
---|
305 | they must be careful to increment its reference count |
---|
306 | since the retained pointer is a new reference. |
---|
307 | .PP |
---|
308 | Command procedures that directly modify objects |
---|
309 | such as those for \fBlappend\fR and \fBlinsert\fR must be careful to |
---|
310 | copy a shared object before changing it. |
---|
311 | They must first check whether the object is shared |
---|
312 | by calling \fBTcl_IsShared\fR. |
---|
313 | If the object is shared they must copy the object |
---|
314 | by using \fBTcl_DuplicateObj\fR; |
---|
315 | this returns a new duplicate of the original object |
---|
316 | that has \fIrefCount\fR 0. |
---|
317 | If the object is not shared, |
---|
318 | the command procedure |
---|
319 | .QW "owns" |
---|
320 | the object and can safely modify it directly. |
---|
321 | For example, the following code appears in the command procedure |
---|
322 | that implements \fBlinsert\fR. |
---|
323 | This procedure modifies the list object passed to it in \fIobjv[1]\fR |
---|
324 | by inserting \fIobjc-3\fR new elements before \fIindex\fR. |
---|
325 | .PP |
---|
326 | .CS |
---|
327 | listPtr = objv[1]; |
---|
328 | if (Tcl_IsShared(listPtr)) { |
---|
329 | listPtr = Tcl_DuplicateObj(listPtr); |
---|
330 | } |
---|
331 | result = Tcl_ListObjReplace(interp, listPtr, index, 0, |
---|
332 | (objc-3), &(objv[3])); |
---|
333 | .CE |
---|
334 | .PP |
---|
335 | As another example, \fBincr\fR's command procedure |
---|
336 | must check whether the variable's object is shared before |
---|
337 | incrementing the integer in its internal representation. |
---|
338 | If it is shared, it needs to duplicate the object |
---|
339 | in order to avoid accidentally changing values in other data structures. |
---|
340 | .SH "SEE ALSO" |
---|
341 | Tcl_ConvertToType(3), Tcl_GetIntFromObj(3), Tcl_ListObjAppendElement(3), Tcl_ListObjIndex(3), Tcl_ListObjReplace(3), Tcl_RegisterObjType(3) |
---|
342 | .SH KEYWORDS |
---|
343 | internal representation, object, object creation, object type, reference counting, string representation, type conversion |
---|