www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 0.161 release

reply Walter Bright <newshound digitalmars.com> writes:
Mostly bug fixes.

http://www.digitalmars.com/d/changelog.html
Jun 19 2006
next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
On Tue, 20 Jun 2006 02:03:08 -0400, Walter Bright  
<newshound digitalmars.com> wrote:


 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html



Wow, that new literal delegate syntax is crazy but I like it.

I suggest changing word lambda to literal on the changelog since lambda  
isn't mentioned in the spec and no need to make things more confusing.

- Chris
Jun 19 2006
parent reply BCS <BCS pathlink.com> writes:
Chris Miller wrote:

 On Tue, 20 Jun 2006 02:03:08 -0400, Walter Bright  
 <newshound digitalmars.com> wrote:
 

 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html


 
 
 
 Wow, that new literal delegate syntax is crazy but I like it.
 


[...]

Ohhhh fun!! Try finding the bug in this one (ignore the hints).

<code>
#import std.stdio;
#void main()




#int fn()




















#int doNothing(){return 1;}
</code>


Yah, yah thats about a contrived a C-list movie but...
Jun 20 2006
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
BCS wrote:

 Chris Miller wrote:

 On Tue, 20 Jun 2006 02:03:08 -0400, Walter Bright  
 <newshound digitalmars.com> wrote:


 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html




 Wow, that new literal delegate syntax is crazy but I like it.


 [...]
 
 Ohhhh fun!! Try finding the bug in this one (ignore the hints).


-snip-

It seems to work just fine here? Prints 2, exactly what I expected :)

L.
Jun 20 2006
parent BCS <BCS pathlink.com> writes:
Lionello Lunesu wrote:

 BCS wrote:
 

 Chris Miller wrote:


 On Tue, 20 Jun 2006 02:03:08 -0400, Walter Bright  
 <newshound digitalmars.com> wrote:


 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html





 Wow, that new literal delegate syntax is crazy but I like it.


 [...]

 Ohhhh fun!! Try finding the bug in this one (ignore the hints).


 
 
 -snip-
 
 It seems to work just fine here? Prints 2, exactly what I expected :)
 
  L.



if about 4 typos are removes it becomes this and returns 1.

<code>
#import std.stdio;
#void main()




#int fn()





























#int doNothing(){return 1;}
</code>

Another not so obfuscated one is this:

#import std.stdio;
#void main()










The point is that there could end up being some confusion as to weather 
something is a function or just a block. I think that the last rule gos 
a bit to far. Typing in the "()" doesn't cost much and adds a bunch as 
far as readability goes.


FunctionLiteral
	function Typeopt ( ArgumentList )opt FunctionBody
	delegate Typeopt ( ArgumentList )opt FunctionBody
	( ArgumentList ) FunctionBody

	FunctionBody
Jun 21 2006
prev sibling next sibling parent "Chris Miller" <chris dprogramming.com> writes:
About this literal delegate syntax, there seems to be an ambiguity:
    void delegate() foo = { }; // Thinks it's a struct initializer.
    void delegate() foo = ( { } ); // Workaround.
Jun 20 2006
prev sibling next sibling parent Frank Benoit <keinfarbton nospam.xyz> writes:
Walter Bright schrieb:

 Mostly bug fixes.
 
 http://www.digitalmars.com/d/changelog.html


Thanks. Especially for 106.
Jun 20 2006
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Walter Bright wrote:

 Mostly bug fixes.
 
 http://www.digitalmars.com/d/changelog.html


Great update, lots of bugfixes, and the shorter delegate syntax looks 
awesome!

It says "Fixed Bugzilla 53 according to Bruno's analysis" but I don't 
know anything about bug 53. Did you meant Oskar, or perhaps bug 47?

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jun 20 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Bruno Medeiros wrote:

 Walter Bright wrote:

 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html


 
 Great update, lots of bugfixes, and the shorter delegate syntax looks 
 awesome!
 
 It says "Fixed Bugzilla 53 according to Bruno's analysis" but I don't 
 know anything about bug 53. Did you meant Oskar, or perhaps bug 47?


It wasn't 53, but I can't remember which one it was!
Jun 20 2006
parent Walter Bright <newshound digitalmars.com> writes:
Walter Bright wrote:

 Bruno Medeiros wrote:

 Walter Bright wrote:

 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html


 Great update, lots of bugfixes, and the shorter delegate syntax looks 
 awesome!

 It says "Fixed Bugzilla 53 according to Bruno's analysis" but I don't 
 know anything about bug 53. Did you meant Oskar, or perhaps bug 47?


 
 It wasn't 53, but I can't remember which one it was!
Jun 20 2006
prev sibling next sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Walter Bright wrote:

 Mostly bug fixes.
 
 http://www.digitalmars.com/d/changelog.html



 Added opIn_r operator overload.


Excellent! I have just the use for that in this Python thing...


 New function template syntax.


So now that it's documented, it's here to stay and I can feel safe 
playing with it? Cool.

-Kirk McDonald
Jun 20 2006
prev sibling next sibling parent reply David Medlock <noone nowhere.com> writes:
Walter Bright wrote:

 Mostly bug fixes.
 
 http://www.digitalmars.com/d/changelog.html


New delegate syntax looks great, can't wait to try it!

-DavidM
Jun 20 2006
parent reply Jari-Matti =?UTF-8?B?TcOka2Vsw6Q=?= <jmjmak utu.fi.invalid> writes:
David Medlock wrote:


 Walter Bright wrote:

 Mostly bug fixes.
 
 http://www.digitalmars.com/d/changelog.html


 
 New delegate syntax looks great, can't wait to try it!


