NULL?

NO they are not.

Not usually. They''re set to whatever garbage happened to be in that chunk of memory when it got allocated. Set them yourself in your constructor to avoid serious headaches.

-fel

Thanks everyone. That is what I thought, but I wanted to be sure.

Um, let me think...NOOO!!! Sorry, don''t mean to be rude:D. Whenever a pointer is created, it points to "garbage" data. To get around this, YOU MUST always initialize it yourself. EG. char *ptrString = 0; will create a char pointer ptrString and set it to NULL. If you were to just call char *ptrString; It points to invalid data. There are some valid exceptions to not always initializing pointers, such as declaring variables/objects in classes. Hope this helps

Technically you don''t want to ever assume that 0 == NULL. While 0x00000 is the address representation of NULL in most machines, that''s not necessarily a "standard" by any stretch. NULL is a defined value that is simply set aside to represent "unassigned pointer". NULL could be 0x999999 or 0x1290374... it''s all in the define.

-fel

fel? heh, i thought you were dead...jeez, you certainly took your pretty time gettin'' back to us

SuperRoy: Actually I''ve been pretty active deleting help wanted posts and booting things to the lounge (which, if I''m doing well, you''ll never notice *grin*), and I''ve answered a few things lately. I''ve been busy though, having just gotten a new job and moved, and I don''t have an internet connection at home yet (I''ll have cable the 19th), so I haven''t had a lot of time to post.

-fel

Hey guys, you are not being too precise here.

It is true that dynamically allocated data and locally allocated data is not initialized.

But statically globally allocated data is. Global static data (i.e. variables at global scope) is initialized when the application is started. If no explicit initialization is provided the variable is initialized to 0 - and this goes for both floating point numbers, integers and pointers.

This is explained in detail in Stroustrup's The C++ Programming Language page 217.

[edited by - felonius on June 12, 2002 4:35:28 PM]

fel: well it''s good to see you back.

woohoo! guess who''s got a new video and sound card ''cos it was his birthday on the tenth! booyeah...now to install....

That just leads us to the "global variables BAD" area of discussion felonius... and it''s good practice to always initialize your variables, which is why I said "not usually" rather than "no". *grin*

-fel

quote:

---

Original post by felisandria
That just leads us to the "global variables BAD" area of discussion felonius... and it''s good practice to always initialize your variables, which is why I said "not usually" rather than "no". *grin*

-fel

---

I agree completely - and as somebody pointed out, just because a variable is initialized to 0, doesn''t mean that this is the correct bitpattern for a NULL-pointer - but on all the computers I have programmed for it is true (M68000, x86, MIPS, Alpha). I just wanted to point this detail out since everybody seemed to cry out that variables was never initialized - and that is not true.

Stroustrup also says:
"Because of C++''s tighter(than C) type checking, the use of plain 0, rather than any suggested NULL macro, leads to fewer problems."
5.1.1

but... I can''t agree or disagree, because I rarely use C++.

So if some moron was to build a system where the base NULL address is not 0x00000000, it would break every piece of C/C++ code in existence, not to mention the current standard headers for C/C++?

____________________________________________________________
Direct3D vs. OpenGL

quote:

---

Original post by Promit
So if some moron was to build a system where the base NULL address is not 0x00000000, it would break every piece of C/C++ code in existence, not to mention the current standard headers for C/C++?

---

Not really. But if you tried to run the executable for machine A on machine B, you would have problems. However, if machine B does not have 0 as its NULL address, the C/C++ compiler would have NULL defined properly, and not as the NULL address on machine A. That code snippit you gave is from a compiler written for machine A. The compiler would also know that if you assigned 0 to a pointer, it should be the NULL address, and cast it to the appropriate bit-pattern of the NULL address.

BTW!!!! That's just my opinion of how things would work. What I just said could be a load of bull, and I'm waiting for somebody to call me an idiot.

EDIT: Yeah, what the AP above me said...


[edited by - Thrump on June 13, 2002 11:54:27 AM]

From what I understand, the compilers are actually the NULL-enforcers (as any *actual* data contained in a machine''s 0x000000 memory register would be entirely ignored, if the compiler define sets aside 0x00000 as the NULL). So if someone were to build a compiler where they define something other than 0x00000 as NULL, then you would probably have problems. It is, after all, the compiler, not the hardware, that screams bloody murder if you try to set the 0x000000 address to something.

-fel

quote:

---

