------- Comment #5 from redi at gcc dot gnu dot org 2009-11-03 14:21 -------
(In reply to comment #4)
> > I'm not sure whether using A in a union causes the implicitly-declared copy
> > assignment operator to be implicitly defined, but that seems to be what's
> > happening.
>
> No, that's not quite it.
>
> The requirement for union members is that there cannot be a non-trivial copy
> assignment operator.
>
> gcc uses a different rule: it insists that there be a default copy assignment
> operator.
>
> Presumably someone thought those two formulations were the same.
Use the source, Luke:
if (TYPE_HAS_COMPLEX_ASSIGN_REF (type))
error ("member %q+#D with copy assignment operator not allowed in
union"
,
field);
/* Nonzero if there is a user-defined X::op=(x&) for this class. */
#define TYPE_HAS_COMPLEX_ASSIGN_REF(NODE) (LANG_TYPE_CLASS_CHECK
(NODE)->has_com
plex_assign_ref)
Now there could be a bug there, but it superficially looks right, and does not
look as though anyone thought the two formulations are the same.
> But they
> are not: struct A doesn't have a copy assignment operator at all.
It might not be defined, but one is declared, according to [class.copy]/10
"If the class definition does not explicitly declare a copy assignment
operator, one is declared implicitly."
> For the record, this kind of code occurs fairly naturally in C when creating
> trees with different node types, tagged here by "x". The problems arise when
> C++ code needs to interface with that C code.
The fact there are problems doesn't mean g++ is wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39934
