[25] | 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 |
---|