www.mikrocontroller.net

Forum: Compiler & IDEs char array mit Hex-Werten


Autor: Frank Maier (fuzzy-vibes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich schätze mal der erste Ansatz mit den Hex-Werten muss irgendeinen
>Vorteil haben, ...

Nein. Muß er nicht...
static const unsigned char string[] =  "guard time";

solltest du aber schon schreiben, sonst ist es nicht das gleiche.

Oliver

Autor: Frank Maier (fuzzy-vibes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gut, mal abgesehen von dem, was davor steht :)

wozu der umstand mit den hex werten?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manche Wege sind übersichtlich und manchen sieht man nicht direkt an wo 
sie hinführen. Aber alle Wege führen nach Rom.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>wozu der umstand mit den hex werten?

Frag den, der das so gemacht hat.

Oliver

Autor: Frank Maier (fuzzy-vibes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?
....

Autor: Ahem (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank Maier (fuzzy-vibes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast wrote:
> Das Compilieren mit den Hex Werten geht schneller als mit dem ASCII
> Textstring.

Auch wenn's nur win Witz war, es ist genau andersrum...

Autor: Ahem (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Ahem (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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?

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch besser wäre freilich ein
static const unsigned char string[] =  "guard time\0";

:-)

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mark Brandis wrote:
> Noch besser wäre freilich ein
>
>
static const unsigned char string[] =  "guard time\0";

Wieso? Der original "Hex-String" hat auch keine zwei Nullen am Ende.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Ernst wrote:
> Mark Brandis wrote:
>> Noch besser wäre freilich ein
>>
>>
static const unsigned char string[] =  "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?

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ne, das macht der automatisch, wenn man Stringliterale benutzt. Hat nix 
mit dem Vektor zu tun.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mark Brandis
Bei Strings macht es der Compieler immer.

Sonst würde ja printf("test") nie gehen.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aha... und in welchen Fällen genau muss ich mich dann selbst um die 
Nullterminierung kümmern?

Autor: meha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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... ;-)

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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)

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ahem (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Ahem (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ahem (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Sven P.

Nur immer weiter so. Man braucht Dich garnicht zu disqualifizieren. Das 
besorgst Du schon selbst ganz ausgezeichnet.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ahem (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Sven P.

Ja, ja.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank Maier: Hast Post von mir, auf das Gebrabbel von Ahem lass ich mich 
hier nicht länger ein.

Autor: Ahem (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es hier eigentlich keinen Mod? :-(

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und, was soll der tun? Die Kontrahenden am Händchen nehmen und "dududu" 
sagen?

Autor: JayJay (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ^^

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus t. Firefly wrote:
> Und, was soll der tun?

Moderieren natürlich.

Autor: Frank Maier (fuzzy-vibes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
     Digit = Character - 0x30;

wenn ein simples
    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)

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger wrote:

> Besonders 'schlaue' Programmierer schreiben das gerne als
>
>      Digit = Character - 0x30;
> 
>
> wenn ein simples
>
>
>     Digit = Character - '0';
> 

Ich benutze zwar auch immer die zweite Variante, sehe aber keinen Grund, 
sich an der ersten hochzuziehen?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
    if( charac == '[' || charac == ']' ||
        charac == '{' || charac == '}' ||
        charac == '<' || charac == '>' )
      charac = '_';

das hier
    if( charac == 0x5B || charac == 0x5D ||
        charac == 0x7B || charac == 0x7D ||
        charac == 0x3B || charac == 0x3D )
      charac = 0x5F;

zu schreiben (oder hast du bemerkt, dass der Code für < nicht 0x3B ist?)
Typischer Fall von: selbst ins Bein geschossen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.