Konstante String-Parameter und der Delphi XE5-Compiler für Android

Wir haben einige interne Untersuchungen durchgeführt, und es stellt sich heraus, dass dies von der Art abhängt, wie der Code geschrieben wird, und dass der Compiler nichts dagegen tun kann. Es ist etwas komplex, aber kurz gesagt, die GoToDirectory-Methode erhält einen konstanten String-Parameter (Dir), der sich auf einen String bezieht. Im Code der Methode wird jedoch die Zeichenfolge durch eine neue Zeichenfolge ersetzt (die sich möglicherweise an derselben Stelle oder an einem anderen Speicherort befindet). Wenn der const-Parameter die Referenzzahl nicht erhöht, wird die Zeichenfolge entfernt, wenn Sie die Ref-Anzahl der gleichen Zeichenfolge im Code verringern. Sie haben also einen Parameter, der auf einen nicht definierten Speicherplatz zeigt, und die tatsächliche Ausgabe ist zufällig. Das gleiche Problem tritt auf allen Plattformen auf (nicht für Mobilgeräte).

Es gibt viele Problemumgehungen:

1) nicht den const-Parameter haben (daher ist die ref-Zählung höher, Sie ändern die referenzierte Zeichenfolge, aber der Parameter ist jetzt eine Referenz auf eine separate Zeichenfolge

2) Übergeben Sie einen Alias ​​der Zeichenfolge:

3) Weisen Sie der temporären lokalen Variablen den Parameter "const String" zu:

Ich weiß, dass dies alles andere als eine klare Beschreibung ist, und ich musste es ein paar Mal rot machen, um es zu verstehen, aber es ist ein Szenario, das der Compiler nicht wirklich automatisch verarbeiten kann ".

Um Marcos Kommentar ein wenig zu erweitern, ist dieser Grubenabfall bei der Verwendung von const auf einem Parameter in Delphi seit der Einführung von const -Parametern aufgetreten und ist kein Bug, sondern eher ein Feature, das Ihre Beispiel ist ein Beispiel für einen Fall, es sollte nicht verwendet werden.

Der Modifikator const ist ein Versprechen an den Aufrufer, dass es keine Möglichkeit gibt, dass eine als Parameter übergebene Variable als Nebeneffekt des Aufrufs modifiziert wird. Der einfachste Weg, dies zu gewährleisten, ist, niemals eine global zugängliche Variable in einer Funktion oder Prozedur mit einem Parameter const zu modifizieren. Auf diese Weise kann sich der Angerufene auf die Referenzzahl des Aufrufers verlassen, die Semantik des Kopierens vermeiden usw. Mit anderen Worten, er teilt dem Compiler mit, dass der Wert als var effizienter übergeben wird und als var -Parameter behandelt werden kann (Das heißt, hat einen Lvalue) dann übergeben Sie es als var anstelle eines Wertes. Wenn es sich um einen verwalteten Typ handelt, z. B. eine Zeichenfolge, kann er sich auch auf die Referenz des Aufrufers verlassen, um den Speicher am Leben zu halten.

Dieser Vertrag wird durch GoToDirectory verletzt, wenn er eine globale zugängliche Zeichenfolge ändert (jeder Heapzugriff sollte in diesem Kontext als global betrachtet werden, obwohl es ein Feld eines Objekts ist). GoToDirectory sollte keinen const -Parameter haben, weil dieser gegen den von const implizierten Vertrag verstößt.

Beachten Sie, dass sich dies erheblich von dem Vertrag unterscheidet, der von const in anderen Sprachen wie C ++ impliziert wird. Es ist bedauerlich, dass es zu dieser Zeit kein besseres Wort gab. Was es wirklich sagt, ist, dass die Funktion oder Prozedur in Bezug auf Variablen rein ist, die mit dem formalen Typ des const -Arguments kompatibel sind, nicht, dass es das Argument nicht ändert. Es ist einfacher, sich daran zu erinnern, dass const nicht auf Parameter einer Funktion oder Prozedur angewendet wird, die einen Nebeneffekt hat.

Diese Faustregel kann verletzt werden, wenn der Nebeneffekt des Schreibens auf ein globales Element für die Prozedur oder Funktion oder für Prozeduren oder Funktionen, die sie aufruft, nicht sichtbar ist. Das ist in der Regel sehr schwierig, um triviale Fälle von außen zu gewährleisten (z. B. einen einfachen Eigenschaften-Setter), und sollte nur verwendet werden, wenn eine Leistungseinschränkung den Overhead der Wertkopie nicht leisten kann. Mit anderen Worten, Sie sollten besser eine Performance-Spur in der Hand haben, um es zu rechtfertigen, oder es ist für den zufälligen Beobachter offensichtlich, dass eine Kopie teuer wäre.

FWIW, ich kann das Problem nicht lokal mit XE5 Update 2, Android 4.4.2, auf einem Nexus 7 mit Ihrer Nicht-FMX-Version reproduzieren. Das Projekt wurde mithilfe Ihrer Schritt-für-Schritt-Anweisungen (Kopieren / Einfügen von Code) erstellt und im Debug-Modus auf dem Gerät ausgeführt. Die Protokollausgabe war:

Um sicher zu sein, dass ich es nicht reproduzieren konnte, habe ich die Anwendung mehrmals mit denselben Ergebnissen erstellt und ausgeführt.

Die FMX-Version weist jedoch inkonsistente Ergebnisse auf. Das erste Mal, als ich es ausgeführt und aufgebaut habe, hat es nach dem dritten ShowMessageFmt eine Zugriffsverletzung erzeugt und musste gestoppt werden. Ich habe es dann erneut erstellt, ausgeführt und konnte alle vier ShowMessageFmt -Dialoge sehen, aber das letzte zeigte einen falschen Wert:

Die dritte und vierte Build- und Laufwiederholung haben die gleiche Ausgabe wie die zweite erzeugt.

Ich würde sagen, das ist ein Fehler. Es ist offen und R & amp; D-Team bei Embarcadero wird es untersuchen.