Commit e6f3b89d by Phil Edwards

extend.texi: Move C++-extension-related node from the C section into the C++ section.

2001-01-12  Phil Edwards  <pme@sources.redhat.com>

	* extend.texi:  Move C++-extension-related node from the C section
	  into the C++ section.

From-SVN: r38950
parent 01d9cb8b
2001-01-12 Phil Edwards <pme@sources.redhat.com>
* extend.texi: Move C++-extension-related node from the C section
into the C++ section.
2001-01-12 Joseph S. Myers <jsm28@cam.ac.uk>
* extend.texi: Refer to an array of pointers to functions instead
......
......@@ -65,8 +65,6 @@ C++ Language}, for extensions that apply @emph{only} to C++.
function.
* Return Address:: Getting the return or frame address of a function.
* Other Builtins:: Other built-in functions.
* Deprecated Features:: Things might disappear from g++.
* Backwards Compatibility:: Compatibilities with earlier definitions of C++.
@end menu
@end ifset
@ifclear INTERNALS
......@@ -114,8 +112,6 @@ C++ Language}, for extensions that apply @emph{only} to C++.
* Function Names:: Printable strings which are the name of the current
function.
* Return Address:: Getting the return or frame address of a function.
* Deprecated Features:: Things might disappear from g++.
* Backwards Compatibility:: Compatibilities with earlier definitions of C++.
* Other Builtins:: Other built-in functions.
@end menu
@end ifclear
......@@ -3528,68 +3524,6 @@ if (__builtin_expect (ptr != NULL, 1))
when testing pointer or floating-point values.
@end table
@node Deprecated Features
@section Deprecated Features
In the past, the GNU C++ compiler was extended to experiment with new
features, at a time when the C++ language was still evolving. Now that
the C++ standard is complete, some of those features are superseded by
superior alternatives. Using the old features might cause a warning in
some cases that the feature will be dropped in the future. In other
cases, the feature might be gone already.
While the list below is not exhaustive, it documents some of the options
that are now deprecated:
@table @code
@item -fexternal-templates
@itemx -falt-external-templates
These are two of the many ways for g++ to implement template
instantiation. @xref{Template Instantiation}. The C++ standard clearly
defines how template definitions have to be organized across
implementation units. g++ has an implicit instantiation mechanism that
should work just fine for standard-conforming code.
@item -fstrict-prototype
@itemx -fno-strict-prototype
Previously it was possible to use an empty prototype parameter list to
indicate an unspecified number of parameters (like C), rather than no
parameters, as C++ demands. This feature has been removed, except where
it is required for backwards compatibility @xref{Backwards Compatibility}.
@end table
The named return value extension has been deprecated, and will be
removed from g++ at some point.
@node Backwards Compatibility
@section Backwards Compatibility
@cindex Backwards Compatibility
@cindex ARM
Now that there is a definitive ISO standard C++, g++ has a specification
to adhere to. The C++ language evolved over time, and features that used
to be acceptable in previous drafts of the standard, such as the ARM, are
no longer accepted. In order to allow compilation of C++ written to such
drafts, g++ contains some backwards compatibilities. @emph{All such
backwards compatibility features are liable to disappear in future
versions of g++.} They should be considered deprecated @xref{Deprecated
Features}.
@table @code
@item For scope
If a variable is declared at for scope, it used to remain in scope until
the end of the scope which contained the for statement (rather than just
within the for scope). g++ retains this, but issues a warning, if such a
variable is accessed outside the for scope.
@item implicit C language
Old C system header files did not contain an @code{extern "C" @{...@}}
scope to set the language. On such systems, all header files are
implicitly scoped inside a C language scope. Also, an empty prototype
@code{()} will be treated as an unspecified number of arguments, rather
than no arguments, as C++ demands.
@end table
@node C++ Extensions
@chapter Extensions to the C++ Language
@cindex extensions, C++ language
......@@ -3608,12 +3542,14 @@ Predefined Macros,cpp.info,The C Preprocessor}).
* Volatiles:: What constitutes an access to a volatile object.
* Restricted Pointers:: C99 restricted pointers and references.
* C++ Interface:: You can use a single C++ header file for both
declarations and definitions.
declarations and definitions.
* Template Instantiation:: Methods for ensuring that exactly one copy of
each needed template instantiation is emitted.
each needed template instantiation is emitted.
* Bound member functions:: You can extract a function pointer to the
method denoted by a @samp{->*} or @samp{.*} expression.
* C++ Attributes:: Variable, function, and type attributes for C++ only.
* C++ Attributes:: Variable, function, and type attributes for C++ only.
* Deprecated Features:: Things might disappear from g++.
* Backwards Compatibility:: Compatibilities with earlier definitions of C++.
@end menu
@node Min and Max
......@@ -4173,3 +4109,65 @@ thus, only the base class in a COM hierarchy needs @code{com_interface}.
@end table
@node Deprecated Features
@section Deprecated Features
In the past, the GNU C++ compiler was extended to experiment with new
features, at a time when the C++ language was still evolving. Now that
the C++ standard is complete, some of those features are superseded by
superior alternatives. Using the old features might cause a warning in
some cases that the feature will be dropped in the future. In other
cases, the feature might be gone already.
While the list below is not exhaustive, it documents some of the options
that are now deprecated:
@table @code
@item -fexternal-templates
@itemx -falt-external-templates
These are two of the many ways for g++ to implement template
instantiation. @xref{Template Instantiation}. The C++ standard clearly
defines how template definitions have to be organized across
implementation units. g++ has an implicit instantiation mechanism that
should work just fine for standard-conforming code.
@item -fstrict-prototype
@itemx -fno-strict-prototype
Previously it was possible to use an empty prototype parameter list to
indicate an unspecified number of parameters (like C), rather than no
parameters, as C++ demands. This feature has been removed, except where
it is required for backwards compatibility @xref{Backwards Compatibility}.
@end table
The named return value extension has been deprecated, and will be
removed from g++ at some point.
@node Backwards Compatibility
@section Backwards Compatibility
@cindex Backwards Compatibility
@cindex ARM [Annotated C++ Reference Manual]
Now that there is a definitive ISO standard C++, g++ has a specification
to adhere to. The C++ language evolved over time, and features that
used to be acceptable in previous drafts of the standard, such as the ARM
[Annotated C++ Reference Manual], are no longer accepted. In order to allow
compilation of C++ written to such drafts, g++ contains some backwards
compatibilities. @emph{All such backwards compatibility features are
liable to disappear in future versions of g++.} They should be considered
deprecated @xref{Deprecated Features}.
@table @code
@item For scope
If a variable is declared at for scope, it used to remain in scope until
the end of the scope which contained the for statement (rather than just
within the for scope). g++ retains this, but issues a warning, if such a
variable is accessed outside the for scope.
@item implicit C language
Old C system header files did not contain an @code{extern "C" @{...@}}
scope to set the language. On such systems, all header files are
implicitly scoped inside a C language scope. Also, an empty prototype
@code{()} will be treated as an unspecified number of arguments, rather
than no arguments, as C++ demands.
@end table
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment