g++faq.texi

来自「GCC编译器源代码」· TEXI 代码 · 共 1,691 行 · 第 1/5 页

installed automatically.  Even better, it is used by the @code{collect}
linker, so you don't see mangled symbols anymore (except on platforms
that use neither collect nor the GNU linker, like Solaris).

@node static data members, internal compiler error, Demangler, User Problems
@section Linker reports undefined symbols for static data members

@cindex Static data members
``g++ reports undefined symbols for all my static data members when I link,
even though the program works correctly for compiler XYZ.  What's going on?''

The problem is almost certainly that you don't give definitions for
your static data members.  If you have

@example
class Foo @{
	...
	void method();
	static int bar;
@};
@end example

you have only declared that there is an int named Foo::bar and a member
function named Foo::method that is defined somewhere.  You still need to
define @emph{both} method() and bar in some source file.  According to
the draft ANSI standard, you must supply an initializer, such as

@example
int Foo::bar = 0;
@end example

@noindent
in one (and only one) source file.

@node internal compiler error, bug reports, static data members, User Problems
@section What does ``Internal compiler error'' mean?

It means that the compiler has detected a bug in itself.  Unfortunately,
g++ still has many bugs, though it is a lot better than it used to be.
If you see this message, please send in a complete bug report (see next
section).

@node bug reports, porting to g++, internal compiler error, User Problems
@section I think I have found a bug in g++.

@cindex Bug in g++, newly found
``I think I have found a bug in g++, but I'm not sure.  How do I know,
and who should I tell?''

@cindex Manual, for gcc
First, see the excellent section on bugs and bug reports in the gcc manual
(which is included in the gcc distribution).  As a short summary of that
section: if the compiler gets a fatal signal, for any input, it's a bug
(newer versions of g++ will ask you to send in a bug report when they
detect an error in themselves).  Same thing for producing invalid
assembly code.

When you report a bug, make sure to describe your platform (the type of
computer, and the version of the operating system it is running) and the
version of the compiler that you are running.  See the output of the
command @code{g++ -v} if you aren't sure.  Also provide enough code
so that the g++ maintainers can duplicate your bug.  Remember that the
maintainers won't have your header files; one possibility is to send
the output of the preprocessor (use @code{g++ -E} to get this).  This
is what a ``complete bug report'' means.

I will add some extra notes that are C++-specific, since the notes from
the gcc documentation are generally C-specific.

@cindex g++ bug report
First, mail your bug report to "bug-g++@@prep.ai.mit.edu".  You may also
post to @file{gnu.g++.bug}, but it's better to use mail, particularly if you
have any doubt as to whether your news software generates correct reply
addresses.  Don't mail C++ bugs to bug-gcc@@prep.ai.mit.edu.

@strong{News:} as I write this (late February 1996) the gateway
connecting the bug-g++ mailing list and the @file{gnu.g++.bug} newsgroup
is (temporarily?) broken.  Please mail, do not post bug reports.

@cindex libg++ bug report
If your bug involves libg++ rather than the compiler, mail to
bug-lib-g++@@prep.ai.mit.edu.  If you're not sure, choose one, and if you
guessed wrong, the maintainers will forward it to the other list.

