Vergleich zweier strings von eingabe

SpeedFly009

Newbie
Registriert
Apr. 2008
Beiträge
1
Hallo ihr da Drausen

Mein Problem ist , Ich mochte ein String einlesen und ein vorher diffnierten String vergleichen so in etwa:

Das ist mein source code :

char feld_string1[100];
const char name_string[] = Tim,tim,TIM ;

/* char *name_string[] = str;
char str[] = &name_string;
*/
einaus()
{
printf("Hallo ; Bitte Name eingaben");
gets(feld_string1);
}


main()
{

einaus();
if(feld_string1 == name_string)
printf("Der String ist gleich");
else printf("Der String ist leider nicht gleich !");



}

Was mache ich Falsch.




Danke im vorhaus ::::::

thx SpeedFly009
 
Hallo,

Strings vergleichen kannst du über die Funktion strcmp. Ansonsten werden nur die Adressen des ersten Elements des Arrays verglichen, die in deinem Fall natürlich immer unterschiedlich sind.

Definiert ist strcmp in string.h. Bei Gleichheit wird 0 zurückgegeben, sonst ein von 0 verschiedener Wert. Für genaue Infos schau einfach mal in die man-page oder in die Hilfe.

Gruß
 
Was claw meint, sind stl-strings. Etwas langsamer, aber sehr flexibel.
Zum verwenden <string> einbinden, dann kannst du "string VarName;" benutzen.
stl-Strings kannst du dann einfach mit == vergleichen.

Zusätzlich gibt es noch ein paar andere tolle Funktionen, zB .find/.append/ etc.
Einfach mal die MSDN dazu befragen.
 
dazu müsste man vielleicht noch sagen, dass man dazu die codezeile

Code:
using std::string;

verwenden sollte. sonst musst du jeden string über std::string erstellen (std ist der "standard" namespace).
 
Wenn man auf Standardstrings verzichtet wäre es evtl. sinnvoll auf die strcmp() Funktion zu verzichten und strncmp() zu verwenden. Mit den zusätzlichen Argument gibt man an, wie viele Zeichen maximal in dem Vergleich berücksichtigt werden. Das ist sinnvoll, wenn man nicht weiß, ob die Strings mit '\0' abgeschlossen sind.
Siehe: http://www.hmug.org/man/3/strncmp.php
 
Spartaner117 schrieb:
Was claw meint, sind stl-strings. Etwas langsamer, aber sehr flexibel.
Das halte ich für eine sehr gewagte These. :) Belege?

Habe mich mal mit STL zurückgehalten (und meiner sonstigen Pedantik *g*), da das doch ziemlich nach Plain C aussieht.
 
Ich kann nur von meiner Erfahrung mit "string"-Strings berichten, wobei die stl-Variante immer leicht langsamer als char-Arrays waren (Eigendlich ja auch naheliegend, da bei stl-Strings immer eine ganze Klasse mitgeschleppt wird). Ob die Verwendung von == schneller ist als strcmp(), kann ich nicht sagen.

Oder bist du der Meinung dass sie nicht flexibler sind?
Oder meint claw keine stl-Strings?
 
was ist stl - standard library? also im namespace std? wenn ja, dann meine ich die.

== bei strings wird wohl nicht schneller sein, intern wird wohl zu 99% genau so mit strcmp verglichen. strings sind eigentlich nur flexibler, der geringe geschwindigkeitsnachteil wird dank oop in den schatten gestellt. ;)

man kann es eigentlich ganz leicht ausrechnen welche variante schneller ist. man durchläuft einfach 1.000.000.000 vergleiche von strcmp bei char arrays und == bei strings. es wird, denke ich, < 0,1 ms sein. trotz allem hat man mit klassen mehr vorteile und vertut sich nicht mal eben mit der \0 zum schluss wie bei ansi c.
 