Original post by felisandria
It is, after all, the compiler, not the hardware, that screams bloody murder if you try to set the 0x000000 address to something.

---

It''s actually the "implementation" which is affected by this - at the time a program is run, there is no compiler present to complain. Under most circumstances I can think of, it would be the OS that would catch the "access violation" or "GPF". There might even be an implementation where it is desirable to write to the address represented by 0, which is why the C++ Standard does not attempt to define the behaviour resulting from dereferencing a null pointer.

Additionally, there is nothing to say that 0 be all bits zero, just that the bit pattern is consistent with the implementation''s representation of zero. At the source level, there''s no need to concern ourselves with what that bit pattern might be.

quote:

---

Original post by SabreMan
[quote]Original post by felisandria
It is, after all, the compiler, not the hardware, that screams bloody murder if you try to set the 0x000000 address to something.

---

It''s actually the "implementation" which is affected by this - at the time a program is run, there is no compiler present to complain. Under most circumstances I can think of, it would be the OS that would catch the "access violation" or "GPF", but it could affect the h/w if the OS doesn''t trap it. There might even be an implementation where it is desirable to write to the address represented by 0, which is why the C++ Standard does not attempt to define the behaviour resulting from dereferencing a null pointer.

Additionally, there is nothing to say that 0 be all bits zero, just that the bit pattern is consistent with the implementation''s representation of zero. At the source level, there''s no need to concern ourselves with what that bit pattern might be.

True, but it''s just a definition of address. If someone wants to try, they can attempt an override of the standard definition of NULL and see if it works.

There are really two parts to the NULL definition, one being that it''s assigned as such to be interpreted as "unassigned pointer", and the second being that the machine itself is prohibited from putting any "real" data at the address assigned to NULL. The hardware cannot be affected because the hardware really couldn''t care less what you set the gate states to. If you are capable of, in your own program, setting an "unassigned pointer" other than the 0x0000 address and forcing variables to *not* be assigned to the address you choose, then you would be able to merrily define NULL as anything you please (provided, of course, that you do not assign it to an address beyond the range of your machine''s capabilities.)

The question, then, is whether the actual implementation that both assigns the NULL address, and prohibits your particular program from using the address assigned to NULL, is part of your program, or part of the OS, because the hardware doesn''t really care. There are only so many wires going into the hardware to ask it for an address (and, consequently, the RAM''s concept of the actual "address" for itself often differs from the OS''s concept of that "address"... because you can throw in multiple RAM pieces, so it has to be resolved by the motherboard and OS according to slot. From the RAM hardware''s perspective, it has a lot of gates in a grid that can be "on" or "off", and that''s about it. Retrieval is done by checking voltage levels at intersections.)

-fel

quote:

---

Original post by felisandria
True, but it''s just a definition of address. If someone wants to try, they can attempt an override of the standard definition of NULL and see if it works.

---

I''m not sure I understand what you mean? Are you saying to define NULL as, for example:

const int NULL = 1;

and see what happens? The results are fairly obvious - 1 is an integral constant with no implicit conversion to pointer type, so a compiler diagnostic is required.

quote:

---

There are really two parts to the NULL definition, one being that it''s assigned as such to be interpreted as "unassigned pointer"

---

That''s the only definition that matters to C++.

quote:

---

and the second being that the machine itself is prohibited from putting any "real" data at the address assigned to NULL.

---

Which machine? All machines or the ones you know?

quote:

---

The hardware cannot be affected because the hardware really couldn''t care less what you set the gate states to.

---

If the OS doesn''t stop you from writing to a memory address, then you are writing directly to memory. That memory might be mapped.

quote:

---

If you are capable of, in your own program, setting an "unassigned pointer" other than the 0x0000 address and forcing variables to *not* be assigned to the address you choose, then you would be able to merrily define NULL as anything you please

---

No, the C++ Standard requires you define it as zero. Whether the bit pattern of that zero is all bits zero or not is for the implementation to decide. C++ couldn''t care, and neither could I.

quote:

---

The question, then, is whether the actual implementation that both assigns the NULL address, and prohibits your particular program from using the address assigned to NULL, is part of your program, or part of the OS

---

Since C++ leaves this undefined, it is possible the compiler adds logic to the program to trap the illegal access. Alternately, the hosted environment (read "OS") which executes the program might trap it. If the OS does not trap it, then you write directly to the memory address represented by "0" - the results will then depend upon how the h/w reacts to that.