Excellent. It's good to see that Walter likes many of the good features in
Ruby. Some Java/C++ -fanboys might say that they're pure syntactic sugar,
but trust me - they have lost their sanity long time ago ;)

-- 
Jari-Matti
Jun 20 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Jari-Matti Mäkelä wrote:

 David Medlock wrote:
 

 Walter Bright wrote:

 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html


 New delegate syntax looks great, can't wait to try it!


 
 Excellent. It's good to see that Walter likes many of the good features in
 Ruby. Some Java/C++ -fanboys might say that they're pure syntactic sugar,
 but trust me - they have lost their sanity long time ago ;)


It's possible to go too far with conciseness (APL and Perl show that!), 
but in general being able to write what you mean with a minimum of fuss 
makes for a more productive language.
Jun 20 2006
parent Jari-Matti =?UTF-8?B?TcOka2Vsw6Q=?= <jmjmak utu.fi.invalid> writes:
Walter Bright wrote:

 Jari-Matti Mäkelä wrote:

 David Medlock wrote:

 New delegate syntax looks great, can't wait to try it!


 
 Excellent. It's good to see that Walter likes many of the good features
 in Ruby. Some Java/C++ -fanboys might say that they're pure syntactic
 sugar, but trust me - they have lost their sanity long time ago ;)


 
 It's possible to go too far with conciseness (APL and Perl show that!),
 but in general being able to write what you mean with a minimum of fuss
 makes for a more productive language.


I like most of the new features in D. They are both efficient and productive
and still quite easy to use. Other than array literals and some polishing
of interfaces, imports and templates there is not much left to make D the
next king in it's class. I'm more than grateful for the experience I've had
exploring the world of D.

-- 
Jari-Matti
Jun 21 2006
prev sibling next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Walter Bright wrote:

 Mostly bug fixes.
 
 http://www.digitalmars.com/d/changelog.html


Thanks, Walter :) Nice list of bug fixes ! I also dig the new features :D


-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
Jun 20 2006
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:

 Mostly bug fixes.
 
 http://www.digitalmars.com/d/changelog.html


"Shadowing local variable declarations is now deprecated."

I thought it had always been illegal by the spec.


"Folded in D.bugs/7509"

You seem to have slipped up here:

"What's needed is an error handling philosophy and methodology such that:
[...]
     * 'Quick and dirty' utilities to be written that still correctly 
handle errors."

s/to/can


"Fixed Bugzilla 57  in 0.151"

Why is this in the changelog for 0.161?


"Fixed Bugzilla 36  (better error message)"
"Fixed Bugzilla 85  (now issues error message)"

And they're also marked as fixed in Bugzilla.  However, at the moment I 
can't seem to find the bit of the spec that indicates that either is 
illegal code.

Stewart.
Jun 20 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Stewart Gordon wrote:

 Walter Bright wrote:

 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html


 
 "Shadowing local variable declarations is now deprecated."
 
 I thought it had always been illegal by the spec.


It wasn't implemented.



 "Folded in D.bugs/7509"
 
 You seem to have slipped up here:
 
 "What's needed is an error handling philosophy and methodology such that:
 [...]
     * 'Quick and dirty' utilities to be written that still correctly 
 handle errors."
 
 s/to/can


Thanks, I'll fix.


 
 "Fixed Bugzilla 57  in 0.151"
 
 Why is this in the changelog for 0.161?


It was overlooked.



 "Fixed Bugzilla 36  (better error message)"
 "Fixed Bugzilla 85  (now issues error message)"
 
 And they're also marked as fixed in Bugzilla.  However, at the moment I 
 can't seem to find the bit of the spec that indicates that either is 
 illegal code.


36: forward references are an ongoing issue, I'd like to get rid of all 
such errors. But in the meantime, having feet of clay, some will give 
error messages instead.

85: It can't be made to work, because an interface handle is different 
from a class handle. It doesn't work in C++, either, for the same reasons.
Jun 20 2006
next sibling parent reply BCS <BCS pathlink.com> writes:
Walter Bright wrote:

 Stewart Gordon wrote:

 
 "Fixed Bugzilla 85  (now issues error message)"


 
 85: It can't be made to work, because an interface handle is different 
 from a class handle. It doesn't work in C++, either, for the same reasons.


Anyway to get a cast? (If it is already there...)
Somthing like:

interface I{...}
class C : I {...}
...

C[] c;
I[] i;

c = ....;

i = cast(I)c;

// same as

i.length = c.length;
foreach(int j, C e; c)
	i[j] = (null !is e)?e:null;
Jun 20 2006
parent Walter Bright <newshound digitalmars.com> writes:
BCS wrote:

 Walter Bright wrote:

 Stewart Gordon wrote:

 "Fixed Bugzilla 85  (now issues error message)"


 85: It can't be made to work, because an interface handle is different 
 from a class handle. It doesn't work in C++, either, for the same 
 reasons.


 
 Anyway to get a cast? (If it is already there...)
 Somthing like:
 
 interface I{...}
 class C : I {...}
 ...
 
 C[] c;
 I[] i;
 
 c = ....;
 
 i = cast(I)c;
 
 // same as
 
 i.length = c.length;
 foreach(int j, C e; c)
     i[j] = (null !is e)?e:null;
 


You'll have to iterate over the loop and cast each element.
Jun 20 2006
prev sibling next sibling parent reply xs0 <xs0 xs0.com> writes:
Walter Bright wrote:


 85: It can't be made to work, because an interface handle is different 
 from a class handle. It doesn't work in C++, either, for the same reasons.


