home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / gnu / g / help / 1698 < prev    next >
Encoding:
Internet Message Format  |  1993-01-23  |  8.6 KB

  1. Path: sparky!uunet!enterpoop.mit.edu!biosci!joes!toad.com!brendan
  2. From: brendan@cygnus.com (Brendan Kehoe)
  3. Newsgroups: gnu.g++.help
  4. Subject: Re: g++ release question
  5. Message-ID: <31003@toad.com>
  6. Date: 23 Jan 93 01:19:23 GMT
  7. References: <1jk51qINNj8j@fido.asd.sgi.com>
  8. Sender: news@toad.com
  9. Reply-To: brendan@cygnus.com (Brendan Kehoe)
  10. Organization: Cygnus Support, Mountain View, CA
  11. Lines: 193
  12. Nntp-Posting-Host: lisa.cygnus.com
  13. In-reply-to: asgeir@viking.asd.sgi.com's message of 20 Jan 93 18:18:34 GMT
  14.  
  15. In article <1jk51qINNj8j@fido.asd.sgi.com> asgeir@viking.asd.sgi.com (Asgeir Eiriksson) writes:
  16.  
  17.    Is there a way to access the bug list for a particular release?
  18.  
  19. I'm afraid not.
  20.  
  21.    How about the list of bugs that are fixed in a particular release?
  22.  
  23. Well, here's a list of some of the different things that were changed
  24. between 2.2.2 and 2.3.3 (approximately).
  25.  
  26. --
  27. * Handling @code{const} and @code{volatile} references is improved when
  28. they are used as arguments.  When passing a non-const argument into a
  29. function expecting a @code{const} reference, the compiler will make an effort
  30. to match a function accepting a non-const reference first.
  31.  
  32. * The implicit @code{this} parameter to class functions is no longer
  33. considered in the cost for matching possible function candidates.  Among
  34. other things, the argument could be point to a derived class, which
  35. would make the choice more expensive.
  36.  
  37. * For a class that has only private member functions, the compiler will
  38. also provide the name of the class when generating warnings.
  39.  
  40. * In accordance with ARM section 9.4, the compiler will not permit fields
  41. of local classes to be declared @code{static}.
  42.  
  43. * The compiler will more intelligently deal with @code{extern "C"} functions
  44. being made friends.
  45.  
  46. * Use of user-defined conversion operators is now checked more strictly
  47. for possibly ambiguities.
  48.  
  49. * The option @samp{-Wredundant-decls} will warn about multiple redundant
  50. declarations for the same variable or function.
  51.  
  52. * Support for nested enumerated types has been improved, particularly in
  53. situations where the types are actually located in base classes.
  54.  
  55. * Wrappers are no longer supported in the compiler; this helped, in part,
  56. to achieve a 12% code reduction in the compiler.
  57.  
  58. * The compiler's performance has been tweaked in a few areas; the second
  59. phase will include a full profiling and analysis of the C++ front-end. 
  60.  
  61. * Member functions can be called without objects if the functions are
  62. declared to be @code{static}.
  63.  
  64. * When attempting to convert from one type to another, the compiler will
  65. provide the user with @emph{both} types involved in the error message,
  66. rather than just vaguely say that something couldn't be converted to a
  67. reference type.  Also, if a method's name is duplicated in a class, the
  68. compiler will give you both the class and the function to aid in
  69. debugging.  (No more ``aggregate scope'' error messages.)
  70.  
  71. * Finding members of nested classes, and diagnosing possible access
  72. violations, are more properly performed.
  73.  
  74. * Handling severe compiler errors was completely changed.  Now even in the
  75. most disastrous cases, the compiler will no longer core dump with an
  76. abort, or die with a segmentation fault.  Instead, it will notify the
  77. user of the internal compiler error, and encourage submission of a bug
  78. report.  In most cases, the compiler will also provide an internal
  79. reference number, which will aid the maintainers in diagnosing the
  80. problem.
  81.  
  82. * The math functions @code{sin} and @code{cos} have built-in equivalents,
  83. to match the C front-end.
  84.  
  85. * The wide character type @samp{wchar_t} has been added as a recognized
  86. type, per the specification in the ANSI X3J16 standards working paper.
  87.  
  88. * To comply with ARM section 9.5, the compiler will not allow anonymous
  89. unions to have function members.
  90.  
  91. * Initialization of references has been greatly refined, fully
  92. implementing section 9.4 of the ARM.
  93.  
  94. * According to section 7.1 of the ARM, a @code{const} object does not have
  95. external linkage and must be initialized, unless it is explicitly
  96. declared extern.  GNU C++ now follows this dictum, but this behavior may
  97. be slightly changed in the second phase, to allow cases where such
  98. constructs are common practice.  
  99.  
  100. * The compiler will reject attempts to declare type conversion operators
  101. as non-member functions.
  102.  
  103. * Section 12.1 of the ARM says that neither constructors nor destructors
  104. may not be declared to be @code{const} or @code{volatile}, and may not
  105. be @code{static}.  GNU C++ will now correctly diagnose these cases.  In
  106. addition, constructors will not be allowed to be declared to be @code{virtual}.
  107.  
  108. * To comply with ARM section 9.5, an error will be generated if a union is
  109. declared to have virtual functions.
  110.  
  111. * Member initialization has been changed with the first phase of Reno.  By
  112. default, no member in a class definition may be initialized.  Static
  113. members will not be permitted to be initialized, since they must be
  114. defined separately from their declaration.  In the interests of
  115. backwards compatibility, @code{const} members will be allowed to have
  116. initializers, unless the @samp{-pedantic} flag is used.  GNU C++ is
  117. closer to compliance with section 9.2.2 of the ANSI C++ working paper,
  118. but will probably never be an exact match.
  119.  
  120. * The function @samp{main} will not be allowed to be declared to have
  121. @code{static} linkage.
  122.  
  123. * The @samp{extern inline} extension of GNU C and C++ will be warned
  124. against with the @samp{-ansi} flag, and produce an error with
  125. @samp{-pedantic}.
  126.  
  127. * To agree with ARM section 8.2, GNU C++ will not allow local variables to
  128. be used in default argument expressions.
  129.  
  130. * Protected base classes are implemented and supported.
  131.  
  132. * Ambiguity checking and better support for multiple inheritance was
  133. greatly improved.
  134.  
  135. * Debugging info for enumeral types is now emitted in many more cases than
  136. before.
  137.  
  138. * Scoping rules for @code{friend} functions have been corrected to make them be
  139. in the same lexical scope as the scope of the class in which it is
  140. defined.
  141.  
  142. * The @samp{-Wchar-subscripts} flag will warn when arrays are referenced
  143. with subscripts of type @samp{char}, which on some systems could be
  144. signed, leading to unexpected results.
  145.  
  146. * The options @samp{+e0} and @samp{+e1}, which provide some
  147. call-compatibility with other C++ compilers, are now recognized and
  148. handled correctly.
  149.  
  150. * The compiler will now more intelligently recognize ambiguities between
  151. conversion operators and constructors.
  152.  
  153. * When used with the @code{-traditional} flag, the sequences @samp{\x} and
  154. @samp{\a} will resolve to just @samp{x} and @samp{a}, respectively.  If
  155. used with @samp{-Wtraditional}, a warning about this difference in
  156. behavior will be generated.
  157.  
  158. * The compiler will now recognize @samp{\e} in addition to @samp{\E} for
  159. an escape sequence, but will warn about its non-compliance with the
  160. emerging ANSI standard if @samp{-pedantic} is used.
  161.  
  162. * Bugs in the handling of multi-byte strings (of the form @samp{L"..."})
  163. have been corrected.
  164.  
  165. * The compiler previously made mistakes with how to handle the context of
  166. a virtual function; it now behaves much better.
  167.  
  168. * Working with nested types in template classes has been improved to a
  169. degree; the second phase of Reno will include many improvements to the
  170. compiler's handling of templates in general.
  171.  
  172. * The GNU C front-end extension of using labels as values
  173. (@samp{&&@var{label}}) and its accompanying support of the computed goto
  174. (@samp{goto *@var{exp}}) has been added to the C++ front-end.
  175.  
  176. * Neither operator @code{new} nor operator @code{delete} may now be
  177. declared as @samp{virtual}.
  178.  
  179. * Attempts to overload operator @code{delete} is more strictly controlled,
  180. per section 12.5 of the ARM.
  181.  
  182. * Operator @code{delete} now behaves properly when used with non-pointers,
  183. constant pointers, and pointers with the value 0.
  184.  
  185. * It is now illegal to apply operator @code{new} to a reference type.
  186.  
  187. * Using operator @code{new} with placement has been dramatically improved.
  188.  
  189. * The compiler will now warn that use of operator @code{new} with the old
  190. placement syntax (using curly braces, as in @samp{new @{@var{foo}@}})
  191. should be replaced by using proper syntax (@samp{new (@var{foo})}).
  192.  
  193. * Casts to references are now allowed to be used as lvalues, per ARM
  194. section 5.4.
  195.  
  196. * According to ARM section 8.4.2, it is illegal to initialize a character
  197. array with more initializers than there are array elements.  In C, it's
  198. legal to forget about the terminating @samp{\0}, but in C++ it's now an
  199. error if the array's initialization does not fit, @emph{including} the
  200. trailing null character.
  201.  
  202. * An array reference is now considered @code{const} or @code{volatile} if
  203. the array elements are or if the array itself is.
  204. --
  205. --
  206. Brendan Kehoe                                               brendan@cygnus.com
  207. Cygnus Support, Mountain View, CA                              +1 415 903 1400
  208.