gpcompare.texi (10095B)
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 invalid 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: