Delphi 2009/2010 ohne Unicode?
Jens Lenge
was spricht ggf. dagegen, den Umstieg eines Projektes auf Delphi
2009/2010 so vorzunehmen, dass man zunï¿œchst bei AnsiStrings bleibt und
die Unicode-Umstellung erst spï¿œter macht?
Ich meine, den Typ AnsiString und alle zugehï¿œrigen Funktionen gibt es ja
auch in D2009+ noch. Man Kï¿œnnte also erstmal alle vorkommen von "string"
durch "AnsiString" ersetzen und wï¿œre auf der sicheren Seite.
Allerdings habe ich irgendwo im Hinterkopf, dass etwas gegen dieses
Vorgehen spricht. Es will mir nur nichts einfallen...
Jens
Arno Garrels
> Hallo Welt,
>
> was spricht ggf. dagegen, den Umstieg eines Projektes auf Delphi
> die Unicode-Umstellung erst später macht?
>
> Ich meine, den Typ AnsiString und alle zugehörigen Funktionen gibt es
> ja auch in D2009+ noch. Man Könnte also erstmal alle vorkommen von
> "string" durch "AnsiString" ersetzen und wäre auf der sicheren Seite.
>
> Allerdings habe ich irgendwo im Hinterkopf, dass etwas gegen dieses
> Vorgehen spricht. Es will mir nur nichts einfallen...
Man handelt sich jede Menge implizite Stringumwandlungen mit den
entsprechenden Warnungen ein. Dass, was mit Ansi-Delphi die Windows
API intern erledigte wird damit in die Anwendung verlagert.
Nicht alle RTL-Funktionen und Typen gibt es als Ansi-Variante,
IntToStr z.B., auch TStrings und Abkömmlinge gibt es nur als
Unicode-Variante. Aber prinzipiell sollte das klappen, hab
ich selbst nie getestet. Ob es wirklich einfacher ist als gleich
auf Unicode umzustellen, wage ich zu bezweifeln.
--
Arno Garrels
Hubert Seidel
"Arno Garrels" <arno.g...@gmx.de> schrieb im
Newsbeitrag news:hbn6c5$v0r$1...@online.de...
...
>Nicht alle RTL-Funktionen und Typen gibt es als Ansi-Variante,
>IntToStr z.B., auch TStrings und Abk�mmlinge gibt es nur als
>Unicode-Variante. Aber prinzipiell sollte das klappen, hab
Ein einfachen ANSI-Text kann man nicht mehr mit .LoadFromFile laden?
Dann wird es bestimmt wieder einen haufen bunter
Fremdkomponenten geben, bei denen man sich nicht
entscheiden kann, welche Bugs man haben m�chte :-(
Wir werden es ja sehen...
mfg.
Herby
--
http://www.hubert-seidel.eu
Arno Garrels
> Hallo Arno,
>
> "Arno Garrels" <arno.g...@gmx.de> schrieb im
> Newsbeitrag news:hbn6c5$v0r$1...@online.de...
>
> ...
>> Nicht alle RTL-Funktionen und Typen gibt es als Ansi-Variante,
>> Unicode-Variante. Aber prinzipiell sollte das klappen, hab
>
> Ein einfachen ANSI-Text kann man nicht mehr mit .LoadFromFile laden?
Kann man, ist sogar der Standard! Der text wird aber nach UTF-16
konvertiert weil das der neue default Stringtyp in Delphi >= 2009
ist.
>
> Dann wird es bestimmt wieder einen haufen bunter
> Fremdkomponenten geben, bei denen man sich nicht
> entscheiden kann, welche Bugs man haben möchte :-(
Verstehe ich nicht, hast du wenigstens mal D2010/D2009
in der Demoversion getestet?
--
Arno Garrels
Jens Lenge
> Man handelt sich jede Menge implizite Stringumwandlungen mit den
> entsprechenden Warnungen ein. Dass, was mit Ansi-Delphi die Windows
> API intern erledigte wird damit in die Anwendung verlagert.
> Nicht alle RTL-Funktionen und Typen gibt es als Ansi-Variante,
> IntToStr z.B., auch TStrings und Abkï¿œmmlinge gibt es nur als
> Unicode-Variante. Aber prinzipiell sollte das klappen [...]
Es wï¿œre wichtig, dass es erstmal klappt, Warnings hin oder her.
> Ob es wirklich einfacher ist als gleich
> auf Unicode umzustellen, wage ich zu bezweifeln.
Ist eher ein Sachzwang, weil andere Dinge hï¿œhere Prioritï¿œt haben und
terminlich drï¿œcken. Dabei wï¿œrden uns die neuen (Nicht-Unicode-)Features
aus D2009/10 einiges vereinfachen, deshalb wï¿œrden wir gern umsteigen.
Zeit fï¿œr einen sauberen Unicodeumstieg wird es aber erst spï¿œter geben.
Der wird auch nicht trivial, weil wir bislang viele in D2007 noch
fehlende API-Calls selbst eingebaut haben (natï¿œrlich alle nur in der
ANSI-Variante) und an vieles Stellen noch implizit davon ausgegangen
wir, dass ein "Char" immer genau ein Zeichen ist.
@Alle:
Wer hat mit sowas schon Erfahrungen sammeln kï¿œnnen?
Was muss man neben
string => AnsiString
Char => AnsiChar
noch umstellen, damit "erstmal" alles wieder geht wie vorher?
Jens
Hubert Seidel
"Arno Garrels" <arno.g...@gmx.de> schrieb im
Newsbeitrag news:hbnls3$dcj$1...@online.de...
Hubert Seidel wrote:
> "Arno Garrels" schrieb:
>> Ein einfachen ANSI-Text kann man nicht mehr mit .LoadFromFile
>laden?
>
>Kann man, ist sogar der Standard! Der text wird aber nach UTF-
>16 konvertiert weil das der neue default Stringtyp in
>Delphi >= 2009 ist.
Und beim Speichern wieder nach ANSI?
>> Dann wird es bestimmt wieder einen haufen bunter
>> Fremdkomponenten geben, bei denen man sich nicht
>> entscheiden kann, welche Bugs man haben m�chte :-(
>
>Verstehe ich nicht, hast du wenigstens mal D2010/D2009
>in der Demoversion getestet?
Nein.
Mein Interesse bzgl. >=D2009 ist derzeit etwas ged�mpft...
Und nur weil UTF-8 noch schlimmer ist, wird mir UTF-16
nicht wirklich besser gefallen (Kennst ja meine Meinung ;-)
Naja... nach 16 Bit kam 32 Bit, und danach 64Bit.
Ist vermutlich nur eine Frage der Zeit bis sich UTF-32 etabliert.
Ich stelle mir vor, wenn z.b. auch Kompressionsverfahren
an 32-Bit-Daten angepasst werden, das die Effizienz
diesbez�glich noch besser werden d�rfte.
Derzeit gehe ich davon aus, arbeiten alle Byte-basiert.
Hans-Peter Diettrich
> Ich stelle mir vor, wenn z.b. auch Kompressionsverfahren
> an 32-Bit-Daten angepasst werden, das die Effizienz
> diesbez�glich noch besser werden d�rfte.
Nur schlecher :-(
> Derzeit gehe ich davon aus, arbeiten alle Byte-basiert.
Richtig, und sie arbeiten mit Byte-Bl�cken variabler L�nge.
Nehmen wir mal ASCII Daten, z.B. 'abcabcabc'. Mit 32 Bit Einheiten lie�e
sich da garnichts komprimieren :-(
DoDi
Hubert Seidel
"Hans-Peter Diettrich" <DrDiet...@aol.com> schrieb im
Newsbeitrag news:7ka1q0F...@mid.individual.net...
Bei 32-Bit-Kompression und bei UTF-32-Daten s�he das so aus:
Die Zeichen 'abcabcabc' belegen auf in der Datei
'...a...b...c...a...b...c...a...b...c' 4 mal mehr Platz.
Komprimiert st�nde vereinfacht: 3x'...a...b...c'
Peter Eckweiler
> @Alle:
> Wer hat mit sowas schon Erfahrungen sammeln kï¿œnnen?
> Was muss man neben
>
> string => AnsiString
> Char => AnsiChar
ich habe mittlerweile mehrere Projekte auf Delphi 2009 umgestellt. Meine
Lï¿œsung war allerdings, nicht auf AnsiChar umzusteigen, sondern erst einmal
alles unverï¿œndert laufen zu lassen.
Ergebnis:
Projekt 1 (ca. 50.000 Zeilen Code) -> 2 Zeilen geï¿œndert, um GetUserNameA
richtig zu behandeln.
Projekt 2 (ca. 20.000 Zeilen Code) -> Keinerlei ï¿œnderungen erforderlich
Projekt 3 (ca. 450.000 Zeilen Code) -> ein paar hundert ï¿œnderungen,
insbesondere falsch deklarierte API-Aufrufe und Anpassungen in der
Kommunikation mit COM.
Insgesamt muss ich sagen, dass alle Umstellungen relativ einfach zu
realisieren waren.
Der Zugriff auf Datenbanken funktioniert auf Anhieb (ADO), INI-Files,
LoadFromFile... etc. arbeiten mit automatischer Konvertierung beim Lesen und
Schreiben.
Was nicht geht: Annahmen ￜber die Byte-Grￜￜe von Zeichen, RTF-Textfelder,
ï¿œbergabe von Strings an z.B. Word ï¿œber Automation. In allen Fï¿œllen ist eine
explizite Code-Anpassung erforderlich bzw. eine korrekte Spezifizierung der
Methoden-Deklaration.
Wenn Strings in der Form for i:= 1 to length(String) verarbeitet werden, ist
es ï¿œbrigens kein Problem. Erst bei einer Manipulation ï¿œber einen anderen
Variablentyp, etwa Array of Byte, wird es garstig.
Ich hï¿œtte nie gedacht, dass es so problemlos gehen wï¿œrde. In Abhï¿œngigkeit
vom vorhandenen Code kann die Erfahrung natï¿œrlich auch ganz anders aussehen.
Gruￜ,
Peter
Arno Garrels
> Hallo Arno,
>
> "Arno Garrels" <arno.g...@gmx.de> schrieb im
> Newsbeitrag news:hbnls3$dcj$1...@online.de...
>
> Hubert Seidel wrote:
>> "Arno Garrels" schrieb:
>>> Ein einfachen ANSI-Text kann man nicht mehr mit .LoadFromFile laden?
>>
>> Kann man, ist sogar der Standard! Der text wird aber nach UTF-
>> 16 konvertiert weil das der neue default Stringtyp in
>> Delphi >= 2009 ist.
>
> Und beim Speichern wieder nach ANSI?
Das ist der Standard, Stichwort: Kompatibilität!
Alternativ kann mit einem anderen Encoding gespeichert
werden, also auch mit einem anderen Ansi-Zeichensatz
als dem aktuellen System-Ansi-Zeichensatz.
>
>>> Dann wird es bestimmt wieder einen haufen bunter
>>> Fremdkomponenten geben, bei denen man sich nicht
>>> entscheiden kann, welche Bugs man haben möchte :-(
>>
>> Verstehe ich nicht, hast du wenigstens mal D2010/D2009
>> in der Demoversion getestet?
>
> Nein.
> Mein Interesse bzgl. >=D2009 ist derzeit etwas gedämpft...
> Und nur weil UTF-8 noch schlimmer ist, wird mir UTF-16
> nicht wirklich besser gefallen (Kennst ja meine Meinung ;-)
Deine Meinung zu UTF-16 bleibt mir ein vollkommenes Rätsel.
Einmal nach UTF-16 konvertiert kann der UnicodeString ohne
weitere Konvertierung der Windows API übergeben werden und
in der GUI angezeigt werden, wenn das kein Vorteil ist?
Es bedeutet unterm Strich _weniger_ Konvertierungen!
Wenn du einen AnsiString in einer Ansi-Anwendung anzeigst
oder nur einmal AnsiUpperCase aufrufst hat Windows den String
schon intern hin und her konvertiert!
--
Arno Garrels
Hans-Peter Diettrich
>> Nehmen wir mal ASCII Daten, z.B. 'abcabcabc'. Mit 32 Bit Einheiten
> lie�e
>> sich da garnichts komprimieren :-(
>
> Bei 32-Bit-Kompression und bei UTF-32-Daten s�he das so aus:
>
> Die Zeichen 'abcabcabc' belegen auf in der Datei
> '...a...b...c...a...b...c...a...b...c' 4 mal mehr Platz.
> Komprimiert st�nde vereinfacht: 3x'...a...b...c'
Wobei es dem "3x" egal ist, ob danach Bytes oder andere Typen kommen.
Die L�nge der zu wiederholenden Daten mu� jedesmal angegeben werden, und
ob da nun 3 (Longs) oder 12 (Bytes) als L�nge steht, macht keinen
signifikanten Unterschied.
Aber die L�nge des zu wiederholenden Blocks w�re bei 32 Bit Einheiten
auf Vielfache von 4 Bytes beschr�nkt, w�hrend bei Bytes jede beliebige
L�nge m�glich ist. Entsprechend m�ssen die zu wiederholenden Bl�cke an
Vielfachen der Datengr��e stehen, sonst k�nnen sie nicht komprimiert werden.
Dein Vorschlag w�re damit auf reine UCS4/UTF-32 Dateien beschr�nkt, und
k�nnte bessere Ergebnisse auch nur dann liefern, wenn die zu
wiederholenden Bl�cke so gro� sind, da� die k�rzere L�ngenangabe
tats�chlich eine Rolle spielt. Das d�rfte aber kaum jemals der Fall
sein, denn zu einer (angenommen) 1-Byte L�ngenangabe geh�ren dann
maximal 256 Bytes oder Longs, d.h. die L�ngenangaben machen dann weit
unter 1% der Dateigr��e aus.
DoDi
Hans-Peter Diettrich
> ich habe mittlerweile mehrere Projekte auf Delphi 2009 umgestellt. Meine
> Lï¿œsung war allerdings, nicht auf AnsiChar umzusteigen, sondern erst
> einmal alles unverï¿œndert laufen zu lassen.
>
> Ergebnis:
>
> Projekt 1 (ca. 50.000 Zeilen Code) -> 2 Zeilen geï¿œndert, um GetUserNameA
> richtig zu behandeln.
>
> Projekt 2 (ca. 20.000 Zeilen Code) -> Keinerlei ï¿œnderungen erforderlich
>
> Projekt 3 (ca. 450.000 Zeilen Code) -> ein paar hundert ï¿œnderungen,
> insbesondere falsch deklarierte API-Aufrufe und Anpassungen in der
> Kommunikation mit COM.
Bei solchen Angaben beschleicht mich immer der Verdacht, daￜ nur
diejenigen (offensichtlichen) Problemstellen korrigiert wurden, die der
Compiler anhand der Datentypen erkennen kann. Das soll kein persï¿œnlicher
Vorwurf sein, einfach nur eine allgemeine Feststellung. Ein Nachweis,
daￜ der ￜberarbeitete Code keine logischen Fehler mehr enthￜlt, ist wie
bei allen Bugs praktisch nicht mï¿œglich.
> Insgesamt muss ich sagen, dass alle Umstellungen relativ einfach zu
> realisieren waren.
Das ist sehr erfreulich, sollte aber nicht dazu fï¿œhren, bei weiteren
Umstellungen auf eine genaue Durchsicht des Codes zu verzichten. Der
Mensch ist von Natur aus faul ;-)
> Wenn Strings in der Form for i:= 1 to length(String) verarbeitet werden,
> ist es ï¿œbrigens kein Problem.
Solange man es nur mit Zeichen aus der BMP zu tun hat. Ich gehe mal
davon aus, daￜ dies bei Deinen Anwendungen der Fall ist.
> Erst bei einer Manipulation ï¿œber einen
> anderen Variablentyp, etwa Array of Byte, wird es garstig.
>
> Ich hï¿œtte nie gedacht, dass es so problemlos gehen wï¿œrde. In
> Abhï¿œngigkeit vom vorhandenen Code kann die Erfahrung natï¿œrlich auch ganz
> anders aussehen.
CodeGear hat sich bei der Umstellung sehr viel Mï¿œhe gegeben, und die
zahlt sich nun aus :-)
DoDi
Arno Garrels
> @Alle:
> Wer hat mit sowas schon Erfahrungen sammeln können?
> Was muss man neben
>
> string => AnsiString
> Char => AnsiChar
In der Liste fehlt wenigstens noch "PChar => PAnsiChar".
--
Arno Garrels
Arno Garrels
>> Wenn Strings in der Form for i:= 1 to length(String) verarbeitet
>
> Solange man es nur mit Zeichen aus der BMP zu tun hat. Ich gehe mal
Natürlich kann man so jeden UnicodeString verarbeiten. Ob der OP auf
Surrogat-Paare prüft oder nicht wissen wir nicht.
--
Arno Garrels
Jens Lenge
>> string => AnsiString
>> Char => AnsiChar
> In der Liste fehlt wenigstens noch "PChar => PAnsiChar".
Ja, stimmt natï¿œrlich.
Hab ich sonst noch was vergessen?
Jens
Arno Garrels
> Arno Garrels wrote:
>>> string => AnsiString
>>> Char => AnsiChar
>> In der Liste fehlt wenigstens noch "PChar => PAnsiChar".
>
> Hab ich sonst noch was vergessen?
Probier das einfach mal und guck dir die Compiler-Warnungen
genau an (vieleicht überlegst du es dir dann ja nocheinmal ;)
Um bei der Menge der zu erwartenden Warnungen noch den Überblick
zu behalten, kannst du die selectiv auch per Unit ein- und
ausschalten.
{$WARN IMPLICIT_STRING_CAST ON/OFF}
{$WARN IMPLICIT_STRING_CAST_LOSS ON/OFF}
{$WARN EXPLICIT_STRING_CAST ON/OFF}
{$WARN EXPLICIT_STRING_CAST_LOSS ON/OFF}
Ich würde entweder auf Unicode mit D2009/2010 umstellen oder beim
alten Ansi-Compiler (D2007) bleiben.
--
Arno Garrels
Hubert Seidel
"Arno Garrels" <arno.g...@gmx.de> schrieb im
Newsbeitrag news:hbp5rt$i63$1...@online.de...
>Hubert Seidel wrote:
...
>> Mein Interesse bzgl. >=D2009 ist derzeit etwas ged�mpft...
>> Und nur weil UTF-8 noch schlimmer ist, wird mir UTF-16
>> nicht wirklich besser gefallen (Kennst ja meine Meinung ;-)
>
>Deine Meinung zu UTF-16 bleibt mir ein vollkommenes R�tsel.
Meine Kurzfassung:
EVA = Eingabe/Verarbeitung/Ausgabe
Wenn Eingabe und Ausgabe ANSI ist,
dann m�chte ich in Bauch nicht mit Unicode
arbeiten da zum einen die Eingangskonvertierung
und die Ausgangskonvertierung �berfl�ssig ist,
zum anderen die Verarbeitung im "Bauch"
toppelt so viele Bytes transferieren muss.
Ich gehe mal davon aus, das die 256 darstellbaren
Zeichen in UTF-16 keine Surrogate-Pairs ben�tigen.
>Einmal nach UTF-16 konvertiert kann der UnicodeString ohne
>weitere Konvertierung der Windows API �bergeben werden und
>in der GUI angezeigt werden, wenn das kein Vorteil ist?
Wenn ich jedoch bei Ansi bleiben kann, und weiterhin
zur Stringmanipulation Ansi-Funktionen zur Verf�gung habe,
dann habe ich halb so viel Speicherdurchsatz.
Und nur weil ein W-API-Aufruf pr�zise mit allen
m�glichen Zeichen umgehen kann, geht es nicht besser,
wenn eh nur die 256 m�glichen aus ANSI 1252 enthalten sind.
>Es bedeutet unterm Strich _weniger_ Konvertierungen!
Wenn ich ein Ansi-String mit einer Ansi-Funktion
aufrufe k�nnte, warum sollte konvertieren wollen?
>Wenn du einen AnsiString in einer Ansi-Anwendung anzeigst
>oder nur einmal AnsiUpperCase aufrufst hat Windows den String
>schon intern hin und her konvertiert!
Bei Delphi5 sind ja noch zum Gl�ck etliche Funktionen nativ vorhanden.
Ich kenne diesen Nachteil demnach noch gar nicht.
Wenn es darauf ankommt, dann nutze ich auch gerne
mal eine eigene sehr performante Funktion.
M�glicherweise nich 100%tig, aber
ausreichend korrekt f�r die Aufgabe.
Schade wenn ich das dann nur noch machen muss.
Hubert Seidel
"Hans-Peter Diettrich" <DrDiet...@aol.com> schrieb
im Newsbeitrag news:7kb534F...@mid.individual.net...
> Hubert Seidel schrieb:
...
> > Die Zeichen 'abcabcabc' belegen auf in der Datei
> > '...a...b...c...a...b...c...a...b...c' 4 mal mehr Platz.
> > Komprimiert st�nde vereinfacht: 3x'...a...b...c'
>
> Wobei es dem "3x" egal ist, ob danach Bytes oder andere Typen kommen.
Nein. Egal ist es nicht. Aber das ist ja auch kein Delphi-Thema.
..
> Aber die L�nge des zu wiederholenden Blocks w�re bei 32 Bit Einheiten
> auf Vielfache von 4 Bytes beschr�nkt, w�hrend bei Bytes jede beliebige
> L�nge m�glich ist. Entsprechend m�ssen die zu wiederholenden Bl�cke an
> Vielfachen der Datengr��e stehen, sonst k�nnen sie nicht komprimiert
werden.
>
> Dein Vorschlag w�re damit auf reine UCS4/UTF-32 Dateien beschr�nkt,
und
Das eine muss das andere ja nicht ausschlie�en.
> k�nnte bessere Ergebnisse auch nur dann liefern, wenn die zu
> wiederholenden Bl�cke so gro� sind, da� die k�rzere L�ngenangabe
> tats�chlich eine Rolle spielt. Das d�rfte aber kaum jemals der Fall
> sein, denn zu einer (angenommen) 1-Byte L�ngenangabe geh�ren dann
> maximal 256 Bytes oder Longs, d.h. die L�ngenangaben machen dann weit
> unter 1% der Dateigr��e aus.
Nicht unbedingt. Im "Kompressionsfenster" m�ssen mehr Kombinationen
vorgehalten werden, im vergleich zu ANSI-Text.
'abcd' hat 4 unterschiedliche Codes 'a', 'b', 'c' und 'd'
'...a...b...c...d' hat 5: '...', 'a', 'b', 'c' und 'd'.
4 unterschiedliche k�nnen mit 2 bit codiert werden, 5 mit 3.
Bei 32-Bit-Anpassung g�be es auch nur 4 Codes.
'...a', '...b', '...c', '...d'
Ich denke, _ich_ werde zu diesem Thema aus dem Bauch
heraus keine Absch�tzung machen wie effizient das ist.
Jens Lenge
> Probier das einfach mal und guck dir die Compiler-Warnungen
Guter Tipp, danke!
> Ich wï¿œrde entweder auf Unicode mit D2009/2010 umstellen oder beim
> alten Ansi-Compiler (D2007) bleiben.
D2009/10 sind vor allem wegen der Generics interessant, das in D2007 von
Hand nachzubauen dï¿œrfte sehr viel unnï¿œtige Arbeit machen.
Auï¿œerdem soll das Projekt ja nicht auf ewige Zeiten ANSI bleiben, die
Umstellung soll nur hinausgezï¿œgert werden kï¿œnnen, weil andere Sachen
termlich drï¿œckender sind. Generics hingegen sollen sofort eingesetzt werden.
Jens
Hubert Seidel
"Arno Garrels" <arno.g...@gmx.de> schrieb im
Newsbeitrag news:hbp5rt$i63$1...@online.de...
>Hubert Seidel wrote:
...
>> Mein Interesse bzgl. >=D2009 ist derzeit etwas ged�mpft...
>> Und nur weil UTF-8 noch schlimmer ist, wird mir UTF-16
>> nicht wirklich besser gefallen (Kennst ja meine Meinung ;-)
...
>Wenn du einen AnsiString in einer Ansi-Anwendung anzeigst
>oder nur einmal AnsiUpperCase aufrufst hat Windows den String
>schon intern hin und her konvertiert!
Mich w�rde mal interessieren ob folgene Funktion
>=D2009 - tauglich ist, und welcher Faktor ausgegeben wird:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[umyansi.pas]
unit umyansi;
interface
function MyAnsiUpperCase(const aStr:AnsiString):AnsiString;
implementation
uses
SysUtils;
var
gAu:array[#0..#255] of char;
function MyAnsiUpperCase(const aStr:AnsiString):AnsiString;
var
l:integer;
pac:PAnsiChar;
begin
l:=Length(aStr);
SetString(Result, PChar(aStr), l);
if (l>0) then
begin
pac:=@aStr[1];
while (l>8) do
begin dec(l,8);
pac[0]:=gAu[pac[0]];
pac[1]:=gAu[pac[1]];
pac[2]:=gAu[pac[2]];
pac[3]:=gAu[pac[3]];
pac[4]:=gAu[pac[4]];
pac[5]:=gAu[pac[5]];
pac[6]:=gAu[pac[6]];
pac[7]:=gAu[pac[7]];
inc(pac,8);
end;
while (l>0) do
begin dec(l);
pac[0]:=gAu[pac[0]];
inc(pac);
end;
end;
end;
procedure init;
var
i:char;
s:string;
begin
for i:=Low(gAu) to High(gAu) do
begin
s:=AnsiUpperCase(i);
if (Length(s)=1)
then gAu[i]:=s[1]
else gAu[i]:=#0;
end;
end;
initialization init;
end.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[main.pas]
...
implementation
{$R *.DFM}
uses
umyansi;
function RdTsc:int64;
asm
db $0F,$31 { RdTsc }
end;
procedure TForm1.Button1Click(Sender: TObject);
var
s,t:ansistring;
i:integer;
t1,t2,t3:int64;
m12,m23,e1,e2:int64;
begin
t:='';
for i:=1 to 100 do t:=t+'Hello World!';
//---
m12:=MaxInt; m23:=m12;
for i:=1 to 1000 do
begin
t1:=RdTsc;
t2:=RdTsc;
s:=MyAnsiUpperCase(t);
t3:=RdTsc;
if (t2-t1<m12) then m12:=t2-t1;
if (t3-t2<m23) then m23:=t3-t2;
end;
e1:=m23-m12;
//---
m12:=MaxInt; m23:=m12;
for i:=1 to 1000 do
begin
t1:=RdTsc;
t2:=RdTsc;
s:=AnsiUpperCase(t);
t3:=RdTsc;
if (t2-t1<m12) then m12:=t2-t1;
if (t3-t2<m23) then m23:=t3-t2;
end;
e2:=m23-m12;
//---
Caption:=FormatFloat('0.000', e2/e1)+' => '+s;
end;
...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Evtl. bei SetString besonderes beachten?
MyAnsiUpperCase ist bei mir (D5) (je nach Betriebssystem)
5.5 (W2k) bis 17.2 (WinMe) mal schneller als AnsiUpperCase.
Faktoren bei unterschiedlichen Delphi- und Betriebssysteme
w�rden mich sehr interessieren.... wer Lust hat...
Vor allem Verbesserungen w�rden mich sehr freuen :-)
Hubert Seidel
"Hubert Seidel" <nos...@hubert-seidel.de> schrieb im
Newsbeitrag news:hbqt8n$af6$02$1...@news.t-online.com...
...
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[umyansi.pas]
...
> var
> gAu:array[#0..#255] of char;
...
Sollte wohl besser:
var
gAu:array[#0..#255] of AnsiChar;
sein... ####
Ob das ein Geschwindigkeitsunterschied ausmacht,
w�re ja auch interessant....
Hans-Peter Diettrich
> Meine Kurzfassung:
> EVA = Eingabe/Verarbeitung/Ausgabe
>
> Wenn Eingabe und Ausgabe ANSI ist,
> dann m�chte ich in Bauch nicht mit Unicode
> arbeiten da zum einen die Eingangskonvertierung
> und die Ausgangskonvertierung �berfl�ssig ist,
> zum anderen die Verarbeitung im "Bauch"
> toppelt so viele Bytes transferieren muss.
Das sehe ich genauso.
> Ich gehe mal davon aus, das die 256 darstellbaren
> Zeichen in UTF-16 keine Surrogate-Pairs ben�tigen.
Allgemein: Zeichen aus der Unicode BMP.
>> Einmal nach UTF-16 konvertiert kann der UnicodeString ohne
>> weitere Konvertierung der Windows API �bergeben werden und
>> in der GUI angezeigt werden, wenn das kein Vorteil ist?
>
> Wenn ich jedoch bei Ansi bleiben kann, und weiterhin
> zur Stringmanipulation Ansi-Funktionen zur Verf�gung habe,
> dann habe ich halb so viel Speicherdurchsatz.
In Cobol wird zwischen Usage=Display und Usage=Computational
unterschieden. Vielleicht sollte man das in Delphi genauso sehen, bei
der Festlegung des jeweils passenden Stringtyps.
> Und nur weil ein W-API-Aufruf pr�zise mit allen
> m�glichen Zeichen umgehen kann, geht es nicht besser,
> wenn eh nur die 256 m�glichen aus ANSI 1252 enthalten sind.
Bei ASCII war ToUpper und ToLower eine reine Funktion, die ein Bit im
Zeichen entsprechend gesetzt hat.
Bei Ansi (SBCS) ist f�r jede Codepage eine eigene Tabelle notwendig,
mindestens f�r den non-ASCII Teil. Bei MBCS mehrere Tabellen, mit
entsprechend mehrstufigem Lookup.
Bei Unicode (UTF-32) wird nur eine Tabelle ben�tigt, die aber durch die
vielen L�cher ebenfalls baumartig mit mehrstufigem Lookup aufgebaut sein
d�rfte.
Bei UTF-16 f�r UCS4 werden solche Funktionen und die �bergebenen
Parameter noch aufwendiger, da auch bei einzelnen Zeichen immer mit
Strings (Surrogat-Paare aus mehreren WideChars) zu rechnen ist.
Damit d�rfte klar sein, da� eine Beschr�nkung auf einen bestimmten
Zeichensatz deutliche Optimierungsm�glichkeiten bietet. Dann kommt es
drauf an, ob diese Optimierungsm�glichkeiten in der RTL wahrgenommen
werden, z.B. in Abh�ngigkeit vom String-Typ oder -Encoding.
Ein Anwendungsprogrammierer mu� bei der Verwendung von Unicode schon
genau angeben (und sicherstellen), warum z.B. seine indizierten Zugriffe
auf String-Elemente �berhaupt zul�ssig sind. Bei Ansi war das einfach,
da eine Codepage entweder SBCS oder MBCS ist. Bei Unicode kann man sich
zwar entsprechend auf die BMP beschr�nken, es gibt dann aber keine
Sperren, welche die Einhaltung dieser Annahme sicherstellen.
>> Es bedeutet unterm Strich _weniger_ Konvertierungen!
>
> Wenn ich ein Ansi-String mit einer Ansi-Funktion
> aufrufe k�nnte, warum sollte konvertieren wollen?
Was die Benennung der Delphi-Funktionen betrifft, da hat sich CodeGear
dazu entschlossen, die alten Namen aus Kompatibilit�tsgr�nden
beizubehalten, aber die Ansi Parameter durch Unicode zu ersetzen. Wenn
man das wei�, kann man bei Ansi-Texten um diese Funktionen einen weiten
Bogen machen. Benutzerfreundlicher w�re jedenfalls eine eigene
(�berladene) Implementierung f�r AnsiString Parameter.
>> Wenn du einen AnsiString in einer Ansi-Anwendung anzeigst
>> oder nur einmal AnsiUpperCase aufrufst hat Windows den String
>> schon intern hin und her konvertiert!
Ich hab's selber nicht nachgepr�ft, aber wenn ein WinAPI ToUpperA nach
ToUpperW delegiert, dann ist das eine herbe Bremse. (s.o.)
DoDi
Hans-Peter Diettrich
>>> Die Zeichen 'abcabcabc' belegen auf in der Datei
>>> '...a...b...c...a...b...c...a...b...c' 4 mal mehr Platz.
>>> Komprimiert st�nde vereinfacht: 3x'...a...b...c'
>> Wobei es dem "3x" egal ist, ob danach Bytes oder andere Typen kommen.
>
> Nein. Egal ist es nicht. Aber das ist ja auch kein Delphi-Thema.
Was ist daran nicht egal?
>> Dein Vorschlag w�re damit auf reine UCS4/UTF-32 Dateien beschr�nkt,
> und
>
> Das eine muss das andere ja nicht ausschlie�en.
Bytes schlie�en Longs nicht aus, umgekehrt gilt das nicht.
>> k�nnte bessere Ergebnisse auch nur dann liefern, wenn die zu
>> wiederholenden Bl�cke so gro� sind, da� die k�rzere L�ngenangabe
>> tats�chlich eine Rolle spielt. Das d�rfte aber kaum jemals der Fall
>> sein, denn zu einer (angenommen) 1-Byte L�ngenangabe geh�ren dann
>> maximal 256 Bytes oder Longs, d.h. die L�ngenangaben machen dann weit
>> unter 1% der Dateigr��e aus.
>
> Nicht unbedingt. Im "Kompressionsfenster" m�ssen mehr Kombinationen
> vorgehalten werden, im vergleich zu ANSI-Text.
Im Falle von RLE trifft das IMO nicht zu.
Zudem ist hier ein Vergleich von Ansi und Unicode nicht unbedingt
sinnvoll, wenn sich eine Unicode-Datei (und damit das Fenster) alleine
durch Konvertierung in Ansi oder UTF-8 auf ein Viertel schrumpfen l��t.
> 'abcd' hat 4 unterschiedliche Codes 'a', 'b', 'c' und 'd'
> '...a...b...c...d' hat 5: '...', 'a', 'b', 'c' und 'd'.
> 4 unterschiedliche k�nnen mit 2 bit codiert werden, 5 mit 3.
Bei welchem Komprimierungsverfahren bist Du jetzt? Und Du betrachtest
hier die Interna, nicht das Ergebnis.
DoDi
Hans-Peter Diettrich
>>> Wenn Strings in der Form for i:= 1 to length(String) verarbeitet
>>> werden, ist es ï¿œbrigens kein Problem.
>> Solange man es nur mit Zeichen aus der BMP zu tun hat. Ich gehe mal
>> davon aus, daￜ dies bei Deinen Anwendungen der Fall ist.
>
> Natï¿œrlich kann man so jeden UnicodeString verarbeiten. Ob der OP auf
> Surrogat-Paare prï¿œft oder nicht wissen wir nicht.
Man kann nicht ausschlieￜen, daￜ so eine Prￜfung vergessen wurde. Anders
bei einer Umstellung auf Iteratoren, die lassen keinen Raum fï¿œr solche
Fehler.
DoDi
Rene Kadner
ich habe letztens ein grￜￜeres Projekt von D2006 nach D2009 "portiert". Ich
hatte anfangs ï¿œhnliche Bedenken, habe es aber einfach mal darauf ankommen
lassen.
Erstaunlicherweise gab es nur relativ wenige Stellen, an denen der Compiler
etwas auszusetzen hatte (naja, ein paar Hinweise habe ich spï¿œter
ausgeschaltet). Zuvor hatte ich mir noch alle zusï¿œtzliche Bibliotheken
(RxLib, DragDrop, QR, AC) in der aktuellsten Version besorgt.
Ich hatte eher zwei Probleme zur Laufzeit. Bei den RX Tools muï¿œte ich
TPropsStorage.LoadAnyProperty und TPropsStorage.StoreAnyProperty um den
PropertyType tkUString erweitern und bei meinen XML Exportern musste ich die
Textvariablen von String auf AnsiString und bei direkten Filezugriffen
(FileRead, FileWrite) die Buffer auf PAnsiChar stellen.
Das war dann auch schon alles.
Gruￜ
Renￜ
Arno Garrels
> Vor allem Verbesserungen würden mich sehr freuen :-)
Nette Idee!
Erstmal ein Bugfix :
> SetString(Result, PChar(aStr), l);
> if (l>0) then
> begin
> pac:=@aStr[1]; <==????
pac:=@Result[1];
> MyAnsiUpperCase ist bei mir (D5) (je nach Betriebssystem)
> 5.5 (W2k) bis 17.2 (WinMe) mal schneller als AnsiUpperCase.
>
> Faktoren bei unterschiedlichen Delphi- und Betriebssysteme
> würden mich sehr interessieren.... wer Lust hat...
Bei mir ~4,4 (XP) sowohl D2009 als auch D7, beide mit dem
selben FastMM4.
Aber jetzt kommt's! Wenn ich deine ANSI-Variante in D2009 mit
AnsiUpperCase(UnicodeString) vergleiche, sind es nur noch ~2,4.
> Vor allem Verbesserungen würden mich sehr freuen :-)
procedure init;
var
i : AnsiChar;
begin
for i:=Low(gAu) to High(gAu) do
gAu[i] := i;
CharUpperBuffA(gAu, 256);
end;
--
Arno Garrels
Arno Garrels
>>> Mein Interesse bzgl. >=D2009 ist derzeit etwas gedämpft...
>>> Und nur weil UTF-8 noch schlimmer ist, wird mir UTF-16
>>> nicht wirklich besser gefallen (Kennst ja meine Meinung ;-)
>>
>> Deine Meinung zu UTF-16 bleibt mir ein vollkommenes Rätsel.
>
> Meine Kurzfassung:
> EVA = Eingabe/Verarbeitung/Ausgabe
>
> Wenn Eingabe und Ausgabe ANSI ist,
> dann möchte ich in Bauch nicht mit Unicode
> arbeiten da zum einen die Eingangskonvertierung
> und die Ausgangskonvertierung überflüssig ist,
Wie gesagt, ist das das Standardverhalten.
> zum anderen die Verarbeitung im "Bauch"
> toppelt so viele Bytes transferieren muss.
Dann nimm einen FileStream und einen AnsiString und schon
ist die Ansiwelt (fast) wieder in Ordnung ;)
> Ich gehe mal davon aus, das die 256 darstellbaren
> Zeichen in UTF-16 keine Surrogate-Pairs benötigen.
Jedenfalls nicht die Zeichen eines SBCS.
>
>> Einmal nach UTF-16 konvertiert kann der UnicodeString ohne
>> weitere Konvertierung der Windows API übergeben werden und
>> in der GUI angezeigt werden, wenn das kein Vorteil ist?
>
> Wenn ich jedoch bei Ansi bleiben kann,
Das kannst du ja mit D2010/2009 auch.
> und weiterhin
> zur Stringmanipulation Ansi-Funktionen zur Verfügung habe,
Die meisten oder alle der AnsiXyz-Funktionen der RTL
waren immer schon ein Wrapper um das WinAPI, früher um die
A-Versionen seit D2009 um die W-Versionen.
Nur die ASCII-Routinen waren und sind nativ in der RTL
implementiert, z.B. UpperCase().
> dann habe ich halb so viel Speicherdurchsatz.
> Und nur weil ein W-API-Aufruf präzise mit allen
> möglichen Zeichen umgehen kann, geht es nicht besser,
> wenn eh nur die 256 möglichen aus ANSI 1252 enthalten sind.
Willst du Performance mit AnsiString dann vermeide den direkten
oder indirekten Aufruf der Win32 A-API, das gilt für
Ansi-Delphi genauso wie für Unicode-Delphi (W-API ist häufig
wesentlich schneller). Mit einem Unicode-Delphi sollte man dann
noch ein paar Routinen selbst als Ansi-Version bereitstellen,
z.B. IntToStrA, da sonst die Delphi RTL hin und her konvertiert.
In der Unit AnsiStrings.pas sind aber viele der alten ANSI-Routinen
als overloads enthalten.
>> Es bedeutet unterm Strich _weniger_ Konvertierungen!
>
> Wenn ich ein Ansi-String mit einer Ansi-Funktion
> aufrufe könnte, warum sollte konvertieren wollen?
s.o.
>
>> Wenn du einen AnsiString in einer Ansi-Anwendung anzeigst
>> oder nur einmal AnsiUpperCase aufrufst hat Windows den String
>> schon intern hin und her konvertiert!
>
> Bei Delphi5 sind ja noch zum Glück etliche Funktionen nativ vorhanden.
Aber nicht für ANSI sondern für ASCII Strings.
> Ich kenne diesen Nachteil demnach noch gar nicht.
> Wenn es darauf ankommt, dann nutze ich auch gerne
> mal eine eigene sehr performante Funktion.
Und die kannst du weiterhin in Delphi 2010/2009 benutzen.
--
Arno Garrels
Hans-Peter Diettrich
> Erste Erg�nzung/Korrektur:
> Sollte wohl besser:
> var
> gAu:array[#0..#255] of AnsiChar;
> sein... ####
Warum nicht gleich
gAu:array[AnsiChar] of AnsiChar;
Ggf. braucht man mehrere Tabellen, wenn man mit Strings aus
verschiedenen Codepages arbeiten mu�.
L��t sich da nicht mit XLAT noch mehr Tempo herausquetschen?
DoDi
Hans-Peter Diettrich
> die Textvariablen von String auf AnsiString und bei direkten
> Filezugriffen (FileRead, FileWrite) die Buffer auf PAnsiChar stellen.
Wï¿œre da nicht RawByteString geeigneter?
DoDi
Rudy Velthuis
> Hallo Jens,
>
> ich habe letztens ein grￜￜeres Projekt von D2006 nach D2009
> "portiert". Ich hatte anfangs ï¿œhnliche Bedenken, habe es aber einfach
> mal darauf ankommen lassen. Erstaunlicherweise gab es nur relativ
> wenige Stellen, an denen der Compiler etwas auszusetzen hatte (naja,
> ein paar Hinweise habe ich spï¿œter ausgeschaltet).
Kein gute Idee. Die gibt es meistens nicht umsonst. Sie einfach zu
ignorieren ist nicht der beste Weg, Fehler zu vermeiden und erst recht
nicht, wenn man von D2006 nach D2009 portiert.
--
Rudy Velthuis http://rvelthuis.de
"It has become appallingly obvious that our technology has
exceeded our humanity."
-- Albert Einstein
Hubert Seidel
"Arno Garrels" <arno.g...@gmx.de> schrieb im Newsbeitrag
news:hbs5gp$vve$2...@online.de...
>Hubert Seidel wrote:
>> Vor allem Verbesserungen w�rden mich sehr freuen :-)
>
>Nette Idee!
Danke :-)
>Erstmal ein Bugfix :
>
>> SetString(Result, PChar(aStr), l);
>> if (l>0) then
>> begin
>> pac:=@aStr[1]; <==????
>
>pac:=@Result[1];
Ups... hatte das bei Dir Auswirkungen?
Ich frage mich gerade, wieso das bei mir klappen konnte :-?
hmmm.. am const liegt es auch nicht.
Sehr gut aufgepasst :-)
>> MyAnsiUpperCase ist bei mir (D5) (je nach Betriebssystem)
>> 5.5 (W2k) bis 17.2 (WinMe) mal schneller als AnsiUpperCase.
>>
>> Faktoren bei unterschiedlichen Delphi- und Betriebssysteme
>> w�rden mich sehr interessieren.... wer Lust hat...
>
>Bei mir ~4,4 (XP) sowohl D2009 als auch D7, beide mit dem
>selben FastMM4.
>
>Aber jetzt kommt's! Wenn ich deine ANSI-Variante in D2009 mit
>AnsiUpperCase(UnicodeString) vergleiche, sind es nur noch ~2,4.
Cool! Bei doppelter Datenmenge ist Faktor x2 normal.
Also pro Unicode-Zeichen noch ca. ein halber Takt mehr, da 0.4 mehr.
Das best�tigt meine Prognose/Erfahrung: Mehr Speicher, mehr Zeit.
>> Vor allem Verbesserungen w�rden mich sehr freuen :-)
>
>procedure init;
>var
> i : AnsiChar;
>begin
> for i:=Low(gAu) to High(gAu) do
> gAu[i] := i;
> CharUpperBuffA(gAu, 256);
>end;
Ok. Und jetzt noch einen f�r den oberen Teil...
(oder wie war das mit dem Finder und der ganzen Hand ;-)
Hubert Seidel
"Hubert Seidel" <nos...@hubert-seidel.de> schrieb im
Newsbeitrag news:hbsssl$qg9$03$1...@news.t-online.com...
...
> >> Vor allem Verbesserungen w�rden mich sehr freuen :-)
> >
> >procedure init;
> >var
> > i : AnsiChar;
> >begin
> > for i:=Low(gAu) to High(gAu) do
> > gAu[i] := i;
> > CharUpperBuffA(gAu, 256);
> >end;
>
> Ok. Und jetzt noch einen f�r den oberen Teil...
> (oder wie war das mit dem Finder und der ganzen Hand ;-)
Ich habe die beiden Hinweise entspr. �bernommen.
Nun mein bzw. noch ein High-Light :-))
Mit einer etwas anderen Vorgehenseise
bekomme ich noch einmal 14% mehr Durchsatz:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[umyansi.pas]
unit umyansi;
interface
function MyAnsiUpperCase(const aStr:AnsiString):AnsiString;
implementation
uses
Windows;
var
gAu:array[AnsiChar] of AnsiChar;
function MyAnsiUpperCase(const aStr:AnsiString):AnsiString;
var
pic:PAnsiChar;
pac:PAnsiChar;
l:integer;
begin
l:=Length(aStr);
SetLength(Result, l);
if (l>0) then
begin
pic:=@aStr[1];
pac:=@Result[1];
while (l>8) do
begin dec(l,8);
pac[0]:=gAu[pic[0]];
pac[1]:=gAu[pic[1]];
pac[2]:=gAu[pic[2]];
pac[3]:=gAu[pic[3]];
pac[4]:=gAu[pic[4]];
pac[5]:=gAu[pic[5]];
pac[6]:=gAu[pic[6]];
pac[7]:=gAu[pic[7]];
inc(pac,8);
inc(pic,8);
end;
while (l>0) do
begin dec(l);
pac[0]:=gAu[pic[0]];
inc(pac);
inc(pic);
end;
end;
end;
(*
function MyAnsiUpperCase(const aStr:AnsiString):AnsiString;
var
l:integer;
pac:PAnsiChar;
begin
l:=Length(aStr);
SetString(Result, PAnsiChar(aStr), l);
if (l>0) then
begin
pac:=@Result[1];
while (l>8) do
begin dec(l,8);
pac[0]:=gAu[pac[0]];
pac[1]:=gAu[pac[1]];
pac[2]:=gAu[pac[2]];
pac[3]:=gAu[pac[3]];
pac[4]:=gAu[pac[4]];
pac[5]:=gAu[pac[5]];
pac[6]:=gAu[pac[6]];
pac[7]:=gAu[pac[7]];
inc(pac,8);
end;
while (l>0) do
begin dec(l);
pac[0]:=gAu[pac[0]];
inc(pac);
end;
end;
end;
*)
procedure init;
var
i:AnsiChar;
begin
for i:=Low(gAu) to High(gAu) do gAu[i]:=i;
CharUpperBuff(gAu, SizeOf(gAu));
end;
initialization init;
end.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[main.pas]
...
implementation
{$R *.DFM}
uses
umyansi;
function RdTsc:int64;
asm
db $0F,$31 { RdTsc }
end;
procedure TForm1.Button1Click(Sender: TObject);
var
s,t:ansistring;
i,l:integer;
t1,t2,t3:int64;
m12,m23,e1,e2:int64;
begin
t:='';
for i:=1 to 100 do t:=t+'Hello World!';
l:=Length(t);
Caption:=FormatFloat('0.000', e2/e1)+'; '+
FormatFloat('0.000', e1/l)+'; '+
FormatFloat('0.000', e2/l)+' => '+s;
end;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Au�erdem habe ich an der Ausgabe etwas ge�ndert.
Es werden nun drei Werte angezeigt:
- Faktor
- Takte pro Zeichen bei MyAnsiUpperCase
- Takte pro Zeichen bei AnsiUpperCase
Meine Werte:
Faktor; MyAnsi; Ansi
19,526; 2,566; 50,102
100/17,103*19,526=114,17 = 14% schneller :-))
Wenn ich mich nicht verkalkuliert habe,
steigert sich der Faktor gegen�ber Unicode bei Dir auf 2,73.
Evtl. kann man noch mit Assembler etwas raus quetschen.
Falls das untere Limit 2.5 sein sollte, lohnt sich der
Aufwand nicht. Aber ich sehe noch Potenzial mehrere
unterschiedliche Register zu verwenden...
Sollte das Ergebnis Vorzeigbar sein, melde ich mich nochmal.
Hubert Seidel
"Hans-Peter Diettrich" <DrDiet...@aol.com> schrieb
im Newsbeitrag news:7ke494F...@mid.individual.net...
> Hubert Seidel schrieb:
> > Erste Erg�nzung/Korrektur:
>
> > Sollte wohl besser:
> > var
> > gAu:array[#0..#255] of AnsiChar;
> > sein... ####
>
> Warum nicht gleich
> gAu:array[AnsiChar] of AnsiChar;
Ich habe den Hinweis �bernommen, der Lesbarkeit wegen.
> Ggf. braucht man mehrere Tabellen, wenn man mit Strings aus
> verschiedenen Codepages arbeiten mu�.
Den Aufri� will ich ja nicht betreiben, da wie bereits u.A. in
news:hbqb92$ap$00$1...@news.t-online.com geschrieben 1252 interessant ist.
> L��t sich da nicht mit XLAT noch mehr Tempo herausquetschen?
Nein.
Wenn Du ein so erfahrener Programmierer bist (und xlat/xlatb kennst),
solltest Du wissen das es tierisch langsam ist.
Aber evtl. m�chtest Du ja meine Hausaufgaben
(siehe news:7kb532F...@mid.individual.net) pr�fen
bzw. die Korrekturen preis geben?
(Macht ja sonst kein Sinn, Hausaufgaben zu machen!)
Hubert Seidel
"Hans-Peter Diettrich" <DrDiet...@aol.com> schrieb im
Newsbeitrag news:7kcjbpF...@mid.individual.net...
> Hubert Seidel schrieb:
...
> > Wenn ich jedoch bei Ansi bleiben kann, und weiterhin
> > zur Stringmanipulation Ansi-Funktionen zur Verf�gung habe,
> > dann habe ich halb so viel Speicherdurchsatz.
>
> In Cobol wird zwischen Usage=Display und Usage=Computational
> unterschieden. Vielleicht sollte man das in Delphi genauso sehen, bei
> der Festlegung des jeweils passenden Stringtyps.
Womit wir vermutlich wieder beim Compiler-Schalter (04/2009) w�ren.
> > Und nur weil ein W-API-Aufruf pr�zise mit allen
> > m�glichen Zeichen umgehen kann, geht es nicht besser,
> > wenn eh nur die 256 m�glichen aus ANSI 1252 enthalten sind.
>
> Bei ASCII war ToUpper und ToLower eine reine Funktion, die ein Bit im
> Zeichen entsprechend gesetzt hat.
��� h�tte man ja fr�her �hnlich geschickt legen k�nnen... tja...
> Bei Ansi (SBCS) ist f�r jede Codepage eine eigene Tabelle notwendig,
> mindestens f�r den non-ASCII Teil. Bei MBCS mehrere Tabellen, mit
> entsprechend mehrstufigem Lookup.
Dann kann man ja wieder beim Aufw�ndigen bleiben.
"Einfach" als Default, oder Switchbar w�re ganz gut.
> Bei Unicode (UTF-32) wird nur eine Tabelle ben�tigt, die aber durch
die
> vielen L�cher ebenfalls baumartig mit mehrstufigem Lookup aufgebaut
sein
> d�rfte.
Ich denke, _wenn_ man unbedingt Unicode ben�tigt,
dann kann man ja "getrost" die W-API-Calls machen...
Wenn ich den Faktor 2.4 zu Byte-Zugriffen sehe, dann sind
die ja nah am Ideal (wegen dem doppeltem Speicherverbrauch).
> Bei UTF-16 f�r UCS4 werden solche Funktionen und die �bergebenen
> Parameter noch aufwendiger, da auch bei einzelnen Zeichen immer mit
> Strings (Surrogat-Paare aus mehreren WideChars) zu rechnen ist.
dejavu...
> Damit d�rfte klar sein, da� eine Beschr�nkung auf einen bestimmten
> Zeichensatz deutliche Optimierungsm�glichkeiten bietet. Dann kommt es
> drauf an, ob diese Optimierungsm�glichkeiten in der RTL wahrgenommen
> werden, z.B. in Abh�ngigkeit vom String-Typ oder -Encoding.
Irre ich mich, oder bekomme ich das Gef�hl das Du
langsam verstehst worauf wir hinaus wollen...
> Ein Anwendungsprogrammierer mu� bei der Verwendung von Unicode schon
> genau angeben (und sicherstellen), warum z.B. seine indizierten
Zugriffe
> auf String-Elemente �berhaupt zul�ssig sind. Bei Ansi war das einfach,
> da eine Codepage entweder SBCS oder MBCS ist. Bei Unicode kann man
sich
> zwar entsprechend auf die BMP beschr�nken, es gibt dann aber keine
> Sperren, welche die Einhaltung dieser Annahme sicherstellen.
Genau.
Ein Kompromitt w�hre bei UTF-16, die Surrogate-Pairs zu ignorieren.
Nur grob 2x mehr Durchsatz/Langsamer gegen�ber Ansi,
aber verh�lltnism��ig gro�e Sprachunterst�tzung.... dejavu ;-)
> >> Es bedeutet unterm Strich _weniger_ Konvertierungen!
> >
> > Wenn ich ein Ansi-String mit einer Ansi-Funktion
> > aufrufe k�nnte, warum sollte konvertieren wollen?
>
> Was die Benennung der Delphi-Funktionen betrifft, da hat sich CodeGear
> dazu entschlossen, die alten Namen aus Kompatibilit�tsgr�nden
> beizubehalten, aber die Ansi Parameter durch Unicode zu ersetzen. Wenn
Und das war ein Anf�ngerfehler :-((( ohne Compiler-Schalter )))
> man das wei�, kann man bei Ansi-Texten um diese Funktionen einen
weiten
> Bogen machen. Benutzerfreundlicher w�re jedenfalls eine eigene
> (�berladene) Implementierung f�r AnsiString Parameter.
Bingo, mein Reden!!!
> >> Wenn du einen AnsiString in einer Ansi-Anwendung anzeigst
> >> oder nur einmal AnsiUpperCase aufrufst hat Windows den String
> >> schon intern hin und her konvertiert!
>
> Ich hab's selber nicht nachgepr�ft, aber wenn ein WinAPI ToUpperA nach
> ToUpperW delegiert, dann ist das eine herbe Bremse. (s.o.)
Die extreme Langsamkeit ist zumindest Me�bar.
Ob nun hin- und hergewandelt wird, oder nach jedem Zeichen ein
kleiner Dummy-Loop 0..15 ausgef�hrt wirs, ist fast unerheblich ;-)
Hubert Seidel
"Arno Garrels" <arno.g...@gmx.de> schrieb im
Newsbeitrag news:hbs5gp$vve$1...@online.de...
>Hubert Seidel wrote:
...
>> zum anderen die Verarbeitung im "Bauch"
>> toppelt so viele Bytes transferieren muss.
>
>Dann nimm einen FileStream und einen AnsiString und schon
>ist die Ansiwelt (fast) wieder in Ordnung ;)
Darauf wird das wohl hinaus laufen... alles b�se umfrickeln :(
...
>> Wenn ich jedoch bei Ansi bleiben kann,
>Das kannst du ja mit D2010/2009 auch.
Aber eben nicht einfach durch einen simplen Compiler-Schalter.
...
>Die meisten oder alle der AnsiXyz-Funktionen der RTL
>waren immer schon ein Wrapper um das WinAPI, fr�her um die
>A-Versionen seit D2009 um die W-Versionen.
>Nur die ASCII-Routinen waren und sind nativ in der RTL
>implementiert, z.B. UpperCase().
Ja, und wenn ich mir den Quellcode ansehe,
dann kein Wunder das eine optimierte W-API-Funktion
manchmal gar schneller sein kann ;-)
Aber zum Gl�ck macht der Optimizer von Delphi sehr gute Arbeit.
Ohne diesen w�rde Delphi ziemlich arm aussehen.
>> dann habe ich halb so viel Speicherdurchsatz.
>> Und nur weil ein W-API-Aufruf pr�zise mit allen
>> m�glichen Zeichen umgehen kann, geht es nicht besser,
>> wenn eh nur die 256 m�glichen aus ANSI 1252 enthalten sind.
>
>Willst du Performance mit AnsiString dann vermeide den direkten
>oder indirekten Aufruf der Win32 A-API, das gilt f�r
>Ansi-Delphi genauso wie f�r Unicode-Delphi (W-API ist h�ufig
>wesentlich schneller). Mit einem Unicode-Delphi sollte man dann
>noch ein paar Routinen selbst als Ansi-Version bereitstellen,
>z.B. IntToStrA, da sonst die Delphi RTL hin und her konvertiert.
>In der Unit AnsiStrings.pas sind aber viele der alten ANSI-Routinen
>als overloads enthalten.
Aha... das h�rt sich doch nach der gesuchten Alternative an...
W�re nicht schlecht, wenn diese �hnlich den W-Funktionen
ebenfalls optimiert werden w�rden, da sonst wirklich langsamer.
>> Bei Delphi5 sind ja noch zum Gl�ck etliche Funktionen nativ
>>vorhanden.
>Aber nicht f�r ANSI sondern f�r ASCII Strings.
Stimmt leider. Wenn es darauf ankommt, weis ich
mir bereits zu helfen (wird halt immer mehr).
>> Ich kenne diesen Nachteil demnach noch gar nicht.
>> Wenn es darauf ankommt, dann nutze ich auch gerne
>> mal eine eigene sehr performante Funktion.
>
>Und die kannst du weiterhin in Delphi 2010/2009 benutzen.
Halt leider mit viel viel Umwegen.
(-; Vermutlich bleibe ich noch bis 2015 bei D5 ;-)
Hubert Seidel
"Hans-Peter Diettrich" <DrDiet...@aol.com> schrieb im
Newsbeitrag news:7kcjboF...@mid.individual.net...
> Hubert Seidel schrieb:
>
> >>> Die Zeichen 'abcabcabc' belegen auf in der Datei
> >>> '...a...b...c...a...b...c...a...b...c' 4 mal mehr Platz.
> >>> Komprimiert st�nde vereinfacht: 3x'...a...b...c'
> >> Wobei es dem "3x" egal ist, ob danach Bytes oder andere Typen
kommen.
> >
> > Nein. Egal ist es nicht. Aber das ist ja auch kein Delphi-Thema.
>
> Was ist daran nicht egal?
Wenn der Typ fest ist, dann muss die Information des Types
(Gr��e, ggf. gar Struktur?) nicht st�ndig mitgepflegt werden.
> >> Dein Vorschlag w�re damit auf reine UCS4/UTF-32 Dateien beschr�nkt,
> > und
> > Das eine muss das andere ja nicht ausschlie�en.
> Bytes schlie�en Longs nicht aus, umgekehrt gilt das nicht.
Das ist im Falle von UTF-32 auch gar nicht
n�tig, da ja jedes Elemet 4 Bytes belegt.
In diesem Fall ist ein Euro-Zeichen, welches 3
Bytes bei UTF-8 belegt, und 2 Bytes beu UTF-16,
gleichberechtigt zu einem einfachen A.
Das d�rfte die internen Kompressions-Strukturen beeinflussen.
> > Nicht unbedingt. Im "Kompressionsfenster" m�ssen mehr Kombinationen
> > vorgehalten werden, im vergleich zu ANSI-Text.
>
> Im Falle von RLE trifft das IMO nicht zu.
Eben darum extra UTF-32/32-Bit optimiert!
RLE ist ein guter Vergleich. Wenn RLE nicht 8-Bit,
sondern 32-Bit-Orientiert w�re, dann k�nnten
RGBA-Werten genau so RLEt werden.
Warum das nicht geschieht, hat in der Grafik-Welt andere Gr�nde.
(Nicht nur anderes kapitel, gleich ein ganz anderes Buch!)
> Zudem ist hier ein Vergleich von Ansi und Unicode nicht unbedingt
> sinnvoll, wenn sich eine Unicode-Datei (und damit das Fenster) alleine
> durch Konvertierung in Ansi oder UTF-8 auf ein Viertel schrumpfen
l��t.
In dem Fall, in dem immer 4 Bytes als ein "Code" betrachtet wird,
haben 256 unterschiedliche Codes, ebenfalls nur 8 Bit.
Und das ist v�llig egal, aus welchem Bereich die 256 Codes kommen.
Kommt halt auf das "Fenster" (bzw.) des Kompressionsverfahren an.
> > 'abcd' hat 4 unterschiedliche Codes 'a', 'b', 'c' und 'd'
> > '...a...b...c...d' hat 5: '...', 'a', 'b', 'c' und 'd'.
> > 4 unterschiedliche k�nnen mit 2 bit codiert werden, 5 mit 3.
>
> Bei welchem Komprimierungsverfahren bist Du jetzt? Und Du betrachtest
> hier die Interna, nicht das Ergebnis.
Das Beispiel gib ja, wie Du offensichtlich erkannt hast, Richtung RLE.
Aber nat�rlich habe ich andere, wie z.b. ZIP im Hinterkopf.
Ich will mich jetzt gar nicht auf ein bestimmtest verfahren festlegen.
Wenn man verschiedene Verfahren mit 32-Bit auf UTF-32 anwendet,
wird sich sicher ein besseres, oder gar Ideal heraus kriostalisieren.
Genau so wie z.b. GIF manchmal besser ist als WasWeisIch...
Jens Lenge
> Man kann nicht ausschlieￜen, daￜ so eine Prￜfung vergessen wurde.
Wurde sie definitiv. (Ich weiￜ, strￜfliches Unterlassen, aber das
Projekt gab es schon lange vor meiner Zeit.)
Soviel ich davon sehen konnte wird ï¿œberall implizit davon ausgegangen,
dass ein Char gleich einem Zeichen ist, egal in welcher Kodierung.
> Anders bei einer Umstellung auf Iteratoren, die lassen keinen Raum fï¿œr solche Fehler.
*interessiertdieohrenaufstell*
Daraus lese ich: Delphi kennt spezielle Iteratorn, mit deren Hilfe man
*zeichenweise* durch einen wie-auch-immer-kodierten String laufen kann
und sich nicht darum kï¿œmmern muss, ob das nï¿œchste Zeichen in einem,
zwei, drei oder vier "Chars" beginnt. Lese ich richtig? Gibt es die
schon immer oder erst in Delphi 2009+?
Jens
Hubert Seidel
"Jens Lenge" <Spa...@gmx.net> schrieb im Newsbeitrag
news:hbv3rn$6sg$1...@news.albasani.net...
> Hans-Peter Diettrich wrote:
...
> Soviel ich davon sehen konnte wird �berall implizit davon ausgegangen,
> dass ein Char gleich einem Zeichen ist, egal in welcher Kodierung.
> > Anders bei einer Umstellung auf Iteratoren, die lassen keinen Raum
f�r solche Fehler.
>
> *interessiertdieohrenaufstell*
Bin gespannt, ob wesentlich anderes an folgendse kommt:
http://blogs.teamb.com/joannacarter/2004/06/30/697
> Daraus lese ich: Delphi kennt spezielle Iteratorn, mit deren Hilfe man
> *zeichenweise* durch einen wie-auch-immer-kodierten String laufen kann
> und sich nicht darum k�mmern muss, ob das n�chste Zeichen in einem,
> zwei, drei oder vier "Chars" beginnt. Lese ich richtig? Gibt es die
> schon immer oder erst in Delphi 2009+?
Egal ob Bordmittel oder selbst gemacht. Fakt ist folgendes:
Wenn ich gezwungen bin "durchzuiterieren" da kein "wahlfreier Zugriff"
erlaubt ist, geht das auf Kosten der Performance :-(
Bzw. man ist im Design eingeschr�nkt, bzw. mit weiterem kompensieren.
Ein Methodenaufruf von .next kann ja kaum schneller als ein inc sein.
Arno Garrels
> Hans-Peter Diettrich wrote:
>
> Wurde sie definitiv. (Ich weiß, sträfliches Unterlassen, aber das
> Projekt gab es schon lange vor meiner Zeit.)
Ob das sträflich ist, hängt davon ab was tatsächlich gemacht wird
mit den Chars. Werden denn z.B. explizit Zeichen ausserhalb der BMP
gesucht, verglichen, geprüft etc.? Falls nicht, sollte das so wunderbar
funktionieren.
> Soviel ich davon sehen konnte wird überall implizit davon ausgegangen,
> dass ein Char gleich einem Zeichen ist, egal in welcher Kodierung.
>
>> Anders bei einer Umstellung auf Iteratoren, die lassen keinen Raum
>> für solche Fehler.
Die wären echt praktisch für die Masse der Delphi-Entwickler, die Text-
und Notenverarbeitungen schreibt ;)
>
> *interessiertdieohrenaufstell*
>
> Daraus lese ich: Delphi kennt spezielle Iteratorn, mit deren Hilfe man
> *zeichenweise* durch einen wie-auch-immer-kodierten String laufen kann
> und sich nicht darum kümmern muss, ob das nächste Zeichen in einem,
> zwei, drei oder vier "Chars" beginnt. Lese ich richtig? Gibt es die
> schon immer oder erst in Delphi 2009+?
Gibt und gab es AFAIK nicht.
Was es gibt, sind die Funktionen der Character.pas, z.B. IsWhiteSpace,
IsUpper, IsLowSurrogate, IsSurrogatePair etc.., was m.E. völlig
ausreicht.
--
Arno Garrels
Arno Garrels
> Hallo Arno,
>
> "Arno Garrels" <arno.g...@gmx.de> schrieb im
> Newsbeitrag news:hbs5gp$vve$1...@online.de...
>
>> Hubert Seidel wrote:
> ...
>>> zum anderen die Verarbeitung im "Bauch"
>>> toppelt so viele Bytes transferieren muss.
>>
>> Dann nimm einen FileStream und einen AnsiString und schon
>> ist die Ansiwelt (fast) wieder in Ordnung ;)
>
Aha, nimmst also doch TStringList für die Logdateiauswertungen ;)
> ...
>>> Wenn ich jedoch bei Ansi bleiben kann,
>> Das kannst du ja mit D2010/2009 auch.
>
> Aber eben nicht einfach durch einen simplen Compiler-Schalter.
Tja, so ist das, hast du dir denn schonmal überlegt was so ein
Schalter bedeuten würde? Mal abgesehen von zwei VCLs und RTLs?
Was wenn ein Package den einen und das andere den anderen Schalter
gesetzt hat, nur mal so gesponnen?
> ...
>> Die meisten oder alle der AnsiXyz-Funktionen der RTL
>> waren immer schon ein Wrapper um das WinAPI, früher um die
>> A-Versionen seit D2009 um die W-Versionen.
>> Nur die ASCII-Routinen waren und sind nativ in der RTL
>> implementiert, z.B. UpperCase().
>
> Ja, und wenn ich mir den Quellcode ansehe,
> dann kein Wunder das eine optimierte W-API-Funktion
> manchmal gar schneller sein kann ;-)
> Aber zum Glück macht der Optimizer von Delphi sehr gute Arbeit.
> Ohne diesen würde Delphi ziemlich arm aussehen.
Was hat der Optimizer mit der WinAPI zu schaffen?
>>> dann habe ich halb so viel Speicherdurchsatz.
>>> Und nur weil ein W-API-Aufruf präzise mit allen
>>> möglichen Zeichen umgehen kann, geht es nicht besser,
>>> wenn eh nur die 256 möglichen aus ANSI 1252 enthalten sind.
>>
>> Willst du Performance mit AnsiString dann vermeide den direkten
>> oder indirekten Aufruf der Win32 A-API, das gilt für
>> Ansi-Delphi genauso wie für Unicode-Delphi (W-API ist häufig
>> wesentlich schneller). Mit einem Unicode-Delphi sollte man dann
>> noch ein paar Routinen selbst als Ansi-Version bereitstellen,
>> z.B. IntToStrA, da sonst die Delphi RTL hin und her konvertiert.
>> In der Unit AnsiStrings.pas sind aber viele der alten ANSI-Routinen
>> als overloads enthalten.
>
> Aha... das hört sich doch nach der gesuchten Alternative an...
> Wäre nicht schlecht, wenn diese ähnlich den W-Funktionen
> ebenfalls optimiert werden würden, da sonst wirklich langsamer.
Langsamer als deine eigenen schnellen ANSI-Routinen vieleicht.
Aber schneller als die A-Funktionen (auch in Delphi 5).
>>> Bei Delphi5 sind ja noch zum Glück etliche Funktionen nativ
>>> vorhanden.
>> Aber nicht für ANSI sondern für ASCII Strings.
>
> Stimmt leider. Wenn es darauf ankommt, weis ich
> mir bereits zu helfen (wird halt immer mehr).
ANSI gibt es schon längere Zeit, wenn ich mich recht erinnere.
>>> Ich kenne diesen Nachteil demnach noch gar nicht.
>>> Wenn es darauf ankommt, dann nutze ich auch gerne
>>> mal eine eigene sehr performante Funktion.
>>
>> Und die kannst du weiterhin in Delphi 2010/2009 benutzen.
>
> Halt leider mit viel viel Umwegen.
Wenn du meinst.
> (-; Vermutlich bleibe ich noch bis 2015 bei D5 ;-)
Von mir aus, ich bin kein CG-Profiseller der andernfalls
ne Provision bekäme.
--
Arno Garrels
Hubert Seidel
"Arno Garrels" <arno.g...@gmx.de> schrieb im
Newsbeitrag news:hbv9mu$le0$1...@online.de...
>Hubert Seidel wrote:
>> "Arno Garrels" schrieb:
>>> Dann nimm einen FileStream und einen AnsiString und schon
>>> ist die Ansiwelt (fast) wieder in Ordnung ;)
>> Darauf wird das wohl hinaus laufen... alles b�se umfrickeln :(
>Aha, nimmst also doch TStringList f�r die Logdateiauswertungen ;)
Ja, verwende ich :-) Nur eben nicht zum "Einlesen am St�ck" ;-)
>> ...
>>>> Wenn ich jedoch bei Ansi bleiben kann,
>>> Das kannst du ja mit D2010/2009 auch.
>> Aber eben nicht einfach durch einen simplen Compiler-Schalter.
>
>Tja, so ist das, hast du dir denn schonmal �berlegt was so ein
>Schalter bedeuten w�rde? Mal abgesehen von zwei VCLs und RTLs?
>Was wenn ein Package den einen und das andere den anderen Schalter
>gesetzt hat, nur mal so gesponnen?
Dann wird so verfahren, wie es jetzt auch bei Schalter ist.
Wird ein Schalter in den Projekt-Optionen gesetzt, gilt dies
�ber das gesampe Projekt => Erkl�rt sich ja von selbst ;-)
Wird ein Schalter in einer Unit gesetzt, gilt es in dem Fokus.
Wo sollte das Problem sein?
W�rde man in einer "portierten" unit die Abw�rtskompatibilit�
haben wollen, einfach ganz oben rein, etwas wie: {$UNICODE-}
Das w�rde wie jetzt, nur Unit-Weit gelten. Fertig aus.
Bei einem �bergang, m�sste konvertiert werden.
Ein abschaltbarer Hint w�re an dieser Stelle hilfreich.
>> ...
>> Ja, und wenn ich mir den Quellcode ansehe,
>> dann kein Wunder das eine optimierte W-API-Funktion
>> manchmal gar schneller sein kann ;-)
>> Aber zum Gl�ck macht der Optimizer von Delphi sehr gute Arbeit.
>> Ohne diesen w�rde Delphi ziemlich arm aussehen.
>
>Was hat der Optimizer mit der WinAPI zu schaffen?
Den Quellcode sehe ich mir von Delphi an.
Da dieser nicht immer ideal programmiert ist, sorgt
der Optimizer daf�r, das er nicht so lahm gegen�ber einer
W-API-Funktion ist, wie er (schlecht) gecodet wurde ;-)
Denn eine W-API-Funktion muss 2x mehr Daten schaufeln.
...
>>> In der Unit AnsiStrings.pas sind aber viele der alten ANSI-
>>> Routinen als overloads enthalten.
>> Aha... das h�rt sich doch nach der gesuchten Alternative an...
>> W�re nicht schlecht, wenn diese �hnlich den W-Funktionen
>> ebenfalls optimiert werden w�rden, da sonst wirklich langsamer.
>
>Langsamer als deine eigenen schnellen ANSI-Routinen vieleicht.
>Aber schneller als die A-Funktionen (auch in Delphi 5).
Du meintest bestimmt: ...schneller als die W-Funktionen...
Oder meinst Du, das die Ansi-Funktionen
tats�chlich optimiert wurden?
Hey, die h�tte man gut in den Compiler generierten
Code einbauen k�nnen. Quasi bei {$UNICODE-} :-)
>> (-; Vermutlich bleibe ich noch bis 2015 bei D5 ;-)
>Von mir aus, ich bin kein CG-Profiseller der andernfalls
>ne Provision bek�me.
Wenn das Preis-/Leistungsverh�lltnis stimmt, muss man
kein _Profi_seller sein, um doch ne Provision zu kassieren ;-)
Hans-Peter Diettrich
>> Man kann nicht ausschlieￜen, daￜ so eine Prￜfung vergessen wurde.
>
> Wurde sie definitiv. (Ich weiￜ, strￜfliches Unterlassen, aber das
> Projekt gab es schon lange vor meiner Zeit.)
Deshalb ja mein Kommentar :-)
> Soviel ich davon sehen konnte wird ï¿œberall implizit davon ausgegangen,
> dass ein Char gleich einem Zeichen ist, egal in welcher Kodierung.
Richtig. Es macht durchaus Sinn, ein Programm auf die Unicode BMP zu
beschrￜnken - nur sollte man dann dafￜr sorgen, daￜ diese Einschrￜnkung
auch eingehalten wird.
Bei dieser Gelegenheit fï¿œllt mir ein, CG hï¿œtte ja durchaus auch einen
Stringtyp oder Encoding UnicodeBMP einfï¿œhren kï¿œnnen, bei dem weiterhin
jedes Zeichen eine feste Lï¿œnge hat. Dann lassen sich auf solche Strings
die ganzen altgewohnten SBCS/Ansi Behandlungen sicher anwenden. Bei der
Zuweisung eines allgemeinen UnicodeString kï¿œnnte es dann eine Exception
geben, wenn der String Surrogat-Paare enthï¿œlt.
>> Anders bei einer Umstellung auf Iteratoren, die lassen keinen Raum fï¿œr
>> solche Fehler.
>
> *interessiertdieohrenaufstell*
>
> Daraus lese ich: Delphi kennt spezielle Iteratorn, mit deren Hilfe man
> *zeichenweise* durch einen wie-auch-immer-kodierten String laufen kann
> und sich nicht darum kï¿œmmern muss, ob das nï¿œchste Zeichen in einem,
> zwei, drei oder vier "Chars" beginnt. Lese ich richtig? Gibt es die
> schon immer oder erst in Delphi 2009+?
Die gibts schon seit es MBCS gibt. Suche mal in der OH nach
NextCharIndex, oder gleich nach MBCS Utilities.
DoDi
Hans-Peter Diettrich
>>>> Wenn ich jedoch bei Ansi bleiben kann,
>>> Das kannst du ja mit D2010/2009 auch.
>> Aber eben nicht einfach durch einen simplen Compiler-Schalter.
>
> Tja, so ist das, hast du dir denn schonmal �berlegt was so ein
> Schalter bedeuten w�rde? Mal abgesehen von zwei VCLs und RTLs?
> Was wenn ein Package den einen und das andere den anderen Schalter
> gesetzt hat, nur mal so gesponnen?
Ja, wo siehst Du da irgendwelche Probleme?
Denke mal an $H, diese Direktive funktioniert global wie auch lokal.
Eine zweite VCL/RTL ist nicht notwendig, bei Ansi/Unicode w�re es
allenfalls w�nschenswert, da� die betroffenen Klassen z.B. wie bei den
API Aufrufen als A und W Versionen implementiert werden - dann kann der
Linker das Rauswerfen der unbenutzten Klassen �bernehmen.
DoDi
Arno Garrels
> Arno Garrels schrieb:
>
>>>>> Wenn ich jedoch bei Ansi bleiben kann,
>>>> Das kannst du ja mit D2010/2009 auch.
>>> Aber eben nicht einfach durch einen simplen Compiler-Schalter.
>>
>> Schalter bedeuten würde? Mal abgesehen von zwei VCLs und RTLs?
>> Was wenn ein Package den einen und das andere den anderen Schalter
>> gesetzt hat, nur mal so gesponnen?
>
> Ja, wo siehst Du da irgendwelche Probleme?
> Denke mal an $H, diese Direktive funktioniert global wie auch lokal.
Mit welchem Schalter sollte dann, deiner Meinung nach, die IDE selbst
compiliert werden?
Was, wenn mein Entwurfzeit-Package mit einem anderen Schalter
compilert wurde?
Zusätzliche Stringchecks wie sie jetzt schon nötig sind für die
C++Builder Kompatibilität, die den erzeugten Kode unnötig
aufblähen, siehe undokumentierten Schalter "String format checking",
{$STRINGCHECKS ON/OFF} default = ON.
> Eine zweite VCL/RTL ist nicht notwendig, bei Ansi/Unicode wäre es
> allenfalls wünschenswert, daß die betroffenen Klassen z.B. wie bei den
> API Aufrufen als A und W Versionen implementiert werden - dann kann
> der Linker das Rauswerfen der unbenutzten Klassen übernehmen.
Weiß zwar nicht, wie das mit einer einfachen Portierung alter
Projekte zusammengehen soll, der Aufwand wäre jedenfalls enorm, auch
für Drittanbieter, und m.E. nutzlos noch dazu, denn in kurzer Zeit
wird kein Hahn mehr nach ANSI-GUIs krähen. Ohne Schalter kannst du
sicher sein, dass ein "string" immer ein UnicodeString ist, "$H"
hat da m.E. schon immer für Verwirrung gesorgt.
--
Arno Garrels
Arno Garrels
> Hallo Arno,
>
> "Arno Garrels" <arno.g...@gmx.de> schrieb im
> Newsbeitrag news:hbv9mu$le0$1...@online.de...
>
>> Hubert Seidel wrote:
>>> "Arno Garrels" schrieb:
>>>> Dann nimm einen FileStream und einen AnsiString und schon
>>>> ist die Ansiwelt (fast) wieder in Ordnung ;)
>> Aha, nimmst also doch TStringList für die Logdateiauswertungen ;)
>
> Ja, verwende ich :-) Nur eben nicht zum "Einlesen am Stück" ;-)
>
>>> ...
>>>>> Wenn ich jedoch bei Ansi bleiben kann,
>>>> Das kannst du ja mit D2010/2009 auch.
>>> Aber eben nicht einfach durch einen simplen Compiler-Schalter.
>>
>> Schalter bedeuten würde? Mal abgesehen von zwei VCLs und RTLs?
>> Was wenn ein Package den einen und das andere den anderen Schalter
>> gesetzt hat, nur mal so gesponnen?
>
> Dann wird so verfahren, wie es jetzt auch bei Schalter ist.
> Wird ein Schalter in den Projekt-Optionen gesetzt, gilt dies
> Wird ein Schalter in einer Unit gesetzt, gilt es in dem Fokus.
> Wo sollte das Problem sein?
Siehe meine Antwort an Hans-Peter.
--
Arno Garrels
Hubert Seidel
"Arno Garrels" <arno.g...@gmx.de> schrieb im
Newsbeitrag news:hc178s$6ng$2...@online.de...
>Siehe meine Antwort an Hans-Peter.
Welche Antwort von Hans-Peter ist gemeint...
Vermutlich news:hc178s$6ng$1...@online.de, aber ohne MSG_ID
k�nnten ja alle von Hans-Peter in Frage kommen...
(Ich gehe mal bis auf Wiederruf davon aus)
Hubert Seidel
"Arno Garrels" <arno.g...@gmx.de> schrieb im
Newsbeitrag news:hc178s$6ng$1...@online.de...
>Hans-Peter Diettrich wrote:
...
>> Ja, wo siehst Du da irgendwelche Probleme?
>> Denke mal an $H, diese Direktive funktioniert global wie auch
>>lokal.
>Mit welchem Schalter sollte dann, deiner Meinung nach, die IDE
>selbst compiliert werden?
Das sollte den gleichen Regeln folgen wie bei allen Schaltern.
Wenn ein Schalter f�r eine Unit unabdingbar ist, dann ist
dieser Schalter in die Unit oben, oder an entspr. Stellen
einzuf�gen. Dann ist es unerheblich mit welchen Schalter ein
Projekt oder die IDE (bzw. dessen Komponenten) compiliert werden.
>Was, wenn mein Entwurfzeit-Package mit einem anderen Schalter
>compilert wurde?
*1) Unkenntnis ist kein Grund, das Strafma� herabzusetzen.
Das h�chstma�:
Lebensl�nglich unertr�glich langsame Konvertierungen.
...
>wird kein Hahn mehr nach ANSI-GUIs kr�hen. Ohne Schalter kannst du
>sicher sein, dass ein "string" immer ein UnicodeString ist,
Soweit leider richtig,...
>"$H" hat da m.E. schon immer f�r Verwirrung gesorgt.
Siehe oben *1)
Eine Verwirrung kann beseitigt werden, und dann ist es ganz
leicht den Schalter bei umfangreichen Portierungen zu verwenden.
Wenn ein Schalter erst gar nicht existiert, muss man es neu machen.
Obwohl.... Idealer Zeitpunkt sich zu �berlegen eine v�llig
andere L�sung bzw. Entwicklungsumgebung zu verwenden.
Hans-Peter Diettrich
>> Denke mal an $H, diese Direktive funktioniert global wie auch lokal.
>
> Mit welchem Schalter sollte dann, deiner Meinung nach, die IDE selbst
> compiliert werden?
Mit dem, der die besten Ergebnisse liefert.
> Was, wenn mein Entwurfzeit-Package mit einem anderen Schalter
> compilert wurde?
Dann wird beim Entwerfen eben ab und zu mal konvertiert. So oft wie das
geschehen mu�, merkt niemand was davon. Zudem sollten alle Komponenten
beide Stringtypen unterst�tzen, und intern mit dem am besten zum System
passenden Typ arbeiten. Ggf. mu� der Compiler etwas aufgebohrt werden,
damit Properties entsprechend (A/W) �berladen werden k�nnen.
> Zus�tzliche Stringchecks wie sie jetzt schon n�tig sind f�r die
> C++Builder Kompatibilit�t, die den erzeugten Kode unn�tig
> aufbl�hen, siehe undokumentierten Schalter "String format checking",
> {$STRINGCHECKS ON/OFF} default = ON.
Das sagt mir jetzt garnichts. Hat das was mit LPTSTRING zu tun?
>> Eine zweite VCL/RTL ist nicht notwendig, bei Ansi/Unicode w�re es
>> allenfalls w�nschenswert, da� die betroffenen Klassen z.B. wie bei den
>> API Aufrufen als A und W Versionen implementiert werden - dann kann
>> der Linker das Rauswerfen der unbenutzten Klassen �bernehmen.
>
> Wei� zwar nicht, wie das mit einer einfachen Portierung alter
> Projekte zusammengehen soll,
Es soll eine Portierung schlicht �berfl�ssig machen.
> der Aufwand w�re jedenfalls enorm, auch
> f�r Drittanbieter, und m.E. nutzlos noch dazu, denn in kurzer Zeit
> wird kein Hahn mehr nach ANSI-GUIs kr�hen. Ohne Schalter kannst du
> sicher sein, dass ein "string" immer ein UnicodeString ist, "$H"
> hat da m.E. schon immer f�r Verwirrung gesorgt.
Aus diesem Grund sollte IMO "string" immer nur f�r solche Parameter
verwendet werden, wo der Code mit allen Stringtypen funktioniert. Die
�brigen Prozeduren bzw. Methoden haben ihren konkreten Stringtyp, und
k�nnen �berladen werden, wenn eine Laufzeitoptimierung gew�nscht wird.
DoDi
Hubert Seidel
"Hans-Peter Diettrich" <DrDiet...@aol.com> schrieb im
Newsbeitrag news:7kj6upF...@mid.individual.net...
> Arno Garrels schrieb:
> >> Denke mal an $H, diese Direktive funktioniert global wie auch
lokal.
> > Mit welchem Schalter sollte dann, deiner Meinung nach, die IDE
selbst
> > compiliert werden?
>
> Mit dem, der die besten Ergebnisse liefert.
Was glaubst Du was "die besten Ergebnisse" sind?
...
> Dann wird beim Entwerfen eben ab und zu mal konvertiert. So oft wie
das
> geschehen mu�, merkt niemand was davon. Zudem sollten alle Komponenten
> beide Stringtypen unterst�tzen, und intern mit dem am besten zum
System
> passenden Typ arbeiten. Ggf. mu� der Compiler etwas aufgebohrt werden,
> damit Properties entsprechend (A/W) �berladen werden k�nnen.
Es ist ja nicht grunds�tzlich schlimm, das UNICODE der Default ist.
Schlimm ist, das es kein Schalter f�r Abw�rtskompatibilit�t gibt.
Die Klassen/Komponenten m�ssen/sollen keine Wollmilchs�ue sein.
�berladene Properties sind eher kontraproduktiv.
G�be es einen derartigen Schalter, dann k�nnte man mit einem
einfachen z.b. {$ANSISTR+} in der ersten Zeile, die alte
Unit ohne weitere Anpassungen 100% zum Laufen bekommen,
da der String eben so funktioniert wie gewohnt.
In den Projekt-Optionen k�nnte eine neue Auswahl geben,
in der man bestimmt wie bei Wandlung verfahren wird.
- Ignorieren
- Als Hinweis
- Als Warnung
- Als Fehler
Denn am Ende liegt es im Ursprung/Internen der Komponente,
ob diese besser mit Ansi- oder Unicode umgehen kann.
Besser muss eben nicht immer Korrekt sein, sondern mal schnell.
�hnlich beim Ziehen einer Quadratwurzel in Grafikkarten.
Es wird ein schnellse, aber nicht so pr�zises Ergebnis gedultet.
Beim String w�re es, die nicht 100%tige Abdeckung alle Sprachen.
> > Zus�tzliche Stringchecks wie sie jetzt schon n�tig sind f�r die
> > C++Builder Kompatibilit�t, die den erzeugten Kode unn�tig
> > aufbl�hen, siehe undokumentierten Schalter "String format checking",
> > {$STRINGCHECKS ON/OFF} default = ON.
>
> Das sagt mir jetzt garnichts. Hat das was mit LPTSTRING zu tun?
<M�glicherweise wie {$V+} / {$V-} wie {$VARSTRINGCHECKS ON/OFF},
nur eben f�r UNICODE/ANSI?
> >> Eine zweite VCL/RTL ist nicht notwendig, bei Ansi/Unicode w�re es
> >> allenfalls w�nschenswert, da� die betroffenen Klassen z.B. wie bei
den
> >> API Aufrufen als A und W Versionen implementiert werden - dann kann
> >> der Linker das Rauswerfen der unbenutzten Klassen �bernehmen.
> >
> > Wei� zwar nicht, wie das mit einer einfachen Portierung alter
> > Projekte zusammengehen soll,
>
> Es soll eine Portierung schlicht �berfl�ssig machen.
Zumindest herausz�gern.
Zudem es sehr fehleranf�llig ist, wenn eien Anwendung zu 100%
portiert wird, da leicht Mehrfachfehler enthalten sein k�nnen.
Wird eine Anwendung Schritt f�r Schritt portiert, indem
unit f�r unit ein Schalter entfernt, und portierte Komponenten
bzw. �nderungen sofort/gezielt getestet werden k�nnen,
so kann zumindest die Korrektheit eher gew�hrleistet werden.
Auch Performance-Probleme/Ursachen sollte so eigentlich
leichter identifiziert/lokalisiert und beseitigt werden k�nnen.
> > der Aufwand w�re jedenfalls enorm, auch
> > f�r Drittanbieter, und m.E. nutzlos noch dazu, denn in kurzer Zeit
> > wird kein Hahn mehr nach ANSI-GUIs kr�hen. Ohne Schalter kannst du
> > sicher sein, dass ein "string" immer ein UnicodeString ist, "$H"
> > hat da m.E. schon immer f�r Verwirrung gesorgt.
>
> Aus diesem Grund sollte IMO "string" immer nur f�r solche Parameter
> verwendet werden, wo der Code mit allen Stringtypen funktioniert. Die
> �brigen Prozeduren bzw. Methoden haben ihren konkreten Stringtyp, und
> k�nnen �berladen werden, wenn eine Laufzeitoptimierung gew�nscht wird.
Derartig �berladene Funktionen bieten Schlupfl�cher f�r Bugs!!
Da kann es zu leicht passieren, das Komponente XYZ bei Ansi
100% funktioniert (da bereist 1000Jahr l�uft), und pl�tzlich
wird die Unicode-Variante verwendet, welche in ganz besonderen,
noch nie getesteten Situationen v�llig verr�ckt spielt. Prost.
Zu viel (unn�tiger) Automatismus, bergen automatisierte Probleme.
Arno Garrels
> ...
>>> Ja, wo siehst Du da irgendwelche Probleme?
>>> Denke mal an $H, diese Direktive funktioniert global wie auch
>>> lokal.
>
>> Mit welchem Schalter sollte dann, deiner Meinung nach, die IDE
>> selbst compiliert werden?
>
> Das sollte den gleichen Regeln folgen wie bei allen Schaltern.
> dieser Schalter in die Unit oben, oder an entspr. Stellen
> Projekt oder die IDE (bzw. dessen Komponenten) compiliert werden.
Aber nicht mit Laufzeitpackages von Dritten, die kann ich ggf. nicht
neu erzeugen und sie müssten in zweifacher Ausführung geliefert werden.
>> Was, wenn mein Entwurfzeit-Package mit einem anderen Schalter
>> compilert wurde?
>
> *1) Unkenntnis ist kein Grund, das Strafmaß herabzusetzen.
>
> Das höchstmaß:
> Lebenslänglich unerträglich langsame Konvertierungen.
Genau.
--
Arno Garrels
Arno Garrels
> Arno Garrels schrieb:
>
>>> Denke mal an $H, diese Direktive funktioniert global wie auch lokal.
>>
>> Mit welchem Schalter sollte dann, deiner Meinung nach, die IDE selbst
>> compiliert werden?
>
> Mit dem, der die besten Ergebnisse liefert.
>
>> Was, wenn mein Entwurfzeit-Package mit einem anderen Schalter
>> compilert wurde?
>
> Dann wird beim Entwerfen eben ab und zu mal konvertiert.
Plus, dass Laufzeitpackages, die mit so einem Ansischalter erzeugt
worden wären in einem Projekt ohne diesen Schalter jede Menge Konvertierungen
zur Folge hätten. Laufzeitpackages, für die ich keinen Quellcode besitze,
kann ich nicht eben mal neu erzeugen. Bedeutet dass Komponentenhersteller
auch zwei Versionen liefern müssten (Package-Hölle).
Dann gäbe es bestimmt noch Probleme mit Eventhandlern wie beim
C++Builder s.u..
>> Zusätzliche Stringchecks wie sie jetzt schon nötig sind für die
>> C++Builder Kompatibilität, die den erzeugten Kode unnötig
>> aufblähen, siehe undokumentierten Schalter "String format checking",
>> {$STRINGCHECKS ON/OFF} default = ON.
>
> Das sagt mir jetzt garnichts. Hat das was mit LPTSTRING zu tun?
Es hat mit Eventhandlern und der kalkulierten Faulheit von CB-Benutzern
bei der Umstellung ihrer Projekte auf Unicode zu tun:
http://www.micro-isv.asia/2008/10/needless-string-checks-with-ensureunicodestring/
>
>
>>> Eine zweite VCL/RTL ist nicht notwendig, bei Ansi/Unicode wäre es
>>> allenfalls wünschenswert, daß die betroffenen Klassen z.B. wie bei
>>> den API Aufrufen als A und W Versionen implementiert werden - dann
>>> kann der Linker das Rauswerfen der unbenutzten Klassen übernehmen.
>>
>> Weiß zwar nicht, wie das mit einer einfachen Portierung alter
>> Projekte zusammengehen soll,
>
> Es soll eine Portierung schlicht überflüssig machen.
Gibt es denn eine IDE, die sowas ermöglicht? VB vieleicht?
>
>> der Aufwand wäre jedenfalls enorm, auch
>> für Drittanbieter, und m.E. nutzlos noch dazu, denn in kurzer Zeit
>> wird kein Hahn mehr nach ANSI-GUIs krähen. Ohne Schalter kannst du
>> sicher sein, dass ein "string" immer ein UnicodeString ist, "$H"
>> hat da m.E. schon immer für Verwirrung gesorgt.
>
> Aus diesem Grund sollte IMO "string" immer nur für solche Parameter
> verwendet werden, wo der Code mit allen Stringtypen funktioniert.
Auch für alle zukünftigen?
--
Arno Garrels
Jens Lenge
> Bin gespannt, ob wesentlich anderes an folgendse kommt:
> http://blogs.teamb.com/joannacarter/2004/06/30/697
Ich dachte eher an "eingebaute" Iteratoren, die die Logik fï¿œr alle
mï¿œglichen String-Kodierungen schon mitbringen.
> Wenn ich gezwungen bin "durchzuiterieren" da kein "wahlfreier Zugriff"
> erlaubt ist, geht das auf Kosten der Performance :-(
Vï¿œllig klar. Dennoch ist "langsam" zuweilen besser als "schnell, aber
falsch"... ;)
Jens
Hubert Seidel
"Arno Garrels" <arno.g...@gmx.de> schrieb im
Newsbeitrag news:hc22e1$bv$2...@online.de...
>Hans-Peter Diettrich wrote:
...
>> Dann wird beim Entwerfen eben ab und zu mal konvertiert.
>
>Plus, dass Laufzeitpackages, die mit so einem Ansischalter erzeugt
>worden w�ren in einem Projekt ohne diesen Schalter jede Menge
>Konvertierungen zur Folge h�tten.
Konvertierungen sind aber besser als "Geht �berhaupt nicht".
>Laufzeitpackages, f�r die ich keinen Quellcode besitze, kann ich
>nicht eben mal neu erzeugen. Bedeutet dass Komponentenhersteller
>auch zwei Versionen liefern m�ssten (Package-H�lle).
Nicht m�ssen, eher k�nnen.
Aber jetzt geht es erst garnicht (Service-W�ste).
...
>> Das sagt mir jetzt garnichts. Hat das was mit LPTSTRING zu tun?
>
>Es hat mit Eventhandlern und der kalkulierten Faulheit von CB-
>Benutzern bei der Umstellung ihrer Projekte auf Unicode zu tun:
>http://www.micro-isv.asia/2008/10/needless-string-checks-with-
>ensureunicodestring/
Ich weis nicht ob ich alles verstanden habe, aber wenn er
sich schon �ber �berfl�ssiges aufregt, dann sollte er statt
procedure TForm1.AddLengthTwice(const S: UnicodeString);
begin
Inc(Len, Length(S));
Inc(Len, Length(S));
end;
auch
procedure TForm1.AddLengthTwice(const S: UnicodeString);
begin
Inc(Len, Length(S)*2);
end;
machen.
Zumindest bei Delphi5 wird dann bei AnsiString ausb zwei:
push ebx
push esi
mov esi, edx
mov ebx, eax
mov eax,esi
call @LStrLen
add [ebx+$2d8], eax
mov eax,esi
call @LStrLen
add [ebx+$2d8], eax
pop esi
pop ebx
ret
eine Ermittlung der L�nge:
push ebx
push esi
mov esi, edx
mov ebx, eax
mov eax,esi
call @LStrLen
add eax, eax
add [ebx+$2d8], eax
pop esi
pop ebx
ret
...
>>> Wei� zwar nicht, wie das mit einer einfachen Portierung alter
>>> Projekte zusammengehen soll,
>>
>> Es soll eine Portierung schlicht �berfl�ssig machen.
>
>Gibt es denn eine IDE, die sowas erm�glicht? VB vieleicht?
Wenn es den Schalter geben w�rde, h�tte ich jetzt eine Antwort ;-)
...
>> Aus diesem Grund sollte IMO "string" immer nur f�r solche Parameter
>> verwendet werden, wo der Code mit allen Stringtypen funktioniert.
>
>Auch f�r alle zuk�nftigen?
Vermutlich kommt nicht mehr all zu viel...
Weil "gepennt wurde", noch eine Umstellung auf UTF-32/UCS4 o.�.
Anschl. wird es dann wieder eng, wenn noch Au�erirdische
Sprachen und Codes auch die 32 Bit gesprengt haben.
Hubert Seidel
"Jens Lenge" <Spa...@gmx.net> schrieb im
Newsbeitrag news:hc26jl$dup$1...@news.albasani.net...
> Hubert Seidel wrote:
> > Bin gespannt, ob wesentlich anderes an folgendse kommt:
> > http://blogs.teamb.com/joannacarter/2004/06/30/697
>
> Ich dachte eher an "eingebaute" Iteratoren, die die Logik f�r alle
> m�glichen String-Kodierungen schon mitbringen.
>
> > Wenn ich gezwungen bin "durchzuiterieren" da kein "wahlfreier
Zugriff"
> > erlaubt ist, geht das auf Kosten der Performance :-(
>
> V�llig klar. Dennoch ist "langsam" zuweilen besser als "schnell, aber
> falsch"... ;)
Freunde Dich mit dem Gedanken an, das es f�r alle Unicode-Zeichen,
�berhaupt (noch) kein vern�nftigen Standard-String-Datentypen gibt.
(vern�nftig = String mit wahlfreiem Zugriff auf alle Zeichen ;-)
G�be es diesen, dann k�nnte man mit "inc(Zeichen);" sowohl schnell,
als auch korrekt iterieren (Zeichen w�re ein TUCS4Char ;-)
Hubert Seidel
"Arno Garrels" <arno.g...@gmx.de> schrieb im
Newsbeitrag news:hc22e0$bv$1...@online.de...
>Hubert Seidel wrote:
...
>> Das sollte den gleichen Regeln folgen wie bei allen Schaltern.
>> Wenn ein Schalter f�r eine Unit unabdingbar ist, dann ist
>> dieser Schalter in die Unit oben, oder an entspr. Stellen
>> einzuf�gen. Dann ist es unerheblich mit welchen Schalter ein
>> Projekt oder die IDE (bzw. dessen Komponenten) compiliert werden.
>
>Aber nicht mit Laufzeitpackages von Dritten, die kann ich ggf. nicht
>neu erzeugen und sie m�ssten in zweifacher Ausf�hrung geliefert
>werden.
Wird doch jetzt auch f�r jede Version so gemacht.
Wobei ich ja dazu tendiere, das eine Komponente
jeweils f�r ein StringTyp spezialisiert ist und den
entspr. Schalter in der Unit richtig gesetzt hat.
Wenn dann die falsche Komponente/Unit verwendet wurde,
wird man mit langen Laufzeiten bestraft, kann aber
bei Erkenntnis, kann man schnell/einfach wechseln.
Zumindest h�tte der Kunde bzgl. Angebot uns Nachfrage
mehr in der Hand die Richtung vorzugeben, anstatt
einfach so davon auszugehen das jedem Unicode gef�llt.
Performance ist ein ziemlich m�chtiges Argument.
Vor allem, wenn es bei Faktor >2 (>100%) ist!!
Hans-Peter Diettrich
>>> Wei� zwar nicht, wie das mit einer einfachen Portierung alter
>>> Projekte zusammengehen soll,
>> Es soll eine Portierung schlicht �berfl�ssig machen.
>
> Gibt es denn eine IDE, die sowas erm�glicht? VB vieleicht?
FPC/Lazarus kann man alles beibringen :-)
>> Aus diesem Grund sollte IMO "string" immer nur f�r solche Parameter
>> verwendet werden, wo der Code mit allen Stringtypen funktioniert.
>
> Auch f�r alle zuk�nftigen?
Immer.
DoDi
Hubert Seidel
"Hans-Peter Diettrich" <DrDiet...@aol.com> schrieb im Newsbeitrag
news:7kk2brF...@mid.individual.net...
> Arno Garrels schrieb:
>
> >>> Wei� zwar nicht, wie das mit einer einfachen Portierung alter
> >>> Projekte zusammengehen soll,
> >> Es soll eine Portierung schlicht �berfl�ssig machen.
> >
> > Gibt es denn eine IDE, die sowas erm�glicht? VB vieleicht?
>
> FPC/Lazarus kann man alles beibringen :-)
Masse statt Klasse?
Zumindest bis D5 war es noch umgekehrt...
> >> Aus diesem Grund sollte IMO "string" immer nur f�r solche Parameter
> >> verwendet werden, wo der Code mit allen Stringtypen funktioniert.
> >
> > Auch f�r alle zuk�nftigen?
>
> Immer.
Funktionieren? Ja klar, keine Frage. Nur wie?
FPC/Lazarus ist (b.gr.U) auch langsamer als z.b. D5.
Sowohl beim compilieren, als auch in der Ausf�hrung.
Arno Garrels
> Arno Garrels schrieb:
>
>>>> Projekte zusammengehen soll,
>>> Es soll eine Portierung schlicht überflüssig machen.
>>
>> Gibt es denn eine IDE, die sowas ermöglicht? VB vieleicht?
>
> FPC/Lazarus kann man alles beibringen :-)
Beibringen ja, ist dann aber leider nicht mehr RAD.
Hab mir das aktuelle FPC/Lazarus am Wochenende mal kurz angeguckt,
Unicode wird da immer noch nicht vollständig unterstützt,
ShellTreeView/ListView z.B., Komponenten kann ich nur installieren,
indem ich die IDE neu compiliere und deren UTF8-Konzept überzeugt
mich einfach nicht.
--
Arno Garrels
Arno Garrels
> ...
>>> Das sollte den gleichen Regeln folgen wie bei allen Schaltern.
>>> dieser Schalter in die Unit oben, oder an entspr. Stellen
>>> Projekt oder die IDE (bzw. dessen Komponenten) compiliert werden.
>>
>> Aber nicht mit Laufzeitpackages von Dritten, die kann ich ggf. nicht
>> werden.
>
> Wird doch jetzt auch für jede Version so gemacht.
Nein, wie kommst du denn darauf?
> Wobei ich ja dazu tendiere, das eine Komponente
> jeweils für ein StringTyp spezialisiert ist und den
> entspr. Schalter in der Unit richtig gesetzt hat.
> Wenn dann die falsche Komponente/Unit verwendet wurde,
> wird man mit langen Laufzeiten bestraft, kann aber
> bei Erkenntnis, kann man schnell/einfach wechseln.
>
> Zumindest hätte der Kunde bzgl. Angebot uns Nachfrage
> mehr in der Hand die Richtung vorzugeben, anstatt
> einfach so davon auszugehen das jedem Unicode gefällt.
Mit "Gefallen" hat das wohl weniger zu tun als mit den
gewachsenen Anforderungen in einer globalisierten Welt.
Bedenke, dass Delphi eine der letzten IDEs war, die auf
Unicode umgestellt hat, der Druck der Benutzer wurde am
Ende wohl doch zu groß. So eine tiefgreifende Änderung
macht CG bestimmt nicht, wenn es dafür keine große
Nachfrage gibt (CodeGear/Embarcardero ist nicht Borland).
> Performance ist ein ziemlich mächtiges Argument.
> Vor allem, wenn es bei Faktor >2 (>100%) ist!!
Um welchen Faktor sind wohl moderne Rechner schneller
geworden seit es Delphi 5 gibt?
--
Arno Garrels
Hans-Peter Diettrich
> Hab mir das aktuelle FPC/Lazarus am Wochenende mal kurz angeguckt,
> Unicode wird da immer noch nicht vollst�ndig unterst�tzt,
> ShellTreeView/ListView z.B., Komponenten kann ich nur installieren,
> indem ich die IDE neu compiliere und deren UTF8-Konzept �berzeugt
> mich einfach nicht.
Ich will keine gro�e Reklame f�r Lazarus machen, weil es (noch) kein
vollst�ndiges Produkt ist. Ich ben�tige Lazarus seitdem ich von Windows
zu Linux gewechselt habe, und Delphi dort nicht pr�sent ist. �ber ein
paar Schw�chen kann ich hinwegsehen, die anderen fixe ich soweit
m�glich. Geschwindigkeit ist f�r mich kein gro�es Thema, mein Rechner
ist mir schnell genug - immerhin werkelt da schon lange ein 64 Bit
System ;-)
DoDi
Andrej Kluge
Hans-Peter Diettrich wrote:
> vollst�ndiges Produkt ist. Ich ben�tige Lazarus seitdem ich von
> Windows zu Linux gewechselt habe, und Delphi dort nicht pr�sent ist.
Es gab doch mal Kylix -- wurde das nicht weiterentwickelt?
Ciao
AK
Arno Garrels
> Arno Garrels schrieb:
>
>> Hab mir das aktuelle FPC/Lazarus am Wochenende mal kurz angeguckt,
>> ShellTreeView/ListView z.B., Komponenten kann ich nur installieren,
>> mich einfach nicht.
>
> Ich will keine große Reklame für Lazarus machen, weil es (noch) kein
> vollständiges Produkt ist. Ich benötige Lazarus seitdem ich von
> Windows zu Linux gewechselt habe, und Delphi dort nicht präsent ist.
> Über ein paar Schwächen kann ich hinwegsehen, die anderen fixe ich
> soweit möglich. Geschwindigkeit ist für mich kein großes Thema, mein
> Rechner ist mir schnell genug - immerhin werkelt da schon lange ein
> 64 Bit System ;-)
Ich will FPC/Lazarus auch nicht niedermachen, es kommt ja sichtbar
voran. Was mich allerdings nervt, ist wenn Leute es schon jetzt als
Alternative zu Delphi für die Windows Plattform bezeichnen (wie in
dieser Gruppe häufiger zu lesen war), davon ist es m.E., selbst aus
der D7-Perspektive, noch weit entfernt, obwohl es für manche (Ansi)
Windows-Anwendungen durchaus brauchbar scheint. Zur Linux- und
MacOS-Unterstützung kann ich aber nichts sagen, vieleicht sind die
ja schon weiter.
Bestimmt hilft Lazarus die Jungs bei CG ein bischen auf Trab zu
halten, allein deshalb ist es für mich schon ein interessantes
Projekt ;)
--
Arno Garrels
Hubert Seidel
"Arno Garrels" <arno.g...@gmx.de> schrieb im
Newsbeitrag news:hc44ki$2n8$1...@online.de...
>Hubert Seidel wrote:
>> ...
>>> Aber nicht mit Laufzeitpackages von Dritten, die kann ich ggf.
>nicht
>>> neu erzeugen und sie m�ssten in zweifacher Ausf�hrung geliefert
>>> werden.
>>
>> Wird doch jetzt auch f�r jede Version so gemacht.
>Nein, wie kommst du denn darauf?
F�r jede Delphi-, nicht String-Version.
...
>> Zumindest h�tte der Kunde bzgl. Angebot uns Nachfrage
>> mehr in der Hand die Richtung vorzugeben, anstatt
>> einfach so davon auszugehen das jedem Unicode gef�llt.
>
>Mit "Gefallen" hat das wohl weniger zu tun als mit den
>gewachsenen Anforderungen in einer globalisierten Welt.
1) Deswegen h�tte der Unicode-String trotsdem
anders implementiert werden k�nnen ;-)
>Bedenke, dass Delphi eine der letzten IDEs war, die auf
>Unicode umgestellt hat, der Druck der Benutzer wurde am
>Ende wohl doch zu gro�. So eine tiefgreifende �nderung
>macht CG bestimmt nicht, wenn es daf�r keine gro�e
>Nachfrage gibt (CodeGear/Embarcardero ist nicht Borland).
siehe 1)
>> Performance ist ein ziemlich m�chtiges Argument.
>> Vor allem, wenn es bei Faktor >2 (>100%) ist!!
>
>Um welchen Faktor sind wohl moderne Rechner schneller
>geworden seit es Delphi 5 gibt?
Wenn etwas 2x schneller ist, ist es 2x schneller.
Egal wie schnell die CPU ist.
Zudem steigen auch die Anforderungen....
Und wenn ich doppelt so viel Leistung f�r das
gleiche Geld bekommen k�nnte, warum nicht?
Soeren Muehlbauer
> Zumindest h�tte der Kunde bzgl. Angebot uns Nachfrage
> mehr in der Hand die Richtung vorzugeben, anstatt
> einfach so davon auszugehen das jedem Unicode gef�llt.
> Performance ist ein ziemlich m�chtiges Argument.
> Vor allem, wenn es bei Faktor >2 (>100%) ist!!
Was meinst Du was Deine Meinung z�hlt? Nichts. Du bist bei D5 h�ngen
geblieben. Du bist kein zahlender Kunde. Damit bist Du schon aus dem
Rennen im Spiel "W�nsch Dir was".
S�ren
Soeren Muehlbauer
>>> zum anderen die Verarbeitung im "Bauch"
>>> toppelt so viele Bytes transferieren muss.
>> Dann nimm einen FileStream und einen AnsiString und schon
>> ist die Ansiwelt (fast) wieder in Ordnung ;)
>
> Darauf wird das wohl hinaus laufen... alles b�se umfrickeln :(
Du hast deinen Quelltext schon weit vorher kaputtgefrickelt. Der Typ
String ist wie der Integer-Typ "Integer" (und andere) vor �nderungen
nicht gesch�tzt. Du darfst Dich also nicht wundern, wenn Du einen
Integer in einen Stream schreibst und mit Delphi Commodore wieder lesen
m�chtest, nur Schrott rauskommt[1]. Auch bei Deinem D5 gibt es
AnsiString. H�ttest Du nicht beim Schreiben Deines Quelltextes den
Fehler begangen anzunehmen, w�rdest Du hier nicht kritisieren m�ssen.
S�ren
[1] Ich weiss, dass Integer wahrscheinlich 32bit breit bleibt. Zumindest
macht IRC MS bei C++ so. Verlassen w�rde ich mich darauf aber nicht.
Arno Garrels
> Hallo Arno,
>
> "Arno Garrels" <arno.g...@gmx.de> schrieb im
> Newsbeitrag news:hc44ki$2n8$1...@online.de...
>
>> Hubert Seidel wrote:
>>> ...
>>>> Aber nicht mit Laufzeitpackages von Dritten, die kann ich ggf.
>>>> geliefert werden.
>>>
>>> Wird doch jetzt auch für jede Version so gemacht.
>> Nein, wie kommst du denn darauf?
>
Ah ok, dann wären aber zwei pro Delphi-Version notwendig.
> ...
>>> Zumindest hätte der Kunde bzgl. Angebot uns Nachfrage
>>> mehr in der Hand die Richtung vorzugeben, anstatt
>>> einfach so davon auszugehen das jedem Unicode gefällt.
>>
>> Mit "Gefallen" hat das wohl weniger zu tun als mit den
>> gewachsenen Anforderungen in einer globalisierten Welt.
>
> 1) Deswegen hätte der Unicode-String trotsdem
> anders implementiert werden können ;-)
Also so kommen wir nicht weiter, weil du offenbar jede
Innovation seit Delphi 5 ablehnst.
Mal Unicode im allgemeinen und dann wieder Unicode-Delphi
(dass du noch nicht einmal getestet hast).
>> Bedenke, dass Delphi eine der letzten IDEs war, die auf
>> Unicode umgestellt hat, der Druck der Benutzer wurde am
>> Ende wohl doch zu groß. So eine tiefgreifende Änderung
>> macht CG bestimmt nicht, wenn es dafür keine große
>> Nachfrage gibt (CodeGear/Embarcardero ist nicht Borland).
>
> siehe 1)
>
>>> Performance ist ein ziemlich mächtiges Argument.
>>> Vor allem, wenn es bei Faktor >2 (>100%) ist!!
>>
>> Um welchen Faktor sind wohl moderne Rechner schneller
>> geworden seit es Delphi 5 gibt?
>
> Wenn etwas 2x schneller ist, ist es 2x schneller.
> Egal wie schnell die CPU ist.
> Zudem steigen auch die Anforderungen....
Genau, und nicht alle neuen Features sind mumpitz, Unicode
zähle ich zu den nützlichen Innovationen, die dann auch
etwas Rechenzeit kosten dürfen.
--
Arno Garrels
Hubert Seidel
"Arno Garrels" <arno.g...@gmx.de> schrieb im
Newsbeitrag news:hc50on$tla$1...@online.de...
>Hubert Seidel wrote:
>>>> Wird doch jetzt auch f�r jede Version so gemacht.
>>> Nein, wie kommst du denn darauf?
>> F�r jede Delphi-, nicht String-Version.
>
>Ah ok, dann w�ren aber zwei pro Delphi-Version notwendig.
Aber nur, wenn es ANSI-Relevant ist.
Wobei ich glaube, wenn ANSI genau so 1 zu 1 weiter
unterst�tzt werden w�rde, aufgrund leichterer
portierbarkeit weniger abspringen.
>> ...
>> 1) Deswegen h�tte der Unicode-String trotsdem
>> anders implementiert werden k�nnen ;-)
>
>Also so kommen wir nicht weiter, weil du offenbar jede
>Innovation seit Delphi 5 ablehnst.
Wieso jede?
Wie man liest, sieht es bei Delphi momentan nicht so gut aus.
:-(momentan dauert derzeit leider schon etwas l�nger)
So bin ich dabei mich suzzesive bei andere Themen zu
etablieren (Gibte sicher ein paar, denen das recht kommt ;-).
Die k�nnen dann anschl. so richtig ihre M�rchen ablassen...
>Mal Unicode im allgemeinen und dann wieder Unicode-Delphi
>(dass du noch nicht einmal getestet hast).
Ich habe immerhin bis D2005 getestet....
>>> Bedenke, dass Delphi eine der letzten IDEs war, die auf
>>> Unicode umgestellt hat, der Druck der Benutzer wurde am
>>> Ende wohl doch zu gro�. So eine tiefgreifende �nderung
Welcher Druck auf was?
Man h�tte doch WideString aufbohren k�nnen.
Wenn der neue String wie bei C++ WString gehei�en h�tte,
dann w�re die Welt auch in ordnung gewesen.
Aber nein, dam muss der string �ber das Knie gebrochen werden :(
...
>> Wenn etwas 2x schneller ist, ist es 2x schneller.
>> Egal wie schnell die CPU ist.
>> Zudem steigen auch die Anforderungen....
>
>Genau, und nicht alle neuen Features sind mumpitz, Unicode
>z�hle ich zu den n�tzlichen Innovationen, die dann auch
>etwas Rechenzeit kosten d�rfen.
Ich habe grunds�tzlich nichts gegen Unicode-Unterst�tzung!
Es ist nur grob fahrl�ssig das die Abw�rtskompatibilit�t nicht
mit einem Schalter gew�rleistet ist, wie damals bei der
Umstellung/Erweiterung von ShortString auf LongString.
Mir fehlen bei meinen Kollegen nun jegliche Argumente :-(
Und zwar fehlen die mir _f�r_ Delphi...
Hubert Seidel
(der Name ist Programm ;-)
"Soeren Muehlbauer" <soer...@gmx.de> schrieb im
Newsbeitrag news:7kmerqF...@mid.individual.net...
...
> > Darauf wird das wohl hinaus laufen... alles b�se umfrickeln :(
>
> Du hast deinen Quelltext schon weit vorher kaputtgefrickelt. Der Typ
Wer sagt denn, das ich _meinen_ Code warte?
Meine Lieferungen sind (bisher nahezu gespenstisch) wartungsfrei :-)))
Wenn, dann isr nur ne Mikroschraube zu justieren...
...
> Fehler begangen anzunehmen, w�rdest Du hier nicht kritisieren m�ssen.
Als Frau Flodder gefragt wurde, ob der Gestank st�ren w�rde,
fragte sie: Welcher Gestank? Du fragst das gleiche in gr�n!
ofg.
Herby
--
http://www.hubert-seidel.eu
Hubert Seidel
"Soeren Muehlbauer" <soer...@gmx.de> schrieb im
Newsbeitrag news:7kmeb2F...@mid.individual.net...
> Hallo,
:-(
http://de.wikipedia.org/wiki/H%C3%B6flichkeitsform
)
...
> > Vor allem, wenn es bei Faktor >2 (>100%) ist!!
>
> Was meinst Du was Deine Meinung z�hlt? Nichts. Du bist bei D5 h�ngen
> geblieben. Du bist kein zahlender Kunde. Damit bist Du schon aus dem
> Rennen im Spiel "W�nsch Dir was".
Das ist nur Deine (primitive:) Meinung :-)
Ich bin nicht _der zahlende Kunde_!
Damit hast Du v�llig und absolut Recht!!!!!!
Ich bin jemand, der den _zahlenden Kunden_ "vern�nftig" ber�t!!
((Und Du nist f�r mich nur eine platzende Managerblase :-))
ofg.
Herby
P.S:
Bei Deinem/dem Bullshit, solltest Du Deine
Beitr�ge auf aklle F�lle OffTopic kennzeichnen!!!!
P.P:S:
Eigentlich waren wir "per Sie" geblieben...
--
http://www.hubert-seidel.eu
Hans-Peter Diettrich
>> vollst�ndiges Produkt ist. Ich ben�tige Lazarus seitdem ich von
>> Windows zu Linux gewechselt habe, und Delphi dort nicht pr�sent ist.
>
> Es gab doch mal Kylix -- wurde das nicht weiterentwickelt?
Bis zur Version 3, dann war Sense.
Die Akzeptanz war wohl zu gering, und die CLX so verkr�ppelt, da� nicht
mal die IDE als native Linux Anwendung compiliert werden konnte :-(
Kylix l�uft unter den aktuellen Kernels schon lange nicht mehr.
DoDi
Soeren Muehlbauer
>>> Darauf wird das wohl hinaus laufen... alles b�se umfrickeln :(
>> Du hast deinen Quelltext schon weit vorher kaputtgefrickelt. Der Typ
>
> Wer sagt denn, das ich _meinen_ Code warte?
> Meine Lieferungen sind (bisher nahezu gespenstisch) wartungsfrei :-)))
> Wenn, dann isr nur ne Mikroschraube zu justieren...
Wor�ber beschwerst Du Dich dann? Kaum ein anderer hat Probleme mit der
Unicode-Umsetzung in Delphi. Schau Dir mal die Nutzerbasis und deren
Meinung an. Die finden das Konzept durchaus �berzeugend.
>> Fehler begangen anzunehmen, w�rdest Du hier nicht kritisieren m�ssen.
>
> Als Frau Flodder gefragt wurde, ob der Gestank st�ren w�rde,
> fragte sie: Welcher Gestank? Du fragst das gleiche in gr�n!
Ahja, ich keine einzige Frage gestellt.
S�ren
Soeren Muehlbauer
> http://de.wikipedia.org/wiki/H%C3%B6flichkeitsform
G�hn.
> ...
>>> Vor allem, wenn es bei Faktor >2 (>100%) ist!!
>> Was meinst Du was Deine Meinung z�hlt? Nichts. Du bist bei D5 h�ngen
>> geblieben. Du bist kein zahlender Kunde. Damit bist Du schon aus dem
>> Rennen im Spiel "W�nsch Dir was".
>
> Das ist nur Deine (primitive:) Meinung :-)
> Ich bin nicht _der zahlende Kunde_!
> Damit hast Du v�llig und absolut Recht!!!!!!
Sag ich doch.
> Ich bin jemand, der den _zahlenden Kunden_ "vern�nftig" ber�t!!
> ((Und Du nist f�r mich nur eine platzende Managerblase :-))
Der Kunde ist also jemand, welcher seinen Quelltext nicht unter
Kontrolle hat? Dem Kunden, welcher f�r ein Softwareprodukt zahlt, ist es
v�llig wurscht, wie es entwickelt wird. Er hat nur Interesse daran,
seine Anforderungen umgesetzt zu bekommen. Eine sehr h�ufige Forderung
international t�tiger Unternehmen ist die Unterst�tzung von Zeichen in
unterschiedlichen CodePages. BTW, wird Embarcadero nur im Enterprise
Umfeld richtig Geld verdienen. Dazu ist es aber eben unabdingbar korrekt
mit Unicode umgehen zu k�nnen und es dem Entwickler m�glichst leicht zu
machen. Kaum ein Entwickler, welcher in einer Hochsprache entwickelt
macht sich die M�he, seinen Quelltext auf Assemblerebene zu optimieren.
Dazu fehlt einfach die Zeit, wenn man Lieferzeiten einhalten muss.
> P.S:
> Bei Deinem/dem Bullshit, solltest Du Deine
> Beitr�ge auf aklle F�lle OffTopic kennzeichnen!!!!
Fr�her gab es hier mal sogenannte Regulars. Von denen h�tte ich mir das
vielleicht angenommen. Aber von _Dir_ lasse ich mir nicht vorschreiben,
wie ich meine Postings absetze.
> P.P:S:
> Eigentlich waren wir "per Sie" geblieben...
In Newsgruppen rede ich alle mit Du an. Was Du davon h�lst ist mir
ehrlich gesagt egal.
S�ren
Heinz Zastrau
> Es ist nur grob fahrlï¿œssig das die Abwï¿œrtskompatibilitï¿œt nicht
> mit einem Schalter gewï¿œrleistet ist, wie damals bei der
> Umstellung/Erweiterung von ShortString auf LongString.
Muss das nicht "Ich finde es grob fahrlï¿œssig..." heiï¿œen? Ich persï¿œnlich
finde es grob fahrlï¿œssig wenn man seine persï¿œnliche Meinung als eine
allgemeine Wahrheit verkaufen will.
> Mir fehlen bei meinen Kollegen nun jegliche Argumente :-(
> Und zwar fehlen die mir _fï¿œr_ Delphi...
Da bin ich jetzt erstaunt. Bisher hatte ich auf Grund Deiner Mails den
Eindruck Du wï¿œrdest Dich fï¿œr D5 stark machen. Du beklagst bei Delphi2010
mangelnde Kompatibilitï¿œt und auf der anderen Seite wï¿œrdest Du eine
komplette Neuentwicklung akzeptieren?
Ich glaube nicht das Du mit Delphi jemals glï¿œcklich wirst. Mit Deinem
Wissen (das mir einen sehr fundierten Eindruck macht, ich kann nur nicht
alle deine Meinungen nachvollziehen) scheinst Du mir eher ein C++ Typ zu
sein.
Ciao Heinz Z.
Soeren Muehlbauer
> Aber nur, wenn es ANSI-Relevant ist.
> Wobei ich glaube, wenn ANSI genau so 1 zu 1 weiter
> unterst�tzt werden w�rde, aufgrund leichterer
> portierbarkeit weniger abspringen.
Wieso �bertr�gst Du Deine Meinung auf die Allgemeinheit?
>>> 1) Deswegen h�tte der Unicode-String trotsdem
>>> anders implementiert werden k�nnen ;-)
>> Also so kommen wir nicht weiter, weil du offenbar jede
>> Innovation seit Delphi 5 ablehnst.
>
> Wieso jede?
Die anderen kennst Du wahrscheinlich noch nicht:-)
> Ich habe immerhin bis D2005 getestet....
Du meinst das schlechteste Delphi auf Mutter Erde? Damit kann man keinen
Blumentopf gewinnen:-(.
>
>>>> Bedenke, dass Delphi eine der letzten IDEs war, die auf
>>>> Unicode umgestellt hat, der Druck der Benutzer wurde am
>>>> Ende wohl doch zu gro�. So eine tiefgreifende �nderung
>
> Welcher Druck auf was?
> Man h�tte doch WideString aufbohren k�nnen.
> Wenn der neue String wie bei C++ WString gehei�en h�tte,
> dann w�re die Welt auch in ordnung gewesen.
Genau das sollte ja vermieden werden.
> Aber nein, dam muss der string �ber das Knie gebrochen werden :(
Deine Interpretation von String=AnsiString bleibt weiterhin falsch.
> Ich habe grunds�tzlich nichts gegen Unicode-Unterst�tzung!
> Es ist nur grob fahrl�ssig das die Abw�rtskompatibilit�t nicht
> mit einem Schalter gew�rleistet ist, wie damals bei der
> Umstellung/Erweiterung von ShortString auf LongString.
Das ist unn�tz. Wenn die Entwickler nicht aus ihren damaligen Fehlern
gelernt haben und die Datentypen entsprechend deklarieren, sollte auch
die Entwicklungsumgebung nicht unn�tige Komplexit�t erzeugen.
S�ren
Arno Garrels
> Hallo Arno,
>
> "Arno Garrels" <arno.g...@gmx.de> schrieb im
> Newsbeitrag news:hc50on$tla$1...@online.de...
>
>> Hubert Seidel wrote:
>>>> Nein, wie kommst du denn darauf?
>>
>> Ah ok, dann wären aber zwei pro Delphi-Version notwendig.
>
> Aber nur, wenn es ANSI-Relevant ist.
> Wobei ich glaube, wenn ANSI genau so 1 zu 1 weiter
> portierbarkeit weniger abspringen.
Du meinst die Portierbarkeit, die du selbst nicht kennst,
weil nie getestet?
>>> 1) Deswegen hätte der Unicode-String trotsdem
>>> anders implementiert werden können ;-)
>>
>> Also so kommen wir nicht weiter, weil du offenbar jede
>> Innovation seit Delphi 5 ablehnst.
>
> Wieso jede?
Das ist mein Eindruck, oder du kennst die neuen Features
noch nicht.
> Wie man liest, sieht es bei Delphi momentan nicht so gut aus.
> :-(momentan dauert derzeit leider schon etwas länger)
Seit Delphi 2007 wird die Qualität wieder spürbar besser,
aber diese Versionen hast du ja nie getestet.
> So bin ich dabei mich suzzesive bei andere Themen zu
> etablieren (Gibte sicher ein paar, denen das recht kommt ;-).
> Die können dann anschl. so richtig ihre Märchen ablassen...
Ich frage mich _wer hier wohl der Märchenerzähler ist.
>>>> Bedenke, dass Delphi eine der letzten IDEs war, die auf
>>>> Unicode umgestellt hat, der Druck der Benutzer wurde am
>>>> Ende wohl doch zu groß. So eine tiefgreifende Änderung
>
> Welcher Druck auf was?
> Man hätte doch WideString aufbohren können.
Na dann viel Spaß bei der Umstellung alter Projekte auf
Unicode.
> ...
>>> Wenn etwas 2x schneller ist, ist es 2x schneller.
>>> Egal wie schnell die CPU ist.
>>> Zudem steigen auch die Anforderungen....
>>
>> Genau, und nicht alle neuen Features sind mumpitz, Unicode
>> zähle ich zu den nützlichen Innovationen, die dann auch
>> etwas Rechenzeit kosten dürfen.
>
> Ich habe grundsätzlich nichts gegen Unicode-Unterstützung!
> Es ist nur grob fahrlässig das die Abwärtskompatibilität nicht
> mit einem Schalter gewärleistet ist, wie damals bei der
> Umstellung/Erweiterung von ShortString auf LongString.
Ansi ist seit NT4 auf der Windowsplattform veraltet, es würde
mich nicht wundern, wenn Windows demnächst keine A-API mehr
anbieten wird.
Die Umstellung auf Unicode kann nicht einfacher gewährleistet
werden als sie es jetzt ist. Wer nicht auf Unicode umsteigen
will, sollte besser bei D2007 bleiben.
> Mir fehlen bei meinen Kollegen nun jegliche Argumente :-(
> Und zwar fehlen die mir _für_ Delphi...
In dieser Gruppe gab es genug davon zu lesen.
--
Arno Garrels
Mario Rothacher
> Das ist unn�tz. Wenn die Entwickler nicht aus ihren damaligen Fehlern
> gelernt haben und die Datentypen entsprechend deklarieren, sollte auch
> die Entwicklungsumgebung nicht unn�tige Komplexit�t erzeugen.
By the way... String ist ja nun mal einfach per �bersetzung aus dem
Englischen gem�ss Google folgendes:
Nomen
1. Schnur
2. Koppel
3. Faden
4. Spagat
5. Leine
6. Band
7. Bindfaden
8. Reihe
9. Serie
10. Strippe
11. Sehne
12. Kette
13. Schlange
14. Saite
Verb
1. aufreihen
2. reihen
3. besaiten
4. beziehen
Wieso bekommt der String nun neben dieser �bersetzung eine spezifische
Codierung? Oder anders gefragt, bin�re Dateninhalte habe ich bisher auch
per string verarbeiten k�nnen. Das kann ich nun nicht mehr, da zum
Beispiel beim einlesen mittels Stringlist.LoadFromFile eine Umwandlung
in Unicode vollzogen wird. Also ist die Bytefolge nicht mehr identisch
mit der Bytefolge auf der Platte. Welchen Typ soll ich f�r Bin�re Daten
in Zukunft nehmen? Und welche Klasse bietet mir �hnlich simple Methoden
wie LoadFromFile um die Bin�rdaten in den Speicher zu kriegen? Gibts
eine TAnsiStringList? AnsiString w�rde ja wohl funktionieren, aber ist
meiner Ansicht nach auch falsch. Denn ich will ja bloss Bytes aufreihen
und nicht irgendwelche Konventionen bez�glich Inhalt angeben.
Ich bin noch mit Delphi 2007 unterwegs. W�re sch�n zu wissen, wie man
solche Stolpersteine bei einer Umstellung auf Delphi 2010 beheben kann.
cu
Mario
Heinz Zastrau
> Wieso bekommt der String nun neben dieser ï¿œbersetzung eine spezifische
> Codierung? Oder anders gefragt, binï¿œre Dateninhalte habe ich bisher auch
> per string verarbeiten kï¿œnnen. Das kann ich nun nicht mehr, da zum
> Beispiel beim einlesen mittels Stringlist.LoadFromFile eine Umwandlung
> in Unicode vollzogen wird. Also ist die Bytefolge nicht mehr identisch
> mit der Bytefolge auf der Platte.
TStringList ist bei binï¿œren Daten gefï¿œhrlich weil die Folge #10#13 nicht
korrekt gelesen wird. Auch ein #0 macht Probleme. Mir scheint ein
dynamisches Array of Byte sinnvoll. Die Laderoutine braucht keine 10
Zeilen. Evt. kann man in Delphi2010 auch RawByteString verwenden. Den
sollte man aber nicht in Kombination mit Stringliterale oder anderen
Stringtypen verwenden.
Kleine Beispiel zur Verdeutlichung (Delphi 2006):
procedure TForm1.Button1Click(Sender: TObject);
var
s: String;
a: array of byte;
begin
s := #10#13#0#13#10;
with TFileStream.Create('test.dat', fmCreate) do
try
Write(s[1], Length(s));
finally
Free;
end;
with TStringList.Create do
try
LoadFromFile('test.Dat');
s := Text; // ergibt s #$D#$A#$D#$A - was falsch ist
finally
Free;
end;
with TStringList.Create do
try
LineBreak := '';
LoadFromFile('test.Dat');
s := Text; // ergibt s #$D#$A - was falsch ist
finally
Free;
end;
with TFileStream.Create('test.dat', fmOpenRead) do
try
SetLength(a, Size);
Read(a[0], Size); // ergibt [10, 13, 0, 10, 13] - was richtig ist
finally
Free;
end;
end;
Ciao Heinz Z.
Arno Garrels
> Soeren Muehlbauer wrote:
>> gelernt haben und die Datentypen entsprechend deklarieren, sollte
>
>
> Wieso bekommt der String nun neben dieser Übersetzung
> eine spezifische Codierung?
http://de.wikipedia.org/wiki/Zeichenkette:
"Eine Zeichenkette oder ein String (englisch) ist eine Folge von
Zeichen (z. B. Buchstaben, Ziffern, Sonderzeichen und Steuerzeichen)
aus einem definierten Zeichensatz."
In Delphi ist "string" ein reserviertes Wort und kein Datentyp.
War früher ein Alias für Datentyp AnsiString und jetzt für
UnicodeString.
> Oder anders gefragt, binäre Dateninhalte habe ich bisher
> auch per string verarbeiten können.
Das war möglich aber trotzdem falsch.
> Das kann ich nun nicht mehr, da
> zum Beispiel beim einlesen mittels Stringlist.LoadFromFile eine
> Umwandlung in Unicode vollzogen wird. Also ist die Bytefolge nicht
> mehr identisch mit der Bytefolge auf der Platte. Welchen Typ soll ich
> für Binäre Daten in Zukunft nehmen?
> Und welche Klasse bietet mir
> ähnlich simple Methoden wie LoadFromFile um die Binärdaten in den
> Speicher zu kriegen?
Binärdaten haben nun wirklich nichts in einer StringListe zu suchen.
Es gibt schon länger TBytes und TFileStream.
> Gibts eine TAnsiStringList? AnsiString würde ja
> wohl funktionieren, aber ist meiner Ansicht nach auch falsch.
Gibt es nicht, aber Jedi hat sie, oder mach dir eine eigene.
Aber Binärdaten gehören da nicht rein sondern Ansitext!
> Denn
> ich will ja bloss Bytes aufreihen und nicht irgendwelche Konventionen
> bezüglich Inhalt angeben.
TBytes = array of Byte; ist dafür gedacht.
>
> Ich bin noch mit Delphi 2007 unterwegs. Wäre schön zu wissen, wie man
> solche Stolpersteine bei einer Umstellung auf Delphi 2010 beheben
> kann.
In D2007 gibt es bereits TBytes, dann kannst du ja schonmal die
dicksten Brocken aus dem Weg räumen.
--
Arno Garrels
Mario Rothacher
> TStringList ist bei binï¿œren Daten gefï¿œhrlich weil die Folge #10#13 nicht
> korrekt gelesen wird. Auch ein #0 macht Probleme. Mir scheint ein
> dynamisches Array of Byte sinnvoll. Die Laderoutine braucht keine 10
> Zeilen. Evt. kann man in Delphi2010 auch RawByteString verwenden. Den
> sollte man aber nicht in Kombination mit Stringliterale oder anderen
> Stringtypen verwenden.
ï¿œh stimmt... Stringlist verwende ich ja auch nicht bei binï¿œren Daten,
sondern Filestream und string... Solange ich keine Stringmanipulationen
mache, bleibt der Inhalt wohl so wie er ist und wird nicht konvertiert?
RawByteString sieht jedenfalls schon mal vom Namen her gesehen richtig aus.
cu
Mario
Mario Rothacher
> Mario Rothacher wrote:
>> Soeren Muehlbauer wrote:
>>> gelernt haben und die Datentypen entsprechend deklarieren, sollte
>>
>> Wieso bekommt der String nun neben dieser �bersetzung
>
> http://de.wikipedia.org/wiki/Zeichenkette:
> "Eine Zeichenkette oder ein String (englisch) ist eine Folge von
> Zeichen (z. B. Buchstaben, Ziffern, Sonderzeichen und Steuerzeichen)
> aus einem definierten Zeichensatz."
Eine Zeichenkette ist ein string, aber ein string ist nicht nur eine
Zeichenkette. Jedenfalls ist das das, was ich in der Informatik unter
String verstehe. Und das string eben Bin�rdaten gerade in Delphi (<2010)
auch enthalten k�nnen ist eigentlich durch die Definition dass auch
#0-Zeichen nicht als Stringendkennzeichen gelten, sondern die L�nge
zus�tzlich gespeichert wird. Das sah ich bisher als grossen Vorteil
gegen�ber anderen Sprachen an. Das string bisher ein Synonym f�r
Ansistring gegelten haben sollte, stimmt so nicht �berein. Denn in einem
string wird nichts �ber eine Codepage gesagt.
Da ist meiner Meinung nach schon ein Bruch geschehen. Ich kann damit
leben und die fehleranf�lligen Codestellen sollten einfach zu ersetzen sein.
cu
Mario
Hans-Peter Diettrich
> By the way... String ist ja nun mal einfach per �bersetzung aus dem
> Englischen gem�ss Google folgendes:
[...]
> Wieso bekommt der String nun neben dieser �bersetzung eine spezifische
> Codierung?
Die Frage ist berechtigt. Ebenfalls aus dem Englischen sind Bytes und
Chars (bei ASCII) ziemlich gleichbedeutend, und so kam es zu einer
global unbrauchbaren Vermischung der Begriffe :-(
> Oder anders gefragt, bin�re Dateninhalte habe ich bisher auch
> per string verarbeiten k�nnen.
Im Prinzip gibt es daf�r jetzt RawByteString, aber der ist IMO
unbrauchbar implementiert, nicht passend zum Namen :-(
Offiziell wird AFAIR TBytes f�r Bin�rdaten propagiert.
> Das kann ich nun nicht mehr, da zum
> Beispiel beim einlesen mittels Stringlist.LoadFromFile eine Umwandlung
> in Unicode vollzogen wird. Also ist die Bytefolge nicht mehr identisch
> mit der Bytefolge auf der Platte.
In Delphi sollte man unter "string" stets Text verstehen, und damit ist
diese Umwandlung systemkonform.
> Welchen Typ soll ich f�r Bin�re Daten
> in Zukunft nehmen? Und welche Klasse bietet mir �hnlich simple Methoden
> wie LoadFromFile um die Bin�rdaten in den Speicher zu kriegen?
Bei Bin�rdaten reicht ja ein TFileStream und BlockRead in einen
entsprechenden Datentyp (Record...).
DoDi
Arno Garrels
> Arno Garrels wrote:
>> Mario Rothacher wrote:
>>> Soeren Muehlbauer wrote:
>>>> Fehlern gelernt haben und die Datentypen entsprechend deklarieren,
>>>> erzeugen.
>>>
>>> Wieso bekommt der String nun neben dieser Übersetzung
>>> eine spezifische Codierung?
>>
>> http://de.wikipedia.org/wiki/Zeichenkette:
>> "Eine Zeichenkette oder ein String (englisch) ist eine Folge von
>> Zeichen (z. B. Buchstaben, Ziffern, Sonderzeichen und Steuerzeichen)
>> aus einem definierten Zeichensatz."
>
> Eine Zeichenkette ist ein string, aber ein string ist nicht nur eine
> Zeichenkette. Jedenfalls ist das das, was ich in der Informatik unter
> String verstehe.
Das wäre mir neu.
> Und das string eben Binärdaten gerade in Delphi
> (<2010) auch enthalten können ist eigentlich durch die Definition
> dass auch #0-Zeichen nicht als Stringendkennzeichen gelten, sondern
> die Länge zusätzlich gespeichert wird. Das sah ich bisher als grossen
> Vorteil gegenüber anderen Sprachen an.
Daran hat sich ja auch nichts geändert. Gefahr besteht und bestand
immer dann, wenn der String als Zeichenkette interpretiert wurde.
Einige RTL-Routinen tun das genauso wie eine TStringList oder der
Compiler bei Stringcasts.
> Das string bisher ein Synonym
> für
> Ansistring gegelten haben sollte, stimmt so nicht überein. Denn in
> einem string wird nichts über eine Codepage gesagt.
Ein "AnsiString" wird und wurde immer mit aktueller Ansi-System-Codepage
interpretiert. Seit D2009 besitzen alle Strings ein Codepage-Feld.
Der neue Utf8String ist jetzt z.B. ein AnsiString mit Codepage
CP_UTF8 und nicht mehr ein simpler Typalias.
Auf Utf8String ist also bei der Umstellung ggf. zu achten.
>
> Da ist meiner Meinung nach schon ein Bruch geschehen. Ich kann damit
> leben und die fehleranfälligen Codestellen sollten einfach zu
> ersetzen sein.
Ein Bruch mit altem, fehlerhaftem Kode ja, so betrachtet zwingt
einen Delphi 2010 zu besserem Stil.
--
Arno Garrels
Arno Garrels
>> Oder anders gefragt, binäre Dateninhalte habe ich bisher auch
>> per string verarbeiten können.
>
> Im Prinzip gibt es dafür jetzt RawByteString, aber der ist IMO
> unbrauchbar implementiert, nicht passend zum Namen :-(
Der ist nicht unbrauchbar implementiert, so ein Blödsinn!
Gleichwohl der Name für alle möglichen Spekulationen sorgt.
RawByteString = type AnsiString($ffff); // Ungültige Codepage!
RawByteString weist den Compiler an, keine impliziten
Ansistringumwandlung vorzunehmen. Diesen Typ verwendet man
hauptsächlich als Parameter, was einem das Schreiben von
overloads erspart. Denn es ist seit D2009 möglich eigene
Ansitypen zu deklarieren, so viele, wie Codepages vorhanden
sind :)
--
Arno Garrels
Soeren Muehlbauer
> BTW, wird Embarcadero nur im Enterprise
> Umfeld richtig Geld verdienen.
Damit ist vor allem gemeint, dass man nicht auf jeden Hobbyisten h�ren
kann, sondern das Ohr der zahlenden Mehrheit zuwendet. Ich habe mir
privat auch die eine oder andere Delphi-Version geg�nnt. Bei den
heutigen Preisen ist das nicht mehr machbar. Das k�nnen durchaus auch
mittelst�ndige Unternehmen sein.
S�ren
Hubert Seidel
"Mario Rothacher" <mario.r...@gmx.ch> schrieb im
Newsbeitrag news:hc6upc$tiv$1...@gwaiyur.mb-net.net...
...
> By the way... String ist ja nun mal einfach per �bersetzung aus dem
> Englischen gem�ss Google folgendes:
>
> Nomen
...
> 4. Spagat
triff derzeit wohl am Besten ;-)
...
> Wieso bekommt der String nun neben dieser �bersetzung eine spezifische
> Codierung? Oder anders gefragt, bin�re Dateninhalte habe ich bisher
auch
> per string verarbeiten k�nnen. Das kann ich nun nicht mehr, da zum
Ja, vor allem das wirklich alle Zeichen enthalten sein d�rfen.
(also #0 bis #255)
Aber daf�r klappt ja in der "ach so perfekten Unicodewelt"
(zumindest glauben da wohl ein paar dran ;-) so etwas wie:
var
wc:WideChar;
begin
wc:=#600000;
Caption:=IntToStr(Ord(wc));
end;
Da frage ich mich, wieso das trotz eingeschalteter
Bereichs- und �berlaufpr�fung zugewiesen werden darf?
Anschl. steht aber leider 10176 im Titel :-(((
Ich h�tte bei einem gut implementierten Unicode-String/Char
erwartet das man auch #60000 oder #100000 zuweisen kann.
> Beispiel beim einlesen mittels Stringlist.LoadFromFile eine Umwandlung
> in Unicode vollzogen wird. Also ist die Bytefolge nicht mehr identisch
Diese Umwandlung finde ich auch �berfl�ssig.
Bisher gab es solche Magics bei Delphi nicht.
Wenn ich das h�tte haben wollen, w�rde ich VB nehmen ;-)
> mit der Bytefolge auf der Platte. Welchen Typ soll ich f�r Bin�re
Daten
> in Zukunft nehmen? Und welche Klasse bietet mir �hnlich simple
Methoden
TFileStream
> wie LoadFromFile um die Bin�rdaten in den Speicher zu kriegen? Gibts
Mit Read aus dem Filestream, oder ggf. MemoryStream.
> eine TAnsiStringList? AnsiString w�rde ja wohl funktionieren, aber ist
> meiner Ansicht nach auch falsch. Denn ich will ja bloss Bytes
aufreihen
> und nicht irgendwelche Konventionen bez�glich Inhalt angeben.
TStringList konvertiert jedoch CR/LF.
Die bin�rdaten sind also nich garantiert unver�ndert.
(Was ich jedoch sehr gut finde)
Hubert Seidel
"Soeren Muehlbauer" <soer...@gmx.de> schrieb im Newsbeitrag
news:7knhueF...@mid.individual.net...
> > http://de.wikipedia.org/wiki/H%C3%B6flichkeitsform
> G�hn.
Das war mir klar...
> > P.S:
> > Bei Deinem/dem Bullshit, solltest Du Deine
> > Beitr�ge auf aklle F�lle OffTopic kennzeichnen!!!!
>
> Fr�her gab es hier mal sogenannte Regulars. Von denen h�tte ich mir
das
> vielleicht angenommen. Aber von _Dir_ lasse ich mir nicht
vorschreiben,
> wie ich meine Postings absetze.
das auch...
Ich hoffe Sie schaffen es diemal auf mehr konstruktive Beitr�ge.
mfg.
Herby
--
http://www.hubert-seidel.eu
http://groups.google.de/group/de.comp.lang.delphi.misc/browse_thread/thread/6b72e4504ab583d6/91175802e5bd17a7?hl=de&q=
Hubert Seidel
"Arno Garrels" <arno.g...@gmx.de> schrieb im
Newsbeitrag news:hc6ott$anc$1...@online.de...
>Hubert Seidel wrote:
>> "Arno Garrels" schrieb:
...
>> Aber nur, wenn es ANSI-Relevant ist.
>> Wobei ich glaube, wenn ANSI genau so 1 zu 1 weiter
>> unterst�tzt werden w�rde, aufgrund leichterer
>> portierbarkeit weniger abspringen.
>
>Du meinst die Portierbarkeit, die du selbst nicht kennst,
>weil nie getestet?
Hier in der NG wurden entspr. viele Beispiele geliefert.
Die Messergebnisse und Fakten sprechen f�r sich.
...
>> Wieso jede?
>Das ist mein Eindruck, oder du kennst die neuen Features
>noch nicht.
Ich bin sogar so offen f�r Inovationen,
das ich diese gar au�erhalb des Delphi-Umfeldes angehe.
>Ich frage mich _wer hier wohl der M�rchenerz�hler ist.
Du hast bestimmt das KnowHow die in
news:7kb532F...@mid.individual.net
geforderten Hausaufgaben (zu Lebzeiten) zu pr�fen.
Entgegen dem Hausaufgabensteller, er pr�ft offensichtlich noch ;-)
Evtl. auch eine gute Denksportaufgabe/Ablenkung f�r SM?
Immerhin soll es beweisen ob man von Programmierung
in Hochsprachen Ahnung hat. Bis zu einem gewissen Teil richtig.
Hubert Seidel
"Mario Rothacher" <mario.r...@gmx.ch> schrieb im
Newsbeitrag news:hc76i5$cag$1...@gwaiyur.mb-net.net...
...
> > http://de.wikipedia.org/wiki/Zeichenkette:
> > "Eine Zeichenkette oder ein String (englisch) ist eine Folge von
> > Zeichen (z. B. Buchstaben, Ziffern, Sonderzeichen und Steuerzeichen)
> > aus einem definierten Zeichensatz."
>
> Eine Zeichenkette ist ein string, aber ein string ist nicht nur eine
> Zeichenkette. Jedenfalls ist das das, was ich in der Informatik unter
Dann korrigiere doch mal bitte gleich den Wiki-Eintrag ;-)
> String verstehe. Und das string eben Bin�rdaten gerade in Delphi
(<2010)
> auch enthalten k�nnen ist eigentlich durch die Definition dass auch
> #0-Zeichen nicht als Stringendkennzeichen gelten, sondern die L�nge
> zus�tzlich gespeichert wird. Das sah ich bisher als grossen Vorteil
Die L�nge wird ja statt dessen "#0 als Endekennzeichen" gespeichert.
> gegen�ber anderen Sprachen an. Das string bisher ein Synonym f�r
> Ansistring gegelten haben sollte, stimmt so nicht �berein. Denn in
einem
> string wird nichts �ber eine Codepage gesagt.
string ist nat�rlich kein synonym f�r Ansistring.
Nur fr�her konnte string ein short- oder longstring sein ($H-Schalter).
Nun soll es ein short- oder Unicodestring sein.
Warum nicht short- long oder Unicodestring?
####
Hubert Seidel
"Soeren Muehlbauer" <soer...@gmx.de> schrieb im
Newsbeitrag news:7knhueF...@mid.individual.net...
...
>> Der Kunde ist also jemand, welcher seinen Quelltext nicht unter
>> Kontrolle hat? Dem Kunden, welcher f�r ein Softwareprodukt zahlt,
>> ist es v�llig wurscht, wie es entwickelt wird.
>> Er hat nur Interesse daran,
>> seine Anforderungen umgesetzt zu bekommen. Eine sehr h�ufige
"Er hat nur Interesse daran",
bedeutet im Umkehrschluss ja
"an nichts anderem Interesse".
Es gibt Kunden die nicht nur funktionales Interesse haben.
Z.b. weil sicher gestellt sein muss, das wenn der
Entwickler kein Bock mehr auf Entwicklung hat und Pilot wird,
die Software dennoch weiter entwickelt werden kann.
Z.b. weil sicher gestellt sein muss, das die Software
an neue Anforderung leicht/schnell angepasst werden kann.
Z.b. weil sicher gestellt sein muss, das...
Du solltest Dir Kunden w�nschen die
wenigstens zwei Interessen haben.
Hubert Seidel
"Heinz Zastrau" <heinz....@gmx.de> schrieb im
Newsbeitrag news:op.u2gezx04litn6d@heinz...
> > Es ist nur grob fahrl�ssig das die Abw�rtskompatibilit�t nicht
> > mit einem Schalter gew�rleistet ist, wie damals bei der
> > Umstellung/Erweiterung von ShortString auf LongString.
>
> Muss das nicht "Ich finde es grob fahrl�ssig..." hei�en? Ich
pers�nlich
> finde es grob fahrl�ssig wenn man seine pers�nliche Meinung als eine
> allgemeine Wahrheit verkaufen will.
Grunds�tzlich hast Du nat�rlich recht.
Hintergrund meiner Behauptung ist:
Der "neue string" >=2009 ist scheinbar nur noch Unicode- oder
Shortstring.
M�chte man longstring haben, soll man AnsiString nehmen.
Zudem der Unicode-String nur ein WideString mit Referenzz�hlung ist.
Intern ist dieser UTF-16 codiert und kann demnach surrogate-Pairs
enthalten, welche nur h�ndisch ber�cksichtigt werden kann.
> Da bin ich jetzt erstaunt. Bisher hatte ich auf Grund Deiner Mails den
> Eindruck Du w�rdest Dich f�r D5 stark machen. Du beklagst bei
Delphi2010
Nein, ich mach mich nicht f�r D5 stark.
Bin da nur h�ngen geblieben :-(
> mangelnde Kompatibilit�t und auf der anderen Seite w�rdest Du eine
> komplette Neuentwicklung akzeptieren?
Meinst Du die "Neuentwicklung" bezgl. eigenen
Ansi-Funktionen, oder den Wechsel auf andere Technologien?
Im allgemeinen ist das Vertrauen seit geraumer Zeit angekratzt.
> Ich glaube nicht das Du mit Delphi jemals gl�cklich wirst. Mit Deinem
Zumindest war ich sehr lange Zeit mit Delphi sehr gl�cklich.
> Wissen (das mir einen sehr fundierten Eindruck macht, ich kann nur
nicht
> alle deine Meinungen nachvollziehen) scheinst Du mir eher ein C++ Typ
zu
> sein.
Vereinfacht sollte m�glich sein:
- eine klassische IDE zu verwenden
- string per Schalte als long- und unicodestring erm�glichen
Zwei kleinigkeiten mit gro�er Wirkung.
Hubert Seidel
"Mario Rothacher" <mario.r...@gmx.ch> schrieb im
Newsbeitrag news:hc75rs$ams$1...@gwaiyur.mb-net.net...
> Heinz Zastrau wrote:
> > TStringList ist bei bin�ren Daten gef�hrlich weil die Folge #10#13
nicht
...
> �h stimmt... Stringlist verwende ich ja auch nicht bei bin�ren Daten,
> sondern Filestream und string... Solange ich keine
Stringmanipulationen
> mache, bleibt der Inhalt wohl so wie er ist und wird nicht
konvertiert?
> RawByteString sieht jedenfalls schon mal vom Namen her gesehen richtig
aus.
Nicht selten kapsel ich ein TMemoryStream und weise die Eigenschaft
Memory einem pointer zu welcher auf die gew�nscht Datenstruktur zeigt.
Dank LoadFromFile/LoadFromStream ist das sehr leicht handhabbar.
Hubert Seidel
"Hubert Seidel" <nos...@hubert-seidel.de> schrieb im
Newsbeitrag news:hc7s4j$3u9$00$1...@news.t-online.com...
...
> Nicht selten kapsel ich ein TMemoryStream und weise die Eigenschaft
> Memory einem pointer zu welcher auf die gew�nscht Datenstruktur zeigt.
> Dank LoadFromFile/LoadFromStream ist das sehr leicht handhabbar.
Die einzige mir bisher bekannte Falle ist:
Der Pointer muss aktualisiert werden, wenn sich die Gr��e des
MemoryStream �ndert.
Hubert Seidel
"Arno Garrels" <arno.g...@gmx.de> schrieb im Newsbeitrag
news:hc75rf$lo1$1...@online.de...
>Mario Rothacher wrote:
>> Wieso bekommt der String nun neben dieser �bersetzung
>> eine spezifische Codierung?
>
>http://de.wikipedia.org/wiki/Zeichenkette:
>"Eine Zeichenkette oder ein String (englisch) ist eine Folge von
>Zeichen (z. B. Buchstaben, Ziffern, Sonderzeichen und Steuerzeichen)
>aus einem definierten Zeichensatz."
>
>In Delphi ist "string" ein reserviertes Wort und kein Datentyp.
>War fr�her ein Alias f�r Datentyp AnsiString und jetzt f�r
>UnicodeString.
Was den fr�heren Part angeht, nicht ganz richtig:
<ZitatAusDerOH_GueltigkeitLokal>
Die Direktive $H legt fest, welche Bedeutung das reservierte Wort string
hat, wenn es ohne Zusatz in einer Typdeklaration steht. Der generische
Typ String kann entweder einen langen, dynamisch zugewiesenen String
(vom fundamentalen Typ Ansi-String) oder einen kurzen, statisch
zugewiesenen String (vom fundamentalen Typ ShortString) darstellen.
</ZitatAusDerOH_GueltigkeitLokal>
Was den neueren Part angeht, nur vom H�rensagen:
Entweder ShortString oder UnicodeString, jedoch nicht
AnsiString/LongString.
Arno Garrels
> Hallo Arno,
>
> "Arno Garrels" <arno.g...@gmx.de> schrieb im Newsbeitrag
> news:hc75rf$lo1$1...@online.de...
>
>> Mario Rothacher wrote:
>>> eine spezifische Codierung?
>>
>> http://de.wikipedia.org/wiki/Zeichenkette:
>> "Eine Zeichenkette oder ein String (englisch) ist eine Folge von
>> Zeichen (z. B. Buchstaben, Ziffern, Sonderzeichen und Steuerzeichen)
>> aus einem definierten Zeichensatz."
>>
>> In Delphi ist "string" ein reserviertes Wort und kein Datentyp.
>> UnicodeString.
>
> <ZitatAusDerOH_GueltigkeitLokal>
> Die Direktive $H legt fest, welche Bedeutung das reservierte Wort
> string hat, wenn es ohne Zusatz in einer Typdeklaration steht. Der
> generische Typ String kann entweder einen langen, dynamisch
> zugewiesenen String (vom fundamentalen Typ Ansi-String) oder einen
> kurzen, statisch zugewiesenen String (vom fundamentalen Typ
> ShortString) darstellen.
>
> </ZitatAusDerOH_GueltigkeitLokal>
>
> Entweder ShortString oder UnicodeString, jedoch nicht
> AnsiString/LongString.
Die Directive $H gib es nicht mehr (online help bug).
Sehr wohl gibt es ShortString, der muss dann aber auch so
explizit deklariert werden.
--
Arno Garrels
Hubert Seidel
"Soeren Muehlbauer" <soer...@gmx.de> schrieb im
Newsbeitrag news:7ko2cuF...@mid.individual.net...
...
> > Ich habe immerhin bis D2005 getestet....
>
> Du meinst das schlechteste Delphi auf Mutter Erde? Damit kann man
keinen
> Blumentopf gewinnen:-(.
Ja, vermutlich gar schlechter als Delphi 4.
Offensichtlich versucht man negative Rekorde zu brechen :-(
> > Welcher Druck auf was?
> > Man h�tte doch WideString aufbohren k�nnen.
> > Wenn der neue String wie bei C++ WString gehei�en h�tte,
> > dann w�re die Welt auch in ordnung gewesen.
>
> Genau das sollte ja vermieden werden.
Auf die Gefahr hin das ich mich wiederhole (und das tue ich):
Es w�re auch OK gewesen, wenn es einen Schalter
f�r Abw�rtskompatibilit�t gegeben h�tte.
> > Aber nein, dam muss der string �ber das Knie gebrochen werden :(
> Deine Interpretation von String=AnsiString bleibt weiterhin falsch.
Das ist nicht meine, das ist Ihre Interpretation meiner Postings.
Ich moniere den fehlenden Abw�rtskompatibilit�tsschalter.
Warum?
Damit ich eine alte Unit mit neuem Delphi h�tte compilieren
k�nnen, indem ich in der ersten Zeile vergl. {$ANSISTRING ON}
oder �hnliches hingeschrieben h�tte. Fertig aus.
Bei Performance-Probleme aufgrund unn�tiger Konvertierungen,
kann man sich dann immer noch Gedanken machen.
Hauptsache es l�uft so wie fr�her. Wo ist das Problem?
> > Ich habe grunds�tzlich nichts gegen Unicode-Unterst�tzung!
> > Es ist nur grob fahrl�ssig das die Abw�rtskompatibilit�t nicht
> > mit einem Schalter gew�rleistet ist, wie damals bei der
> > Umstellung/Erweiterung von ShortString auf LongString.
>
> Das ist unn�tz. Wenn die Entwickler nicht aus ihren damaligen Fehlern
> gelernt haben und die Datentypen entsprechend deklarieren, sollte auch
> die Entwicklungsumgebung nicht unn�tige Komplexit�t erzeugen.
Es geht gar nicht nur um Fehler.
Sie haben offensichtlich nicht alle Postings gelesen.
Der Unicodestring ben�tigt 2 mal mehr Speicher.
Dementspr. wird die doppelte Zeit bei jedem Transfer ben�tigt.
Dabei ist unerheblich ob die Messung in einer Schleife
erfolgt um ein m�glichst genauen Faktor zu bekommen, oder beim
Erstmaligem Zugriff, welcher sich nur schlecht messen l�sst.
(Schlecht messen, aufgrund starker Schwankungen)
Und so sind wir wieder an dem Punkt, wo als Hausaufgabe ein
Fehler gesucht werden sollte, den _ich_ gar nicht gemacht habe.
(In diese Kerbe werde ich noch �fters hauen, bis zur L�sung ;-)
Hubert Seidel
"Arno Garrels" <arno.g...@gmx.de> schrieb im
Newsbeitrag news:hc7tos$d8f$1...@online.de...
>Die Directive $H gib es nicht mehr (online help bug).
>Sehr wohl gibt es ShortString, der muss dann aber auch so
>explizit deklariert werden.
D.h. man kann bei string nicht mal zwischen
short- und Unicode-String wechseln...
Gut zu wissen.
Vielen Dank &
Hubert Seidel
"Soeren Muehlbauer" <soer...@gmx.de> schrieb im Newsbeitrag
news:7knhb1F...@mid.individual.net...
...
> > Meine Lieferungen sind (bisher nahezu gespenstisch) wartungsfrei
:-)))
> > Wenn, dann isr nur ne Mikroschraube zu justieren...
>
> Wor�ber beschwerst Du Dich dann? Kaum ein anderer hat Probleme mit der
Wenn Sie auf meine Postings eingehen w�rdest, dann
w�rden Sie die Frage nicht stellen, sondern es wissen.
Ob Sie die Punkte anschl. akzeptierst, ist ein anderes Thema.
Aber Sie w�rden diese Frage nicht stellen, um mir
zu beweisen das Sie mich _nicht_ verstehen (wollen :-).
> Unicode-Umsetzung in Delphi. Schau Dir mal die Nutzerbasis und deren
> Meinung an. Die finden das Konzept durchaus �berzeugend.
Weniger als das Beste ist nicht gut genug.
Wenn _Sie_ sich damit zufrieden geben: OK.
Das beweist f�r mich keine Qualit�t.
Hans-Peter Diettrich
>>> Oder anders gefragt, bin�re Dateninhalte habe ich bisher auch
>>> per string verarbeiten k�nnen.
>> Im Prinzip gibt es daf�r jetzt RawByteString, aber der ist IMO
>> unbrauchbar implementiert, nicht passend zum Namen :-(
>
> Der ist nicht unbrauchbar implementiert, so ein Bl�dsinn!
> Gleichwohl der Name f�r alle m�glichen Spekulationen sorgt.
> RawByteString = type AnsiString($ffff); // Ung�ltige Codepage!
> RawByteString weist den Compiler an, keine impliziten
> Ansistringumwandlung vorzunehmen.
Das gilt aber leider nur f�r jungfr�uliche Strings. Bei jeder Zuweisung
kann sich das Encoding �ndern :-(
> Diesen Typ verwendet man
> haupts�chlich als Parameter, was einem das Schreiben von
> overloads erspart.
Soweit okay, aber das ist IMO ein Mi�brauch dieses Typs. Genausogut
h�tte man AnsiString f�r Parameter verwenden k�nnen.
> Denn es ist seit D2009 m�glich eigene
> Ansitypen zu deklarieren, so viele, wie Codepages vorhanden
> sind :)
Strings mit eingebauter Encoding-Information waren schon �berf�llig.
Sch�n, da� es die jetzt gibt, aber die Implementierung hat IMO noch
Kinderkrankheiten.
DoDi
Soeren Muehlbauer
>>> Der Kunde ist also jemand, welcher seinen Quelltext nicht unter
>>> Kontrolle hat? Dem Kunden, welcher f�r ein Softwareprodukt zahlt,
>>> ist es v�llig wurscht, wie es entwickelt wird.
>>> Er hat nur Interesse daran,
>>> seine Anforderungen umgesetzt zu bekommen. Eine sehr h�ufige
>
> "Er hat nur Interesse daran",
> bedeutet im Umkehrschluss ja
> "an nichts anderem Interesse".
Das bedeutet es f�r Dich. Wenn Du weiter Erbsen z�hlen m�chtest, dann
bitte. Eine seiner Anforderung ist Stabilit�t in Bezug auf den
Vertragspartner. Viele Vertr�ge sehen eine Hinterlegung des Quelltextes
inkl. der Entwicklungsumgebung beim Notar vor.
> Du solltest Dir Kunden w�nschen die
> wenigstens zwei Interessen haben.
Meine Kunden haben Anforderungen und diese werden umgesetzt.
S�ren
Soeren Muehlbauer
>>> Welcher Druck auf was?
>>> Man h�tte doch WideString aufbohren k�nnen.
>>> Wenn der neue String wie bei C++ WString gehei�en h�tte,
>>> dann w�re die Welt auch in ordnung gewesen.
>> Genau das sollte ja vermieden werden.
>
> Auf die Gefahr hin das ich mich wiederhole (und das tue ich):
> Es w�re auch OK gewesen, wenn es einen Schalter
> f�r Abw�rtskompatibilit�t gegeben h�tte.
Abw�rtskompatibilit�t ist immer noch gew�hrleistet. Borland hat damals
beim �bergang von IRC D1 auf D2 den Schalter $H eingef�hrt, da es vorher
_keinen_ Datentypen f�r ShortString gab! Der heutige Fall sieht aber
ganz anders aus. AnsiString existiert schon lange!
>>> Aber nein, dam muss der string �ber das Knie gebrochen werden :(
>> Deine Interpretation von String=AnsiString bleibt weiterhin falsch.
>
> Das ist nicht meine, das ist Ihre Interpretation meiner Postings.
> Ich moniere den fehlenden Abw�rtskompatibilit�tsschalter.
> Warum?
> Damit ich eine alte Unit mit neuem Delphi h�tte compilieren
> k�nnen, indem ich in der ersten Zeile vergl. {$ANSISTRING ON}
> oder �hnliches hingeschrieben h�tte. Fertig aus.
Wahrer werden Deine Aussagen trotzdem nicht. Du hast den Fehler gemacht
string mit AnsiString gleichzusetzen. Da kann nun wirklich niemand
ausser Dir was daf�r.
>> Das ist unn�tz. Wenn die Entwickler nicht aus ihren damaligen Fehlern
>> gelernt haben und die Datentypen entsprechend deklarieren, sollte auch
>> die Entwicklungsumgebung nicht unn�tige Komplexit�t erzeugen.
>
> Es geht gar nicht nur um Fehler.
> Sie haben offensichtlich nicht alle Postings gelesen.
> Der Unicodestring ben�tigt 2 mal mehr Speicher.
Du vermischst mehrere Sachen. Wenn Dir der UnicodeString nicht gef�llt,
nutze doch AnsiString! Du kannst auch weiterhin die Ansi-Funktionen aus
dem WinAPI aufrufen!
> Dementspr. wird die doppelte Zeit bei jedem Transfer ben�tigt.
> Dabei ist unerheblich ob die Messung in einer Schleife
> erfolgt um ein m�glichst genauen Faktor zu bekommen, oder beim
> Erstmaligem Zugriff, welcher sich nur schlecht messen l�sst.
> (Schlecht messen, aufgrund starker Schwankungen)
Du siehst Probleme, wo keine sind. Nutze den f�r den Einsatzfall
richtigen Datentyp!
> Und so sind wir wieder an dem Punkt, wo als Hausaufgabe ein
> Fehler gesucht werden sollte, den _ich_ gar nicht gemacht habe.
> (In diese Kerbe werde ich noch �fters hauen, bis zur L�sung ;-)
Ich erledige weder welche, noch gebe ich welche auf. Wir sind ja hier
schlie�lich nicht im Kindergarten oder der Schule.
S�ren