is this guaranteed to work as expected (to output 23 34)? This question refers to the validity of copying structs to structs.thanks!Code:struct fg { int a,b; }; int main(void) { struct fg d,f; d.a=23; d.b=34; f=d; printf("%d %d\n", f.a,f.b); return 0; }
Last edited by robwhit; 06-23-2007 at 04:08 PM. Reason: main+=void
When copying structs, all members are copied, so the above would print what you would expect it to (the f.a and f.b will be the same as d.a, d.b). However, it gets tricky when using pointers as pointer members in a struct will be copied, but not their actual contents. In OOP this is commonly referred to as a "shallow copy", so usually, for advanced structures, you may want to implement your own copy function.
Edit: almost forgot to point out:Code:int main(void)
thanks!
although your phrasing brings up another question: are the padded areas also copied, or is that like undefined or something?
Padding for the new struct would be created as needed, but I am pretty sure the "values" of the padded bytes would not be copied over (since they are not really considered a part of the struct).
Or they can be copied as well if some memmove underlying mechanism was choosen by the compiler... But what's the point? You anyway cannot access these areas legally in your code, so why bother?Originally Posted by @nthony
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
memcmp() will fail if the padded bytes are not copied. Hence, partly why you need to take care in your comparisons of structs and make sure your comparisons are explicit based upon the members of the struct.
Who said you can use memcmp to compare structs?
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
Nobody, but you asked why it matters if the padded bytes were copied. I provided a scenario where using memcmp() might or might not work depending upon the implementation of the memory copying method the implementation uses.
ok so how about thisdoes this copy that padding in the struct? or just the members? does it copy the padding in the union at the end? is there padding at the end or do the structs fill it out? if they do, can I count on them always filling them out?Code:union gh { struct fg d; struct hj b; } rt, ty; int main(void) { /* fill rt */ ty = rt; /* do stuff */ return 0; }
if the two structs were the same size, would this work? (just from a data integrity standpoint)Code:ty=(union gh)rt.d; /*access ty.b*/
For
u = t;
It would depend on which member is used in t. The compiler could change this instruction to do the same as u.m = t.m; and be logically consistent. It's not really an assignment that handles all of u's possible fields, just one. The underlying representation of u wouldn't change drastically, if at all.
And if you wanted to change the field in use, the only safe thing to do is access and assign individual members. Again in that case, u.n = t.n; is consistent with what you want to do.
