Smart Pointers

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Smart Pointers

Mazo Winst
Hello list,

I don't know if here is the correct place to make this question.

I read that mails about implementation of management operators and smart pointers.

1 - These features are expected to be available in which version?

2 - Are these features an introduction to Arc objects?

Best regards
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Smart Pointers

Sven Barth-2

Am 09.05.2016 19:50 schrieb "Mazo Winst" <[hidden email]>:
>
> Hello list,
>
> I don't know if here is the correct place to make this question.
>
> I read that mails about implementation of management operators and smart pointers.
>
> 1 - These features are expected to be available in which version?

They are currently worked on in a branch. Once they are merged they would be in trunk which currently is 3.1.1. At the earliest the feature would be on 3.2.0.

> 2 - Are these features an introduction to Arc objects?

In the case of that implementation the instances themselves wouldn't be reference counted, but the containers they're passed around in would be (like C++ smart pointers).

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Smart Pointers

Maciej Izak
In reply to this post by Mazo Winst
2016-05-09 19:50 GMT+02:00 Mazo Winst <[hidden email]>:
I read that mails about implementation of management operators and smart pointers.

1 - These features are expected to be available in which version?

The feature is ready and works almost perfectly but I need more time to tests. It brings also nullable types (nullable type is kind of smart pointer) and it brings new kind of type helpers for example for dynamic arrays, interfaces and in practice for any other types (side effect of new syntax ;) ).

IMO there is very weak chance for merging into official FPC trunk. FPC core team has strong opposition to new features like in Oxygene or Delphi Nextgen/ARC. "Smart pointers idea" is main point of my further work, plans are much more deeper.

Because of that I've decide to fork (ofc I will try to track trunk as long as possible - hopefully always). All will be available together with Generics.Collections as part of RTL at:

-> https://github.com/dathox/freepascal (source) + maybe http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/maciej/
-> http://objectpascal.space and http://freesparta.com (binary + new site - in progress)

I think that summer is a realistic date to put all together. Above links are invalid for now.
 
2 - Are these features an introduction to Arc objects?

Yes, is possible to create {$MODE DELPHINEXTGEN} and these features are an introduction to ARC objects (with full backward compatibility and with great compatibility with Delphi Nextgen, also will be possible to link ARC modules with "non-ARC" modules and vice-versa).

--
Best regards,
Maciej Izak

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Smart Pointers

Florian Klämpfl
Am 09.05.2016 um 21:40 schrieb Maciej Izak:

> 2016-05-09 19:50 GMT+02:00 Mazo Winst <[hidden email] <mailto:[hidden email]>>:
>
>     I read that mails about implementation of management operators and smart pointers.
>
>     1 - These features are expected to be available in which version?
>
>
> The feature is ready and works almost perfectly but I need more time to tests. It brings also
> nullable types (nullable type is kind of smart pointer) and it brings new kind of type helpers for
> example for dynamic arrays, interfaces and in practice for any other types (side effect of new
> syntax ;) ).
>
> IMO there is very weak chance for merging into official FPC trunk.

Who said that? We discussed the syntax etc. and at least I see good changes to integrate it in trunk
as soon as it is ready. Neither Sven nor me would discuss a feature if we are in doubt that it will
make it in trunk.

> FPC core team has strong
> opposition to new features like in Oxygene or Delphi Nextgen/ARC.

It is more a matter of doing it properly. It is more an opposition against quickly hacked together
stuff without proper testing etc. I am pretty sure that we get ARC soon or later in trunk, if
somebody shows enough dedication :)

After all, FPC tries to support as much as possible pascal dialects in OSS compiler. But this does
not mean, we are supporting everybody's pet dialect ;)

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Smart Pointers

Sven Barth-2
On 09.05.2016 22:11, Florian Klämpfl wrote:

> Am 09.05.2016 um 21:40 schrieb Maciej Izak:
>> 2016-05-09 19:50 GMT+02:00 Mazo Winst <[hidden email] <mailto:[hidden email]>>:
>>
>>     I read that mails about implementation of management operators and smart pointers.
>>
>>     1 - These features are expected to be available in which version?
>>
>>
>> The feature is ready and works almost perfectly but I need more time to tests. It brings also
>> nullable types (nullable type is kind of smart pointer) and it brings new kind of type helpers for
>> example for dynamic arrays, interfaces and in practice for any other types (side effect of new
>> syntax ;) ).
>>
>> IMO there is very weak chance for merging into official FPC trunk.
>
> Who said that? We discussed the syntax etc. and at least I see good changes to integrate it in trunk
> as soon as it is ready. Neither Sven nor me would discuss a feature if we are in doubt that it will
> make it in trunk.

I agree with Florian regarding the management operators. They will
probably be merged.
What I'm not in favor of however is overloading of "." and such (but you
haven't put that up for discussion yet, thus for now I'm not considering
it part of your branch anyway).

Regards,
Sven

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Smart Pointers

Maciej Izak
In reply to this post by Florian Klämpfl
2016-05-09 22:11 GMT+02:00 Florian Klämpfl <[hidden email]>:
Who said that? We discussed the syntax etc. and at least I see good changes to integrate it in trunk
as soon as it is ready. Neither Sven nor me would discuss a feature if we are in doubt that it will
make it in trunk.

I have feeling that Sven has negative attitude to my work (like in thread "Initialize/Finalize management operators and Default intrinsic"). I have also bad experience with Generics.Collections (submitted 2014-12-23)... which should be part of RTL for a long time... For outsider like me, is almost impossible to contribute changes to trunk. I think it will take few years before someone checks branch. Sven is the only person in core team who is working on new things, additionally he has a lot of things in TODO list so IMO merge will never happen, the queue is long: packages branch, attributes branch, rtti for interfaces branch, anonymous methods branch...
 
It is more a matter of doing it properly. It is more an opposition against quickly hacked together
stuff without proper testing etc. I am pretty sure that we get ARC soon or later in trunk, if
somebody shows enough dedication :)

After all, FPC tries to support as much as possible pascal dialects in OSS compiler. But this does
not mean, we are supporting everybody's pet dialect ;)

Oxygene in FPC core team opinion is not Pascal language. So my work for Oxygene compatibility is "outlawed" by definition. "Smart pointer" related syntax is step into Oxygene mode so dedication might be not enough :P. 

Seems like my own little FPC fork + small website to host binaries, according to current situation is rational step, especially I need to merge few other branches together... I can't wait whole life.

--
Best regards,
Maciej Izak

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Smart Pointers

Maciej Izak
In reply to this post by Sven Barth-2
2016-05-09 23:23 GMT+02:00 Sven Barth <[hidden email]>:
I agree with Florian regarding the management operators. They will
probably be merged.

probably = wait few years + rather no 

;)
 
What I'm not in favor of however is overloading of "." and such (but you
haven't put that up for discussion yet, thus for now I'm not considering
it part of your branch anyway).

New modifier to achieve overloading of ".", "@", "@@", "^" is not committed yet. There is no discussion yet because my research is in progress. I have few working versions I need to decide which one is the best. The new syntax/compiler behavior is developed for many new elements (nullable types, smart pointers, arc objects) and must be perfect.

--
Best regards,
Maciej Izak

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Smart Pointers

Anthony Walter-3
In reply to this post by Maciej Izak
Maciej,

Hey I'm all for your improvements. Good work, keep it up, and I actually appreciate it. If you want, I can write up an overview of your improvements at getlazarus.org and provide precompiled versions for testings/use on all platforms (win, mac, linux, raspbian)..

I asked Sven the other day about type helpers on generic array types and there was no hint in his response that it was on anyone's radar. I think you mentioned you have type helpers working on arrays then that's great. Specifically I was asking about:

type
  TArray<T> = array of T;

  TArrayHelper<T> = record helper for TArray<T>
    // Extensions here like Add(), Remove(), Sort() and so on
  end;

Which probably isn't something you or anyone else has implemented yet because of the generic factor. Actually support for type helpers for any generic types (classes, records, interfaces, arrays) would be great, especially when combined with the work you've done on record initialization and finalization.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Smart Pointers

Maciej Izak
2016-05-10 11:26 GMT+02:00 Anthony Walter <[hidden email]>:
Hey I'm all for your improvements. Good work, keep it up, and I actually appreciate it. If you want, I can write up an overview of your improvements at getlazarus.org and provide precompiled versions for testings/use on all platforms (win, mac, linux, raspbian)..
 
glad to hear that ^^. I think is good idea to wait for smart pointers. I will let you know in PM.

Which probably isn't something you or anyone else has implemented yet because of the generic factor. Actually support for type helpers for any generic types (classes, records, interfaces, arrays) would be great, especially when combined with the work you've done on record initialization and finalization.

With my private "not committed yet" version of compiler I can compile code like that (I think the good name for below construction is "specialized helper" or "forced helper" or just "record with default field"):

