If I write:

int main (char[][] args)
{
   int *t;
     *t; //The program should crash here -access violation

   return 0;
}

The advantages are obvious.  The bug can then be found/fixed much earlier before it is ever passed into a function which the user may have no control over.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:

> If I write:
> 
> int main (char[][] args)
> {
>    int *t;
>      *t; //The program should crash here -access violation
> 
>    return 0;
> }
> 
> The advantages are obvious.  The bug can then be found/fixed much earlier before it is ever passed into a function which the user may have no control over.

assert(t !== null); achieves what you're after, and is much more self evident.

 -- andy

Andy Friesen wrote:

> J Anderson wrote:
>
>> If I write:
>>
>> int main (char[][] args)
>> {
>>    int *t;
>>      *t; //The program should crash here -access violation
>>
>>    return 0;
>> }
>>
>> The advantages are obvious.  The bug can then be found/fixed much earlier before it is ever passed into a function which the user may have no control over.
>
>
> assert(t !== null); achieves what you're after, and is much more self evident.
>
>  -- andy

I wouldn't want to explicitly place that through every bit of code.

int *t;

assert(t !== null);
func(*t);
assert(t !== null);
func(*t);
assert(t !== null);
func(*t);

Yuck.  Every time you use a pointer you would need an assert on just about every line.  This is not what I'm talking about.  If you for example dereference a null-pointer (in any situation), then the compiler should cause an access violation message like C++.

You could for example be passing t to a function

int *t;

func(*t); //Access violation

It's just obvious.  Also this would only be required on debug builds.


-- 
-Anderson: http://badmama.com.au/~anderson/

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c6s93o$725$1@digitaldaemon.com...
> If I write:
>
> int main (char[][] args)
> {
>     int *t;
>
>     *t; //The program should crash here -access violation

Isn't that just a null expression? Why should the compiler generate code for that statement? There is no opDeref() in D.

>     return 0;
> }
>
> The advantages are obvious.  The bug can then be found/fixed much earlier before it is ever passed into a function which the user may have no control over.

