Throwing auto_ptr

[Thomas Kowalski]

Hi everyone,
I currently was thinking whether the following is a good idea:
I want to have something like an auto_ptr that checks during the
dereferencing whether the pointer is null and throws something like a
NullPointerException. Does someone have some experiences with
something like this? In general is it a good idea at all?

Regards,
Thomas Kowalski

[Alf P. Steinbach]

* Thomas Kowalski:

Hi everyone,
I currently was thinking whether the following is a good idea:
I want to have something like an auto_ptr that checks during the
dereferencing whether the pointer is null and throws something like a
NullPointerException. Does someone have some experiences with
something like this? In general is it a good idea at all?

Better have it terminate the program. Even better, do the checking only
in the constructor and make it immutable.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[James Kanze]

On Apr 2, 12:09 pm, "Alf P. Steinbach" <[e-mail]:

* Thomas Kowalski:

I currently was thinking whether the following is a good idea:
I want to have something like an auto_ptr that checks during the
dereferencing whether the pointer is null and throws something like a
NullPointerException. Does someone have some experiences with
something like this? In general is it a good idea at all?

Better have it terminate the program. Even better, do the checking only
in the constructor and make it immutable.

Isn't that just what a reference does. (Some compilers omit the
checking, but there's no reason to. From a quality of
implementation point of view, they should check. I guess most
just consider that the code's going to blow up fast enough
anyway.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Alf P. Steinbach]

* James Kanze:

On Apr 2, 12:09 pm, "Alf P. Steinbach" <[e-mail]:

>* Thomas Kowalski:

>>I currently was thinking whether the following is a good idea:
I want to have something like an auto_ptr that checks during the
dereferencing whether the pointer is null and throws something like a
NullPointerException. Does someone have some experiences with
something like this? In general is it a good idea at all?

>Better have it terminate the program. Even better, do the checking only
in the constructor and make it immutable.

Isn't that just what a reference does.

Nope. A reference does not provide any guaranteed null-reference
checking: it's like a cast in that it says "I guarantee that this
assumption (of validity) holds". And it doesn't support checking for
nullness yourself, for if you have a null-reference on hand you're
already in Undefined Behavior land.

A smart pointer can provide both guaranteed null-pointer checking and
the option of checking that yourself, and in addition, a smart-pointer
can add any functionality, such as argument-independent pre- and
post-actions for calls on the pointee object, or e.g. information
/about/ the pointee object.

IMHO references are for when you're guaranteeing validity, based on
existing validity guarantees, whereas class type wrappers such as smart
pointers are for when you need to enforce that guarantee.

(Some compilers omit the
checking, but there's no reason to. From a quality of
implementation point of view, they should check. I guess most
just consider that the code's going to blow up fast enough
anyway.)

I agree that there are situations where a compiler could and ideally
should insert checking of pointer dereferencing, if instructed to do so
by e.g. compiler options, such as when initializing a reference.

Correctness is far more important than performance, but I wouldn't like
a compiler to add such checks by default -- then better use C# or Java
or some other language that doesn't have efficiency as a main feature
and isn't based on "don't pay for what you don't use".

However, a smart pointer is compiler-independent and allows such
checking to be applied at much finer granularity than a complete app.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[James Kanze]

On Apr 3, 12:10 pm, "Alf P. Steinbach" <[e-mail]:

* James Kanze:

On Apr 2, 12:09 pm, "Alf P. Steinbach" <[e-mail]:

* Thomas Kowalski:

>I currently was thinking whether the following is a good idea:
I want to have something like an auto_ptr that checks during the
dereferencing whether the pointer is null and throws something like a
NullPointerException. Does someone have some experiences with
something like this? In general is it a good idea at all?

Better have it terminate the program. Even better, do the checking only
in the constructor and make it immutable.

Isn't that just what a reference does.

Nope. A reference does not provide any guaranteed null-reference
checking:

It doesn't guarantee it, but it allows it (and I've used
compilers which do it). My point is that what you seem to be
asking for is a pointer which 1) can't be changed after
initialization, and 2) doesn't allow initialization with null.
And that's more or less the definition of a reference.

it's like a cast in that it says "I guarantee that this
assumption (of validity) holds".

But what can you (formally) offer more. That trying to
initialize with a null address is guaranteed to call abort()?

And it doesn't support checking for
nullness yourself, for if you have a null-reference on hand you're
already in Undefined Behavior land.

A smart pointer can provide both guaranteed null-pointer checking and
the option of checking that yourself,

Or, not and. If it checks, and brings the program down, you
can't check later:-).

References don't give the guarantee, but a good compiler could
certainly make them work that way.

and in addition, a smart-pointer
can add any functionality, such as argument-independent pre- and
post-actions for calls on the pointee object, or e.g. information
/about/ the pointee object.

IMHO references are for when you're guaranteeing validity, based on
existing validity guarantees, whereas class type wrappers such as smart
pointers are for when you need to enforce that guarantee.

Let me see if I've understood correctly here. If you use a
reference, it is a programming error if you try to initialize a
reference with a null address, but with your smart pointers, it
is a programming error if you try to initialize one of them with
a null address.

(Some compilers omit the
checking, but there's no reason to. From a quality of
implementation point of view, they should check. I guess most
just consider that the code's going to blow up fast enough
anyway.)

I agree that there are situations where a compiler could and ideally
should insert checking of pointer dereferencing, if instructed to do so
by e.g. compiler options, such as when initializing a reference.

I'd argue the reverse. It should insert the checking code
unless instructed not to by e.g. compiler options or a pragma.

Correctness is far more important than performance, but I wouldn't like
a compiler to add such checks by default -- then better use C# or Java
or some other language that doesn't have efficiency as a main feature
and isn't based on "don't pay for what you don't use".

The main reason I use C++ instead of Java is that C++ code is
more robust. Java hides errors that C++ allows to crash the
program.

However, a smart pointer is compiler-independent and allows
such checking to be applied at much finer granularity than a
complete app.

Note that if the compiler does it, a good optimizer should be
able to eliminate a large percentage of the checks. It's a bit
like array bounds checking---in practice, with even a half
decent optimizer, there is no measurable difference in speed
when they are activated. (I'm supposing, here, a language which
has a real array type, which can be passed to functions, etc.,
and that is known and understood by the compiler. Bounds
checking is C/C++ rapidly becomes expensive, because you need to
add extra information to the pointers.)

Anyhow, my point was only that your "class" actually has exactly
the semantics of references. All you get is a required check
(rather than an optional one).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Alf P. Steinbach]

* James Kanze:

>
Let me see if I've understood correctly here. If you use a
reference, it is a programming error if you try to initialize a
reference with a null address, but with your smart pointers, it
is a programming error if you try to initialize one of them with
a null address.

Basically you got that part right.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[mlimber]

On Apr 2, 5:44 am, "Thomas Kowalski" <[e-mail]:

I currently was thinking whether the following is a good idea:
I want to have something like an auto_ptr that checks during the
dereferencing whether the pointer is null and throws something like a
NullPointerException. Does someone have some experiences with
something like this? In general is it a good idea at all?

In answer to your first question, yes: Loki::SmartPtr (from _Modern C+
+ Design_) allows you to supply a checking policy that will do such a
thing. See <http://sourceforge.net/projects/loki-lib>.

The answer to your second question is trickier. It's not *necessarily*
a bad idea, but as Alf says elsethread, there may be better options.

Cheers! --M