![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gxxint.texi CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc / cp|
Return to gxxint.texi CVS log | Up to [GCC 2.x] / gcc / cp |
1.1 ! root 1: \input texinfo @c -*-texinfo-*- ! 2: @c %**start of header ! 3: @setfilename g++int.info ! 4: @settitle G++ internals ! 5: @setchapternewpage odd ! 6: @c %**end of header ! 7: ! 8: @node Top, Limitations of g++, (dir), (dir) ! 9: @chapter Internal Architecture of the Compiler ! 10: ! 11: This is meant to describe the C++ front-end for gcc in detail. ! 12: Questions and comments to mrs@@cygnus.com. ! 13: ! 14: @menu ! 15: * Limitations of g++:: ! 16: * Routines:: ! 17: * Implementation Specifics:: ! 18: * Glossary:: ! 19: * Macros:: ! 20: * Typical Behavior:: ! 21: * Coding Conventions:: ! 22: * Templates:: ! 23: * Access Control:: ! 24: * Error Reporting:: ! 25: * Parser:: ! 26: * Copying Objects:: ! 27: * Exception Handling:: ! 28: * Free Store:: ! 29: * Concept Index:: ! 30: @end menu ! 31: ! 32: @node Limitations of g++, Routines, Top, Top ! 33: @section Limitations of g++ ! 34: ! 35: @itemize @bullet ! 36: @item ! 37: Limitations on input source code: 240 nesting levels with the parser ! 38: stacksize (YYSTACKSIZE) set to 500 (the default), and requires around ! 39: 16.4k swap space per nesting level. The parser needs about 2.09 * ! 40: number of nesting levels worth of stackspace. ! 41: ! 42: @cindex pushdecl_class_level ! 43: @item ! 44: I suspect there are other uses of pushdecl_class_level that do not call ! 45: set_identifier_type_value in tandem with the call to ! 46: pushdecl_class_level. It would seem to be an omission. ! 47: ! 48: @cindex access checking ! 49: @item ! 50: Access checking is unimplemented for nested types. ! 51: ! 52: @cindex @code{volatile} ! 53: @item ! 54: @code{volatile} is not implemented in general. ! 55: ! 56: @cindex pointers to members ! 57: @item ! 58: Pointers to members are only minimally supported, and there are places ! 59: where the grammar doesn't even properly accept them yet. ! 60: ! 61: @cindex multiple inheritance ! 62: @item ! 63: @code{this} will be wrong in virtual members functions defined in a ! 64: virtual base class, when they are overridden in a derived class, when ! 65: called via a non-left most object. ! 66: ! 67: An example would be: ! 68: ! 69: @example ! 70: extern "C" int printf(const char*, ...); ! 71: struct A @{ virtual void f() @{ @} @}; ! 72: struct B : virtual A @{ int b; B() : b(0) @{@} void f() @{ b++; @} @}; ! 73: struct C : B @{@}; ! 74: struct D : B @{@}; ! 75: struct E : C, D @{@}; ! 76: int main() ! 77: @{ ! 78: E e; ! 79: C& c = e; D& d = e; ! 80: c.f(); d.f(); ! 81: printf ("C::b = %d, D::b = %d\n", e.C::b, e.D::b); ! 82: return 0; ! 83: @} ! 84: @end example ! 85: ! 86: This will print out 2, 0, instead of 1,1. ! 87: ! 88: @end itemize ! 89: ! 90: @node Routines, Implementation Specifics, Limitations of g++, Top ! 91: @section Routines ! 92: ! 93: This section describes some of the routines used in the C++ front-end. ! 94: ! 95: @code{build_vtable} and @code{prepare_fresh_vtable} is used only within ! 96: the @file{cp-class.c} file, and only in @code{finish_struct} and ! 97: @code{modify_vtable_entries}. ! 98: ! 99: @code{build_vtable}, @code{prepare_fresh_vtable}, and ! 100: @code{finish_struct} are the only routines that set @code{DECL_VPARENT}. ! 101: ! 102: @code{finish_struct} can steal the virtual function table from parents, ! 103: this prohibits related_vslot from working. When finish_struct steals, ! 104: we know that ! 105: ! 106: @example ! 107: get_binfo (DECL_FIELD_CONTEXT (CLASSTYPE_VFIELD (t)), t, 0) ! 108: @end example ! 109: ! 110: @noindent ! 111: will get the related binfo. ! 112: ! 113: @code{layout_basetypes} does something with the VIRTUALS. ! 114: ! 115: Supposedly (according to Tiemann) most of the breadth first searching ! 116: done, like in @code{get_base_distance} and in @code{get_binfo} was not ! 117: because of any design decision. I have since found out the at least one ! 118: part of the compiler needs the notion of depth first binfo searching, I ! 119: am going to try and convert the whole thing, it should just work. The ! 120: term left-most refers to the depth first left-most node. It uses ! 121: @code{MAIN_VARIANT == type} as the condition to get left-most, because ! 122: the things that have @code{BINFO_OFFSET}s of zero are shared and will ! 123: have themselves as their own @code{MAIN_VARIANT}s. The non-shared right ! 124: ones, are copies of the left-most one, hence if it is its own ! 125: @code{MAIN_VARIENT}, we know it IS a left-most one, if it is not, it is ! 126: a non-left-most one. ! 127: ! 128: @code{get_base_distance}'s path and distance matters in its use in: ! 129: ! 130: @itemize @bullet ! 131: @item ! 132: @code{prepare_fresh_vtable} (the code is probably wrong) ! 133: @item ! 134: @code{init_vfields} Depends upon distance probably in a safe way, ! 135: build_offset_ref might use partial paths to do further lookups, ! 136: hack_identifier is probably not properly checking access. ! 137: ! 138: @item ! 139: @code{get_first_matching_virtual} probably should check for ! 140: @code{get_base_distance} returning -2. ! 141: ! 142: @item ! 143: @code{resolve_offset_ref} should be called in a more deterministic ! 144: manner. Right now, it is called in some random contexts, like for ! 145: arguments at @code{build_method_call} time, @code{default_conversion} ! 146: time, @code{convert_arguments} time, @code{build_unary_op} time, ! 147: @code{build_c_cast} time, @code{build_modify_expr} time, ! 148: @code{convert_for_assignment} time, and ! 149: @code{convert_for_initialization} time. ! 150: ! 151: But, there are still more contexts it needs to be called in, one was the ! 152: ever simple: ! 153: ! 154: @example ! 155: if (obj.*pmi != 7) ! 156: @dots{} ! 157: @end example ! 158: ! 159: Seems that the problems were due to the fact that @code{TREE_TYPE} of ! 160: the @code{OFFSET_REF} was not a @code{OFFSET_TYPE}, but rather the type ! 161: of the referent (like @code{INTEGER_TYPE}). This problem was fixed by ! 162: changing @code{default_conversion} to check @code{TREE_CODE (x)}, ! 163: instead of only checking @code{TREE_CODE (TREE_TYPE (x))} to see if it ! 164: was @code{OFFSET_TYPE}. ! 165: ! 166: @end itemize ! 167: ! 168: @node Implementation Specifics, Glossary, Routines, Top ! 169: @section Implementation Specifics ! 170: ! 171: @itemize @bullet ! 172: @item Explicit Initialization ! 173: ! 174: The global list @code{current_member_init_list} contains the list of ! 175: mem-initializers specified in a constructor declaration. For example: ! 176: ! 177: @example ! 178: foo::foo() : a(1), b(2) @{@} ! 179: @end example ! 180: ! 181: @noindent ! 182: will initialize @samp{a} with 1 and @samp{b} with 2. ! 183: @code{expand_member_init} places each initialization (a with 1) on the ! 184: global list. Then, when the fndecl is being processed, ! 185: @code{emit_base_init} runs down the list, initializing them. It used to ! 186: be the case that g++ first ran down @code{current_member_init_list}, ! 187: then ran down the list of members initializing the ones that weren't ! 188: explicitly initialized. Things were rewritten to perform the ! 189: initializations in order of declaration in the class. So, for the above ! 190: example, @samp{a} and @samp{b} will be initialized in the order that ! 191: they were declared: ! 192: ! 193: @example ! 194: class foo @{ public: int b; int a; foo (); @}; ! 195: @end example ! 196: ! 197: @noindent ! 198: Thus, @samp{b} will be initialized with 2 first, then @samp{a} will be ! 199: initialized with 1, regardless of how they're listed in the mem-initializer. ! 200: ! 201: @item Argument Matching ! 202: ! 203: In early 1993, the argument matching scheme in @sc{gnu} C++ changed ! 204: significantly. The original code was completely replaced with a new ! 205: method that will, hopefully, be easier to understand and make fixing ! 206: specific cases much easier. ! 207: ! 208: The @samp{-fansi-overloading} option is used to enable the new code; at ! 209: some point in the future, it will become the default behavior of the ! 210: compiler. ! 211: ! 212: The file @file{cp-call.c} contains all of the new work, in the functions ! 213: @code{rank_for_overload}, @code{compute_harshness}, ! 214: @code{compute_conversion_costs}, and @code{ideal_candidate}. ! 215: ! 216: Instead of using obscure numerical values, the quality of an argument ! 217: match is now represented by clear, individual codes. The new data ! 218: structure @code{struct harshness} (it used to be an @code{unsigned} ! 219: number) contains: ! 220: ! 221: @enumerate a ! 222: @item the @samp{code} field, to signify what was involved in matching two ! 223: arguments; ! 224: @item the @samp{distance} field, used in situations where inheritance ! 225: decides which function should be called (one is ``closer'' than ! 226: another); ! 227: @item and the @samp{int_penalty} field, used by some codes as a tie-breaker. ! 228: @end enumerate ! 229: ! 230: The @samp{code} field is a number with a given bit set for each type of ! 231: code, OR'd together. The new codes are: ! 232: ! 233: @itemize @bullet ! 234: @item @code{EVIL_CODE} ! 235: The argument was not a permissible match. ! 236: ! 237: @item @code{CONST_CODE} ! 238: Currently, this is only used by @code{compute_conversion_costs}, to ! 239: distinguish when a non-@code{const} member function is called from a ! 240: @code{const} member function. ! 241: ! 242: @item @code{ELLIPSIS_CODE} ! 243: A match against an ellipsis @samp{...} is considered worse than all others. ! 244: ! 245: @item @code{USER_CODE} ! 246: Used for a match involving a user-defined conversion. ! 247: ! 248: @item @code{STD_CODE} ! 249: A match involving a standard conversion. ! 250: ! 251: @item @code{PROMO_CODE} ! 252: A match involving an integral promotion. For these, the ! 253: @code{int_penalty} field is used to handle the ARM's rule (XXX cite) ! 254: that a smaller @code{unsigned} type should promote to a @code{int}, not ! 255: to an @code{unsigned int}. ! 256: ! 257: @item @code{QUAL_CODE} ! 258: Used to mark use of qualifiers like @code{const} and @code{volatile}. ! 259: ! 260: @item @code{TRIVIAL_CODE} ! 261: Used for trivial conversions. The @samp{int_penalty} field is used by ! 262: @code{convert_harshness} to communicate further penalty information back ! 263: to @code{build_overload_call_real} when deciding which function should ! 264: be call. ! 265: @end itemize ! 266: ! 267: The functions @code{convert_to_aggr} and @code{build_method_call} use ! 268: @code{compute_conversion_costs} to rate each argument's suitability for ! 269: a given candidate function (that's how we get the list of candidates for ! 270: @code{ideal_candidate}). ! 271: ! 272: @end itemize ! 273: ! 274: @node Glossary, Macros, Implementation Specifics, Top ! 275: @section Glossary ! 276: ! 277: @table @r ! 278: @item binfo ! 279: The main data structure in the compiler used to represent the ! 280: inheritance relationships between classes. The data in the binfo can be ! 281: accessed by the BINFO_ accessor macros. ! 282: ! 283: @item vtable ! 284: @itemx virtual function table ! 285: ! 286: The virtual function table holds information used in virtual function ! 287: dispatching. In the compiler, they are usually referred to as vtables, ! 288: or vtbls. The first index is not used in the normal way, I believe it ! 289: is probably used for the virtual destructor. ! 290: ! 291: @item vfield ! 292: ! 293: vfields can be thought of as the base information needed to build ! 294: vtables. For every vtable that exists for a class, there is a vfield. ! 295: See also vtable and virtual function table pointer. When a type is used ! 296: as a base class to another type, the virtual function table for the ! 297: derived class can be based upon the vtable for the base class, just ! 298: extended to include the additional virtual methods declared in the ! 299: derived class. The virtual function table from a virtual base class is ! 300: never reused in a derived class. @code{is_normal} depends upon this. ! 301: ! 302: @item virtual function table pointer ! 303: ! 304: These are @code{FIELD_DECL}s that are pointer types that point to ! 305: vtables. See also vtable and vfield. ! 306: @end table ! 307: ! 308: @node Macros, Typical Behavior, Glossary, Top ! 309: @section Macros ! 310: ! 311: This section describes some of the macros used on trees. The list ! 312: should be alphabetical. Eventually all macros should be documented ! 313: here. There are some postscript drawings that can be used to better ! 314: understnad from of the more complex data structures, contact Mike Stump ! 315: (@code{mrs@@cygnus.com}) for information about them. ! 316: ! 317: @table @code ! 318: @item BINFO_BASETYPES ! 319: A vector of additional binfos for the types inherited by this basetype. ! 320: The binfos are fully unshared (except for virtual bases, in which ! 321: case the binfo structure is shared). ! 322: ! 323: If this basetype describes type D as inherited in C, ! 324: and if the basetypes of D are E anf F, ! 325: then this vector contains binfos for inheritance of E and F by C. ! 326: ! 327: Has values of: ! 328: ! 329: TREE_VECs ! 330: ! 331: ! 332: @item BINFO_INHERITANCE_CHAIN ! 333: Temporarily used to represent specific inheritances. It usually points ! 334: to the binfo associated with the lesser derived type, but it can be ! 335: reversed by reverse_path. For example: ! 336: ! 337: @example ! 338: Z ZbY least derived ! 339: | ! 340: Y YbX ! 341: | ! 342: X Xb most derived ! 343: ! 344: TYPE_BINFO (X) == Xb ! 345: BINFO_INHERITANCE_CHAIN (Xb) == YbX ! 346: BINFO_INHERITANCE_CHAIN (Yb) == ZbY ! 347: BINFO_INHERITANCE_CHAIN (Zb) == 0 ! 348: @end example ! 349: ! 350: Not sure is the above is really true, get_base_distance has is point ! 351: towards the most derived type, opposite from above. ! 352: ! 353: Set by build_vbase_path, recursive_bounded_basetype_p, ! 354: get_base_distance, lookup_field, lookup_fnfields, and reverse_path. ! 355: ! 356: What things can this be used on: ! 357: ! 358: TREE_VECs that are binfos ! 359: ! 360: ! 361: @item BINFO_OFFSET ! 362: The offset where this basetype appears in its containing type. ! 363: BINFO_OFFSET slot holds the offset (in bytes) from the base of the ! 364: complete object to the base of the part of the object that is allocated ! 365: on behalf of this `type'. This is always 0 except when there is ! 366: multiple inheritance. ! 367: ! 368: Used on TREE_VEC_ELTs of the binfos BINFO_BASETYPES (...) for example. ! 369: ! 370: ! 371: @item BINFO_VIRTUALS ! 372: A unique list of functions for the virtual function table. See also ! 373: TYPE_BINFO_VIRTUALS. ! 374: ! 375: What things can this be used on: ! 376: ! 377: TREE_VECs that are binfos ! 378: ! 379: ! 380: @item BINFO_VTABLE ! 381: Used to find the VAR_DECL that is the virtual function table associated ! 382: with this binfo. See also TYPE_BINFO_VTABLE. To get the virtual ! 383: function table pointer, see CLASSTYPE_VFIELD. ! 384: ! 385: What things can this be used on: ! 386: ! 387: TREE_VECs that are binfos ! 388: ! 389: Has values of: ! 390: ! 391: VAR_DECLs that are virtual function tables ! 392: ! 393: ! 394: @item BLOCK_SUPERCONTEXT ! 395: In the outermost scope of each function, it points to the FUNCTION_DECL ! 396: node. It aids in better DWARF support of inline functions. ! 397: ! 398: ! 399: @item CLASSTYPE_TAGS ! 400: CLASSTYPE_TAGS is a linked (via TREE_CHAIN) list of member classes of a ! 401: class. TREE_PURPOSE is the name, TREE_VALUE is the type (pushclass scans ! 402: these and calls pushtag on them.) ! 403: ! 404: finish_struct scans these to produce TYPE_DECLs to add to the ! 405: TYPE_FIELDS of the type. ! 406: ! 407: It is expected that name found in the TREE_PURPOSE slot is unique, ! 408: resolve_scope_to_name is one such place that depends upon this ! 409: uniqueness. ! 410: ! 411: ! 412: @item CLASSTYPE_METHOD_VEC ! 413: The following is true after finish_struct has been called (on the ! 414: class?) but not before. Before finish_struct is called, things are ! 415: different to some extent. Contains a TREE_VEC of methods of the class. ! 416: The TREE_VEC_LENGTH is the number of differently named methods plus one ! 417: for the 0th entry. The 0th entry is always allocated, and reserved for ! 418: ctors and dtors. If there are none, TREE_VEC_ELT(N,0) == NULL_TREE. ! 419: Each entry of the TREE_VEC is a FUNCTION_DECL. For each FUNCTION_DECL, ! 420: there is a DECL_CHAIN slot. If the FUNCTION_DECL is the last one with a ! 421: given name, the DECL_CHAIN slot is NULL_TREE. Otherwise it is the next ! 422: method that has the same name (but a different signature). It would ! 423: seem that it is not true that because the DECL_CHAIN slot is used in ! 424: this way, we cannot call pushdecl to put the method in the global scope ! 425: (cause that would overwrite the TREE_CHAIN slot), because they use ! 426: different _CHAINs. finish_struct_methods setups up one version of the ! 427: TREE_CHAIN slots on the FUNCTION_DECLs. ! 428: ! 429: friends are kept in TREE_LISTs, so that there's no need to use their ! 430: TREE_CHAIN slot for anything. ! 431: ! 432: Has values of: ! 433: ! 434: TREE_VECs ! 435: ! 436: ! 437: @item CLASSTYPE_VFIELD ! 438: Seems to be in the process of being renamed TYPE_VFIELD. Use on types ! 439: to get the main virtual function table pointer. To get the virtual ! 440: function table use BINFO_VTABLE (TYPE_BINFO ()). ! 441: ! 442: Has values of: ! 443: ! 444: FIELD_DECLs that are virtual function table pointers ! 445: ! 446: What things can this be used on: ! 447: ! 448: RECORD_TYPEs ! 449: ! 450: ! 451: @item DECL_CLASS_CONTEXT ! 452: Identifies the context that the _DECL was found in. For virtual function ! 453: tables, it points to the type associated with the virtual function ! 454: table. See also DECL_CONTEXT, DECL_FIELD_CONTEXT and DECL_FCONTEXT. ! 455: ! 456: The difference between this and DECL_CONTEXT, is that for virtuals ! 457: functions like: ! 458: ! 459: @example ! 460: struct A ! 461: @{ ! 462: virtual int f (); ! 463: @}; ! 464: ! 465: struct B : A ! 466: @{ ! 467: int f (); ! 468: @}; ! 469: ! 470: DECL_CONTEXT (A::f) == A ! 471: DECL_CLASS_CONTEXT (A::f) == A ! 472: ! 473: DECL_CONTEXT (B::f) == A ! 474: DECL_CLASS_CONTEXT (B::f) == B ! 475: @end example ! 476: ! 477: Has values of: ! 478: ! 479: RECORD_TYPEs, or UNION_TYPEs ! 480: ! 481: What things can this be used on: ! 482: ! 483: TYPE_DECLs, _DECLs ! 484: ! 485: ! 486: @item DECL_CONTEXT ! 487: Identifies the context that the _DECL was found in. Can be used on ! 488: virtual function tables to find the type associated with the virtual ! 489: function table, but since they are FIELD_DECLs, DECL_FIELD_CONTEXT is a ! 490: better access method. Internally the same as DECL_FIELD_CONTEXT, so ! 491: don't us both. See also DECL_FIELD_CONTEXT, DECL_FCONTEXT and ! 492: DECL_CLASS_CONTEXT. ! 493: ! 494: Has values of: ! 495: ! 496: RECORD_TYPEs ! 497: ! 498: ! 499: What things can this be used on: ! 500: ! 501: @display ! 502: VAR_DECLs that are virtual function tables ! 503: _DECLs ! 504: @end display ! 505: ! 506: ! 507: @item DECL_FIELD_CONTEXT ! 508: Identifies the context that the FIELD_DECL was found in. Internally the ! 509: same as DECL_CONTEXT, so don't us both. See also DECL_CONTEXT, ! 510: DECL_FCONTEXT and DECL_CLASS_CONTEXT. ! 511: ! 512: Has values of: ! 513: ! 514: RECORD_TYPEs ! 515: ! 516: What things can this be used on: ! 517: ! 518: @display ! 519: FIELD_DECLs that are virtual function pointers ! 520: FIELD_DECLs ! 521: @end display ! 522: ! 523: ! 524: @item DECL_NESTED_TYPENAME ! 525: Holds the fully qualified type name. Example, Base::Derived. ! 526: ! 527: Has values of: ! 528: ! 529: IDENTIFIER_NODEs ! 530: ! 531: What things can this be used on: ! 532: ! 533: TYPE_DECLs ! 534: ! 535: ! 536: @item DECL_NAME ! 537: ! 538: Has values of: ! 539: ! 540: @display ! 541: 0 for things that don't have names ! 542: IDENTIFIER_NODEs for TYPE_DECLs ! 543: @end display ! 544: ! 545: @item DECL_IGNORED_P ! 546: A bit that can be set to inform the debug information output routines in ! 547: the back-end that a certain _DECL node should be totally ignored. ! 548: ! 549: Used in cases where it is known that the debugging information will be ! 550: output in another file, or where a sub-type is known not to be needed ! 551: because the enclosing type is not needed. ! 552: ! 553: A compiler constructed virtual destructor in derived classes that do not ! 554: define an exlicit destructor that was defined exlicit in a base class ! 555: has this bit set as well. Also used on __FUNCTION__ and ! 556: __PRETTY_FUNCTION__ to mark they are ``compiler generated.'' c-decl and ! 557: c-lex.c both want DECL_IGNORED_P set for ``internally generated vars,'' ! 558: and ``user-invisible variable.'' ! 559: ! 560: Functions built by the C++ front-end such as default destructors, ! 561: virtual desctructors and default constructors want to be marked that ! 562: they are compiler generated, but unsure why. ! 563: ! 564: Currently, it is used in an absolute way in the C++ front-end, as an ! 565: optimization, to tell the debug information output routines to not ! 566: generate debugging information that will be output by another separately ! 567: compiled file. ! 568: ! 569: ! 570: @item DECL_VIRTUAL_P ! 571: A flag used on FIELD_DECLs and VAR_DECLs. (Documentation in tree.h is ! 572: wrong.) Used in VAR_DECLs to indicate that the variable is a vtable. ! 573: It is also used in FIELD_DECLs for vtable pointers. ! 574: ! 575: What things can this be used on: ! 576: ! 577: FIELD_DECLs and VAR_DECLs ! 578: ! 579: ! 580: @item DECL_VPARENT ! 581: Used to point to the parent type of the vtable if there is one, else it ! 582: is just the type associated with the vtable. Because of the sharing of ! 583: virtual function tables that goes on, this slot is not very useful, and ! 584: is in fact, not used in the compiler at all. It can be removed. ! 585: ! 586: What things can this be used on: ! 587: ! 588: VAR_DECLs that are virtual function tables ! 589: ! 590: Has values of: ! 591: ! 592: RECORD_TYPEs maybe UNION_TYPEs ! 593: ! 594: ! 595: @item DECL_FCONTEXT ! 596: Used to find the first baseclass in which this FIELD_DECL is defined. ! 597: See also DECL_CONTEXT, DECL_FIELD_CONTEXT and DECL_CLASS_CONTEXT. ! 598: ! 599: How it is used: ! 600: ! 601: Used when writing out debugging information about vfield and ! 602: vbase decls. ! 603: ! 604: What things can this be used on: ! 605: ! 606: FIELD_DECLs that are virtual function pointers ! 607: FIELD_DECLs ! 608: ! 609: ! 610: @item DECL_REFERENCE_SLOT ! 611: Used to hold the initialize for the reference. ! 612: ! 613: What things can this be used on: ! 614: ! 615: PARM_DECLs and VAR_DECLs that have a reference type ! 616: ! 617: ! 618: @item DECL_VINDEX ! 619: Used for FUNCTION_DECLs in two different ways. Before the structure ! 620: containing the FUNCTION_DECL is laid out, DECL_VINDEX may point to a ! 621: FUNCTION_DECL in a base class which is the FUNCTION_DECL which this ! 622: FUNCTION_DECL will replace as a virtual function. When the class is ! 623: laid out, this pointer is changed to an INTEGER_CST node which is ! 624: suitable to find an index into the virtual function table. See ! 625: get_vtable_entry as to how one can find the right index into the virtual ! 626: function table. The first index 0, of a virtual function table it not ! 627: used in the normal way, so the first real index is 1. ! 628: ! 629: DECL_VINDEX may be a TREE_LIST, that would seem to be a list of ! 630: overridden FUNCTION_DECLs. add_virtual_function has code to deal with ! 631: this when it uses the variable base_fndecl_list, but it would seem that ! 632: somehow, it is possible for the TREE_LIST to pursist until method_call, ! 633: and it should not. ! 634: ! 635: ! 636: What things can this be used on: ! 637: ! 638: FUNCTION_DECLs ! 639: ! 640: ! 641: @item DECL_SOURCE_FILE ! 642: Identifies what source file a particular declaration was found in. ! 643: ! 644: Has values of: ! 645: ! 646: "<built-in>" on TYPE_DECLs to mean the typedef is built in ! 647: ! 648: ! 649: @item DECL_SOURCE_LINE ! 650: Identifies what source line number in the source file the declaration ! 651: was found at. ! 652: ! 653: Has values of: ! 654: ! 655: @display ! 656: 0 for an undefined label ! 657: ! 658: 0 for TYPE_DECLs that are internally generated ! 659: ! 660: 0 for FUNCTION_DECLs for functions generated by the compiler ! 661: (not yet, but should be) ! 662: ! 663: 0 for ``magic'' arguments to functions, that the user has no ! 664: control over ! 665: @end display ! 666: ! 667: ! 668: @item TREE_USED ! 669: ! 670: Has values of: ! 671: ! 672: 0 for unused labels ! 673: ! 674: ! 675: @item TREE_ADDRESSABLE ! 676: A flag that is set for any type that has a constructor. ! 677: ! 678: ! 679: @item TREE_COMPLEXITY ! 680: They seem a kludge way to track recursion, poping, and pushing. They only ! 681: appear in cp-decl.c and cp-decl2.c, so the are a good candidate for ! 682: proper fixing, and removal. ! 683: ! 684: ! 685: @item TREE_PRIVATE ! 686: Set for FIELD_DECLs by finish_struct. But not uniformly set. ! 687: ! 688: The following routines do something with PRIVATE access: ! 689: build_method_call, alter_access, finish_struct_methods, ! 690: finish_struct, convert_to_aggr, CWriteLanguageDecl, CWriteLanguageType, ! 691: CWriteUseObject, compute_access, lookup_field, dfs_pushdecl, ! 692: GNU_xref_member, dbxout_type_fields, dbxout_type_method_1 ! 693: ! 694: ! 695: @item TREE_PROTECTED ! 696: The following routines do something with PROTECTED access: ! 697: build_method_call, alter_access, finish_struct, convert_to_aggr, ! 698: CWriteLanguageDecl, CWriteLanguageType, CWriteUseObject, ! 699: compute_access, lookup_field, GNU_xref_member, dbxout_type_fields, ! 700: dbxout_type_method_1 ! 701: ! 702: ! 703: @item TYPE_BINFO ! 704: Used to get the binfo for the type. ! 705: ! 706: Has values of: ! 707: ! 708: TREE_VECs that are binfos ! 709: ! 710: What things can this be used on: ! 711: ! 712: RECORD_TYPEs ! 713: ! 714: ! 715: @item TYPE_BINFO_BASETYPES ! 716: See also BINFO_BASETYPES. ! 717: ! 718: @item TYPE_BINFO_VIRTUALS ! 719: A unique list of functions for the virtual function table. See also ! 720: BINFO_VIRTUALS. ! 721: ! 722: What things can this be used on: ! 723: ! 724: RECORD_TYPEs ! 725: ! 726: ! 727: @item TYPE_BINFO_VTABLE ! 728: Points to the virtual function table associated with the given type. ! 729: See also BINFO_VTABLE. ! 730: ! 731: What things can this be used on: ! 732: ! 733: RECORD_TYPEs ! 734: ! 735: Has values of: ! 736: ! 737: VAR_DECLs that are virtual function tables ! 738: ! 739: ! 740: @item TYPE_NAME ! 741: Names the type. ! 742: ! 743: Has values of: ! 744: ! 745: @display ! 746: 0 for things that don't have names. ! 747: should be IDENTIFIER_NODE for RECORD_TYPEs UNION_TYPEs and ! 748: ENUM_TYPEs. ! 749: TYPE_DECL for RECORD_TYPEs, UNION_TYPEs and ENUM_TYPEs, but ! 750: shouldn't be. ! 751: TYPE_DECL for typedefs, unsure why. ! 752: @end display ! 753: ! 754: What things can one use this on: ! 755: ! 756: @display ! 757: TYPE_DECLs ! 758: RECORD_TYPEs ! 759: UNION_TYPEs ! 760: ENUM_TYPEs ! 761: @end display ! 762: ! 763: History: ! 764: ! 765: It currently points to the TYPE_DECL for RECORD_TYPEs, ! 766: UNION_TYPEs and ENUM_TYPEs, but it should be history soon. ! 767: ! 768: ! 769: @item TYPE_METHODS ! 770: Synonym for @code{CLASSTYPE_METHOD_VEC}. Chained together with ! 771: @code{TREE_CHAIN}. @file{dbxout.c} uses this to get at the methods of a ! 772: class. ! 773: ! 774: ! 775: @item TYPE_DECL ! 776: Used to represent typedefs, and used to represent bindings layers. ! 777: ! 778: Components: ! 779: ! 780: DECL_NAME is the name of the typedef. For example, foo would ! 781: be found in the DECL_NAME slot when @code{typedef int foo;} is ! 782: seen. ! 783: ! 784: DECL_SOURCE_LINE identifies what source line number in the ! 785: source file the declaration was found at. A value of 0 ! 786: indicates that this TYPE_DECL is just an internal binding layer ! 787: marker, and does not correspond to a user suppiled typedef. ! 788: ! 789: DECL_SOURCE_FILE ! 790: ! 791: @item TYPE_FIELDS ! 792: A linked list (via @code{TREE_CHAIN}) of member types of a class. The ! 793: list can contain @code{TYPE_DECL}s, but there can also be other things ! 794: in the list apparently. See also @code{CLASSTYPE_TAGS}. ! 795: ! 796: ! 797: @item TYPE_VIRTUAL_P ! 798: A flag used on a @code{FIELD_DECL} or a @code{VAR_DECL}, indicates it is ! 799: a virtual function table or a pointer to one. When used on a ! 800: @code{FUNCTION_DECL}, indicates that it is a virtual function. When ! 801: used on an @code{IDENTIFIER_NODE}, indicates that a function with this ! 802: same name exists and has been declared virtual. ! 803: ! 804: When used on types, it indicates that the type has virtual functions, or ! 805: is derived from one that does. ! 806: ! 807: Not sure if the above about virtual function tables is still true. See ! 808: also info on @code{DECL_VIRTUAL_P}. ! 809: ! 810: What things can this be used on: ! 811: ! 812: FIELD_DECLs, VAR_DECLs, FUNCTION_DECLs, IDENTIFIER_NODEs ! 813: ! 814: ! 815: @item VF_BASETYPE_VALUE ! 816: Get the associated type from the binfo that caused the given vfield to ! 817: exist. This is the least derived class (the most parent class) that ! 818: needed a virtual function table. It is probably the case that all uses ! 819: of this field are misguided, but they need to be examined on a ! 820: case-by-case basis. See history for more information on why the ! 821: previous statement was made. ! 822: ! 823: Set at @code{finish_base_struct} time. ! 824: ! 825: What things can this be used on: ! 826: ! 827: TREE_LISTs that are vfields ! 828: ! 829: History: ! 830: ! 831: This field was used to determine if a virtual function table's ! 832: slot should be filled in with a certain virtual function, by ! 833: checking to see if the type returned by VF_BASETYPE_VALUE was a ! 834: parent of the context in which the old virtual function existed. ! 835: This incorrectly assumes that a given type _could_ not appear as ! 836: a parent twice in a given inheritance lattice. For single ! 837: inheritance, this would in fact work, because a type could not ! 838: possibly appear more than once in an inheritance lattice, but ! 839: with multiple inheritance, a type can appear more than once. ! 840: ! 841: ! 842: @item VF_BINFO_VALUE ! 843: Identifies the binfo that caused this vfield to exist. If this vfield ! 844: is from the first direct base class that has a virtual function table, ! 845: then VF_BINFO_VALUE is NULL_TREE, otherwise it will be the binfo of the ! 846: direct base where the vfield came from. Can use @code{TREE_VIA_VIRTUAL} ! 847: on result to find out if it is a virtual base class. Related to the ! 848: binfo found by ! 849: ! 850: @example ! 851: get_binfo (VF_BASETYPE_VALUE (vfield), t, 0) ! 852: @end example ! 853: ! 854: @noindent ! 855: where @samp{t} is the type that has the given vfield. ! 856: ! 857: @example ! 858: get_binfo (VF_BASETYPE_VALUE (vfield), t, 0) ! 859: @end example ! 860: ! 861: @noindent ! 862: will return the binfo for the the given vfield. ! 863: ! 864: May or may not be set at @code{modify_vtable_entries} time. Set at ! 865: @code{finish_base_struct} time. ! 866: ! 867: What things can this be used on: ! 868: ! 869: TREE_LISTs that are vfields ! 870: ! 871: ! 872: @item VF_DERIVED_VALUE ! 873: Identifies the type of the most derived class of the vfield, excluding ! 874: the the class this vfield is for. ! 875: ! 876: Set at @code{finish_base_struct} time. ! 877: ! 878: What things can this be used on: ! 879: ! 880: TREE_LISTs that are vfields ! 881: ! 882: ! 883: @item VF_NORMAL_VALUE ! 884: Identifies the type of the most derived class of the vfield, including ! 885: the class this vfield is for. ! 886: ! 887: Set at @code{finish_base_struct} time. ! 888: ! 889: What things can this be used on: ! 890: ! 891: TREE_LISTs that are vfields ! 892: ! 893: ! 894: @item WRITABLE_VTABLES ! 895: This is a option that can be defined when building the compiler, that ! 896: will cause the compiler to output vtables into the data segment so that ! 897: the vtables maybe written. This is undefined by default, because ! 898: normally the vtables should be unwritable. People that implement object ! 899: I/O facilities may, or people that want to change the dynamic type of ! 900: objects may want to have the vtables writable. Another way of achieving ! 901: this would be to make a copy of the vtable into writable memory, but the ! 902: drawback there is that that method only changes the type for one object. ! 903: ! 904: @end table ! 905: ! 906: @node Typical Behavior, Coding Conventions, Macros, Top ! 907: @section Typical Behavior ! 908: ! 909: @cindex parse errors ! 910: ! 911: Whenever seemingly normal code fails with errors like ! 912: @code{syntax error at `\@{'}, it's highly likely that grokdeclarator is ! 913: returning a NULL_TREE for whatever reason. ! 914: ! 915: @node Coding Conventions, Templates, Typical Behavior, Top ! 916: @section Coding Conventions ! 917: ! 918: It should never be that case that trees are modified in-place by the ! 919: back-end, @emph{unless} it is guaranteed that the semantics are the same ! 920: no matter how shared the tree structure is. @file{fold-const.c} still ! 921: has some cases where this is not true, but rms hypothesizes that this ! 922: will never be a problem. ! 923: ! 924: @node Templates, Access Control, Coding Conventions, Top ! 925: @section Templates ! 926: ! 927: g++ uses the simple approach to instantiating templates: it blindly ! 928: generates the code for each instantiation as needed. For class ! 929: templates, g++ pushes the template parameters into the namespace for the ! 930: duration of the instantiation; for function templates, it's a simple ! 931: search and replace. ! 932: ! 933: This approach does not support any of the template definition-time error ! 934: checking that is being bandied about by X3J16. It makes no attempt to deal ! 935: with name binding in a consistent way. ! 936: ! 937: Instantiation of a class template is triggered by the use of a template ! 938: class anywhere but in a straight declaration like @code{class A<int>}. ! 939: This is wrong; in fact, it should not be triggered by typedefs or ! 940: declarations of pointers. Now that explicit instantiation is supported, ! 941: this misfeature is not necessary. ! 942: ! 943: Important functions: ! 944: ! 945: @table @code ! 946: @item instantiate_class_template ! 947: This function ! 948: @end table ! 949: ! 950: @node Access Control, Error Reporting, Templates, Top ! 951: @section Access Control ! 952: The function compute_access returns one of three values: ! 953: ! 954: @table @code ! 955: @item access_public ! 956: means that the field can be accessed by the current lexical scope. ! 957: ! 958: @item access_protected ! 959: means that the field cannot be accessed by the current lexical scope ! 960: because it is protected. ! 961: ! 962: @item access_private ! 963: means that the field cannot be accessed by the current lexical scope ! 964: because it is private. ! 965: @end table ! 966: ! 967: DECL_ACCESS is used for access declarations; alter_access creates a list ! 968: of types and accesses for a given decl. ! 969: ! 970: Formerly, DECL_@{PUBLIC,PROTECTED,PRIVATE@} corresponded to the return ! 971: codes of compute_access and were used as a cache for compute_access. ! 972: Now they are not used at all. ! 973: ! 974: TREE_PROTECTED and TREE_PRIVATE are used to record the access levels ! 975: granted by the containing class. BEWARE: TREE_PUBLIC means something ! 976: completely unrelated to access control! ! 977: ! 978: @node Error Reporting, Parser, Access Control, Top ! 979: @section Error Reporting ! 980: ! 981: The C++ front-end uses a call-back mechanism to allow functions to print ! 982: out reasonable strings for types and functions without putting extra ! 983: logic in the functions where errors are found. The interface is through ! 984: the @code{cp_error} function (or @code{cp_warning}, etc.). The ! 985: syntax is exactly like that of @code{error}, except that a few more ! 986: conversions are supported: ! 987: ! 988: @itemize @bullet ! 989: @item ! 990: %C indicates a value of `enum tree_code'. ! 991: @item ! 992: %D indicates a *_DECL node. ! 993: @item ! 994: %E indicates a *_EXPR node. ! 995: @item ! 996: %L indicates a value of `enum languages'. ! 997: @item ! 998: %P indicates the name of a parameter (i.e. "this", "1", "2", ...) ! 999: @item ! 1000: %T indicates a *_TYPE node. ! 1001: @item ! 1002: %O indicates the name of an operator (MODIFY_EXPR -> "operator ="). ! 1003: ! 1004: @end itemize ! 1005: ! 1006: There is some overlap between these; for instance, any of the node ! 1007: options can be used for printing an identifier (though only @code{%D} ! 1008: tries to decipher function names). ! 1009: ! 1010: For a more verbose message (@code{class foo} as opposed to just @code{foo}, ! 1011: including the return type for functions), use @code{%#c}. ! 1012: To have the line number on the error message indicate the line of the ! 1013: DECL, use @code{cp_error_at} and its ilk; to indicate which argument you want, ! 1014: use @code{%+D}, or it will default to the first. ! 1015: ! 1016: @node Parser, Copying Objects, Error Reporting, Top ! 1017: @section Parser ! 1018: ! 1019: Some comments on the parser: ! 1020: ! 1021: The @code{after_type_declarator} / @code{notype_declarator} hack is ! 1022: necessary in order to allow redeclarations of @code{TYPENAME}s, for ! 1023: instance ! 1024: ! 1025: @example ! 1026: typedef int foo; ! 1027: class A @{ ! 1028: char *foo; ! 1029: @}; ! 1030: @end example ! 1031: ! 1032: In the above, the first @code{foo} is parsed as a @code{notype_declarator}, ! 1033: and the second as a @code{after_type_declarator}. ! 1034: ! 1035: Ambiguities: ! 1036: ! 1037: There are currently four reduce/reduce ambiguities in the parser. They are: ! 1038: ! 1039: 1) Between @code{template_parm} and ! 1040: @code{named_class_head_sans_basetype}, for the tokens @code{aggr ! 1041: identifier}. This situation occurs in code looking like ! 1042: ! 1043: @example ! 1044: template <class T> class A @{ @}; ! 1045: @end example ! 1046: ! 1047: It is ambiguous whether @code{class T} should be parsed as the ! 1048: declaration of a template type parameter named @code{T} or an unnamed ! 1049: constant parameter of type @code{class T}. Section 14.6, paragraph 3 of ! 1050: the January '94 working paper states that the first interpretation is ! 1051: the correct one. This ambiguity results in two reduce/reduce conflicts. ! 1052: ! 1053: 2) Between @code{primary} and @code{type_id} for code like @samp{int()} ! 1054: in places where both can be accepted, such as the argument to ! 1055: @code{sizeof}. Section 8.1 of the pre-San Diego working paper specifies ! 1056: that these ambiguous constructs will be interpreted as @code{typename}s. ! 1057: This ambiguity results in six reduce/reduce conflicts between ! 1058: @samp{absdcl} and @samp{functional_cast}. ! 1059: ! 1060: 3) Between @code{functional_cast} and ! 1061: @code{complex_direct_notype_declarator}, for various token strings. ! 1062: This situation occurs in code looking like ! 1063: ! 1064: @example ! 1065: int (*a); ! 1066: @end example ! 1067: ! 1068: This code is ambiguous; it could be a declaration of the variable ! 1069: @samp{a} as a pointer to @samp{int}, or it could be a functional cast of ! 1070: @samp{*a} to @samp{int}. Section 6.8 specifies that the former ! 1071: interpretation is correct. This ambiguity results in 7 reduce/reduce ! 1072: conflicts. Another aspect of this ambiguity is code like 'int (x[2]);', ! 1073: which is resolved at the '[' and accounts for 6 reduce/reduce conflicts ! 1074: between @samp{direct_notype_declarator} and ! 1075: @samp{primary}/@samp{overqualified_id}. Finally, there are 4 r/r ! 1076: conflicts between @samp{expr_or_declarator} and @samp{primary} over code ! 1077: like 'int (a);', which could probably be resolved but would also ! 1078: probably be more trouble than it's worth. In all, this situation ! 1079: accounts for 17 conflicts. Ack! ! 1080: ! 1081: The second case above is responsible for the failure to parse 'LinppFile ! 1082: ppfile (String (argv[1]), &outs, argc, argv);' (from Rogue Wave ! 1083: Math.h++) as an object declaration, and must be fixed so that it does ! 1084: not resolve until later. ! 1085: ! 1086: 4) Indirectly between @code{after_type_declarator} and @code{parm}, for ! 1087: type names. This occurs in (as one example) code like ! 1088: ! 1089: @example ! 1090: typedef int foo, bar; ! 1091: class A @{ ! 1092: foo (bar); ! 1093: @}; ! 1094: @end example ! 1095: ! 1096: What is @code{bar} inside the class definition? We currently interpret ! 1097: it as a @code{parm}, as does Cfront, but IBM xlC interprets it as an ! 1098: @code{after_type_declarator}. I believe that xlC is correct, in light ! 1099: of 7.1p2, which says "The longest sequence of @i{decl-specifiers} that ! 1100: could possibly be a type name is taken as the @i{decl-specifier-seq} of ! 1101: a @i{declaration}." However, it seems clear that this rule must be ! 1102: violated in the case of constructors. This ambiguity accounts for 8 ! 1103: conflicts. ! 1104: ! 1105: Unlike the others, this ambiguity is not recognized by the Working Paper. ! 1106: ! 1107: @node Copying Objects, Exception Handling, Parser, Top ! 1108: @section Copying Objects ! 1109: ! 1110: The generated copy assignment operator in g++ does not currently do the ! 1111: right thing for multiple inheritance involving virtual bases; it just ! 1112: calls the copy assignment operators for its direct bases. What it ! 1113: should probably do is: ! 1114: ! 1115: 1) Split up the copy assignment operator for all classes that have ! 1116: vbases into "copy my vbases" and "copy everything else" parts. Or do ! 1117: the trickiness that the constructors do to ensure that vbases don't get ! 1118: initialized by intermediate bases. ! 1119: ! 1120: 2) Wander through the class lattice, find all vbases for which no ! 1121: intermediate base has a user-defined copy assignment operator, and call ! 1122: their "copy everything else" routines. If not all of my vbases satisfy ! 1123: this criterion, warn, because this may be surprising behavior. ! 1124: ! 1125: 3) Call the "copy everything else" routine for my direct bases. ! 1126: ! 1127: If we only have one direct base, we can just foist everything off onto ! 1128: them. ! 1129: ! 1130: This issue is currently under discussion in the core reflector ! 1131: (2/28/94). ! 1132: ! 1133: @node Exception Handling, Free Store, Copying Objects, Top ! 1134: @section Exception Handling ! 1135: ! 1136: Note, exception handling in g++ is still under development. ! 1137: ! 1138: This section describes the mapping of C++ exceptions in the C++ ! 1139: front-end, into the back-end exception handling framework. ! 1140: ! 1141: The basic mechanism of exception handling in the back-end is ! 1142: unwind-protect a la elisp. This is a general, robust, and language ! 1143: independent representation for exceptions. ! 1144: ! 1145: The C++ front-end exceptions are mapping into the unwind-protect ! 1146: semantics by the C++ front-end. The mapping is describe below. ! 1147: ! 1148: Objects with RTTI support should use the RTTI information to do mapping ! 1149: and checking. Objects without RTTI, like int and const char *, have to ! 1150: use another means of matching. Currently we use the normal mangling used in ! 1151: building functions names. Int's are "i", const char * is PCc, etc... ! 1152: ! 1153: Unfortunately, the standard allows standard type conversions on throw ! 1154: parameters so they can match catch handlers. This means we need a ! 1155: mechanism to handle type conversion at run time, ICK. I read this part ! 1156: again, and it appears that we only have to be able to do a few of the ! 1157: conversions at run time, so we should be ok. ! 1158: ! 1159: In C++, all cleanups should be protected by exception regions. The ! 1160: region starts just after the reason why the cleanup is created has ! 1161: ended. For example, with an automatic variable, that has a constructor, ! 1162: it would be right after the constructor is run. The region ends just ! 1163: before the finalization is expanded. Since the backend may expand the ! 1164: cleanup multiple times along different paths, once for normal end of the ! 1165: region, once for non-local gotos, once for returns, etc, the backend ! 1166: must take special care to protect the finalization expansion, if the ! 1167: expansion is for any other reason than normal region end, and it is ! 1168: `inline' (it is inside the exception region). The backend can either ! 1169: choose to move them out of line, or it can created an exception region ! 1170: over the finalization to protect it, and in the handler associated with ! 1171: it, it would not run the finalization as it otherwise would have, but ! 1172: rather just rethrow to the outer handler, careful to skip the normal ! 1173: handler for the original region. ! 1174: ! 1175: In Ada, they will use the more runtime intensive approach of having ! 1176: fewer regions, but at the cost of additional work at run time, to keep a ! 1177: list of things that need cleanups. When a variable has finished ! 1178: construction, they add the cleanup to the list, when the come to the end ! 1179: of the lifetime of the variable, the run the list down. If the take a ! 1180: hit before the section finishes normally, they examine the list for ! 1181: actions to perform. I hope they add this logic into the back-end, as it ! 1182: would be nice to get that alternative approach in C++. ! 1183: ! 1184: On an rs6000, xlC stores exception objects on that stack, under the try ! 1185: block. When is unwinds down into a handler, the frame pointer is ! 1186: adjusted back to the normal value for the frame in which the handler ! 1187: resides, and the stack pointer is left unchanged from the time at which ! 1188: the object was throwed. This is so that there is always someplace for ! 1189: the exception object, and nothing can overwrite it, once we start ! 1190: throwing. The only bad part, is that the stack remains large. ! 1191: ! 1192: Flaws in g++'s exception handling. The stack pointer is restored from ! 1193: stack, we want to match rs6000, and propagate the stack pointer from ! 1194: time of throw, down, to the catch place. ! 1195: ! 1196: Only exact type matching of throw types works (references work also), ! 1197: catch variables cannot be used. Only works on a Sun sparc running SunOS ! 1198: 4.1.x. Unwinding to outer catch clauses works. All temps and local ! 1199: variables are cleaned up in all unwinded scopes. Completed parts of ! 1200: partially constructed objects are not cleaned up. Don't expect ! 1201: exception handling to work right if you optimize, in fact the compiler ! 1202: will probably core dump. If two EH regions are the exact same size, the ! 1203: backend cannot tell which one is first. It punts by picking the last ! 1204: one, if they tie. This is usually right. We really should stick in a ! 1205: nop, if they are the same size. ! 1206: ! 1207: If we fall off the end of a series of catch blocks, we return to the ! 1208: flow of control in a normal fasion. But this is wrong, we should ! 1209: rethrow. ! 1210: ! 1211: When we invoke the copy constructor for an exception object because it ! 1212: is passed by value, and if we take a hit (exception) inside the copy ! 1213: constructor someplace, where do we go? I have tentatively choosen to ! 1214: not catch throws by the outer block at the same unwind level, if one ! 1215: exists, but rather to allow the frame to unwind into the next series of ! 1216: handlers, if any. If this is the wrong way to do it, we will need to ! 1217: protect the rest of the handler in some fashion. Maybe just changing ! 1218: the handler's handler to protect the whole series of handlers is the ! 1219: right way to go. ! 1220: ! 1221: The EH object is copied like it should be, if it is passed by value, ! 1222: otherwise we get a reference directly to it. ! 1223: ! 1224: EH objects make it through unwinding, but are subject to being ! 1225: overwritten as they are still past the top of stack. Don't throw ! 1226: automatic objects if this is a problem. ! 1227: ! 1228: Exceptions in catch handlers now go to outer block. ! 1229: ! 1230: @node Free Store, Concept Index, Exception Handling, Top ! 1231: @section Free Store ! 1232: ! 1233: operator new [] adds a magic cookie to the beginning of arrays for which ! 1234: the number of elements will be needed by operator delete []. These are ! 1235: arrays of objects with destructors and arrays of objects that define ! 1236: operator delete [] with the optional size_t argument. This cookie can ! 1237: be examined from a program as follows: ! 1238: ! 1239: @example ! 1240: typedef unsigned long size_t; ! 1241: extern "C" int printf (const char *, ...); ! 1242: ! 1243: size_t nelts (void *p) ! 1244: @{ ! 1245: struct cookie @{ ! 1246: size_t nelts __attribute__ ((aligned (sizeof (double)))); ! 1247: @}; ! 1248: ! 1249: cookie *cp = (cookie *)p; ! 1250: --cp; ! 1251: ! 1252: return cp->nelts; ! 1253: @} ! 1254: ! 1255: struct A @{ ! 1256: ~A() @{ @} ! 1257: @}; ! 1258: ! 1259: main() ! 1260: @{ ! 1261: A *ap = new A[3]; ! 1262: printf ("%ld\n", nelts (ap)); ! 1263: @} ! 1264: @end example ! 1265: ! 1266: @node Concept Index, , Free Store, Top ! 1267: @section Concept Index ! 1268: ! 1269: @printindex cp ! 1270: ! 1271: @bye
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.