IN durch CharInSet ersetzen

[baumina]

OK, fünfmal gelesen und doch falsch interpretiert. :oops: Wenn nicht dann ... sonst ..., grauenhaft.

[Uwe Raabe]

Zitat:

Zitat von baumina (Beitrag 1322648)

Ifndef ?

Deswegen bei genauem Hinsehen...

[himitsu]

Ich wusste nur noch, daß mir die Meldung dieses Jahr schon paar Mal um die Ohren flog,
aber bei ersterem Hinsehen hatte ich irgendwie IFDEF gelesen.


Nja, genau aus diesem Grund versuche ich keine negativen Bedingungen zu verwenden, zumindestens nicht, wenn ein ELSE im Spiel ist.

Und wenn man crossplattform Bibliotheken erstellen will, darf man nun entweder mit IFNDEFs abreiten, oder muß eben auf CharInSet verzichten.
Warum wird hier nur bei NEXTGEN gemeckert? Ich bekomme in Delphi doch sonst auch alle möglichen sinnlosen Warnungen, wenn was in C++ nicht geht. :wall:

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1322662)

oder muß eben auf CharInSet verzichten.

Wenn man es genau nimmt, ist das die sichere Methode. Ich weiß, es wird viele nicht wirklich betreffen, aber sowohl ein

Delphi-Quellcode:

C in [...]

als auch ein

Delphi-Quellcode:

CharInSet

funktioniert so richtig nur dann, wenn die ordinalen Werte unter #128 liegen. Richtiges Unicode geht damit sowieso nicht und bei allem zwischen #128 und #255 spielt die aktuelle Codepage eine Rolle.

Die Verwendung von

Delphi-Quellcode:

IsInArray

ist zugegebenermaßen etwas umständlich, wenn man Bereiche abfragen will, aber für viele reale Abfragen gibt es eigene Routinen (

Delphi-Quellcode:

IsLetter

,

Delphi-Quellcode:

IsDigit

,

Delphi-Quellcode:

IsLower

, ...), die auch für exotische Umgebungen funktionieren und nebenbei den Code in vielen Fällen lesbarer machen.

[SMO]

Zitat:

Zitat von Uwe Raabe (Beitrag 1322667)

Wenn man es genau nimmt, ist das die sichere Methode. Ich weiß, es wird viele nicht wirklich betreffen, aber sowohl ein

Delphi-Quellcode:

C in [...]

als auch ein

Delphi-Quellcode:

CharInSet

funktioniert so richtig nur dann, wenn die ordinalen Werte unter #128 liegen. Richtiges Unicode geht damit sowieso nicht und bei allem zwischen #128 und #255 spielt die aktuelle Codepage eine Rolle.

Genaugenommen spielt die Codepage immer eine Rolle. Die Zeichen zwischen #0 und #127 wären nur dann "sicher", wenn sie in allen Codepages identisch wären - sind sie aber nicht. Siehe z.B. EBCDIC. Hatte gerade erst damit zu tun... habe naiv angenommen, dass CR und LF (zum Erkennen eines Zeilenendes) immer auf #$D und #$A liegen, aber in EBCDIC ist LF #$25.