Nach Hause
Top.Mail.Ru Yandeks.Metrika
Forum: "Haupt";
Aktuelles Archiv: 2002.04.01;
Herunterladen: [xml.tar.bz2];

Nach unten

Wert zugewiesen Finden Sie ähnliche Zweige


Gluka   (2002-03-14 02:18) [0]

Was zum Teufel ist das und wie man damit umgeht !!!



Lego   (2002-03-14 02:26) [1]

Bist du irgendwo drin? war hat dieses A angekündigt und es wird einfach nicht verwendet ... oder wenn es verwendet wird, ist es nicht so, wie Ihr Delphi es erwartet hat



~Sergius   (2002-03-14 02:57) [2]

Zum zweiten Teil der Frage ("Wie gehe ich damit um?") - Die Option zum Anzeigen von Warnungen ist deaktiviert



Suntechnic   (2002-03-14 03:20) [3]

> ~ Sergius (14.03.02 02: 57)
> Deaktivieren Sie die Option, um Warnungen anzuzeigen

Normalerweise wird dies durch Entfernen der "überflüssigen" Variablen beseitigt, aber wer ist natürlich viel natürlich ...



~Sergius   (2002-03-14 04:06) [4]

2 Suntechnic ©
Noch einmal, die Angewohnheit, nach einem Witz nicht zu lächeln, versagt mir



Suntechnic   (2002-03-14 04:14) [5]

> ~ Sergius (14.03.02 04: 06)
:)



Gluka   (2002-03-14 04:21) [6]

Programm g1;

benutzt ??;

war
a: ganze Zahl;
beginnen
a: = 0;
...
...
Wert, der "A" zugewiesen wurde, wurde nie verwendet
Warum!?!?!?



Suntechnic   (2002-03-14 04:32) [7]

> Gluka © (14.03.02 04: 21)
Und zeig mir den Ort, an dem du eine Variable hast a wird verwendet? Wenn es keine gibt, was wollen Sie dann vom Compiler?



Lego   (2002-03-14 06:41) [8]

Sie haben eine Variable
1. angekündigt.
2. 0 gleichgesetzt.
3. aber nicht benutzt :)



stub   (2002-03-14 07:39) [9]

Konzentrieren Sie sich auf Ihr Nachrichtenfenster (in dem der Compiler seine Nachrichten sammelt) und drücken Sie F1 für den ausgewählten Fehler. Eine Fehlerbeschreibung erhalten Sie von der borland help.
genießen.



Song   (2002-03-14 08:32) [10]

Übrigens macht der Compiler manchmal Fehler in Bezug auf eine solche Nachricht.

Zuerst wollte ich ein Beispiel für einen solchen Fehler geben, aber ich denke, dass es (ein Beispiel im Sinne) von Zeilen auf 30 nicht interessant wäre, es anders zu betrachten. Der Compiler ist leicht zu verwechseln.




drpass   (2002-03-14 10:19) [11]

> Gluka
Und was stört dich? Dies ist kein Fehler, sondern eine Warnung. Der Compiler sieht eine völlig nutzlose Zuweisung (weil Sie den zugewiesenen Wert wirklich nicht verwenden) und sieht es als seine Pflicht an, Sie zu warnen - plötzlich haben Sie vergessen, einen Befehl hinzuzufügen. Wenn Ihnen solche Warnungen nicht gefallen, können Sie sie auf der Registerkarte "Projektoptionen"> "Compiler" deaktivieren



Anatoly Podgoretsky   (2002-03-14 22:53) [12]

Hören Sie sich am besten den Compiler an und verwenden Sie ihn. Warum brauchen Sie ihn sonst?

Lied © (14.03.02 08: 32)
Und los, los, plötzlich hat der Compiler recht.



Malder   (2002-03-14 23:12) [13]

Anatoly Podgoretsky, der Compiler ist wirklich falsch. Und es ist wirklich schwer, ein Beispiel zu nennen. Ich hatte es mit irgendeiner Komponente. Er schrieb immer S1 nicht verwendet. Obwohl S1 immer noch verwendet wird ...



Anatoly Podgoretsky   (2002-03-14 23:25) [14]

Nicht so wörtlich, normalerweise liegt eine Logik in den Aktionen des Compilers oder Sie haben es verwirrt :-)



Shirson   (2002-03-15 07:54) [15]

Der Compiler hat recht.
a: = 0; Hier wird keine Variable verwendet. Die Verwendung einer Variablen ist c: = b + a; Oder für ein: = 0 zu 100 machen ...
Versuchen Sie, die Deklaration dieser Variablen aus Ihrer Prozedur zu entfernen, entfernen Sie a: = 0 aus dem Hauptteil und führen Sie das Programm aus. Ist etwas kaputt :)



Внук   (2002-03-15 09:27) [16]

Und ich würde auch gerne ein Codebeispiel sehen. Der Compiler erzeugt manchmal manchmal "zusätzliche" Warnungen, aber nicht von diesem Typ (dies geschieht über eine nicht initialisierte Variable). Die Warnung zur Verwendung einer Variablen ist leicht zu überprüfen. Der Compiler sucht nur nach Lesezugriffen auf diesen Speicherbereich. Sie ist entweder vorhanden oder nicht. Zumindest in meiner Praxis (und bei meinen Kollegen) gab es keinen Fall einer falschen Schlussfolgerung aus dieser speziellen Warnung.



