![]() |
AW: Programm entschlacken: JclStrings nimmt 500KB im Projekt ein?
Alles klar, dann werde ich mal aktualisieren und danach nochmal Rückmeldung geben.
Vielen Dank für die Info! |
AW: Programm entschlacken: JclStrings nimmt 500KB im Projekt ein?
Vielen Dank, hat geklappt! :thumb:
|
AW: Programm entschlacken: JclStrings nimmt 500KB im Projekt ein?
Nun steh ich doch tatsächlich ziemlich genau ein Jahr später erneut vor dem gleichen Problem. :(
Ich habe auf einem neuen Rechner meine Entwicklungsumgebung mit Delphi XE erneut aufgesetzt und alle Komponenten eingerichtet, darunter auch JCL+JVCL. Ich habe von beiden die aktuellen Daily-Builds genommen, da sich die JCL-Version aus dem aktuellen Stable JVCL-Paket nicht installieren ließ (irgendein Problem mit JclOtaUtils). Die beiden Daily-Builds wurden hingegen problemlos installiert. Nach dem Kompilieren der Anwendung Stirnrunzeln: die exe ist ein gutes Stück größer als zuvor. Ein Blick in die Projekt-Analyse zeigt erneut das gleiche Bild wie vor einem Jahr: die JclStrings (BSS) belegt gut 500kB im Projekt. :( Damals löste sich das Problem durch die Installation eines Daily Builds. Diesmal geht's leider nicht aktueller (JCL 2.4.0.4319). Ist in der Zwischenzeit bei JCL wieder was schiefgelaufen? Oder gibt es eine neue Lösung? |
AW: Programm entschlacken: JclStrings nimmt 500KB im Projekt ein?
Schau mal in deine JclStrings.pas, ob dort "UNICODE_RTL_DATABASE" vorkommt. Wenn das fehlt, dann stimmt was mit dem Daily Build nicht (oder es werden keine neueren mehr erzeugt)
Du kannst das auch in einem eigenen Programm Testen:
Delphi-Quellcode:
program Test;
{$I jcl.inc} begin {$IFNDEF UNICODE_RTL_DATABASE} 'Da stimmt was nicht wenn das hier nicht Delphi XE ist' {$ENDIF} end. |
AW: Programm entschlacken: JclStrings nimmt 500KB im Projekt ein?
Liste der Anhänge anzeigen (Anzahl: 1)
UNICODE_RTL_DATABASE kommt dort sogar recht häufig vor. 61 Mal um genau zu sein. Ich hab die Datei hier mal angehängt, vielleicht siehst Du da ja eher was.
Allerdings frage ich mich, wo UNICODE_RTL_DATABASE überhaupt definiert wird. In der jcl.inc steht:
Delphi-Quellcode:
(wozu das "~"?)
{$IFNDEF HAS_UNIT_CHARACTER}
{$UNDEF UNICODE_RTL_DATABASE} {$ENDIF ~HAS_UNIT_CHARACTER} Habe in meiner Anwendung mal getestet und es ist weder UNICODE_RTL_DATABASE noch HAS_UNIT_CHARACTER definiert. Und nu? :| |
AW: Programm entschlacken: JclStrings nimmt 500KB im Projekt ein?
Zitat:
Zitat:
Für folgendes Programm sehe ich mit XE2 den folgenden Output, wenn ich UNICODE_RTL_DATABASE in jcld16win32.inc aktiviere. Vielleicht liegen bei Dir irgendwo veraltete Includes rum die Dein Programm verwendet.
Code:
RTLVersion: 23.0
HAS_UNIT_CHARACTER UNICODE_RTL_DATABASE
Delphi-Quellcode:
program Project31;
{$APPTYPE CONSOLE} {$I jcl.inc} begin WriteLn('RTLVersion: ', RTLVersion:2:1); {$IFDEF HAS_UNIT_CHARACTER} WriteLn('HAS_UNIT_CHARACTER'); {$ENDIF HAS_UNIT_CHARACTER} {$IFDEF UNICODE_RTL_DATABASE} WriteLn('UNICODE_RTL_DATABASE'); {$ENDIF UNICODE_RTL_DATABASE} ReadLn; end. |
AW: Programm entschlacken: JclStrings nimmt 500KB im Projekt ein?
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo,
ich habe im Installer der JCL unter Conditional Defines -> Unicode Options das Häkchen bei Prefer RTL Database gesetzt und dann installiert. Dann passt es auch mit der Größe. |
AW: Programm entschlacken: JclStrings nimmt 500KB im Projekt ein?
Zitat:
Jetzt frage ich mich dann doch, warum diese Option scheinbar geändert wurde, denn damals hatte ich das nicht manuell eingestellt. Und zudem: Wozu ist sie überhaupt gut? Der einzige für mich sichtbare Unterschied ist die Dateigröße. |
AW: Programm entschlacken: JclStrings nimmt 500KB im Projekt ein?
Zitat:
Und bei beiden (darauf würde ich wetten) gibt es mindestens bei 2-3 Zeichen unterschiede gibt (so wie .NET, Java, Win32 und ElPack hier jeweils bei ein paar Zeichen eigene Interpretation der Unicode-Standards haben). |
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:35 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz