www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Calling members of null pointers-to-struct

reply Tor Myklebust <tmyklebu csclub.uwaterloo.ca> writes:
Why is this illegal in D?  As I understand it (from discussion with 
GregorR on IRC), methods of a D struct are not virtual --- the following 
program cannot use vtables as an excuse for its AssertError.


struct foo {
  int doit(int x) { return 42; }
}
void main() {
  foo *bar;  bar.doit(9);
}


Neither does the following slightly less trivial code (note that null 
pointers passed as the 'this' argument aren't dereferenced by struct 
list's methods):


struct list {
  list *next;
  int data;

  static list *make(list *foo, int bar) {
    list *x = new list();
    x.next = foo; x.data = bar;
    return x;
  }

  list *put(int k) {
    return make(this, k);
  }

  bool has(int k) {
    if (this == null) return false;
    return data == k || next.has(k);
  }
}

void main() {
  list *foo;
  foo = foo.put(42);
  foo = foo.put(17);
  foo = foo.put(31345);
  assert(foo.has(42));
  assert(foo.has(17));
  assert(foo.has(31345));
  assert(!foo.has(24));
}


(Except for one minor detail about foo not being initialised to null by 
default, this is perfectly good C++ code; calling a nonvirtual method of 
a null pointer-to-struct simply results in the 'this' parameter coming 
out to be null.  So, like, why doesn't D do the same?)


Tor Myklebust
May 06 2007
next sibling parent reply James Dennett <jdennett acm.org> writes:
Tor Myklebust wrote:

 Why is this illegal in D?  As I understand it (from discussion with 
 GregorR on IRC), methods of a D struct are not virtual --- the following 
 program cannot use vtables as an excuse for its AssertError.


[snip]


 (Except for one minor detail about foo not being initialised to null by 
 default, this is perfectly good C++ code; calling a nonvirtual method of 
 a null pointer-to-struct simply results in the 'this' parameter coming 
 out to be null.  So, like, why doesn't D do the same?)


It's technically invalid in C++ also unless the function
is a static member function.  The fact that most compilers
allow it to run means nothing; in a portably valid C++
program, the value of the "this" pointer is never null.

If D requires this to be diagnosed in at least some modes,
that would be a minor improvement on C++ (which leaves
this as undefined, largely for performance reasons).

-- James
May 06 2007
parent reply Tor Myklebust <tmyklebu csclub.uwaterloo.ca> writes:
James Dennett <jdennett acm.org> wrote:

 Tor Myklebust wrote:

 Why is this illegal in D?  As I understand it (from discussion with 
 GregorR on IRC), methods of a D struct are not virtual --- the following 
 program cannot use vtables as an excuse for its AssertError.


 
 [snip]
 

 (Except for one minor detail about foo not being initialised to null by 
 default, this is perfectly good C++ code; calling a nonvirtual method of 
 a null pointer-to-struct simply results in the 'this' parameter coming 
 out to be null.  So, like, why doesn't D do the same?)


 
 It's technically invalid in C++ also unless the function
 is a static member function.  The fact that most compilers
 allow it to run means nothing; in a portably valid C++
 program, the value of the "this" pointer is never null.
 	
 If D requires this to be diagnosed in at least some modes,
 that would be a minor improvement on C++ (which leaves
 this as undefined, largely for performance reasons).


OK, what you say about the C++ standard is true; 9.3.2.1 says the this 
pointer is a pointer to the object on which the function is called, and 
there can't very well be such a thing if this is null.  (I still see no 
earthly reason why it *should* be invalid for nonvirtual functions --- 
by extension, I see no earthly reason why it should be invalid for 
methods in D structs.)

Tor Myklebust
May 06 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Tor Myklebust wrote:

 [...] (I still see no
 earthly reason why it *should* be invalid for nonvirtual functions --- 
 by extension, I see no earthly reason why it should be invalid for 
 methods in D structs.)
 
 Tor Myklebust


I suppose one could argue that if it is allowable to call the method
with a non-existent instance for context, then there's no reason for
making it a member function in the first place.

Conversely, the vast majority of member functions are member functions
specifically *because* they require the context to be there, where the
assertion makes sense to have.

Of course, since all D ever gives is "ZOMG!  ASSERT ERRORZ!" and neither
tells you *where* it happened[1], or on what, it's not very useful for
more than telling you you screwed up somewhere.

Thank $DEITY for ddbg, though.

	-- Daniel

[1] Ok, it tells you the line of the function being called, but all
things considered, that isn't very useful.  Oh for the day we get
back-traces in the standard library :)

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
May 06 2007
parent Tor Myklebust <tmyklebu csclub.uwaterloo.ca> writes:
Daniel Keep <daniel.keep.lists gmail.com> wrote:

 
 
 Tor Myklebust wrote:

 [...] (I still see no
 earthly reason why it *should* be invalid for nonvirtual functions --- 
 by extension, I see no earthly reason why it should be invalid for 
 methods in D structs.)
 
 Tor Myklebust


 
 I suppose one could argue that if it is allowable to call the method
 with a non-existent instance for context, then there's no reason for
 making it a member function in the first place.
 
 Conversely, the vast majority of member functions are member functions
 specifically *because* they require the context to be there, where the
 assertion makes sense to have.


It doesn't make sense, though, which was precisely the point of the 
original post.  I even gave an example demonstrating why it doesn't make 
sense; it is reproduced below:


struct list {
  list *next;
  int data;

  static list *make(list *foo, int bar) {
    list *x = new list();
    x.next = foo; x.data = bar;
    return x;
  }

  list *put(int k) {
    return make(this, k);
  }

  bool has(int k) {
    if (this == null) return false;
    return data == k || next.has(k);
  }
}

void main() {
  list *foo;
  foo = foo.put(42);
  foo = foo.put(17);
  foo = foo.put(31345);
  assert(foo.has(42));
  assert(foo.has(17));
  assert(foo.has(31345));
  assert(!foo.has(24));
}


This is a toy implementation of a linked list representing a set of 
ints.  The empty list is represented by a null pointer.  A nonempty list 
is represented by a null-terminated, er, list of struct lists.

It makes sense for put() to be a member function because put() needs to 
know what 'this' is.  It doesn't need to know about any of the members 
of 'this', though, so it doesn't need to dereference 'this'.  It also 
makes sense for 'has' to be a member function, since it needs to know 
about 'data' and 'has'.  (Neither one is needed if 'this' is null, 
however, since null represents the empty list and the empty list 
contains nothing.)  Thus, in neither method does it make sense for a 
not-null assertion to be made but in both methods the context provided 
by 'this' is required.

Tor Myklebust
May 07 2007
prev sibling parent BCS <ao pathlink.com> writes:
Reply to Tor,


 Why is this illegal in D?  As I understand it (from discussion with
 GregorR on IRC), methods of a D struct are not virtual --- the
 following program cannot use vtables as an excuse for its AssertError.
 
 struct foo {
 int doit(int x) { return 42; }
 }
 void main() {
 foo *bar;  bar.doit(9);
 }


try this


 foo *bar= cast(foo*)(null+1);  bar.doit(9);


I was found this trick because I had a function that needed to be called 
as a delegate and I didn't want the overhead of doing the nested call trick.

p.s.

Wow, 2 (strange things I was working on that other people bring up) in one 
day! The other is label variables.
May 06 2007