Rekursive Funktionen iterativ ausführen

    • VB.NET
    • .NET (FX) 4.0

      Rekursive Funktionen iterativ ausführen

      Im Bezug auf diesen Thread: Iterative und rekursive Algorithmen

      Ich hab mir mal überlegt, wie man rekursive Funktionen so ausführen kann, dass auch bei beliebig großen Rekursionstiefen der Stapel nicht beliebig groß wird. Das Problem ist nämlich, dass bei rekursiven Funktionen relativ schnell ein StackOverflow auftreten kann (und damit ist nicht die Website gemeint ;) ).

      Weil das hier etwas länger geworden ist, als ich anfangs erwartet habe, habe ich es etwas gegliedert:
      • Problemstellung
      • Lösungsansatz
      • Implementierung
      • Fibonacci
      • Ackermann
      • Yield in C#
      • Hausaufgabe
      • Anhang


      Problemstellung

      Die wohl bekannteste, rekursive Funktion ist die Fibonacci-Funktion, welche so definiert ist (wir gehen davon aus, dass n immer >= 0 ist):

      VB.NET-Quellcode

      1. Function RecursiveFibonacci(n As Integer) As Integer
      2. Select Case n
      3. Case 0
      4. Return 0
      5. Case 1
      6. Return 1
      7. Case Else
      8. Return RecursiveFibonacci(n - 1) + RecursiveFibonacci(n - 2)
      9. End Select
      10. End Function

      Hier ist die Anzahl an benötigten StackFrames im Regelfall n. Also RecursiveFibonacci(30) = 832040 und es werden 30 StackFrames benötigt.

      ErfinderDesRades hat in diesem Post gezeigt, wie die Fibonacci-Funktion iterativ implementiert werden kann.

      Mit der Ackermann-Funktion geht das aber nicht mehr ganz so einfach. Die ist nämlich so definiert (die Argumente sind ebenfalls >= 0):

      VB.NET-Quellcode

      1. Function RecursiveAckermann(m As Integer, n As Integer) As Integer
      2. If m = 0 Then
      3. Return n + 1
      4. End If
      5. If n = 0 Then
      6. Return RecursiveAckermann(m - 1, 1)
      7. End If
      8. Return RecursiveAckermann(m - 1, RecursiveAckermann(m, n - 1))
      9. End Function

      Also wenn m und n nicht 0 sind muss man die Funktion rekursiv aufrufen, nur um ein Argument zu bekommen, mit dem man die Funktion nochmal rekursiv aufruft. Die Anzahl an StackFrames explodiert förmlich:

      Quellcode

      1. Für n = 0, 1, 2, 3, 4, 5, 6
      2. Bei m = 0: Anzahl an StackFrames = 1, 1, 1, 1, 1, 1, 1
      3. Bei m = 1: Anzahl an StackFrames = 2, 3, 4, 5, 6, 7, 8
      4. Bei m = 2: Anzahl an StackFrames = 4, 6, 8, 10, 12, 14, 16
      5. Bei m = 3: Anzahl an StackFrames = 7, 15, 31, 63, 127, 255, 511
      6. Bei m = 4: Anzahl an StackFrames = 16, >8596, ?, ?, ?, ?, ?
      7. Bei m = 5: Anzahl an StackFrames = >8593, ?, ?, ?, ?, ?, ?

      RecursiveAckermann(4, 1) und RecursiveAckermann(5, 0) lösen bei mir nach ca. 8600 StackFrames eine StackOverflowException aus. Abgesehen davon, dass es eine Weile dauert, das alles zu berechnen: Wenn möglich möchte man StackOverflows verhindern.


      Lösungsansatz

      Ich habe da an folgendes Konzept gedacht:
      Es gibt eine Liste von auszuführenden Tasks.
      Ein Task repräsentiert einen Rekursions-Aufruf. Also ein Task stellt alle Informationen bereit, die die Funktion benötigt, wie z.B. Argumente.
      Ein Task kann außerdem "Wartend" oder "Abgeschlossen" sein. Wenn ein Task abgeschlossen wird, wird er aus der Liste von auszuführenden Tasks entfernt.
      Ein Task kann unter-Tasks haben, von denen er abhängt. Ein Task kann ausgeführt werden, wenn alle unter-Tasks abgeschlossen sind (also auch, wenn keine unter-Tasks vorhanden sind). Während ein Task ausgeführt wird, kann er unter-Tasks einreihen. Wenn unter-Tasks eingereiht werden, muss der aktuelle Task abgebrochen werden, damit zuerst die unter-Tasks abgeschlossen werden können.

      Als Beispiel soll Fibonacci(4) berechnet werden:
      Viele Bilder und Text

      Zu Beginn wird der allererste Task eingereiht. Fibonacci(4) soll berechnet werden.

      Dann beginnt der eigentliche Ablauf. Die Liste wird immer von rechts nach links durchlaufen. Da nur ein Task in der Liste ist, wird mit diesem begonnen. Da alle unter-Tasks abgeschlossen sind (bzw. in diesem Fall keine unter-Tasks vorhanden sind), wird der Task ausgeführt. Fibonacci(4) lässt sich aber nicht trivial berechnen. Stattdessen werden Fibonacci(3) und Fibonacci(2) eingereiht und der aktuelle Task abgebrochen.

      Dann wird mit dem nächsten Task weitergemacht. Da der aktuelle ganz links in der Liste ist, wird wieder rechts begonnen. Da Fibonacci(2) auch nicht trivial berechnet werden kann, werden wieder 2 weitere Tasks (Fibonacci(1) und Fibonacci(0)) eingereiht.

      Fibonacci(3) kann ebenfalls nicht trivial berechnet werden. Fibonacci(2) und Fibonacci(1) werden eingereiht.

      Der nächste Task kann nicht ausgeführt werden, weil er nicht abgeschlossene unter-Tasks hat, was logisch ist, denn er ist ja der allererste Task, der überhaupt eingereiht wurde.

      Also wieder ganz nach rechts. Dieser Task kann ausgeführt werden. Da Fibonacci(1) trivial ist, wird das Ergebnis direkt berechnet, ohne unter-Tasks einzureihen.

      Der nächste Task kann ebenfalls ausgeführt werden, aber es müssen wieder Tasks eingereiht werden (Fibonacci(1) und Fibonacci(0)).

      Die nächsten beiden Tasks sind wieder trivial.

      Der nächste Task wurde bereits einmal ausgeführt, ist aber noch nicht abgeschlossen. Da alle unter-Tasks abgeschlossen sind, wird er erneut ausgeführt und da die Ergebnisse von Fibonacci(1) und Fibonacci(0) jetzt berechnet sind, wird auch dieser Task abgeschlossen.

      Bei den nächsten beiden Tasks sind nicht alle unter-Tasks abgeschlossen, deswegen werden sie noch nicht ausgeführt.

      Und wieder nach rechts. Die nächsten Beiden Tasks sind wieder trivial.

      Und bei den nächsten beiden Tasks werden wieder Ergebnisse abgeschlossener Tasks zusammengerechnet.

      Und damit bleibt noch der letzte (bzw. erste) Task übrig. Da alle unter-Task abgeschlossen sind, kann auch dieser ausgeführt und schlussendlich abgeschlossen werden.

      Das Ergebnis des letzten Tasks ist dann das Ergebnis, das man ursprünglich haben wollte.


      Wie muss nun die Fibonacci-Funktion aussehen, um mit diesem System zu funktionieren?
      Pseudocode-mäßig würde das inetwa so aussehen:

      Quellcode

      1. 'Fibonacci-Funktion:
      2. 'Wenn das der erste Aufruf ist
      3. 'Wenn n = 0
      4. 'Ergebnis = 0
      5. 'Angeben, dass der Task abgeschlossen ist
      6. Return
      7. 'Wenn n = 1
      8. 'Ergebnis = 1
      9. 'Angeben, dass der Task abgeschlossen ist
      10. Return
      11. 'Ansonsten
      12. 'Task einreihen mit n - 1
      13. 'Task einreihen mit n - 2
      14. 'Angeben, dass der Task nicht abgeschlossen ist
      15. Return
      16. 'Ansonsten
      17. 'Ergebnis = (Ergebnis von Task mit n - 1) + (Ergebnis von Task mit n - 2)
      18. 'Angeben, dass der Task abgeschlossen ist
      19. Return

      Also es muss irgendwie festgestellt werden, ob die Funktion schon mal ausgeführt wurde. Und es muss irgendwie auf andere Tasks verweisen werden. Wie oben beschrieben muss ein Task alle Informationen bereitstellen, die für die Funktion notwendig sind. Darunter sind Argumente, Ergebnis und andere Dinge, die je nach Anwendungsfall unterschiedlich sein können.


      Implementierung

      Generica!

      Die Funktion kann dann diese Signatur haben:

      VB.NET-Quellcode

      1. Public Delegate Sub TaskMethod(Of TInput, TOutput, TState)(Context As TaskContext(Of TInput, TOutput, TState))

      Der Kontext mit den Informationen wird als Parameter mitgegeben. Man beachte, dass die Funktion nichts mehr zurückgibt, sondern das Ergebnis im Kontext ablegt.
      Der Kontext sieht so aus:

      VB.NET-Quellcode

      1. Public Class TaskContext(Of TInput, TOutput, TState)
      3. Public ReadOnly Property ReadyToExecute As Boolean
      4. Get
      5. Return _DependingOn.All(Function(i) i._IsFinished)
      6. End Get
      7. End Property
      9. Dim _IsFinished As Boolean
      10. Public ReadOnly Property IsFinished As Boolean
      11. Get
      12. Return _IsFinished
      13. End Get
      14. End Property
      16. Dim _Input As TInput
      17. Public ReadOnly Property Input As TInput
      18. Get
      19. Return _Input
      20. End Get
      21. End Property
      23. Dim _Result As TOutput = Nothing
      24. Public ReadOnly Property Result As TOutput
      25. Get
      26. Return _Result
      27. End Get
      28. End Property
      30. Public Property State As TState
      32. Dim Executor As TaskExecutor(Of TInput, TOutput, TState)
      33. Dim DependingOn As New List(Of TaskContext(Of TInput, TOutput, TState))
      35. Friend Sub New(NewExecutor As TaskExecutor(Of TInput, TOutput, TState), NewInput As TInput, NewState As TState)
      36. Executor = NewExecutor
      37. _Input = NewInput
      38. _State = NewState
      39. End Sub
      41. Public Function QueueTask(Input As TInput) As TaskContext(Of TInput, TOutput, TState)
      42. Dim Result = Executor.QueueTask(Input)
      43. DependingOn.Add(Result)
      44. Return Result
      45. End Function
      47. Public Sub Finish(Result As TOutput)
      48. _IsFinished = True
      49. _Result = Result
      50. End Sub
      52. End Class

      Alles ziemlich selbsterklärend, bis auf die TaskExecutor-Klasse, aber die kommt gleich.
      Es gibt eine Liste von Tasks, die abgeschlossen sein müssen, bevor dieser Task ausgeführt werden kann und eine Property, um genau das unkompliziert abzufragen. Dann noch Properties für Parameter, Ergebnis, Zustand und ob der Task abgeschlossen ist. Die QueueTask-Funktion reiht einen neuen Task ein und fügt diesen der oben genannten Liste hinzu. Die Finish-Methode stellt klar, dass der Task abgeschlossen ist. Hier wird auch das Ergebnis festgelegt.

      Im TaskExecutor ist dann die eigentliche Logik verpackt, die die einzelnen Tasks in der richtigen Reihenfolge ausführt.

      VB.NET-Quellcode

      1. Public Class TaskExecutor(Of TInput, TOutput, TState)
      3. Dim TaskMethod As TaskMethod(Of TInput, TOutput, TState)
      4. Dim InitialStateGenerator As Func(Of TState)
      5. Dim RunningTasks As New List(Of TaskContext(Of TInput, TOutput, TState))
      7. Public Sub New(NewTaskMethod As TaskMethod(Of TInput, TOutput, TState), NewInitialStateGenerator As Func(Of TState))
      8. TaskMethod = NewTaskMethod
      9. InitialStateGenerator = NewInitialStateGenerator
      10. End Sub
      12. Public Function Execute(Input As TInput) As TOutput
      13. Dim InitialTask = QueueTask(Input)
      14. Do
      15. For i = RunningTasks.Count - 1 To 0 Step -1
      16. Dim CurrentTask = RunningTasks(i)
      17. If CurrentTask.ReadyToExecute Then
      18. TaskMethod(CurrentTask)
      19. If CurrentTask.IsFinished Then
      20. RunningTasks.RemoveAt(i)
      21. End If
      22. End If
      23. Next
      24. Loop Until RunningTasks.Count = 0
      25. Return InitialTask.Result
      26. End Function
      28. Friend Function QueueTask(Input As TInput) As TaskContext(Of TInput, TOutput, TState)
      29. Dim Result As New TaskContext(Of TInput, TOutput, TState)(Me, Input, InitialStateGenerator())
      30. RunningTasks.Add(Result)
      31. Return Result
      32. End Function
      34. End Class

      TaskMethod ist ein Delegat auf die Funktion, die ausgeführt werden soll. RunningTasks ist die weiter oben beschriebene Liste von Tasks, die auszuführen ist.
      InitialStateGenerator ist ein Delegat auf eine Funktion, die eine Instanz von TState zurückgibt. Man kann nicht einfach eine TState-Instanz im Konstruktor angebe, die man bei allen Tasks verwendet. Denn die Tasks würden sich in die Quere kommen, weil sie alle die gleiche Instanz verwenden. Natürlich wäre es möglich, TState As New zu deklarieren, um über einen parameterlosen Konstruktor Instanzen erzeugen zu können, aber dadurch verliert man etwas Kontrolle über den Startzustand. Kann natürlich abgeändert werden.
      Die QueueTask-Funktion (die von der TaskContext.QueueTask-Funktion verwendet wird) erstellt einen neuen Task mit den angegebenen Argumenten, holt sich einen Anfangszustand vom InitialStateGenerator-Delegaten und reiht den Task ein.
      Und in der Execute-Funktion passiert die Magic. Ist auch nicht sonderlich kompliziert und ich denke, der Code ist ziemlich selbsterklärend. Nur ein Hinweise: Anders als die Darstellung mit den Bildchen vermittelt werden die abgeschlossenen Tasks aus der Liste etnfernt. Es war nur einfacher zu zeichnen (und auch für die Verständlichkeit besser, wenn die Tasks nicht ins Nirvana verschwinden.


      Fibonacci

      Um die Fibonacci-Funktion passend umzuschreiben braucht es jetzt noch die passende Zustands-Klasse:

      VB.NET-Quellcode

      1. Private Class FibonacciState
      2. Public IsInitialCall As Boolean = True
      3. Public RecursionTask1 As TaskContext(Of Integer, Integer, FibonacciState)
      4. Public RecursionTask2 As TaskContext(Of Integer, Integer, FibonacciState)
      5. End Class

      Und dann kann auch schon losgelegt werden:

      VB.NET-Quellcode

      1. Private Shared Sub NonRecursiveFibonacci(Context As TaskContext(Of Integer, Integer, FibonacciState))
      2. If Context.State.IsInitialCall Then
      3. Select Case Context.Input
      4. Case Is < 0
      5. 'Darf eigentlich nie passieren, wird aber zur Sicherheit nochmal geprüft, für den Fall, dass sich irgendwo ein Bug eingeschlichen hat.
      6. Throw New NopeException
      7. 'Triviale Fälle abfragen
      8. Case 0
      9. Context.Finish(0)
      10. Return
      11. Case 1
      12. Context.Finish(1)
      13. Return
      14. Case Else
      15. 'Rekursion einleiten. Durch das Setzen von IsInitialCall auf False wird beim nächsten Aufruf der Code weiter unten ausgeführt.
      16. Context.State.IsInitialCall = False
      17. 'Tasks einreihen und im Zustand einen Verweis darauf behalten.
      18. Context.State.RecursionTask1 = Context.QueueTask(Context.Input - 1)
      19. Context.State.RecursionTask2 = Context.QueueTask(Context.Input - 2)
      20. Return
      21. End Select
      22. Else
      23. 'Ergebnisse der Rekursionen addieren und als Ergebnis festlegen.
      24. Context.Finish(Context.State.RecursionTask1.Result + Context.State.RecursionTask2.Result)
      25. Return
      26. End If
      27. End Sub

      Und ein Aufruf:

      VB.NET-Quellcode

      1. Dim FibonacciTaskExecutor As New TaskExecutor(Of Integer, Integer, FibonacciState)(AddressOf NonRecursiveFibonacci, Function() New FibonacciState)
      2. For i = 0 To 10
      3. Console.WriteLine("Fibonacci({0}) = {1}", i, FibonacciTaskExecutor.Execute(i))
      4. Next



      Ackermann

      Und weils so schön war hier noch die Ackermann-Funktion nach dem Schema:

      VB.NET-Quellcode

      1. 'Ackermann benötigt 2 Parameter
      2. Private Structure AckermannInput
      3. Public m As Integer
      4. Public n As Integer
      5. End Structure
      7. '... und 3 Schritte
      8. Private Enum AckermannStateNumber As Integer
      9. Initial = 0
      10. Recurse1 = 1
      11. Recurse2 = 2
      12. End Enum
      14. Private Class AckermannState
      15. Public Number As AckermannStateNumber = AckermannStateNumber.Initial
      16. Public RecursionTask As TaskContext(Of AckermannInput, Integer, AckermannState)
      17. End Class
      19. Private Shared Sub NonRecursiveAckermann(Context As TaskContext(Of AckermannInput, Integer, AckermannState))
      20. Select Case Context.State.Number
      21. Case AckermannStateNumber.Initial
      22. 'Auch hier kann man sicherheitshalber nochmal prüfen, ob die Argumente überhaupt gültig sind.
      23. If Context.Input.m < 0 OrElse Context.Input.n < 0 Then
      24. Throw New NopeException
      25. End If
      26. 'Trivialer Fall
      27. If Context.Input.m = 0 Then
      28. Context.Finish(Context.Input.n + 1)
      29. Return
      30. End If
      31. 'Rekursion einleiten
      32. Context.State.Number = AckermannStateNumber.Recurse1
      33. If Context.Input.n = 0 Then
      34. Context.State.RecursionTask = Context.QueueTask(New AckermannInput With {.m = Context.Input.m - 1, .n = 1})
      35. Return
      36. End If
      37. Context.State.RecursionTask = Context.QueueTask(New AckermannInput With {.m = Context.Input.m, .n = Context.Input.n - 1})
      38. Return
      39. Case AckermannStateNumber.Recurse1
      40. 'Hier muss ein zweites Mal geprüft werden, ob Ackermann(m - 1, 1) oder Ackermann(m - 1, RecursiveAckermann(m, n - 1)) berechnet wird.
      41. If Context.Input.n = 0 Then
      42. 'In ersterem Falle ist der Task nämlich schon fertig.
      43. Context.Finish(Context.State.RecursionTask.Result)
      44. Return
      45. End If
      46. 'In letzterem muss nochmal gewartet werden.
      47. Context.State.Number = AckermannStateNumber.Recurse2
      48. Context.State.RecursionTask = Context.QueueTask(New AckermannInput With {.m = Context.Input.m - 1, .n = Context.State.RecursionTask.Result})
      49. Return
      50. Case AckermannStateNumber.Recurse2
      51. Context.Finish(Context.State.RecursionTask.Result)
      52. Return
      53. End Select
      54. End Sub

      Und der Aufruf:

      VB.NET-Quellcode

      1. Dim AckermannTaskExecutor As New RecursiveTaskIteration.TaskExecutor(Of AckermannInput, Integer, AckermannState)(AddressOf NonRecursiveAckermann, Function() New AckermannState)
      2. For m = 0 To 4
      3. For n = 0 To 4
      4. Console.WriteLine("Ackermann({0}, {1}) = {2}", m, n, AckermannTaskExecutor.Execute(New AckermannInput With {.m = m, .n = n}))
      5. Next
      6. Next



      Yield in C#

      Die Funktion wird auf diese Weise leider etwas auseinandergerissen. Das lässt sich auch nicht einfach vermeiden. Je komplexer die Funktion, desto schlimmer wird es. C# hat Iterator-Funktionen. Damit könnte man vermutlich was basteln, wenn man das alles etwas umschreibt. Könnte inetwa so aussehen:

      C#-Quellcode

      1. public class TaskContext<TInput, TOutput> { ... }
      3. private static IEnumerable<int?> FibonacciTest(TaskContext<int, int> Context)
      4. {
      5. if (Context.Input == 0)
      6. {
      7. yield return 0; //0 als Ergebnis festlegen.
      8. yield break; //Vermutlich unnötig, weil die Funktion sowieso nicht mehr aufgerufen wird, nachdem ein Ergebnis zurückgeliefert wurde.
      9. }
      10. if (Context.Input == 1)
      11. {
      12. yield return 1; //1 als Ergebnis festlegen.
      13. yield break;
      14. }
      15. var Task1 = Context.QueueTask(Context.Input - 1); //Tasks einreihen.
      16. var Task2 = Context.QueueTask(Context.Input - 2);
      17. yield return null; //Rekursion benötigt.
      18. yield return Task1.Result + Task2.Result; //Summe der Ergebnisse als Ergebnis festlegen.
      19. yield break;
      20. }

      Das sieht wesentlich übersichtlicher aus.
      Der Compiler generiert automatisch Code, mit dem er sich "merkt", wo aktuell Code ausgeführt wird:

      C#-Quellcode

      1. //Gaaaaaanz stark vereinfacht!
      2. private static IEnumerable<int?> FibonacciTest(TaskContext<int, int> Context)
      3. {
      4. <FibonacciTest>d__0 <FibonacciTest>d__ = new <FibonacciTest>d__0(-2);
      5. <FibonacciTest>d__.Context = Context;
      6. return <FibonacciTest>d__;
      7. }
      9. private class <FibonacciTest>d__0 : IEnumerable<int?>, IEnumerator<int?>
      10. {
      12. private int? <>2__current;
      13. private int <>1__state;
      15. public TaskContext<int, int> Context;
      16. public TaskContext<int, int> <Task1>5__1;
      17. public TaskContext<int, int> <Task2>5__2;
      19. public <FibonacciTest>d__0(int <>1__state)
      20. {
      21. this.<>1__state = <>1__state;
      22. }
      24. int? IEnumerator<int?>.Current { get { return this.<>2__current; } }
      26. IEnumerator<int?> IEnumerable<int?>.GetEnumerator()
      27. {
      28. //Extrem vereinfacht!
      29. return this;
      30. }
      32. bool IEnumerator.MoveNext()
      33. {
      34. switch (this.<>1__state)
      35. {
      36. case 0:
      37. this.<>1__state = -1;
      38. if (this.Context.Input == 0)
      39. {
      40. this.<>2__current = new int?(0);
      41. this.<>1__state = 1;
      42. return true;
      43. }
      44. if (this.Context.Input == 1)
      45. {
      46. this.<>2__current = new int?(1);
      47. this.<>1__state = 2;
      48. return true;
      49. }
      50. this.<Task1>5__1 = this.Context.QueueTask(this.Context.Input - 1);
      51. this.<Task2>5__2 = this.Context.QueueTask(this.Context.Input - 2);
      52. this.<>2__current = null;
      53. this.<>1__state = 3;
      54. return true;
      55. case 1:
      56. this.<>1__state = -1;
      57. break;
      58. case 2:
      59. this.<>1__state = -1;
      60. break;
      61. case 3:
      62. this.<>1__state = -1;
      63. this.<>2__current = new int?(this.<Task1>5__1.Result + this.<Task2>5__2.Result);
      64. this.<>1__state = 4;
      65. return true;
      66. case 4:
      67. this.<>1__state = -1;
      68. break;
      69. }
      70. return false;
      71. }
      73. }

      Das hat eine verblüffende Ähnlichkeit zur VB-Implementierung oben.
      Man beachte, dass der Compiler hier absichtlich Bezeichner verwendet, die man in C# normalerweise nicht hinschreiben kann. Das <FibonacciTest> gehört zum Bezeichner und stellt keinen generischen Typenparameter dar. Dadurch soll verhindert werden, dass der Compiler einen Namen generiert, den man schon woanders im Programm verwendet.

      Eventuell könnte sowas ähnliches auch mit Await/Async funktionieren. Damit habe ich aber nicht genug Erfahrung.


      Hausaufgabe

      Als Hausaufgabe für den Leser ;) :
      1.: Die Fibonacci-Funktion optimieren, indem man ein Dictionary verwendet, um bereits berechnete Ergebnisse zwischenzuspeichern. Wie man beim Beispiel oben erkennt, wird bei Fibonacci(4) mehrmals Fibonacci(2) berechnet. Erhöht man n, wird das umso schlimmer. In einem Dictionary kann gespeichert werden, was bereits berechnet wurde.
      2.: Das Ganze so umschreiben, dass man nicht nur eine Funktion rekursiv verwenden kann, sondern beliebige, die auch nicht die gleiche Signatur haben müssen. Also z.B. Function A(n As Integer) As String verwendet Function B(s As String) As Integer und umgekehrt.
      3.: So umschreiben, dass in C# Iterator-Funktionen damit verwendet werden können. Nur doof, dass es dann in VB noch schlimmer wird.


      Anhang
      Ich habe ein Projekt mit einer Bibliothek und Beispielanwendung angehängt. Im Code oben ist das eine oder andere als Friend deklariert (internal in C#). Diese Sachen sind nicht dazu gedacht, von außen angegriffen zu werden. Wenn sich TaskExecutor, TaskContext und TaskMethod in einer eigenen Bibliothek befinden, wie in der Projektmappe, dann sind diese Sachen von außen nicht sichtbar.
      Es kann sein, dass beim ersten Öffnen das falsche Startprojekt eingestellt ist. Hier einfach im Projektmappen-Explorer mit der rechten Maustaste auf TestApplication klicken und dann "Als Startprojekt festlegen".
      RecursiveTaskIteration.zip (19.9 KB gepackt, 50.2 KB entpackt)
      Bilder

      • Fibonacci4_01.png

        2,76 kB, 1.149×308, 875 mal angesehen

      • Fibonacci4_02.png

        3,7 kB, 1.149×308, 843 mal angesehen

      • Fibonacci4_03.png

        4,41 kB, 1.149×308, 842 mal angesehen

      • Fibonacci4_04.png

        5,51 kB, 1.149×308, 853 mal angesehen

      • Fibonacci4_05.png

        5,51 kB, 1.149×308, 843 mal angesehen

      • Fibonacci4_06.png

        5,53 kB, 1.149×308, 855 mal angesehen

      • Fibonacci4_07.png

        6,15 kB, 1.149×308, 850 mal angesehen

      • Fibonacci4_08_09.png

        12,24 kB, 1.149×616, 938 mal angesehen

      • Fibonacci4_10.png

        6,24 kB, 1.149×308, 851 mal angesehen

      • Fibonacci4_11_12.png

        12,29 kB, 1.149×616, 844 mal angesehen

      • Fibonacci4_13_14.png

        12,21 kB, 1.149×616, 877 mal angesehen

      • Fibonacci4_15_16.png

        12,19 kB, 1.149×616, 895 mal angesehen

      • Fibonacci4_17.png

        6,22 kB, 1.149×308, 845 mal angesehen
      "Luckily luh... luckily it wasn't poi-"
      -- Brady in Wonderland, 23. Februar 2015, 1:56
      Desktop Pinner | ApplicationSettings | OnUtils

    Facebook
    Telefonspende