Welches Zeichen, das angibt, dass der nächste Buchstabe in Großschreibung interpretiert werden soll?

[Guido C. (guidoanalog)]

Hallo,

manchmal arbeite ich mit Systemen, die intern nicht zwischen Groß- und 
Kleinschreibung unterscheiden. Eine Abfrage der Art "ä" == "Ä" liefert 
entsprechend der Abfrage "ä" == "ä" den booleschen Wert True. Ich 
behelfe mir in diesem Fall, indem ich großen Buchstaben das "^"-Zeichen 
voranstelle. Die Abfrage lautet somit "ä" == "^ä" und liefert den 
booleschen Wert False.

Meine Frage an Euch: Gibt es ein "offizielles" Zeichen das angibt, dass 
der folgende Buchstabe in Großschreibung interpretiert bzw. ausgegeben 
werden soll?

Mit freundlichen Grüßen
Guido

[Peter II (Gast)]

um welche Programiersprache geht es überhaupt?

> Ich
> behelfe mir in diesem Fall, indem ich großen Buchstaben das "^"-Zeichen
> voranstelle.
du kannst auch "ich will false" davor schreiben dann liefert dann auch 
eine false zurück - aber ob das sinn macht?

[mb (Gast)]

Hi Guido,

wir bauen alle Befehlsinterpreter so, dass nur auf Kleinschreibung 
geprüft wird. Vorher werden alle Befehle in 'lower case' konvertiert. 
Dementsprechend gibt es nur einen Befehlssatz und der Anwender kann die 
Befehle schreiben, wie er möchte.
Vielleicht wäre das für Dein Projekt auch ein weg.

[Guido C. (guidoanalog)]

Hallo,

Peter II schrieb:
> um welche Programiersprache geht es überhaupt?

z. B. FAMOS

Peter II schrieb:
> du kannst auch "ich will false" davor schreiben dann liefert dann auch
> eine false zurück - aber ob das sinn macht?

Ist mir natürlich klar. Mich hätte eher interessiert, ob es hierfür ein 
gebräuchliches Zeichen bzw. eine gebräuchliche Zeichenkette gibt.

Mit freundlichen Grüßen
Guido

[Guido C. (guidoanalog)]

Hallo,

mb schrieb:
> wir bauen alle Befehlsinterpreter so, dass nur auf Kleinschreibung
> geprüft wird. Vorher werden alle Befehle in 'lower case' konvertiert.
> Dementsprechend gibt es nur einen Befehlssatz und der Anwender kann die
> Befehle schreiben, wie er möchte.
> Vielleicht wäre das für Dein Projekt auch ein weg.

Im konkreten Fall möchte ich in Zeichenketten Sonderzeichen durch 
"normale" Zeichen ersetzen (z. B. "ä" durch "ae" oder "Ä" durch "Ae"). 
Die Groß- und Kleinschreibung soll dabei erhalten bleiben. Das 
Schwierigkeit dabei ist weniger das Ersetzen und das ganze "drum herum", 
sondern vielmehr die Tatsache, dass ich innerhalb des Listings eine 
Ersetzungstabelle definieren muss. So in der Art:

Tabelle:{ä} = "ae"
Tabelle:{Ä} = "Ae"
Tabelle:{ö} = "oe"
Tabelle:{Ö} = "Oe"
usw...

Das Problem ist, dass Tabelle:{ä} und Tabelle:{Ä} die gleiche Variable 
ist. Daher die Idee mit

Tabelle:{ä} = "ae"
Tabelle:{^ä} = "Ae"
Tabelle:{ö} = "oe"
Tabelle:{^ö} = "Oe"
usw...

Die Frage ist nur, ob das "^" so glücklich gewählt ist.

Mit freundlichen Grüßen
Guido

[Günther (Gast)]

Guido C. schrieb:
> Gibt es ein "offizielles" Zeichen das angibt, dass
> der folgende Buchstabe in Großschreibung interpretiert bzw. ausgegeben
> werden soll?

nennt sich Shift-Taste.

[MWS (Gast)]

Guido C. schrieb:
> Die Frage ist nur, ob das "^" so glücklich gewählt ist.

Kannst ja auch vereinbaren, dass zwei ää ein Ae ergeben.

[Udo S. (urschmitt)]

Wenn die Systeme keine Unterscheidung machen warum willst du dann mit 
Gewalt eine machen.
Es gibt kein solches Zeichen, denn in praktisch allen Zeichensätzen gibt 
es dafür einfach 2 Zeichen nämlich 'O' und 'o', 'A' und 'a' ...
Wenn du die deutschen Sonderzeichen wegen Suchen ersetzen willst würde 
ich nicht ä mit ae sondern einfach ä mit a ersetzen usw.
Zum suchen und vergleichen einen STring immer in Lowercase konvertieren. 
Wenn du das Original noch für eine Anzeige incl. Großschreibung brauchst 
musst du ihn halt doppelt halten.

[Guido C. (guidoanalog)]

Hallo,

Udo Schmitt schrieb:
> Wenn die Systeme keine Unterscheidung machen warum willst du dann mit
> Gewalt eine machen.

Die Daten kommen von außerhalb des Systems, daher der "Gewaltakt".

Mit freundlichen Grüßen
Guido

[hmmmm (Gast)]

Verstehe ich das richtig: Es gibt intern Repräsentationen für Groß- und 
kleinbuchstaben, aber Vergleiche unterscheiden nicht zwischen Groß- und 
kleinschreibung?
Vielleicht gibts nen Parameter zum einstellen oder ne Extrafunktion mit 
der es geht?
Kannst du auf die ASCII-Codes zugreifen und dir darüber nen Hack bauen?

[Guido C. (guidoanalog)]

Hallo,

hmmmm schrieb:
> Verstehe ich das richtig: Es gibt intern Repräsentationen für Groß- und
> kleinbuchstaben, aber Vergleiche unterscheiden nicht zwischen Groß- und
> kleinschreibung?

Ja. Es gibt keine vordefinierte Funktion, die es ermöglicht zwei 
Zeichenketten unter Berücksichtigung der Groß- und Kleinschreibung zu 
vergleichen. Der Vergleich von "TeST" mit "tesT" liefer True.

hmmmm schrieb:
> Kannst du auf die ASCII-Codes zugreifen und dir darüber nen Hack bauen?

Darauf wollte ich eigentlich hinaus. Beim Einlesen ändere ich alle 
Großbuchstaben in z. B. "^Kleinbuchstabe" und beim Ausgeben geht's 
wieder zurück. Meine Frage war, welches Präfix hierfür üblich ist? Wie 
ich den bisherigen Antwort entnehmen gibt es hierfür jedoch nicht den 
Präfix. Ich werde daher wohl bei "^" bleiben.

Mit freundlichen Grüßen
Guido

[hmmmm (Gast)]

Wenn du auf die Ascii-Codes zugreifen kannst, kannst du dir doch eine 
Vergleichsfunktion bauen?

[Robert L. (lrlr)]

>Beim Einlesen ändere ich alle
>Großbuchstaben

woher weißt du dass es ein großbuchstabe ist ;-)

wenn sich A nicht von a unterscheidet?

mach es wie hmmmm  vorgeschlagen hat...

[Guido C. (guidoanalog)]

Hallo,

Robert L. schrieb:
> woher weißt du dass es ein großbuchstabe ist ;-)

Über die Codes der Zeichen. Hierfür gibt es eine Funktion.

Robert L. schrieb:
> mach es wie hmmmm  vorgeschlagen hat...

Dies würde natürlich auch gehen. Wenn ich jedoch mit einem Präfix 
arbeite, muss ich nur beim Einlesen und Ausgeben der Zeichenketten 
"aktiv werden". Es sind keine weiteren Anpassungen innerhalb bestehender 
Programme notwendig.

Mit freundlichen Grüßen
Guido

[Andreas S. (andreas) (Admin)]

