Re: Vererbung und scope
Stefan Reuther
ich leite das mal um zu den Windowsprogrammieren...
Markus Wichmann wrote:
> Markus Donath <ma_d...@t-online.de> wrote:
>>On 05.08.2009 10:03, James Kanze wrote:
>>>wchar_t** nicht. Die meisten Betriebssysteme unterstützen es
>>>nicht. char** mit UTF-8 funktionniert auf all Unix, die ich
>>>kenne; ich glaube, dass es auch unter Windows geht. (Absolut
>>>portabel kann es nicht sein. Es gibt Systeme, wo Zeichen in
>>>EBCDIC kodiert sind, z.B.)
>>
>>Aber das 'meistverbreitetste' Betriebssystem untertützt es. Mit dem
>>aktuellen MSVC ist es überhaupt kein Problem, UTF-16 Parameter an ein
>>Programm zu übergeben:
>>
>>int APIENTRY _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
>>LPTSTR lpCmdLine, int nCmdShow);
>>
>>wobei 'LPTSTR' nach:
>>
>>typedef unsigned short WCHAR; // wc, 16-bit UNICODE character
>>typedef __nullterminated WCHAR *NWPSTR, *LPWSTR, *PWSTR;
>>typedef LPWSTR PTSTR, LPTSTR;
>>
>>aufgelöst wird.
>>
>>Nur ist das natürlich nicht standardkonform.
>
> Diese Form der main-Funktion ist sowieso ein Krampf:
>
> hInstance - wieso nicht gleich eine PID? Am Ende kann man das sowieso
> für die gleichen Sachen verwenden.
Einige Aufrufe benutzen ein HINSTANCE, aber kaum einer eine PID.
> hPrevInstance - ist AFAIK immer 0. Wozu dann?
Kompatibilität....
> lpCmdLine - och nee, ich darf die auch noch selbst in Worte zerlegen?
> Nebenbei bemerkt gibt es seit Windows95 keinen Unterschied
> zwischen einem short pointer und einem long pointer mehr,
> weswegen das 'l' sinnlos ist.
Als kleinen Anreiz dazu, Unicode-Programme zu schreiben, enthält das
Win32-API eine Funktion 'CommandLineToArgvW' (aber keine Funktion
'CommandLineToArgvA' für "ANSI"-Programme).
Selberparsen ist unter Windows schon deswegen angesagt, weil es zum
guten Ton gehört, dass jedes Programm seine eigenen Globbing- und
Quotingregeln mitbringt.
> nCmdShow - Noch so ein Witz -- dieser Parameter ist nur für
> GUI-Programme von Belang, wird aber an _alle_ ausgeliefert.
> Na toll.
Korrigier mich, wenn ich mich irre, aber meine nicht-GUI-Programme
enthalten ganz normal eine 'main'-Funktion, keine 'WinMain'.
> Und dann wollen die ja angeblich UTF-16 im Dateisystem unterstützen,
> aber wehe, man verwendet mal einen Umlaut im Dateinamen.
Das funktioniert schon. 'CreateFileW(L"\u1234", ...)', kein Problem. Nur
das ganze durch die 8-bit-Kommandozeile zu schleusen macht keinen Spaß.
Überhaupt scheitert sogar Microsoft an der Kommandozeile: "Москва.doc"
im Explorer doppelklicken scheitert mit einer Fehlermeldung von Word,
"??????.doc" nicht öffnen zu können, mit Word->Datei->Öffnen geht's aber
ganz normal.
>>>>Dann ist der Standard wohl nicht mehr ganz zeitgemäß.
>>>
>>>Wieso. UTF-8 wird zu eine universele Norm, und geht, wo das
>>>System es unterstützt. (In Allgemein: wchar_t soll man nur
>>>intern benutzen. Sofort Daten das Programm verlassen, gilt char.
>>>Das in einem modernen System UTF-8 enthalten kann und soll.)
>>
>>UTF-16 und UTF-32 sind auch universelle Normen. Ein Unicodezeichen passt
>>nunmal nicht in ein Byte. Deshalb sind Typen mit mindestens 2 Byte eben
>>besser geeignet.
>
> Wie schon beschrieben, passt es auch nicht unbedingt in 2 Byte. Also
> spart UTF-8 in jedem Fall mehr Platz als UTF-16.
Das kommt ganz auf die Sprache an. CJK braucht in UTF-8 eben drei Bytes
pro Zeichen und damit mehr als UTF-16. Bei Kyrillisch ist es egal, und
für uns Westeuropäer ist UTF-8 immer eine Ersparnis gegenüber UTF-16.
Stefan
James Kanze
> > lpCmdLine - och nee, ich darf die auch noch selbst in Worte zerlegen?
> > Nebenbei bemerkt gibt es seit Windows95 keinen Unterschied
> > zwischen einem short pointer und einem long pointer mehr,
> > weswegen das 'l' sinnlos ist.
> Als kleinen Anreiz dazu, Unicode-Programme zu schreiben,
> enthält das Win32-API eine Funktion 'CommandLineToArgvW' (aber
> keine Funktion 'CommandLineToArgvA' für "ANSI"-Programme).
> Selberparsen ist unter Windows schon deswegen angesagt, weil
> es zum guten Ton gehört, dass jedes Programm seine eigenen
> Globbing- und Quotingregeln mitbringt.
So wie jedes Dienstprogramm unter Unix reguläre Ausdrücke leicht
anders interpretiert. Unter Unix hat das zu Perl geführt.
(Eigentlich bin ich auch der Meinung, dass die Globbing im
Prozeß gehört, und nicht im Shell. Aber bitte nicht, dass jedes
Programm seine eigene Version mitbringt. Leiter scheint mir die
Funktion CommandLineToArgW ein bisschen grob; ich möchte z.B.
können, ein Parameter mit * auf zwei Verzeichnisse zu globben.
Immerhin geht es in die richtige Richtung.)
[...]
> > Wie schon beschrieben, passt es auch nicht unbedingt in 2
> > Byte. Also spart UTF-8 in jedem Fall mehr Platz als UTF-16.
> Das kommt ganz auf die Sprache an. CJK braucht in UTF-8 eben
> drei Bytes pro Zeichen und damit mehr als UTF-16.
CJK braucht Zeichen außerhalb dem BMP. Also 4 Bytes mit UTF-16.
Dagegen wenn du nur mit lateinischen Schriftarten zu tun hast,
oder mit "europäischen" Schriftarten, UTF-16 braucht immer genau
ein Halbwort; in solchen Fällen hast du mit UTF-16 alle
Vorteilen von UTF-32, in halb des Platz.
Aber solche Überlegungen gelten nur Programmintern.
> Bei Kyrillisch ist es egal, und für uns Westeuropäer ist UTF-8
> immer eine Ersparnis gegenüber UTF-16.
Immer? Typischerweise sicher; es gibt aber eine Menge seltener
lateinische Buchstaben, die in UTF-8 drei Bytes verlangen, dazu
einige Interpunktion (der Dolch oder die deutschen
Anführungszeichen, z.B., oder das Eurozeichen).
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Stefan Reuther
> On Aug 10, 7:15 pm, Stefan Reuther <stefan.n...@arcor.de> wrote:
>>>lpCmdLine - och nee, ich darf die auch noch selbst in Worte zerlegen?
>>> Nebenbei bemerkt gibt es seit Windows95 keinen Unterschied
>>> zwischen einem short pointer und einem long pointer mehr,
>>> weswegen das 'l' sinnlos ist.
>
>>Als kleinen Anreiz dazu, Unicode-Programme zu schreiben,
>>enthält das Win32-API eine Funktion 'CommandLineToArgvW' (aber
>>keine Funktion 'CommandLineToArgvA' für "ANSI"-Programme).
>
>>Selberparsen ist unter Windows schon deswegen angesagt, weil
>>es zum guten Ton gehört, dass jedes Programm seine eigenen
>>Globbing- und Quotingregeln mitbringt.
>
> So wie jedes Dienstprogramm unter Unix reguläre Ausdrücke leicht
> anders interpretiert. Unter Unix hat das zu Perl geführt.
>
> (Eigentlich bin ich auch der Meinung, dass die Globbing im
> Prozeß gehört, und nicht im Shell. Aber bitte nicht, dass jedes
> Programm seine eigene Version mitbringt.
Genau letzteres wird wohl die Folge sein, wenn du es dem Prozess
überlässt. Weil sich dann der Autor des 'echo'-Utilities fragen wird,
wozu er denn eigentlich Globbing braucht, "ist doch viel nützlicher,
wenn man den auszugebenden Text nicht zu quoten braucht".
Und ehrlich gesagt hab ich diese Freiheit durchaus schon benutzt, damit
sich der Nutzer eines meiner Scriptinterpreter (allerdings für DOS)
nicht so sehr verrenken muss, wenn er ihm ein Script auf der Kommando-
zeile übergibt.
> Leiter scheint mir die
> Funktion CommandLineToArgW ein bisschen grob; ich möchte z.B.
> können, ein Parameter mit * auf zwei Verzeichnisse zu globben.
> Immerhin geht es in die richtige Richtung.)
Globbt die Funktion überhaupt? Meines Wissens spaltet die nur Argumente
auf, globben darf man selber.
>>>Wie schon beschrieben, passt es auch nicht unbedingt in 2
>>>Byte. Also spart UTF-8 in jedem Fall mehr Platz als UTF-16.
>>
>> Das kommt ganz auf die Sprache an. CJK braucht in UTF-8 eben
>> drei Bytes pro Zeichen und damit mehr als UTF-16.
>
> CJK braucht Zeichen außerhalb dem BMP. Also 4 Bytes mit UTF-16.
Laut Wikipedia sind das "40,000 Unified Han Ideographs that have
previously been seldom used in daily written communications.". Braucht
man die häufig? Und: würde Windows die unterstützen? Wenn ich eine Datei
mit einem Namen anlege, der einem UTF-16-Surrogatpaar entspricht, zeigt
der Explorer zumindest zwei Kästchen für zwei nicht bekannte Glyphen an,
nicht nur eins.
>>Bei Kyrillisch ist es egal, und für uns Westeuropäer ist UTF-8
>>immer eine Ersparnis gegenüber UTF-16.
>
> Immer? Typischerweise sicher; es gibt aber eine Menge seltener
> lateinische Buchstaben, die in UTF-8 drei Bytes verlangen, dazu
> einige Interpunktion (der Dolch oder die deutschen
> Anführungszeichen, z.B., oder das Eurozeichen).
Die würde ich jetzt nicht ernsthaft mitzählen. Wenn man im Text mit
lustigen Grafikzeichen rumoperiert, wird der auch größer, obwohl wir
noch wissen, dass ☺ auch mit einem Byte auskommt (0x01 in Codepage 437).
Die Buchstaben für den Text liegen aber im Wesentlichen unterhalb U+07FF
(Basic Latin, Latin 1, Latin Extended A+B, IPA, Griechisch, Kyrillisch,
Hebräisch, Arabisch).
Stefan
Edzard Egberts
>>>> Wieso. UTF-8 wird zu eine universele Norm, und geht, wo das
>>>> System es unterstützt. (In Allgemein: wchar_t soll man nur
>>>> intern benutzen. Sofort Daten das Programm verlassen, gilt char.
>>>> Das in einem modernen System UTF-8 enthalten kann und soll.)
>>> UTF-16 und UTF-32 sind auch universelle Normen. Ein Unicodezeichen passt
>>> nunmal nicht in ein Byte. Deshalb sind Typen mit mindestens 2 Byte eben
>>> besser geeignet.
>> Wie schon beschrieben, passt es auch nicht unbedingt in 2 Byte. Also
>> spart UTF-8 in jedem Fall mehr Platz als UTF-16.
>
> Das kommt ganz auf die Sprache an. CJK braucht in UTF-8 eben drei Bytes
> pro Zeichen und damit mehr als UTF-16. Bei Kyrillisch ist es egal, und
> für uns Westeuropäer ist UTF-8 immer eine Ersparnis gegenüber UTF-16.
UTF-8 hat den Vorteil, dass es programmintern ein ganz normaler
basic_string< char > ist, und nur in den I/O-Funktionen der GUI und bei
Größenberechnungen des Ausgabebereichs und der Anzahl Zeichen muss die
Auswertung und Umsetzung auf UTF-8 erfolgen. Bei der Eclipse ist es
möglich, den Editor auf UTF-8 umzuschalten, so dass man mit der
entsprechenden GUI (z.B. FLTK 1.3) die komplette Entwicklungsumgebung
unter UTF-8 laufen hat und trotzdem den alten Code verwenden kann. Ich
denke auch, dass die Länge für Westeuropäer immer eine Ersparnis ist und
es für den Rest bei der Leistungsfähigkeit der heutigen Computer nicht
darauf ankommt. Die Kompatibilität ist besser.
Gruß,
Ed