 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Right. That's what I figured.
And the first thing listed in the union is what gets initialized to the
appropriate type of zero if it's static. So if you have
static union {
double * dp;
long l;
} X;
static union {
long l;
double * dp;
} Y;
then X and Y might start out with different bit patterns if the "null"
pointer on that platform isn't all zero bits.
>>> Does C++ have a concept of a "null pointer" - i.e., a pointer that
>>> doesn't point to anything valid, and can be detected as such?
>>
>> Yes: 0.
>
> So I say "int *x = 0;" and then later I can check that "if (x == 0) ..."?
Yes. Note that in each case, that's technically a cast. The bit pattern
of the pointer doesn't have to be zeros. If it's a null pointer, casting
it to an integer gives you zero, and casting the integer 0 to a pointer
gives you null.
At least in C, the "NULL" macro is more commonly used to me "a pointer
that when cast to an integer yields zero." I think C++ changed this
when it improved the type system.
> Does C++ check whether a pointer you're deferencing is zero? Or will it
> just segfault?
It segfaults, if you're on a machine that can do that. :-)
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> Does C++ check whether a pointer you're deferencing is zero? Or will it
> just segfault?
I don't remember for sure, but I think that the standard might say
something that if you access the data behind a null pointer the program
will be terminated.
At least in practice this is so in all the most common systems.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > So I say "int *x = 0;" and then later I can check that "if (x == 0) ..."?
> Yes. Note that in each case, that's technically a cast. The bit pattern
> of the pointer doesn't have to be zeros. If it's a null pointer, casting
> it to an integer gives you zero, and casting the integer 0 to a pointer
> gives you null.
> At least in C, the "NULL" macro is more commonly used to me "a pointer
> that when cast to an integer yields zero." I think C++ changed this
> when it improved the type system.
The next C++ standard will actually introduce the keyword nullptr
to better disambiguate between the integer 0 and the null pointer.
Currently if you have this:
#include <cstddef>
void foo(int);
void foo(int*);
void main()
{
foo(NULL);
}
the foo(int) function will be called (and the compiler might give you a
warning about this if it's smart enough).
With the next standard you can write:
foo(nullptr);
and the foo(int*) function will be called.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> the foo(int) function will be called (and the compiler might give you a
> warning about this if it's smart enough).
Ah! OK. I wondered why C++ had bothered to change this, but now it makes
sense, yes.
Actually, many times I've seen NULL defined as
#define NULL ((void*)0)
I'm not sure which (if either) such a thing would match in your C++ example.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I don't remember for sure, but I think that the standard might say
> something that if you access the data behind a null pointer the program
> will be terminated.
I would be surprised if running off the end of an array is undefined but
accessing the null pointer is defined. It would prevent C++ from being
standards-compliant in lots of places that don't have memory management
hardware. I wouldn't be surprised if the number of such systems actually
outnumbers the number of systems *with* memory protection, once you
start counting cell phones, microwave ovens, televisions, etc.
However, you may very well be right. I'm just guessing from
what-should-be-reasonable. :-)
> At least in practice this is so in all the most common systems.
Most common desktop systems, yes. I suspect this is more a POSIX thing
than a C++ thing, really.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Actually, many times I've seen NULL defined as
> #define NULL ((void*)0)
> I'm not sure which (if either) such a thing would match in your C++ example.
The problem with that is that void* is not implicitly castable to any
other pointer type in C++ due to C++ having stricter implicit casting
rules than C.
You might try some clever tricks using templates and type conversion
operators, but then you will probably stumble accross problems with
method pointers and member variable pointers (which are one of the most
obscure features of C++).
'nullptr' will be a generic null pointer which is implicitly convertible
to any other pointer type.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 24 Sep 2008 19:53:49 +0200, Warp <war### [at] tagpovrayorg> wrote:
> I don't remember for sure, but I think that the standard might say
> something that if you access the data behind a null pointer the program
> will be terminated.
It does not. Dereferencing a null pointer has undefined behaviour.
> At least in practice this is so in all the most common systems.
Because it is enforced by the OS.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> My understanding is that when you create variables, they start off
> containing junk unless you initialise them (or their types have
> constructors which initialise them to something specific). Is that correct?
I may be wrong, but I believe all variables declared outside of a
function have default values.
--
For Sale: Parachute. Only used once, never opened, small.
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz wrote:
> I may be wrong, but I believe all variables declared outside of a
> function have default values.
More exactly, in C at least, any variables allocated statically start
with a default value of zero appropriate for their type. That includes
static variables allocated inside a function.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Mueen Nawaz wrote:
> > I may be wrong, but I believe all variables declared outside of a
> > function have default values.
> More exactly, in C at least, any variables allocated statically start
> with a default value of zero appropriate for their type. That includes
> static variables allocated inside a function.
It would be interesting to see a quote from the C standard.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