Sergey13   (2002-03-15 09:52) [17]

Das ist mir auch passiert. Nichtgebrauchsbeschwörung mit expliziter Verwendung der Variablen. Aber irgendwie episodisch (also nicht jeden Tag) und durch mehrmaliges Zusammenstellen "behandelt". So einfach. Einmal kompiliert - erhalten, das zweite kompiliert - verloren. Vielleicht habe ich 8 zum ersten Mal nicht verstanden-) Aber es lohnt sich nicht, die Warings zu trennen - manchmal heißt es.



Shirson   (2002-03-15 10:10) [18]

> Enkel © (15.03.02 09: 27)
Und ich würde auch gerne ein Codebeispiel sehen. Der Compiler erzeugt manchmal manchmal "zusätzliche" Warnungen, aber nicht von diesem Typ (dies geschieht über eine nicht initialisierte Variable).
---

Sowas gibt es. In diesem Fall deklarieren Sie eine Variable und verwenden ihren Wert ohne Initialisierung. Was auf eigene Gefahr und Gefahr gerufen wird - der Compiler trägt keine Verantwortung für die Folgen;)



MAxiMum   (2002-03-15 10:16) [19]

Das Problem ist, dass der Compiler auch Codezeilen mit einer nicht verwendeten Variablen auswirft (sehen Sie sich die linke Seite des Editors mit Punkten an).
CODE! CODE! CODE! CODE! CODE! CODE! CODE! CODE! CODE! CODE! CODE!



Sergey13   (2002-03-15 10:52) [20]

Kletterte wieder nach Delfu und es stellte sich heraus

Prozedur TForm12.FormShow (Sender: TObject);
var i, k, ls, vch, vcho: ganze Zahl;
....
bla bla bla
....
vch: = 1;
vcho: = 1;
für i: = 1 zu tun
beginnen
c: = Kopie (s, i, 1);
wenn pos (c, "0123456789.")> 0, dann ist st: = st + c
sonst
beginnen
wenn c = "(" dann vch: = 1 sonst
wenn c = "*" dann vch: = 2 else
wenn c = "/" dann vch: = 3 sonst vch: = 0;
if vch = 1 dann k: = k + 1;
.....
bla bla bla
.....
Issued - Der Wert, der "vch" zugewiesen wurde, wurde nie verwendet
Beim erneuten Kompilieren verschwand es.



Внук   (2002-03-15 10:53) [21]

>> Shirson ©
Ich hatte etwas anderes im Sinn, das heißt wirklich "zusätzliche" Warnungen. Zum Beispiel eine bedingte Anweisung, bei der eine Variable nur in einem Zweig initialisiert wird und die Ausführung eines anderen Zweigs nach der Logik des Programms unmöglich ist (bisher nicht abgeschlossen). So:

...
var i: Byte;
...

Verfahren zuerst;
beginnen
i: = 1;
...
end;

Verfahren Zweitens;
var AAA: ganze Zahl;
beginnen
wenn i = 1, dann
beginnen
AAA: = 1;
...
Ende
sonst
beginnen
...
end;
ShowMessage (IntToStr (AAA));
end;

Der Code wurde genau hier eingegeben, aber ich denke, die Bedeutung ist klar



Внук   (2002-03-15 11:00) [22]

>> Sergey13 ©
Also ist es richtig. Zuordnung vch: = 1; Ganz am Anfang macht es keinen Sinn, da diese Variable dann in jedem Fall neu zugewiesen wird.
"Neuzusammenstellung verschwunden." :)) Und wenn Sie Build All machen, wird es wieder angezeigt.




Внук   (2002-03-15 11:09) [23]

Ja, zum Code in der Nachricht Grandson © (15.03.02 10: 53) müssen Sie etwas wie hinzufügen
procedure Form1.OnCreate ...
beginnen
Zuerst;
Zweite;
end;



Sergey13   (2002-03-15 11:17) [24]

> Enkel © (15.03.02 11: 00)
Ja, du hast recht, danke. Etwas, das mir das Geschäft verdorben hat, und ich habe Delfu ein Fass gerollt. Ich bereue.



Anatoly Podgoretsky   (2002-03-15 21:47) [25]

Sergey13 © (15.03.02 10: 52)
Sie sagten dem Compiler zuhören, der erste Wert wird nie verwendet

Enkel © (15.03.02 10: 53)
Nun, es gibt zwei Probleme.
1. Der Compiler hat nur einen Durchgang. Er kann nicht wissen, ob die Variable in einer anderen Prozedur verwendet werden kann oder nicht, beispielsweise aufgrund einer Ausnahme.

2. AAA-Variable kann nicht initialisiert werden.

Das heißt, beide Beispiele sind unbefriedigend.



Song   (2002-03-16 11:09) [26]

2Anatoly Podgoretsky © (14.03.02 22: 53)
Ich entschuldige mich dafür, dass ich nicht angekommen bin.
Bitte melden Sie, dass die Flag-Variable niemals verwendet wird:

Flag: = Falsch; Mit strg do Mit TreeView.Items Do Für t: = 1 zu RowCount-1 Do Beginnen Sie Knoten: = TreeView.Items [0]; Wiederholen versuchen Sie es IF Pos (Zellen [IndexNo, t], Node.Text)> 0 dann IF Pos ("eingehend", S)> 0 dann Beginnen Sie ..... Flag: = True; Beende sonst Beginnen Sie ...... Flag: = True; Ende; IF Node.Text = "Andere Dokumente" dann NodeSafe: = Node; Knoten: = Node.GetNextSibling; außer WENN dann nicht kennzeichnen Beginnen Sie ..... Flag: = True; Ende; Pause Ende; Bis falsch; Ende;



Внук   (2002-03-18 17:20) [27]

>> Song ©
Glaubst du, das wird benutzt? Wenn der Code wirklich derselbe ist wie hier, können Sie diese Flag-Variable sicher verwerfen. Das Verlassen der Schleife ist nur mit Ausnahme möglich, wobei Flag immer wahr ist. Der Wert von Flag wird im Hauptteil der Schleife nicht verwendet. Oder habe ich etwas nicht verstanden?



Внук   (2002-03-18 17:55) [28]

>> Song ©
Ich bremse jedoch. Es ist unmöglich, Flag wegzuwerfen, die Ausnahmebehandlung hängt davon ab. Glauben Sie es einfach, glauben Sie es oder nicht, aber dieser Code (Delphi5) hat der Variablen Flag keine Warnungen gegeben. Vielleicht ist die Tatsache, dass es statt ... steht?



Song   (2002-03-19 08:59) [29]

2 Enkel © (18.03.02 17: 55)
Und es leitet von mir ab: ((Ich sage, der Compiler ist verwirrt ...
Nein, statt ... gibt es nichts Vergleichbares.
Übrigens ist das Auszugsbit aus dem Programm falsch.
String Flag: = False; Gesichter Wiederholen, d.h .:
.....
Für t: = 1 zu RowCount-1 Do Beginnen Sie Knoten: = TreeView.Items [0]; Flag: = Falsch; Wiederholen versuchen Sie es IF Pos (Cells [Ind
...

Das ändert aber nichts. Es sollte immer noch keine Warnung ausgegeben werden.



ao1973   (2002-03-19 09:49) [30]

Vom Moderator gelöscht



Song   (2002-03-19 09:55) [31]

2ao1973 (19.03.02 09:49)
Was ist deine frage Warum sofort beleidigt?



keg   (2002-03-19 10:16) [32]

In dem gezeigten Beispiel warnt der Compiler korrekt. In der ersten Zeile weisen Sie es False zu und dann (in der fehlenden Zeile) nehmen Sie erneut eine Zuordnung vor, und Flag wird nicht zwischen ihnen verwendet, sodass die erste Zuordnung nicht erforderlich ist - Sie können sie ausschneiden. Nun, ganz am Ende führen Sie die Zuweisung in Exception erneut durch, und nachdem (bis zum Ende der Prozedur) Flag nicht verwendet wurde, macht es einen Unterschied, welchen Wert Flag nach dem Verlassen der Schleife hat.



Rooman   (2002-03-19 10:36) [33]

Also, meine Herren, Programmierer!
Ich löse dein Problem ein für alle Mal!

1: Der Compiler kompiliert das Projekt mit OPTIMIERUNG des Codes (das heißt, er konvertiert Ihren Code optimal - siehe ZERLEGUNG Ihres Codes), wenn die Option OPTIMIERUNG Code aktiviert ist (siehe Projekteigenschaften).
Was bedeutet das? Dies bedeutet, dass unter einigen LOCAL-Variablen der Platz in MEMORY nicht reserviert ist, d. H. Der Code ist so optimiert, dass alle Operationen an DIESER VARIABLE in den PROCESSOR REGISTERS stattfinden. Ein Beispiel:

var a, b: ganze Zahl;
...
a: = 1;
b: = a;
...

kompiliert wie folgt:

mov eax, 1; eax - Prozessorregister
mov b, eax
...

und der Compiler gibt die Warnung "Variable a wird nie verwendet" aus.

Im Großen und Ganzen ist das sogar gut, weil funktioniert so schnell wie möglich (ohne auf den Speicher zuzugreifen).

2. Eine einfache Zuweisung ohne nachträgliche Verwendung einer Variablen wird vom Compiler automatisch notiert, WENN OPTIMIERUNG EINGESCHALTET IST (siehe Projekt s-va).






Ray   (2002-03-19 10:46) [34]

2 Rooman. Alles klar Der gesamte obige Code leidet unter demselben Fehler oder vielmehr nicht unter einem Fehler, sondern unter einem Missverständnis oder unter mangelnder Aufmerksamkeit. Es gibt zum ersten Mal eine Zuweisung zu einer Variablen, und egal, wie viel Code passiert, wenn nichts daraus gelesen und nur zugewiesen wird, ist die erste Zuweisung völlig unnötig. Hier ist der Compiler und warnt. Dies ist am einfachsten zu verstehen. Nimm den Code. wir löschen Zeilen, in denen diese Variable fehlt und schauen dann, was bleibt?

Flag: = Falsch; Flag: = True;



RedWood   (2002-03-19 10:54) [35]

Hallo!

> Übrigens ist das Auszugsbit aus dem Programm falsch.

> String Flag: = False; Gesichter Wiederholen, d.h .:
.....
Flag: = False;
Mit strg do
Mit TreeView.Items Do
Für t: = 1 zu RowCount-1 Do
Beginnen
Knoten: = TreeView.Items [0];
Flag: = False;
Wiederholen

es stellt sich heraus, dass die Warnung die erste Zuweisung gibt Flag: = False; weil In einer FOR-Schleife wird die Variable jedoch neu definiert. Dies gilt natürlich, wenn die Variable in der Prozedur nicht weiter verwendet wird.
Übrigens gibt die Warnung in welcher Zeile?



keg   (2002-03-19 11:17) [36]

2 RedWood. Doppelklicken Sie auf die Warnung, um die gewünschte Zeile anzuzeigen.



Song   (2002-03-19 11:32) [37]

2RedWood:
Ich habe einen Fehler gemacht, als ich hier gepostet habe. Die Flag-Variable steht vor Repeat und nicht vor.

Ich verstehe die Meldung wie folgt: "Die Variable wurde deklariert, aber nicht verwendet." Zeigen Sie mir jeden Pfad in dieser Passage, auch mit einer Ausnahme, wo die mit Flag arbeitende Zeile vorkommt.



Drex   (2002-03-19 12:35) [38]

Und wie gefällt dir dieses Stück? Es wird auch hier nicht verwendet
i: = 0;
CardByte: = 0;
Wiederholen
Byte10: = 0;
Bit: = 0;
Wiederholen
i: = CardByte * 8 + Bit;
Fallbit von {Binär zu Dezimal}
0: Byte10: = Byte10 + Current [i] * 128;
1: Byte10: = Byte10 + Current [i] * 64;
2: Byte10: = Byte10 + Current [i] * 32;
3: Byte10: = Byte10 + Current [i] * 16;
4: Byte10: = Byte10 + Current [i] * 8;
5: Byte10: = Byte10 + Current [i] * 4;
6: Byte10: = Byte10 + Current [i] * 2;
7: Byte10: = Byte10 + Current [i] * 1;
End;
Bit: = Bit + 1;
i: = i + 1;
Bis Bit = 8;



Внук   (2002-03-19 13:35) [39]

>> Song c (19.03.02 09: 55) "Aber das ändert nichts. Eine Warnung sollte trotzdem nicht ausgegeben werden."
Es ändert sich sogar :) Jetzt bekomme ich eine Warnung zu Flag: = True im Fragment unten:
...
Außer
WENN dann nicht kennzeichnen
Beginnen Sie
Flag: = True;
...
Ende;
Pause
end;
...
Nun, richtig, der Austritt aus der Schleife ist nur durch Exception möglich, während Flag: = True ausgeführt wird, und sofort in der nächsten Iteration der äußeren Schleife Flag: = False.
Eigentlich ist das eine Warnung. Die Flagzuweisung sollte aus dem Ausnahmehandler entfernt werden. Der Compiler hat recht.
Ich wiederhole: Diese Warnung wird ausgegeben, wenn zwischen zwei Zugriffen auf eine Variable zum Schreiben kein einziger Zugriff zum Lesen vorhanden war.
„Ich verstehe die Meldung folgendermaßen:„ Die Variable wurde deklariert, aber nicht verwendet. “- Die Meldung sollte (wörtlich) so verstanden werden: Der Variablen wurde ein Wert zugewiesen, der in der Zukunft nicht verwendet wird, das heißt, sie konnte nicht zugewiesen werden.
>> keg (19.03.02 10: 16) Siehe Enkel c (18.03.02 17: 55) "Sie können kein Flag werfen, die Ausnahmebehandlung hängt davon ab" - für ein altes Codefragment ist dies der Fall.
>> Ray c (19.03.02 10: 46) Ich wage es zu bemerken, nicht alles ist so einfach. Obwohl Rooman natürlich recht hat.
>> alle
Ich versuche hier nur zu beweisen, dass eine Warnung dieser Art NIEMALS vergeblich angezeigt wird. Aber oft kann es ignoriert werden :)))



Внук   (2002-03-19 13:55) [40]

>> Drex (19.03.02 12: 35)
Das selbe. Wenn Sie dem Compiler erklären können, warum Sie die erste Zeile i: = 0 benötigen (das konnte ich nicht rechtfertigen), gibt er Ihnen nie wieder eine Warnung :)



Анонимщик   (2002-03-19 15:44) [41]

Was ist dein Beruf? Der Compiler kompiliert und optimiert. Er hat Ihre Variable nicht im endgültigen Code, schreibt er. Okay?



Внук   (2002-03-19 16:14) [42]

>> Anonym © (19.03.02 15: 44)
Und warum schreibt er das? Für sich selbst oder willst du chatten? Die Frage ist, wann diese Meldungen angezeigt werden und wie sie vermieden werden können. Darüber hinaus sind in allen obigen Beispielen die Variablen, für die Warnungen ausgegeben werden, im Code WELL in vollem Umfang vorhanden. Aber die Tatsache, dass die meisten "coolen Programmierer" (ich meine keines der Mitglieder des Threads und möchte nicht beleidigen) diese Nachrichten nicht lesen oder ihre Bedeutung nicht verstehen - das ist eine Tatsache.



deleon   (2002-03-19 16:29) [43]

Einmal hatte ich einen Compiler in einer absolut korrekten Funktion eines Objekts, das schrieb: "Interner Fehler xxxx" half weder beim Neustart der IDE noch beim Eisen. Im Allgemeinen habe ich diese Funktion mit der nächsten getauscht und der Compiler hat mir sofort gefallen! Es war aber nur einmal! Wie oft ich schon auf Delphi geschworen habe, aber nachdem ich es immer aufgegriffen hatte, stellte sich heraus, dass dies meine Fehler sind. Wir können also sagen, dass der Compiler in 99,8% richtig ist :)



Donal_Graeme   (2002-03-19 16:38) [44]

hier über interne Fehler Dies ist eine andere Geschichte :-)) Die Hilfe sagt, dass solche Fehler niemals auftreten sollten. Trotzdem erscheinen sie :-) In einigen Fällen ist es möglich zu verstehen, was dem Compiler nicht gefallen hat (es ist mir einmal gelungen, aber ich erinnere mich nicht an den Fehlercode oder den Grund).



Анонимщик   (2002-03-19 18:28) [45]

Enkel
Sie sind möglicherweise im Code enthalten, aber der Compiler sieht keinen Sinn darin, sie zu verwenden, da sie für nichts benötigt werden. Wie genau dieser Compiler entscheidet, dass diese bestimmte Variable überflüssig ist und Sie sich keine Gedanken darüber machen müssen, kann ich nicht beurteilen, dafür müssen Sie sie von innen kennen. Aber natürlich kann etwas vorgeschlagen werden. Sind diese Variablen in dem Code enthalten, den der Compiler für Ihren Pascal-Code verwendet (dies ist natürlich ausführbarer Code), ist dies genau das Wichtigste, um zu verstehen, woher solche Warnungen stammen. Suchen Sie im Debugger nach dem Wert der Variablen, für die der Compiler etwas Schlechtes sagt, dann wird die Sache klarer.



Anatoly Podgoretsky   (2002-03-19 20:46) [46]

Insbesondere ist es notwendig, dass der präsentierte Code wiederholt werden kann, indem er einfach in den Editor kopiert wird, und die abgerissenen Codes geben darüber hinaus mit Fehlern während des Kopierens nicht viel, bis kein Beispiel angegeben wird, das reproduziert werden könnte. Dies deutet darauf hin, dass ein fehlerhafter Computer äußerst selten vorkommt. Aber selbst wenn er sich irrt, ist es sinnvoll darüber nachzudenken, warum eine erfolglose Konstruktion erstellt werden kann, die zu komplex ist, als dass der Compiler sie nicht verstehen könnte.



Drex   (2002-03-20 05:46) [47]

>> Enkel
Eigentlich habe ich versucht, mich zu vereinen, aber es hat einfach nicht funktioniert ;-) Manchmal schreibst du so einen Unsinn. Dies kann gesehen werden, als die Prozedur einige zuvor benötigte Dinge debuggte, die aufgehört haben, notwendig zu sein ... Danke



vl_chel   (2002-03-20 08:13) [48]

Meiner Meinung nach ist all diese Diskussion, dass Leute, die das Programmieren und die Arbeit eines Programms schlecht oder gar nicht verstehen, wütend auf den Compiler wegen ihrer Fehler sind. Die Variable wird nicht verwendet - ein Signal, dass der Code fehlerhaft ist und verbessert werden muss



vl_chel   (2002-03-20 08:24) [49]

>> Drex in dem Code, den Sie geschrieben haben, die Variablen CardByte und ich sind nicht männlich
i: = 0; << Sinn ??
CardByte: = 0;
Wiederholen << wofür gilt das?
Byte10: = 0;
Bit: = 0;
Wiederholen
i: = CardByte * 8 + Bit; << CardByte = 0 Sense ??


Fallbit von {Binär zu Dezimal}
0: Byte10: = Byte10 + Current [i] * 128; << Änderung in allen Zeilen I zu Bit
1: Byte10: = Byte10 + Current [i] * 64;
2: Byte10: = Byte10 + Current [i] * 32;
3: Byte10: = Byte10 + Current [i] * 16;
4: Byte10: = Byte10 + Current [i] * 8;
5: Byte10: = Byte10 + Current [i] * 4;
6: Byte10: = Byte10 + Current [i] * 2;
7: Byte10: = Byte10 + Current [i] * 1;
End;
Bit: = Bit + 1;
i: = i + 1; << warum erhöhe ich (kompetenter) inc (I))
Bis Bit = 8;




Внук   (2002-03-20 10:00) [50]

>> Anonym © (19.03.02 18: 28)
Ich wiederhole in Großbuchstaben: Eine Warnung bedeutet nicht, dass die Variable nicht verwendet wird, sondern dass der aktuelle Wert der Variable nicht verwendet wird. Fühlen Sie den Unterschied und lesen Sie die Nachrichten buchstäblich, während sie geschrieben werden. Falsche Übersetzung führt zu falscher Interpretation. Der Compiler entscheidet nicht, dass die Variable überflüssig ist, sondern meldet lediglich, dass der der Variablen zugewiesene Wert sofort (ohne Verwendung dieses Werts) durch einen anderen Wert überschrieben wird.



Rooman   (2002-03-20 11:19) [51]

Nochmals fett: Eine Variable wird nicht nur verwendet, wenn kein RAM-Speicher zugewiesen ist. Das heißt seine Bedeutung zumindest geht in Register. Und das ist in der Regel immer gut!



Rooman   (2002-03-20 11:29) [52]

Warnungen sind keine Fehler, wenn Sie mindestens eine elementare Hilfe für einen Delphin lesen. Wenn dies ein Fehler wäre - die Hölle würde Sie kompilieren, kein Programm! In diesem Fall sagt der Compiler, dass während der Kompilierung kein Speicher für die Variable zugewiesen wurde, d.h. Es ist beispielsweise nicht möglich, einen Haltepunkt auf seinen Wert zu setzen, oder Sie können den Wert zur Laufzeit nicht von einem Debugger anzeigen lassen. Das ist alles! Was sind dann die Probleme?



Внук   (2002-03-20 11:38) [53]

>> Rooman (20.03.02 11: 19)
Ich bin damit einverstanden Dies widerspricht jedoch nicht allem, was ich zuvor gesagt habe. Ich bestätige, dass die hier diskutierte Warnung auch in Fällen gerechtfertigt erscheint, in denen der Variablen im endgültigen Programmcode Speicher im virtuellen RAM zugewiesen ist. Das eine stört das andere nicht. Und das Erscheinen dieser Nachricht zeigt immer die Krümmung des Codes an, und dies ist nicht gut (obwohl es nicht beängstigend ist, sonst wäre es ein Fehler).



Alx2   (2002-03-20 11:38) [54]

> dieser Speicher für eine Variable wurde beim Übersetzen nicht belegt
Es wurde kein ausführbarer Code generiert.



Внук   (2002-03-20 11:55) [55]

"In diesem Fall gibt der Compiler an, dass der Variablen während der Kompilierung kein Speicher zugewiesen wurde."
Leute, schreibst du das ernsthaft ??? Nichts dergleichen. Die Zuweisung oder Nichtzuweisung von Speicher hängt nur indirekt damit zusammen (als Sonderfall). Ja, wenn es unmöglich ist, einen Haltepunkt in eine Zeile mit einer Variablen zu setzen, könnte es sein, dass kein Speicher dafür reserviert wurde ??? Diese Zeile ist aufgrund der Optimierung nicht möglich. Es ist also möglich, eine andere Zeile mit derselben Variablen zu verwenden. - Der Speicher wird einer statischen Variablen zugewiesen und dann konfisziert, oder was? Ich bin es leid zu erklären. Bald wird dieser Thread im "Fuck" tragen: ((



Rooman   (2002-03-20 12:03) [56]

Noch Zeit halten - nur nicht auffallen! Glauben Sie mir nicht - sehen Sie sich den Code-Disassembler an (ich hoffe, Sie müssen nicht erklären, wie das geht :)



Внук   (2002-03-20 12:13) [57]

>> Rooman (20.03.02 12: 03)
Alles, ich gehe zum Kloster. Code schreiben
var i: ganze Zahl;
i: = 0;
i: = 1;
Es folgt ein furchtbar ausgefeilter Code, in dem die Variable i optimal genutzt wird (20000-Zeilen mit gruseliger Logik, die es nicht zulassen, diese Variable in das Register aufzunehmen) - entscheiden Sie selbst.

In Zeile i: = 0; Sie erhalten garantiert die berüchtigte Warnung. Haben Sie weitere Fragen?



Rooman   (2002-03-20 12:18) [58]

Variablen werden manchmal direkt in Prozessorregistern gespeichert. Siehe Verwenden von Delphi:

Die Direktive $ O steuert die Codeoptimierung. Im Status {$ O +} führt der Compiler eine Reihe von Codeoptimierungen durch, z. B. das Platzieren von Variablen in CPU-Registern ( Platzierung von Variablen in Prozessorregistern - d.h. nicht im RAM), gemeinsame Unterausdrücke eliminieren ( Umstrukturierung komplexer mathematischer Ausdrücke in einfache) und Erzeugen von Induktionsvariablen ( Induktionsvariablen erstellen) Im Status {$ O-} sind alle derartigen Optimierungen deaktiviert.
Anders als in bestimmten Debugsituationen sollten Sie Optimierungen niemals deaktivieren müssen. Alle Optimierungen, die vom Object Pascal-Compiler von Delphi durchgeführt werden, ändern garantiert nicht die Bedeutung eines Programms ( garantiert nicht die Gleichwertigkeit Ihres Codes und des optimierten Codes) Mit anderen Worten, Delphi führt keine "unsicheren" Optimierungen durch, die eine besondere Kenntnis des Programmierers erfordern ( Mit anderen Worten, die Optimierung führt zu einer Änderung der Logik des ursprünglichen Algorithmus, jedoch nicht zu einer Änderung seiner Ergebnisse).



Rooman   (2002-03-20 12:24) [59]

Enkel, in diesem Fall hat der Compiler gerade Ihre Linie geworfen. Dies ist auch nicht beängstigend, wie im Fall der Verwendung einer Variablen innerhalb von Registern. Verdammt noch mal, vergeben Sie erst eine und dann eine andere - es ist ineffizient, sagt der Compiler.



Rooman   (2002-03-20 12:34) [60]

Enkel: Der Compiler in Ihrem Beispiel sagt den folgenden Satz:

Der Wert, der "i" zugewiesen wurde, wurde nie verwendet (nie verwendet - in kompiliertem Code).

Was ist nicht klar?



Rooman   (2002-03-20 12:38) [61]

gleiche Botschaft manchmal ( nicht immer Natürlich) wird angezeigt, wenn der Compiler Ihren Code so geändert hat, dass er Ihre Variable überhaupt nicht benötigt! Es geht um diese Ich habe über die obige Situation gesprochen, weil ich oft darauf gestoßen bin.



Rooman   (2002-03-20 13:16) [62]

In Bezug auf Induktionsvariablen:

var i: ganze Zahl;
procedure doany (var n: integer); stdcall;

i: = 1;
doany (i);
i: = 2;
doany (i);
i: = 3;
doany (i);

Hier wird unter der Variablen i der Speicher eindeutig zugeordnet.
Also, hier ist - für Sie ist dies eine Variable und für den Compiler - drei verschiedene (siehe Disassembler):

mov [esp], 1; erste Induktionsvariable (angeblich "i")
Drücken Sie esp
Ruf doany an

mov [esp], 2; zweite Induktionsvariable (angeblich "i")
Drücken Sie esp
Ruf doany an

mov [esp], 3; dritte Induktionsvariable (angeblich "i")
Drücken Sie esp
Ruf doany an

Dies ist das Phänomen der Induktion einer Variablen.

Dieses Beispiel ist einfach: Der Algorithmus wird während der Kompilierung nicht umstrukturiert, sodass keine Warnungen angezeigt werden.

Aber in Zyklen, ziemlich oft während der Optimierung, stieß ich auf eine Situation, in der der Compiler einfach eine Variable auswirft (durch Induktion, d. H. Erzeugen einer separaten Variablen, oft in Prozessorregistern - siehe oben).
Und in der Situation:

i: = 0;
wiederholen
...
wir benutzen die Variable i
...
bis ...

Der Compiler sagt, dass die Zuweisung zu Null niemals erfolgt, da sie nicht weiter verwendet wird, da innerhalb der Schleife die Variable i nicht dieselbe Variable ist, die vor der Schleife war (und danach sein wird)!

Ich rate Ihnen, darüber nachzudenken, da solche Situationen selten vorkommen und es schwierig ist, sofort ein Beispiel zu geben.



Rooman   (2002-03-20 13:26) [63]

Kurz gesagt, der Rat an die Person, die die Frage gestellt hat, lautet, die Optimierung in den Projektoptionen zu deaktivieren. Dann kompiliert alles genau so, wie Sie es in Ihrem Code geschrieben haben. Aber es ist besser, dies nicht zu tun und im Allgemeinen zu punkten (überprüfen Sie Ihren Code, d. H.) :))



