<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    I suggest doing one thing at a time. ARC class first, complex
    delegates capturing local context later<br>
    <br>
    In my opinion having ARC class would be a great advantage. As far as
    I know this feature was proposed many times in the past. Developers
    have been asking for it for years. It just feels right because in
    FPC we already have ARC-interfaces, ARC-dynamic arrays and
    ARC-strings. And the Variant type, which is also ARC. In my opinion,
    implementing ARC for class type is both easier to implement and more
    important than anonymous methods. Anonymous methods save you typing,
    but that's it. ARC objects not only save you typing, but they also
    save you from many mistakes you can make while inserting .AddRef and
    .Release calls everywhere by hand.<br>
    <br>
    I am not even sure if weak reference feature is necessary. We don't
    have weak references for COM interfaces, and it still works so far.
    Well, of course, if we had weak references as well, it would be a
    useful feature perhaps, but considering just <b>how many times</b>
    ARC class was proposed before, I lost hope that it will be ever
    implemented at all quite a while ago <br>
    <br>
    Some people thing that GC is better than ARC. However ARC has at
    least one major advantage: unlike GC, it does not cause stop of the
    world. Complex Java programs often suffer from stop of the world
    because it may take considerable amount of time, and the application
    can't do anything during that time. For example, it can't respond to
    HTTP requests. If it is a game, even 200 ms freeze would be
    annoying. Well, you got the idea. ARC does not have to stop threads
    to collect garbage.<br>
    <br>
    <div class="moz-cite-prefix">22.09.2014 22:54, Boian Mitov:<br>
    </div>
    <blockquote cite="mid:D40D109CC92840B78A4D3516EADF46B7@mpc1"
      type="cite">Here is example from our implementation:
      <br>
      <br>
      for AIndex := 0 to Length( AList ) - 1 do
      <br>
       AExecutionTask.Add(
      <br>
           FExecutor.Execute(
      <br>
               TDelegate.Capture<Integer>( AIndex,
      <br>
                   procedure( ALocalIndex : Integer )
      <br>
                   begin
      <br>
                     Sleep( 1000 ); // Simulate thread busy doing time
      consuming task
      <br>
                     AList[ ALocalIndex ] := ALocalIndex * 2;
      <br>
                   end
      <br>
                 )
      <br>
             )
      <br>
         );
      <br>
      <br>
      AExecutionTask.WaitFor();
      <br>
      <br>
      <br>
      Notice the need for TDelegate :-( This is due to the fact that
      Delphi unlike C++11 does not allow the option to capture local
      context my value, and captures everything by reference :-( .
      <br>
      This is something to be considered when implementing anonymous
      methods or lambdas in FPC, especially for multithreading and
      parallel execution.
      <br>
      <br>
      With best regards,
      <br>
      Boian Mitov
      <br>
      <br>
      -------------------------------------------------------
      <br>
      Mitov Software
      <br>
      <a class="moz-txt-link-abbreviated" href="http://www.mitov.com">www.mitov.com</a>
      <br>
      -------------------------------------------------------
      <br>
      -----Original Message----- From: Michael Schnell
      <br>
      Sent: Monday, September 22, 2014 5:58 AM
      <br>
      To: <a class="moz-txt-link-abbreviated" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>
      <br>
      Subject: Re: [fpc-devel] Suggestion: reference counted objects
      <br>
      <br>
      On 09/22/2014 02:51 PM, Sven Barth wrote:
      <br>
      <blockquote type="cite">
        <br>
        Then you should also not use interfaces, strings and arrays,
        because they use the same mechanisms.
        <br>
        <br>
      </blockquote>
      Yep. The advanced developer should know what he is doing.
      <br>
      <blockquote type="cite">
        <br>
        What us confusing there?
        <br>
        <br>
      </blockquote>
      Of course I do know the pitfalls.
      <br>
      <br>
      If fpc would provide a syntax for "parallel loop" and "future
      variables"
      <br>
      e.g. similar to what Prism offers, even more inexperienced users
      will be
      <br>
      inclined to use (invisible) threads. I suppose it's not possible
      to
      <br>
      avoid the "confusion" that is introduced by this, but it should be
      <br>
      limited as much as possible. (No idea how.)
      <br>
      <br>
      -Michael
      <br>
      _______________________________________________
      <br>
      fpc-devel maillist  -  <a class="moz-txt-link-abbreviated" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>
      <br>
      <a class="moz-txt-link-freetext" href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a> <br>
      _______________________________________________
      <br>
      fpc-devel maillist  -  <a class="moz-txt-link-abbreviated" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>
      <br>
      <a class="moz-txt-link-freetext" href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>
      <br>
    </blockquote>
    <br>
  </body>
</html>