Re: [fpc-devel] Creating Generic Object

[Sven Barth via fpc-devel]

Amir  schrieb am So., 15. Apr. 2018, 23:51:

> Hi all,
>
>Currently, FPC allows declaring objects as
> var
>MyMap: specialize TFPGMap;
>
> This is very nice feature since I do not need define every Map/List/etc
> as a  separate type.
>
> But to create MyMap object, one has to write something like:
>MyMap := (specialize TFPGMap).Create()
>
> Wondering if there is any shorter way to handle the objects'
> initialization, .e.g., something like
>MyMap := auto.Create;
>

Just declare a type for the specialization:

=== code begin ===

type
  TMyDataMap = specialize TFPGMap;

var
  MyData: TMyDataMap;
begin
  MyData := TMyDataMap.Create;
end.

=== code end ===

Regards,
Sven

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

[fpc-devel] Creating Generic Object

[Amir]

Hi all,

  Currently, FPC allows declaring objects as
var
  MyMap: specialize TFPGMap;

This is very nice feature since I do not need define every Map/List/etc 
as a  separate type.


But to create MyMap object, one has to write something like:
  MyMap := (specialize TFPGMap).Create()

Wondering if there is any shorter way to handle the objects' 
initialization, .e.g., something like

  MyMap := auto.Create;


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

Re: [fpc-devel] Dangerous optimization in CASE..OF

[Ondrej Pokorny]

On 15.04.2018 19:46, Martok wrote:

Am 15.04.2018 um 11:09 schrieb Ondrej Pokorny:

Please note that I want to support all ordinal values on the left side
of the operator. You can then validate a value of variable of the enum
type itself.

Useful indeed! It still strikes me as weird that one will need to add this check
many times when porting code from Delphi, but at least now one can.

Jonas will probably argue that this is a tautology and should always evaluate to
true because a variable of a type by definition is of that type, regardless of
content, but it might be considered as somewhat in line with how "var is class"
handles nil values as "not an instance of class".


Yes, unfortunately the "implementation detail"/"undefined behavior" 
mantra can strike us here as well :/ Actually it can strike us 
everywhere. If you take it to an extreme, the Ord(E) result is undefined 
for an invalid enum value as well:


type
  TMyEnum = (zero, one);
var
  E: TMyEnum;
begin
  E := TMyEnum(5);
  case Ord(E) of
    Ord(zero): A;
    Ord(two): B;
  else
    C;
  end;

Who knows what will be executed. A, B or C or nothing? Undefined 
behavior indeed...


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

Re: [fpc-devel] Dangerous optimization in CASE..OF

[Martok]

Am 15.04.2018 um 11:09 schrieb Ondrej Pokorny:
> Please note that I want to support all ordinal values on the left side 
> of the operator. You can then validate a value of variable of the enum 
> type itself.
Useful indeed! It still strikes me as weird that one will need to add this check
many times when porting code from Delphi, but at least now one can.

Jonas will probably argue that this is a tautology and should always evaluate to
true because a variable of a type by definition is of that type, regardless of
content, but it might be considered as somewhat in line with how "var is class"
handles nil values as "not an instance of class".

-- 
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

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

[fpc-devel] AS/IS operators for enums

[Ondrej Pokorny]

I uploaded a new patch to add enum support to AS/IS operators to 
https://bugs.freepascal.org/view.php?id=33603


1.) I added support for the IS operator.
2.) I added support of any ordinal type (int/enum) on the left side of 
the operator:

var
  E: TMyEnum;
begin
  E := E as TMyEnum; // check if E is valid value
  if E is TMyEnum then // check if E is valid value

3.) I added support for compile-time constant evaluation as Sven suggested.

4.) I uploaded new test case projects for both AS and IS operators.

---

I did not add support to any integer type on the right side:
if I is Byte then // not supported

because the boundaries of int64 and uint64 types make the whole story 
too complicated for me and I don't need it. If anybody wants this 
feature, feel free to implement it yourself.


Ondrej

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

Re: [fpc-devel] Dangerous optimization in CASE..OF

[Ondrej Pokorny]

On 15.04.2018 0:05, Martok wrote:
All this is not quite as easy to get right as it seems on the surface. 
But I do like the the "v is TEnum" operator from the other side of 
this thread, regardless of where this goes... 


I don't want to force FPC to any direction. I just want to have a simple 
built-in method to validate an ordinal value against an enum. Be it the 
AS/IS operator or a new compiler intrinsic. I chose the AS/IS operators 
because they are easier to implement for me.


It should not change any kind of religion or anything else, they are 
just helpful tools.


Please note that I want to support all ordinal values on the left side 
of the operator. You can then validate a value of variable of the enum 
type itself. Then you can use code like:


var
  E: TMyEnum;

// ...

if not (E is TMyEnum) then
  // handle your error here
else
case E of
  one:
  two:
else
  // handle possible valid values not listed above
end;

That should be OK for all of us.

Ondrej

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

Re: [fpc-devel] What's the status on the "record default field" functionality?

[Sven Barth via fpc-devel]

Ben Grasset  schrieb am So., 15. Apr. 2018, 09:05:

> AFAIK it's been working for over a year in a separate branch. The smart
> pointer example demos worked perfectly as far as I could tell. Is there a
> particular reason it hasn't been added to the main codebase the way
> management operators were?
>

That the other core devs aren't perfectly happy with it yet.

Regards,
Sven

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

[fpc-devel] What's the status on the "record default field" functionality?

[Ben Grasset]

AFAIK it's been working for over a year in a separate branch. The smart
pointer example demos worked perfectly as far as I could tell. Is there a
particular reason it hasn't been added to the main codebase the way
management operators were?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel