A number of bugs fixed.

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

 Please update the Change Log!

Thanks,
Andrew

Andrew Edwards wrote:
>  Please update the Change Log!
> 
> Thanks,
> Andrew

Yeah, the file in the .zip is updated, but the website isn't. Here's the changes listed:

What's New for D 0.72
Sep 14, 2003
New/Changed Features

    * Implicit conversions of B[] to A[] are now allowed if B is derived from A.
    * Functions in abstract classes can now have function bodies.

Bugs Fixed

    * Fixed bug with in and out instructions in inline assembler.
    * Fixed speed problem with %.*s printf format.
    * Fixed problem with foreach over array of arrays or structs.
    * Fixed compiler error with array rehash.
    * Now correctly issues error on self-initializations like:
      int a = a;
    * Fixed problem converting "string" to char[], it should be an exact conversion, not an implicit conversion.

Linux Bugs Fixed

    * Occaisional segfault during gc collection fixed.
    * Empty static arrays now placed in BSS segment.
    * Conversion of uint to real now works.

Walter wrote:
> A number of bugs fixed.
> 
> http://www.digitalmars.com/d/changelog.html
> 

how do I create wchar strings now ?

(file wchartest.d is just the line)
wchar[] foo( wchar[] msg ) { return msg ~ "foo"; }

dmd -c wchartest.d
reports

wchartest.d(1): incompatible types for ((msg) ~ ("foo")): 'wchar[]' and 'char[]'

[linux(RH 9.0) dmd 0.72]

Mike Wynn wrote:
> Walter wrote:
> 
>> A number of bugs fixed.
>>
>> http://www.digitalmars.com/d/changelog.html
>>
> 
> how do I create wchar strings now ?
> 
> (file wchartest.d is just the line)
> wchar[] foo( wchar[] msg ) { return msg ~ "foo"; }
> 
> dmd -c wchartest.d
> reports
> 
> wchartest.d(1): incompatible types for ((msg) ~ ("foo")): 'wchar[]' and 'char[]'
> 
> [linux(RH 9.0) dmd 0.72]
> 
I tried
import utf;
wchar[] foo( wchar[] msg ) { return msg ~ toUTF16("foo"); }

but that causes
utftest.d(2): function toUTF16 overloads wchar[](char[]s) and wchar[](dchar[]s)
both match argument list for toUTF16

Walter wrote:
> A number of bugs fixed.
> 
> http://www.digitalmars.com/d/changelog.html
> 

while I like having the ability to pass a Derived[] as a Base[]
simply disallowing inout does not solve the problems of ending up with an instance of Base in your array (or worse).
cast(X[])ar should check all elements of ar;
I've not used two threads but is I had then its easy to see a sitation where one thread sees an array as a B[] (or worse Object[]) the other sees the same range as D[], and chaos may follow shortly after

as in

import c.stdio;

class A {
	int val = 99;
	void printStuff( int a, A b ) { printf( "A::printInts(%d, %d)\n", a, b.val ); }
}
class B {
	void printInts( int a, int b ) { printf( "B::printInts(%d, %d)\n", a, b ); }
}
class D : B {
	void printInts( int a, int b ) { printf( "D::printInts(%d, %d)\n", a, b ); }
}

void show( B[] bs ) {
	foreach( B b; bs ) { b.printInts( 1, 2 ); }
}
void showA( A[] as ) {
	foreach( A a; as ) { a.printStuff( 1, a ); }
}

void addB( B[] bs ) {
	bs[0] = new B();
}

void addA( Object[] os ) {
	os[1] = new A();
	printf( "after addA:\n" );
	showA( cast(A[])os );
}

int main( char[][] args ) {
	D[] ds;
	ds ~= new D();
	ds ~= new D();
	ds ~= new D();
	printf( "ds:\n" );
	show( ds );
	addB( ds );
	printf( "after addB:\n" );
	show( ds );
	addA( ds );
	printf( "done\n" );
	return 0;
}

-----------------------
outputs
ds:
D::printInts(1, 2)
D::printInts(1, 2)
D::printInts(1, 2)
after addB:
B::printInts(1, 2)
D::printInts(1, 2)
D::printInts(1, 2)
after addA:
B::printInts(1, 1074098048)
A::printInts(1, 99)
D::printInts(1, 1074098064)
done

"Mike Wynn" <mike@l8night.co.uk> wrote in message news:bk5k38$m5t$1@digitaldaemon.com...
> Walter wrote:
> > A number of bugs fixed.
> >
> > http://www.digitalmars.com/d/changelog.html
> >
>
> while I like having the ability to pass a Derived[] as a Base[]
> simply disallowing inout does not solve the problems of ending up with
> an instance of Base in your array (or worse).
> cast(X[])ar should check all elements of ar;
> I've not used two threads but is I had then its easy to see a sitation
> where one thread sees an array as a B[] (or worse Object[]) the other
> sees the same range as D[], and chaos may follow shortly after

I know about that gaping hole in type safety, but I don't see a fix for it. It happens in C++ as well.

"Mike Wynn" <mike@l8night.co.uk> wrote in message news:bk5hf9$i90$1@digitaldaemon.com...
> Walter wrote:
> > A number of bugs fixed.
> >
> > http://www.digitalmars.com/d/changelog.html
> >
>
> how do I create wchar strings now ?
>
> (file wchartest.d is just the line)
> wchar[] foo( wchar[] msg ) { return msg ~ "foo"; }
>
> dmd -c wchartest.d
> reports
>
> wchartest.d(1): incompatible types for ((msg) ~ ("foo")): 'wchar[]' and
> 'char[]'

I should fix that. In the meantime, you can rewrite "foo" as
cast(wchar[])"foo", or make
    wchar[] foo = "foo";
    return msg ~ foo;

Walter wrote:
> A number of bugs fixed.
> 
> http://www.digitalmars.com/d/changelog.html
> 
> 
> 
there seems to be a problem with wchar switchs I have some code that reads from a file (bytes) and casts to wchar ... though that was the problem, has taken me a while to get a 10 line prog to repro this ...
but here it is with internal strings.

----------------------------------

import c.stdio;

wchar[] getName() {
	return "name";
}

int main(char[][] args ) {
	wchar[] tmp = getName();
	switch( tmp ) {	
	case "name":
		printf("switch to name\n");
		break;
	case "afoo": printf("switch to afoo\n"); break;
	default:
		printf("switch to default(not afoo or name)\n");
		printf("tmp[0..%d]:\n", tmp.length);
		for( int i = 0; i < tmp.length; i++ ) {
			printf("tmp[%d] = '%c'(%d)\n", i, cast(char)tmp[i], cast(int)tmp[i] );
		}
		break;
	}
	return 0;
}
---------------------------
switch to default(not afoo or name)
tmp[0..4]:
tmp[0] = 'n'(110)
tmp[1] = 'a'(97)
tmp[2] = 'm'(109)
tmp[3] = 'e'(101)

Walter wrote:
> "Mike Wynn" <mike@l8night.co.uk> wrote in message
> news:bk5k38$m5t$1@digitaldaemon.com...
> 
>>Walter wrote:
>>
>>>A number of bugs fixed.
>>>
>>>http://www.digitalmars.com/d/changelog.html
>>>
>>
>>while I like having the ability to pass a Derived[] as a Base[]
>>simply disallowing inout does not solve the problems of ending up with
>>an instance of Base in your array (or worse).
>>cast(X[])ar should check all elements of ar;
>>I've not used two threads but is I had then its easy to see a sitation
>>where one thread sees an array as a B[] (or worse Object[]) the other
>>sees the same range as D[], and chaos may follow shortly after
> 
> 
> I know about that gaping hole in type safety, but I don't see a fix for it.
> It happens in C++ as well.
> 
never used to ... C++ never used to allow derived* x[] to be passed as base* x[]

and just 'cos it happens in C++ does not seem a very "D" justification for including the feature (thought the idea was to improve on C++).

Java does, but has runtime checks (the solution).

other solutions ...
derived[] is (readonly base[]) is another solution but there is no way to pass readonly arrays.

internal copy on write, or dup (its an `in` array so the question of the programmers ability to write to it and modify its original values rears its head again).

finally why is Derived[] a subclass of Base[] ??
will `instance MyTemplate(Derived).someclass` be automatically a subclass of `instance MyTemplate(Base).someclass`