But it can be made to work, because an interface handle could be the 
same as a class handle. It works that way in Java, and is _far_ more 
useful, even if performance of method calls is reduced slightly.

But we talked about that already, and I don't suppose you'll change your 
mind this time..


xs0
Jun 21 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
xs0 wrote:

 Walter Bright wrote:
 

 85: It can't be made to work, because an interface handle is different 
 from a class handle. It doesn't work in C++, either, for the same 
 reasons.


 
 But it can be made to work, because an interface handle could be the 
 same as a class handle. It works that way in Java, and is _far_ more 
 useful, even if performance of method calls is reduced slightly.
 
 But we talked about that already, and I don't suppose you'll change your 
 mind this time..


Java makes it "work" by doing runtime manipulation of interface/class 
handles whenever they are used. This is too inefficient for a native 
compiled language.

Consider this:

   int can be implicitly converted to long.
   Therefore, shouldn't int[] be usable as a long[]?

It's an exactly analogous situation.
Jun 21 2006
next sibling parent BCS <BCS pathlink.com> writes:
Walter Bright wrote:

 xs0 wrote:
 

 Walter Bright wrote:


 85: It can't be made to work, because an interface handle is 
 different from a class handle. It doesn't work in C++, either, for 
 the same reasons.



 But it can be made to work, because an interface handle could be the 
 same as a class handle. It works that way in Java, and is _far_ more 
 useful, even if performance of method calls is reduced slightly.

 But we talked about that already, and I don't suppose you'll change 
 your mind this time..


 
 
 Java makes it "work" by doing runtime manipulation of interface/class 
 handles whenever they are used. This is too inefficient for a native 
 compiled language.
 
 Consider this:
 
   int can be implicitly converted to long.
   Therefore, shouldn't int[] be usable as a long[]?
 
 It's an exactly analogous situation.



A user code solution could be used:

T[] castArray(F, T)(F[] array)
{
	T[] ret = new T[array.length];
	foreach(i,e;array)
	{
			// this is from memory, but you get the picture
		static if(is(T : Object))
			(e!is null) ? ret[i]=e; ? ret[i]=null;
		else
			ret[i]=e;
	}
	return ret;
}


void main()
{
	const static int[] from = [1,2,3,4,5,6,7,8,9];

	long[] to = castArray!(int, long)(from);
}
Jun 21 2006
prev sibling next sibling parent reply xs0 <xs0 xs0.com> writes:
Walter Bright wrote:

 xs0 wrote:

 Walter Bright wrote:


 85: It can't be made to work, because an interface handle is 
 different from a class handle. It doesn't work in C++, either, for 
 the same reasons.


 But it can be made to work, because an interface handle could be the 
 same as a class handle. It works that way in Java, and is _far_ more 
 useful, even if performance of method calls is reduced slightly.

 But we talked about that already, and I don't suppose you'll change 
 your mind this time..


 
 Java makes it "work" by doing runtime manipulation of interface/class 
 handles whenever they are used.


Well, I think it's quite irrelevant what Java does (and the same goes 
for C++*), the question is what is a better option, where we seem to 
disagree.


 This is too inefficient for a native 
 compiled language.


I (still) think you're over-exaggerating the efficiency issue, because 
the difference is not that large in reality. For anything but the 
simplest methods the speed penalty is practically negligible (I measured 
it), and it's not the simplest methods that most time is spent on, I'd say.

And you could use the same argument against virtual methods, but you 
still implemented them.


 Consider this:
 
   int can be implicitly converted to long.
   Therefore, shouldn't int[] be usable as a long[]?
 
 It's an exactly analogous situation.


No, it isn't. int is of a different "class" than long, while an 
interface reference and a class reference point to exactly the same object.

You also seem to miss the reduced complexity of implementation (a stated 
goal I believe). With a simple double lookup, interfaces can be handled 
in a single place, and I'd guess you could implement that very easily 
just by faking another calling convention.

On the other hand, if interface references point to a different address 
than class references, you need to store offsets somewhere, have to 
modify the address on every call, need to handle implicit conversions 
when passing function boundaries, etc. etc.


xs0

*) Note that C++ supports MI, meaning double lookup would hurt every 
method call. Otoh, in D we'd get to keep the speed of non-interface calls.
Jun 21 2006
next sibling parent reply BenHinkle <BenHinkle_member pathlink.com> writes:
 Consider this:
 
   int can be implicitly converted to long.
   Therefore, shouldn't int[] be usable as a long[]?
 
 It's an exactly analogous situation.


No, it isn't. int is of a different "class" than long, while an 
interface reference and a class reference point to exactly the same object.

You also seem to miss the reduced complexity of implementation (a stated 
goal I believe). With a simple double lookup, interfaces can be handled 
in a single place, and I'd guess you could implement that very easily 
just by faking another calling convention.


Can you explain more what you mean by double lookup? I'm not aware of that
technique.


On the other hand, if interface references point to a different address 
than class references, you need to store offsets somewhere, have to 
modify the address on every call, need to handle implicit conversions 
when passing function boundaries, etc. etc.


This technique I'm used to. It's called thunking and I believe it's the standard
way of implementing MI and/or interfaces. That is, when a class implements an
interface method it makes a thunk to adjust the 'this' pointer before calling
the actual class method. So when you have an interface A and class C and call a
method f in A that is implemented in C the slot in the vtable for f (which takes
an A) calls the thunk to adjust the A to a C and then the thunk jumps to the
method (which takes a C).

