Als Einsteiger in der Mikrocontroller-Programmierung stellt mich
folgendes vor ein kleines Rätsel:
static const unsigned char string[] = {
0x67, 0x75, 0x61, 0x72, 0x64, 0x20, 0x74, 0x69, 0x6d, 0x65,
0};
könnte man dies doch auch einfach mit folgender Zeile erreichen:
char string[] = "guard time";
Ich schätze mal der erste Ansatz mit den Hex-Werten muss irgendeinen
Vorteil haben, sonst wäre er vermutlich nicht verwendet worden.
Kann mich jemand aufklären?
klar, beides bewirkt das selbe.
aber ich schätze der mir unbekannte "autor" hat das nicht ohne grund
gemacht.
ist ja schließlich einfacher den string in "" einzuschließen.
mich würde eben genau dieser grund interessieren.
zeichensatz konsitenz bei umlauten?
kann der uC das Hex array schneller verarbeiten?
....
Ehrlich gesagt, habe ich keine Lust Dir zu bestätigen, das Du schon ein
so schlauer und kenntnisreicher Programmierer bist.
Denn wenn Du dir wirklich darüber klar wärst das beide Notationen die
selben Daten im Speicher erzeugen, dann solltest Du auch erkennen, das
dann auch im Code kein Unterschied entsteht.
Die ganze Fragerei dient also vermutlich nur dazu dein Ego zu
streicheln.
nun, wie man unschwer erkennen kann, bin ich kein "so schlauer und
kenntnisreicher Programmierer", sonst hätte ich diese Frage wohl nicht
gestellt.
ich für meinen teil gebe mich nun mal nicht mit oberflächlichkeiten wie
"es läuft doch" zufrieden.
unnütze kommentare dieser sorte sind im übrigen nichts als datenmüll,
der foren unnötig aufbläht. sollte man sich verkneifen, denn
weiterhelfen tun die nicht im geringsten...
Es erhöht die gefühlte Wichtigkeit des Codes ;)
Vielleicht war sich die Person, die das geschrieben hat auch nicht
darüber klar, dass es einfacher geht.
Es gibt keinen speziellen Grund warum man so etwas tun sollte.
Das Compilieren mit den Hex Werten geht schneller als mit dem ASCII
Textstring. Dort muss ja schließlich erst nachgeschaut werden was die
Buchstaben in Hex repräsentieren.
Lieber Frank,
Du hast leider nicht verstanden, das ich versucht habe, Dir eine Brücke
zu bauen. Aber gut, wenn Du es denn so haben willst...
>ich für meinen teil gebe mich nun mal nicht mit oberflächlichkeiten wie>"es läuft doch" zufrieden.
Und kannst Du bitte noch das Posting angeben, aus dem Du da zitierst?
>denn weiterhelfen tun die nicht im geringsten...
Das liegt in diese Fall am Leser, nicht am Autor.
Wenn Du mein Post nochmal ganz aufmerksam liest, dann wirst Du merken,
das Du Dir Deine Frage schon selbst beantwortet hast.
Nur weil Du der Meinung bist, das eine Tatsache eine Begründung haben
müsste, die Deinen Ansprüchen genügt, heisst das noch nicht das solch
eine Begründung existiert.
UND WIE ICH DIR SCHON GESCHRIEBEN HABEN ERZEUGEN BEIDE VARIANTEN DIE
GLEICHEN DATEN. LIES DAS UND DENKE DRÜBER NACH!
>nun, wie man unschwer erkennen kann, bin ich kein "so schlauer und>kenntnisreicher Programmierer", sonst hätte ich diese Frage wohl nicht>gestellt.
Wenn Du mein Post aufmerksam gelesen hättest wäre Dir vielleicht
aufgefallen, das ich Dir ja nicht Schlauheit und Kenntnis als Grund für
Deine Frage sondern ein Bedürfnis nach Aufmerksamkeit unterstellt habe.
Das Du nun also Texte nicht verstehen kannst, haben wir damit
ausreichend dargelegt, Du und ich, oder?
Ahem wrote:
Dein Gebrabbel war unnötig, die Frage des Autors ist berechtigt...
> UND WIE ICH DIR SCHON GESCHRIEBEN HABEN ERZEUGEN BEIDE VARIANTEN DIE> GLEICHEN DATEN. LIES DAS UND DENKE DRÜBER NACH!
...denn genau das ist nicht immer der Fall.
Wenn ich "abcde" schreibe, hängt es vom Zeichensatz der übersetzenden
Maschine ab, welchen Zahlenwerten die Buchstaben zugeordnet werden, denn
das muss nicht immer ASCII sein, gerade die obere Hälfte mit
Akzentzeichen usw. variiert doch stark.
Früher auf der Konsole hat man das z.B. schön gesehen, wenn ein Programm
versucht hat, einen Rahmen zu zeichnen, der Zeichensatz der Maschine die
Rahmenzeichen aber woanders einsortiert hatte.
Wenn man den String aus einzelnen Zahlenwerten zusammensetzt, ist es
wenigstens unabhängig davon, welche Maschine den Programmtext übersetzt.
Stefan Ernst wrote:
> Mark Brandis wrote:>> Noch besser wäre freilich ein>>>>
1
staticconstunsignedcharstring[]="guard time\0";
>> Wieso? Der original "Hex-String" hat auch keine zwei Nullen am Ende.
Aber eine. Ich dachte die Nullterminierung muss man immer noch von Hand
machen, oder macht der Compiler die automatisch bei einem static const
char Array?
> Ich schätze mal der erste Ansatz mit den Hex-Werten muss irgendeinen> Vorteil haben, sonst wäre er vermutlich nicht verwendet worden.>> Kann mich jemand aufklären?
Just to confuse the Russians, oh sorry, the chinese... ;-)
@Mark Brandis
> Aha... und in welchen Fällen genau muss ich mich dann selbst um die> Nullterminierung kümmern?
Wenn du den String manitpulierst, z.b. ein zeichen hinten anfügst. (und
zwar nicht mit strcat)
> Wenn ich "abcde" schreibe, hängt es vom Zeichensatz der> übersetzenden Maschine ab, welchen Zahlenwerten die Buchstaben> zugeordnet werden, denn das muss nicht immer ASCII sein,
EBCDIC begegnet man in der freien Wildbahn praktisch nie.
> gerade die obere Hälfte mit Akzentzeichen usw. variiert> doch stark.
ASCII beschreibt einen 7-Bit-Zeichensatz und enthält keine "obere
Hälfte".
Es gibt etliche 8-Bit-Codierungsstandards, die als gemeinsamen Nenner
ASCII verwenden, aber um weitere Symbole erweitern - der sogenannte
DOS-Zeichensatz (CP437) oder der ANSI-Zeichensatz (CP1251) oder aber der
zum ANSI-Zeichensatz sehr ähnliche Latin1-Zeichensatz.
C-Compiler tolerieren i.d.R. die Verwendung von Nicht-ASCII-Zeichen in
Stringkonstanten, bessere Compiler geben dann eine Warnung
("non-portable character" o.ä.) aus.
Sie tolerieren es, aber in Abhängigkeit vom eingestellten Zeichensatz
der übersetzenden Maschine führt derselbe Programmtext zu
unterschiedlichen Programmen. Nicht portabel, wie deine Fehlermeldung
sagt, genau.
@ Sven P.
Du bist mir schon öfter mit irrelevanten und inkorrekten Äusserungen
aufgefallen.
Wenn Du das Originalposting aufmerksam gelesen hättest, wäre Dir
aufgefallen, das der Autor bei der Erstellung des äquivalenten Strings
von einer ASCII-Kodierung ausgegangen ist. Das hat er vielleicht nicht
bewußt getan, aber wenn man das voraussetzt, so ist zu schliessen, das
beide Alternativen mit einem Compiler mit ASCII-Kodierung kompiliert
werden. (Nur so würde es Sinn machen). Daher ergeben beide Alternativen
denselben Code.
Wenn man also die Hex-Werte so wählt, das sie dem String in EBCDIC
äquivalent wären und beide Quellen mit einem Compiler, der von EBCDIC
versteht, kompiliert, wird sich wieder der selbe Code ergeben.
Mit der Maschine hat das im übrigen aber auch nicht das Geringste zu
tun, da nicht diese die Zeichenkodierung festlegt sondern der
Compilerschreiber neben dem Entwickler der Ausgabegeräte. Das hast Du
damit verwechselt, das auf gewissen Maschinen EBCDIC "üblich" war. Aus
der Hardwarestruktur ergibt sich das keineswegs zwingend.
@ Sven P.
Im übrigen möchte ich Dich noch auf folgendes hinweisen.
Da Du die Verwendung des Wortes "Gebrabbel" für nötig gehalten hast,
möchte ich zum einen mein Bedauern darüber äussern, das damit das Niveau
unserer Konversation unnötig gesenkt wird zum anderen aber auch darauf,
dass es sich um ein lautmalerisches Wort handelt, das die sinnlose
Aneinanderreihung von unartikulierten Lauten bezeichnet die keinerlei
Sinn ergeben. Da wir uns hier in Textform austausche, kann dieses Wort
nicht zutreffen.
Trete ich aber dem damit ausgedrückten Gedanken dessen ungeachtet einmal
auf assoziativem Wege näher, so würde er die sinnlose Aneinanderreihung
von Buchstaben bzw. die Abfolge von Lauten bezeichnenden
Buchstabenfolgen bedeuten, die beide keine Worte ergeben. Weder hast Du
mich nicht mit solchen Zeichenfolgen zitiert, noch kann ich selbst
solche in meinen Postings finden.
Wenn Du mich schon herabsetzen willst, dann offenbare dabei nicht noch
Deine Unkenntnis der Sprache und sorge dafür das es wenigsten Anflüge
von Indizien für von Dir kritisierte Äusserungen gibt.
Damit hast Du jedenfalls bestätigt, das Du weder menschlich noch Deinem
Allgemeinwissen nach oder gar fachlich gesehen ernst zu nehmen bist.
Ahem wrote:
> @ Sven P.>> Du bist mir schon öfter mit irrelevanten und inkorrekten Äusserungen> aufgefallen.
Ah ja. Wo denn?
> Wenn Du das Originalposting aufmerksam gelesen hättest, wäre Dir> aufgefallen, das der Autor bei der Erstellung des äquivalenten Strings> von einer ASCII-Kodierung ausgegangen ist.
Da steht in keinem Wort irgendetwas von ASCII drin.
> Wenn man also die Hex-Werte so wählt, das sie dem String in EBCDIC> äquivalent wären und beide Quellen mit einem Compiler, der von EBCDIC> versteht, kompiliert, wird sich wieder der selbe Code ergeben.
Richtig. Und wenn man Zeichen aus der oberen Hälfte des Zeichensatzes
als 'Hex-Werte' hinterlegt, bleiben es immer und überall die gleichen
'Hex-Werte'. Und wenn man die Zeichen direkt in ein Stringliteral fasst,
können sich die 'Hex-Werte' dahinter mit jedem Quellzeichensatz auf der
übersetzenden Maschine ändern. Lediglich der Basiszeichensatz bleibt.
> Mit der Maschine hat das im übrigen aber auch nicht das Geringste zu> tun, da nicht diese die Zeichenkodierung festlegt sondern der> Compilerschreiber neben dem Entwickler der Ausgabegeräte.
Ich glaube, du solltest dir mal meine Beiträge sorgfältiger
durchlesen.
Die Zeichencodes, die im Speicher landen, müssen zur Übersetzungszeit
durch den Zeichensatz der übersetzenden Maschine hindurch. Als einfaches
Beispiel wäre da UTF-8 zu nennen. Wenn ich das UTF8-Zeichen "ê" auf
einer UTF-8-Maschine in einen Stringliteral eingebe und dann übersetze,
stehen dann nämlich mehr Bytes im Speicher, als wenn ich "ê" auf einer
latin-1-Maschine hinterlege. Dem Compiler ist das letztlich wurscht, den
interessieren, wenns hoch kommt, noch Escape-Zeichen ('\').
Relevant ist hier einzig und allein der Zeichensatz der übersetzenden
Maschine (Quellzeichensatz).
Was später auf dem Bildschirm oder auf der Lochkarte landet, ist da noch
ein ganz andres Thema (Ausführungszeichensatz).
Wo du jetzt einen Strich zwischen 'Zeichensatz im Editor' und
'Zeichensatz der Maschine' ziehst, ist mir grad egal. Die 'übersetzende
Maschine' ist für mich diejenige, auf der Programmtext und -code erzeugt
werden.
So, nun kannstes mir glauben oder es selbst ausprobieren oder mir den
Buckel runterrutschen. B.T.D.T.
Ahem wrote:
> @ Sven P.>> Nur immer weiter so. Man braucht Dich garnicht zu disqualifizieren. Das> besorgst Du schon selbst ganz ausgezeichnet.
Ah ja, kein Argumente, dann Behauptungen nicht belegen und schließlich
schmollen. Prima.
Jetzt pass mal auf: Jemand stellt eine simple und berechtigte Frage und
hakt nach. Dann kommst du:
> Ehrlich gesagt, habe ich keine Lust Dir zu bestätigen, das Du schon ein> so schlauer und kenntnisreicher Programmierer bist.
Nun gut. Dann bringst du eine vollkommen irreführende Aussage:
> UND WIE ICH DIR SCHON GESCHRIEBEN HABEN ERZEUGEN BEIDE VARIANTEN DIE> GLEICHEN DATEN. LIES DAS UND DENKE DRÜBER NACH!
Und das gegenüber jemandem, der sowieso noch auf dünnem Eis steht. Auch
gut.
Und jetzt muss ich mich von so einem dahergelaufenen Schreiber, der sich
nicht mal registriert hat, persönlich angreifen lassen, weil ihm oder
ihr die sachlichen Argumente ausgehen?
Merkst du eigentlich, dass du immer weiter von der Diskussion wegläufst?
Das Gebrabbel lautmalerisch ist, weiß ich, vorallem ist es hier Dialekt.
Ich glaub, es geht los. Ich lass mich gerne eines Besseren belehren,
aber nicht auf diesem Weg.
@ Sven P.
>Frank Maier: Hast Post von mir, auf das Gebrabbel von Ahem lass ich mich>hier nicht länger ein.
Das ist nett von Dir, das Du mit Frank privat korrespondieren willst.
Okay ich probier mal was witziges das hat in der Grundschule öfters mal
funktioniert. Achtung jetzt kommts:
Der Klügere gibt nach!
Mal schaun wir das letzte Wort haben muss. ^^
ok, besten dank an alle, die einen konstriuktiven beitrag zur
beantwortung meiner frage geleistet haben.
@Ahem
wenn ich mir deine beiträge (gebrabbel) so ansehe, werde ich einfach das
gefühl nicht los, dass hier jemand ganz anderer ein "Bedürfnis nach
Aufmerksamkeit" hat...
Frank Maier wrote:
> Ich schätze mal der erste Ansatz mit den Hex-Werten muss irgendeinen> Vorteil haben, sonst wäre er vermutlich nicht verwendet worden.
Mal abgesehen von den Problemen mit Umlauten (die auch nicht kleiner
werden, wenn man Hex-Zahlen benutzt), gibt es keinen wirklichen
Unterschied, sofern überall ASCII benutzt wird (EBCDIC lassen wir mal
aussen vor).
Eine Variation davon findet man auch häufig. In Code zum Wandeln von
Zahlen in Textrepräsentierung zu echten Zahlen, ist es notwendig von
einem Character den Charactercode von '0' abzuziehen.
Besonders 'schlaue' Programmierer schreiben das gerne als
1
Digit=Character-0x30;
wenn ein simples
1
Digit=Character-'0';
es auch getan hätte, dazu identisch ist (unter der Voraussetzung dass
wir nur über ASCII reden), auch bei anderen Zeichensätzen (EBCDIC)
funktioniert hätte, und einfacher lesbarer wäre.
Zusammenfassend kann man sagen, dass es oft einfach nur 2 Erklärungen
für solchen Stil gibt:
* Der Autor weiß es nicht besser. In dem Fall sollte er sich ein
Einführungsbuch mal zu Gemüte führen
* Der Autor will sein Ego gestreichelt sehen. Hex-Zahlen sind nun mal
cooler als so ein schnöder Character.
* Der Autor denkt, er kann dadurch den Code etwas 'verschleiern', weil
er wieder mal Angst davor hat, dass seine Ergüsse geklaut werden.
(Und cross-compilation können wir wahrscheinlich mal aussen vor lassen.
Da tut sich neben dem Schauplatz Zeichensatz noch ein ganz anderer Sack
von Problemen auf, gegen die die unterschiedlichen Zeichencodierungen
reiner Pipifax sind)
Peter Stegemann wrote:
> Ich benutze zwar auch immer die zweite Variante, sehe aber keinen Grund,> sich an der ersten hochzuziehen?
Wozu soll es gut sein, etwas mittels Hex-Zahlen zu verschleiern?
Meistens ist die Verwendung an dieser Stelle ein Indiz dafür, dass der
Autor noch nicht begriffen hat, dass in C ein char auch nur ein kleiner
Integer ist, für den eine andere Schreibweise möglich ist und der bei
Ein/Ausgabe anders behandelt wird. Aber abgesehen davon ist ein char in
C ein stink normaler Integer, mit dem selbstverständlich auch gerechnet
werden kann.
Gründe warum ich die '0' Schreibweise vorziehe
* Ich brauch beim Schreiben nicht in der ASCII Tabelle nachsehen,
welches der Code für '0' ist
* (OK, der zieht heutzutage nicht mehr wirklich) Das ganze funktioniert
auch auf EBCDIC, ohne dass ich was dazutun muss
* Um zu verstehen, was da passiert, brauch ich keine ASCII Tabelle um
nachzusehen, welches denn das Zeichen für 0x30 ist. In diesem Sinne ist
letzteres in einem gewissen Sinne selbstdokumentierend.
Ich hatte mal Code übernommen, der u.A. eine Sonderbehandlung für die
verschiedenen Klammertypen (rund, eckig, spitz) bei einer Ausgabe an ein
weiterverarbeitendes Programm enthielt (mussten durch _ ersetzt werden).
Der Autor hat dort ebenfalls die Hex-Codes benutzt. Irgendwo war da ein
Wurm drinnen. Wir haben dann den Code durchforstet, bis ich dann
irgendwann die Codes durch Character ersetzt habe. Und da sah man dann
sehr schön, dass er sich einfach beim Ablesen der Codes aus der ASCII
Tabelle verhaut hatte. Hätte er gleich normale char benutzt, wäre ihm
das nicht passiert, bzw. er hätte uns Ärger mit dem Kunden und Zeit in
der Fehlersuche erspart.
Es gibt ganz einfach keinen wirklichen Grund dafür, anstelle von
1
if(charac=='['||charac==']'||
2
charac=='{'||charac=='}'||
3
charac=='<'||charac=='>')
4
charac='_';
das hier
1
if(charac==0x5B||charac==0x5D||
2
charac==0x7B||charac==0x7D||
3
charac==0x3B||charac==0x3D)
4
charac=0x5F;
zu schreiben (oder hast du bemerkt, dass der Code für < nicht 0x3B ist?)
Typischer Fall von: selbst ins Bein geschossen.
Thread beobachten
Seitenaufteilung abschalten