Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2016-03

Feature announcement: Record management operators

46 messages · 7 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Maciej Izak

Hi,

I'm pleased to finally announce the additional record operators: Initialize, Finalize.

Download (r33200):
http://svn.freepascal.org/svn/fpc/branches/maciej/smart_pointers

"Record management operators aka record constructor/destructor"

They working like low level auto-executed constructor/destructor for records.

===== motivation =====

It can be used for:

-nullable types
-very fast RTTI.TValue implementation
-as replacement for manually called Init/Finit record methods for example like in mORMot for many types.
-auto init/finit for fields of pointer/object type

Additionally, it is base for my further work:

-smart pointers
-ARC objects
-Oxygene mode
-Delphi NextGen mode

===== example begin =====
{$MODE DELPHI}
uses SysUtils;
type
  TFoo = record
  private
    class operator Initialize(var aFoo: TFoo);
    class operator Finalize(var aFoo: TFoo);
  public
    F: Integer;
    S: string;
    P: Pointer;
    C: TObject
  end;
class operator TFoo.Initialize(var aFoo: TFoo);
begin
  F := 10;
  S := 'FPC rulezzz';
  P := nil;
  C := nil;
end;
class operator TFoo.Finalize(var aFoo: TFoo);
begin
  if S = 'Delphi rulezzz' then
    raise Exception.Create('Trololo');
  FreeMem(P);
  C.Free;
end;
procedure Foo;
var
  f: TFoo;
begin
  WriteLn(f.F); // output: 10
  WriteLn(f.S); // output: FPC rulezzz
  WriteLn(f.P = nil); // output: true
  WriteLn(f.C = nil); // output: true
end;
begin
  Foo;
end.
===== example end=====

===== more info =====

When Initialize of Finalize is used, record is treated as managed record (similar to record containg string, interface or dynamic array).

It works correctly in all possible ways, works for:

* New
* Dispose
* Initialize
* Finalize
* InitializeArray
* FinalizeArray
* global variables
* local variables
* for fields inside: records, objects, classes

===== additional gain =====

Speed of dynamicly created instances for records increased. For now is used always init table instead of rtti table:

type
  TBar = record
    f1,f2,f3,f4,f5,f6,f7,f8,f9: byte;
    s: string;
  end;

previously:

  GetMem(PB, SizeOf(TBar));
  InitializeArray(PB, TypeInfo(TBar), 1); // FPC_INITIALIZE was executed 10
times

now:

  GetMem(PB, SizeOf(TBar));
  InitializeArray(PB, TypeInfo(TBar), 1); // FPC_INITIALIZE is executed
just once

===== more examples =====

http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/maciej/smart_pointers/tests/test/toperator90.pp?view=co&revision=33200&content-type=text%2Fplain&pathrev=33200

http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/maciej/smart_pointers/tests/test/toperator91.pp?view=co&revision=33200&content-type=text%2Fplain&pathrev=33200

http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/maciej/smart_pointers/tests/test/toperator92.pp?view=co&content-type=text%2Fplain

http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/maciej/smart_pointers/tests/test/toperator93.pp?view=co&content-type=text%2Fplain

===== more details from commit message =====

http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/maciej/smart_pointers/?view=log&sortby=date&pathrev=33200

Best regards, Maciej Izak

Reply by email

Michael Van Canneyt
to Maciej Izak
Maciej Izak wrote 53 lines
Hi, I'm pleased to finally announce the additional record operators: Initialize, Finalize. Download (r33200): http://svn.freepascal.org/svn/fpc/branches/maciej/smart_pointers "Record management operators aka record constructor/destructor" They working like low level auto-executed constructor/destructor for records. ===== motivation ===== It can be used for: -nullable types -very fast RTTI.TValue implementation -as replacement for manually called Init/Finit record methods for example like in mORMot for many types. -auto init/finit for fields of pointer/object type Additionally, it is base for my further work: -smart pointers -ARC objects -Oxygene mode -Delphi NextGen mode ===== example begin ===== {$MODE DELPHI} uses SysUtils; type TFoo = record private class operator Initialize(var aFoo: TFoo); class operator Finalize(var aFoo: TFoo); public F: Integer; S: string; P: Pointer; C: TObject end; class operator TFoo.Initialize(var aFoo: TFoo); begin F := 10; S := 'FPC rulezzz'; P := nil; C := nil; end;

