«

On Wed, 22 Sep 2004 14:02:56 GMT, JKop <> wrote:


>
>As regards pointers... well let's say that on a certain system, a pointer
>variable takes up 32 bits in memory, as so:
>
>
>0000 0000 0000 0000 0000 0000 0000 0000
>
>
>What you're looking at above is "all bits zero". On Windows, this indicates
>that the pointer is a null pointer. Now imagine a system where the memory
>address 0 is a valid one, ie. it's the first byte of memory, and that on
>this particular system, the null pointer value is:
>
>1111 1111 1111 1111 1111 1111 1111 1111
>
>
>When you write a program with the following line in it:
>
>
>int* p_k = 0;
>
>The compiler doesn't produce code that sets all bits to zero... no no...
>what it does is produce code that sets it to the null pointer value for that
>system (and/or for that type, I believe systems may choose to have different
>null pointer values depending on the type...). But "memset" doesn't have a
>clue about this, all it does is set all bits to zero, which may be a valid
>memory address on some systems, hence it's not portable.
>
>And as regards floating point numbers, implementations aren't obligated to
>represent the value zero as "all bits zero" either.
>
>I don't see how either of the three could be slower/faster than each other,
>they should all yield the same machine code (except maybe the call to
>"memeset" might add overhead if it's not inline...)
>
>
>-JKop



Thank you. Very clear now on why not to always rely on memset.

-Nollie