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: |
---|