What is the need for the (var aFoo: TFoo); ?

Michael.

Reply by email

Jonas Maebe
to Maciej Izak: I'm pleased to finally announce the additional record operators: Initialize, Finalize.…

Maciej Izak wrote on Mon, 07 Mar 2016:

I'm pleased to finally announce the additional record operators: Initialize, Finalize.

Congratulations! However, in the future please try to split your commits more. For example, it seems the optimisation regarding the RTTI for initialisation could have been committed (and hence tested and potentially merged) separately from the rest.

The syntax with the separate "var aFoo: TFoo" parameter, but then seemingly using that parameter as some kind of automatic alias for a fake "self" in the body, is also rather strange (why don't you have to use "aFoo.F := 10" etc?)

Jonas

Reply by email

Unknown author
to Maciej Izak: 2016-03-07 15:34 GMT+01:00 Kazantsev Alexey : Work in progress. Will be probably released…

You mean really,really,smart pointers and the introduction of the comma into the language?

Maciej Izak wrote 17 lines
2016-03-07 15:34 GMT+01:00 Kazantsev Alexey < >: It's cool! What about Copy or CopyRecord? Work in progress. Will be probably released together with smart pointers. -- Best regards, Maciej Izak _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply by email

Michael Van Canneyt
to Jonas Maebe: Maciej Izak wrote on Mon, 07 Mar 2016: Congratulations! However, in the future please try…
Jonas Maebe wrote 14 lines
Maciej Izak wrote on Mon, 07 Mar 2016: > I'm pleased to finally announce the additional record operators: > Initialize, Finalize. Congratulations! However, in the future please try to split your commits more. For example, it seems the optimisation regarding the RTTI for initialisation could have been committed (and hence tested and potentially merged) separately from the rest. The syntax with the separate "var aFoo: TFoo" parameter, but then seemingly using that parameter as some kind of automatic alias for a fake "self" in the body, is also rather strange (why don't you have to use "aFoo.F := 10" etc?)

Exactly my question.
I think it would have been preferable to drop the parameter and simply introduce 'self' ?

The current solution seems quite counter-intuitive.

Michael.

Reply by email

Jonas Maebe
to Michael Van Canneyt

Michael Van Canneyt wrote on Mon, 07 Mar 2016:

Show quoted text 10 lines
On Mon, 7 Mar 2016, Jonas Maebe wrote: > The syntax with the separate "var aFoo: TFoo" parameter, but then > seemingly using that parameter as some kind of automatic alias for > a fake "self" in the body, is also rather strange (why don't you > have to use "aFoo.F := 10" etc?) Exactly my question. I think it would have been preferable to drop the parameter and simply introduce 'self' ?

No, since as Maciej remarked, a class operator is always a static method. Introducing conventions or behaviours for this class operator that are different compared to those of other class operators would not be a good idea (even if it would result in slightly less typing -- you can always add a "with" block if you want to avoid that :)

The current solution seems quite counter-intuitive.

Definitely.

Jonas

Reply by email

Maciej Izak
to Jonas Maebe: Maciej Izak wrote on Mon, 07 Mar 2016: Congratulations! However, in the future please try…

2016-03-07 15:50 GMT+01:00 Jonas Maebe :

Show quoted text 5 lines
Congratulations! However, in the future please try to split your commits more. For example, it seems the optimisation regarding the RTTI for initialisation could have been committed (and hence tested and potentially merged) separately from the rest.

Thanks :). I will try to commit more regular. Btw. for mentioned initialization, optimization was not that obvious without implementing Initialization/Finalization operators.

