Re: [fpc-devel] Compiler bug in macro handling?

2017-04-12 Thread Bernd Oppolzer
No, if you put a semicolon in there, you will get wrong syntax, no matter what the datatype is. Example: {$MACRO ON} {$define Fifteen:=15;} {$define Twelve:=12;} ... if HDCOUNT0 >= COUNT0 then X := Fifteen else X := Twelve; will generate this Pascal statement: if HDCOUNT0

Re: [fpc-devel] Compiler bug in macro handling?

2017-04-12 Thread Giuliano Colla
Il 12/04/2017 19:54, Bernd Oppolzer ha scritto: I'm no FPC macro language wizard, but in my believe you are replacing Positiva with False, followed by a semicolon, and so you get the error from the compiler. {$define Positiva:=False} should probably work. You are right, I was misled by some

Re: [fpc-devel] Compiler bug in macro handling?

2017-04-12 Thread Giuliano Colla
Il 12/04/2017 19:51, Michael Van Canneyt ha scritto: Try removing the semicolon: {$define Positiva:=False} {$define Negativa:=True} Without semicolon it works! Thanks a lot. BTW, do you think that this holds true only for the define of boolean values?

Re: [fpc-devel] Compiler bug in macro handling?

2017-04-12 Thread Bernd Oppolzer
Hi Guiliano, I'm no FPC macro language wizard, but in my believe you are replacing Positiva with False, followed by a semicolon, and so you get the error from the compiler. {$define Positiva:=False} should probably work. HTH, kind regards Bernd Am 12.04.2017 um 19:39 schrieb Giuliano

Re: [fpc-devel] Compiler bug in macro handling?

2017-04-12 Thread Michael Van Canneyt
On Wed, 12 Apr 2017, Giuliano Colla wrote: Hi honourable fpc developers! I found a strange error (both with fpc 2.6.4 and fpc 3.0.0, in Linux environment) The following snippet of code: {$MACRO ON} {$define Positiva:=False;} {$define Negativa:=True;} ... if HDCOUNT0 >= COUNT0

[fpc-devel] Compiler bug in macro handling?

2017-04-12 Thread Giuliano Colla
Hi honourable fpc developers! I found a strange error (both with fpc 2.6.4 and fpc 3.0.0, in Linux environment) The following snippet of code: {$MACRO ON} {$define Positiva:=False;} {$define Negativa:=True;} ... if HDCOUNT0 >= COUNT0 then V_PIU0 := Positiva else V_PIU0 :=

[fpc-devel] compiler bug with structs within nested classes

2011-06-10 Thread Andrew Brunner
I heavily use nested classes in general and I've come across a problem where I cannot make explicit references data structures from another unit while embedded within classes. //Developer/Source/Builds/SCS/Linux/64/Output/uRTSPd.o:(.data+0x52f): undefined reference to `RTTI_DBMRTSP_DEF112' The

Re: [fpc-devel] Compiler bug?

2010-01-31 Thread Paul van Helden
Of course Thanks Cobines! I have never used the function name instead of Result, but of course you can. Using () after a function to me seems so C-like and un-Pascallish but it works. But it is things like this that trip up people coming from Delphi, I guess. Isn't this a potential

Re: [fpc-devel] Compiler bug?

2010-01-31 Thread cobines
2010/1/31 Paul van Helden p...@planetgis.co.za: But it is things like this that trip up people coming from Delphi, I guess. Isn't this a potential improvement to the compiler though: scan for overloaded functions before assuming that it is the result value (like Delphi does)? (Or warn about

Re: [fpc-devel] Compiler bug?

2010-01-31 Thread Daniël Mantione
Op Sun, 31 Jan 2010, schreef Paul van Helden: Of course Thanks Cobines! I have never used the function name instead of Result, but of course you can. Using () after a function to me seems so C-like and un-Pascallish but it works. But it is things like this that trip up people coming

Re: [fpc-devel] Compiler bug?

2010-01-31 Thread Paul van Helden
On 2010/01/31 10:30 AM, Daniël Mantione wrote: This behaviour is intentional to allow you to read instead of just write the function result. The incompatibility just affects recursive procedures without parameters, which seldomly occurs, because normally the parameters determine the

Re: [fpc-devel] Compiler bug?

2010-01-31 Thread Marco van de Voort
In our previous episode, Paul van Helden said: I have never used the function name instead of Result, but of course you can. Using () after a function to me seems so C-like and un-Pascallish but it works. But it is things like this that trip up people coming from Delphi, I guess. Isn't

Re: [fpc-devel] Compiler bug?

2010-01-31 Thread Graeme Geldenhuys
Paul van Helden wrote: And to regain my productivity: to figure out how to debug with Lazarus the way I'm used to in Delphi... I miss this too, though recently there was a lot of improvements to debugging support. All I can say is, be thankful you didn't start 5 years ago with FPC where

[fpc-devel] Compiler bug?

2010-01-30 Thread Paul van Helden
Hi All, I hope I'm doing something really dumb, but I have to say it is stuff like this that is really disheartening to me. I've been using FPC/Lazarus for a year now and I have to report that my rate of development (compared to Delphi) has slowed down significantly... The following simple

Re: [fpc-devel] Compiler bug?

2010-01-30 Thread cobines
2010/1/31 Paul van Helden p...@planetgis.co.za: function TMyClass.GetValue_overloaded(SomeValue: Integer): Integer; begin  case SomeValue of    1: Result:=GetValue_overloaded; // compiler warning: Function result variable does not seem to be initialized (!)    2:

Re: [fpc-devel] compiler bug?

2005-01-02 Thread Nico Aragón
El Jueves, 30 de Diciembre de 2004 22:01, peter green escribiste: you are forciblly putting an out of range value in a variable what do you expect to happen? I think it's slightly subtler. I guess that this code: if not b then WriteLn('False') else if b then WriteLn('True')

