NULLs

[Hans-Dieter.Dreier@materna.de]

--MwYNystOA8slDioWNNMPyJPxUr4iRbLo
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable


jason@injektilo.org wrote:

>Hi. I've been lurking for a while. Thought I'd add my $0.02 for a =

>change.
>
>>
>> NULLs are very convenient but they also introduce some problems:
>> =

>> 1. They do not fit nicely into a statical type system.
>
>Is this because you can assign NULL to any variable regardless of its =

>type? Is this really that bad?

No. The problem comes later: When you use a variable that is NULL. In C++, =
a frequent error situation is "this =3D=3D NULL" due to a method call in a =
situation like this:

MyClass* myPtr;
...
myPtr =3D NULL;
...
myPtr->Foo ();    // bang !


>> A, B: aUnion			// object named aUnion may be an A or =

>a B
>> =

>> .... to be used like this:
>> =

>> if aUnion.classOf =3D=3D A // classOf is allowed for any object
>>   then <do something> // here compiler knows aUnion is an A
>>   else <do something else> // here compiler knows it is something =

>else, in =3D
>> this case it must be a B
>> =

>> IOW, you cannot use aUnion as an A unless you make sure (by a =

>contional) it=3D
>>  really *is* an A.
>
>How is this different than checking to see if the variable in =

>question is set to NULL?

No difference. The important fact is that the compiler *checks* to make sur=
e the required condition holds, and won't let you write things like

aUnion.Foo ()

in places where aUnion might be an object (such as NULL) that does not supp=
ort Foo (). BTW, if the compiler would not only keep track of types but als=
o keep track of values, the same mechanism would rule out stuff like ...

<some code>
if x < 0 then y =3D sqrt (x)

because the compiler would know that x < 0 in this place, which violates th=
e precondition of sqrt that demands the argument to be >=3D 0, *unless* <so=
me code> made sure that x >=3D 0 (in which case the compiler should emit a =
warning about unreachable code).

>You might actually be on to something. Some programmers claim that =

>one should always check every pointer passed or returned to them as =

>if they could possibly be NULL. This is unarguably a good programming =

>practice. What if a language required that you check each pointer for =

>NULL before you could use it in a function or after a function call? =

>If the result of a function could never be NULL, then you could =

>return a reference in which case the compiler wouldn't require you to =

>check to see if it's NULL.

You get my point. The compiler would have to keep track of possible types (=
and maybe values) for each identifier and intermediate result to avoid forc=
ing the programmer to write unneccessary checks, however.

Keeping track of possible types is rather easy because the type set can be =
easily handled. Keeping track of possible values is hard; so it seems sensi=
ble to me to try to map as much as possible of the checking sketched above =
to type checking.

>I think that it'd be possible to offer a higher-level construct for =

>this than checking to see if a pointer equaled NULL, though. Maybe a =

>defined keyword? Would this fit with the static type system? Of =

>course, it would probably be implemented by checking to see if the =

>reference was set to NULL but we don't need to know that.

Could you show an example?

>
>Jason Diamond.
>
>
>
>--
>Is your email secure? http://www.pop3now.com
>(c) 1998,1999 Cave Creations Corp. All rights reserved.
>
>


--

Regards,

Hans-Dieter Dreier
(Hans-Dieter.Dreier@materna.de)=

--MwYNystOA8slDioWNNMPyJPxUr4iRbLo
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

IDENTIFIKATIONSANGABEN:
a23701a.txt IA5 DX-MAIL X.400 User Agent=

--MwYNystOA8slDioWNNMPyJPxUr4iRbLo--