The syntax with the separate "var aFoo: TFoo" parameter, but then seemingly using that parameter as some kind of automatic alias for a fake "self" in the body, is also rather strange (why don't you have to use "aFoo.F := 10" etc?)

"var aFoo: TFoo" parameter syntax is "Sven approved" ;)

Best regards, Maciej Izak

Reply by email

Michael Van Canneyt
to Maciej Izak
Maciej Izak wrote 20 lines
2016-03-07 15:50 GMT+01:00 Jonas Maebe : > Congratulations! However, in the future please try to split your commits > more. For example, it seems the optimisation regarding the RTTI for > initialisation could have been committed (and hence tested and potentially > merged) separately from the rest. > Thanks :). I will try to commit more regular. Btw. for mentioned initialization, optimization was not that obvious without implementing Initialization/Finalization operators. > The syntax with the separate "var aFoo: TFoo" parameter, but then > seemingly using that parameter as some kind of automatic alias for a fake > "self" in the body, is also rather strange (why don't you have to use > "aFoo.F := 10" etc?) "var aFoo: TFoo" parameter syntax is "Sven approved" ;)

In that case, I think you need to force people to use it.

Michael.

Reply by email

Sven Barth
to Maciej Izak: 2016-03-07 15:50 GMT+01:00 Jonas Maebe : Thanks :). I will try to commit more regular.…
"Maciej Izak" wrote
2016-03-07 15:50 GMT+01:00 Jonas Maebe : > > Congratulations! However, in the future please try to split your commits

more. For example, it seems the optimisation regarding the RTTI for initialisation could have been committed (and hence tested and potentially merged) separately from the rest.

Thanks :). I will try to commit more regular. Btw. for mentioned

initialization, optimization was not that obvious without implementing Initialization/Finalization operators.

Might be, but even then you can commit that separately.

> > The syntax with the separate "var aFoo: TFoo" parameter, but then

seemingly using that parameter as some kind of automatic alias for a fake "self" in the body, is also rather strange (why don't you have to use "aFoo.F := 10" etc?)

"var aFoo: TFoo" parameter syntax is "Sven approved" ;)

Jonas meant that you didn't use "aFoo" inside the body of the Initialize/Finalize operators. Is that a copy and paste oversight or does that really work? In the latter case: that definitely shouldn't be the case then.

Regards,
Sven

Reply by email

Maciej Izak
to Sven Barth

2016-03-07 17:12 GMT+01:00 Sven Barth :

Show quoted text 9 lines
Might be, but even then you can commit that separately. Might be ;) Jonas meant that you didn't use "aFoo" inside the body of the Initialize/Finalize operators. Is that a copy and paste oversight or does that really work? In the latter case: that definitely shouldn't be the case then.

Oh my... Sorry! This is definitely copy and paste oversight :\ Correct example code:

===== example begin =====
{$MODE DELPHI}
uses SysUtils;
type
  TFoo = record
  private
    class operator Initialize(var aFoo: TFoo);
    class operator Finalize(var aFoo: TFoo);
  public
    F: Integer;
    S: string;
    P: Pointer;
    C: TObject
  end;
class operator TFoo.Initialize(var aFoo: TFoo);
begin
  aFoo.F := 10;
  aFoo.S := 'FPC rulezzz';
  aFoo.P := nil;
  aFoo.C := nil;
end;
class operator TFoo.Finalize(var aFoo: TFoo);
begin
  if aFoo.S = 'Delphi rulezzz' then
    raise Exception.Create('Trololo');
  FreeMem(aFoo.P);
  aFoo.C.Free;
end;
procedure Foo;
var
  f: TFoo;
begin
  WriteLn(f.F); // output: 10
  WriteLn(f.S); // output: FPC rulezzz
  WriteLn(f.P = nil); // output: true
  WriteLn(f.C = nil); // output: true
end;
begin
  Foo;
end.
===== example end=====
Best regards, Maciej Izak

Reply by email

Maciej Izak
to Jonas Maebe: Maciej Izak wrote on Mon, 07 Mar 2016: Congratulations! However, in the future please try…

07.03.2016 15:50 "Jonas Maebe" :

The syntax with the separate "var aFoo: TFoo" parameter, but then

seemingly using that parameter as some kind of automatic alias for a fake "self" in the body, is also rather strange (why don't you have to use "aFoo.F := 10" etc?)

My mistake in example. I misunderstood. That was too obvious and somehow was very hard to see lack of "aFoo." part in attached example :/ see the replay to Sven, sorry for mess.

Reply by email

Michael Van Canneyt
to Maciej Izak
Maciej Izak wrote 9 lines
07.03.2016 15:50 "Jonas Maebe" : > The syntax with the separate "var aFoo: TFoo" parameter, but then seemingly using that parameter as some kind of automatic alias for a fake "self" in the body, is also rather strange (why don't you have to use "aFoo.F := 10" etc?) My mistake in example. I misunderstood. That was too obvious and somehow was very hard to see lack of "aFoo." part in attached example :/ see the replay to Sven, sorry for mess.

Nice to hear this, and a good job you did!

Michael.

Reply by email

Maciej Izak
to Unknown author: You mean really,really,smart pointers and the introduction of the comma into the language?

2016-03-07 15:52 GMT+01:00 :

You mean really,really,smart pointers and the introduction of the comma into the language?

By comma did you mean comma "," ?

I mean really really really smart pointers ;) without comma "," operator:

http://lists.freepascal.org/pipermail/fpc-devel/2015-October/036098.html

the final result can be a little different, but this is my direction.

Best regards, Maciej Izak

Reply by email

Michael Van Canneyt
to Maciej Izak
Maciej Izak wrote 13 lines
2016-03-07 15:52 GMT+01:00 : > You mean really,really,smart pointers and the introduction of the comma > into the language? > By comma did you mean comma "," ? I mean really really really smart pointers ;) without comma "," operator: http://lists.freepascal.org/pipermail/fpc-devel/2015-October/036098.html the final result can be a little different, but this is my direction.

And it seems like a good direction.

Are there plans to merge the current work - which seems like a finished functionality - to trunk, so it can be tested more easily ?

Michael.

Reply by email

Sven Barth
to Michael Van Canneyt
"Michael Van Canneyt" wrote 24 lines
On Tue, 8 Mar 2016, Maciej Izak wrote: > 2016-03-07 15:52 GMT+01:00 : > >> You mean really,really,smart pointers and the introduction of the comma >> into the language? >> > > By comma did you mean comma "," ? > > I mean really really really smart pointers ;) without comma "," operator: > > http://lists.freepascal.org/pipermail/fpc-devel/2015-October/036098.html > > the final result can be a little different, but this is my direction. And it seems like a good direction. Are there plans to merge the current work - which seems like a finished functionality - to trunk, so it can be tested more easily ?

Yes, there are plans. I just need to check whether the implementation itself is so far correct and if there aren't any complains (either from me or anyone else) I'd merge it soon.

Regards,
Sven

Reply by email

Maciej Izak
to Sven Barth

2016-03-08 14:18 GMT+01:00 Sven Barth :

Yes, there are plans. I just need to check whether the implementation itself is so far correct and if there aren't any complains (either from me or anyone else) I'd merge it soon.

Sounds scary ;).

Should I continue my work on smart_pointer branch or better is wait for merge?

Best regards, Maciej Izak

Reply by email

Sven Barth
to Maciej Izak
"Maciej Izak" wrote
2016-03-08 14:18 GMT+01:00 Sven Barth : > > Yes, there are plans. I just need to check whether the implementation

itself is so far correct and if there aren't any complains (either from me or anyone else) I'd merge it soon.

