hitz@sim5.csi.uottawa.ca (Martin Hitz) (03/23/91)
I recently came across the following incompatibility between
C and C++:
If a structure X contains an array, then the assignment
struct X a, b;
/* ..... */
b = a;
is well defined in C and older C++ versions (bitwise copy).
Now, as C++ adopted the memberwise assignment semantics, it is not clear
to me what should happen, as there is no such thing as assignment to
arrays.
Trying doesn't help: The following program prints
1 1 1
with g++, and
0 0 0
with Zortech.
Can anybody tell me, which is correct?
#include <stdio.h>
struct X
{
int x[3];
};
main ()
{
X a, b;
a.x[0] = a.x[1] = a.x[2] = 1;
b.x[0] = b.x[1] = b.x[2] = 0;
b = a;
printf("%d %d %d\n", b.x[0], b.x[1], b.x[2]);
}jimad@microsoft.UUCP (Jim ADCOCK) (04/02/91)
In article <1991Mar22.172508.1881@csi.uottawa.ca> hitz@sim5.csi.uottawa.ca (Martin Hitz) writes: |I recently came across the following incompatibility between |C and C++: |If a structure X contains an array, then the assignment | | struct X a, b; | /* ..... */ | b = a; | |is well defined in C and older C++ versions (bitwise copy). | |Now, as C++ adopted the memberwise assignment semantics, it is not clear |to me what should happen, as there is no such thing as assignment to |arrays. I agree that ARM is not very clear on this issue. However, see section 12.8 Generated copy constructors and op= now use memberwise assignment. So the generated op= should come down to a part that does a: b.array = a.array; Which is undefined. Therefore, I claim that at compile-time the compiler should squawk that the array assignment is undefined in the generated copy constructor. One way around this dilemma would be for C++ to support the pure extension over C to allow array assignment. Such could be enabled in C++ since in C++ arrays and references to arrays include a concept of the size of the array. While some people would consider such an extension of the language, I would consider it as removing a special case from the language, and thus rather a *reduction* in the language. I support removing such special case "warts" from the language where it is possible to do so without being incompatible with existing programs, and where such removing such special cases from the language makes the language more orthogonal.
hitz@sim5.csi.uottawa.ca (Martin Hitz) (04/03/91)
In article <71616@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: >In article <1991Mar22.172508.1881@csi.uottawa.ca> hitz@sim5.csi.uottawa.ca (Martin Hitz) writes: >|I recently came across the following incompatibility between >|C and C++: >|If a structure X contains an array, then the assignment >| >| struct X a, b; >| /* ..... */ >| b = a; >| >|is well defined in C and older C++ versions (bitwise copy). >| >|Now, as C++ adopted the memberwise assignment semantics, it is not clear >|to me what should happen, as there is no such thing as assignment to >|arrays. > >I agree that ARM is not very clear on this issue. However, see section >12.8 > >Generated copy constructors and op= now use memberwise assignment. So >the generated op= should come down to a part that does a: > >b.array = a.array; > >Which is undefined. Therefore, I claim that at compile-time the compiler >should squawk that the array assignment is undefined in the generated >copy constructor. > >One way around this dilemma would be for C++ to support the pure extension over >C to allow array assignment. Such could be enabled in C++ since in C++ >arrays and references to arrays include a concept of the size of the >array. > [paragraph on benefits deleted] I asked Bjarne Stroustroup for his opinion on the assignment of arrays nested within structures: MH>What does "memberwise assignment" (in the absence of an explicit MH>assignment operator) mean for class members that are (ordinary) arrays? BS> that every element of the member array is copied. So, I believe it *is* defined (BTW, g++ did it correctly, Zortech did it wrong). However, to my knowledge the ARM lacks an explicit mention of the fact that memberwise assignment is *recursively* applied (which is implicitely clear for structures, but not for arrays). Martin (hitz@csi.UOttawa.CA)