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.

diff --git a/gcc/doc/trouble.texi b/gcc/doc/trouble.texi
index 40c51ae..8b34be4 100644 (file)
--- a/gcc/doc/trouble.texi
+++ b/gcc/doc/trouble.texi
@@ -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