{ be aware that code below is experimental }
type
  TManagedArray<T> = record
    Instance: TArray<T> default;
   
    function Add(A: T): Integer; 
  end;
 
function TManagedArray<T>.Add(A: T): Integer;
begin
  Result := Length(Instance);
  SetLength(Instance, Succ(Result));
  Instance[Result] := A;
end;   
 
procedure foo(A: TArray<Integer>);
begin
  WriteLn(a[0]); // 10
end; 
 
var
  a: TManagedArray<Integer>;
  pa: ^TArray<Integer>;
  i: Integer;
begin
  a.Add(10);
  i := a[0]; // compiler magic, equivalent of: i := a.Instance[0];
  foo(a); // compiler magic, equivalent of: foo(a.Instance);
  pa := @a; // compiler magic, equivalent of: pa := @a.Instance;
  WriteLn(pa^[0], ' = ', i); // 10 = 10
end.

--
Best regards,
Maciej Izak

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Smart Pointers

Florian Klämpfl
In reply to this post by Maciej Izak
Am 10.05.2016 um 10:25 schrieb Maciej Izak:
> 2016-05-09 23:23 GMT+02:00 Sven Barth <[hidden email]
> <mailto:[hidden email]>>:
>
>     I agree with Florian regarding the management operators. They will
>     probably be merged.
>
>
> probably = wait few years + rather no

probably: depends on you if it gets into agood shape :)

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Smart Pointers

Florian Klämpfl
In reply to this post by Maciej Izak
Am 10.05.2016 um 10:07 schrieb Maciej Izak:

> 2016-05-09 22:11 GMT+02:00 Florian Klämpfl <[hidden email] <mailto:[hidden email]>>:
>
>     Who said that? We discussed the syntax etc. and at least I see good changes to integrate it in trunk
>     as soon as it is ready. Neither Sven nor me would discuss a feature if we are in doubt that it will
>     make it in trunk.
>
>
> I have feeling that Sven has negative attitude to my work (like in thread "Initialize/Finalize
> management operators and Default intrinsic"). I have also bad experience with Generics.Collections
> (submitted 2014-12-23)... which should be part of RTL for a long time...

Aren't there several bug reports open which must be fixed first?

> For outsider like me, is
> almost impossible to contribute changes to trunk. I think it will take few years before someone
> checks branch. Sven is the only person in core team who is working on new things,

Well, the others are all busy with cleaning up and fixing old stuff. And still, the bug count
increases. This is also one of the reasons why probably nobody is really happy to merge another
branch with new features.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Smart Pointers

Anthony Walter-3
In reply to this post by Maciej Izak
Maciej,

From your example code, the usage looks exactly like what I'd want. One question though. Would the magic code also work with var and out arguments?

That is with (note these functions are generic):

procedure Foo1<T>(A: TArray<T>);
procedure Foo2<T>(var A: TArray<T>);
procedure Foo3<T>(out A: TArray<T>);

Where each can be called with a TManagedArray<T> as the "A" argument without qualifying the Instance field?

var
  A: TManagedArray<Integer>;
begin
  Foo3(A);
  Foo2(A);
  Foo1(A);
end;

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Smart Pointers

Maciej Izak
In reply to this post by Florian Klämpfl
2016-05-10 21:18 GMT+02:00 Florian Klämpfl <[hidden email]>:
Aren't there several bug reports open which must be fixed first?

There is one critical bug related to class var and generics, but as Sven said it need wait to "packages branch"...

With other bugs we can +/- live. ;)

btw I've started to fix few of them...

--
Best regards,
Maciej Izak

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Smart Pointers

Maciej Izak
In reply to this post by Anthony Walter-3
2016-05-10 22:33 GMT+02:00 Anthony Walter <[hidden email]>:
From your example code, the usage looks exactly like what I'd want. One question though. Would the magic code also work with var and out arguments?

Yes.
 
That is with (note these functions are generic):

procedure Foo1<T>(A: TArray<T>);
procedure Foo2<T>(var A: TArray<T>);
procedure Foo3<T>(out A: TArray<T>);

Where each can be called with a TManagedArray<T> as the "A" argument without qualifying the Instance field?

Yes, anyway example is buggy because we don't have "type inference" for generic methods/functions like in Java (which is on my TODO list), but is possible to compile and run example like this:
 
var
  a: TManagedArray<Integer>;
begin
  Foo1<Integer>(a);
  Foo2<Integer>(a);
  Foo3<Integer>(a);

