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
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
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?
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
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
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
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
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
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
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
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
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:
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')
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.
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 -
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
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
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,
[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
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
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
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/
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
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
[]
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
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
--- 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
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/
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
29 matches
Mail list logo