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

2006-09-06 Thread Daniël Mantione
Op Thu, 7 Sep 2006, schreef Jonas Maebe: > > On 7 sep 2006, at 07:52, Peter Vreman wrote: > > > This is not a generic optimization that will give real benefits. Your > > code > > also relies on the fact that (a > garantueed. A boolean is defined as 0=false and everything else is true. > > Afa

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

2006-09-06 Thread Jonas Maebe
On 7 sep 2006, at 07:52, Peter Vreman wrote: This is not a generic optimization that will give real benefits. Your code also relies on the fact that (ais not garantueed. A boolean is defined as 0=false and everything else is true. Afaik only in case of reading a boolean everything <> 0 is

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 wou

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

2006-09-06 Thread Florian Klaempfl
Daniël Mantione schrieb: 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.

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

[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] 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 s

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

2006-09-06 Thread Micha Nelissen
Michael Van Canneyt wrote: > If you want to store objects, use a TCollection, and store > TCollectionItem.ID in the component tag. ID is a unique identifier, even > when elements are added and removed from the collection. > > Slightly more work, but clean and portable. And much slower. Micha ___

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 containi

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() function

[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 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 make the tag something huge for years to come, like Int64. The idea

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 n

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

[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 +234