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

[Sven Barth via fpc-devel]

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 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/finally. Also make sure you inline
the MoveNext and GetCurrent!

 How do you make a (for in) enumerator with a record? I don't use them 
for exactly this reason, and they did seem to be another useful 
language feature that turned out to be poorly implemented by 
Embarcadero. (Haven't checked with FPC).
Just as you would a class (an object is fine, too, by the way). You can 
take a look at the testcase here: 
https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/test/tforin25.pp?view=markup


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[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 
> 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/finally. Also make sure you inline the MoveNext and
> GetCurrent!
>
>  How do you make a (for in) enumerator with a record? I don't use them for
exactly this reason, and they did seem to be another useful language
feature that turned out to be poorly implemented by Embarcadero. (Haven't
checked with FPC).
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Ben Grasset]

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/finally. Also make sure you inline the MoveNext and
GetCurrent!
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Ben Grasset]

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.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Florian Klämpfl]

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 this /> >/list. 
/
People could change this attitude by contributing to FPC. But very few 
do constantly with high quality patches.


Not at all. My experience is that contributing to FPC compiler development is 
just a waste of time.
1.) First you have to convince core compiler developers that your idea is good. 



Well, it is not about ideas but contribution in the sense of maintenance 
as I mentioned below. So basically bug fixing, release building and 
testing etc.


The number of unfixed bugs in the bug tracker continuously increases and 
this is a reason to be very careful with new "ideas". I have also a lot 
of ideas where I could slap together a half-baken patch (well, actually 
I often do, most of it is in my private git repository), but finalizing 
everything and fixing bugs is what's missing.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Martin Frb]

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 you know for sure from their 
meaning that their values just make no sense outside of this very 
block, you would know they do not leak out accidentally. This is 
certainly not the same as detecting uninitialized variables. A 
variable might be technically initialized, but at the same time its 
value might make no sense outside of some scope (for the reasons of 
your business logic or whatever else considerations).


Search the forum and mail history. The discussion has been add several 
times. And there are plenty of more examples, why it is not good.
No point in repeating them. Especially not, since the decision has afaik 
already been made long ago.



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Nikolai Zhubr]

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) in that case, it depends on the way the for
loop is implemented.
Using only the variable local to the loop would cause a compiler error, while 
using only the variable defined in the function body would not even cause a 
warning but leed to unwanted results.


That does not need inlined variables.

The compiler already has a warning about uninitialized vars. If not
detected after a for loop, this should be improved (rather than adding
some other workaround).

And there is a command line switch to tread warnings as errors. So that
problem is perfectly solve-able.


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 you know for sure from their meaning 
that their values just make no sense outside of this very block, you 
would know they do not leak out accidentally. This is certainly not the 
same as detecting uninitialized variables. A variable might be 
technically initialized, but at the same time its value might make no 
sense outside of some scope (for the reasons of your business logic or 
whatever else considerations).



Thank you,

Regards,
Nikolai





___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[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) in that case, it depends on the way the for 
loop is implemented.

Using only the variable local to the loop would cause a compiler error, while 
using only the variable defined in the function body would not even cause a 
warning but leed to unwanted results.


That does not need inlined variables.

The compiler already has a warning about uninitialized vars. If not 
detected after a for loop, this should be improved (rather than adding 
some other workaround).


And there is a command line switch to tread warnings as errors. So that 
problem is perfectly solve-able.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Franz Müller]

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 of code  Result := (I <= 
High(arr)); end; regards, -- Dimitrios Chr. Ioannidis


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 way the for loop is implemented.
Using only the variable local to the loop would cause a compiler error, while 
using only the variable defined in the function body would not even cause a 
warning but leed to unwanted results.

On the other side, using a scoped variable while knowing that you will need the 
value of the value of the variable later is a kind of stupidity which will make 
this one a minor probem, compared to thers that such a programmer woud 
introduce into the code...

I don't know how inline variables are defined in Delphi, but forbidding to use 
names for inline variables which are already known at that place of the code, 
no matter where they have been defined, would eliminate this potential problem 
completely.
(And if such a restriction does not exist in Delphi, it could be removed just 
for $mode delphi to keep compatibility, while the other compiler modes would 
ensure code safety in that respect.)





 

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[wkitty42]

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 constructs unrelated to safety which I think merit examination,

also.


we already have this, don't we? the biggest problem i see is the lack of proper 
buffer, stack, and heap checking when folks are developing their programs... i 
mean if you have a 1024byte destination buffer you're going to fill from another 
buffer, check how much is in the originating buffer before just blindly copying 
it over to the destination buffer... not checking for things like that is just 
lazy... hell, deploy with stack and heap checking enabled... slower? really? 
with today's machines? it doesn't make that much difference, in the long run... 
the system will still be waiting 95+% of the time for something to do...



--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list unless*
   *a signed and pre-paid contract is in effect with us.*
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel