Re: [fpc-devel] "Blank slate" next version of FPC

Am 22.02.2019 um 07:06 schrieb Paul van Helden: On Fri, Feb 22, 2019 at 2:35 AM Ben Grasset > wrote: On Sat, Feb 16, 2019 at 5:44 PM Benito van der Zander mailto:ben...@benibela.de>> wrote it can turn out the enumerators are slower than an old schoo

Re: [fpc-devel] "Blank slate" next version of FPC

On Fri, Feb 22, 2019 at 2:35 AM Ben Grasset wrote: > > On Sat, Feb 16, 2019 at 5:44 PM Benito van der Zander > wrote > >> it can turn out the enumerators are slower than an old school loop >> > > The trick with enumerators is to never make them classes, and use advanced > records instead, I've f

Re: [fpc-devel] "Blank slate" next version of FPC

On Sat, Feb 16, 2019 at 5:44 PM Benito van der Zander wrote > it can turn out the enumerators are slower than an old school loop > The trick with enumerators is to never make them classes, and use advanced records instead, I've found. This way you avoid the heap allocation and the implicit try/f

Re: [fpc-devel] "Blank slate" next version of FPC

On Sun, Feb 17, 2019 at 3:15 AM Florian Klämpfl wrote: > This is a property of production compiler code. > I'm not sure about that. I don't think FPC's codebase is (for the most part) a mess, although the style is a little bit inconsistent sometimes. _

Re: [fpc-devel] "Blank slate" next version of FPC

Am 21.02.19 um 06:19 schrieb Ondrej Pokorny: Am 20.02.19 um 21:33 schrieb Florian Klämpfl > Am 20.02.19 um 08:36 schrieb Paul van Helden: > As a big >/fan of the Pascal language, I'd rather break compatibility and see the /> >/language evolve than the stoic attitude of the core devs as seen on

Re: [fpc-devel] fpc-devel Digest, Vol 178, Issue 38

On 21/02/2019 17:05, Nikolai Zhubr wrote: Actually no. Inline declarations (where implemented) are not limited to a loop index and not even limited to a loop. If you have an option to declare some few variables locally to some code block (e.g. FOR, as well as IF, CASE, WHILE, etc), in case yo

Re: [fpc-devel] fpc-devel Digest, Vol 178, Issue 38

Hi, 21.02.2019 17:41, Martin Frb: On 20/02/2019 19:31, Franz Müller wrote: It's a nice example why scoped variables would be in fact better, because the value of i is undefined if the for loop is exited normally. So even the original code wouln't work as expected, you cannot rely on i>High(arr)

Re: [fpc-devel] fpc-devel Digest, Vol 178, Issue 38

On 20/02/2019 19:31, Franz Müller wrote: It's a nice example why scoped variables would be in fact better, because the value of i is undefined if the for loop is exited normally. So even the original code wouln't work as expected, you cannot rely on i>High(arr) in that case, it depends on the w

Re: [fpc-devel] fpc-devel Digest, Vol 178, Issue 38

Well one of the answer in the Cantu blog has this ( which I changed to lets say a "real world" relative big function ) : var arr: array... function Fuckup: boolean; var I: Integer; begin  <> 20 lines of code  for var I := Low(arr) to High(arr) do if arr[I]. then break; <> 20 lines

Re: [fpc-devel] "Blank slate" next version of FPC

On 2/20/19 12:58 PM, James via fpc-devel wrote: Someone pointed out that a main goal of Pascal was to keep one from shooting oneself in the foot. It is this spirit that I think should be extended (if possible) to adopt at least the memory safe aspect of Rust. There are other programming constr