ce there a bunch of places
we're doing memcpy()s with math for multiple structs. I'll work on
that today. Getting rid of the math may be the best reason to use a
macro yet.
Andy
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Andy Lester wrote:
I guess I don't see the need to document a standard C behavior with a
macro.
If you had read all the way through the message, you would see that the
biggest benefit is the ability to hang debugging hooks off the macro.
We have a number of these kinds of debugging hooks t
On Jun 20, 2007, at 1:05 PM, Mark J. Reed wrote:
Incrementing a var is much less likely to have unpredictable effects
due to modifying the wrong memory. Sure, x might be a pointer, and
things might gang agley there, but pointers getting set to the wrong
type of pointee is a pretty common probl
On 6/20/07, Andy Lester <[EMAIL PROTECTED]> wrote:
My point is that
*d = *s;
is no more a weird cryptic construct than
n++;
or
while (*s)
*d++ = *s++;
for that matter.
That's a very good point. As you said in the original message, all you need is
*dest = *src;
since the c
On 6/20/07, Andy Lester <[EMAIL PROTECTED]> wrote:
I guess I don't see the need to document a standard C behavior with a
macro. We don't have
#define inc(x) (x)++
do we?
Incrementing a var is much less likely to have unpredictable effects
due to modifying the wrong memory. Sure, x might
On Jun 20, 2007, at 11:50 AM, Allison Randal wrote:
I wasn't entirely happy with either option, so I asked around a bit
for other ideas. I like the macro approach below, it gives us both
self documentation and better checking for the size of the two
structs.
I guess I don't see the need
TED]>
To: Allison Randal <[EMAIL PROTECTED]>
This can be a bit brittle -- you have to be careful when changing the
type of dst else you could end up with over or underflow.
memcpy(dst, src, sizeof(FOO));
I do like memcpy because it serves as a red flag that a potentially
medium to large si
Am Montag, 18. Juni 2007 23:48 schrieb Andy Lester:
> Is there a reason we use
>
> memcpy( dest, src, sizeof(FOO) );
>
> instead of
>
> *dest = *src;
>
> The latter should be the exact same code, but be much less likely to
> be screwed up.
I'm usin
On 19 Jun 2007, at 08:48, Joshua Isom wrote:
On Jun 18, 2007, at 4:48 PM, Andy Lester wrote:
Is there a reason we use
memcpy( dest, src, sizeof(FOO) );
instead of
*dest = *src;
The latter should be the exact same code, but be much less likely
to be screwed up.
No, they're extr
On Jun 18, 2007, at 4:48 PM, Andy Lester wrote:
Is there a reason we use
memcpy( dest, src, sizeof(FOO) );
instead of
*dest = *src;
The latter should be the exact same code, but be much less likely to
be screwed up.
No, they're extremely different. In the first, the data of F
Is there a reason we use
memcpy( dest, src, sizeof(FOO) );
instead of
*dest = *src;
The latter should be the exact same code, but be much less likely to
be screwed up.
At the very least we should be using:
memcpy( dest, src, sizeof(*dest) );
Of course, I'm only talking about
11 matches
Mail list logo