@cindex C++, reference books
@cindex ARM [Annotated C++ Ref Manual]
Second, if your program does one thing, and you think it should do
something else, it is best to consult a good reference if in doubt.
The standard reference is the draft working paper from the ANSI/ISO
C++ standardization committee, which you can get on the net.
For PostScript and PDF (Adobe Acrobat) versions, see the
archive at @file{ftp://research.att.com/dist/stdc++/WP}.  For HTML and ASCII
versions, see @file{ftp://ftp.cygnus.com/pub/g++}.  On the World Wide Web, see
@file{http://www.cygnus.com/misc/wp/}.

An older
standard reference is "The Annotated C++ Reference Manual", by Ellis and
Stroustrup (copyright 1990, ISBN #0-201-51459-1).  This is what they're
talking about on the net when they refer to ``the ARM''.  But you should
know that changes have been made to the language since then.

The ANSI/ISO C++ standards committee have adopted some changes to the
C++ language since the publication of the original ARM, and newer
versions of g++ (2.5.x and later) support some of these changes, notably
the mutable keyword (added in 2.5.0), the bool type (added in 2.6.0),
and changes in the scope of variables defined in for statements (added
in 2.7.0).
You can obtain an addendum to the ARM explaining many of these changes by FTP
from @file{ftp://ftp.std.com/AW/stroustrup2e/new_iso.ps}.

@cindex AT&T cfront
Note that the behavior of (any version of) AT&T's "cfront" compiler is
NOT the standard for the language.

@node porting to g++, name mangling, bug reports, User Problems
@section Porting programs from other compilers to g++

``I have a program that runs on <some other C++ compiler>, and I want
to get it running under g++.  Is there anything I should watch out
for?''

@cindex Porting to g++

Note that g++ supports many of the newer keywords that have recently
been added to the language.  Your other C++ compiler may not support
them, so you may need to rename variables and members that conflict
with these keywords.

There are two other reasons why a program that worked under one compiler
might fail under another: your program may depend on the order of
evaluation of side effects in an expression, or it may depend on the
lifetime of a temporary (you may be assuming that a temporary object
"lives" longer than the standard guarantees).  As an example of the
first:

@example
void func(int,int);

int i = 3;
func(i++,i++);
@end example

@cindex Order of evaluation, problems in porting
Novice programmers think that the increments will be evaluated in strict
left-to-right order.  Neither C nor C++ guarantees this; the second
increment might happen first, for example.  func might get 3,4, or it
might get 4,3.

@cindex Classes, problems in porting
@cindex Problems in porting, class
The second problem often happens with classes like the libg++ String
class.  Let's say I have

@example
String func1();
void func2(const char*);
@end example

and I say

@example
func2(func1());
@end example

because I know that class String has an "operator const char*".  So what
really happens is

@example
func2(func1().convert());
@end example

@cindex temporaries
where I'm pretending I have a convert() method that is the same as the
cast.  This is unsafe in g++ versions before 2.6.0, because the
temporary String object may be deleted after its last use (the call to
the conversion function), leaving the pointer pointing to garbage, so by
the time func2 is called, it gets an invalid argument.

@cindex ANSI draft standard
Both the cfront and the old g++ behaviors are legal according to the ARM,
but the powers that be have decided that compiler writers were given
too much freedom here.

The ANSI C++ committee has now come to a resolution of the lifetime of
temporaries problem: they specify that temporaries should be deleted at
end-of-statement (and at a couple of other points).  This means that g++
versions before 2.6.0 now delete temporaries too early, and cfront
deletes temporaries too late.  As of version 2.6.0, g++ does things
according to the new standard.

@cindex Scope, problems in porting
@cindex Problems in porting, scope
For now, the safe way to write such code is to give the temporary a name,
which forces it to live until the end of the scope of the name. For
example:

@example
String& tmp = func1();
func2(tmp);
@end example

Finally, like all compilers (but especially C++ compilers, it seems),
g++ has bugs, and you may have tweaked one.  If so, please file a bug
report (after checking the above issues).

@node name mangling, problems linking with other libraries, porting to g++, User Problems
@section Why does g++ mangle names differently from other C++ compilers?

See the answer to the next question.
@cindex Mangling names

@node problems linking with other libraries, documentation, name mangling, User Problems
@section Why can't g++ code link with code from other C++ compilers?

``Why can't I link g++-compiled programs against libraries compiled by
some other C++ compiler?''

@cindex Mangling names
@cindex Cygnus Support
Some people think that,
if only the FSF and Cygnus Support folks would stop being
stubborn and mangle names the same way that, say, cfront does, then any
g++-compiled program would link successfully against any cfront-compiled
library and vice versa.  Name mangling is the least of the problems.
Compilers differ as to how objects are laid out, how multiple inheritance
is implemented, how virtual function calls are handled, and so on, so if
the name mangling were made the same, your programs would link against
libraries provided from other compilers but then crash when run.  For this
reason, the ARM @emph{encourages} compiler writers to make their name mangling
different from that of other compilers for the same platform.
Incompatible libraries are then detected at link time, rather than at run
time.
@cindex ARM [Annotated C++ Ref Manual]
@cindex Compiler differences

@node documentation, templates, problems linking with other libraries, User Problems
@section What documentation exists for g++ 2.x?

@cindex g++, documentation
Relatively little.
While the gcc manual that comes with the distribution has some coverage
of the C++ part of the compiler, it focuses mainly on the C compiler
(though the information on the ``back end'' pertains to C++ as well).
Still, there is useful information on the command line options and the
#pragma interface and #pragma implementation directives in the manual,
and there is a useful section on template instantiation in the 2.6 version.
There is a Unix-style manual entry, "g++.1", in the gcc-2.x
distribution; the information here is a subset of what is in the manual.

You can buy a nicely printed and bound copy of this manual from the FSF;
see above for ordering information.

A draft of a document describing the g++ internals appears in the gcc
distribution (called g++int.texi); it is incomplete but gives lots of
information.

For class libraries, there are several resources available:

@itemize @bullet
@item
The libg++ distribution has a manual
@file{libg++/libg++.texi} describing the old libg++ classes, and
another manual @file{libio/iostream.texi} describing the iostreams
implementation.
@item
While there is no libg++-specific document describing the STL
implementation, SGI's web site, at @file{http://www.sgi.com/Technology/STL/},
is an excellent resource.
@end itemize

@node templates, undefined templates, documentation, User Problems
@section Problems with the template implementation

@cindex g++, template support
@cindex Templates

g++ does not implement a separate pass to instantiate template functions
and classes at this point; for this reason, it will not work, for the most
part, to declare your template functions in one file and define them in
another.  The compiler will need to see the entire definition of the
function, and will generate a static copy of the function in each file
in which it is used.

(The experimental template repository code (@pxref{repository}) that
can be added to 2.7.0 or later does implement a separate pass, but there
is still no searching of files that the compiler never saw).

@cindex -fno-implicit-templates
For version 2.6.0, however, a new switch @code{-fno-implicit-templates}
was added; with this switch, templates are expanded only under user
control.  I recommend that all g++ users that use templates read the
section ``Template Instantiation'' in the gcc manual (version 2.6.x
and newer).  g++ now supports explicit template expansion using the
syntax from the latest C++ working paper:

@example
template class A<int>;
template ostream& operator << (ostream&, const A<int>&);
@end example

@cindex template limitations
As of version 2.6.3, there are still a few limitations in the template
implementation besides the above (thanks to Jason Merrill for this info):
These are still present in version 2.7.2, but a new implementation of
templates planned for version 2.8 will eliminate them.

@enumerate 1
@item
Static data member templates are not supported.  You can work around
this by explicitly declaring the static variable for each template
specialization:

@example
template <class T> struct A @{
  static T t;
@};

template <class T> T A<T>::t = 0; // gets bogus error
int A<int>::t = 0;                // OK (workaround)
@end example

(still a limitation in 2.7.2)

@item
Template member names are not available when defining member function
templates.

@example
template <class T> struct A @{
  typedef T foo;
  void f (foo);
  void g (foo arg) @{ ... @}; // this works
@};

template <class T> void A<T>::f (foo) @{ @}