Rooman   (2002-03-20 13:34) [64]

Enkel: Der letzte Akkord zu Ihnen - was Sie sprechen, ist nur die Folge dessen, was ich spreche. Weil Die häufigste Optimierungssituation ist die Platzierung von Induktionsvariablen in Prozessorregistern führt dazu, dass der Compiler gezwungen ist, die erste Codezeile auszulösen:
i: = 0;
i: = 1;
da das erstellen einer induktionsvariablen in dieser zeile nicht sinnvoll ist, wird sie nicht weiter verwendet.

Denk drüber nach und du wirst mich verstehen.



Rooman   (2002-03-20 13:40) [65]

Allgemeiner Tipp: Trennen Sie die Konzepte in sich selbst: Pascal-Code und Assembler-Code. Für den Prozessor pro Trommel setzen Sie eine Variable oder Konstante, der Prozessor verfügt über Register, den dafür zur Verfügung stehenden Speicher (virt.machine) mit unterschiedlichen Zugriffsrechten (s / w) und einen Stack. Alle Register und alle Daten, mit denen der Prozessor arbeitet, sind von drei Typen: QWORD, DWORD, WORD und BYTE.
Das ist alles! Nichts mehr.



Внук   (2002-03-20 14:16) [66]

>> Rooman
Ich muss das nicht erklären :) Registervariablen in C wurden von mir verwendet, auch wenn DOS unsere einzige Hoffnung und Unterstützung war. Die Tatsache, dass dieselbe Variable im Text eines Programms in Pascal während der Verwendung im Assembler-Code unterschiedlich dargestellt werden kann, ist eine Tatsache. Für einen Anfänger (oder nicht) Programmierer, der nur den Quellcode seines Programms sieht, ist dies dasselbe. Deshalb argumentiere ich aus der Sicht einer Hochsprache. Nach den Repliken zu urteilen (siehe ganz am Anfang), missverstehen einige die Bedeutung der Meldung, dass die Variable überhaupt nicht verwendet wird. Nur der Zwischenwert dieser Variablen wird nicht verwendet. Jetzt scheinen wir über dasselbe zu reden :)
Jetzt bin ich an der Reihe, dem Fragesteller Ratschläge zu erteilen: Deaktivieren Sie die Optimierung nicht und ignorieren Sie keine Warnungen, da diese darauf hinweisen, dass Ihr Algorithmus so ineffizient ist, dass er selbst vom Compiler erkannt und grob für Sie korrigiert werden kann. Dies ist bereits eine Art Halbzeug :)



