In article <6dhdej$eiq$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com writes:
>In article <34F79644.292D@pratique.fr>, bonnardv@pratique.fr wrote:
>>I have a related question: why does the operator= of an union do ?

>A bitwise copy.  In C, all operator='s can use bitwise copy.  You cannot
>define it any other way.

In the draft for C9x, some work has been done to define characteristics
of representations as well as values.  If this kind of work has been
done in C++, and if bits have been defined as bits of the representation,
then it would make sense to define operator= as a bitwise copy in C++.

C89 defined everything in terms of values.  Therefore in C, bitwise
operations worked on mathematical-style bits of a value not representation.
It would not be appropriate to define C assignments in terms of bits.

To be practical and sensible, we *want* C assignments to be capable of
implementation as bitwise copies.  For C9x, the problem is how to define
the language so that this will be possible.

>>I can't find its definition in the draft.

>I'll admit that I haven't looked.

No kidding.  I looked in the C9x draft and couldn't find it.  No surprise,
since C89 doesn't define it either.

>>   union U { int i; float f; T t; };
>>   U u1, u2;
>>   u1 = u2;
>>Q1 Which member is copied ?

>Theoretically, I would guess that it is whichever member the object on
>the right hand side held.

As far as I can tell, theoretically, in C89 the answer is none.
Consider this:
     union U { int i; float f; } u1, u2;
     u1.f = 9.2;
     u2.i = 3;
     u1 = u2;
     printf("%f", u1.f);  /* Must print 9.2 in C89! */
     printf("%d", u1.i);  /* Prints an implementation defined value in C89 */

>>Q2 Does anyone care ?

>In practice, no.

In practice, C9x had better be fixed so that sensible implementations
will be conforming.  C89 has a big problem but it's hopeless to try
fixing C89.

If the situation is unclear, consider this simpler case:
     u1.i = 3;
     printf("%f", u1.f);
In C89, the printed value is implementation defined -- i.e. behavior is
not undefined.  Surely this is a problem.  The C9x draft is the same.
However, since C9x knows about trap representations, a proposal has been
made to delete the implementation defined bit from C9x.  Then conforming
implementations won't have to prevent u1.f from being a trap representation.

Next, consider whether the member of u1 that is being evaluated is the
same as the member of u1 that was last stored, or a different member than
the member of u1 that was last stored.  C89 only considers the values of
the members so the answer is clear and undesirable.

In C9x it is not quite clear if modifying the value of a union object
is defined as modifying one of its members.  Obviously a clear definition
must be added.  To figure out which member is copied seems to border on
magic, but it must be done.

--
 <<  If this were the company's opinion, I would not be allowed to post it.  >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]