Show quoted text 5 lines
Sounds scary ;). Should I continue my work on smart_pointer branch or better is wait for

merge?

As long as further work of you does not directly interfere with the code you changed you're good to go. I only want to avoid changes to code you touched just in case I have suggestions for corrections or complains or whatever.

Regards,
Sven

Reply by email

Maciej Izak
to Sven Barth

2016-03-10 0:14 GMT+01:00 Sven Barth :

Show quoted text 5 lines
As long as further work of you does not directly interfere with the code you changed you're good to go. I only want to avoid changes to code you touched just in case I have suggestions for corrections or complains or whatever.

Ok, so I am waiting for feedback. Feature is stable. Predictable new operators in my next step: AddRef and Copy (that will not require new ppu version), and meybe some special operator (that will break ppu version), but that will not require any deep refactoring.

Best regards, Maciej Izak

Reply by email

Sven Barth
to Maciej Izak
"Maciej Izak" wrote
2016-03-10 0:14 GMT+01:00 Sven Barth : > > As long as further work of you does not directly interfere with the code

you changed you're good to go. I only want to avoid changes to code you touched just in case I have suggestions for corrections or complains or whatever.

Ok, so I am waiting for feedback. Feature is stable. Predictable new

operators in my next step: AddRef and Copy (that will not require new ppu version), and meybe some special operator (that will break ppu version), but that will not require any deep refactoring.

What do you mean with AddRef operator?
What do you mean with special operator?
(maybe this should be discussed in a new thread however)

Regards,
Sven

Reply by email

Maciej Izak
to Sven Barth

2016-03-11 11:25 GMT+01:00 Sven Barth :

What do you mean with AddRef operator? AddRef is a special case, is used for records passed to procedures by

value (to increase reference count for strings, interfaces, dyn. arrays).

I have done a little patch (r33229), where copy and addref empty slots/placeholders in VMT are omitted. I need to think about it (AddRef operator existence is uncertain).

For merge with trunk purpose is recommended to use smart_pointers branch r33229 (more optimal "Init VMT" without empty slots for management operators: AddRef and Copy).

What do you mean with special operator? (maybe this should be discussed in a new thread however)

I'd like to omit discussion on this topic for a while. I need to finish research first.

Best regards, Maciej Izak

Reply by email

Anthony Walter
to Maciej Izak

Maciej,

Just a note, I attempted to compile your smart_pointer branch revision 33229 on a Raspberry Pi 3 Raspbian Jessie (with the latest updates) and the build failed.

make all OPT="-dFPC_ARMHF"

Sorry, I didn't capture the output error messages.

Reply by email

Maciej Izak
to Anthony Walter

2016-03-21 2:12 GMT+01:00 Anthony Walter :

Show quoted text 8 lines
Just a note, I attempted to compile your smart_pointer branch revision 33229 on a Raspberry Pi 3 Raspbian Jessie (with the latest updates) and the build failed. make all OPT="-dFPC_ARMHF" Sorry, I didn't capture the output error messages.

...as expected. Building smart_pointers branch is more complicated. smart_pointers branch contains RTL and RTTI changes for records. To "make all" for smart_pointers branch you need to use smart_pointers compiler (sounds like paradox :).

You can't build RTL and PACKAGES for smart_pointers branch by using standard FPC compiler. Small tips:

1. build smart_pointers compiler by using FPC 3.0
2. build smart_pointers RTL & PACKAGES by using smart_pointers compiler from step 1.
3. now you can "make all" but only by using Compiler & RTL from steps 1 & 2

Best regards, Maciej Izak

Reply by email

Sven Barth
to Maciej Izak
"Maciej Izak" wrote
2016-03-21 2:12 GMT+01:00 Anthony Walter : > > Just a note, I attempted to compile your smart_pointer branch revision

33229 on a Raspberry Pi 3 Raspbian Jessie (with the latest updates) and the build failed.

Show quoted text 7 lines
> > make all OPT="-dFPC_ARMHF" > > Sorry, I didn't capture the output error messages. ...as expected. Building smart_pointers branch is more complicated.

smart_pointers branch contains RTL and RTTI changes for records. To "make all" for smart_pointers branch you need to use smart_pointers compiler (sounds like paradox :).

You can't build RTL and PACKAGES for smart_pointers branch by using

standard FPC compiler. Small tips:

1. build smart_pointers compiler by using FPC 3.0 2. build smart_pointers RTL & PACKAGES by using smart_pointers compiler

from step 1.

3. now you can "make all" but only by using Compiler & RTL from steps 1 &

2

The RTL *must* be compileable with the latest release. You need to use ifdefs to ensure that.
If a "make all" at the top level with a FPC 3.0.0 does not work then your branch won't be merged. Simple as that...

Regards,
Sven

Reply by email

Maciej Izak
to Sven Barth

2016-03-21 14:28 GMT+01:00 Sven Barth :

Show quoted text 6 lines
The RTL *must* be compileable with the latest release. You need to use ifdefs to ensure that. If a "make all" at the top level with a FPC 3.0.0 does not work then your branch won't be merged. Simple as that...

So what should I do? Additional compiler $DEFINE RECORD_OPERATORS? FPC_FULLVERSION seems not sufficient. The change for records RTTI is required to adopt record operators, seems like I am locked. Or maybe should I just continue my work in branch don't looking at trunk (just for fun).

Best regards, Maciej Izak

Reply by email

Michael Van Canneyt
to Maciej Izak: 2016-03-21 14:28 GMT+01:00 Sven Barth : So what should I do? Additional compiler $DEFINE…
Maciej Izak wrote 13 lines
2016-03-21 14:28 GMT+01:00 Sven Barth : > The RTL *must* be compileable with the latest release. You need to use > ifdefs to ensure that. > > If a "make all" at the top level with a FPC 3.0.0 does not work then your > branch won't be merged. Simple as that... > So what should I do? Additional compiler $DEFINE RECORD_OPERATORS? FPC_FULLVERSION seems not sufficient. The change for records RTTI is required to adopt record operators, seems like I am locked. Or maybe should I just continue my work in branch don't looking at trunk (just for fun).

No need for that.

You just need to {$IFNDEF VER3_0} all record operators code.

A make cycle compiles 3 times.

During a make cycle you must start with 3.0.0, this will compile the RTL with 3.0.0 and this excludes record operators.

During the second compile, it will be with the latest compiler, so VER3_1_1, which will include the record operators code, and all will be well.

Michael.

Reply by email

Maciej Izak
to Michael Van Canneyt

2016-03-21 15:08 GMT+01:00 Michael Van Canneyt :

Show quoted text 12 lines
No need for that. You just need to {$IFNDEF VER3_0} all record operators code. A make cycle compiles 3 times. During a make cycle you must start with 3.0.0, this will compile the RTL with 3.0.0 and this excludes record operators. During the second compile, it will be with the latest compiler, so VER3_1_1, which will include the record operators code, and all will be well.

Sounds perfect!

@Michael, @Sven: now I know why compiler_cycle was problematic for my branch :)

Best regards, Maciej Izak

Reply by email

Sven Barth
to Maciej Izak
Maciej Izak wrote 21 lines
2016-03-21 15:08 GMT+01:00 Michael Van Canneyt < >: No need for that. You just need to {$IFNDEF VER3_0} all record operators code. A make cycle compiles 3 times. During a make cycle you must start with 3.0.0, this will compile the RTL with 3.0.0 and this excludes record operators. During the second compile, it will be with the latest compiler, so VER3_1_1, which will include the record operators code, and all will be well. Sounds perfect! @Michael, @Sven: now I know why compiler_cycle was problematic for my branch :)

When you add a new feature as a first step it's recommended to do a "make cycle" in the compiler directory. This way you know that cycling the compiler (starting with the last release and coming to the trunk one) works. If you changed something in code generation then a "make fullcycle" is advisable as well as that builds the compiler once for each supported architecture. And then "make all" at the top level is the next big step with the final one being a testsuite run with a comparison of the results.

Regards,
Sven

Reply by email

Sven Barth
to Anthony Walter
"Anthony Walter" wrote
Maciej, Please let me know when you apply Sven's recommendations to the make

commands and I'll test. Thanks..

Small correction: these changes don't aplly to the make commands, but the RTL so that these make commands work correctly again.

Regards,
Sven

Reply by email

Maciej Izak
to Maciej Izak: I'm pleased to finally announce the additional record operators: Initialize, Finalize.…

Done in rev 33381... Anthony, feel free to checkout smart_pointers branch.

Thanks again Michael and Sven for the tips! That will be useful for further work. I've decide to use {$if FPC_FULLVERSION>30100} instead of {$IFNDEF VER3_0}.

The last task "make all" with FPC 3.0.0 as start compiler, was depressing. Anyway I am alive.

Note to myself: check few times old files like system.o/ppu generated for Lazarus >.< for pp.lpi. Any make clean/distclean will not help... I'll have nightmares with message:

Compiling ptop.pp
PPU Loading C:\freepascal\fpc\trunk\units\i386-win32\fcl-base\custapp.ppu PPU Source: custapp.pp not available
Recompiling CustApp, checksum changed for System

Best regards, Maciej Izak

Reply by email

Sven Barth
to Maciej Izak
"Maciej Izak" wrote
Done in rev 33381... Anthony, feel free to checkout smart_pointers branch. Thanks again Michael and Sven for the tips! That will be useful for

further work. I've decide to use {$if FPC_FULLVERSION>30100} instead of {$IFNDEF VER3_0}.

The last task "make all" with FPC 3.0.0 as start compiler, was

depressing. Anyway I am alive.

Great. I'll try to take a look soonish. :)

Note to myself: check few times old files like system.o/ppu generated for

Lazarus >.< for pp.lpi. Any make clean/distclean will not help... I'll have nightmares with message:

Show quoted text 5 lines
Compiling ptop.pp PPU Loading C:\freepascal\fpc\trunk\units\i386-win32\fcl-base\custapp.ppu PPU Source: custapp.pp not available Recompiling CustApp, checksum changed for System