RE: [fpc-devel] compiler bug?

2005-01-02 Thread Jose Manuel
I think it's slightly subtler. I guess that this code: if not b then WriteLn('False') else if b then WriteLn('True') else WriteLn('Other'); ...could throw a different result. IIRC, any non-zero value is evaluated as True for a Boolean variable. The No, and no.

Re: [fpc-devel] compiler bug?

2005-01-02 Thread Michael Van Canneyt
No offence meant but, Can this thread (see subject) please be stopped ? It is no longer interesting for the rest of us, and threatens to lead to a flame war. I'm sure no-one is interested in that either. Michael. ___ fpc-devel maillist -

RE: [fpc-devel] compiler bug?

2005-01-01 Thread Jose Manuel
3: the PASCAL way boolean is a totally seperate type from integer types so the compiler knows whether you mean logial or bitwise operations. I don't know if false That's the point. :-) and true having ordinal values of 0 and 1 is part of a standard or a borlandism but im pretty sure its

Re: [fpc-devel] compiler bug?

2005-01-01 Thread Nico Aragón
El Sábado, 1 de Enero de 2005 09:06, Jose Manuel escribiste: So i think. I think Ord(TRUE), Succ(FALSE), etc. are valid Standard and Extended Pascal expressions, as well as the behaviour of a declarion of As far as I know: Ord(True) Ord(False) = True Succ(False) = True ...are not only

Re: [fpc-devel] compiler bug?

2005-01-01 Thread DrDiettrich
Nico Aragón wrote: IIRC, any non-zero value is evaluated as True for a Boolean variable. You should not guess about any implementation. I don't. Do I? Yes, you do. How can you know what bit pattern is stored in a boolean variable? Using typecasts may result in silent type conversion,

Re: [fpc-devel] compiler bug?

2005-01-01 Thread Nico Aragón
[merged responses to two messages] El Sábado, 1 de Enero de 2005 06:54, DrDiettrich escribiste: ¡Serás melón! Could you please help me to improve my rudimentary Spanish? ;-) http://hotel.jp-guide.net/job/point/melon.jpg (Eierkopf? ;-) My rudimentary... I meant my non-existent... whatever

Re: [fpc-devel] compiler bug?

2004-12-31 Thread DrDiettrich
Nico Aragón wrote: IIRC, any non-zero value is evaluated as True for a Boolean variable. You should not guess about any implementation. Forcing out-of-range values into strictly typed variables is a user bug, at the full risk of (and shame on) that user. Who's to blame when somebody applies

Re: [fpc-devel] compiler bug?

2004-12-31 Thread Florian Klaempfl
Nico Aragón wrote: El Viernes, 31 de Diciembre de 2004 14:58, Florian Klaempfl escribiste: type boolean = (false,true); is how boolean is defined/declared so assigning anything else than true or false to a boolean might cause problems :) That's great! But why do you tell it *to me*? I only cross

Re: [fpc-devel] compiler bug?

2004-12-31 Thread Nico Aragón
El Viernes, 31 de Diciembre de 2004 17:18, Florian Klaempfl escribiste: That's great! But why do you tell it *to me*? I only cross read the thread and wanted to clarify things :) Oh, I see. Happy new year! :-) -- saludos, Nico Aragón http://espira.net/nico/

RE: [fpc-devel] compiler bug?

2004-12-31 Thread Jose Manuel
else WriteLn('Other'); This better should read: WriteLn('corrupt data space!!!'); Panic; Much more useful :- (AFAIK) you do. You're programing, the C way. You can't expect that -1 equals True, and any other value equals false, (I really dunno, but I think I could

Re: [fpc-devel] compiler bug?

2004-12-31 Thread Nico Aragón
El Viernes, 31 de Diciembre de 2004 18:40, Jose Manuel escribiste: else WriteLn('Other'); This better should read: WriteLn('corrupt data space!!!'); Panic; Much more useful :- (AFAIK) you do. ¡Serás melón! ¿A qué se supone que estás respondiendo ahí? X'D You're

RE: [fpc-devel] compiler bug?

2004-12-31 Thread Jose Manuel
[] You're programing, the C way. [] You can't expect that -1 equals True, and any other value equals false, (I You can expect whatever it's documented equals true and sometimes you must That's right. I can expect whatever is documented. In C there's no boolean type. In Pascal (as in

RE: [fpc-devel] compiler bug?

2004-12-31 Thread peter green
Different languages approach boolean operations in different ways. 1: the C way false=0 true=anything else seperate logical and bitwise operators. 2: the BASIC way (also used by the access database) false=0 true=-1 logical and bitwise operations therefore equivilent (though it should be noted

RE: [fpc-devel] compiler bug?

2004-12-30 Thread Jesus Reyes
--- peter green [EMAIL PROTECTED] escribió: you are forciblly putting an out of range value in a variable what do you expect to happen? Of course the program was made to do that evident, but what happen when you find a procedure, for example: procedure doAorB(value: boolean); begin

Re: [fpc-devel] compiler bug?

2004-12-30 Thread Nico Aragón
El Jueves, 30 de Diciembre de 2004 22:48, Jesus Reyes escribiste: procedure doAorB(value: boolean); begin case value of true: doA; false: doB; end; end; if Value then DoA else BoB; -- saludos, Nico Aragón http://espira.net/nico/

RE: [fpc-devel] compiler bug?

2004-12-30 Thread peter green
Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jesus Reyes Sent: 30 December 2004 21:49 To: FPC developers' list Subject: RE: [fpc-devel] compiler bug? --- peter green [EMAIL PROTECTED] escribió: you are forciblly putting an out of range value in a variable what