Quote:Original post by Spoonbender

Quote:
I would have, but my dead-tree-paste version is at home right now, so I don't have access to it, and it isn't legally available online as far as I know.

Isn't it? I found it available online in pdf format a while back. Was that illegal?
*feels guilty*

The actual standard isn't legally available for free, most (all?) of the drafts for the standards are available though, and they are pretty close to the actual standard.

Quote:
There may be something in the C++ standard which implicitely states that the representation is guarenteed to be 0,

It states that the value representation of pointers is implementation defined.

However, it is guaranteed that a constant expression that evaluates to zero (during assignment, initialization or comparison of a pointer) is converted to value (the null pointer) and that this value is guaranteed to be distinguishable from a pointer to anything else. This doesn't mean that that null pointer has the same bit pattern as zero, however.

So, in your case, memset() is not a safe way set the pointers to null, because it will simply copy the bitpattern of zero into them. Then need to explitly be assigned or initialized to zero. There's no other way.

EDIT: Eh, I was slow.

The truth is it doesn't matter what the C++ spec says, it all depends on what you actually need. Not to sound pessimistic but the truth is that to develop for all architectures is essentially impossible, since the various querks even in the compilers would make program maintenence a nightmare and not engineeringly 'sane'.

What I think you should do is decide whether to natively support architectures that use non 0 null pointers or whether to search for all usages of pointers at a later date to fix any issues caused by ignoring them.

If you decide to support them then just add a null definition to your project, this will work on almost all architectures (some operator overloading may be needed on more exotic machines for the operator == to work but that's ok). Otherwise use an is_null predicate for the best compatibility.

Of course if you only need to deal with 'real' systems that tend to maintain compatibility with more usual architectures then assuming 0 (and therefore also NULL) will suffice.

ps. on a side note you might want to see if the spec indicates whether pointer 'truth' value is always guarantee'd to be correct, but I believe it doesn't (unfortunately I don't have a copy of the spec).

Good Luck

Lorenz

edit: lol, i guess someone already got the answer in here anyway.

Quote:Original post by ToohrVyk
In C, the following code is not guaranteed to set the pointers a and b to NULL:

typedef struct { int *a, *b; } S;

int main() {
S s;
memset(&s,0,sizeof S);
}

Does this problem also exist in C++, or is the C++ standard also unspecific about NULL pointer representation?

Going back to the example then, the safe method(if the real version was as simple as this) would be:

Quote:
struct S
{
S():a(NULL),b(NULL){}
int* a,*b;
};

Oops

Quote:rvalue of integer type that evaluates to zero.

a(0),b(0) is valid

CTar, going to my std headers it has this written:
#define NULL (void*)0
So its not my fault it isnt actually "standard".

Quote:Original post by Anonymous Poster
CTar, going to my std headers it has this written:
#define NULL (void*)0
So its not my fault it isnt actually "standard".

But it is your fault you're using a broken compiler. You should consider updating. Even if the standard didn't explicitly outlaw that definition, it would still be invalid: implicit conversion from void* to other pointer types is not allowed.

Quote:
The truth is it doesn't matter what the C++ spec says, it all depends on what you actually need. Not to sound pessimistic but the truth is that to develop for all architectures is essentially impossible, since the various querks even in the compilers would make program maintenence a nightmare and not engineeringly 'sane'.

While true, you can go a long way by avoiding things that are obviously unsafe in favor of nice, well defined constructs. Using default constructors instead of memset isn't exactly bending over backwards for compatability purposes.

CM