entwickler schrieb:> Guten Morgen,> in meiner C Applikation benötige ich die Funktion strstr um ein Wort> herauszufinden ob es in dem string vorkommt oder nicht.> static char* ptr;> ptr = strstr(rxBuffer, "OK");>> if(strcmp(ptr,"OK\r\n"))> {> // tue irgendwas> }>> Im string kommt das Wort OK vor aber strcmp funktioniert nicht.> Der Pointer ptr enthält die Zeichenkette "OK\r\n".
Ich glaube strcmp liefert 0 wenn die Zeichenketten gleich sind.
LG, Sebastian
Zwei weitere Probleme:
1. strstr liefert NULL wenn der Suchstring nicht gefunden wird. Zugriff
auf *NULL ist böse.
2. Du solltest strncmp benutzen, sonst findest du nur Wörter am Ende.
LG, Sebastian
entwickler schrieb:> in meiner C Applikation benötige ich die Funktion strstr um ein Wort> herauszufinden ob es in dem string vorkommt oder nicht.
Also offenbar irgend eine Kommandozeilen-Auswertung o.ä.
Und was machst du, wenn da zufällig mal sowas wie "look" dasteht? Ist
dieses dir dann auch recht?
Was ich damit anzudeuten versuche, ist daß eine Zeilenauswertung mit den
üblichen Verdächtigen aus dem C Repertoire eine ziemliche
Umständlichkeit ist oder gar falsche Ergebnisse liefern kann. Mache das,
was du grad im Sinne hast, lieber anders.
W.S.
entwickler schrieb:> Im string kommt das Wort OK vor aber strcmp funktioniert nicht.> Der Pointer ptr enthält die Zeichenkette "OK\r\n".
Wenn es nach dem "OK" weiter geht, dann ist der String länger als "OK"
und das Ergebnis demit ungleich.
Mit folgender Funktion kann man Worte von einander isolieren:
/* returns a pointervalue to the start of the wanted keyword */
45
}
46
return(po);
47
}
unsigned char n ........ n-tes Wort wird isoliert
const char *SrcStr ..... Zeiger auf Quellstring
const char *delimiters.. Zeichenkette mit Trennzeichen z.B. " ;."
char *DstStr............ Übergabe des Puffers für den Zielstrings (muss
länger als dr Quellstring sein)
Gerald K. schrieb:> Wenn es nach dem "OK" weiter geht, dann ist der String länger als "OK"> und das Ergebnis demit ungleich.entwickler schrieb:> um ein Wort> herauszufinden ob es in dem string vorkommt oder nicht.
Egal ob was kommt oder nicht...er sucht nur "ob es vorkommt".
magic word: KISS
Gerald K. schrieb:> **strcmp** bewertet immer Inhalt und Länge des Strings>> "OK" ungleich "OK "
JA...aber der TO sucht nur das Vorkommen, nicht die Gleichheit.
pseudo-code:
[if (vorhanden)] != [str1 == str2]
Gerald K. schrieb:> Mit folgender Funktion kann man Worte von einander isolieren:> char *extract_word(unsigned char n, const char *SrcStr, const char> *delimiters, char *DstStr)...
OMG, 5 Argumente für sowas.
Besser geht's etwa so:
1
if(match("OTTOKAR",&Cpt))DoOttokar();
2
if(match("EMIL",&Cpt))
3
{ifmatch("IST",&Cpt))
4
{ifmatch("DOOF",&Cpt))DoEmilIstDoof();}
5
}
Sowas liest vom Zeilenanfang bzw. vom Stand des Zeigers 'Cpt' an,
vergleicht nach Übergehen von white space Zeichen die Zeichen (Case
unsensitive für eingegebene Zeichen) und stoppt dann bei match mit true
oder bei unmatch mit false. Der Zeiger 'Cpt' wird bei match auf das
Zeichen nach dem erkannten String gesetzt.
W.S.
W.S. schrieb:> Besser geht's etwa so:
Mal abgesehen von der absolut unüblichen Positionierung der geschweiften
Klammern kannst Du es eleganter so machen:
Nop schrieb:> Mal abgesehen von der absolut unüblichen Positionierung der geschweiften> Klammern kannst Du es eleganter so machen:
Nö, erstens wird dieses Beispiel dadurch nicht eleganter und zweitens
(bedeutender!) ist das Ergebnis davon abhängig, wie der jeweilige
Compiler arbeitet. Grund: du weißt es nicht wirklich, in welcher
Reihenfolge der Compiler für deinen Ausdruck die Aufrufe der Funktion
match erstellt. Dem geht man komplett aus dem Weg, wenn jede Stufe
separat ist.
Und was für dich eine absolut unübliche Positionierung sein mag, ist
dein Problem, wenn es denn überhaupt ein Problem sein sollte.
W.S.
W.S. schrieb:> Grund: du weißt es nicht wirklich, in welcher> Reihenfolge der Compiler für deinen Ausdruck die Aufrufe der Funktion> match erstellt.
DU weißt es nicht, ich schon. Weil ich C kann.
W.S. schrieb:> Grund: du weißt es nicht wirklich, in welcher> Reihenfolge der Compiler für deinen Ausdruck die Aufrufe der Funktion> match erstellt.
Falsch.
Die Reihenfolge ist in C garantiert. Es geht bei der Verknüpfung immer
von links nach rechts, solange die logischen Operatoren identisch sind.
Wenn nicht mehr identisch, wird nach der definierten Priorität der
C-Operatoren vorgegangen (z.B. AND vor OR).
Sobald ein Ausdruck einer Und-Kette
1
if(A&&B&&C&&D)
falsch ist, wird die weitere Evaluation eventuell folgender logischer
Ausdrücke (und damit auch der Funktionsaufrufe!) abgebrochen - also
genau wie bei Deinen ineinander verschachtelten if-Blöcken.
Bei Veroderung
Frank M. schrieb:> Auch in Free-Pascal und Modula-2 (als Nachfolger von Pascal) sind die> logischen Operatoren AND und OR Kurzschlussoperatoren.
Das war sogar im ursprünglichen Pascal so, sollten also alle
Pascal-Dialekte ebenso machen.
Gerald K. schrieb:> Mit folgender Funktion kann man Worte von einander isolieren:> char *extract_word(unsigned char n, const char *SrcStr, const char> *delimiters, char *DstStr)
Warum nicht einfach strtok() (oder strtok_r(), falls notwendig)
benutzen?
Dafür ist es da.
W.S. schrieb:> und zweitens> (bedeutender!) ist das Ergebnis davon abhängig, wie der jeweilige> Compiler arbeitet. Grund: du weißt es nicht wirklich, in welcher> Reihenfolge der Compiler für deinen Ausdruck die Aufrufe der Funktion> match erstellt. Dem geht man komplett aus dem Weg, wenn jede Stufe> separat ist.
Es ist echt immerwieder der Hammer wie du allen zeigen musst, dass du
absolut KEINE AHNUNG von C hast!
Aber immer so tun als wärst du der größte Programmierer aller Zeiten auf
der Welt und alle müssen deine Vorschläge nutzen, denn andere Argumente
zählen ja nicht.
Du bist wirklich einfach nurnoch ne peinliche Vollpanne...
Wie Frank schon geschrieben hat ist die Reihenfolge der Evaluation
garantiert.
So lässt sich ein einer und Verkettung sogar erst ein Pointer auf
ungleich NULL prüfen und dann dereferenzieren.
Ist der Pointer NULL so kommt er nicht mehr bei der Deref. vorbei und es
stürzt auch nix ab.
Ein sehr gutes Feature!
Weiterhin kannst du doch auch soooo gut ASM.
Dann schreibs mal ordentliuch hin (also wie vorgeschlagen) und guck dir
mal an was der Compiler draus macht.
Frank M. schrieb:> Falsch.
Meinst du. Wenn ich mich recht entsinne, dann hatte z.B. der
Sozobon-Compiler die dekodierten Ausdrücke zunächst in einen Stack
gedrückt, so daß so ein Ausdruck wie oben quasi von rechts nach links in
der Zielhardware abgearbeitet wurde. Also davon, daß es bei dem gerade
dir vorliegenden Compiler anders herum ist, darfst du nicht schließen,
daß es immer und überall genau so gehandhabt wird.
Also schreibe nicht so ein vorwitziges "Falsch" hin, wenn du etwas
siehst, was du nicht gewöhnt bist.
Abgesehen davon ist das mal wieder ein Herumhacken auf dem
nebensächlichsten Detail der bisherigen Diskussion. Zumindest DU
solltest das begreifen. Den übrigen Disputenten nehme ich das nicht
übel.
Sinn des Ganzen ist eine geordnete Verarbeitung von Kommandozeilen, wo
z.B. auch stehen könnte:
1
if(match("Ottokar",&Cpt))
2
{x=GetLong(&Cpt);
3
b=match("ein",&Cpt);
4
DoOttokar(x,b);
5
return;
6
}
Und auch dieses Beispiel ist nur ein Beispiel zur Demonstration des
Prinzips. Und nun sind all die anderen Leute mal aufgerufen, etwas
besseres unter den üblichen Stringfunktionen bei C zu posten, falls so
etwas zu finden ist.
W.S.
Da ist sie wieder die Hybris des W.S.
"Alle doof nur ich nicht".
Du kannst kein C, ziehst dir nen alten Gammelcompiler ausm Hintern, der
sich nicht an den C Standard hält und erklärst das für das golden
Sample.
Geh einfach weg, du nervst nurnoch.
W.S. schrieb:> Und nun sind all die anderen Leute mal aufgerufen, etwas> besseres unter den üblichen Stringfunktionen bei C zu posten, falls so> etwas zu finden ist.
Wurde schon längst, aber du HASST ja die c std lib, daher bist du blind.
Mw E. schrieb:> So lässt sich ein einer und Verkettung sogar erst ein Pointer auf> ungleich NULL
Das ist doch Käse, man könnte selbst in dem Konstrukt von W.S. zuerst
prüfen ob der Pointer ungleich NULL ist. Aber darum ging es doch gar
nicht. Es ging darum abzuprüfen ob ein bestimmter String in einem
anderen String enthalten ist. Ob man das nun per if oder &&-Verkettung
macht ist am Ende erst mal für die Funktion unerheblich.
Wie man seinen Code formatiert ist doch auch jedem selbst überlassen. Am
Ende muß man seinen Code für's erste selbst gut lesen können und wenn
man seine Formatierung konsequent durchzieht, dann ist es i.d.R. auch
für andere kein Problem den Code zu lesen.
Der eine mag eben lieber Vanilleeis, der andere bevorzugt halt Schoko.
Du mußt doch nur Deinen Senf dazu geben, weil der W.S. halt etwas anders
oder von mir aus auch etwas speziell ist und Dir das nicht passt.
Zeno, der W.S. Versteher ist wieder da ;)
Im Kern gehts um die Aussage, dass der Compiler das in irgendeiner
Reihenfolge durchgeht.
Das stimmt eben nicht.
Dies hat Frank aber auch schon ausführlichst erklärt.
Mal abgesehen reichts hier vielen im Forum, was W.S. hvor sich hin
schwurbelt.
Du solltest doch so langsam mitbekommen haben, dass auch andere
angemeldete User hier immer "freundlicher" zu ihm werden ;)
Was eben an seiner Beratungsresistenz liegt.
Es wird im was erklärt wenn er wieder was falsches vor sich hinblubbert,
zB zum Thema nop wegoptimieren und DMA.
Nach ein paar Wochen kommt er dann wieder mit genau dem selben Stuss um
die Ecke.
W.S. schrieb:> Meinst du.
Nein, meint der C-Standard. Und das war schon immer so, seit Anfang an.
Short Circuit Evaluation ist absolut sinnvoll. Wenn Du nun meinst, es
gäbe da einein ollen Compiler, der es nicht so täte, dann
- hält er sich entweder nicht an die Regeln und ist damit kein
C-Compiler
oder
- trügt Dich Dein Gedächtnis gewaltig.
Ich tippe auf letzteres.
Sorry, Du hast einfach keine Ahnung von C. Ich habe Dir Links
aufgezählt, welche klar und deutlich belegen, dass nicht nur in C,
sondern auch in vielen anderen Sprachen Short Circuit Evaluation gang
und gäbe und sogar Vorschrift ist. Du als alter Pascal-Hase solltest sie
eigentlich kennen.
W.S. schrieb:> Abgesehen davon ist das mal wieder ein Herumhacken auf dem> nebensächlichsten Detail der bisherigen Diskussion.
Sorry, Du hast mit dem Gehacke auf verkettete AND-Operationen selber
angefangen. Versuche einfach nicht immer, anderen großspurig die Welt zu
erklären. Zu oft tritt man dabei in einen Fettnapf.
Frank M. schrieb:> W.S. schrieb:>> Meinst du.>> Nein, meint der C-Standard. Und das war schon immer so, seit Anfang an.> Short Circuit Evaluation ist absolut sinnvoll. Wenn Du nun meinst, es> gäbe da einein ollen Compiler, der es nicht so täte, dann...
Ja was dann?
Also die verkürzte Ausdrucksberechnung, die dann abbricht, wenn das
Ergebnis gefunden wurde und weitere Terme daran nichts mehr ändern
können, ist etwas anderes, als die Frage, in welcher Reihenfolge das auf
der Zielhardware abgearbeitet wird. Begreife das mal.
Wozu sollte es also gut sein, so etwas herauszufordern?
Ich sehe dazu keinerlei triftigen Grund.
Hier hat nur einer alles auf eine Zeile kriegen wollen, das war der
Anlaß dieser Neben-Diskussion. Und ob ich oder sonstwer das ästhetischer
finden würde, ist hier kein Thema. Also laß lieber deine kühnen
Behauptungen. Es wäre allemal sinnvoller, zum Thema etwas beizutragen.
Hier haben wir einen TO, der mit Hilfe von Standard-String-Funktionen
von C irgend eine Kommandozeile auswerten will und dabei feststellen
muß, daß das mühsam ist, weil all diese o.g. Funktionen ihm dabei nicht
effektiv helfen.
W.S.
W.S. schrieb:> Also die verkürzte Ausdrucksberechnung, die dann abbricht, wenn das> Ergebnis gefunden wurde und weitere Terme daran nichts mehr ändern> können, ist etwas anderes, als die Frage, in welcher Reihenfolge das auf> der Zielhardware abgearbeitet wird. Begreife das mal.
Wieder falsch!
Red dich nicht raus, du kannst es einfach nicht...
Daher zündest du hier wieder Nebelkerzen, so wie immer!
Der C Compiler hat die Instruktionen auf der Zielhardwaree eben so zu
sortieren, dass die Evaluationsreihenfolge eingehalten wird.
Begreife das mal.
W.S. schrieb:> Also die verkürzte Ausdrucksberechnung, die dann abbricht, wenn das> Ergebnis gefunden wurde und weitere Terme daran nichts mehr ändern> können, ist etwas anderes, als die Frage, in welcher Reihenfolge das auf> der Zielhardware abgearbeitet wird. Begreife das mal.
Begreife Du mal, wieso überhaupt gängige C-Idiome wie das hier schon
genannte
1
if(ptr&&ptr->foo==bar)
überhaupt funktionieren können. Eben weil die Auswertungsreihenfolge
festgelegt ist, weswegen man in diesem Beispiel keine Dereferenzierung
eines Nullpointers riskiert.
Deswegen würde ich in meiner Firma in einem Codereview sowas wie Deine
unnötig geschachtelten if nicht durchgehen lassen, weil sie darauf
verweisen, daß dem Programmierer grundlegendes C-Wissen fehlt.
Nop schrieb:> Deswegen würde ich in meiner Firma in einem Codereview sowas wie Deine> unnötig geschachtelten if nicht durchgehen lassen, weil sie darauf> verweisen, daß dem Programmierer grundlegendes C-Wissen fehlt.
Die Frage is auch wie lange jemand eingestellt bleibt, der bei der
Nachfrage dann diese W.S. Antwort bringt und sich dann weigert dies
anzuerkennen.
Diese Antwort lässt so tief ins unwissen blicken was den C Standard
anbelangt und auch wie ein Compiler dies auf der Mikroarchitektur
abbildet.
Bei den ganzen Magic Numbers im Code, die er hier auch imemr wieder
vorschlägt, wär er auch jedesmal durch nen internen Codereview
durchgefallen.
Daher Frage ich mich echt wo der Arbeitet, damit wir nicht ausversehen
mal was von dieser Firma kaufen oder nen Auftrag dahin vergeben.
Er hatte mal was von Berlin erwähnt.
Wer hier labert ist doch wohl klar. Für einen Oberlehrer, der ständig
Code anderer Leute kritisiert, ist das doch wohl hochnotpeinlich.
Und Codereview würde ja Teamarbeit bedeuten, dafür halte ich so einen
selbsternannten Programmiergott nicht fähig.
W.S. schrieb:> ist etwas anderes, als die Frage, in welcher Reihenfolge das auf der> Zielhardware abgearbeitet wird. Begreife das mal.
Die Reihenfolge ist garantiert: von links nach rechts. Sonst wäre - wie
schon öfter erwähnt
1
if(ptr&&ptr->foo)
sinnlos.
Und damit ist für mich EOD - zumindest, was die Sache Short Circuit
Evaluation betrifft.
Übrigens: Leider bist Du die Implementation der Funktion match()
schuldig geblieben. Diese ist nämlich nicht Bestandteil der libc. Warum
also nicht strstr(), siehe https://linux.die.net/man/3/strstr
Frank M. schrieb:> Übrigens: Leider bist Du die Implementation der Funktion match()> schuldig geblieben.
Das ist mir jetzt auch schon oft aufgefallen, dass die beispiele von
W.S. unbrauchbar sind, weil wichtige Teile immer fehlen.
Darauf angesprochen liefert er dies dann nicht nach.
Er redet sich lieber raus, dass dies doch nur Beispiele sein.
D.h. seine Beiträge sind von Anfang an wertlos bzw. unbrauchbar.
Abgesehen von den ganzen enthaltenen Fehlern welche auf mangelnde
Grundkenntnisse in C hindeuten.
Warum meldet sich W.S. nicht mehr?
Hier muss aufgeklärt werden.
Entweder er erklärt sich wieso er dieser Annahme ist oder er muss
hinnehmen, dass er falsch liegt und dies zugeben.
Aber er entzieht sich der Verantwortung.
Das läßt tief in den Charakter blicken!
meow schrieb:> Hier muss aufgeklärt werden.
Da gibts nicht mehr aufzuklären.
Einsicht, ist jedem seine persönliche Sache.
Diese kann man nicht erfolgreich einfordern bzw. durchsetzen.
EAF schrieb:> Da gibts nicht mehr aufzuklären.>> Einsicht, ist jedem seine persönliche Sache.> Diese kann man nicht erfolgreich einfordern bzw. durchsetzen.
Du meinst: Abwarten bis er dieses Beispiel wieder postet?
meow schrieb:> Warum meldet sich W.S. nicht mehr?
Weil dieser Absturz vom eigentlichen Thema der ganzen Diskussion nichts
bringt. Das Beispiel war eigentlich nur zum Verdeutlichen, wie man auf
einfache Weise Kommandozeilen etc. testen kann, ohne daß man so viel
Code rings um sowas wie strstr schreiben muß.
Aber anstatt wenigstens ein wenig am Thema zu bleiben, haben sich die
ewigen Besserwisser an sowas wie "emil...ist...doof" hochgezogen. Nicht
um einen sinnvollen Beitrag zu leisten, sondern um herumzuzanken.
Nebenbei würde ich so eine Zusammenziehung wie die von nop auch
weiterhin nicht schön finden. Und auch nicht praktisch oder gar sinnvoll
finden. Gehört aber nicht zum Thema. Deshalb kein weiterer Kommentar.
Nochwas: Da Frank dediziert nach der Funktion 'match' nachgefragt hat
kommt hier das Reizwort für ihn: schau in die Lernbetty. Es ist nur eine
ganz kleine Funktion. Aber du hast ja schon einmal feierlich erklärt,
dort niemals hineinschauen zu wollen. Aber auch das ist nicht mein
Problem und auch nicht das Problem des TO. Der hat sich mit strstr
herumgeärgert und das zeigt mir, daß es an manchen Stellen weitaus
besser ist, sich seine eigenen und passenderen Funktionen selber zu
schreiben, als mit Gewalt das vorgefertigte Zeug mit viel dazu nötigem
Anpaßcode benutzen zu wollen. So ist das eben. Guckt nicht immer nur in
euer Regelbuch, sondern wenigstens gelegentlich auch mal aus der Furche.
W.S.
Eigentlich wurde ja nur gefragt wieso die Schreibweise so interessant
ist.
Die Antwort darauf war etwas merkwürdig.
Es wäre eben nicht schlecht sowas in der Zukunft zu bedenken, das Forum
ist ein geben und nehmen.
Kein "Beispiele reinwerfen und wieder gehen".
W.S. schrieb:> ewigen Besserwisser
Wieso ewige Besserwisser?
Es wurde doch über ein kleines Verständnisproblem im C Standard
aufgeklärt.
W.S. schrieb:> Gehört aber nicht zum Thema. Deshalb kein weiterer Kommentar.
Das Thema ist schon entgleist, da machen wir einfach weiter.
meow schrieb:>> Einsicht, ist jedem seine persönliche Sache.
Du siehst!
Keinerlei Einsicht.
Es sind die anderen.
Und zwar nur die anderen.
Nicht, dass er eine Nebelkerze abgeschossen hatte...
Nööö.....
Man hat auch nicht versucht ihn zu korrigieren....
Er hat auch sofort in sein C Buch geschaut.
Das (Seiten)Thema hätte in 5 Minuten durch sein können!
Einer behauptet, die Reihenfolge ist definiert.
Einer glaubt, sie wäre nicht definiert.
Also schaut man in die Doku, und stellt fest, sie ist definiert.
Dann ein kleiner Spruch:
"Jau! Ihr im Recht, sie ist definiert!"
Fertig!
Es ist allerdings etwas mentale Stärke erforderlich, einen Irrtum
zuzugeben.
Dabei wird es doch meistens honoriert, eine Schwäche oder Irrtum
zuzugeben.
Es macht menschlich. Im Irrtum zu verharren ist dagegen eher blamabel.
Richtig peinlich ist es natürlich, wenn die Behauptung schwarz auf weiß
widerlegbar ist.
Stellt man sich nicht seinen Irrtümern, gibt es negative Folgen zu
tragen:
1. Man sinkt in der Achtung der anderen
2. Auch falls man mal recht hat, wird das nicht mehr wahrgenommen (wer
drei mal lügt...)
3. Man blockiert sich selber, lernt nicht mehr dazu, denn lernen geht
über die Einsicht
4. Die Leute, denen man die Schuld in die Schuhe schiebt, werden sich
pikiert abwenden.
Thread beobachten
Seitenaufteilung abschalten