Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt

2006-09-06 Thread Bram Kuijvenhoven
Michael Van Canneyt wrote: I don't consider storing a pointer in the tag is broken code, it was considered the accepted way to maintain a pointer to your custom data from a standard control and there is often no simple alternative. Accepted only because there was no other way. The only

[fpc-devel] patch - classes.xml

2006-09-06 Thread Graeme Geldenhuys
Hi, Attached is a small patch to fix a error in the TCollectionItem docs Regards, - Graeme - -- There's no place like 127.0.0.1 Index: classes.xml === --- classes.xml (revision 197) +++ classes.xml (working copy) @@ -2346,7

RE: [fpc-devel] RE: FloatToStrF problem

2006-09-06 Thread Danie Wessels
Thanks. That worked fine. Now I get in Lazarus in this code: {$IFDEF UNIX}{$IFDEF UseCThreads} // a break here with error: Ymproject.lpr(6,28) Fatal: Can't find unit Interfaces You need to rebuild the LCL for the new compiler. Do, Tools, Configure Build Lazarus and recompile the LCL.

Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt

2006-09-06 Thread Aleš Katona
The problem here is that if you introduce a changing type to Tag, you're going to break streaming of the components between various platforms. However I think simplest would be to simply make the tag something huge for years to come, like Int64. The idea with hidden union is nice tho. But you'll

Re: [fpc-devel] patch - types.pp (InflateRect)

2006-09-06 Thread Vincent Snijders
Graeme Geldenhuys schreef: Hi, I sent a patch for this before on the 25 July, but it hasn't been applied yet. I think the reason might have been due to that patch file containing a new Size() method as well which caused some problems. Anyway, this patch only contains the InflateRect()

Re: [fpc-devel] patch - types.pp (InflateRect)

2006-09-06 Thread Graeme Geldenhuys
Dope!!! :-) See attached... Regards, - Graeme - On 9/6/06, Vincent Snijders [EMAIL PROTECTED] wrote: Graeme Geldenhuys schreef: Hi, I sent a patch for this before on the 25 July, but it hasn't been applied yet. I think the reason might have been due to that patch file containing a

[fpc-devel] patch - types.pp (InflateRect)

2006-09-06 Thread Graeme Geldenhuys
Hi, I sent a patch for this before on the 25 July, but it hasn't been applied yet. I think the reason might have been due to that patch file containing a new Size() method as well which caused some problems. Anyway, this patch only contains the InflateRect() function. Regards, - Graeme -

Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt

2006-09-06 Thread Burkhard Carstens
Am Mittwoch, 6. September 2006 11:05 schrieb Michael Van Canneyt: On Wed, 6 Sep 2006, Ale Katona wrote: The problem here is that if you introduce a changing type to Tag, you're going to break streaming of the components between various platforms. However I think simplest would be to simply

[fpc-devel] Bit manipulation as optimization in FPC

2006-09-06 Thread ik
Hello, I wonder if FPC optimize a code such as: if a b then c := d else c := b; as : r := b + ((d - b) and -(a b)); If so, do you check the type of CPU (because as I understand, some CPU will not execute as fast as other CPU's. If not, then why, and how would you optimize such code ?

Re: [fpc-devel] Bit manipulation as optimization in FPC

2006-09-06 Thread Daniël Mantione
Op Wed, 6 Sep 2006, schreef ik: Hello, I wonder if FPC optimize a code such as: if a b then c := d else c := b; as : r := b + ((d - b) and -(a b)); If so, do you check the type of CPU (because as I understand, some CPU will not execute as fast as other CPU's. If not,

Re: [fpc-devel] Bit manipulation as optimization in FPC

2006-09-06 Thread Peter Vreman
Hello, I wonder if FPC optimize a code such as: if a b then c := d else c := b; as : r := b + ((d - b) and -(a b)); If so, do you check the type of CPU (because as I understand, some CPU will not execute as fast as other CPU's. If not, then why, and how would you optimize