Programm entschlacken: JclStrings nimmt 500KB im Projekt ein?

[jbg]

Am 5.10.2010 wurden bei der JclStrings.pas Unit IFDEFs eingebaut, die ab Delphi 2009 nicht mehr eigene Char-Maps aufbauen, sondern auf die von der Characters.pas Unit bereit gestellte Tabelle zugreifen. Dadurch entfallen die 500 KB im BSS Segment.

Bugreport:
http://issuetracker.delphi-jedi.org/view.php?id=5333

Die Änderung hat es aber nicht in die aktuelle Release Version JCL 2.2 Build 3886 geschafft. Im Daily Build ist die Änderung aber enthalten.

[Keks]

Alles klar, dann werde ich mal aktualisieren und danach nochmal Rückmeldung geben.
Vielen Dank für die Info!

[Keks]

Vielen Dank, hat geklappt!

[Keks]

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?

[jbg]

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.

[Keks]

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:

{$IFNDEF HAS_UNIT_CHARACTER}
  {$UNDEF UNICODE_RTL_DATABASE}
{$ENDIF ~HAS_UNIT_CHARACTER}

(wozu das "~"?)

Habe in meiner Anwendung mal getestet und es ist weder UNICODE_RTL_DATABASE noch HAS_UNIT_CHARACTER definiert. Und nu?

[USchuster]

Zitat von Keks:

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:

{$IFNDEF HAS_UNIT_CHARACTER}
  {$UNDEF UNICODE_RTL_DATABASE}
{$ENDIF ~HAS_UNIT_CHARACTER}

(wozu das "~"?)

~ steht bei uns in diesem Fall dafür das dieses ENDIF einen Block beendet wo HAS_UNIT_CHARACTER nicht definiert ist (für den Compiler hat das keinerlei Bedeutung)

Zitat von Keks:

Habe in meiner Anwendung mal getestet und es ist weder UNICODE_RTL_DATABASE noch HAS_UNIT_CHARACTER definiert. Und nu?

HAS_UNIT_CHARACTER wird durch jedi.inc definiert und UNICODE_RTL_DATABASE durch jcldxx.inc (siehe jcl.inc; jcld15.inc für XE und jcld16win32.inc für XE2 Win32).

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.