Zuletzt bearbeitet:
Spartaner117 schrieb:
Ich kann nur von meiner Erfahrung mit "string"-Strings berichten, wobei die stl-Variante immer leicht langsamer als char-Arrays waren (Eigendlich ja auch naheliegend, da bei stl-Strings immer eine ganze Klasse mitgeschleppt wird). Ob die Verwendung von == schneller ist als strcmp(), kann ich nicht sagen.

Das es langsamer sein soll, weil ein Objekt mitgeschleppt wird, glaube ich mal nicht. Zumal durch die Klasse eine Kopplung zwischen Daten und Methoden vorhanden ist, was eine wesentlich bessere Locality of Reference ergibt und somit vom Compiler besser optimierbar. Außerdem sind die STL-Allokatoren sehr intelligent je nach Implementation und wesentlich effektiver als ein eigenes malloc. Wenn ein std::string mit der Standard-3-Pointer-Logik (start, end, end of storage) implementiert ist, hat das ermitteln der Länge konstante Laufzeit im Gegensatz zu linearer. Das wiederum schlägt beim Vergleichen dramatisch zu, da hier sofort erstmal ein Längenvergleich gemacht werden kann, was bei char-arrays erstmal ein durchlaufen des Arrays erfordern würde (was dann aber natürlich keinen Sinn mehr macht).

Kann man natürlich mit Plain C genauso nachprogrammieren, aber ich sehe keinen Grund, warum char-arrays schneller sein sollten. Und selbst dann interessiert mich der Code, wo dieser Unterschied signifikant ist.

@claW3581: Kann man machen, die Aussage muss aber keine Bedeutung haben, da das kein produktiver Code ist. Wenn nebenbei noch andere Sachen passieren, die Daten erstmal in den Cache geschaufelt werden müssen (oder bei guter Optimierung schon vorsorglich geholt wurden), etc., sieht das ganz schnell anders aus.
 
Zuletzt bearbeitet:
7H3 N4C3R schrieb:
@claW3581: Kann man machen, die Aussage muss aber keine Bedeutung haben, da das kein produktiver Code ist. Wenn nebenbei noch andere Sachen passieren, die Daten erstmal in den Cache geschaufelt werden müssen (oder bei guter Optimierung schon vorsorglich geholt wurden), etc., sieht das ganz schnell anders aus.

hat es wie ich denke schon. wenn du mal verschiedenste schleifen durchläufst (habe ich in php z.b. mal gemacht, gibt auch genug im internet zu sehen), dann siehst du (relativ natürlich) gewaltige unterschiede.

der aufbau dabei ist ziemlich einfach:

Code:
i = wie auch immer
schleife( bedingung )
 i++

wenn du dies nun 10000.... mal ausführst, kannst du dir sicher sein, dass das von dir genannte nicht zutrifft. und selbst wenn tritt es nur beim 1. mal auf. die strings müssen ja nun nicht 100 zeichen enthalten, ein einfacher von 3 bis 4 zeichen an länge würde schon ausreichen (dieser wird bestimmt nicht mal so eben aus dem cache der cpu gelegt).

wie will man es sont machen, wenn das von dir genannte zutrifft? man könnte natürlich schnell mal ein freedos booten und dort einen kleinen benchmark machen, da wird wohl nicht allzuviel passieren. aber ich denke die unterschiede zu dem (bei 1.000.000.000 durchläufen) sind wirklich sehr gering und wenn relativiert sich dies wieder, da ja bei beiden tests nebensächlich andere sachen geschehen.
 
Also ganz einfach, so ein Benchmark ist synthetisch und gibt nur bedingte Aussagen über das Verhalten in einer realen Situation, in der jede Menge Nebeneffekte auftreten. Es wird solche und solche Situationen geben, wo jenachdem eine Implementierung sich besser verhalten wird. Die synthetische Variante dagegen wird in realem Produktivcode eher selten auftreten und ist daher für den realen Einsatz höchstens eine grobe Abschätzung.

Wenn man in einer ganz konkreten Situation den Verdacht hat, dass man ein Performanceproblem hat und es genau an den Strings liegt, wirft man einen Profiler an und schaut, was exakt wo verbraten wird und wie man optimieren kann.
 
Zurück
Oben