www.digitalmars.com         C & C++   DMDScript  

D - DMD 0.72 release

reply "Walter" <walter digitalmars.com> writes:
A number of bugs fixed.

http://www.digitalmars.com/d/changelog.html
Sep 14 2003
next sibling parent reply "Andrew Edwards" <edwardsac spamfreeusa.com> writes:
 Please update the Change Log!

Thanks,
Andrew
Sep 14 2003
parent J C Calvarese <jcc7 cox.net> writes:
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.
Sep 14 2003
prev sibling next sibling parent reply Mike Wynn <mike l8night.co.uk> writes:
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]
Sep 15 2003
next sibling parent Mike Wynn <mike l8night.co.uk> writes:
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
Sep 15 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"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;
Sep 15 2003
parent reply Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:

 "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;
 


how safe is cast(wchar[])"...." because casting char[]<->wchar[]

as in ...

import c.stdio;

void showstrw( wchar[] tmp ) {
	printf( "len:%d ", tmp.length );
	for( int i = 0; i < tmp.length; i++ ) {
		printf("'%c'(%d) ", cast(char)tmp[i], cast(int)tmp[i] );
	}
}
void showstra( char[] tmp ) {
	printf( "len:%d ", tmp.length );
	for( int i = 0; i < tmp.length; i++ ) {
		printf("'%c'(%d) ", tmp[i], cast(int)tmp[i] );
	}
}

void process( char[] oca, wchar[] owa ) {
	printf( "\n wchar array as wchars    : " ); showstrw( owa );
	printf( "\n wchar array cast(char[]) : " ); showstra( cast(char[])owa );
	printf( "\n\n char array as chars      : " ); showstra( oca );
	printf( "\n char array cast(wchar[]) : " ); showstrw( cast(wchar[])oca );
	printf( "\n\n" );
}

int main(char[][] args ) {
	wchar[] owa = "abcd";
	char[]  oca = "abcd";
	process( oca.dup, owa.dup );
	return 0;
}

outputs
  wchar array as wchars    : len:4 'a'(97) 'b'(98) 'c'(99) 'd'(100)
  wchar array cast(char[]) : len:8 'a'(97) ''(0) 'b'(98) ''(0) 'c'(99) 
''(0) 'd'(100) ''(0)

  char array as chars      : len:4 'a'(97) 'b'(98) 'c'(99) 'd'(100)
  char array cast(wchar[]) : len:2 'a'(25185) 'c'(25699)

(linux dmd 0.72)
Sep 15 2003
parent "Walter" <walter digitalmars.com> writes:
"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bk611g$22fm$1 digitaldaemon.com...

 Walter wrote:

 "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;


 how safe is cast(wchar[])"...." because casting char[]<->wchar[]


