hilfe!!! compiler vebuggt?

Athar

Aufgeräumt sieht das so aus:

const char* const cm=char_modus;
verschluesseln=cm[0]=='v' && cm[1]=='e' && cm[2]=='r';
entschluesseln=cm[0]=='e' && cm[1]=='n' && cm[2]=='t';
log=cm[3]=='l' && cm[4]=='o' && cm[5]=='g';
if ((verschluesseln || entschluesseln) && (log || cm[3]=='\0'))break;

Kurzfassen lohnt sich, auch beim Programmieren.
Die Leser werden's dir danken. Du selbst dir auch, wenn du deinen Code später nochmal lesen musst.

brotbernd

Athar schrieb:

Aufgeräumt sieht das so aus:

Das ist für mich genau das gleiche.
Wir sind ja hier in einem C++ Forum und in C++ gibt es viele tolle Sachen, die sowas wirklich aufräumen.

l'abra d'or

sudo rm -rf schrieb:

ja, MEISTENS liegt es am code, dennoch kann es auch am compiler liegen, denn der ist auch nur ein von menschen geschriebenes programm und genau deswegen übernehmen die programmierer des g++ auch keine verantwortung für mögliche fehler im compiler

Ich denke du kannst noch einige Zeit davon ausgehen, dass auftretende Problem nie am Compiler sondern an deinem Code liegen. Riesige Projekte, die deutlich "extremere" features als simples if/else nutzen, haben keinerlei Probleme.

Athar

brotbernd schrieb:

Das ist für mich genau das gleiche.

Naja, beim Original bekomme ich persönlich Kopfschmerzen, bei der aufgeräumten Variante sehe ich auf den ersten Blick, dass hier nach Zeichenfolgen gesucht wird.

Wir sind ja hier in einem C++ Forum und in C++ gibt es viele tolle Sachen, die sowas wirklich aufräumen.

Sowas kann durchaus Sinn machen, wenn man Daten nach Zeichenfolgen absuchen muss. Mit string (falls du das meintest) wäre das um ein Vielfaches langsamer.
Ist hier vermutlich aber nicht der Fall.

otze

sudo rm -rf schrieb:

@nexus

ja, MEISTENS liegt es am code, dennoch kann es auch am compiler liegen, denn der ist auch nur ein von menschen geschriebenes programm und genau deswegen übernehmen die programmierer des g++ auch keine verantwortung für mögliche fehler im compiler

Keine Frage, der GCC hat Bugs. Aber der GCC gehört auch mit zu den bestgetesteten programmen die man so auf dem opensource markt kriegen kann. Immerhin wird der von mehreren Betriebssystemen als Grundlage verwendet.
Die Bugs die der GCC hat sind eignetlich nur Kategorien: 1. floatingpoint Berechnungen beim Optimieren(das fällt auf bei Rechenfehlern nach der 15. Nachkommastelle) 2. nicht unterstützte Sprachfeatures. Und bei 2. sind das so spezielle Sachen, dass die meisten Programmierer damit nie in Berührung kommen.

Also, bevor du das nächste mal glaubst, dass dein Compiler verbuggt ist: check deinen Code 15 mal Zeile für Zeile mit dem Debugger. Der Compiler wurde von Profis geschrieben die ihn brauchten um ihre eigenen Programme zu compilieren. Die werden sicherlich merken, wenn da was einfaches kaputt ist...

brotbernd

Athar schrieb:

wäre das um ein Vielfaches langsamer.

Wieso ist denn

char c[x];
...
c[0] == 'a' && c[1] == 'b' && c[2] == 'c'

um ein Vielfaches schneller als

string c;
...
c == "abc"

Athar

Weil du im ursprünglichen Fall noch ein substr brauchst.

Nexus

Athar schrieb:

Weil du im ursprünglichen Fall noch ein substr brauchst.

Man sollte natürlich nicht unnötig kopieren.

Falls es es sich tatsächlich um ein geschwindigkeitskritisches Programm handelt (was hier sicherlich nicht der Fall ist), dürfte std::string etwas im Nachteil sein. Zum Beispiel wegen der dynamischen Allokation oder teilweise unnötigen Kopien.

Aber zum Glück programmieren wir in C++, wo Sauberkeit und Effizienz nicht zwingend Gegensätze sind.

verschluesseln=cm[0]=='v' && cm[1]=='e' && cm[2]=='r'

wird zu

verschluesseln = std::equal(cm, cm+3, "ver");

Athar

Ahnte ich schon, dass die Standard-Library da was schönes bereithält.
Falls das vergleichbaren Assemblercode produziert, ist es so natürlich besser.

tntnet

Athar schrieb:

Ahnte ich schon, dass die Standard-Library da was schönes bereithält.
Falls das vergleichbaren Assemblercode produziert, ist es so natürlich besser.

programmierst Du in Assembler oder C++? Lesbarkeit von Code ist sehr wichtig. Ich verzichte sogar an der einen oder anderen Stelle auf den einen oder anderen Takt im Prozessor, um den Code lesbar zu machen. In der Regel wird er dadurch deutlich besser und fehlerfreier. Du hast selbst erlebt, wie Dein Spaggetticode zu unlesbaren Code führt, so dass Du selbst triviale Fehler überliest. Das hast Du mit diesem Beitrag doch demonstriert.

Und C++ ist deswegen so gut, da der lesbare Code in der Regel keinen Overhead produziert. (Textzeile aus einer bedeutenden C++-Hymne: "I want abstraction and optimization both"

Das Beispiels ist sehr gut dafür. Das std::equal produziert tatsächlich keinen Overhead. Allerdings sagst Du nicht nur dem Leser des Codes sondern auch der Standardbibliothek und dem Compliler präziser, was Du tun willst. Dadurch kann der Compiler möglicherweise spezializierte Assemblerbefehle verwenden, die er bei Deinem Spaghetticode nicht kann.

Athar

tntnet schrieb:

programmierst Du in Assembler oder C++? Lesbarkeit von Code ist sehr wichtig. Ich verzichte sogar an der einen oder anderen Stelle auf den einen oder anderen Takt im Prozessor, um den Code lesbar zu machen. In der Regel wird er dadurch deutlich besser und fehlerfreier. Du hast selbst erlebt, wie Dein Spaggetticode zu unlesbaren Code führt, so dass Du selbst triviale Fehler überliest. Das hast Du mit diesem Beitrag doch demonstriert.

Ich bin nicht der OP
Dass Lesbarkeit wichtig ist, sagte ich schon selbst. Bis auf performancekritische Codebereiche auch wichtiger als Effizienz.

tntnet schrieb:

Und C++ ist deswegen so gut, da der lesbare Code in der Regel keinen Overhead produziert. (Textzeile aus einer bedeutenden C++-Hymne: "I want abstraction and optimization both"

In der Theorie schon, aber das erfordert, dass die Compiler auch alle Optimierungsmöglichkeiten ausnutzen. Zumindest g++ produziert hier auch bei -O3 nicht immer optimalen Code, gerade wenn's ums Loop-Unrolling geht. In "normalem" Code ist das völlig egal, aber wenn es um Schnelligkeit geht, sollte man selbst überprüfen, ob der Compiler das ideal löst.

int test()
{
  const char cm[4]="ver"; //das reicht schon, um g++ aus dem Konzept zu bringen
  return std::equal(cm, cm+3, "ver"); //kompiliert in eine schön umfangreiche Schleife
  //return cm[0]=='v' && cm[1]=='e' && cm[2]=='r'; //kompiliert zu mov eax,1
}

Naja, egal. Im Grunde wollte ich nur sagen, dass man möglichst lesbaren Code schreiben sollte.