-Ben
Jun 21 2006
parent reply xs0 <xs0 xs0.com> writes:
BenHinkle wrote:

 Consider this:

   int can be implicitly converted to long.
   Therefore, shouldn't int[] be usable as a long[]?

 It's an exactly analogous situation.


 No, it isn't. int is of a different "class" than long, while an 
 interface reference and a class reference point to exactly the same object.

 You also seem to miss the reduced complexity of implementation (a stated 
 goal I believe). With a simple double lookup, interfaces can be handled 
 in a single place, and I'd guess you could implement that very easily 
 just by faking another calling convention.


 
 Can you explain more what you mean by double lookup? I'm not aware of that
 technique.


It's very simple :)


 iref.someFunction(...) // iref is an interface reference


becomes


 iref.getVtbl(SomeInterface.classinfo)[2](iref, ...)


instead of the current


 iref.someFunction(iref-offset, ...)



I tested speed of various calling methods with
http://www.xs0.com/d/ifaces.d.html

and here are the results I get:

               Normal:             12165450 / sec
    Through interface:             11764706 / sec
    Lookup every time:              9580379 / sec
     Optimized lookup:             13390466 / sec
     Static functions:             13224015 / sec

The number is function calls / second.

With a function of any significant complexity, the differences would be 
even smaller, and even here it's just around 20% in the worst case. And 
if a simple observation* is implemented in the optimizer, the speed loss 
in fact becomes speed gain (ok, in reality it would also be implemented 
for non-interface methods, so the speed would end up the same).

*) if the object reference doesn't change neither can the function pointer



 On the other hand, if interface references point to a different address 
 than class references, you need to store offsets somewhere, have to 
 modify the address on every call, need to handle implicit conversions 
 when passing function boundaries, etc. etc.


 
 This technique I'm used to. It's called thunking and I believe it's the
standard
 way of implementing MI and/or interfaces. That is, when a class implements an
 interface method it makes a thunk to adjust the 'this' pointer before calling
 the actual class method. So when you have an interface A and class C and call a
 method f in A that is implemented in C the slot in the vtable for f (which
takes
 an A) calls the thunk to adjust the A to a C and then the thunk jumps to the
 method (which takes a C).


Well, I think there's a significant difference between MI and interfaces 
in that interfaces only allow methods, while with MI you also have 
fields to think of. Having to basically make a function call for each 
field access would indeed be too inefficient, but it's not the same case 
with methods, because the call itself usually takes only a (very) small 
part of total method execution time.


xs0
Jun 22 2006
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 I tested speed of various calling methods with
 http://www.xs0.com/d/ifaces.d.html

 and here are the results I get:

               Normal:             12165450 / sec
    Through interface:             11764706 / sec
    Lookup every time:              9580379 / sec
     Optimized lookup:             13390466 / sec
     Static functions:             13224015 / sec

 The number is function calls / second.

 With a function of any significant complexity, the differences would be 
 even smaller, and even here it's just around 20% in the worst case. And if 
 a simple observation* is implemented in the optimizer, the speed loss in 
 fact becomes speed gain (ok, in reality it would also be implemented for 
 non-interface methods, so the speed would end up the same).

 *) if the object reference doesn't change neither can the function pointer


ok, I see what you mean. thanks for explaining. Pretty cool! Since the 
vtable lookup is linear in the total number of interfaces the class 
implements (including the interfaces of super-interfaces) it could be more 
noticeable in larger examples.


 On the other hand, if interface references point to a different address 
 than class references, you need to store offsets somewhere, have to 
 modify the address on every call, need to handle implicit conversions 
 when passing function boundaries, etc. etc.


 This technique I'm used to. It's called thunking and I believe it's the 
 standard
 way of implementing MI and/or interfaces. That is, when a class 
 implements an
 interface method it makes a thunk to adjust the 'this' pointer before 
 calling
 the actual class method. So when you have an interface A and class C and 
 call a
 method f in A that is implemented in C the slot in the vtable for f 
 (which takes
 an A) calls the thunk to adjust the A to a C and then the thunk jumps to 
 the
 method (which takes a C).


 Well, I think there's a significant difference between MI and interfaces 
 in that interfaces only allow methods, while with MI you also have fields 
 to think of. Having to basically make a function call for each field 
 access would indeed be too inefficient, but it's not the same case with 
 methods, because the call itself usually takes only a (very) small part of 
 total method execution time.


In general I agree function call speed isn't a big deal for interfaces but 
it isn't unusual to have an interface that abstracts out a field lookup (eg, 
getLength). For those the body of the implementation would be very simple. 
I'm curious if the double lookup technique has been tried in practice and 
what the impressions were.
Jun 22 2006
next sibling parent Jari-Matti =?UTF-8?B?TcOka2Vsw6Q=?= <jmjmak utu.fi.invalid> writes:
Ben Hinkle wrote:

 In general I agree function call speed isn't a big deal for interfaces but
 it isn't unusual to have an interface that abstracts out a field lookup
 (eg, getLength). For those the body of the implementation would be very
 simple. I'm curious if the double lookup technique has been tried in
 practice and what the impressions were.


Does any commonly used language / compiler implement these double lookups?


Like xs0 said, the decrease in overall speed is ridiculously small. Most
(non-pro guru) Java programmers I know of use interfaces this way a lot
despite the obvious drawbacks in performance. I think that beefing up the
compiler logic just a little bit here pays itself back faster than we can
even imagine. At least it makes the life of application programmers and
thus end users a bit easier (better modularity, less error-prone casting).

To me it sounds a bit weird that Walter has promised to implement array
literals, but interfaces are going to be left broken. They're can be both
implemented now by using template hacks and seem to be equally hard to
implement.

