View mode: basic / threaded / horizontal-split · Log in · Help
September 24, 2004
Re: Most important issues for D (MIID)
My personal concern are the array issues which clearly are a 2.0 topic.
Anyhow: one 1.0-issue related to this are "Array Operations" explained in
the specs.

It should be finally be made clear whether these are going to be part of 1.0
or not. My personal belief is that they are ill defined leading to
contradicting interpretations. Unfortunately, the current spec is so vague
that it is really hard to argue against them.

If it is the plan to implement them in 1.0, this should happen soon, because
it will most likely introduce a bunch of problems.

Otherwise (and this is what I would suggest) the whole section should be
thrown out of the specs completely and the topic should be rolled up anew,
once there is a clear concept for multidimensional arrays.
September 29, 2004
Re: Most important issues for D (MIID)
I've been silent, waiting to think of an important enough issue.  Then 
today in the shower, I remembered two of them.  They are discussed at 
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/6766, but I'm 
going to give more detail here to (hopefully) make things more clear.

1. Create delegates from arbitrary pointers
2. Access stack variables as an anonymous struct



1. Create delegates from arbitrary pointers

This is required so that we have a portable way of creating a delegate 
from an arbitrary pointer and an arbitrary function pointer.  You can 
create delegates using unions, but that is not portable.  Plus, it would 
require templates that were parameterized by the return value AND an 
unknown number of arguments.

I would prefer that D simply support this syntax:
	<ptr>.delegate <ret>(<args>) { <code> }
where <ptr> could be any pointer or class reference.

NOTE: If <ptr> is a class reference, then the delegate can ONLY access 
the fields and functions which the enclosing block can access.  That is, 
it cannot access private or protected fields or functions unless the 
enclosing block could.

The compiler should support a 'this' pointer inside the delegate which 
allows the code to access the pointer.  But it should also allow fields 
of structs, unions, and classes to be accessed without having to use 
'this'.  So all three of the following delegates would be legal:
	struct S { int a; }
	class  C { public int a(); }

	S s;
	C c = new C;
	char **p = <whatever>;

	void delegate() foo = &s.delegate void()
				{ a++; };
	void delegate() bar =  c.delegate void()
				{ printf("%d", a()); };
	void delegate() baz =  p.delegate void()
				{ printf("%s", *this); };



2. Access stack variables as an anonymous struct

This is necessary so that you can copy stack delegates.

I want to be able to get a pointer to an anonymous struct.  The pointer 
points to the current stack frame, and the anonymous struct lines up 
with the stack variables.

The anonymous struct should also include a dup() property, like this:
	struct _anon_stack_struct_12345 {
		_anon_stack_struct_12345 *dup() {
			return this[0..1].dup;
		}
	}

My suggestion is that the way to do this is via a new keyword, "stackframe":
	int a;
	int *p1 = &a;
	int *p2 = &(stackframe.a);
	// p1 points to the same thing as p2

When I want to copy a stack delegate, what I do is get the stack 
structure, copy it, and then use (1) above to create a delegate.
	void delegate() getFoo() {
		int x,y,z;
		return stackframe.dup.delegate void() {
			return x+y+z;
		}
	}
Next ›   Last »
7 8 9 10 11
Top | Discussion index | About this forum | D home