(struct) a= (struct) b ; ANSI C ?

[mynickmynick]

I have been told and I realized myself that in many C situations if i have two structs of the same kind I can assing one another and what will happen will be a corresponding assignment member by member ( field by field)

But the question is :
(1) Is it quite general?
(2) Is it ANSI C ?

Thank you

[matsp]

You have two VARIABLES of the same struct, you can assign them.

If there are two structures with the same content, they are, in the view of the compiler, different types, and can't be assigned directly. Why would you want that? You either use the same struct, or don't.

--
Mats

[itCbitC]

I have been told and I realized myself that in many C situations if i have two structs of the same kind I can assing one another and what will happen will be a corresponding assignment member by member ( field by field)

But the question is :
(1) Is it quite general?
(2) Is it ANSI C ?

Thank you

Yep, you can assign variables that are of the same struct type as it's syntactically analogous to assignment between any basic type like char, int, or float.

[Salem]

But watch out for structs containing pointers.

You end up with "shallow" aliases of the pointers, not "deep" copies of the what the pointers point to.

[Sharke]

But watch out for structs containing pointers.

You end up with "shallow" aliases of the pointers, not "deep" copies of the what the pointers point to.

What is a "shallow" alias of a pointer? And why would you want a deep copy of what they point to? As long as it's a pointer of the same type then it's exactly the same as the other pointer in terms of its value and what it points to, is it not?

[Salem]

struct foo {
   char *shallow;
};

struct foo a, b;

a.shallow = malloc(10);
b = a;
free( a.shallow );
// now b is up the creek without a paddle, pointing to deallocated memory

[nonoob]

But Salem, sir, a.shallow is also pointing at deallocated memory. Whoopteedoo.

I thought with your warning of "shallow alias" you might be alluding to some compiler optimization issue.

As for the original problem: (struct) a= (struct) b...

I use such casting when I know there is a fixed array size. So a typedef of a struct of said size, casting both sides, and assignment is the trick to get the compiler to issue inline machine-level block moves without calling a memcpy() function.

Darn, there goes one of my patented uber-cool techniques.

[laserlight]

a.shallow is also pointing at deallocated memory

But it is easy to see that a.shallow points to deallocated memory, and in fact one can just turn it into a null pointer.

[matsp]

I use such casting when I know there is a fixed array size. So a typedef of a struct of said size, casting both sides, and assignment is the trick to get the compiler to issue inline machine-level block moves without calling a memcpy() function.

Darn, there goes one of my patented uber-cool techniques.

memcpy() is often better [faster/more optimized] than the corresponding inlined struct copy code, unless the compiler inlines the memcpy in the first place, in which case all you have gained is a bit of obfucation.

If the data is really short, the compiler SHOULD be able to inline the memcpy itself.

--
Mats

[jim mcnamara]

deep copies refer to allocating memory and copying the contents of allocated objects into the destination pointer's allocated memory.
i.e.,
b.shallow needs it own separate chunk of allocated memory, with a copy of whatever was in a.shallow placed in that memory.

[nonoob]

I doubt the compiler inlines the memcpy()... After all, it may or may not be standard C-library... so it may not resolve to something normal.

memcpy() or any function call needs at least stack push(s) and cleanup. Plus the call itself. The fact that the number-of-bytes to move is a variable is probably the same number of clocks these days as assigning a constant.

How can a memcpy() be any more optimized internally than an inline move of a fixed number of bytes?

[matsp]

1. The compiler CERTAINLY _WILL_ inline memcpy() - at least gcc and MS compilers do that. Sure, it can't ALWAYS do it - and the relevant header files will need to be included, sufficient optimization enabled, etc. But the compiler can, if it likes to, inline memcpy. Try it for yourself, and check the compiler generated code at various optimization levels and with/without the <string.h> header. memcpy() is commonly in the category of "intrinsic" functions - functions that the compiler itself KNOWS how they are implemented.

2. An optimized memcpy can do moves in bigger chunks than one or four bytes at a time (e.g. using SSE instructions and/or unrolling the loop), which is most likely what the inline version uses [at least on a 32-bit machine]. Using prefetch/block copying techniques are definitely faster than the trivial form produced by compilers [in my experience].

Obviously, _IF_ the compiler generates a proper call to memcpy then you are probably going to end up with a bit of overhead compared to the inline version.

However, the inline version in x86 probably uses the REP MOVS instruction, which requires certain registers to be used. Unless your function is really trivial, those registers are probably being used for somehting else, so even tho you are not making a call to another function, there are still push & pop instructions involved in getting the right data into the right registers and preserving the original content of those registers.

Obviously, which is better, inline or call to memcpy will depend on the size of the copy - for small copies, inline is probably faster. For larger blocks, I'm certain that the overhead of a call is better than the inline version.

The other question is of course why the fixed array isn't (part of) a struct in the first place - if that's how you are using it...

--
Mats