bcopy

[deepak]

Hello,

In the below program bcopy of 'b=c' is more preferable?
I would like to know the advantage one over other if any.

struct test {
int value;
};

struct test b;
struct test c;

main()
{
b.value = 100;

b = c;
}

Thanks,
Deepak

 

[Ian Collins]

Hello,

In the below program bcopy of 'b=c' is more preferable?

No, let the compiler do its job.

I would like to know the advantage one over other if any.

bcopy isn't a standard C function. The compiler will know how to copy
an object, any generic function will not.

 

[Keith Thompson]

No, let the compiler do its job.


bcopy isn't a standard C function. The compiler will know how to copy
an object, any generic function will not.

Correct, bcopy isn't a standard C function. The standard equivalent is
memcpy or memmove, which will do the right thing if invoked correctly.

Should be "int main(void)".

The assignment
b = c;
could be replaced by
memcpy(&c, &b, sizeof c);
which has exactly the same effect. I consider the assignment to
be much better style; it's simpler and more straightforward, and
it's likely to give the compiler more opportunities for optimization.

 

[Ian Collins]

Correct, bcopy isn't a standard C function. The standard equivalent is
memcpy or memmove, which will do the right thing if invoked correctly.

I should have said "how to copy an object in the most efficient manner"

 

[Nick Keighley]

more preferable than what?

Correct, bcopy isn't a standard C function.  The standard equivalent is
memcpy or memmove, which will do the right thing if invoked correctly.


Should be "int main(void)".


The assignment
    b = c;
could be replaced by
    memcpy(&c, &b, sizeof c);
which has exactly the same effect.

is it guarenteed to copy all the padding bits? Can we be sure that...

struct test b;
struct test c;

c.value = 99;

b = c;

if (memcmp (b, c, sizeof(b)) == 0)
printf ("they match!\n");
else
printf (":-(\n");

....will find a match?

 

[Malcolm McLean]

The assignment
    b = c;
could be replaced by
    memcpy(&c, &b, sizeof c);
which has exactly the same effect.  I consider the assignment to
be much better style; it's simpler and more straightforward, and
it's likely to give the compiler more opportunities for optimization.

The rule in C is that each statement compiles to only a trivial number
of machine instructions. Structure assignment is the one place where
this rule is broken, not most of the time, because assignment is
simple and most structures are small, but occasionally can represent a
huge processor hit.
memcpy() keeps the rule as is. It means that the possibility of a
nasty long operation is clearly flagged.

 

[Nick Keighley]

Which just goes to show that memcmp
isn't the way to compare two structs.

and that b = c does not have "exactly the same effect" as
memcpy(&c, &b, sizeof c)

 

[Keith Thompson]

more preferable than what?

I think the question was whether bcopy is preferable to 'b=c'.

[...]

is it guarenteed to copy all the padding bits?

No. This is unlikely to matter, but you're right, it doesn't
necessarily have "exactly the same effect".

[...]

 

[Malcolm McLean]

and that b = c does not have "exactly the same effect" as
memcpy(&c, &b, sizeof c)- Hide quoted text -

That's a good case against memcpy(). It's not obvious which way the
arguments should go.

 

[Jorgen Grahn]

The rule in C is that each statement compiles to only a trivial number
of machine instructions. Structure assignment is the one place where
this rule is broken, not most of the time, because assignment is
simple and most structures are small, but occasionally can represent a
huge processor hit.

I'm sure some people think about it like that, but there is no such
rule as far as I know. Other exceptions include floating-point on a
machine without an FPU, and arithmetic (especially division etc) on
quantities larger than what your CPU provides instructions for.

memcpy() keeps the rule as is. It means that the possibility of a
nasty long operation is clearly flagged.

But it also obfuscates code, sometimes making it much less readable.
It's not just & and the sizeof -- the reader also cannot rely on the
type checking.

/Jorgen

 

[Nick]

I'm sure some people think about it like that, but there is no such
rule as far as I know. Other exceptions include floating-point on a
machine without an FPU, and arithmetic (especially division etc) on
quantities larger than what your CPU provides instructions for.


But it also obfuscates code, sometimes making it much less readable.
It's not just & and the sizeof -- the reader also cannot rely on the
type checking.

It is something of an anomaly that:

char x[100];
char y[100];

/* put something in y ... */
x = y;

doesn't do what you'd expect, but

struct astr {
char a[100];
} x,y;

/* put something in y.a ... */
x = y;

does.

 

[Keith Thompson]

It is something of an anomaly that:

char x[100];
char y[100];

/* put something in y ... */
x = y;

doesn't do what you'd expect, but

Yes it does, but I expect it to produce a compile-time error message.
}

struct astr {
char a[100];
} x,y;

/* put something in y.a ... */
x = y;

does.

In earlier versions of C, only pointers and arithmetic types could be
assigned (see K&R1); neither arrays nor structs were first-class
types in that sense.

The ability to assign structs and to return them from functions was
added later (shortly after K&R1, I think); this was possible because
the new semantics didn't conflict with anything. But since array
expressions usually decay to pointers, there was no good way to add
array assignment to the language without breaking existing code.
For that matter, it wouldn't have been all that useful without a
lot of language redesign; most code that handles arrays needs to
deal with varying sizes.

 

[Nick]

In earlier versions of C, only pointers and arithmetic types could be
assigned (see K&R1); neither arrays nor structs were first-class
types in that sense.

I'm pretty sure that the first version of C I used didn't allow structure
copying. I don't think anyone's mentioned it before you, but I do
wonder if that's behind whatever prompted the OP's question.

The ability to assign structs and to return them from functions was
added later (shortly after K&R1, I think); this was possible because
the new semantics didn't conflict with anything. But since array
expressions usually decay to pointers, there was no good way to add
array assignment to the language without breaking existing code.
For that matter, it wouldn't have been all that useful without a
lot of language redesign; most code that handles arrays needs to
deal with varying sizes.

The semantics argument is a good one and one I'd not thought of.