OpenE2K
/
gcc
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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:
Martin v. Löwis 1999-03-26 00:58:14 +00:00 committed by Martin v. Löwis
parent dd4b5f0d25
commit 5197829d3c
4 changed files with 72 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
gcc/ChangeLog
View File

@ -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.

4
gcc/cp/ChangeLog
View File

@ -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.

31
gcc/cp/gxxint.texi
View File

@ -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
View File

@ -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}