Casting a "string" is handled specially by the compiler and it will do the
UTF-8=>UTF-16 conversion on the literal.
Sep 15 2003
prev sibling next sibling parent reply Mike Wynn <mike l8night.co.uk> writes:
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
Sep 15 2003
parent reply "Walter" <walter digitalmars.com> writes:
"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.
Sep 15 2003
next sibling parent Mike Wynn <mike l8night.co.uk> writes:
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`
Sep 15 2003
prev sibling next sibling parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 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.


It is relatively easy to fix if the conversion is restricted to argument
with the proper type (that is in parameter --- in should apply to
the whole array).

I think that we should make it safe only if no casting is used...
(similar to C++).

Speaking of cast, I think that we should have more than one cast
operator so that we can be more explicit on what we want to
allows as conversion...

Casting to Derived[] an object of type Base[] should check
that the array was an array of Derived...Casting from
Derived[] to Base[] should require a cast except when
a modifier say that the array is in (or const if it was
supported --- another subject!!!)
Sep 15 2003
prev sibling next sibling parent reply nobody yahoo.com writes:
In article <bk5l19$p7k$1 digitaldaemon.com>, Walter says...

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


Please read Eiffel, also the multiple inheritance (MI) solution in Eiffel is
worth study.
Sep 15 2003
next sibling parent nobody yahoo.com writes:
In article <bk60t4$223l$1 digitaldaemon.com>, nobody yahoo.com says...

In article <bk5l19$p7k$1 digitaldaemon.com>, Walter says...

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


Please read Eiffel, also the multiple inheritance (MI) solution in Eiffel is
worth study.


P.S.  It's called type conformance rules.  Try to google "eiffel type
conformance rules":

http://www.pi.informatik.tu-darmstadt.de/inf1/eiff-ref/chap13.htm
Sep 15 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
<nobody yahoo.com> wrote in message news:bk60t4$223l$1 digitaldaemon.com...

 In article <bk5l19$p7k$1 digitaldaemon.com>, Walter says...

I know about that gaping hole in type safety, but I don't see a fix for




it.

It happens in C++ as well.


 Please read Eiffel, also the multiple inheritance (MI) solution in Eiffel


is

 worth study.


Would you like to summarize it here for the newsgroup readers?
Sep 15 2003
parent reply nobody yahoo.com writes:
In article <bk62pb$26ig$3 digitaldaemon.com>, Walter says...

<nobody yahoo.com> wrote in message news:bk60t4$223l$1 digitaldaemon.com...

 In article <bk5l19$p7k$1 digitaldaemon.com>, Walter says...

I know about that gaping hole in type safety, but I don't see a fix for




it.

It happens in C++ as well.


 Please read Eiffel, also the multiple inheritance (MI) solution in Eiffel


is

 worth study.


Would you like to summarize it here for the newsgroup readers?



For type conformance:

http://www.pi.informatik.tu-darmstadt.de/inf1/eiff-ref/chap13.htm

A quick summary (note, generic ~= template in C++/D):

Let T and V be two types. V conforms to T if and only if one of the following
holds:

1. V and T are identical.
2. V conforms directly to T.
3. V is NONE and T is a reference type.
4. V is B [Y1,... Yn] for some generic class B, T is B [X1,... Xn], and every
one of the Yi conforms (recursively) to the corresponding Xi.
5. T is a reference type and, for some type U, V conforms to U and U conforms
(recursively) to T. 


For multiple inheritance (MI):

http://www.pi.informatik.tu-darmstadt.de/inf1/eiff-ref/chap10.htm
http://www.pi.informatik.tu-darmstadt.de/inf1/eiff-ref/chap11.htm
http://www.pi.informatik.tu-darmstadt.de/inf1/eiff-ref/chap12.htm

Inheritance ::=
inherit Parent_list 

Parent_list ::=
{Parent Separator ...}

Parent ::=
Restricted_class_type [Feature_adaptation]

Feature_adaptation ::=
[Rename] 
[New_exports] 
[Undefine] 
[Redefine] 
[Select] 
end
Sep 15 2003
parent "Walter" <walter digitalmars.com> writes:
Thanks!
Sep 16 2003
prev sibling parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Walter" <walter digitalmars.com> escreveu na mensagem
news:bk5l19$p7k$1 digitaldaemon.com...

 "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.


IME this is a Bad Thing. Usually we have three kinds of subtyping:

1. common covariant subtyping: used for values (e.g. integer is a subtype of
real);
2. contravariant subtyping: used for functions, where (using "->" to denote
function type, "int -> bool" is a function that take an "int" and returns a
"bool", and "<:" to denote subtype of) it holds "A' <: A", "B' <: B" and
"(A -> B') <: (A' -> B)". That in the subtype the parameter can be
generalized and the return type can be constrained. A example would be the
the type "real -> int" that is a subtype of "int -> real". A example in D:


class Real {...}
class Integer : Real {...}

Integer i = new Integer(42);
Real r = null;
Real function(Integer) f;
Integer function(Real) g = Integer function(Real r)  { return
r.truncate(); };

f = g;    // contravariant rule say it's ok.
r = f(i); // g expects any Real, so it's ok to pass an Integer.
          // g returns a Integer, so it's ok to treat it as a Real.


3. invariant subtyping: used for mutable arrays. In this situation there's
no subtyping possibility, because of possible undesirable assignments:


class A {}
class B : A {}
class C : A {}

void bind(A[] as, A a) {
    as[0] = a;  // ok
}
int main() {
    static B[] bs = [new B(), new B()];
    bind(bs, new C());   // ops, if covariance was ok this would break
type-safety.
}


Java has this hole in their type-system, but they use a runtime check to
verify that nobody calls "bind" passing a value that the array rejects. As
we have templates in D, which are capable of F-bounded polymorphism
(impressive, huh? ;), someone can rewrite bind as:


template TBind(T : A) {
    void bind(T[] ts, T t) {
        ts[0] = t;
    }
}


And the template instatiation would point the error at compile time. IMO
it's completely unnecessary to allow array subtyping in a system that has
the correct mechanism to write generic array operations. Java doesn't have
(1.5 is in the future) generics so they had to allow such holes in their
type-system, or else people would have to write the same array libraries for
every possible type. It doesn't kill people to write templates (using them
may kill some ;) specially when they lead to correct code. If the template
syntax starts to get in the way it's a sign that the syntax should be
changed.

    Best regards,
    Daniel Yokomiso.

"Enlightenment does not divide you, just as the moon does not break the
water. The depth of the drop is the height of the moon."
 - Dogen


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.518 / Virus Database: 316 - Release Date: 11/9/2003
Sep 16 2003
parent "Walter" <walter digitalmars.com> writes:
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bk88jp$gi$1 digitaldaemon.com...

 And the template instatiation would point the error at compile time. IMO
 it's completely unnecessary to allow array subtyping in a system that has
 the correct mechanism to write generic array operations. Java doesn't have
 (1.5 is in the future) generics so they had to allow such holes in their
 type-system, or else people would have to write the same array libraries


for

 every possible type. It doesn't kill people to write templates (using them
 may kill some ;) specially when they lead to correct code. If the template
 syntax starts to get in the way it's a sign that the syntax should be
 changed.


I think you're right. I'll change it back :-(
Sep 16 2003
prev sibling parent reply Mike Wynn <mike l8night.co.uk> writes:
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)
Sep 15 2003
parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
That code works here using 0.72 , windows 2000 advanced, dmc8.36


switch to name


Charles

"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bk5t54$1njn$1 digitaldaemon.com...

 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)
Sep 16 2003
parent reply Mike Wynn <mike l8night.co.uk> writes:
Charles Sanders wrote:

 That code works here using 0.72 , windows 2000 advanced, dmc8.36
 


sorry forgot the version/os - linux(RH9 gcc 3.2.2) dmd 0.71 and 0.72

small changes and it works like adding ":" ~ val and ":..."
only seems to be an issue with 4 char values ...

 

switch to name


 
 
 Charles
 
 "Mike Wynn" <mike l8night.co.uk> wrote in message
 news:bk5t54$1njn$1 digitaldaemon.com...
 

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)
Sep 16 2003
parent "Charles Sanders" <sanders-consulting comcast.net> writes:
 small changes and it works like adding ":" ~ val and ":..."
 only seems to be an issue with 4 char values ...


hmm weird.


"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bk7cv4$2ce$1 digitaldaemon.com...

 Charles Sanders wrote:

 That code works here using 0.72 , windows 2000 advanced, dmc8.36


 sorry forgot the version/os - linux(RH9 gcc 3.2.2) dmd 0.71 and 0.72

 small changes and it works like adding ":" ~ val and ":..."
 only seems to be an issue with 4 char values ...

switch to name



 Charles

 "Mike Wynn" <mike l8night.co.uk> wrote in message
 news:bk5t54$1njn$1 digitaldaemon.com...


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)
Sep 16 2003