On Fri, 30 Apr 2004 14:23:31 +1000, Matthew <matthew.hat@stlsoft.dot.org> wrote:
> "J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
> news:c6s93o$725$1@digitaldaemon.com...
>> If I write:
>>
>> int main (char[][] args)
>> {
>>     int *t;
>>
>>     *t; //The program should crash here -access violation
>
> Isn't that just a null expression? Why should the compiler generate code for that
> statement? There is no opDeref() in D.

Yeah, perhaps you mean:

int main (char[][] args)
{
	int *t;
	int i;
	i = *t;
}

or

int main (char[][] args)
{
	int *t;
	*t = 0;
}

which do indeed generate an "Access Violation"

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opr688l9pv5a2sq9@digitalmars.com...
> On Fri, 30 Apr 2004 14:23:31 +1000, Matthew <matthew.hat@stlsoft.dot.org> wrote:
> > "J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c6s93o$725$1@digitaldaemon.com...
> >> If I write:
> >>
> >> int main (char[][] args)
> >> {
> >>     int *t;
> >>
> >>     *t; //The program should crash here -access violation
> >
> > Isn't that just a null expression? Why should the compiler generate code
> > for that
> > statement? There is no opDeref() in D.
>
> Yeah, perhaps you mean:
>
> int main (char[][] args)
> {
> int *t;
> int i;
> i = *t;
> }
>
> or
>
> int main (char[][] args)
> {
> int *t;
> *t = 0;
> }

Exactly.

> which do indeed generate an "Access Violation"

As we would want, and expect

Matthew wrote:

>"Regan Heath" <regan@netwin.co.nz> wrote in message
>news:opr688l9pv5a2sq9@digitalmars.com...
>  
>
>>On Fri, 30 Apr 2004 14:23:31 +1000, Matthew <matthew.hat@stlsoft.dot.org>
>>wrote:
>>    
>>
>>>"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
>>>news:c6s93o$725$1@digitaldaemon.com...
>>>      
>>>
>>>>If I write:
>>>>
>>>>int main (char[][] args)
>>>>{
>>>>    int *t;
>>>>
>>>>    *t; //The program should crash here -access violation
>>>>        
>>>>
>>>Isn't that just a null expression? Why should the compiler generate code
>>>for that
>>>statement? There is no opDeref() in D.
>>>      
>>>
>>Yeah, perhaps you mean:
>>
>>int main (char[][] args)
>>{
>>int *t;
>>int i;
>>i = *t;
>>}
>>
>>or
>>
>>int main (char[][] args)
>>{
>>int *t;
>>*t = 0;
>>}
>>    
>>
>
>Exactly.
>
>  
>
>>which do indeed generate an "Access Violation"
>>    
>>
>
>As we would want, and expect
>
>
>  
>
Sorry,  I didn't mean that code exactly.  I meant when you dereference a pointer in any case.

For example if you dereference when passing to a function you don't get an access violation:

int* t;

func(*t); //No access violation


The reason the code you just gave gives an access violation is not because of the dereference, it's because of the assignment to an no-existent variable.  What I'm saying is that the program should cause an access-violation one step earlier, at the dereference.

Let's try a slight modification to that example of yours:

class A
{
   void t(out int x)
   {        //If I were to do any assignments here there would be a access violation,
       //but what would happen if this was in a lib? - We wouldn't know where
       //the error really occured.
   };
  }

int main (char[][] args)
{
   A a = new A;

   int *t;
     a.t = *t; //No access violation
}

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:

> Sorry,  I didn't mean that code exactly.  I meant when you dereference a pointer in any case.
>
> For example if you dereference when passing to a function you don't get an access violation:
>
> int* t;
>
> func(*t); //No access violation
>
>
> The reason the code you just gave gives an access violation is not because of the dereference, it's because of the assignment to an no-existent variable.  What I'm saying is that the program should cause an access-violation one step earlier, at the dereference.
>
> Let's try a slight modification to that example of yours:
>
> class A
> {
>    void t(out int x)
>    {        //If I were to do any assignments here there would be a access violation,
>        //but what would happen if this was in a lib? - We wouldn't know where
>        //the error really occured.
>    };
>   }
>
> int main (char[][] args)
> {
>    A a = new A;
>
>    int *t;
>      a.t = *t; //No access violation
> }
>

Let's take that one step further to prove that that compiler is not optimising this out.

class A
{
   void t(out int x)
   {        printf("No access violation\n");
             if (&x)
           x = 5;
             printf("No access violation\n");
   };
  }

int main (char[][] args)
{
   A a = new A;

   int *t;
     a.t = *t;

   return 0;
}

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:
> 
> Let's take that one step further to prove that that compiler is not optimising this out.
> 
> class A
> {
>    void t(out int x)
>    {        printf("No access violation\n");
>              if (&x)
>            x = 5;
>              printf("No access violation\n");
>    };
>   }
> 
> int main (char[][] args)
> {
>    A a = new A;
> 
>    int *t;
>      a.t = *t;
> 
>    return 0;
> }

This is a bit tangental, but using 'out int x' as the argument for a setter is one of the most terrifying misuses of D properties that I have ever seen.  (it's also really good evidence that the current property syntax isn't enough)

Back on topic, I don't think it's a big deal for the compiler to implicitly assert that a pointer is not null before every dereference while in debug mode.

 -- andy

Andy Friesen wrote:

> J Anderson wrote:
>
>>
>> Let's take that one step further to prove that that compiler is not optimising this out.
>>
>> class A
>> {
>>    void t(out int x)
>>    {        printf("No access violation\n");
>>              if (&x)
>>            x = 5;
>>              printf("No access violation\n");
>>    };
>>   }
>>
>> int main (char[][] args)
>> {
>>    A a = new A;
>>
>>    int *t;
>>      a.t = *t;
>>
>>    return 0;
>> }
>
>
> This is a bit tangental, but using 'out int x' as the argument for a setter is one of the most terrifying misuses of D properties that I have ever seen.  (it's also really good evidence that the current property syntax isn't enough)
>
> Back on topic, I don't think it's a big deal for the compiler to implicitly assert that a pointer is not null before every dereference while in debug mode.
>
>  -- andy


Ok is

class A
{
  void t(out int x)
  {        printf("No access violation\n");
            if (&x)
          x = 5;
            printf("No access violation\n");
  };
 }

int main (char[][] args)
{
  A a = new A;

  int *t;
  a.t(*t);

  return 0;
}

more to your liking.


Besides using inout with a setter has it's uses.  Imagine passing the object it's parent when calling the setter.

I think it is a big deal as it will save many bugs.

-- 
-Anderson: http://badmama.com.au/~anderson/