www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Reality drives me to write less clean code, sorry for mistakenly posting in D.announce

reply davidl <davidl 126.com> writes:
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
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
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
prev sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
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
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Mike Parker wrote:
 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.

That's news to me. There's nothing wrong with using pointers, it's just more verbose and error prone than foreach.
 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
next sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Bill Baxter wrote:
 Mike Parker wrote:
 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.

That's news to me. There's nothing wrong with using pointers, it's just more verbose and error prone than foreach.

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.
Oct 12 2007
next sibling parent Mike Parker <aldacron71 yahoo.com> writes:
Mike Parker wrote:
 Bill Baxter wrote:
 Mike Parker wrote:
 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.

That's news to me. There's nothing wrong with using pointers, it's just more verbose and error prone than foreach.

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.

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.
Oct 12 2007
prev sibling parent Don Clugston <dac nospam.com.au> writes:
Mike Parker wrote:
 Bill Baxter wrote:
 Mike Parker wrote:
 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.

That's news to me. There's nothing wrong with using pointers, it's just more verbose and error prone than foreach.

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

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.
 
 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
prev sibling parent Charles D Hixson <charleshixsn earthlink.net> writes:
Bill Baxter wrote:
 Mike Parker wrote:
 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.

That's news to me. There's nothing wrong with using pointers, it's just more verbose and error prone than foreach.
 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.

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).
Oct 13 2007
prev sibling next sibling parent Ary Manzana <ary esperanto.org.ar> writes:
Mike Parker escribió:
 davidl wrote:
 First practice:

 char[] text;
 char* p;
 char* end;

Pointer arithmetic in D is a no-no

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.
Oct 12 2007
prev sibling parent reply 0ffh <spam frankhirsch.net> writes:
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
parent reply Mike Parker <aldacron71 yahoo.com> writes:
0ffh wrote:
 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

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.'
Oct 12 2007
parent 0ffh <spam frankhirsch.net> writes:
Mike Parker wrote:
 Yes, yes. I've already posted that I was mistaken about having read it 

Yes, 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