1 \input texinfo @c -*-texinfo-*-
3 @setfilename g++int.info
4 @settitle G++ internals
8 @node Top, Limitations of g++, (dir), (dir)
9 @chapter Internal Architecture of the Compiler
11 This is meant to describe the C++ frontend for gcc in detail.
12 Questions and comments to mrs@@cygnus.com.
15 * Limitations of g++::
17 * Implementation Specifics::
21 * Coding Conventions::
30 @node Limitations of g++, Routines, Top, Top
31 @section Limitations of g++
35 Limitations on input source code: 240 nesting levels with the parser
36 stacksize (YYSTACKSIZE) set to 500 (the default), and requires around
37 16.4k swap space per nesting level. The parser needs about 2.09 *
38 number of nesting levels worth of stackspace.
40 @cindex pushdecl_class_level
42 I suspect there are other uses of pushdecl_class_level that do not call
43 set_identifier_type_value in tandem with the call to
44 pushdecl_class_level. It would seem to be an omission.
46 @cindex delete, two argument
48 For two argument delete, the second argument is always calculated by
49 ``virtual_size ='' in the source. It currently has a problem, in that
50 object size is not calculated by the virtual destructor and passed back
51 for the second parameter to delete. Destructors need to return a value
52 just like constructors. ANSI C++ Jun 5 92 wp 12.5.6
54 The second argument is magically deleted in build_method_call, if it is
55 not used. It needs to be deleted for global operator delete also.
57 @cindex access checking
59 Access checking in general is unimplemented, there are a few cases
60 where it is implemented. grok_enum_decls should be used in more places
61 to do access checking, but this is only the tip of a bigger problem.
63 @cindex @code{volatile}
65 @code{volatile} is not implemented in general.
67 @cindex pointers to members
69 Pointers to members are only minimally supported, and there are places
70 where the grammar doesn't even properly accept them yet.
72 @cindex multiple inheritance
74 @code{this} will be wrong in virtual members functions defined in a
75 virtual base class, when they are overridden in a derived class, when
76 called via a non-left most object.
81 extern "C" int printf(const char*, ...);
82 struct A @{ virtual void f() @{ @} @};
83 struct B : virtual A @{ int b; B() : b(0) @{@} void f() @{ b++; @} @};
92 printf ("C::b = %d, D::b = %d\n", e.C::b, e.D::b);
97 This will print out 2, 0, instead of 1,1.
101 @node Routines, Implementation Specifics, Limitations of g++, Top
104 This section describes some of the routines used in the C++ front-end.
106 @code{build_vtable} and @code{prepare_fresh_vtable} is used only within
107 the @file{cp-class.c} file, and only in @code{finish_struct} and
108 @code{modify_vtable_entries}.
110 @code{build_vtable}, @code{prepare_fresh_vtable}, and
111 @code{finish_struct} are the only routines that set @code{DECL_VPARENT}.
113 @code{finish_struct} can steal the virtual function table from parents,
114 this prohibits related_vslot from working. When finish_struct steals,
118 get_binfo (DECL_FIELD_CONTEXT (CLASSTYPE_VFIELD (t)), t, 0)
122 will get the related binfo.
124 @code{layout_basetypes} does something with the VIRTUALS.
126 Supposedly (according to Tiemann) most of the breadth first searching
127 done, like in @code{get_base_distance} and in @code{get_binfo} was not
128 because of any design decision. I have since found out the at least one
129 part of the compiler needs the notion of depth first binfo searching, I
130 am going to try and convert the whole thing, it should just work. The
131 term left-most refers to the depth first left-most node. It uses
132 @code{MAIN_VARIANT == type} as the condition to get left-most, because
133 the things that have @code{BINFO_OFFSET}s of zero are shared and will
134 have themselves as their own @code{MAIN_VARIANT}s. The non-shared right
135 ones, are copies of the left-most one, hence if it is its own
136 @code{MAIN_VARIENT}, we know it IS a left-most one, if it is not, it is
139 @code{get_base_distance}'s path and distance matters in its use in:
143 @code{prepare_fresh_vtable} (the code is probably wrong)
145 @code{init_vfields} Depends upon distance probably in a safe way,
146 build_offset_ref might use partial paths to do further lookups,
147 hack_identifier is probably not properly checking access.
150 @code{get_first_matching_virtual} probably should check for
151 @code{get_base_distance} returning -2.
154 @code{resolve_offset_ref} should be called in a more deterministic
155 manner. Right now, it is called in some random contexts, like for
156 arguments at @code{build_method_call} time, @code{default_conversion}
157 time, @code{convert_arguments} time, @code{build_unary_op} time,
158 @code{build_c_cast} time, @code{build_modify_expr} time,
159 @code{convert_for_assignment} time, and
160 @code{convert_for_initialization} time.
162 But, there are still more contexts it needs to be called in, one was the
170 Seems that the problems were due to the fact that @code{TREE_TYPE} of
171 the @code{OFFSET_REF} was not a @code{OFFSET_TYPE}, but rather the type
172 of the referent (like @code{INTEGER_TYPE}). This problem was fixed by
173 changing @code{default_conversion} to check @code{TREE_CODE (x)},
174 instead of only checking @code{TREE_CODE (TREE_TYPE (x))} to see if it
175 was @code{OFFSET_TYPE}.
179 @node Implementation Specifics, Glossary, Routines, Top
180 @section Implementation Specifics
183 @item Explicit Initialization
185 The global list @code{current_member_init_list} contains the list of
186 mem-initializers specified in a constructor declaration. For example:
189 foo::foo() : a(1), b(2) @{@}
193 will initialize @samp{a} with 1 and @samp{b} with 2.
194 @code{expand_member_init} places each initialization (a with 1) on the
195 global list. Then, when the fndecl is being processed,
196 @code{emit_base_init} runs down the list, initializing them. It used to
197 be the case that g++ first ran down @code{current_member_init_list},
198 then ran down the list of members initializing the ones that weren't
199 explicitly initialized. Things were rewritten to perform the
200 initializations in order of declaration in the class. So, for the above
201 example, @samp{a} and @samp{b} will be initialized in the order that
205 class foo @{ public: int b; int a; foo (); @};
209 Thus, @samp{b} will be initialized with 2 first, then @samp{a} will be
210 initialized with 1, regardless of how they're listed in the mem-initializer.
212 @item Argument Matching
214 In early 1993, the argument matching scheme in @sc{gnu} C++ changed
215 significantly. The original code was completely replaced with a new
216 method that will, hopefully, be easier to understand and make fixing
217 specific cases much easier.
219 The @samp{-fansi-overloading} option is used to enable the new code; at
220 some point in the future, it will become the default behavior of the
223 The file @file{cp-call.c} contains all of the new work, in the functions
224 @code{rank_for_overload}, @code{compute_harshness},
225 @code{compute_conversion_costs}, and @code{ideal_candidate}.
227 Instead of using obscure numerical values, the quality of an argument
228 match is now represented by clear, individual codes. The new data
229 structure @code{struct harshness} (it used to be an @code{unsigned}
233 @item the @samp{code} field, to signify what was involved in matching two
235 @item the @samp{distance} field, used in situations where inheritance
236 decides which function should be called (one is ``closer'' than
238 @item and the @samp{int_penalty} field, used by some codes as a tie-breaker.
241 The @samp{code} field is a number with a given bit set for each type of
242 code, OR'd together. The new codes are:
245 @item @code{EVIL_CODE}
246 The argument was not a permissible match.
248 @item @code{CONST_CODE}
249 Currently, this is only used by @code{compute_conversion_costs}, to
250 distinguish when a non-@code{const} member function is called from a
251 @code{const} member function.
253 @item @code{ELLIPSIS_CODE}
254 A match against an ellipsis @samp{...} is considered worse than all others.
256 @item @code{USER_CODE}
257 Used for a match involving a user-defined conversion.
259 @item @code{STD_CODE}
260 A match involving a standard conversion.
262 @item @code{PROMO_CODE}
263 A match involving an integral promotion. For these, the
264 @code{int_penalty} field is used to handle the ARM's rule (XXX cite)
265 that a smaller @code{unsigned} type should promote to a @code{int}, not
266 to an @code{unsigned int}.
268 @item @code{QUAL_CODE}
269 Used to mark use of qualifiers like @code{const} and @code{volatile}.
271 @item @code{TRIVIAL_CODE}
272 Used for trivial conversions. The @samp{int_penalty} field is used by
273 @code{convert_harshness} to communicate further penalty information back
274 to @code{build_overload_call_real} when deciding which function should
278 The functions @code{convert_to_aggr} and @code{build_method_call} use
279 @code{compute_conversion_costs} to rate each argument's suitability for
280 a given candidate function (that's how we get the list of candidates for
281 @code{ideal_candidate}).
285 @node Glossary, Macros, Implementation Specifics, Top
290 The main data structure in the compiler used to represent the
291 inheritance relationships between classes. The data in the binfo can be
292 accessed by the BINFO_ accessor macros.
295 @itemx virtual function table
297 The virtual function table holds information used in virtual function
298 dispatching. In the compiler, they are usually referred to as vtables,
299 or vtbls. The first index is not used in the normal way, I believe it
300 is probably used for the virtual destructor.
304 vfields can be thought of as the base information needed to build
305 vtables. For every vtable that exists for a class, there is a vfield.
306 See also vtable and virtual function table pointer. When a type is used
307 as a base class to another type, the virtual function table for the
308 derived class can be based upon the vtable for the base class, just
309 extended to include the additional virtual methods declared in the
310 derived class. The virtual function table from a virtual base class is
311 never reused in a derived class. @code{is_normal} depends upon this.
313 @item virtual function table pointer
315 These are @code{FIELD_DECL}s that are pointer types that point to
316 vtables. See also vtable and vfield.
319 @node Macros, Typical Behavior, Glossary, Top
322 This section describes some of the macros used on trees. The list
323 should be alphabetical. Eventually all macros should be documented
324 here. There are some postscript drawings that can be used to better
325 understnad from of the more complex data structures, contact Mike Stump
326 (@code{mrs@@cygnus.com}) for information about them.
329 @item BINFO_BASETYPES
330 A vector of additional binfos for the types inherited by this basetype.
331 The binfos are fully unshared (except for virtual bases, in which
332 case the binfo structure is shared).
334 If this basetype describes type D as inherited in C,
335 and if the basetypes of D are E anf F,
336 then this vector contains binfos for inheritance of E and F by C.
343 @item BINFO_INHERITANCE_CHAIN
344 Temporarily used to represent specific inheritances. It usually points
345 to the binfo associated with the lesser derived type, but it can be
346 reversed by reverse_path. For example:
356 BINFO_INHERITANCE_CHAIN (Xb) == YbX
357 BINFO_INHERITANCE_CHAIN (Yb) == ZbY
358 BINFO_INHERITANCE_CHAIN (Zb) == 0
361 Not sure is the above is really true, get_base_distance has is point
362 towards the most derived type, opposite from above.
364 Set by build_vbase_path, recursive_bounded_basetype_p,
365 get_base_distance, lookup_field, lookup_fnfields, and reverse_path.
367 What things can this be used on:
369 TREE_VECs that are binfos
373 The offset where this basetype appears in its containing type.
374 BINFO_OFFSET slot holds the offset (in bytes) from the base of the
375 complete object to the base of the part of the object that is allocated
376 on behalf of this `type'. This is always 0 except when there is
377 multiple inheritance.
379 Used on TREE_VEC_ELTs of the binfos BINFO_BASETYPES (...) for example.
383 A unique list of functions for the virtual function table. See also
386 What things can this be used on:
388 TREE_VECs that are binfos
392 Used to find the VAR_DECL that is the virtual function table associated
393 with this binfo. See also TYPE_BINFO_VTABLE. To get the virtual
394 function table pointer, see CLASSTYPE_VFIELD.
396 What things can this be used on:
398 TREE_VECs that are binfos
402 VAR_DECLs that are virtual function tables
405 @item BLOCK_SUPERCONTEXT
406 In the outermost scope of each function, it points to the FUNCTION_DECL
407 node. It aids in better DWARF support of inline functions.
411 CLASSTYPE_TAGS is a linked (via TREE_CHAIN) list of member classes of a
412 class. TREE_PURPOSE is the name, TREE_VALUE is the type (pushclass scans
413 these and calls pushtag on them.)
415 finish_struct scans these to produce TYPE_DECLs to add to the
416 TYPE_FIELDS of the type.
418 It is expected that name found in the TREE_PURPOSE slot is unique,
419 resolve_scope_to_name is one such place that depends upon this
423 @item CLASSTYPE_METHOD_VEC
424 The following is true after finish_struct has been called (on the
425 class?) but not before. Before finish_struct is called, things are
426 different to some extent. Contains a TREE_VEC of methods of the class.
427 The TREE_VEC_LENGTH is the number of differently named methods plus one
428 for the 0th entry. The 0th entry is always allocated, and reserved for
429 ctors and dtors. If there are none, TREE_VEC_ELT(N,0) == NULL_TREE.
430 Each entry of the TREE_VEC is a FUNCTION_DECL. For each FUNCTION_DECL,
431 there is a DECL_CHAIN slot. If the FUNCTION_DECL is the last one with a
432 given name, the DECL_CHAIN slot is NULL_TREE. Otherwise it is the next
433 method that has the same name (but a different signature). It would
434 seem that it is not true that because the DECL_CHAIN slot is used in
435 this way, we cannot call pushdecl to put the method in the global scope
436 (cause that would overwrite the TREE_CHAIN slot), because they use
437 different _CHAINs. finish_struct_methods setups up one version of the
438 TREE_CHAIN slots on the FUNCTION_DECLs.
440 friends are kept in TREE_LISTs, so that there's no need to use their
441 TREE_CHAIN slot for anything.
448 @item CLASSTYPE_VFIELD
449 Seems to be in the process of being renamed TYPE_VFIELD. Use on types
450 to get the main virtual function table pointer. To get the virtual
451 function table use BINFO_VTABLE (TYPE_BINFO ()).
455 FIELD_DECLs that are virtual function table pointers
457 What things can this be used on:
462 @item DECL_CLASS_CONTEXT
463 Identifies the context that the _DECL was found in. For virtual function
464 tables, it points to the type associated with the virtual function
465 table. See also DECL_CONTEXT, DECL_FIELD_CONTEXT and DECL_FCONTEXT.
467 The difference between this and DECL_CONTEXT, is that for virtuals
481 DECL_CONTEXT (A::f) == A
482 DECL_CLASS_CONTEXT (A::f) == A
484 DECL_CONTEXT (B::f) == A
485 DECL_CLASS_CONTEXT (B::f) == B
490 RECORD_TYPEs, or UNION_TYPEs
492 What things can this be used on:
498 Identifies the context that the _DECL was found in. Can be used on
499 virtual function tables to find the type associated with the virtual
500 function table, but since they are FIELD_DECLs, DECL_FIELD_CONTEXT is a
501 better access method. Internally the same as DECL_FIELD_CONTEXT, so
502 don't us both. See also DECL_FIELD_CONTEXT, DECL_FCONTEXT and
510 What things can this be used on:
513 VAR_DECLs that are virtual function tables
518 @item DECL_FIELD_CONTEXT
519 Identifies the context that the FIELD_DECL was found in. Internally the
520 same as DECL_CONTEXT, so don't us both. See also DECL_CONTEXT,
521 DECL_FCONTEXT and DECL_CLASS_CONTEXT.
527 What things can this be used on:
530 FIELD_DECLs that are virtual function pointers
535 @item DECL_NESTED_TYPENAME
536 Holds the fully qualified type name. Example, Base::Derived.
542 What things can this be used on:
552 0 for things that don't have names
553 IDENTIFIER_NODEs for TYPE_DECLs
557 A bit that can be set to inform the debug information output routines in
558 the backend that a certain _DECL node should be totally ignored.
560 Used in cases where it is known that the debugging information will be
561 output in another file, or where a sub-type is known not to be needed
562 because the enclosing type is not needed.
564 A compiler constructed virtual destructor in derived classes that do not
565 define an exlicit destructor that was defined exlicit in a base class
566 has this bit set as well. Also used on __FUNCTION__ and
567 __PRETTY_FUNCTION__ to mark they are ``compiler generated.'' c-decl and
568 c-lex.c both want DECL_IGNORED_P set for ``internally generated vars,''
569 and ``user-invisible variable.''
571 Functions built by the C++ front-end such as default destructors,
572 virtual desctructors and default constructors want to be marked that
573 they are compiler generated, but unsure why.
575 Currently, it is used in an absolute way in the C++ front-end, as an
576 optimization, to tell the debug information output routines to not
577 generate debugging information that will be output by another separately
582 A flag used on FIELD_DECLs and VAR_DECLs. (Documentation in tree.h is
583 wrong.) Used in VAR_DECLs to indicate that the variable is a vtable.
584 It is also used in FIELD_DECLs for vtable pointers.
586 What things can this be used on:
588 FIELD_DECLs and VAR_DECLs
592 Used to point to the parent type of the vtable if there is one, else it
593 is just the type associated with the vtable. Because of the sharing of
594 virtual function tables that goes on, this slot is not very useful, and
595 is in fact, not used in the compiler at all. It can be removed.
597 What things can this be used on:
599 VAR_DECLs that are virtual function tables
603 RECORD_TYPEs maybe UNION_TYPEs
607 Used to find the first baseclass in which this FIELD_DECL is defined.
608 See also DECL_CONTEXT, DECL_FIELD_CONTEXT and DECL_CLASS_CONTEXT.
612 Used when writing out debugging information about vfield and
615 What things can this be used on:
617 FIELD_DECLs that are virtual function pointers
621 @item DECL_REFERENCE_SLOT
622 Used to hold the initialize for the reference.
624 What things can this be used on:
626 PARM_DECLs and VAR_DECLs that have a reference type
630 Used for FUNCTION_DECLs in two different ways. Before the structure
631 containing the FUNCTION_DECL is laid out, DECL_VINDEX may point to a
632 FUNCTION_DECL in a base class which is the FUNCTION_DECL which this
633 FUNCTION_DECL will replace as a virtual function. When the class is
634 laid out, this pointer is changed to an INTEGER_CST node which is
635 suitable to find an index into the virtual function table. See
636 get_vtable_entry as to how one can find the right index into the virtual
637 function table. The first index 0, of a virtual function table it not
638 used in the normal way, so the first real index is 1.
640 DECL_VINDEX may be a TREE_LIST, that would seem to be a list of
641 overridden FUNCTION_DECLs. add_virtual_function has code to deal with
642 this when it uses the variable base_fndecl_list, but it would seem that
643 somehow, it is possible for the TREE_LIST to pursist until method_call,
647 What things can this be used on:
652 @item DECL_SOURCE_FILE
653 Identifies what source file a particular declaration was found in.
657 "<built-in>" on TYPE_DECLs to mean the typedef is built in
660 @item DECL_SOURCE_LINE
661 Identifies what source line number in the source file the declaration
667 0 for an undefined label
669 0 for TYPE_DECLs that are internally generated
671 0 for FUNCTION_DECLs for functions generated by the compiler
672 (not yet, but should be)
674 0 for ``magic'' arguments to functions, that the user has no
686 @item TREE_ADDRESSABLE
687 A flag that is set for any type that has a constructor.
690 @item TREE_COMPLEXITY
691 They seem a kludge way to track recursion, poping, and pushing. They only
692 appear in cp-decl.c and cp-decl2.c, so the are a good candidate for
693 proper fixing, and removal.
697 Set for FIELD_DECLs by finish_struct. But not uniformly set.
699 The following routines do something with PRIVATE access:
700 build_method_call, alter_access, finish_struct_methods,
701 finish_struct, convert_to_aggr, CWriteLanguageDecl, CWriteLanguageType,
702 CWriteUseObject, compute_access, lookup_field, dfs_pushdecl,
703 GNU_xref_member, dbxout_type_fields, dbxout_type_method_1
707 The following routines do something with PROTECTED access:
708 build_method_call, alter_access, finish_struct, convert_to_aggr,
709 CWriteLanguageDecl, CWriteLanguageType, CWriteUseObject,
710 compute_access, lookup_field, GNU_xref_member, dbxout_type_fields,
715 Used to get the binfo for the type.
719 TREE_VECs that are binfos
721 What things can this be used on:
726 @item TYPE_BINFO_BASETYPES
727 See also BINFO_BASETYPES.
729 @item TYPE_BINFO_VIRTUALS
730 A unique list of functions for the virtual function table. See also
733 What things can this be used on:
738 @item TYPE_BINFO_VTABLE
739 Points to the virtual function table associated with the given type.
740 See also BINFO_VTABLE.
742 What things can this be used on:
748 VAR_DECLs that are virtual function tables
757 0 for things that don't have names.
758 should be IDENTIFIER_NODE for RECORD_TYPEs UNION_TYPEs and
760 TYPE_DECL for RECORD_TYPEs, UNION_TYPEs and ENUM_TYPEs, but
762 TYPE_DECL for typedefs, unsure why.
765 What things can one use this on:
776 It currently points to the TYPE_DECL for RECORD_TYPEs,
777 UNION_TYPEs and ENUM_TYPEs, but it should be history soon.
781 Synonym for @code{CLASSTYPE_METHOD_VEC}. Chained together with
782 @code{TREE_CHAIN}. @file{dbxout.c} uses this to get at the methods of a
787 Used to represent typedefs, and used to represent bindings layers.
791 DECL_NAME is the name of the typedef. For example, foo would
792 be found in the DECL_NAME slot when @code{typedef int foo;} is
795 DECL_SOURCE_LINE identifies what source line number in the
796 source file the declaration was found at. A value of 0
797 indicates that this TYPE_DECL is just an internal binding layer
798 marker, and does not correspond to a user suppiled typedef.
803 A linked list (via @code{TREE_CHAIN}) of member types of a class. The
804 list can contain @code{TYPE_DECL}s, but there can also be other things
805 in the list apparently. See also @code{CLASSTYPE_TAGS}.
809 A flag used on a @code{FIELD_DECL} or a @code{VAR_DECL}, indicates it is
810 a virtual function table or a pointer to one. When used on a
811 @code{FUNCTION_DECL}, indicates that it is a virtual function. When
812 used on an @code{IDENTIFIER_NODE}, indicates that a function with this
813 same name exists and has been declared virtual.
815 When used on types, it indicates that the type has virtual functions, or
816 is derived from one that does.
818 Not sure if the above about virtual function tables is still true. See
819 also info on @code{DECL_VIRTUAL_P}.
821 What things can this be used on:
823 FIELD_DECLs, VAR_DECLs, FUNCTION_DECLs, IDENTIFIER_NODEs
826 @item VF_BASETYPE_VALUE
827 Get the associated type from the binfo that caused the given vfield to
828 exist. This is the least derived class (the most parent class) that
829 needed a virtual function table. It is probably the case that all uses
830 of this field are misguided, but they need to be examined on a
831 case-by-case basis. See history for more information on why the
832 previous statement was made.
834 Set at @code{finish_base_struct} time.
836 What things can this be used on:
838 TREE_LISTs that are vfields
842 This field was used to determine if a virtual function table's
843 slot should be filled in with a certain virtual function, by
844 checking to see if the type returned by VF_BASETYPE_VALUE was a
845 parent of the context in which the old virtual function existed.
846 This incorrectly assumes that a given type _could_ not appear as
847 a parent twice in a given inheritance lattice. For single
848 inheritance, this would in fact work, because a type could not
849 possibly appear more than once in an inheritance lattice, but
850 with multiple inheritance, a type can appear more than once.
854 Identifies the binfo that caused this vfield to exist. If this vfield
855 is from the first direct base class that has a virtual function table,
856 then VF_BINFO_VALUE is NULL_TREE, otherwise it will be the binfo of the
857 direct base where the vfield came from. Can use @code{TREE_VIA_VIRTUAL}
858 on result to find out if it is a virtual base class. Related to the
862 get_binfo (VF_BASETYPE_VALUE (vfield), t, 0)
866 where @samp{t} is the type that has the given vfield.
869 get_binfo (VF_BASETYPE_VALUE (vfield), t, 0)
873 will return the binfo for the the given vfield.
875 May or may not be set at @code{modify_vtable_entries} time. Set at
876 @code{finish_base_struct} time.
878 What things can this be used on:
880 TREE_LISTs that are vfields
883 @item VF_DERIVED_VALUE
884 Identifies the type of the most derived class of the vfield, excluding
885 the the class this vfield is for.
887 Set at @code{finish_base_struct} time.
889 What things can this be used on:
891 TREE_LISTs that are vfields
894 @item VF_NORMAL_VALUE
895 Identifies the type of the most derived class of the vfield, including
896 the class this vfield is for.
898 Set at @code{finish_base_struct} time.
900 What things can this be used on:
902 TREE_LISTs that are vfields
905 @item WRITABLE_VTABLES
906 This is a option that can be defined when building the compiler, that
907 will cause the compiler to output vtables into the data segment so that
908 the vtables maybe written. This is undefined by default, because
909 normally the vtables should be unwritable. People that implement object
910 I/O facilities may, or people that want to change the dynamic type of
911 objects may want to have the vtables writable. Another way of achieving
912 this would be to make a copy of the vtable into writable memory, but the
913 drawback there is that that method only changes the type for one object.
917 @node Typical Behavior, Coding Conventions, Macros, Top
918 @section Typical Behavior
922 Whenever seemingly normal code fails with errors like
923 @code{syntax error at `\@{'}, it's highly likely that grokdeclarator is
924 returning a NULL_TREE for whatever reason.
926 @node Coding Conventions, Templates, Typical Behavior, Top
927 @section Coding Conventions
929 It should never be that case that trees are modified in-place by the
930 back-end, @emph{unless} it is guaranteed that the semantics are the same
931 no matter how shared the tree structure is. @file{fold-const.c} still
932 has some cases where this is not true, but rms hypothesizes that this
933 will never be a problem.
935 @node Templates, Access Control, Coding Conventions, Top
938 g++ uses the simple approach to instantiating templates: it blindly
939 generates the code for each instantiation as needed. For class
940 templates, g++ pushes the template parameters into the namespace for the
941 duration of the instantiation; for function templates, it's a simple
944 This approach does not support any of the template definition-time error
945 checking that is being bandied about by X3J16. It makes no attempt to deal
946 with name binding in a consistent way.
948 Instantiation of a class template is triggered by the use of a template
949 class anywhere but in a straight declaration like @code{class A<int>}.
950 This is wrong; in fact, it should not be triggered by typedefs or
951 declarations of pointers. Now that explicit instantiation is supported,
952 this misfeature is not necessary.
957 @item instantiate_class_template
961 @node Access Control, Error Reporting, Templates, Top
962 @section Access Control
963 The function compute_access returns one of three values:
967 means that the field can be accessed by the current lexical scope.
969 @item access_protected
970 means that the field cannot be accessed by the current lexical scope
971 because it is protected.
974 means that the field cannot be accessed by the current lexical scope
975 because it is private.
978 DECL_ACCESS is used for access declarations; alter_access creates a list
979 of types and accesses for a given decl.
981 Formerly, DECL_@{PUBLIC,PROTECTED,PRIVATE@} corresponded to the return
982 codes of compute_access and were used as a cache for compute_access.
983 Now they are not used at all.
985 TREE_PROTECTED and TREE_PRIVATE are used to record the access levels
986 granted by the containing class. BEWARE: TREE_PUBLIC means something
987 completely unrelated to access control!
989 @node Error Reporting, Parser, Access Control, Top
990 @section Error Reporting
992 The C++ frontend uses a call-back mechanism to allow functions to print
993 out reasonable strings for types and functions without putting extra
994 logic in the functions where errors are found. The interface is through
995 the @code{cp_error} function (or @code{cp_warning}, etc.). The
996 syntax is exactly like that of @code{error}, except that a few more
997 conversions are supported:
1001 %C indicates a value of `enum tree_code'.
1003 %D indicates a *_DECL node.
1005 %E indicates a *_EXPR node.
1007 %L indicates a value of `enum languages'.
1009 %P indicates the name of a parameter (i.e. "this", "1", "2", ...)
1011 %T indicates a *_TYPE node.
1013 %O indicates the name of an operator (MODIFY_EXPR -> "operator =").
1017 There is some overlap between these; for instance, any of the node
1018 options can be used for printing an identifier (though only @code{%D}
1019 tries to decipher function names).
1021 For a more verbose message (@code{class foo} as opposed to just @code{foo},
1022 including the return type for functions), use @code{%#c}.
1023 To have the line number on the error message indicate the line of the
1024 DECL, use @code{cp_error_at} and its ilk; to indicate which argument you want,
1025 use @code{%+D}, or it will default to the first.
1027 @node Parser, Copying Objects, Error Reporting, Top
1030 Some comments on the parser:
1032 The @code{after_type_declarator} / @code{notype_declarator} hack is
1033 necessary in order to allow redeclarations of @code{TYPENAME}s, for
1043 In the above, the first @code{foo} is parsed as a @code{notype_declarator},
1044 and the second as a @code{after_type_declarator}.
1048 There are currently four reduce/reduce ambiguities in the parser. They are:
1050 1) Between @code{template_parm} and
1051 @code{named_class_head_sans_basetype}, for the tokens @code{aggr
1052 identifier}. This situation occurs in code looking like
1055 template <class T> class A @{ @};
1058 It is ambiguous whether @code{class T} should be parsed as the
1059 declaration of a template type parameter named @code{T} or an unnamed
1060 constant parameter of type @code{class T}. Section 14.6, paragraph 3 of
1061 the January '94 working paper states that the first interpretation is
1062 the correct one. This ambiguity results in two reduce/reduce conflicts.
1064 2) Between @code{primary} and @code{type_id} for code like @samp{int()}
1065 in places where both can be accepted, such as the argument to
1066 @code{sizeof}. Section 8.1 of the pre-San Diego working paper specifies
1067 that these ambiguous constructs will be interpreted as @code{typename}s.
1068 This ambiguity results in six reduce/reduce conflicts between
1069 @samp{absdcl} and @samp{functional_cast}.
1071 3) Between @code{functional_cast} and
1072 @code{complex_direct_notype_declarator}, for various token strings.
1073 This situation occurs in code looking like
1079 This code is ambiguous; it could be a declaration of the variable
1080 @samp{a} as a pointer to @samp{int}, or it could be a functional cast of
1081 @samp{*a} to @samp{int}. Section 6.8 specifies that the former
1082 interpretation is correct. This ambiguity results in 7 reduce/reduce
1083 conflicts. Another aspect of this ambiguity is code like 'int (x[2]);',
1084 which is resolved at the '[' and accounts for 6 reduce/reduce conflicts
1085 between @samp{direct_notype_declarator} and
1086 @samp{primary}/@samp{overqualified_id}. Finally, there are 4 r/r
1087 conflicts between @samp{expr_or_declarator} and @samp{primary} over code
1088 like 'int (a);', which could probably be resolved but would also
1089 probably be more trouble than it's worth. In all, this situation
1090 accounts for 17 conflicts. Ack!
1092 The second case above is responsible for the failure to parse 'LinppFile
1093 ppfile (String (argv[1]), &outs, argc, argv);' (from Rogue Wave
1094 Math.h++) as an object declaration, and must be fixed so that it does
1095 not resolve until later.
1097 4) Indirectly between @code{after_type_declarator} and @code{parm}, for
1098 type names. This occurs in (as one example) code like
1101 typedef int foo, bar;
1107 What is @code{bar} inside the class definition? We currently interpret
1108 it as a @code{parm}, as does Cfront, but IBM xlC interprets it as an
1109 @code{after_type_declarator}. I believe that xlC is correct, in light
1110 of 7.1p2, which says "The longest sequence of @i{decl-specifiers} that
1111 could possibly be a type name is taken as the @i{decl-specifier-seq} of
1112 a @i{declaration}." However, it seems clear that this rule must be
1113 violated in the case of constructors. This ambiguity accounts for 8
1116 Unlike the others, this ambiguity is not recognized by the Working Paper.
1118 @node Copying Objects, Concept Index, Parser, Top
1119 @section Copying Objects
1121 The generated copy assignment operator in g++ does not currently do the
1122 right thing for multiple inheritance involving virtual bases; it just
1123 calls the copy assignment operators for its direct bases. What it
1124 should probably do is:
1126 1) Split up the copy assignment operator for all classes that have
1127 vbases into "copy my vbases" and "copy everything else" parts. Or do
1128 the trickiness that the constructors do to ensure that vbases don't get
1129 initialized by intermediate bases.
1131 2) Wander through the class lattice, find all vbases for which no
1132 intermediate base has a user-defined copy assignment operator, and call
1133 their "copy everything else" routines. If not all of my vbases satisfy
1134 this criterion, warn, because this may be surprising behavior.
1136 3) Call the "copy everything else" routine for my direct bases.
1138 If we only have one direct base, we can just foist everything off onto
1141 This issue is currently under discussion in the core reflector
1144 @node Concept Index, , Copying Objects, Top
1145 @section Concept Index