-- 
Jari-Matti
Jun 22 2006
prev sibling parent reply xs0 <xs0 xs0.com> writes:
Ben Hinkle wrote:

 ok, I see what you mean. thanks for explaining. Pretty cool! Since the 
 vtable lookup is linear in the total number of interfaces the class 
 implements (including the interfaces of super-interfaces) it could be more 
 noticeable in larger examples.


Well, the lookup need not be linear. Since the interfaces are known in 
advance for each class, it should be possible to achieve a fast O(1) 
lookup with something like a [minimal] perfect hash function, all you'd 
probably need is some sort of numeric identifier for each interface 
(could simply be a MD5 of its full name or something).


 In general I agree function call speed isn't a big deal for interfaces but 
 it isn't unusual to have an interface that abstracts out a field lookup (eg, 
 getLength). For those the body of the implementation would be very simple. 
 I'm curious if the double lookup technique has been tried in practice and 
 what the impressions were.


Well, as far as I can tell, Sun's JVM does something like this (at least 
the timing results seem to suggest so), and considering how often 
interfaces get used in Java, I'd say it's not actually a significant 
problem.

Though I've no idea if any compiled language does so, as I don't know 
that many :)

It should also be noted that having a single reference to each object 
would allow covariance in many more cases, so it'd be easier to actually 
have a class reference than it is now..


xs0
Jun 22 2006
parent BCS <BCS pathlink.com> writes:
xs0 wrote:

 Ben Hinkle wrote:
 

 ok, I see what you mean. thanks for explaining. Pretty cool! Since the 
 vtable lookup is linear in the total number of interfaces the class 
 implements (including the interfaces of super-interfaces) it could be 
 more noticeable in larger examples.


 
 
 Well, the lookup need not be linear. Since the interfaces are known in 
 advance for each class, it should be possible to achieve a fast O(1) 
 lookup with something like a [minimal] perfect hash function, all you'd 
 probably need is some sort of numeric identifier for each interface 
 (could simply be a MD5 of its full name or something).



I would expect that the pointer-to-vtbl for the interface would be 
placed in the classes vtbl. class to interface cast would consist of (in 
sudo code)


/** i = c;  **/

interface_Ijk_Struct i;
with (i)
{
	contextPtr = c;
	vtbl = c.vtbl[Ijk_Vtbl];
}

////// What am I missing?
Jun 22 2006
prev sibling parent BenHinkle <BenHinkle_member pathlink.com> writes:
 Consider this:
 
   int can be implicitly converted to long.
   Therefore, shouldn't int[] be usable as a long[]?
 
 It's an exactly analogous situation.


No, it isn't. int is of a different "class" than long, while an 
interface reference and a class reference point to exactly the same object.

You also seem to miss the reduced complexity of implementation (a stated 
goal I believe). With a simple double lookup, interfaces can be handled 
in a single place, and I'd guess you could implement that very easily 
just by faking another calling convention.


Can you explain more what you mean by double lookup? I'm not aware of that
technique.


On the other hand, if interface references point to a different address 
than class references, you need to store offsets somewhere, have to 
modify the address on every call, need to handle implicit conversions 
when passing function boundaries, etc. etc.


This technique I'm used to. It's called thunking and I believe it's the standard
way of implementing MI and/or interfaces. That is, when a class implements an
interface method it makes a thunk to adjust the 'this' pointer before calling
the actual class method. So when you have an interface A and class C and call a
method f in A that is implemented in C the slot in the vtable for f (which takes
an A) calls the thunk to adjust the A to a C and then the thunk jumps to the
method (which takes a C).

-Ben
Jun 21 2006
prev sibling parent Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <e7bv51$9lp$1 digitaldaemon.com>, Walter Bright says...

[...]

Consider this:

   int can be implicitly converted to long.
   Therefore, shouldn't int[] be usable as a long[]?

It's an exactly analogous situation.


I agree.
To make it simple you can do like this:

template copycast (T : T[])
{
  T[] copycast (X) (X[] array) 
  {
    T[] retVal = new T[array.length];
    foreach (int i, X elem; array)
    {
      retVal[i] = cast(T) elem;
    }
    return retVal;
  }
}
 
int main()
{
  int[] a = new int[10];
  long[] al = copycast!(long[]) (a);
 
  interface I {  }
  class A : I {  }
  A[] array = new A[10];
  I[] dest = copycast!(I[]) (array);
 
  return 0;
}

Ciao

---
http://www.mariottini.net/roberto/
Jun 22 2006
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:

 Stewart Gordon wrote:

 Walter Bright wrote:

 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html


 "Shadowing local variable declarations is now deprecated."

 I thought it had always been illegal by the spec.


 
 It wasn't implemented.


So you've implemented it as a deprecation for the time being, rather 
than banning it altogether?

<snip>

 "Fixed Bugzilla 57  in 0.151"

 Why is this in the changelog for 0.161?


 
 It was overlooked.


What do you mean?  The changelog for 0.151 also lists this bug as fixed.


 "Fixed Bugzilla 36  (better error message)"
 "Fixed Bugzilla 85  (now issues error message)"

 And they're also marked as fixed in Bugzilla.  However, at the moment 
 I can't seem to find the bit of the spec that indicates that either is 
 illegal code.


 
 36: forward references are an ongoing issue, I'd like to get rid of all 
 such errors. But in the meantime, having feet of clay, some will give 
 error messages instead.


Nobody else I know would claim that changing the error message resulting 
from a bug constitutes fixing the bug.

If the bug _is_ the bad error message, rather than the fact that an 
error is produced at all, then that's another matter.


 85: It can't be made to work, because an interface handle is different 
 from a class handle.


