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

c++: Fix docs on assignment of virtual bases [PR60318] 

The description of behaviour is incorrect, the virtual base gets
assigned before entering the bodies of A::operator= and B::operator=,
not after.

The example is also ill-formed (passing a string literal to char*) and
undefined (missing return from Base::operator=).

Signed-off-by: Jonathan Wakely <jwakely@redhat.com>

gcc/ChangeLog:

	PR c++/60318
	* doc/trouble.texi (Copy Assignment): Fix description of
	behaviour and fix code in example.
This commit is contained in:
Jonathan Wakely 2021-08-31 09:46:41 +01:00
parent e66b9f6779
commit 3c64582372
1 changed files with 4 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
gcc/doc/trouble.texi
View File

@ -865,10 +865,11 @@ objects behave unspecified when being assigned. For example:
@smallexample
struct Base@{
char *name;
Base(char *n) : name(strdup(n))@{@}
Base(const char *n) : name(strdup(n))@{@}
Base& operator= (const Base& other)@{
free (name);
name = strdup (other.name);
return *this;
@}
@};
@ -901,8 +902,8 @@ 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 more than once. In the example, copying
proceeds in the following order: @samp{val}, @samp{name} (via
@code{strdup}), @samp{bval}, and @samp{name} again.
proceeds in the following order: @samp{name} (via @code{strdup}),
@samp{val}, @samp{name} again, and @samp{bval}.
If application code relies on copy-assignment, a user-defined
copy-assignment operator removes any uncertainties. With such an