Zitat:
Muß er nicht. Wenn er eine Variable hat, sucht er alle Stellen im Speicher (die mit dem Programmablauf zu tun haben), die dem Inhalt der Variable entsprechen. Danach sucht er im Programmablauf, wo auf diese Stellen zugegriffen wird und überprüft, ob sie tatsächlich eine Variable sein könnten. Wieso also 3 Tage warten, was in einem Abwasch geht?
Das funktioniert NUR wenn im Code des Programmieres direkt auf diese Schattenvariablen zugegriffen wird. Ich gehe aber bei solchen Spielereien immer davon aus das solche Variablen indirekt addressiert werden. D.h. in diesem Moment wird per Program in anderen Variablen die reale Adresse der Schattenvariable dynamisch berechnet. Nun funktioniert dein obiger Vorschlag nicht mehr so einfach. Eine einfache Methode wäre die Anwendung von
OOP. Bei dynamischen Objecten werden deren Felder ja immer indirekt adressiert.
Zitat:
Aber um es auf den Punkt zu bringen: Was ich sagen will und was ich oben schon gesagt habe, nicht so viel Zeit und Elan in Sachen stecken, die eh nicht den 100%igen Erfolg haben, sondern eher in die Funktionalität des Spiels. Was nützt es, wenn keiner einen Trainer proggen kann, aber das Spiel keiner spielt, weil es Sch...ße ist.
Da stimme ich dir voll zu, der Aufwand sollte gerechtfertigt sein. Grundsätzlich bin ich aber der Meinung das der normale Programmierer bei komplexen und großen Anwendungen durch seine enorme Entwicklungsgeschwindigkeit den Vorteil auf seiner Seite hat. Mit wenigen Mausklicks erzeugen wir ganze Programme die der Cracker mit recht "primitiven" Werkzeugen in "unverständlichem" Assembler vor sich sieht. Im Grunde dürften es garnicht so viele Cracks geben, wenn die Cracker nicht so verdammt gut wären. Programme erstellen ist heute Fließband-Arbeit, Programme cracken dagegen manuelle Hand-Arbeit.
Gruß Hagen