Wenn "!=" die von dir erwähnte Optimierung verwendet wird es wohl für Strings mit unterschiedlicher Länge schneller sein. Ich hoffe mal dass jede Implementierung die was auf sich hält das tut. Wenn diese Optimierung fehlt, keine Spezialisierung von "std::basic_string" für "char" existiert, und der Compiler nicht wie die Hölle optimieren kann, wird wohl strcmp schneller sein, da strcmp eben speziell auf nullterminierte char Strings optimiert ist (oft sogar "handgeschriebener" Assemblercode), und kein generischer Code wie in std::basic_string<T>.

Der Hinweis mit den mehrfachen Operationen bei strcmp ist richtig, auch wenn es nur 2 Vergleiche sind;

ups! ja, natürlich nur zwei Vergleiche

der code von std::string ist nicht notwendigerweise generisch (und generizität bedeutet an sich ja auch keinen Nachteil).

Die Möglichkeit einer Spezialisierung auf char hab ich ja erwähnt.

Davon abgesehen ist generischer Code deswegen und genau dann "schlecht" (bzw. eben "langsamer"), wenn der Compiler nicht so gut optimieren kann wie ein Mensch mit Hand. Solche Fälle sind selten, aber gerade was sehr sehr einfache Probleme angeht wie eben Strings zu vergleichen kann sowas schonmal vorkommen.

p.S.: mit dem "Länge bekannt" habt ihr natürlich Recht, das ist ein Vorteil der natürlich auch in der Vergleichsschleife selbst zu tragen kommt bzw. kommen kann, daran hatte ich nicht gedacht

Sorry, wenn ich mich noch einmische, aber: basic_string übergibt solche Verwaltungsaufgaben wie Vergleiche an seine traits-Klasse. Und die Default-Klasse std::char_traits<char> greift wiederum auf die Funktion memcmp() zurück. (wenn man noch dazunimmt, daß strcmp() letztendlich ebenfalls auf memcmp() zurückgreifen dürfte, bleibt als einziger Vorteil für den String, daß er seine Datenlänge nicht mehr berechnen muß)

Du beschreibst eine mögliche, wenn auch naheliegende Lösung.

Diese Diskussion ist aus mehreren Gründen unsinnig. Zum einen ist das ganze Implementierungsabhängig. Kein Standard schreibt vor, wie man != mit string oder strcmp implementieren muß.

Ausserdem wenn man die Information braucht, kann man einfach die spezifische Implementierung benchmarken. Wobei viele Einflußgrössen einfliessen. Optimierungen können selbst CPU-Spezifisch unterschiedliche Erfolge aufweisen.

Weiterhin sollte man sich überlegen, ob das wirklich relevant ist. Es gibt selten Programme, wo der Performanceengpasss bei strcmp oder string::operator!= liegt. Und wenn das so ist, sollte man sich fragen, ob der Stringvergleich wirklich notwendig ist.

Tntnet

Sorry, wenn ich mich noch einmische, aber: basic_string übergibt solche Verwaltungsaufgaben wie Vergleiche an seine traits-Klasse. Und die Default-Klasse std::char_traits<char> greift wiederum auf die Funktion memcmp() zurück. (wenn man noch dazunimmt, daß strcmp() letztendlich ebenfalls auf memcmp() zurückgreifen dürfte, bleibt als einziger Vorteil für den String, daß er seine Datenlänge nicht mehr berechnen muß)

Würde mich wundern, wenn die Implementierungen von strcmp auf memcmp zurückgreifen würden. Das wäre dann ja die doppelte Arbeit.

(Aber die mem*-Funktionen dürften auf den meisten Systemen extrem schnell implementiert sein)

Würde mich wundern, wenn die Implementierungen von strcmp auf memcmp zurückgreifen würden. Das wäre dann ja die doppelte Arbeit.

Wieso denn das? Aber selbst wenn die beiden Funktionen jeweils eigenständig arbeiten, dürften sie technisch vergleichbar in der Geschwindigkeit sein (wobei - memcmp() hat einen leichten Vorteil, weil es die Datengröße kennt).