copying structs?

This is a discussion on copying structs? within the C Programming forums, part of the General Programming Boards category; is this guaranteed to work as expected (to output 23 34)? This question refers to the validity of copying structs ...

  1. #1
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129

    copying structs?

    is this guaranteed to work as expected (to output 23 34)? This question refers to the validity of copying structs to structs.
    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;
    }
    thanks!
    Last edited by robwhit; 06-23-2007 at 04:08 PM. Reason: main+=void

  2. #2
    Registered Abuser
    Join Date
    Jun 2006
    Location
    Toronto
    Posts
    591
    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)

  3. #3
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    thanks!

    although your phrasing brings up another question: are the padded areas also copied, or is that like undefined or something?

  4. #4
    Registered Abuser
    Join Date
    Jun 2006
    Location
    Toronto
    Posts
    591
    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).

  5. #5
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,484
    Quote Originally Posted by @nthony View Post
    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?
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  6. #6
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,211
    Quote Originally Posted by vart View Post
    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?
    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.

  7. #7
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,484
    Quote Originally Posted by MacGyver View Post
    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?
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  8. #8
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,211
    Quote Originally Posted by vart View Post
    Who said you can use memcmp to compare structs?
    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.

  9. #9
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129

    unions

    ok so how about this
    Code:
    union gh
    {
        struct fg d;
        struct hj b;
    } rt, ty;
    
    
    int main(void)
    {
        /* fill rt */
        ty = rt;
        /* do stuff */
    
        return 0;
    }
    does 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?

    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*/

  10. #10
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,706
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Creating array of structs
    By knirirr in forum C++ Programming
    Replies: 12
    Last Post: 06-18-2008, 08:30 AM
  2. Multidimentional structs + memcpy() == FAIL
    By Viper187 in forum C Programming
    Replies: 8
    Last Post: 06-18-2008, 02:46 AM
  3. packed structs
    By moi in forum C Programming
    Replies: 4
    Last Post: 08-20-2002, 01:46 PM
  4. ArrayLists + Inner Structs
    By ginoitalo in forum C# Programming
    Replies: 5
    Last Post: 05-09-2002, 05:09 AM
  5. Searching structs...
    By Sebastiani in forum C Programming
    Replies: 1
    Last Post: 08-25-2001, 12:38 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21