Re: Inside the switch statement
Thanks so much for all your help!I am studying hard to *loop unrolling*. BTW: where is this from? It is from the spec: http://www.digitalmars.com/d/1.0/template-mixin.html BTW,is this Duff? http://groups.google.com/group/net.lang.c/msg/66008138e07aa94c
Re: Inside the switch statement
http://groups.google.com/group/net.lang.c/msg/66008138e07aa94c Many people (even Brian Kernighan?) have said that the worst feature of C is that switches don't break automatically before each case label. Oh god, that's from 1984, and even today we're struggling with this bullshit in the most modern dialect of C, D.
Equality Methods
I have already asked about this topic here months ago, but now I know a bit
more OOP, so I can raise the bar for myself a bit. So now I consider class
inheritance too. I am trying to write correct equality Methods.
I have read this nice article about equality in Java, the things it says can be
used equally in D too:
http://www.artima.com/lejava/articles/equality.html
Even comparing really simple objects can be not easy to do.
So do you see troubles/ bugs/ things that can be improved in the following
code? (D1, Phobos, putr is writefln):
import std.string: format;
import std.stdio: putr = writefln;
/// Used by all exceptions
template ExceptionTemplate() {
this() {
super(this.classinfo.name);
}
this(string msg) {
super(this.classinfo.name ~ : ~ msg);
}
}
/// Thrown by user-defined opCmp() of classes
class UncomparableException: Exception {
mixin ExceptionTemplate;
}
class Point {
// in practice for this purpose, instead of re-defining opEquals,
// opCmp, opHash, etc, I use a Record (Tuple in Phobos2).
alias typeof(this) TyThis;
private final int x, y;
this(int x, int y) {
this.x = x;
this.y = y;
}
public int opEquals(Object other) {
auto that = cast(TyThis)other;
return that !is null that.canEqual(this)
this.x == that.x this.y == that.y;
}
public bool canEqual(Object other) {
return cast(TyThis)other !is null; // ?
}
public hash_t toHash() {
return (41 * (41 + this.x) + this.y); // ugly, but it doesn't matter now
}
public int opCmp(Object other) {
auto that = cast(TyThis)other;
if (that is null || !that.canEqual(this)) // ?
throw new UncomparableException();
if (this.x == that.x)
return this.y - that.y;
else
return this.x - that.x;
}
public string toString() {
return format(Point(%d, %d), this.x, this.y);
}
}
enum Color { RED, ORANGE, YELLOW, GREEN, BLUE, INDIGO, VIOLET }
public class ColoredPoint : Point {
alias typeof(this) TyThis;
private final Color color;
this(int x, int y, Color color) {
super(x, y);
this.color = color;
}
// define this if you want this uncomparable to the base class
override public bool canEqual(Object other) {
return cast(TyThis)other !is null; // ?
}
override public int opEquals(Object other) { // bug: not symmetric
auto that = cast(TyThis)other;
return that !is null that.canEqual(this)
this.color == that.color super.opEquals(that); // ?
}
override public int opCmp(Object other) {
auto that = cast(TyThis)other;
if (that is null || !that.canEqual(this)) // ?
throw new UncomparableException();
// coordinates are more important than color
int super_cmp = super.opCmp(that);
if (super_cmp == 0)
return this.color - that.color;
else
return super_cmp;
}
public string toString() {
return format(Point(%d, %d), this.x, this.y);
}
}
class Point2 : Point {
this(int x, int y) {
super(x, y);
}
}
class Point3 : Point {
alias typeof(this) TyThis;
this(int x, int y) {
super(x, y);
}
public bool canEqual(Object other) {
return cast(TyThis)other !is null; // ?
}
}
void main() {
auto p1 = new Point(1, 1);
auto p2 = new Point(1, 1);
auto p3 = new Point(1, 2);
putr(p1 == p2, , p2 == p1); // 1 1
putr(p1 == p3, , p3 == p1); // 0 0
putr(p2 == p3, , p3 == p2); // 0 0
int[Point] aa = [p1:1, p2:2, p3:3];
putr(aa);
auto p4 = new Point(1, 0);
auto p5 = new Point(2, 0);
auto p6 = new Point(0, 2);
putr(p1 p3, , p3 p1); // false true
putr(p1 p4, , p4 p1); // true false
putr(p1 p5, , p5 p1); // false true
putr(p1 p6, , p6 p1); // true false
putr();
Point p8 = new Point(1, 2);
ColoredPoint cp1 = new ColoredPoint(1, 2, Color.RED);
putr(p8 == cp1); // prints 0
putr(cp1 == p8); // prints 0
//putr(p8 cp1); // uncomparable exception
//putr(p8 cp1); // uncomparable exception
//putr(p8 cp1); // uncomparable exception
//putr(cp1 p8); // uncomparable exception
//putr(cp1 p8); // uncomparable exception
putr();
putr(cast(Point)p1 !is null, , cast(Point)cp1 !is null);
// true true
putr(cast(ColoredPoint)p1 !is null, , cast(ColoredPoint)cp1 !is null);
// false true
putr(p1.classinfo == p2.classinfo, , p1.classinfo == p6.classinfo); //
1 1
putr(cp1.classinfo == p1.classinfo, , p1.classinfo == cp1.classinfo); //
0 0
putr();
auto pp1 = new Point2(1, 1);
putr(p1 == pp1); // 1
putr(p1 pp1, , p1 pp1); // false false
auto pp2 = new Point3(1, 1);
putr(p1 == pp2); // 0
//putr(p1 pp2, , p1 pp2); // uncomparable
Error 1: Previous Definition Different, Error 42: Symbol Undefined
I get this error with dmd 1.045. The _errno seems to be with the DAllegro (http://www.dsource.org/projects/dallegro) library. And the 42 one to do with some thing of mine. OPTLINK (R) for Win32 Release 8.00.1 Copyright (C) Digital Mars 1989-2004 All rights reserved. C:\jpro\dmd45\windows\bin\..\lib\SNN.lib(cinit) Offset 08C2CH Record Type 0090 Error 1: Previous Definition Different : _errno main.obj(main) Error 42: Symbol Undefined _D22TypeInfo_C3jec3snd3Snd6__initZ
Re: Inside the switch statement
Hello grauzone, http://groups.google.com/group/net.lang.c/msg/66008138e07aa94c Many people (even Brian Kernighan?) have said that the worst feature of C is that switches don't break automatically before each case label. Oh god, that's from 1984, and even today we're struggling with this bullshit in the most modern dialect of C, D. I'm sorry, you don't have my sympathy on this one. There are to many place I've used fall throught to chuck it out.
Re: Inside the switch statement
BCS wrote: Hello grauzone, http://groups.google.com/group/net.lang.c/msg/66008138e07aa94c Many people (even Brian Kernighan?) have said that the worst feature of C is that switches don't break automatically before each case label. Oh god, that's from 1984, and even today we're struggling with this bullshit in the most modern dialect of C, D. I'm sorry, you don't have my sympathy on this one. There are to many place I've used fall throught to chuck it out. What kind of fall-throughs were these? A: case value1: case value2: case valueN: code1(); break; B: case value1: code1(); case value2: code2(); break;
Re: Inside the switch statement
Hello grauzone, BCS wrote: Hello grauzone, http://groups.google.com/group/net.lang.c/msg/66008138e07aa94c Many people (even Brian Kernighan?) have said that the worst feature of C is that switches don't break automatically before each case label. Oh god, that's from 1984, and even today we're struggling with this bullshit in the most modern dialect of C, D. I'm sorry, you don't have my sympathy on this one. There are to many place I've used fall throught to chuck it out. What kind of fall-throughs were these? A: case value1: case value2: case valueN: code1(); break; I don't do that, I go with this form: case value1, value2, valueN: code1(); break; case B, The most usefull case was where I used the switch as a jump into the middle of this block of code device. B: case value1: code1(); case value2: code2(); break;
Re: Inside the switch statement
grauzone wrote:
BCS wrote:
Hello grauzone,
http://groups.google.com/group/net.lang.c/msg/66008138e07aa94c
Many people (even Brian Kernighan?) have said that the worst feature
of C is that switches don't break automatically before each case
label.
Oh god, that's from 1984, and even today we're struggling with this
bullshit in the most modern dialect of C, D.
I'm sorry, you don't have my sympathy on this one. There are to many
place I've used fall throught to chuck it out.
What kind of fall-throughs were these?
A:
case value1:
case value2:
case valueN:
code1();
break;
B:
case value1:
code1();
case value2:
code2();
break;
The solution is to forbid fallthrough, and change the switch syntax:
switch(value) {
case 1:
case 2:
// something
break;
}
gives: Error, missing break at the end of case1.
But:
switch(value) {
case 1, 2:
// something
break;
}
works as expected.
What's wrong with that?
Re: Inside the switch statement
What kind of fall-throughs were these?
A:
case value1:
case value2:
case valueN:
code1();
break;
B:
case value1:
code1();
case value2:
code2();
break;
The solution is to forbid fallthrough, and change the switch syntax:
switch(value) {
case 1:
case 2:
// something
break;
}
gives: Error, missing break at the end of case1.
But:
switch(value) {
case 1, 2:
// something
break;
}
works as expected.
What's wrong with that?
Doesn't support B :)
How about a warning instead?
Re: Inside the switch statement
Saaa wrote:
What kind of fall-throughs were these?
A:
case value1:
case value2:
case valueN:
code1();
break;
B:
case value1:
code1();
case value2:
code2();
break;
The solution is to forbid fallthrough, and change the switch syntax:
switch(value) {
case 1:
case 2:
// something
break;
}
gives: Error, missing break at the end of case1.
But:
switch(value) {
case 1, 2:
// something
break;
}
works as expected.
What's wrong with that?
Doesn't support B :)
How about a warning instead?
The idea is that it not supporting B is something good.
An error is ok, and if you want to translate C code then it's really
easy to change the code to not give errors.
Re: Inside the switch statement
What's wrong with that? Doesn't support B :) How about a warning instead? The idea is that it not supporting B is something good. I know this is your idea, but as BCS doesn't support this idea. You should have replied to him iso grauzone. I personally never had any problems with falling through. The IDE ( descent :) indents it nicely. An error is ok, and if you want to translate C code then it's really easy to change the code to not give errors. I don't think you will get that, thus maybe a warning is better than nothing?
Re: Inside the switch statement
How do you know? BCS didn't reply to my idea. Your idea was to give an error on the case (B) he uses. Or did I miss something?
Re: Inside the switch statement
Saaa wrote: How do you know? BCS didn't reply to my idea. Your idea was to give an error on the case (B) he uses. Or did I miss something? You missed the alternative syntax to get the same behaviour. But it's a very subtle difference.
Re: Inside the switch statement
You missed the alternative syntax to get the same behaviour. But it's a very subtle difference. Do you mean the multiple cases? http://www.digitalmars.com/d/1.0/statement.html#SwitchStatement
Re: Inside the switch statement
Saaa wrote: You missed the alternative syntax to get the same behaviour. But it's a very subtle difference. Do you mean the multiple cases? http://www.digitalmars.com/d/1.0/statement.html#SwitchStatement Yes, but make the multiple cases the *only* way to make case statements fallthrough. That would be the change.
Re: Inside the switch statement
Yes, but make the multiple cases the *only* way to make case statements fallthrough. That would be the change. That is the same as giving an error on case B, right?
Re: Inside the switch statement
I mean, the syntax stays the same.
Re: Inside the switch statement
Saaa wrote: Yes, but make the multiple cases the *only* way to make case statements fallthrough. That would be the change. That is the same as giving an error on case B, right? Well, yes, but you also have to prepare your mind for the change. This is a huge step. (nah, just kidding, you're right, I didn't realize it :-P)
Re: Inside the switch statement
Well, yes, but you also have to prepare your mind for the change. This is a huge step. ;)
Re: Inside the switch statement
(nah, just kidding, you're right, I didn't realize it :-P) Ok, enough kidding around, lets get back to you helping me with 'code generalization' :P
Re: Inside the switch statement
Saaa wrote: (nah, just kidding, you're right, I didn't realize it :-P) Ok, enough kidding around, lets get back to you helping me with 'code generalization' :P Write a lexer and a parser.
Re: Inside the switch statement
Write a lexer and a parser. how do you mean?
D compiler for .NET
Earlier today, I tried to use the D compiler for .NET from http://dnet.codeplex.com/ Beyond compilation of the compiler, I found zero instructions on what to do next. How do I integrate the compiler into the .NET framework/visual studio? I'd like to be able to add D files to existing solutions (with C# code). If I can do that, I'll probably push for some small adoption of D at work. (I'm hoping mixins and templates will inspire the initial use of D) Any tips or documentation on how to get started would be appreciated.
Re: D compiler for .NET
Jason House wrote: Earlier today, I tried to use the D compiler for .NET from http://dnet.codeplex.com/ Beyond compilation of the compiler, I found zero instructions on what to do next. How do I integrate the compiler into the .NET framework/visual studio? I'd like to be able to add D files to existing solutions (with C# code). If I can do that, I'll probably push for some small adoption of D at work. (I'm hoping mixins and templates will inspire the initial use of D) Any tips or documentation on how to get started would be appreciated. The back-end code is not of production quality, it is intended for research and educational purposes. The D Programming Language is a fairly complex language, and non-trivial features such as TLS and closures make it an interesting case study for generating IL code. Why do people never read the big red label saying Warning: not ready for use!? As for VS integration, so far as I know, there isn't any. I'm also fairly certain that you can't combine different languages in a single project period.
