CG> Be warned, I've lost all the previous of this in a HD crash :(
 CG> so please pardon any confusions...

  Jeeze! I thought I was the only one who did that sort of thing.

 BL> function StrInt(p: Pchar): integer;

  You have to allocate memory for the pointer first, somewhere else,
or it will just increment on the end of what you were doing last.

 CG> I meant you could do it thus:

 CG> func (VAR str:string)

  Oh. That's actually similar to using the pointer like I did... you
use the already-existing memory in the string variable without having
to write a new lot every time you call the function. 

 CG> your above code quote confuses my limited memory, sorry

  It never occurred to me that someone else had as much trouble using 
pointers as I do. The trick is to *always* make sure that the pointer 
is pointing at something you know about. p^ looks pretty harmless, but 
pointers do not like being dereferenced if they're not pointing at 
anything. They just go ahead and do it anyway.

 CG> I forget how set's are stored, but a lookup table would be an
 CG> array of all your values for Ord ('0'..'9') - 48,
 CG> precalculated. worth checking out which combinations are faster

  Oh! I see what you mean. Yes. I'll try that... 

 CG> So how do you get u/sec timings anyway, what about the timer's
 CG> overhead ? 

  I just do it 100,000 times in a loop and time the whole thing. It's
not really accurate, but it can make comparisons. 

 BL> I stripped it down to make any changes more obvious.

 CG> DON'T DO THAT !!!!

  Chicken.

Regards,
Bob
___ Blue Wave/QWK v2.12
@EOT:

---