But it can be made to create a new array of the interface type.  But 
this should probably require an explicit cast.

Just looking at the documentation, the "Implicit Conversions" section of 
arrays.html mentions "U[] where U is a base class of T" - I now suppose 
it's just a temptation to think that it would work on interfaces as 
well.  Clarification would certainly be welcome.

And we could also do with some decent documentation on what arrays may 
be converted to by explicit casting.


 It doesn't work in C++, either, for the same reasons.


Since when has C++ had interfaces?

Stewart.
Jun 22 2006
next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Thu, 22 Jun 2006 17:11:07 +0100, Stewart Gordon wrote:


 Walter Bright wrote:

 Stewart Gordon wrote:

 Walter Bright wrote:

 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html


 "Shadowing local variable declarations is now deprecated."

 I thought it had always been illegal by the spec.


 
 It wasn't implemented.


 
 So you've implemented it as a deprecation for the time being, rather 
 than banning it altogether?


Walter's actions here made sense to me. A lot of people had begun to think
that the bug lay in the documentation and not the implementation, and so
coded accordingly. Now, rather than force them to immediately change all
their source code, Walter has allowed them a way to gradually convert to
the real specification. 
 
 

 "Fixed Bugzilla 36  (better error message)"
 "Fixed Bugzilla 85  (now issues error message)"

 And they're also marked as fixed in Bugzilla.  However, at the moment 
 I can't seem to find the bit of the spec that indicates that either is 
 illegal code.


 
 36: forward references are an ongoing issue, I'd like to get rid of all 
 such errors. But in the meantime, having feet of clay, some will give 
 error messages instead.


 
 Nobody else I know would claim that changing the error message resulting 
 from a bug constitutes fixing the bug.



eventually fixed. However, now that the message text has changed
(improved?) it might be better for us to open a new bug entry, using the
new message in the commentary, to keep this issue on Walter's TODO list. 



 And we could also do with some decent documentation on what arrays may 
 be converted to by explicit casting.


As you may have noticed, Walter often gets a bit busy. It might then be a
reasonable idea for you, or anyone else, to have a go at writing this
documentation update and sending it to Walter for merging into the main
documentation body.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
23/06/2006 9:17:40 AM
Jun 22 2006
parent reply BCS <BCS pathlink.com> writes:
Derek Parnell wrote:

 On Thu, 22 Jun 2006 17:11:07 +0100, Stewart Gordon wrote:


[...]

 

And we could also do with some decent documentation on what arrays may 
be converted to by explicit casting.


 
 
 As you may have noticed, Walter often gets a bit busy. It might then be a
 reasonable idea for you, or anyone else, to have a go at writing this
 documentation update and sending it to Walter for merging into the main
 documentation body.
 


How do you get DMD to let you use depreciated "things"? I know it's in 
there somewhere but I can't seem to find the switch.
Jun 22 2006
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Thu, 22 Jun 2006 17:31:16 -0700, BCS wrote:


 Derek Parnell wrote:

 On Thu, 22 Jun 2006 17:11:07 +0100, Stewart Gordon wrote:


 [...]

 

And we could also do with some decent documentation on what arrays may 
be converted to by explicit casting.


 
 As you may have noticed, Walter often gets a bit busy. It might then be a
 reasonable idea for you, or anyone else, to have a go at writing this
 documentation update and sending it to Walter for merging into the main
 documentation body.
 


 
 How do you get DMD to let you use depreciated "things"? I know it's in 
 there somewhere but I can't seem to find the switch.


Use the "-d" switch. Documented under "Tools / DMD D Compiler"
-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
23/06/2006 10:28:15 AM
Jun 22 2006
parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Derek Parnell wrote:

 On Thu, 22 Jun 2006 17:31:16 -0700, BCS wrote:
 

 Derek Parnell wrote:

 On Thu, 22 Jun 2006 17:11:07 +0100, Stewart Gordon wrote:


 [...]

 And we could also do with some decent documentation on what arrays may 
 be converted to by explicit casting.


 As you may have noticed, Walter often gets a bit busy. It might then be a
 reasonable idea for you, or anyone else, to have a go at writing this
 documentation update and sending it to Walter for merging into the main
 documentation body.


 How do you get DMD to let you use depreciated "things"? I know it's in 
 there somewhere but I can't seem to find the switch.


 
 Use the "-d" switch. Documented under "Tools / DMD D Compiler"


And under the dmd command line help. BCS, that was hard to miss. *g*

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jun 23 2006
parent BCS <BCS pathlink.com> writes:
Bruno Medeiros wrote:

 Derek Parnell wrote:
 

 On Thu, 22 Jun 2006 17:31:16 -0700, BCS wrote:


 How do you get DMD to let you use depreciated "things"? I know it's 
 in there somewhere but I can't seem to find the switch.


 Use the "-d" switch. Documented under "Tools / DMD D Compiler"


 
 And under the dmd command line help. BCS, that was hard to miss. *g*
 


I'm blind, BLIND I TELL YOU!!  :-p



"The easy way to find the answer to a question is ask someone who knows. 
Usually you will figure it out yourself about half a second before they 
stop smirking and tell you." --B... er Anon.
Jun 23 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Stewart Gordon wrote:

 Walter Bright wrote:

 Stewart Gordon wrote:

 Walter Bright wrote:

 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html


 "Shadowing local variable declarations is now deprecated."

 I thought it had always been illegal by the spec.


 It wasn't implemented.


 
 So you've implemented it as a deprecation for the time being, rather 
 than banning it altogether?


