Warum entfernt TPageProducer keine Anführungszeichen von Zeichenfolgen?

8

Ich versuche, ein Verhalten zu debuggen, das nur dann aufgetreten ist, wenn meine große App, die in XE3 funktioniert, nach dem Kompilieren mit XE4 ausgeführt wird. Das Problem scheint zu bewirken, dass einige Strings in Anführungszeichen (z. B. "MyString") ihre Anführungszeichen behalten, auch nachdem sie von TPageProducer in Web.HTTPProd "de-quoted" wurden. Betrachten Sie zum Beispiel den folgenden Code, der ein kleiner Auszug aus dieser Delphi-Quelleneinheit Web.HTTPApp ist:

%Vor%

Ich sehe das aufgerufen, wenn ich TPageProducer benutze und ich kann meine gute Quellzeichenkette in die ExtractHeaderFields Routine oben und dann in die "DoStripQuotes" Funktion sehen. Wenn Sie in DoStripQuotes einsteigen und "Ergebnis" sehen, wird angezeigt, dass es sich nicht ändert, selbst wenn Result.Remove aufgerufen wird (um das Zitat zu streichen). Wenn ich diese "DoStripQuotes" Routine zu einer einfachen Test-App mache, kompiliert sie nicht und sagt mir, dass 'Ergebnis.irgendwas' nicht erlaubt ist. Ich nehme dann an, dass Ergebnis, obwohl es als 'string' definiert ist, ein anderer Typ von Zeichenfolge im Kontext von Web.HTTPProd sein muss.

Ich denke also, dass das etwas mit den unveränderlichen Strings zu tun hat, von denen ich gehört habe. Ich lese das SO Frage darüber und obwohl ich den Kernpunkt habe, könnte ich es praktischer machen Beratung.

Insbesondere möchte ich Antworten auf die folgenden Fragen:

  1. Welcher Typ von 'String' ist 'Result', wenn die Notation Result.Length erlaubt ist?
  2. Gibt es eine Möglichkeit, dem Compiler mitzuteilen, dass er die 'XE3'-Kompatibilität für eine Einheit verwenden soll? (Dies könnte mir erlauben zu sehen, wo das Problem entsteht). Ich habe versucht {$ ZEROBASEDSTRINGS ON} / OFF, aber das scheint noch mehr Chaos zu verursachen und ich weiß nicht, was ich tue!

Danke für jede Hilfe.

SPÄTER BEARBEITEN: Wie in der akzeptierten Antwort unten erwähnt, ist dies ein Fehler in der VCL-Einheit Web.HTTPApp.pas, der "Ergebnis: = Ergebnis.Remove (I, 1)" an zwei Stellen um Linie 2645 herum und nicht lesen sollte "Result.Remove (I, 1)"

    
Brian Frost 12.06.2013, 08:59
quelle

1 Antwort

9
  

Welche Art von 'String' ist 'Ergebnis', wenn die Notation Result.Length erlaubt ist?

Es ist nur das alte string , aliased für UnicodeString , das Sie seit Delphi 2009 verwendet haben. Der Unterschied besteht darin, dass dieser Code den neuen Datensatzhelfer verwendet (speziell SysUtils.TStringHelper ). Dadurch können Sie . notation für eine String-Variable verwenden.

  

Gibt es eine Möglichkeit, dem Compiler zu sagen, dass er die 'XE3'-Kompatibilität für eine Einheit verwenden soll?

Nein. Der fragliche Code ist eine Bibliothekseinheit und ist so konzipiert, dass er in einem bestimmten Modus kompiliert werden kann. Außerdem können Sie es nicht einfach erneut kompilieren, wenn Sie nicht selbst die RTL / VCL kompilieren. Selbst wenn es einen solchen Modus gäbe, würde es nicht helfen, da der Code einfach falsch ist (siehe unten). Keine Menge an Moduswechsel kann dieses bestimmte Stück Code reparieren.

  

Ich denke, dass das etwas mit den Unveränderlichen Strings zu tun hat, von denen ich schon gehört habe.

Es ist nicht. Keiner der Delphi-Compiler hat noch unveränderbare Zeichenfolgen. Das Konzept der unveränderlichen Strings ist nur etwas, das als eine zukünftige Änderung aufgefächert wurde. Und wenn die Änderung vorgenommen wird, erwarten Sie, dass es zuerst in den mobilen Compilern gemacht wird.

Das Problem ist in der Tat nur ein ziemlich einfacher Fehler in dem Code, den Sie gepostet haben, der eindeutig überhaupt keine Tests hatte. Die Verwendung von Remove ist falsch. Diese Methode ändert die Zeichenfolge nicht direkt. Stattdessen wird eine neue Zeichenfolge zurückgegeben, bei der das Zeichen entfernt wurde. Der Code sollte lauten:

%Vor%

Der Grund, dass der Entwickler, der ExtractHeaderFields programmiert hat, diesen Fehler gemacht hat, ist, dass derjenige, der den String-Helfer-Code entworfen hat, die Methode Remove falsch benannt hat. Da Remove ein Verb ist, würden Sie erwarten, dass es in-place arbeitet. Eine Methode, die den Betreff nicht ändert und eine neue Instanz zurückgibt, wie diese Methode verwendet, sollte einen Namen erhalten, der ein Substantiv ist. Also sollte diese Methode so benannt werden wie Remnants . Es sieht für mich so aus, als ob die RTL-Designer die .net-Benennung kopiert haben, wo derselbe Fehler auch existiert.

Sie sollten einen QC-Bericht einreichen, falls noch keiner vorhanden ist. Ich weiß, dass XE4 Update 1 gerade veröffentlicht wurde. Es ist plausibel, dass es eine Lösung enthält.

Ihre anderen Optionen, wie ich sie sehe, sind:

  1. Bleiben Sie bei XE3, bis XE4 ausreichend getestet ist.
  2. Fügen Sie eine Kopie der Einheit Web.HTTPApp in Ihr Projekt ein und beheben Sie die Fehler selbst.
David Heffernan 12.06.2013, 09:12
quelle

Tags und Links