Re: [fpc-pascal] Auto vars (again)

[Maciej Izak]

2018-08-18 1:24 GMT+02:00 Ryan Joseph :

> but is there any merit to this idea if it was cleaned up and made safe? I
> did some tests to see if you could prevent passing auto vars out of scope
> and it’s possible to prevent most ways but not 100%.
>

You are trying to achieve something what is almost possible with current
FPC trunk version (which is also safe in the case of exception):

=== code begin ===
  TAutoCreate = record
_: T;
class operator Initialize(var a: TAutoCreate);
class operator Finalize(var a: TAutoCreate);
class operator Copy(constref a: TAutoCreate; var b: TAutoCreate);
class operator AddRef(var a: TAutoCreate);
  end;

class operator TAutoCreate.Initialize(var a: TAutoCreate);
begin
  a._ := T.Create;
end;

class operator TAutoCreate.Finalize(var a: TAutoCreate);
begin
  a._.Free;
end;

class operator TAutoCreate.Copy(constref a: TAutoCreate;
  var b: TAutoCreate);
begin
  // raise { some exception - prevent copy };
end;

class operator TAutoCreate.AddRef(var a: TAutoCreate);
begin
  // raise { some exception - prevent copy };
end;

var
  o: TAutoCreate;
begin // auto Create
  Writeln(o._.ToString);
end. // auto Free;
=== code end ===

the code above was not tested (written now) but should work. The only
disadvantage of above solution is lack of the way to omit "_".

The solution which probably should be accepted by fpc team is default
property without indexer:

=== code begin ===
property obj: T read fobj; default;
=== code end ===

with this property should be possible:

=== code begin ===
Writeln(o.ToString);
=== code end ===

next you can try to provide compiler magic:

=== code begin ===
var o: TObject auto; // equivalent of var o: TAutoCreate;
// please note that syntax with semicolon is improper:
//var o: TObject; auto;
=== code end ===

anyway I am not big fan of "auto" because it means many troubles, what if:

* there is no parameter less constructor
* why to call constructor when there is NewInstance (this seems more proper
for this case but...)

after NewInstance you can (and rather this will be necessary) call selected
constructor from instance which will be executed like regular method, but
what is the sense of "auto" calling NewInstance when you still need to
execute Constructor? :D

I see rather no reason for this feature in compiler (but nice try :) ).
There are many other directions to solve "auto free" problems without
compiler modifications - maybe not all can be solved but many problems for
sure - for example you have ready to use TAutoFree from mORMot or initial
experiments with ARC objects for NewPascal (still worth to mention ;P).

-- 
Best regards,
Maciej Izak
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Branch table

[Marco Borsari via fpc-pascal]

Il 17/08/2018 18:04, Giuliano Colla ha scritto:


Enjoy programming!

Giuliano


Thank you!
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Branch table

[Marco Borsari via fpc-pascal]

Il 17/08/2018 18:04, Giuliano Colla ha scritto:


I modified your code, to add a jump table (as it is in the example you
mention)


I came to that

program branch;
{$ASMMODE intel}
label tab,stop,a,b,c;
var idx:byte;
begin
write('Index? ');
readln(idx);
asm
xor eax,eax;
mov al,idx;
shl ax,2;
mov ebx,tab;
add ebx,eax;
jmp ebx;
tab:
dd (*offset*) a;
dd (*offset*) b;
dd (*offset*) c;
end['EAX','EBX'];
a:
writeln('0');
goto stop;
b:
writeln('1');
goto stop;
c:
writeln('2');
stop:
writeln('stop');
end.

but it works only for index 0, and crashes otherwise. Maybe
a problem of alignment? Or must be tab declared in data section?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Auto vars (again)

[Ryan Joseph]

> On Aug 17, 2018, at 7:50 PM, Maciej Izak  wrote:
> 
> 2018-08-18 1:24 GMT+02:00 Ryan Joseph :
> but is there any merit to this idea if it was cleaned up and made safe? I did 
> some tests to see if you could prevent passing auto vars out of scope and 
> it’s possible to prevent most ways but not 100%.
> 
> You are trying to achieve something what is almost possible with current FPC 
> trunk version (which is also safe in the case of exception):
> 
> var
>   o: TAutoCreate;
> begin // auto Create
>   Writeln(o._.ToString); 
> end. // auto Free;
> === code end ===
> 
> the code above was not tested (written now) but should work. The only 
> disadvantage of above solution is lack of the way to omit "_”. 

I think you may be right about this. Having “auto” leverage the existing 
management operators makes sense. It’s more overhead to wrap everything in 
records though and the larger problem is the so-called syntactic sugar missing.

> 
> The solution which probably should be accepted by fpc team is default 
> property without indexer:
> 
> === code begin ===
> property obj: T read fobj; default;
> === code end ===
> 
> with this property should be possible:
> 
> === code begin ===
> Writeln(o.ToString); 
> === code end ===