--
Best regards,
Maciej Izak

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Smart Pointers

Sven Barth-2

Am 10.05.2016 23:06 schrieb "Maciej Izak" <[hidden email]>:
>>
>> That is with (note these functions are generic):
>>
>> procedure Foo1<T>(A: TArray<T>);
>> procedure Foo2<T>(var A: TArray<T>);
>> procedure Foo3<T>(out A: TArray<T>);
>>
>> Where each can be called with a TManagedArray<T> as the "A" argument without qualifying the Instance field?
>
>
> Yes, anyway example is buggy because we don't have "type inference" for generic methods/functions like in Java (which is on my TODO list), but is possible to compile and run example like this:

Type inference is another topic you won't find many friends for...

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Smart Pointers

Sven Barth-2
In reply to this post by Florian Klämpfl

Am 10.05.2016 21:18 schrieb "Florian Klämpfl" <[hidden email]>:
>
> Am 10.05.2016 um 10:07 schrieb Maciej Izak:
> > 2016-05-09 22:11 GMT+02:00 Florian Klämpfl <[hidden email] <mailto:[hidden email]>>:
> >
> >     Who said that? We discussed the syntax etc. and at least I see good changes to integrate it in trunk
> >     as soon as it is ready. Neither Sven nor me would discuss a feature if we are in doubt that it will
> >     make it in trunk.
> >
> >
> > I have feeling that Sven has negative attitude to my work (like in thread "Initialize/Finalize
> > management operators and Default intrinsic"). I have also bad experience with Generics.Collections
> > (submitted 2014-12-23)... which should be part of RTL for a long time...
>
> Aren't there several bug reports open which must be fixed first?

Those bugs mostly have workarounds. The main point was the usage of manual interfaces, but I'm mostly at peace with that by now (or more like a ceasefire ;) ). Scrolling through the code I saw one other thing. I'll have to check that again and after that the code cam probably be integrated with the main problem being the location, e.g. rtl-generics or fcl-generics or whatever...

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Smart Pointers

Florian Klämpfl
Am 11. Mai 2016 12:06:07 vorm. schrieb Sven Barth
<[hidden email]>:

> the main problem being the location, e.g. rtl-generics or fcl-generics or
> whatever...

If it depends on classes: fcl-generic, else RTL-generic.

>
> Regards,
> Sven
>
>
>
> ----------
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Smart Pointers

Marco van de Voort
In our previous episode, Florian Kl?mpfl said:
> > whatever...
>
> If it depends on classes: fcl-generic, else RTL-generic.

Some rtl-objpas units use classes, like fmtbcd.

If you don't use fcl-base I would make it RTL, so we can use it in fcl-base
if needed :-)
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Smart Pointers

Maciej Izak


2016-05-11 10:22 GMT+02:00 Marco van de Voort <[hidden email]>:
Some rtl-objpas units use classes, like fmtbcd.

If you don't use fcl-base I would make it RTL, so we can use it in fcl-base
if needed :-)

Library is low level without using anything outside RTL, IMO it should be part of RTL like in Delphi. 

Note that I need the library as part of RTL not as package. Generics.* contains _LookupVtableInfo/_LookupVtableInfoEx and few other things which are used for my next compiler work...

Generics.* as package will complicate all my plans -,- . If it can't be part of RTL, more comfortable for me is excluding whole library from FPC (easier maintenance of FreePascal fork...)

--
Best regards,
Maciej Izak

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Smart Pointers

Michael Van Canneyt


On Wed, 11 May 2016, Maciej Izak wrote:

> 2016-05-11 10:22 GMT+02:00 Marco van de Voort <[hidden email]>:
>
>> Some rtl-objpas units use classes, like fmtbcd.
>>
>> If you don't use fcl-base I would make it RTL, so we can use it in fcl-base
>> if needed :-)
>
>
> Library is low level without using anything outside RTL, IMO it should be
> part of RTL like in Delphi.
>
> Note that I need the library as part of RTL not as package. Generics.*
> contains _LookupVtableInfo/_LookupVtableInfoEx and few other things which
> are used for my next compiler work...

Anything the compiler needs *must* be in the system unit. The compiler
should only assume the system unit, possibly objpas or macpas or so.

All the rest should remain out of the RTL, which should be as small as
possible. So rtl-generics is your best bet. Even the classes unit is better
outside the rtl, but I think Marco is reluctant to remove it.

I have remarked on this before: this tight dependency you are creating
is very worrying.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12