Yes, because it breaks a lot of existing code.


 "Fixed Bugzilla 57  in 0.151"

 Why is this in the changelog for 0.161?


 It was overlooked.


 
 What do you mean?  The changelog for 0.151 also lists this bug as fixed.


Yes, but it was left open in bugzilla.



 "Fixed Bugzilla 36  (better error message)"
 "Fixed Bugzilla 85  (now issues error message)"

 And they're also marked as fixed in Bugzilla.  However, at the moment 
 I can't seem to find the bit of the spec that indicates that either 
 is illegal code.


 36: forward references are an ongoing issue, I'd like to get rid of 
 all such errors. But in the meantime, having feet of clay, some will 
 give error messages instead.


 
 Nobody else I know would claim that changing the error message resulting 
 from a bug constitutes fixing the bug.
 If the bug _is_ the bad error message, rather than the fact that an 
 error is produced at all, then that's another matter.


Giving clear error messages takes care of the problem for now.



 85: It can't be made to work, because an interface handle is different 
 from a class handle.


 
 But it can be made to create a new array of the interface type.  But 
 this should probably require an explicit cast.
 
 Just looking at the documentation, the "Implicit Conversions" section of 
 arrays.html mentions "U[] where U is a base class of T" - I now suppose 
 it's just a temptation to think that it would work on interfaces as 
 well.  Clarification would certainly be welcome.
 
 And we could also do with some decent documentation on what arrays may 
 be converted to by explicit casting.
 

 It doesn't work in C++, either, for the same reasons.


 Since when has C++ had interfaces?


Multiple inheritance is a superset of interfaces.
Jun 22 2006
prev sibling next sibling parent clayasaurus <clayasaurus gmail.com> writes:
Walter Bright wrote:

 Mostly bug fixes.
 
 http://www.digitalmars.com/d/changelog.html


thanks!
Jun 20 2006
prev sibling next sibling parent daniel.keep.lists gmail.com writes:
In article <e7832r$g4h$1 digitaldaemon.com>, Walter Bright says...

Mostly bug fixes.

http://www.digitalmars.com/d/changelog.html


Once again, you rock.  Thanks very much for this :)
Jun 20 2006
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:e7832r$g4h$1 digitaldaemon.com...

 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html


Oh man, those delegate literals look like it would be very possible to make 
interesting "pseudo-structures," that is, fake language constructs.  So if 
you were to define a function as

void func(void delegate() dg);

That is, the last parameter is a void delegate(), it would be an interesting 
bit of syntactic sugar to be able to write

func
{
    writefln("foo");
}

Not sure what utility this would present, but hey!
Jun 20 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Jarrett Billingsley wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e7832r$g4h$1 digitaldaemon.com...

 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html


 
 Oh man, those delegate literals look like it would be very possible to make 
 interesting "pseudo-structures," that is, fake language constructs.  So if 
 you were to define a function as
 
 void func(void delegate() dg);
 
 That is, the last parameter is a void delegate(), it would be an interesting 
 bit of syntactic sugar to be able to write
 
 func
 {
     writefln("foo");
 }
 
 Not sure what utility this would present, but hey! 


There was some thought about doing that, but I'm not so sure it wouldn't 
be more confusing than useful.
Jun 20 2006
next sibling parent reply Rémy Mouëza <Rémy_member pathlink.com> writes:
The new delegate syntax reminds me Smalltalk's code blocks. As far as I
remember, Ruby also uses code blocks with a syntax using braces rather than
bracket.

Smalltalk: 
collection do:[ :each | Transcript show: each asString ; cr. ].

D:
collection.do (( Object each ){ writefln ( each ); });
( a foreach would be preferrable in that case, but it's just to notice the
similarities ). 

D is getting greater and greater. Thanks Walter !!!
Jun 20 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Rémy Mouëza" <Rémy_member pathlink.com> wrote in message 
news:e79hbc$2tul$1 digitaldaemon.com...



 Smalltalk:
 collection do:[ :each | Transcript show: each asString ; cr. ].

 D:
 collection.do (( Object each ){ writefln ( each ); });
 ( a foreach would be preferrable in that case, but it's just to notice the
 similarities ).


That is an awesome comparison.
Jun 20 2006
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:e79d2a$2o0c$2 digitaldaemon.com...


 There was some thought about doing that, but I'm not so sure it wouldn't 
 be more confusing than useful.


Hehe, how true.  But hey, check it out:

void foo(void delegate() dg)
{
    writefln("before");
    dg();
}

foo =
{
    writefln("inside!");
};

A bit of property abuse..
Jun 20 2006
parent Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 20 Jun 2006 21:12:22 -0400, Jarrett Billingsley wrote:


 But hey, check it out:
 
 void foo(void delegate() dg)
 {
     writefln("before");
     dg();
 }
 
 foo =
 {
     writefln("inside!");
 };
 
 A bit of property abuse..


LOL ... Here is an extended test ...

import std.stdio;
void foo(void delegate() dg)
{
    writefln("before");
    dg();
    writefln("after\n");
}


void main(char[][] arg)
{
    char[] str;

    void bar()
    {
        writefln(arg[0] ~ ":" ~ str);
    }

    foo =
    {
        writefln("inside!");
    };

    foo =
    {
        writefln("again!");
    };

    foo( {writefln("last time");} );

    str = "not really";
    foo(&bar);
    str = "RUBBISH";
    foo = &bar;
}

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
21/06/2006 12:40:50 PM
Jun 20 2006
prev sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Walter Bright wrote:

 Jarrett Billingsley wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e7832r$g4h$1 digitaldaemon.com...

 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html


 Oh man, those delegate literals look like it would be very possible to 
 make interesting "pseudo-structures," that is, fake language 
 constructs.  So if you were to define a function as

 void func(void delegate() dg);

 That is, the last parameter is a void delegate(), it would be an 
 interesting bit of syntactic sugar to be able to write

 func
 {
     writefln("foo");
 }

 Not sure what utility this would present, but hey! 


 
 There was some thought about doing that, but I'm not so sure it wouldn't 
 be more confusing than useful.


With the new delegate syntax, and a very simple function one can finally 
replace the annoying and common case where a for-loop until now still 
has to be used:

void repeat(Int,Delegate)(Int n, Delegate d) {
	static assert(is(Int:int),"Argument 1 to repeat must be int");
	for (int i = 0; i < n; i++)
		d();
}

The implementation could also contain:
static if (NumberOfArgs!(Delegate) == 1)
   d(i);

The use is:

repeat(10, { something(); });

And the multi-line version becomes:

repeat(10, {
   something();
   somethingElse();
});

Which at least makes me wish for Jarretts suggested short form:

repeat(10) {
   something();
   somethingElse();
}

But the implications of having such power is almost scary... :)

/Oskar
Jun 29 2006
next sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
Oskar Linde wrote:

 Which at least makes me wish for Jarretts suggested short form:
 
 repeat(10) {
   something();
   somethingElse();
 }



But that's exactly what foreach does, isn't it? Would be cool if that 
construct would be made available to user functions!

L.
Jun 29 2006
prev sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Oskar Linde wrote:

 Walter Bright wrote:

 Jarrett Billingsley wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e7832r$g4h$1 digitaldaemon.com...

 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html


 Oh man, those delegate literals look like it would be very possible 
 to make interesting "pseudo-structures," that is, fake language 
 constructs.  So if you were to define a function as

 void func(void delegate() dg);

 That is, the last parameter is a void delegate(), it would be an 
 interesting bit of syntactic sugar to be able to write

 func
 {
     writefln("foo");
 }

 Not sure what utility this would present, but hey! 


 There was some thought about doing that, but I'm not so sure it 
 wouldn't be more confusing than useful.


 
 With the new delegate syntax, and a very simple function one can finally 
 replace the annoying and common case where a for-loop until now still 
 has to be used:
 
 void repeat(Int,Delegate)(Int n, Delegate d) {
     static assert(is(Int:int),"Argument 1 to repeat must be int");
     for (int i = 0; i < n; i++)
         d();
 }
 
 The implementation could also contain:
 static if (NumberOfArgs!(Delegate) == 1)
   d(i);
 
 The use is:
 
 repeat(10, { something(); });
 
 And the multi-line version becomes:
 
 repeat(10, {
   something();
   somethingElse();
 });
 
 Which at least makes me wish for Jarretts suggested short form:
 
 repeat(10) {
   something();
   somethingElse();
 }
 
 But the implications of having such power is almost scary... :)
 
 /Oskar


That's too much power for us puny mortals! :P

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 01 2006
prev sibling parent reply David Medlock <noone nowhere.com> writes:
Jarrett Billingsley wrote:


 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e7832r$g4h$1 digitaldaemon.com...
 

Mostly bug fixes.

http://www.digitalmars.com/d/changelog.html


 
 
 Oh man, those delegate literals look like it would be very possible to make 
 interesting "pseudo-structures," that is, fake language constructs.  So if 
 you were to define a function as
 
 void func(void delegate() dg);
 
 That is, the last parameter is a void delegate(), it would be an interesting 
 bit of syntactic sugar to be able to write
 
 func
 {
     writefln("foo");
 }
 
 Not sure what utility this would present, but hey! 
 
 


Deja Vu?

http://www.digitalmars.com/d/archives/digitalmars/D/24770.html

hehe.
Jun 29 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"David Medlock" <noone nowhere.com> wrote in message 
news:e818mk$fcj$2 digitaldaemon.com...


 Deja Vu?

 http://www.digitalmars.com/d/archives/digitalmars/D/24770.html

 hehe.


Heh, I thought I remembered that!
Jun 29 2006
prev sibling next sibling parent reply Jeremy <Jeremy_member pathlink.com> writes:
In article <e7832r$g4h$1 digitaldaemon.com>, Walter Bright says...

Mostly bug fixes.

http://www.digitalmars.com/d/changelog.html


This post might be more useful in here, because I think it might be a bug in the
latest v0.161 release, and I wanted to get Walter's attention :)

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39132
Jun 20 2006
parent Walter Bright <newshound digitalmars.com> writes:
Jeremy wrote:

 This post might be more useful in here, because I think it might be a bug in
the
 latest v0.161 release, and I wanted to get Walter's attention :)
 
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39132


I need a small, reproducible example.
Jun 20 2006
prev sibling next sibling parent reply Vladimir <vlasov scatt.com> writes:
Walter Bright wrote:

 Mostly bug fixes.
 
 http://www.digitalmars.com/d/changelog.html


Nice work, Walter. Thank you.

I hoped the following code will not compile with .161

#struct A




#void main()







Vladimir
Jun 20 2006
parent Walter Bright <newshound digitalmars.com> writes:
Vladimir wrote:

 Walter Bright wrote:

 Mostly bug fixes.

 http://www.digitalmars.com/d/changelog.html


 
 Nice work, Walter. Thank you.
 
 I hoped the following code will not compile with .161
 
 #struct A




 #void main()








A.x is a field, not a local variable, so the shadowing rule doesn't apply.
Jun 20 2006
prev sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:

 Mostly bug fixes.
 
 http://www.digitalmars.com/d/changelog.html


WOW! (For everything) :)
Jun 23 2006