How does that property work exactly? Making this work properly is the most 
important part but I never considered it. It sounds like “with” statements kind 
of.

> 
> next you can try to provide compiler magic:
> 
> === code begin ===
> var o: TObject auto; // equivalent of var o: TAutoCreate;
> // please note that syntax with semicolon is improper: 
> //var o: TObject; auto; 
> === code end ===

I wasn’t sure what’s proper. Function modifiers look like that but there are no 
var modifiers in Pascal as of now. The absolute keyword is kind of similar. We 
have “threadvar” also which sets a precedence and starts a new section which is 
nice. Either way I really like the idea of introducing a keyword instead of 
using the generic <> syntax.

> 
> anyway I am not big fan of "auto" because it means many troubles, what if:
> 
> * there is no parameter less constructor

That’s the biggest problem IMO. Calling NewInstance is correct, you’re right, 
but if the class needs parameters you need to call the constructor again 
anyways so it kind of defeats the purpose. When the class has only a 
parameterless constructor it works beautifully though so the feature is limited 
to those cases.

> * why to call constructor when there is NewInstance (this seems more proper 
> for this case but...)
> 
> after NewInstance you can (and rather this will be necessary) call selected 
> constructor from instance which will be executed like regular method, but 
> what is the sense of "auto" calling NewInstance when you still need to 
> execute Constructor? :D

Agreed, that limits the usefulness of the feature. When it works well it’s a 
real win though.

> 
> I see rather no reason for this feature in compiler (but nice try :) ). There 
> are many other directions to solve "auto free" problems without compiler 
> modifications - maybe not all can be solved but many problems for sure - for 
> example you have ready to use TAutoFree from mORMot or initial experiments 
> with ARC objects for NewPascal (still worth to mention ;P).

How does TAutoFree in mORMot work? Never heard of this.

Full blown ARC is probably the best option but I was thinking of intermediate 
steps that are easy to implement and solve a a portion of the common use cases. 
It’s a poor mans ARC at best. ;)

Regards,
Ryan Joseph

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

Re: [fpc-pascal] why can't we define class operator for old fashion object type, but ok for 'advanced record' type?

[Ryan Joseph]

