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 e
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 Colla:
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 the
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 := Negat
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 li
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 de
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.
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 behaviou
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
2010/1/31 Paul van Helden :
> 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 overloaded function
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 imp
2010/1/31 Paul van Helden :
> 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: Result:=GetValue_not_overloaded;
> else
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 p
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 - fpc-devel@l
El Domingo, 2 de Enero de 2005 17:01, Jose Manuel escribiste:
> > IIRC, any non-zero value is evaluated as "True" for a Boolean
> > variable. The
>
> No, and no. There your assuming some implementation of the type Boolean.
> I Peter stated, bitwise logic and Boolean logic are neatly separated in
>
> 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
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')
el
[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... whate
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 co
Nico Aragón wrote:
> ¡Serás melón!
Could you please help me to improve my rudimentary Spanish? ;-)
(Eierkopf? ;-)
> ¡Feliz año, torpedo! :-)
(Blindgänger? ;-)
Feliz año, Bonne Année, Happy New Year, Gelukkige Nieuwe Jaar, und ein
Gutes Neues Jahr allerseits!
DoDi
_
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
> 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
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
[]
> > 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 (
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 respondiend
>
> > > 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
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/
__
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 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 didn't start this t
Nico Aragón wrote:
type boolean = (false,true);
is how boolean is defined/declared
so assigning anything else than true or false to a boolean might cause
problems :)
else
WriteLn('Other');
This better should read:
WriteLn('corrupt data space!!!'); Panic;
Much more useful :->
___
El Viernes, 31 de Diciembre de 2004 13:13, DrDiettrich escribiste:
> 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?
> > else
> > WriteLn('Other');
>
> This better should read:
>
peter green wrote:
>
> I think the old saying goes garbage in garbage out.
100%
> range checking should probablly catch this sort of stuff but that has a high
> performance penalty and is therefore usually disabled.
IIRC range checking occurs on assignments, not on using the values, just
to red
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
.
> -Original 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
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')
el
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/
___
--- 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);
be
you are forciblly putting an out of range value in a variable what do you
expect to happen?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Jesus Reyes
> Sent: 30 December 2004 19:37
> To: lista de fpc-devel
> Subject: [fpc-d
Never mind, I friend of mine confirmed that delphi does the same
output.
regards.
--- Jesus Reyes <[EMAIL PROTECTED]> escribió:
> update: the following program output:
> TRUE
> OTHER
>
> program problem;
> var
> B: boolean;
> begin
>
> FillChar(B, SizeOf(B), 255);
> if
update: the following program output:
TRUE
OTHER
program problem;
var
B: boolean;
begin
FillChar(B, SizeOf(B), 255);
if b then WriteLn(TRUE)
else WriteLn(FALSE);
case b of
true: WriteLn(True);
false: WriteLn(False);
I have doubts about this so I made a small test, what I want to know
is if a true boolean value be internally be represented by any value
different from 0.
program problem;
var
B: boolean;
begin
FillChar(B, SizeOf(B), 255);
case b of
true: WriteLn(True);
false: WriteLn(False);
el
43 matches
Mail list logo