Rooman   (2002-03-20 18:39) [67]

Enkel Schließlich haben wir uns verstanden. Ich stimme nicht nur der Tatsache zu, dass es notwendig ist, eine Hochsprache zu sprechen. Es scheint mir, dass die meisten Programmierer Fehler machen, nur weil sie einfach nicht wissen, wie dies letztendlich auf der niedrigsten Ebene durchgeführt wird. Ich bin dafür, das Wissen der Programmierer zu erweitern. Generell sollte das Programmieren meines Erachtens nicht in Hochsprachen, sondern in Assembler-Sprachen studiert werden, zumal es viel einfacher zu verstehen ist.



Rooman   (2002-03-20 18:54) [68]

Und der Algorithmus kann effizient sein. Sehr gerne. Eins korreliert nicht mit dem anderen :)



Drex   (2002-03-21 12:50) [69]

>> vl_chel

Drex in dem Code, den Sie geschrieben haben, die Variablen CardByte und ich sind nicht männlich
i: = 0; << Sinn ?? hier habe ich meine kippe schon erkannt
CardByte: = 0;
Wiederholen << wofür gilt das? Eine weitere externe Schleife, in der das Inkrement "CardByte" ist und daher noch CardByte benötigt wird

Byte10: = 0;
Bit: = 0;
Wiederholen
i: = CardByte * 8 + Bit; << CardByte = 0 Sense ??


Fallbit von {Binär zu Dezimal}
0: Byte10: = Byte10 + Current [i] * 128; << Änderung in allen Zeilen I zu Bit (auf CardByte * 8 + Bit) -so ist es möglich ;-)
1: Byte10: = Byte10 + Current [i] * 64;
2: Byte10: = Byte10 + Current [i] * 32;
3: Byte10: = Byte10 + Current [i] * 16;
4: Byte10: = Byte10 + Current [i] * 8;
5: Byte10: = Byte10 + Current [i] * 4;
6: Byte10: = Byte10 + Current [i] * 2;
7: Byte10: = Byte10 + Current [i] * 1;
End;
Bit: = Bit + 1;
i: = i + 1; << warum erhöhe ich (kompetenter als inc (I)) Ich werde darüber nachdenken, danke das ohne Sarkasmus
Bis Bit = 8;

Hier ist das Inkrement von CardByte und Until für die äußere Schleife.





Stratos   (2002-03-21 14:16) [70]

Apropos interne Fehler:
Ich bekam das, nachdem ich einen Zyklus in der Prozedur geschrieben hatte inin ihm Beic brechen. Nach dem Löschen der Schleife (Pause blieb) trat ein Fehler auf. Theoretisch hätte der Compiler gut fluchen sollen. Vielleicht wird er in großen Projekten verwirrt.

Im Allgemeinen ist das einzige zuverlässige Debugging-Tool ein Schamanen-Tamburin 8)



fenics   (2002-03-21 18:42) [71]

Armer Gkuka! Inwieweit kann ein Dutzend Programmierer sprechen?
Eine Woche später wurde seine Frage nicht erinnert!



fenics   (2002-03-21 18:42) [72]

Armer Gluka! Inwieweit kann ein Dutzend Programmierer sprechen?
Eine Woche später wurde seine Frage nicht erinnert!



Seiten: 1 2 ganze Branche

Forum: "Haupt";
Aktuelles Archiv: 2002.04.01;
Herunterladen: [xml.tar.bz2];

nach oben





Speicher: 0.86 MB
Zeit: 0.056 c
6-256
Yuraz
2002-01-17 18:30
2002.04.01
Es gibt einen HTML-Code, den ich zumindest primitiv in eine visuelle Seite umwandeln möchte.


14-314
phantom2040
2002-02-20 14:11
2002.04.01
Fernzugriffsserver auf xp


6-265
Malder
2002-01-19 13:39
2002.04.01
Socket-Verbindung abfangen


1-128
oomneeq
2002-03-21 12:26
2002.04.01
So verwalten Sie die Aufnahme von TD32-Debug-Informationen


14-315
ao1973
2002-02-20 15:37
2002.04.01
Windows Ce





Afrikanisch Albanien Arabisch Armenisch Aserbaidschanisch Baskisch Weißrusse Bulgarisch katalanisch Chinesisch (vereinfacht) Chinesische Tradition) kroatisch Tschechisch Dänisch Niederländisch Englisch estnisch Philippinisch Finnisch Französisch
Galicisch Georgisch Deutsch Griechisch haitian Creole Hebräisch Hindi ungarisch isländisch Indonesian irisch Italian Japanisch Koreanisch lettisch litauisch Makedonisch Malay Maltesisch Norwegisch
persisch Polnisch Portugiesisch Rumänisch Russisch serbisch Slovakisch Slowenisch Spanisch Suaheli Schwedisch Thai Türkisch Ukrainisch Urdu Vietnamesisch Walisisch Jiddisch Bengalisch bosnisch
cebuano Esperanto Gujarati Hausa Hmong igbo Javanisch kannada Khmer Laotisch Lateinisch Maorisch Marathi Mongolisch nepali Pandschabi Somalisch Tamilisch Telugu Yoruba
Zulu
Английский Französisch Deutsch Italienisch Португальский Russisch Spanisch