Return to gpcompare.texi CVS log

Up to [GCC 2.x] / gcc / cp

Annotation of gcc/cp/gpcompare.texi, revision 1.1

1.1     ! root        1: @node ANSI
        !             2: @chapter @sc{gnu} C++ Conformance to @sc{ansi} C++
        !             3: 
        !             4: These changes in the @sc{gnu} C++ compiler were made to comply more
        !             5: closely with the @sc{ansi} base document, @cite{The Annotated C++
        !             6: Reference Manual} (the @sc{arm}).  Further reducing the divergences from
        !             7: @sc{ansi} C++ is a continued goal of the @sc{gnu} C++ Renovation
        !             8: Project.
        !             9: 
        !            10: @b{Section 3.4}, @i{Start and Termination}.  It is now illegal to take
        !            11: the address of the function @samp{main()}.
        !            12: 
        !            13: @b{Section 4.8}, @i{Pointers to Members}.  The compiler produces
        !            14: an error for trying to convert between a pointer to a member and the type
        !            15: @samp{void *}.
        !            16: 
        !            17: @b{Section 5.2.5}, @i{Increment and Decrement}.  It is an error to use
        !            18: the increment and decrement operators on an enumerated type.
        !            19: 
        !            20: @b{Section 5.3.2}, @i{Sizeof}.  Doing @code{sizeof} on a function is now
        !            21: an error.
        !            22: 
        !            23: @b{Section 5.3.4}, @i{Delete}.  The syntax of a @i{cast-expression} is
        !            24: now more strictly controlled.
        !            25: 
        !            26: @b{Section 7.1.1}, @i{Storage Class Specifiers}.  Using the
        !            27: @code{static} and @code{extern} specifiers can now only be applied to
        !            28: names of objects, functions, and anonymous unions.
        !            29: 
        !            30: @b{Section 7.1.1}, @i{Storage Class Specifiers}.  The compiler no longer complains
        !            31: about taking the address of a variable which has been declared to have @code{register}
        !            32: storage.
        !            33: 
        !            34: @b{Section 7.1.2}, @i{Function Specifiers}.  The compiler produces an
        !            35: error when the @code{inline} or @code{virtual} specifiers are
        !            36: used on anything other than a function.
        !            37: 
        !            38: @b{Section 8.3}, @i{Function Definitions}.  It is now an error to shadow
        !            39: a parameter name with a local variable; in the past, the compiler only
        !            40: gave a warning in such a situation.
        !            41: 
        !            42: @b{Section 8.4.1}, @i{Aggregates}.  The rules concerning declaration of
        !            43: an aggregate are now all checked in the @sc{gnu} C++ compiler; they
        !            44: include having no private or protected members and no base classes.
        !            45: 
        !            46: @b{Section 8.4.3}, @i{References}.  Declaring an array of references is
        !            47: now forbidden.  Initializing a reference with an initializer list is
        !            48: also considered an error.
        !            49: 
        !            50: @b{Section 9.5}, @i{Unions}.  Global anonymous unions must be declared
        !            51: @code{static}.
        !            52: 
        !            53: @b{Section 11.4}, @i{Friends}.  Declaring a member to be a friend of a
        !            54: type that has not yet been defined is an error.
        !            55: 
        !            56: @b{Section 12.1}, @i{Constructors}.  The compiler generates a
        !            57: default copy constructor for a class if no constructor has been declared.
        !            58: 
        !            59: @ignore
        !            60: @b{Section 12.4}, @i{Destructors}.  In accordance with the @sc{ansi} C++
        !            61: draft standard working paper, a pure virtual destructor must now be
        !            62: defined.
        !            63: @end ignore
        !            64: 
        !            65: @b{Section 12.6.2}, @i{Special Member Functions}.  When using a
        !            66: @i{mem-initializer} list, the compiler will now initialize class members
        !            67: in declaration order, not in the order in which you specify them.
        !            68: Also, the compiler enforces the rule that non-static @code{const}
        !            69: and reference members must be initialized with a @i{mem-initializer}
        !            70: list when their class does not have a constructor.
        !            71: 
        !            72: @b{Section 12.8}, @i{Copying Class Objects}.  The compiler generates
        !            73: default copy constructors correctly, and supplies default assignment
        !            74: operators compatible with user-defined ones.
        !            75: 
        !            76: @b{Section 13.4}, @i{Overloaded Operators}.  An overloaded operator may
        !            77: no longer have default arguments.
        !            78: 
        !            79: @b{Section 13.4.4}, @i{Function Call}.  An overloaded @samp{operator ()}
        !            80: must be a non-static member function.
        !            81: 
        !            82: @b{Section 13.4.5}, @i{Subscripting}.  An overloaded @samp{operator []}
        !            83: must be a non-static member function.
        !            84: 
        !            85: @b{Section 13.4.6}, @i{Class Member Access}.  An overloaded @samp{operator ->}
        !            86: must be a non-static member function.
        !            87: 
        !            88: @b{Section 13.4.7}, @i{Increment and Decrement}.  The compiler will now
        !            89: make sure a postfix @samp{@w{operator ++}} or @samp{@w{operator --}} has an
        !            90: @code{int} as its second argument.
        !            91: 
        !            92: 
        !            93: @node Encoding
        !            94: @chapter Name Encoding in @sc{gnu} C++
        !            95: 
        !            96: @c FIXME!! rewrite name encoding section
        !            97: @c ...to give complete rules rather than diffs from ARM.
        !            98: @c To avoid plagiarism, invent some different way of structuring the
        !            99: @c description of the rules than what ARM uses.
        !           100: 
        !           101: @cindex mangling
        !           102: @cindex name encoding
        !           103: @cindex encoding information in names
        !           104: In order to support its strong typing rules and the ability to provide
        !           105: function overloading, the C++ programming language @dfn{encodes}
        !           106: information about functions and objects, so that conflicts across object
        !           107: files can be detected during linking. @footnote{This encoding is also
        !           108: sometimes called, whimsically enough, @dfn{mangling}; the corresponding
        !           109: decoding is sometimes called @dfn{demangling}.} These rules tend to be
        !           110: unique to each individual implementation of C++.
        !           111: 
        !           112: The scheme detailed in the commentary for 7.2.1 of @cite{The Annotated
        !           113: Reference Manual} offers a description of a possible implementation
        !           114: which happens to closely resemble the @code{cfront} compiler.  The
        !           115: design used in @sc{gnu} C++ differs from this model in a number of ways:
        !           116: 
        !           117: @itemize @bullet
        !           118: @item
        !           119: In addition to the basic types @code{void}, @code{char}, @code{short},
        !           120: @code{int}, @code{long}, @code{float}, @code{double}, and @code{long
        !           121: double}, @sc{gnu} C++ supports two additional types: @code{wchar_t}, the wide
        !           122: character type, and @code{long long} (if the host supports it).  The
        !           123: encodings for these are @samp{w} and @samp{x} respectively.
        !           124: 
        !           125: @item
        !           126: According to the @sc{arm}, qualified names (e.g., @samp{foo::bar::baz}) are
        !           127: encoded with a leading @samp{Q}.  Followed by the number of
        !           128: qualifications (in this case, three) and the respective names, this
        !           129: might be encoded as @samp{Q33foo3bar3baz}.  @sc{gnu} C++ adds a leading
        !           130: underscore to the list, producing @samp{_Q33foo3bar3baz}.
        !           131:  
        !           132: @item
        !           133: The operator @samp{*=} is encoded as @samp{__aml}, not @samp{__amu}, to
        !           134: match the normal @samp{*} operator, which is encoded as @samp{__ml}.
        !           135: 
        !           136: @c XXX left out ->(), __wr
        !           137: @item
        !           138: In addition to the normal operators, @sc{gnu} C++ also offers the minimum and
        !           139: maximum operators @samp{>?} and @samp{<?}, encoded as @samp{__mx} and
        !           140: @samp{__mn}, and the conditional operator @samp{?:}, encoded as @samp{__cn}.
        !           141: 
        !           142: @cindex destructors, encoding of
        !           143: @cindex constructors, encoding of
        !           144: @item
        !           145: Constructors are encoded as simply @samp{__@var{name}}, where @var{name}
        !           146: is the encoded name (e.g., @code{3foo} for the @code{foo} class
        !           147: constructor).  Destructors are encoded as two leading underscores
        !           148: separated by either a period or a dollar sign, depending on the
        !           149: capabilities of the local host, followed by the encoded name.  For
        !           150: example, the destructor @samp{foo::~foo} is encoded as @samp{_$_3foo}.
        !           151: 
        !           152: @item
        !           153: Virtual tables are encoded with a prefix of @samp{_vt}, rather than
        !           154: @samp{__vtbl}.  The names of their classes are separated by dollar signs
        !           155: (or periods), and not encoded as normal: the virtual table for
        !           156: @code{foo} is @samp{__vt$foo}, and the table for @code{foo::bar} is
        !           157: named @samp{__vt$foo$bar}.
        !           158: 
        !           159: @item
        !           160: Static members are encoded as a leading underscore, followed by the
        !           161: encoded name of the class in which they appear, a separating dollar sign
        !           162: or period, and finally the unencoded name of the variable.  For example,
        !           163: if the class @code{foo} contains a static member @samp{bar}, its
        !           164: encoding would be @samp{_3foo$bar}.
        !           165: 
        !           166: @item
        !           167: @sc{gnu} C++ is not as aggressive as other compilers when it comes to always
        !           168: generating @samp{Fv} for functions with no arguments.  In particular,
        !           169: the compiler does not add the sequence to conversion operators.  The
        !           170: function @samp{foo::bar()} is encoded as @samp{bar__3foo}, not
        !           171: @samp{bar__3fooFv}.
        !           172: 
        !           173: @item
        !           174: The argument list for methods is not prefixed by a leading @samp{F}; it
        !           175: is considered implied.
        !           176: 
        !           177: @item
        !           178: @sc{gnu} C++ approaches the task of saving space in encodings
        !           179: differently from that noted in the @sc{arm}.  It does use the
        !           180: @samp{T@var{n}} and @samp{N@var{x}@var{y}} codes to signify copying the
        !           181: @var{n}th argument's type, and making the next @var{x} arguments be the
        !           182: type of the @var{y}th argument, respectively.  However, the values for
        !           183: @var{n} and @var{y} begin at zero with @sc{gnu} C++, whereas the
        !           184: @sc{arm} describes them as starting at one.  For the function @samp{foo
        !           185: (bartype, bartype)}, @sc{gnu} C++ uses @samp{foo__7bartypeT0}, while
        !           186: compilers following the @sc{arm} example generate @samp{foo__7bartypeT1}.
        !           187: 
        !           188: @c Note it loses on `foo (int, int, int, int, int)'.
        !           189: @item
        !           190: @sc{gnu} C++ does not bother using the space-saving methods for types whose
        !           191: encoding is a single character (like an integer, encoded as @samp{i}).
        !           192: This is useful in the most common cases (two @code{int}s would result in
        !           193: using three letters, instead of just @samp{ii}).
        !           194: @end itemize
        !           195: 
        !           196: @c @node Cfront
        !           197: @c @chapter @code{cfront} Compared to @sc{gnu} C++
        !           198: @c 
        !           199: @c 
        !           200: @c FIXME!! Fill in.  Consider points in the following:
        !           201: @c 
        !           202: @c @display
        !           203: @c Date: Thu, 2 Jan 92 21:35:20 EST
        !           204: @c From: raeburn@@cygnus.com
        !           205: @c Message-Id: <9201030235.AA10999@@cambridge.cygnus.com>
        !           206: @c To: mrs@@charlie.secs.csun.edu
        !           207: @c Cc: g++@@cygnus.com
        !           208: @c Subject: Re: ARM and GNU C++ incompatabilities
        !           209: @c 
        !           210: @c Along with that, we should probably describe how g++ differs from
        !           211: @c cfront, in ways that the users will notice.  (E.g., cfront supposedly
        !           212: @c allows "free (new char[10])"; does g++?  How do the template
        !           213: @c implementations differ?  "New" placement syntax?)
        !           214: @c @end display
        !           215: @c
        !           216: @c XXX For next revision.
        !           217: @c
        !           218: @c GNU C++:
        !           219: @c * supports expanding inline functions in many situations,
        !           220: @c   including those which have static objects, use `for' statements,
        !           221: @c   and other situations.  Part of this versatility is due to is
        !           222: @c   ability to not always generate temporaries for assignments.
        !           223: @c * deliberately allows divide by 0 and mod 0, since [according
        !           224: @c   to Wilson] there are actually situations where you'd like to allow
        !           225: @c   such things.  Note on most systems it will cause some sort of trap
        !           226: @c   or bus error.  Cfront considers it an error.
        !           227: @c * does [appear to] support nested classes within templates.
        !           228: @c * conversion functions among baseclasses are all usable by
        !           229: @c   a class that's derived from all of those bases.
        !           230: @c * sizeof works even when the class is defined within its ()'s
        !           231: @c * conditional expressions work with member fns and pointers to
        !           232: @c    members.
        !           233: @c * can handle non-trivial declarations of variables within switch
        !           234: @c   statements.
        !           235: @c
        !           236: @c Cfront:

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.