Strange, because for me a "make clean all" tends to work without problems (at least if I haven't messed things up in the compiler myself :P )

Regards,
Sven

Reply by email

Maciej Izak
to Sven Barth

2016-03-29 12:23 GMT+02:00 Sven Barth :

Strange, because for me a "make clean all" tends to work without problems (at least if I haven't messed things up in the compiler myself :P )

Nothing strange, when you do forbidden things, like installing RTL inside branch folder :P

Best regards, Maciej Izak

Reply by email

Sven Barth
to Maciej Izak
"Maciej Izak" wrote
2016-03-29 12:23 GMT+02:00 Sven Barth : > > Strange, because for me a "make clean all" tends to work without

problems (at least if I haven't messed things up in the compiler myself :P )

Nothing strange, when you do forbidden things, like installing RTL inside

branch folder :P

Ah, okay. In that case... ;)

Regards,
Sven

Reply by email

Anthony Walter
to Sven Barth

Maceij,

I did a build using your revision 33381. Compilation with "make all" worked with fpc 3.0.0 as a starting compiler. However my first test with it revealed a pretty serious bug:

program mytest;
{$mode delphi}
type
  TFoo = record
  private
    class operator Initialize(var aFoo: TFoo);
    class operator Finalize(var aFoo: TFoo);
  public
    F: Integer;
  end;
  TFooArray = array of TFoo;
class operator TFoo.Initialize(var aFoo: TFoo);
begin
  WriteLn;
  WriteLn('TFoo.Initialize');
  aFoo.F := 1;
end;
class operator TFoo.Finalize(var aFoo: TFoo);
begin
  aFoo.F := 3;
  WriteLn('TFoo.Finalize');
  WriteLn;
end;
procedure Test;
var
  Foos: TFooArray;
begin
  SetLength(Foos, 5);
  WriteLn('Foos[0].F = ', Foos[0].F);
  WriteLn('Foos[1].F = ', Foos[1].F);
  WriteLn;
end;
begin
  Test;
end.

Outputs:

Foos[0].F = 0
Foos[1].F = 0

TFoo.Finalize

TFoo.Finalize

TFoo.Finalize

TFoo.Finalize

TFoo.Finalize

Notice:

TFoo.Initialize is never invoked.

Reply by email

Maciej Izak
to Anthony Walter: I did a build using your revision 33381. Compilation with "make all" worked with fpc…

2016-03-29 19:36 GMT+02:00 Anthony Walter :

TFoo.Initialize is never invoked.

Thanks for report. Fixed at revision: 33384.

Important note:

Copy(Foos) operation for dyn arrays might be a little confusing (since there is no operator "Copy"). Operator "Finalize" can be called more times than "Initialize" (that will be true even with Copy operator).

Best regards, Maciej Izak

Reply by email

Maciej Izak
to Anthony Walter: Should I file mantis bug reports for personal branches such as this or is mailing list…

2016-03-30 0:06 GMT+02:00 Anthony Walter :

Should I file mantis bug reports for personal branches such as this or is mailing list notification sufficient?

Mailing list notification looks good for now.

Btw. I don't have developer status on FPC mantis part (only for Lazarus part for Sparta purpose), mantis bug report has no sense in my situation. AFAIK is impossible to assign anything to reporter :)

Best regards, Maciej Izak

Reply by email

Anthony Walter
to Maciej Izak

I put up a testing page for your modifications here:

http://www.getlazarus.org/language/smart/

The tests are rather simple and sloppy, but so far the few tests I've written have passed using revision 33384. If anyone wants to add/change the test source code you can use the edit feature on that page. I will post your test/results when I run them myself.

A note about keyboard shortcuts for the editor on my website.

Select editor text and pressing [Ctrl >] or [Ctrl <] alternates your selection through headings and paragraphs of differing sizes.

Putting backticks [`] around text allows you to insert syntax highlighted source code. Selecting from backtick to backtick and pressing [Ctrl Enter] converts the selection to syntax highlighted source code, while selecting text with backticks inside is converted to inline snippets when you press [Ctrl Enter]

You and I can see your edits, but I need to merge them before everyone can see them.

Reply by email

Maciej Izak
to Anthony Walter

2016-03-30 7:49 GMT+02:00 Anthony Walter :

Show quoted text 9 lines
I put up a testing page for your modifications here: http://www.getlazarus.org/language/smart/ The tests are rather simple and sloppy, but so far the few tests I've written have passed using revision 33384. If anyone wants to add/change the test source code you can use the edit feature on that page. I will post your test/results when I run them myself.

Thanks for nice page :)

Note that in tests directory exists set of tests for management operators (and for related RTTI):

toperator89.pp - simple syntax test for new operators { %NORUN } toperator90.pp - management operators for global variables, local variables, fields in classes, New and Dispose, InitializeArray and FinalizeArray, Initialize and Finalize
toperator91.pp - similar to toperator90 but for record without managed field toperator92.pp - test for fields in classes with inheritance toperator93.pp - test for fields in objects with inheritance as global/local variable + related objects usages for New, Dispose, InitializeArray,
FinalizeArray, Initialize, Finalize.
toperator94.pp - simple syntax test for expected error { %FAIL } trtti10.pp - record RTTI pointer to init table

new in r33384:

toperator95.pp - dynamic array test for records and objects

Best regards, Maciej Izak

Reply by email