Abstimmung Programmierwettbewerb #5

[KaPiTN]

You do not have permission to view link please Anmelden or Registrieren

Das mit dem Array war jetzt schlecht gewählt, weil das tatsächlich nur ein Unterschied in der Syntax ist und die gleichen CIL ergibt.

Aber es gibt in beiden Sprachen Features, die die andere nicht hat.


Schon ein Integer und einen String zu definieren und dann den integer dem string zu zu weisen´muß zu etwas unterschiedlichem CIL führen, weil in C# der Integer ein Wert zugewiesen werden und eine Methode aufgerufen werden muß, die den Int in ein string castet.

Spoiler

int s=0;
string w;
w = s.ToString();
_______________________

[0] int32 s,
[1] string w
)

IL_0000: nop
IL_0001: ldc.i4.0
IL_0002: stloc.0
IL_0003: ldloca.s s
IL_0005: call instance string [mscorlib]System.Int32:oString()
IL_000a: stloc.1
IL_000b: ret

Spoiler

Dim s As Integer
Dim w As String
w = s
________________________

[0] int32 s,
[1] string w
)

IL_0000: nop
IL_0001: ldloc.0
IL_0002: call string [Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.Conversions:oString(int32)
IL_0007: stloc.1
IL_0008: ret

Ein einfacheres Beispiel dürfte es nicht geben, aber bereits hier gibt es Abweichungen, weil VB automatische Initialisierung und implizite Typumwandlung hat, C# aber nicht.

Das soll jetzt kein kleinliches Korinthenkacken sein, weil es ja schließlich irgendwo noch ähnlich aussieht.
Vielmehr geht es mir darum dem Versprechen zu mißtrauen, unter .NET könne jeder die Sprache seiner Wahl wählen für das Projekt, weil letztendlich käme ja der gleiche Zwischencode heraus.
Das ist jetzt fast 15 Jahre her, ich weiß nicht mehr welche Effekte damals aufgetreten sind, aber wir haben den VB Code portiert, weil verschiedene, mal aus VB und mal aus C# heraus erzeugte Programmteile, zusammen nicht zuverlässig die erwarteten Resultate lieferten.

 

[Brother John]

Häckchen zu vergeben ist gar nicht so einfach. Es hat Spaß gemacht, die ganzen verschiedenen Ansätze in so vielen verschiedenen Sprachen zu sehen, und da seid ihr alle miteinander schuld dran! Sowas wie ein Codereview macht auch wenig Sinn, weil ich die meisten Sprachen höchstens oberflächlich kenne. OK, sagen wir zwei Punkte für die Algos.

Der erste Punkt geht an Rakorium, weil das am Ende der interessanteste algorithmische Ansatz war. Ein perfect Maze zu erzeugen, indem man den Solver draufschmeißt und ausrechnet, dass die Perfectness-Regeln nicht verletzt werden, auf die dumme Idee muss man erstmal kommen! Ich bin ein bisschen skeptisch in Sachen Performance, aber das tut der Idee keinen Abbruch.

Und noch ein Punkt für Roin für die komplette Implementierung von »Zelle ist Wand oder Weg«. Ich fands gut, dass du nicht in Richtung zelluläre Automaten losmarschiert bist, was man für die Art Labyrinth wohl oft macht. Sonst hätte man nicht so schön gesehen, dass sich die Ansätze für »Wand/Weg-Zellen« und »Wand zwischen den Zellen« gar nicht so sehr unterscheiden. In Zweierschritten zu gehen scheint mir der wichtige Trick zu sein. Außerdem Bonus-Daumenhoch dafür, dass das Labyrinth auch noch spielbar ist.

Nochwas zur Perfectness: Ich glaube, ich hab die wichtigen Punkte dafür verstanden. Eine garantierte Lösung stellt man sicher, indem man stecken bleibt und dann irgendwo anders am schon erzeugten Weg wieder ansetzt. So hat man immer freien Rückweg zum Eingang – und das gilt natürlich auch noch am Ausgang. Eine eindeutige Lösung kriegt man, wenn man es vermeidet, einen Weg zu einem schon besuchten Feld zu graben. Spätestens die letzte Wand bleibt immer stehen. Damit kreuzt sich der Lösungsweg nie selbst und es entstehen keine Schleifen, durch die man sich entscheiden könnte wie herum man läuft. Und das klärt auch den spanning tree, der immer wieder als Begriff auftaucht. Denn ein Pfad, der sich nur immer weiter verästelt, aber nie Äste wieder zusammenführt – das ist ein Baum.