> On Aug 17, 2018, at 7:19 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> However for classes there is the problem of temporary variables. Take a := b 
> + c + d. That is essentially compiled as t := b + c; a := t + d. The compiler 
> does not know whether the operator creates an instance or not (yes, there are 
> circumstances when it can know that, but for the general case it can't) and 
> thus this would potentially lead to memory leaks. 
> 

I’m must be confused because classes already have operator overloads, they’re 
just in global scope outside of the class itself. Don’t all the same rules 
apply if the syntax is put inside the class (like in records) just the scope 
rules change?

Regards,
Ryan Joseph

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

Re: [fpc-pascal] Auto vars (again)

[Marcos Douglas B. Santos]

On Sat, Aug 18, 2018 at 2:04 PM, Ryan Joseph  wrote:
>
> How does TAutoFree in mORMot work? Never heard of this.

See 
http://blog.synopse.info/post/2014/11/14/Automatic-TSQLRecord-memory-handling

regards,
Marcos Douglas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Auto vars (again)

[Ryan Joseph]

> On Aug 17, 2018, at 7:50 PM, Maciej Izak  wrote:
> 
> class operator Initialize(var a: TAutoCreate);
> class operator Finalize(var a: TAutoCreate);
> 

One other thing I wanted to ask you. I know it’s minor but for me it’s pretty 
disappointing that the Initialize and Finalize operators aren’t simply 
constructor/destructor since those names are available in records already 
(constructor with no parameter that is).

I say this because the syntax is long and hard to remember and don’t follow the 
usual convention of constructors/destructors. Initialize and Finalize are the 
most common operators you implement so it makes sense they would follow the 
normal syntax rules (c++ does this for classes declared on the stack).

Was there any consideration to making the default constructor and destructor be 
used instead of class operators?

Regards,
Ryan Joseph

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

[fpc-pascal] Docs: portability differences between Borland/FPC

[Martok]

Hi all,

There is the old "Porting TP" document at 
, but it is rather incomplete (and 
probably on an
older language level). It also covers mostly syntactic differences - things a 
programmer will notice because of the error messages.

Since #34140 was again someone tripping over an obscure difference between what 
is documented for the Borland compilers and what
is not actually documented in FPC (there's a reason #16006 has so many dupes), 
I've started writing up some of these things that
I could think of right away on the wiki, for now as a draft under my user 
namespace:


Feel free to suggest more non-obvious topics (or make additions directly, it's 
a wiki). The general pattern for each topic is
"short summary"-"example"-"contrast"-"links". Include citations if possible, 
especially for the Borland side of things. FPC is
easy enough to reproduce for everybody.

-- 
Regards,
Martok

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

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

[Marco van de Voort]

In our previous episode, Martok said:
> There is the old "Porting TP" document at
> , but it is rather incomplete (and
> probably on an older language level).  It also covers mostly syntactic
> differences - things a programmer will notice because of the error
> messages.

Summary: behaviour with range checks off is implementation defined?

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

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

[Florian Klämpfl]

Am 18.08.2018 um 22:59 schrieb Martok:

Hi all,

There is the old "Porting TP" document at 
, but it is rather incomplete (and probably on an
older language level). It also covers mostly syntactic differences - things a 
programmer will notice because of the error messages.

Since #34140 was again someone tripping over an obscure difference between what 
is documented for the Borland compilers and what
is not actually documented in FPC (there's a reason #16006 has so many dupes), 
I've started writing up some of these things that
I could think of right away on the wiki, for now as a draft under my user 
namespace:



"For example in Delphi, Percentile above is a Subrange of the Host Type Integer, so it could contain any value of a 
32bit Integer."


This is plainly wrong, at least for the older delphis, the host type in delphi will be Byte (or even Shortint). Please 
note also, that Delphi shows exactly the same behavior as FPC if you replace 99 by 255.

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

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

[Florian Klämpfl]

Am 18.08.2018 um 23:26 schrieb Florian Klämpfl:

Am 18.08.2018 um 22:59 schrieb Martok:

Hi all,

There is the old "Porting TP" document at , but it is rather incomplete (and 
probably on an
older language level). It also covers mostly syntactic differences - things a programmer will notice because of the 
error messages.


Since #34140 was again someone tripping over an obscure difference between what is documented for the Borland 
compilers and what
is not actually documented in FPC (there's a reason #16006 has so many dupes), I've started writing up some of these 
things that

I could think of right away on the wiki, for now as a draft under my user 
namespace:



"For example in Delphi, Percentile above is a Subrange of the Host Type Integer, so it could contain any value of a 
32bit Integer."


This is plainly wrong, at least for the older delphis, the host type in delphi will be Byte (or even Shortint). 


It is actually shortint ...
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

[Bart]

On Sat, Aug 18, 2018 at 10:59 PM, Martok  wrote:

> There is the old "Porting TP" document at 
> , but it is rather incomplete (and 
> probably on an
> older language level). It also covers mostly syntactic differences - things a 
> programmer will notice because of the error messages.

{ Continued from above }
 if I > 99 then
   Writeln('This is not a Percentage')

Borland
Does exactly what is written.

TurboPascal 6.0 will not do that. It will execute the else statment if
there is one. (example compiled with {$R-})
 if I > 99 then
   Writeln('This is not a Percentage')
  else
writeln('I = ',I);

It will print: I = 100

Tested with TP 6.0 on FreeDos 1.2

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

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

[Bart]

On Sat, Aug 18, 2018 at 11:52 PM, Bart  wrote:

> TurboPascal 6.0 will not do that. It will execute the else statment if

Just ignore my above post.
Made a typo in the if condition

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

Re: [fpc-pascal] Auto vars (again)

[Ryan Joseph]

> On Aug 18, 2018, at 11:04 AM, Ryan Joseph  wrote:
> 
>> The solution which probably should be accepted by fpc team is default 
>> property without indexer:
>> 
>> === code begin ===
>> property obj: T read fobj; default;
>> === code end ===
>> 
>> with this property should be possible:
>> 
>> === code begin ===
>> Writeln(o.ToString); 
>> === code end ===
> 
> How does that property work exactly? Making this work properly is the most 
> important part but I never considered it. It sounds like “with” statements 
> kind of.

Ok, I understand what you mean now. This is actually a really great idea for 
all sorts of other uses  because it helps to unify namespaces between classes 
and prevent long.and.annoying() chaining of fields.

Btw why should this be a property? I know [] properties use the default keyword 
also but I don’t understand where this came  from and it’s strange to name the 
[] property since the name is irrelevant. I would think you’d want to just put 
a modifier on the default field:

 TAutoCreate = record
_: T; default;
class operator Initialize(var a: TAutoCreate);
class operator Finalize(var a: TAutoCreate);
class operator Copy(constref a: TAutoCreate; var b: TAutoCreate);
class operator AddRef(var a: TAutoCreate);
  end;

just curious and I thought I’d ask. 

Regards,
Ryan Joseph

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

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

[Martok]

Am 18.08.2018 um 23:39 schrieb Florian Klämpfl:
>> This is plainly wrong, at least for the older delphis, the host type in 
>> delphi will be Byte (or even Shortint). 
> 
> It is actually shortint ...
Correct, I was thinking of the default PackEnum. Which of course has absolutely
nothing to do with that example.

Fixed, thanks.

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