spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Sollte ein "high-skilled professional" das nicht wissen? *g* :angel:

Zum Thema:
x = 0 wird vom Compiler, soweit ich weiß, wirklich mit xor übersetzt (vorausgesetzt x ist ein Integer). Man kann das aber auch einfach nachprüfen, indem man sich die Assembly mit Originalquellcode als Kommentar vom Compiler ausgeben lässt. Einfach mal in den Projekteinstellungen suchen ... das geht mit allen mir bekannten Versionen von Visual C++!

Ja sollte ich wohl egtl :-D
Wie gesagt, hab bisher in allen anderen Sprachen die ich so benutzt habe ^ genommen und es hat geklappt.. Hatte das in C++ einfach mal vorrausgesetzt.

Zitat

x = 0 wird vom Compiler, soweit ich weiß, wirklich mit xor übersetzt (vorausgesetzt x ist ein Integer). Man kann das aber auch einfach nachprüfen, indem man sich die Assembly mit Originalquellcode als Kommentar vom Compiler ausgeben lässt. Einfach mal in den Projekteinstellungen suchen ... das geht mit allen mir bekannten Versionen von Visual C++!

Ich weiß nich wie das in Assembler geregelt wird, aber die ALU im Prozessor hat ne eigene Funktion um eine 0 zu erstellen die wohl etwas schneller sein dürfte, von daher liegt es denk ich nahe, dass die auch benutzt wird.

Das hängt mit der Logik der Bauteilansteuerung zusammen. Dabei gibt es die negative und positive Logik. Normalerweise verwendet man die positive Logik, spricht 1 == TRUE und 0 == FALSE!
Intern ist dann alles dementsprechend aufgebaut (Gatter-Bausteine). Bei negativer Logik hauptsächlich mit NPN-Transistorschaltern mit TTL-Pegeln.

@Skip
Kennst du dich mit Elektronik ein bisschen aus?

Ich habe folgendes Programm von Visual C++ 2003 optimiert kompilieren lassen:



Hier die Übersetzung:



Also xor!

Also nochmal kurz zum Thema:

1.) Iteration ist zu 90% immer schneller, ausserdem viel weiniger Speicheraufwand.
2.) Noch besser ist das dynamische Programmierkonzept. Anstatt Das Problem vom größen Problemfaktor anzugehen geht man vom kleinsten aus. Man berechnet also erst 0!, 1!, 2! und so weiter...
Vorteil: man kann bei mehrmaligen berechnungen so was wie 32! sogar zwischenspeichern, was einen erheblichen Geschwindigkeitsgewinn bringt.
3.) Eigentlich dürfte der Geschwindkeitsgewinn scho n bei 32!.... sehr deutlich sein, um die 3 Lösungsstrategien zu unterscheiden.
4.) Wer rekursiv denken kann, soll angeblich sehr intelligent sein.... macht aber den Computer auch nicht schneller , das gehört aber eigentlich nicht hier rein musste aber mal gesagt werden

Mein Mathe Lehrer sagte mal so schön, "um Rekursion zu verstehen muss man Rekursion verstanden haben"; dass habe natürlich nur die Informatiker verstanden

Rekursion ist was feines, nur wer das mal in assembler programmiert hat und dann mal den speicheranstieg sich angeguckt hat, der weiß warum es auch seine tücken hat.
Rekursives denken ist nicht so schwer, führt nur nich so schnell zum ziel, warum also es erst versuchen?

... weil es intelligent macht... nach einer Studie jedenfalls.... muss also heissen, allle die Faktulät rekursiv programmieren können sind intelligent ...... lassen wir das doch lieber so im Raum stehen *hust*

@Kovok,
oder der wegen so nem komischen Prof einein "pulssierenden Speicher" aufzeichnen musste, wobei eine Aufgabe mit Rekursion schon mehr als ein Blatt verschlinkt

Rekursion ist auf jeden Fall kompakter. Dass sie "intelligent machen" soll, könnte man sich dadurch erklären, dass man mit ihr lernt, ein Problem so lange aufzuteilen, bis man an einer sehr einfach zu lösenden elementaren Aufgabe angekommen ist. Ein gutes Beispiel dafür sind die "Türme von Hanoi", die man rekursiv sehr schön lösen kann.