Re: [fpc-pascal] ++ and -- ( and +=, -=, ...)

Am 31.07.2013 11:33, schrieb Sven Barth: Technically it would be simple to change that as the corresponding code is already available for the above mentioned situation, but it would definitely change the semantics if the left side is e.g. an array with a function as index accessor (as the funct

Re: [fpc-pascal] ++ and --

Am 30.07.2013 18:20, schrieb Mark Morgan Lloyd: Now specifically to your question - I believe that one of the reasons may be the fact that Pascal does not support unary arithmetic operators in postfix notation. The fact that C allows using them with both prefix and postfix notation makes them

Re: [fpc-pascal] Breaking Pascal source lines

Am 06.09.2013 15:10, schrieb Mark Morgan Lloyd: I'm sure there isn't a single "right" answer to this question, but if transferring Pascal source to a system that enforces short lines (e.g. 78 chars + CRLF) what's the best automatic breaking rule? One possibility is obviously to break after the

Re: [fpc-pascal] Breaking Pascal source lines

Am 06.09.2013 18:16, schrieb Bernd Oppolzer: To keep the syntax correct, you can break after every symbol, that is: not inside identifiers, not inside numbers (including floating point constants) not inside quoted strings but anywhere else I am using a Pascal pretty print program, that knows

Re: [fpc-pascal] DoDirSeparators and special filenames on Windows

On Windows, too: C:\>cd \backup\\\///\\\sich C:\backup\sich> Only the first backslash has to be (only one) backslash; no slash allowed. Kind regards Bernd Am 11.09.2013 19:36, schrieb Reimar Grabowski: On Wed, 11 Sep 2013 17:37:36 +0200 Jürgen Hestermann wrote: And double delimiters *a

Re: [fpc-pascal] struct definition in C

Am 23.03.2014 19:54, schrieb Jonas Maebe: On 23/03/14 19:39, Darius Blaszyk wrote: What would be the equivalent of the following struct definition in C? typedef struct MyStruct { unsigned a :6; unsigned b :15; unsigned c:11; }MyStruct; I imagine this is some sort of struct initializatio

Re: [fpc-pascal] with statement using mulltiple objects

Am 14.09.2014 15:39, schrieb Ched: Hello All, My two cents. The with statement is crystal clear for me. If newbies prefer to use different manners to code the things, that are free to do it. Using some kind of intermediate variable ? That's make to code difficult to understand, need do open

Re: [fpc-pascal] with statement using mulltiple objects

inspiration, at that time. Kind regards Bernd Am 14.09.2014 16:30, schrieb Bernd Oppolzer: The possible dangers of using WITH are only very limited, compared to other languages, for example PL/1, where - you don't need to declare variables, like in FORTRAN - you can omit structure qualifiers, i

Re: [fpc-pascal] For .. in .. loops with sets and valued enums

Maybe types should be forbidden at this place completely. Look at this: 1.) with subrg type - works ok !! program testin; type subrg = 1..10; var i: integer; begin for i in subrg do begin writeln (i) end end. 2.) with subrg type in in-expression - gives syntax error program tes

Re: [fpc-pascal] C translation question

it might help if I translate the C for loop into an equivalent while loop for you, (and eliminating the ++ construct), simply mechanically, without knowing anything about the application. This results in: int pnpoly (int nvert, float *vertx, float *verty, float testx, float testy) { int i, j,

Re: [fpc-pascal] C translation question

while loop first, then you can translate this loop in a straightforward manner to Pascal, and the probability of inserting logic errors is much lower. Kind regards Bernd Am 23.10.2016 um 22:20 schrieb Bernd Oppolzer: it might help if I translate the C for loop into an equivalent while loop for

Re: [fpc-pascal] C# translatation

Am 08.01.2017 um 11:46 schrieb Sven Barth: On 08.01.2017 10:55, Ryan Joseph wrote: I’m going to attempt to translate a perlin noise function (from https://gist.github.com/Flafla2/f0260a861be0ebdeef76) but there are a few things that stopped me from starting. 1) What is & doing in this assignm

Re: [fpc-pascal] C# translatation

Am 08.01.2017 um 18:22 schrieb Sven Barth: Am 08.01.2017 17:32 schrieb "Bernd Oppolzer" mailto:bernd.oppol...@t-online.de>>: > > Am 08.01.2017 um 11:46 schrieb Sven Barth: >> >> On 08.01.2017 10:55, Ryan Joseph wrote: >>> >>> I’m going t

Re: [fpc-pascal] bitwise operations using AND, OR, XOR, NOT

Am 08.01.2017 um 23:04 schrieb Sven Barth: This depends on the Pascal compiler you use; the old Wirth "Standard" yields syntax errors, if you use and etc. on types other than boolean: We're here on the FPC mailing list, so I personally only care about the capabilities of FPC and that defini

Re: [fpc-pascal] named parameter

IMO, it's not about named parameters; furthermore, it is not about readability, but this IMO is a maintenance issue. Think about a procedure that has two parameters and a lot of callers and you want to add a third one. it would be nice if you could specify a default value for the new third param

Re: [fpc-pascal] Food for thought - language string improvement

Am 06.07.2017 um 18:32 schrieb Andreas: For this reason I would be against this implementation. Maybe taking away the need for the + sign at the end of the line. The strings are concatenated until a semi-colon or other symbol is encountered This is what the (new) Stanford Pascal compiler do

Re: [fpc-pascal] Freepascal Floating Point Issue

Am 24.08.2017 um 15:02 schrieb el es: On 24/08/17 13:26, Sven Barth via fpc-pascal wrote: [...] Note: FPC (and Delphi) has a single fixed point type which is Currency. AFAIK it uses four digits after the comma and 28 in front of it. Regards, Sven There was a project I remember, that I was to

Re: [fpc-pascal] Freepascal Floating Point Issue

Am 24.08.2017 um 14:00 schrieb James Richters: Thanks everyone for the explanation and solutions.  I can work around it well enough now that I understand what’s happening, but I’m still curious if there is a way to define fixed point variables?  In a C++ Project I was helping with recently, t

Re: [fpc-pascal] Scoped enums and inferred types

Am 21.02.2018 um 16:29 schrieb Ryan Joseph: On Feb 21, 2018, at 10:13 PM, Michael Van Canneyt wrote: You lose an important type safety if you replace them with constants. I like enums also but you can imagine when they were proposed the compiler teams probably compared them to constants an

[fpc-pascal] procedure and function parameters?

Are procedure and function parameters allowed in Free Pascal? When I tried to compile the Man-or-boy example program (Knuth's test), FPC complained with a syntax error: c:\work\pascal\work>fpc manorboy.pas Free Pascal Compiler version 3.0.0 [2015/11/16] for i386 Copyright (c) 1993-2015 by Flori

Re: [fpc-pascal] procedure and function parameters?

Am 04.03.2018 um 18:45 schrieb Sven Barth via fpc-pascal: On 04.03.2018 18:06, Bernd Oppolzer wrote: Are procedure and function parameters allowed in Free Pascal? When I tried to compile the Man-or-boy example program (Knuth's test), FPC complained with a syntax error: c:\work\pascal

Re: [fpc-pascal] pointerful

program TESTPT ( OUTPUT ) ; // //$A+ ... enable Assembler output // type PT = -> PT ; var PTEST : PT ; function LQUEUE ( P : PT ) : INTEGER ;    var L : INTEGER ;    begin (* LQUEUE *) L := 0

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

Am 02.06.2018 um 15:14 schrieb Sven Barth via fpc-pascal: Mark Morgan Lloyd > schrieb am Sa., 2. Juni 2018, 10:53: However as Dennis points out + is also essential for vector operations. Perhaps either leaving it to the programmer to defi

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

Am 03.06.2018 um 18:12 schrieb Sven Barth via fpc-pascal: Bernd Oppolzer <mailto:bernd.oppol...@t-online.de>> schrieb am So., 3. Juni 2018, 11:56: Am 02.06.2018 um 15:14 schrieb Sven Barth via fpc-pascal: Mark Morgan Lloyd mailto:markmll.fpc-pas...@telemetry.co.uk>>

Re: [fpc-pascal] round(2.5)=2

Am 08.06.2018 um 14:47 schrieb Klaus Hartnegg: Hi, The round function behaves different than in TurboPascal, and its English Wiki page differs from the German page. When given an argument halfway between to integers, FreePascal rounds to the nearest even number, TurboPascal always rounds up

Re: [fpc-pascal] Order of Precedence: FPC/Delphi vs Java

The explanation for the results is as follows: the first three codings do the multiplication first, then the division. the last two first division, then multiplication. That makes the difference. When division is done first, you get an intermediate result of 1.0 exactly. The subsequent multipl

Re: [fpc-pascal] Order of Precedence: FPC/Delphi vs Java

Some corrections, see below ... Am 03.10.2018 um 11:54 schrieb Bernd Oppolzer: The explanation for the results is as follows: the first three codings do the multiplication first, then the division. the last two first division, then multiplication. That makes the difference. When division

Re: [fpc-pascal] Order of Precedence: FPC/Delphi vs Java

Am 07.10.2018 um 00:46 schrieb Graeme Geldenhuys: On 06/10/18 20:15, Santiago A. wrote: places, so can't use Currency data type. 6 decimals, no currency that's a problem ;-) Yeah, tell me about it. you must specify : "Discount will be applied to each item". 64bits is a lot of precision, but

Re: [fpc-pascal] Can FPC optimize: if (s[i]='a') or ...

Am 13.04.2019 um 21:55 schrieb Ralf Quint: On 4/13/2019 12:30 PM, Alexey Tor. wrote: E.g. i have a loop which test each s[i] char for several cases: 'a', 'b', 'c'. for i:= 1 to length(s) do if (s[i]='a') or (s[i]='b') or (s[i]='c') then ... Can FPC optimize it so it only reads s[i] once (to

Re: [fpc-pascal] Can FPC optimize: if (s[i]='a') or ...

Am 15.04.2019 um 03:35 schrieb wkitt...@windstream.net: On 4/14/19 7:28 AM, Rainer Stratmann wrote: On Samstag, 13. April 2019 22:30:55 CEST Alexey Tor. wrote: E.g. i have a loop which test each s[i] char for several cases: 'a', 'b', 'c'. for i:= 1 to length(s) do if (s[i]='a') or (s[i]='b')

Re: [fpc-pascal] Can FPC optimize: if (s[i]='a') or ...

Am 15.04.2019 um 08:29 schrieb Tomas Hajny: On Mon, April 15, 2019 07:52, Bernd Oppolzer wrote: . . On Samstag, 13. April 2019 22:30:55 CEST Alexey Tor. wrote: . . Can FPC optimize it so it only reads s[i] once (to register), not 3 times? . . True for New Stanford Pascal

Re: [fpc-pascal] XML - Indent, text content, special char

Am 30.04.2019 um 02:45 schrieb wkitt...@windstream.net: On 4/29/19 1:27 PM, Gabor Boros wrote: Is this not a bug? Lost of formatting is not disturb me but text between > and < is the data/text content of a node. are you saying that you are trying to use fixed-width fields that are space-padd

Re: [fpc-pascal] Turbo Pascal 3 graphics

This may be off-topic, but anyway: I did some graphics programming in the 1990s (for customers of mine), but with not so much interest on display terminals, but instead on large plotters (DIN A0 format, for example). I used a library called GKS at that time (graphics kernel system), which was de

[fpc-pascal] Implementation of variant records

This question is not directly related to FPC, but it is instead a Pascal question in general. Take this record definition: type S1 = record     X : CHAR ( 27 ) ;     case INTEGER of   1 :     ( V : INTEGER ) ;   2 :     ( W : REAL

Re: [fpc-pascal] += property bug?

Am 14.08.2019 um 17:41 schrieb wkitt...@windstream.net: On 8/14/19 10:54 AM, Ryan Joseph wrote: Seriously? why is i := i + 1 better than i += 1 ? just more typing for such a simple operation. All languages I use have adopted this syntax and for good reason. good reason?? because someone is t

Re: [fpc-pascal] Illegal counter variable?

Am 09.09.2019 um 16:11 schrieb James Richters: I just don't see why having the limitation, there is no technical reason that the for loop couldn't change that I can see.. especially since it works in TP mode. The original reason why some Pascal implementations had this limitation: for perfo

Re: [fpc-pascal] basic question on begin, end;

Am 25.09.2020 um 22:16 schrieb James Richters via fpc-pascal: I think that’s a GREAT quote from Niklaus Wirth, and I agree with that whole heartedly… programs should be readable by humans… otherwise do all your programming in assembly language… the whole POINT of a hi level language is to ma

Re: [fpc-pascal] Graphing library

Hi, I don't know if this can help you, but in the 1980s I worked with a library called GKS (graphic kernel system) which I used to build such graphics like the following example: http://bernd-oppolzer.de/fdynsb.pdf This programs that did this were written in Pascal at that time. It still work

Re: [fpc-pascal] Converting old pascal written for Pascal/MT+ compiler

Am 04.04.2023 um 08:16 schrieb Jacob Kroon via fpc-pascal: Thanks for the tip above. I was able to write a couple of perl-scripts that are able to convert my old Pascal sources to something that fpc can parse. Amongst other things, the scripts inject the "public name"/"external name" annotat

Re: [fpc-pascal] Legitimate use of for and break

Am 18.06.2023 um 03:04 schrieb Hairy Pixels via fpc-pascal: On Jun 18, 2023, at 1:07 AM, tsie...@softcon.com wrote: This is interesting, because it's the first time I've ever seen "break" as a valid command in pascal, and I've been using pascal since the mid/late 80s. All kinds of dialects

Re: [fpc-pascal] Pointer question

FWIW, when I added similar functionality to my Stanford Pascal compiler, I chose not to allow arithmetic of pointers, but instead I added some functions: PTRADD (p, i) - p is type ANYPTR, i is integer, result is of type ANYPTR PTRDIFF (p1, p2) - two pointers, the result is integer ANYPTR is a pr

Re: [fpc-pascal] Does the compiler make prodigious use of use ENTER instruction?

Am 12.12.2023 um 17:51 schrieb Marco van de Voort via fpc-pascal: Op 12-12-2023 om 17:48 schreef Anthony Walter via fpc-pascal: Do any of the compiler devs know if Pascal programs for the x86 instruction set are using ENTER and its second argument to the best possible effect? I am curious.

Re: [fpc-pascal] Does the compiler make prodigious use of use ENTER instruction?

I wrote a comment on the original Microsoft dev blog (for a non-Pascal community), maybe it's of interest here, too ... In normal Pascal procedure calls, such a vector of stack frame addresses is not needed. A standard Pascal runtime knows all the time about the current stack frame address of

Re: [fpc-pascal] case statement

Am 17.12.2023 um 06:12 schrieb Adriaan van Os via fpc-pascal: Anyway, the innocent looking case-statement does have some interesting aspects. Indeed. My Stanford compiler tries to be portable across platforms; due to its IBM mainframe heritage even on platforms that have "strange" charact

Re: [fpc-pascal] case statement

Am 17.12.2023 um 16:36 schrieb Adriaan van Os via fpc-pascal: As the otherwise-clause is not in ISO-7185 Pascal, it seems more plausible that Borland invented the else-clause (without semicolon) independently. All other Pascals I have looked at, use an otherwise-clause (with an obligatory sem

Re: [fpc-pascal] Floating point question

To simplify the problem further: the addition of 12 /24.0 and the subtraction of 0.5 should be removed, IMO, because both can be done with floats without loss of precision (0.5 can be represented exactly in float). So the problem can be reproduced IMO with this small Pascal program: program T

Re: [fpc-pascal] Floating point question

I didn't follow all the discussions on this topic and all the details of compiler options of FPC and Delphi compatibility and so on, but I'd like to comment on this result: program TESTDBL1 ; Const HH = 8427.02291667; Var AA : Integer; BB : Byte; CC : Single;

Re: [fpc-pascal] Floating point question

g the maximum precision, no matter if it is done at compile time or at run time ... and this would IMHO be the solution which is the easiest to document and maybe to implement and which would satisfy the users. Kind regards Bernd Oppolzer ___ fpc-p

Re: [fpc-pascal] Floating point question

aebe via fpc-pascal To: fpc-pascal@lists.freepascal.org Sent: Sunday, February 11, 2024, 23:29:42 Subject: [fpc-pascal] Floating point question On 11/02/2024 23:21, Bernd Oppolzer via fpc-pascal wrote: and this would IMHO be the solution which is the easiest to document and maybe to implement and

Re: [fpc-pascal] Floating point question

Am 13.02.2024 um 10:54 schrieb Michael Van Canneyt via fpc-pascal: On Tue, 13 Feb 2024, James Richters via fpc-pascal wrote: Sorry for the kind of duplicate post, I submitted it yesterday morning and I thought it failed, so I re-did it and tried again.. then after that the original one showe

Re: [fpc-pascal] Floating point question

My opinions about the solutions below ... Am 13.02.2024 um 12:07 schrieb Thomas Kurz via fpc-pascal: But, sorry, because we are talking about compile time math, performance (nanoseconds) in this case doesn't count, IMO. That's what i thought at first, too. But then I started thinking about

Re: [fpc-pascal] Floating point question

Am 16.02.2024 um 08:32 schrieb Florian Klämpfl via fpc-pascal: Am 16.02.2024 um 08:23 schrieb Ern Aldo via fpc-pascal :  Compile-time math needs to be as correct as possible. RUN-time math can worry about performance. So you are saying when constant propagation is on, an expression should hav

Re: [fpc-pascal] Floating point question

Am 16.02.2024 um 15:57 schrieb James Richters via fpc-pascal: So you are saying when constant propagation is on, an expression should have a different result than with constant propagation off? The result of math when using constants MUST be the same as the result of identical math using var

Re: [fpc-pascal] Floating point question

Am 17.02.2024 um 02:12 schrieb Ern Aldo via fpc-pascal: It is possible math is being done differently by the compiler than by programs? For math-related source code, the compiler compiles the instructions and writes them to the program file for execution at runtime. For compile-time constant

Re: [fpc-pascal] Floating point question

Am 17.02.2024 um 14:38 schrieb Michael Van Canneyt via fpc-pascal: There can be discussion about the rules that the compiler uses when it chooses a type, but any given set of rules will always have consequences that may or may not be desirable. Possibly some compiler switches can be invented

Re: [fpc-pascal] Floating point question

Am 17.02.2024 um 16:38 schrieb Bernd Oppolzer: IMO, a compiler switch that gives all FP constants the best available precision would solve the problem - BTW: WITHOUT forcing expressions where they appear to use this precision, if the other parts of the expression have lower precision. In

Re: [fpc-pascal] Floating point question

Am 17.02.2024 um 20:18 schrieb Florian Klämpfl via fpc-pascal: const Xconst : single = 1440.0; var y1, y2 : real; y1 := 33.0 / 1440.0; y2 :=  33.0 / Xconst; the division in the first assignment (to y1) should be done at maximum precision, that is, both constants should be converted by the

Re: [fpc-pascal] Floating point question

See below ... Am 19.02.2024 um 02:00 schrieb James Richters via fpc-pascal: >And if you have set the precision, then the calculation will be identical to the calculation when you use a variable of the same type (if not, it's indeed a bug). This is what I have been trying to point out.Math