Lass es lieber. Die Kennzeichnung von Großbuchstaben durch ein Präfix 
ist absolut unüblich, und wird bei jedem der deinen Code sieht erst mal 
ein Stirnrunzeln hervorrufen. Ich kann mir auch kein Szenario vorstellen 
in dem so ein Hack sinnvoll ist. Du sparst vielleicht hier und da ein 
paar Zeichen Code, aber du bringst zusätzliche Komplexität in das 
Programm, du erschaffst ein neues Stringformat für das du 
Konvertierungsfunktionen von und zu ASCII schreiben musst, du erzeugst 
Mehrdeutigkeiten ("^Bla", "^bla", "Bla"), musst Sonderfälle behandeln 
("^^bla"), kurz, du kommst von Regen in die Traufe. Schreib dir lieber 
eine strcomp-Funktion die case sensitive ist.

[Reinhard Kern (Gast)]

Andreas Schwarz schrieb:
> Schreib dir lieber
> eine strcomp-Funktion die case sensitive ist.

Aber die übliche C-Funktion strcmp() IST case-sensitive. Ich kenne das 
so, z.B. von Pascal, dass man eine Variation der Funktion (stricmp) 
verwenden muss, wenn man case insensitive prüfen will. Ich dachte 
bisher, das wäre generell so, weil die Basisfunktion schlicht 
ASCII-Werte vergleicht, deshalb wundert mich, dass das angefragte 
Problem überhaupt besteht.

Das Win32 API stellt meiner Erinnerung nach Vergleichsfunktionen für 
jede Art des Vergleichs zur Verfügung. Manche Systeme identifizieren 
übrigens Ä nur als Grossbuchstabe zu ä, wenn deutsch oder europäisch im 
System ausgewählt ist.

Gruss Reinhard

[Guido C. (guidoanalog)]

Hallo,

Andreas Schwarz schrieb:
> Konvertierungsfunktionen von und zu ASCII schreiben musst, du erzeugst
> Mehrdeutigkeiten ("^Bla", "^bla", "Bla"), musst Sonderfälle behandeln
> ("^^bla"), kurz, du kommst von Regen in die Traufe. Schreib dir lieber
> eine strcomp-Funktion die case sensitive ist.

Reinhard Kern schrieb:
> Aber die übliche C-Funktion strcmp() IST case-sensitive. Ich kenne das
> so, z.B. von Pascal, dass man eine Variation der Funktion (stricmp)
> verwenden muss, wenn man case insensitive prüfen will. Ich dachte
> bisher, das wäre generell so, weil die Basisfunktion schlicht
> ASCII-Werte vergleicht, deshalb wundert mich, dass das angefragte
> Problem überhaupt besteht.

Ihr habt sicher recht. Allerdings ist es so, dass ich meine Programme 
bzw. Skripte für imc FAMOS 6.0 schreibe. Dort ist es definitiv so, dass 
alle vordefinierten String-Vergleichfunktionen case-insensitive sind. 
Eine eigene String-Vergleichsfunktion zu schreiben werde ich mir noch 
einmal überlegen. Ich befürchte jedoch, dass diese gegenüber den 
eingebauten Vergleichsfunktionen extrem langsam sein wirde. Damit es für 
Euch verständlicher wird: Dies wäre in etwa damit vergleichbar als würde 
man in MATLAB den Mittelwert der Elemente eines Vektors mittels Schleife 
über alle Elemente berechnen. Die macht natürlich keiner, da Matlab 
hierfür eine eingebaute Funktion bereitstellt, die wesentlich schneller 
ist als eine Schleife über die Elemente des Vektors.

Mit freundlichen Grüßen
Guido

[Markus V. (valvestino)]

Guido C. schrieb:
> Ich befürchte jedoch, dass diese gegenüber den
> eingebauten Vergleichsfunktionen extrem langsam sein wirde.

Eines der grundlegenden Prinzipien in der Software-Entwicklung ist es, 
seinen Code erst einmal simpel und einfach zu entwerfen und erst später 
bei Bedarf Code bezüglich Laufzeit und Speicherbedarf zu optimieren, 
wenn sich herausstellt, das Programm ist zu langsam oder benötigt zu 
viel Speicher. Dies erfolgt mit geeigneten Werkzeugen wie z.B. einfachen 
Zeitmessungen oder Profilern und nicht per Raten. Das funktioniert 
nämlich überhaupt nicht.

In Deinem Fall bedeutet dies: Implementiere einen case-sensitiven 
Sting-Vergleich mittels Schleife und schaue mal, ob da nicht ausreicht. 
Wenn nicht, kannst Du Dir immer noch den Kopf über wilde Optimierungen 
zerbrechen.

Gruß
Markus

[Läubi .. (laeubi)]

Man könnte den case sensitiven Vergleich auch einfach nur dann anstoßen 
wenn der nicht sensitive fehlschlug:

if (cmp(a,b) && caseSensitive(a,b)) {
 //tu was
}

je nachdem wie häufig halt gleiche Werte sind... das bringt aber 
wirklich nur was wenn die "naive" Implementierung sehr viel langsamer 
als die eingebaute ist. Ansonsten gilt was Markus schrieb.

[D. I. (Gast)]

Guido C. schrieb:
> Dies wäre in etwa damit vergleichbar als würde
> man in MATLAB den Mittelwert der Elemente eines Vektors mittels Schleife
> über alle Elemente berechnen. Die macht natürlich keiner, da Matlab
> hierfür eine eingebaute Funktion bereitstellt, die wesentlich schneller
> ist als eine Schleife über die Elemente des Vektors.

Aha wie denn? Multi-threaded mittels Tournier-Verfahren? Sonst fiele mir 
ad hoc erstmal nicht ein wie man unter O(n) das berechnen sollte.

Guido C. schrieb:
> Eine eigene String-Vergleichsfunktion zu schreiben werde ich mir noch
> einmal überlegen. Ich befürchte jedoch, dass diese gegenüber den
> eingebauten Vergleichsfunktionen extrem langsam sein wirde.

Same here, was glaubst du denn was die eingebaute Funktion magisches 
macht außer Zeichen für Zeichen zu vergleichen?

[Arc N. (arc)]

D. I. schrieb:
> Guido C. schrieb:
>> Dies wäre in etwa damit vergleichbar als würde
>> man in MATLAB den Mittelwert der Elemente eines Vektors mittels Schleife
>> über alle Elemente berechnen. Die macht natürlich keiner, da Matlab
>> hierfür eine eingebaute Funktion bereitstellt, die wesentlich schneller
>> ist als eine Schleife über die Elemente des Vektors.
>
> Aha wie denn? Multi-threaded mittels Tournier-Verfahren? Sonst fiele mir
> ad hoc erstmal nicht ein wie man unter O(n) das berechnen sollte.

Und? Die Laufzeiten von Algorithmen der gleichen Komplexität müssen 
nicht identisch sein. Einfach mal das Beispiel mit ein paar Durchläufen 
auf einem 1000k Vektor ausprobieren.

[Robert L. (lrlr)]

>Same here, was glaubst du denn was die eingebaute Funktion magisches
>macht außer Zeichen für Zeichen zu vergleichen?


dass die eingebaute (vermutlich) in z.B. C/C++ usw.  geschrieben ist..

die selbergeschriebene (vermutlich) nicht compiliert, sonder 
interpretiert würde..

[Guido C. (guidoanalog)]

Hallo,

Robert L. schrieb:
> dass die eingebaute (vermutlich) in z.B. C/C++ usw.  geschrieben ist..

das weiß ich leider nicht. Es ist jedoch sehr wahrscheinlich.

Robert L. schrieb:
> die selbergeschriebene (vermutlich) nicht compiliert, sonder
> interpretiert würde..

Dem ist so. FAMOS besitzt einen Interpreter und keinen Compiler. Das 
ganze ist dann auch eher eine Skript- als eine Programmiersprache.

Mit freundlichen Grüßen
Guido

[Robert L. (lrlr)]

ich würd a) trotzdem erstmal die selbergeschriebene StrCompare funktion 
probieren

und b) generell mal das vergleichen von strings in frage stellen..

denn: ist der String von einem EndUSER eingegeben, dann macht 
CaseInsesitiv durchaus sinn..

ist der String nicht von einem EndUser, ist sowieso irgendwas am kozept 
faul..

die mEisten endUser scheren sich nicht so um die großKleinschreibung