mirror of
git://gcc.gnu.org/git/gcc.git
synced 2025-03-20 09:00:37 +08:00
gcc.texi (Copy Assignment): New node.
* gcc.texi (Copy Assignment): New node. * gxxint.texi: Remove old discussion on copying virtual bases. From-SVN: r25992
This commit is contained in:
parent
dd4b5f0d25
commit
5197829d3c
@ -1,4 +1,8 @@
|
||||
999-03-25 Zack Weinberg <zack@rabi.columbia.edu>
|
||||
Thu Mar 25 22:53:27 1999 Martin von Löwis <loewis@informatik.hu-berlin.de>
|
||||
|
||||
* gcc.texi (Copy Assignment): New node.
|
||||
|
||||
1999-03-25 Zack Weinberg <zack@rabi.columbia.edu>
|
||||
|
||||
* gcc.c: Compile unconditionally all code formerly dependent
|
||||
on #ifdef LANG_SPECIFIC_DRIVER.
|
||||
|
@ -1,3 +1,7 @@
|
||||
1999-03-25 Martin von Löwis <loewis@informatik.hu-berlin.de>
|
||||
|
||||
* gxxint.texi: Remove old discussion on copying virtual bases.
|
||||
|
||||
1999-03-25 Zack Weinberg <zack@rabi.columbia.edu>
|
||||
|
||||
* Make-lang.in: Remove all references to g++.o/g++.c.
|
||||
|
@ -23,7 +23,6 @@ Questions and comments to Benjamin Kosnik @code{<bkoz@@cygnus.com>}.
|
||||
* Access Control::
|
||||
* Error Reporting::
|
||||
* Parser::
|
||||
* Copying Objects::
|
||||
* Exception Handling::
|
||||
* Free Store::
|
||||
* Mangling:: Function name mangling for C++ and Java
|
||||
@ -931,7 +930,7 @@ To have the line number on the error message indicate the line of the
|
||||
DECL, use @code{cp_error_at} and its ilk; to indicate which argument you want,
|
||||
use @code{%+D}, or it will default to the first.
|
||||
|
||||
@node Parser, Copying Objects, Error Reporting, Top
|
||||
@node Parser, Exception Handling, Error Reporting, Top
|
||||
@section Parser
|
||||
|
||||
Some comments on the parser:
|
||||
@ -1022,33 +1021,7 @@ conflicts.
|
||||
|
||||
Unlike the others, this ambiguity is not recognized by the Working Paper.
|
||||
|
||||
@node Copying Objects, Exception Handling, Parser, Top
|
||||
@section Copying Objects
|
||||
|
||||
The generated copy assignment operator in g++ does not currently do the
|
||||
right thing for multiple inheritance involving virtual bases; it just
|
||||
calls the copy assignment operators for its direct bases. What it
|
||||
should probably do is:
|
||||
|
||||
1) Split up the copy assignment operator for all classes that have
|
||||
vbases into "copy my vbases" and "copy everything else" parts. Or do
|
||||
the trickiness that the constructors do to ensure that vbases don't get
|
||||
initialized by intermediate bases.
|
||||
|
||||
2) Wander through the class lattice, find all vbases for which no
|
||||
intermediate base has a user-defined copy assignment operator, and call
|
||||
their "copy everything else" routines. If not all of my vbases satisfy
|
||||
this criterion, warn, because this may be surprising behavior.
|
||||
|
||||
3) Call the "copy everything else" routine for my direct bases.
|
||||
|
||||
If we only have one direct base, we can just foist everything off onto
|
||||
them.
|
||||
|
||||
This issue is currently under discussion in the core reflector
|
||||
(2/28/94).
|
||||
|
||||
@node Exception Handling, Free Store, Copying Objects, Top
|
||||
@node Exception Handling, Free Store, Parser, Top
|
||||
@section Exception Handling
|
||||
|
||||
Note, exception handling in g++ is still under development.
|
||||
|
66
gcc/gcc.texi
66
gcc/gcc.texi
@ -1643,15 +1643,16 @@ in scope at the time of the call.
|
||||
@cindex misunderstandings in C++
|
||||
@cindex surprises in C++
|
||||
@cindex C++ misunderstandings
|
||||
C++ is a complex language and an evolving one, and its standard definition
|
||||
(the ANSI C++ draft standard) is also evolving. As a result,
|
||||
your C++ compiler may occasionally surprise you, even when its behavior is
|
||||
correct. This section discusses some areas that frequently give rise to
|
||||
questions of this sort.
|
||||
C++ is a complex language and an evolving one, and its standard
|
||||
definition (the ISO C++ standard) was only recently completed. As a
|
||||
result, your C++ compiler may occasionally surprise you, even when its
|
||||
behavior is correct. This section discusses some areas that frequently
|
||||
give rise to questions of this sort.
|
||||
|
||||
@menu
|
||||
* Static Definitions:: Static member declarations are not definitions
|
||||
* Temporaries:: Temporaries may vanish before you expect
|
||||
* Copy Assignment:: Copy Assignment operators copy virtual bases twice
|
||||
@end menu
|
||||
|
||||
@node Static Definitions
|
||||
@ -1746,6 +1747,61 @@ string& tmp = strfunc ();
|
||||
charfunc (tmp.c_str ());
|
||||
@end example
|
||||
|
||||
@node Copy Assignment
|
||||
@subsection Implicit Copy-Assignment for Virtual Bases
|
||||
|
||||
When a base class is virtual, only one subobject of the base class
|
||||
belongs to each full object. Also, the constructors and destructors are
|
||||
invoked only once, and called from the most-derived class. However, such
|
||||
objects behave unspecified when being assigned. For example:
|
||||
|
||||
@example
|
||||
struct Base@{
|
||||
char *name;
|
||||
Base(char *n) : name(strdup(n))@{@}
|
||||
Base& operator= (const Base& other)@{
|
||||
free (name);
|
||||
name = strdup (other.name);
|
||||
@}
|
||||
@};
|
||||
|
||||
struct A:virtual Base@{
|
||||
int val;
|
||||
A():Base("A")@{@}
|
||||
@};
|
||||
|
||||
struct B:virtual Base@{
|
||||
int bval;
|
||||
B():Base("B")@{@}
|
||||
@};
|
||||
|
||||
struct Derived:public A, public B@{
|
||||
Derived():Base("Derived")@{@}
|
||||
@};
|
||||
|
||||
void func(Derived &d1, Derived &d2)
|
||||
@{
|
||||
d1 = d2;
|
||||
@}
|
||||
@end example
|
||||
|
||||
The C++ standard specifies that @samp{Base::Base} is only called once
|
||||
when constructing or copy-constructing a Derived object. It is
|
||||
unspecified whether @samp{Base::operator=} is called more than once when
|
||||
the implicit copy-assignment for Derived objects is invoked (as it is
|
||||
inside @samp{func} in the example).
|
||||
|
||||
g++ implements the "intuitive" algorithm for copy-assignment: assign all
|
||||
direct bases, then assign all members. In that algorithm, the virtual
|
||||
base subobject can be encountered many times. In the example, copying
|
||||
proceeds in the following order: @samp{val}, @samp{name} (via
|
||||
@code{strdup}), @samp{bval}, and @samp{name} again.
|
||||
|
||||
If application code relies on copy-assignment, a user-defined
|
||||
copy-assignment operator removes any uncertainties. With such an
|
||||
operator, the application can define whether and how the virtual base
|
||||
subobject is assigned.
|
||||
|
||||
@node Protoize Caveats
|
||||
@section Caveats of using @code{protoize}
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user