digitalmars.D - Reality drives me to write less clean code, sorry for mistakenly posting in D.announce
- davidl (53/53) Oct 11 2007 First practice:
- Bill Baxter (9/80) Oct 11 2007 Don't be so sure. Did you measure it?
- Mike Parker (8/15) Oct 11 2007 Pointer arithmetic in D is a no-no, unless you are using memory
- Bill Baxter (5/23) Oct 11 2007 That's news to me. There's nothing wrong with using pointers, it's just...
- Mike Parker (10/25) Oct 12 2007 Of course there's nothing wrong with /using/ pointers, but pointer
- Mike Parker (13/40) Oct 12 2007 Hmm. I could have sworn I had read something explicitly saying that any
- Don Clugston (7/34) Oct 12 2007 I can't see anything about pointer arithmetic in that section. Did I mis...
- Charles D Hixson (6/31) Oct 13 2007 I've seen several comments against it, but I don't know how
- Ary Manzana (8/18) Oct 12 2007 Problem is, the code davidl is trying to do is a port of DMD's front-end...
- 0ffh (8/10) Oct 12 2007 What makes you say that?
- Mike Parker (5/19) Oct 12 2007 Yes, yes. I've already posted that I was mistaken about having read it
- 0ffh (18/20) Oct 13 2007 Yes, I've seen it, but too late... I admit I should probably have read
First practice: char[] text; char* p; char* end; Version1: p=text.ptr; end= text.ptr+length; we use p to scan over the text, and end as a mark. Version2: text[blah] to scan over the text. Obviously version 2 is cleaner, but slower. Second practice: version 1: enum basictype { tint, tint32, tunsint32, tlong, tuslong32, tcomplex, tcomplex64, tcomplex80, timaginary, timaginary64, timaginary80, } class Type { basictype bt; } we do some switch-case to test what on earth this type is in this case. version2: class Type{} interface TypeReal:TypeComplex{} interface TypeImaginary:TypeComplex{} interface TypeComplex{} interface Type32bit{} interface Type64bit{} interface Type80bit{} interface TypeUnsigned{} class TypeNumber:Type{} class TypeUSInt:TypeNumber, Type32bit, TypeUnsigned{} class TypeInt:TypeNumber,Type32bit {} class TypeComplex64:TypeNumber,TypeComplex, Type64bit {} class TypeComplex80:TypeNumber,TypeComplex, Type80bit{} class TypeImaginary:TypeNumber,TypeImaginary {} class TypeImaginary64:TypeNumber,TypeImaginary, Type64bit{} Honestly, I prefer version2 a little bit more to version1. But, version2 gets too much runtime penalty. Ideas? -- 使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
Oct 11 2007
davidl wrote:First practice: char[] text; char* p; char* end; Version1: p=text.ptr; end= text.ptr+length; we use p to scan over the text, and end as a mark. Version2: text[blah] to scan over the text. Obviously version 2 is cleaner, but slower.Don't be so sure. Did you measure it? And don't forget Version3: foreach(c; text) { ... } Supposedly generates code as efficient as a for loop.Second practice: version 1: enum basictype { tint, tint32, tunsint32, tlong, tuslong32, tcomplex, tcomplex64, tcomplex80, timaginary, timaginary64, timaginary80, } class Type { basictype bt; } we do some switch-case to test what on earth this type is in this case. version2: class Type{} interface TypeReal:TypeComplex{} interface TypeImaginary:TypeComplex{} interface TypeComplex{} interface Type32bit{} interface Type64bit{} interface Type80bit{} interface TypeUnsigned{} class TypeNumber:Type{} class TypeUSInt:TypeNumber, Type32bit, TypeUnsigned{} class TypeInt:TypeNumber,Type32bit {} class TypeComplex64:TypeNumber,TypeComplex, Type64bit {} class TypeComplex80:TypeNumber,TypeComplex, Type80bit{} class TypeImaginary:TypeNumber,TypeImaginary {} class TypeImaginary64:TypeNumber,TypeImaginary, Type64bit{} Honestly, I prefer version2 a little bit more to version1. But, version2 gets too much runtime penalty. Ideas?No, sorry. Maybe you could explain your requirements a little more clearly. The two examples look like they will do different things. --bb
Oct 11 2007
davidl wrote:First practice: char[] text; char* p; char* end;Pointer arithmetic in D is a no-no, unless you are using memory allocated outside of the GC. To iterate over a D string, or any array, use foreach: foreach(c; text) { // do something with c }
Oct 11 2007
Mike Parker wrote:davidl wrote:That's news to me. There's nothing wrong with using pointers, it's just more verbose and error prone than foreach.First practice: char[] text; char* p; char* end;Pointer arithmetic in D is a no-no, unless you are using memory allocated outside of the GC.To iterate over a D string, or any array, use foreach: foreach(c; text) { // do something with c }... or use foreach(dchar c; text) if you care about handling non-ascii properly.
Oct 11 2007
Bill Baxter wrote:Mike Parker wrote:Of course there's nothing wrong with /using/ pointers, but pointer arithmetic is one item in a list of 'Undefined Behavior' regarding pointers to GC memory. See the page http://www.digitalmars.com/d/garbage.html (section titled Pointers and the Garbage Collector). This isn't really an issue in the present since the current GC doesn't move anything around, AFAIK. But it's still a bad habit to get into (or a good one to get out of for people with C backgrounds) and doesn't do much for future-proofing.davidl wrote:That's news to me. There's nothing wrong with using pointers, it's just more verbose and error prone than foreach.First practice: char[] text; char* p; char* end;Pointer arithmetic in D is a no-no, unless you are using memory allocated outside of the GC.
Oct 12 2007
Mike Parker wrote:Bill Baxter wrote:Hmm. I could have sworn I had read something explicitly saying that any pointer arithmetic was bad. Looking at it again, the only related items I see are the following: "Do not add or subtract an offset to a pointer such that the result points outside of the bounds of the garbage collected object originally allocated." and "Do not use byte-by-byte memory copies to copy pointer values. This may result in intermediate conditions where there is not a valid pointer, and if the gc pauses the thread in such a condition, it can corrupt memory." Maybe there was something about this in the NG before? Or maybe I interpreted the item above as ruling out the incrementing of pointers.Mike Parker wrote:Of course there's nothing wrong with /using/ pointers, but pointer arithmetic is one item in a list of 'Undefined Behavior' regarding pointers to GC memory. See the page http://www.digitalmars.com/d/garbage.html (section titled Pointers and the Garbage Collector). This isn't really an issue in the present since the current GC doesn't move anything around, AFAIK. But it's still a bad habit to get into (or a good one to get out of for people with C backgrounds) and doesn't do much for future-proofing.davidl wrote:That's news to me. There's nothing wrong with using pointers, it's just more verbose and error prone than foreach.First practice: char[] text; char* p; char* end;Pointer arithmetic in D is a no-no, unless you are using memory allocated outside of the GC.
Oct 12 2007
Mike Parker wrote:Bill Baxter wrote:I can't see anything about pointer arithmetic in that section. Did I miss it? As I read it, the basic rule is that pointers must stay as pointers at all times, and you can't subtract pointers that point to unrelated objects. Pointers that are pointing to different parts of the same block of memory (eg the same array) could be changed by the gc, but they'll all be moved in the same way, so everything should still be OK.Mike Parker wrote:Of course there's nothing wrong with /using/ pointers, but pointer arithmetic is one item in a list of 'Undefined Behavior' regarding pointers to GC memory. See the page http://www.digitalmars.com/d/garbage.html (section titled Pointers and the Garbage Collector).davidl wrote:That's news to me. There's nothing wrong with using pointers, it's just more verbose and error prone than foreach.First practice: char[] text; char* p; char* end;Pointer arithmetic in D is a no-no, unless you are using memory allocated outside of the GC.This isn't really an issue in the present since the current GC doesn't move anything around, AFAIK. But it's still a bad habit to get into (or a good one to get out of for people with C backgrounds) and doesn't do much for future-proofing.
Oct 12 2007
Bill Baxter wrote:Mike Parker wrote:I've seen several comments against it, but I don't know how authoritative they were. OTOH, you could easily be doing strange things to the garbage collector. Even if it's safe, I wouldn't expect it to be efficient (unless you turned off the garbage collector).davidl wrote:That's news to me. There's nothing wrong with using pointers, it's just more verbose and error prone than foreach.First practice: char[] text; char* p; char* end;Pointer arithmetic in D is a no-no, unless you are using memory allocated outside of the GC.To iterate over a D string, or any array, use foreach: foreach(c; text) { // do something with c }.... or use foreach(dchar c; text) if you care about handling non-ascii properly.
Oct 13 2007
Mike Parker escribió:davidl wrote:Problem is, the code davidl is trying to do is a port of DMD's front-end from C++ to D. It's a little counterintuitive: "Don't use pointer arithmetic in D, but it helped me a little to make DMD's front-end more readable and efficient." :-P This is just a guess, but I think davidl is looking for a way to iterate over the chars of an array, like in a lexer, as efficient and as nice (beauty of code) as possible.First practice: char[] text; char* p; char* end;Pointer arithmetic in D is a no-no
Oct 12 2007
Mike Parker wrote:Pointer arithmetic in D is a no-no, unless you are using memory allocated outside of the GC.What makes you say that? Playing with pointers is perfectly valid and safe in D, as long as you keep to the rules in http://www.digitalmars.com/d/garbage.html (and currently, in paractice, even quite a bit further)! Please, would everyone chip in and try to keep wrong assertions in the ng to a minimum, so as not to confuse (other) newcomers! Regards, Frank
Oct 12 2007
0ffh wrote:Mike Parker wrote:Yes, yes. I've already posted that I was mistaken about having read it in the spec. But I really was convinced I had seen something about this in that same page about the GC, the NG, or somewhere. I wasn't making it up or intentionally making a 'wrong assertion.'Pointer arithmetic in D is a no-no, unless you are using memory allocated outside of the GC.What makes you say that? Playing with pointers is perfectly valid and safe in D, as long as you keep to the rules in http://www.digitalmars.com/d/garbage.html (and currently, in paractice, even quite a bit further)! Please, would everyone chip in and try to keep wrong assertions in the ng to a minimum, so as not to confuse (other) newcomers! Regards, Frank
Oct 12 2007
Mike Parker wrote:Yes, yes. I've already posted that I was mistaken about having read itYes, I've seen it, but too late... I admit I should probably have read /all/ posts first befor answering any of them. But even when there are still a dozen unread, the reflex is still to answer them as you read them. Atually I have retracted a second posting I wrote after reading news://news.digitalmars.com:119/fen6co$tj8$1 digitalmars.com and before you finally wrote news://news.digitalmars.com:119/fen7fj$15vm$1 digitalmars.com . But at this point of time I felt it was too late to retract my first posting, so I decided to sit it out and write this reply if needed. :)I wasn't making it up or intentionally making a 'wrong assertion.'Sorry, I have not tried to imply you were making things up or intent- ionally making wrong assertions! I just wanted to remind us all to be on our guard and only assert things of which we think we really quite reliably know about - taken into account we all make mistakes. In my retracted post I wrote beside other things "Wow, we're even calling on the same piece of text to bolster our opposite opinions! Maybe the case is not quite as clear as I thought.". Regards, Frank
Oct 13 2007