String concat in c++

[Der Martin]

n'Abend!

Ja und? Deswegen sagte ich doch, ich betreibe keine Arithmetik damit, sondern verwende char (meistens) nur als Zeichen. Da ist es mir doch wurscht, ob signed oder unsigned.
Und warum dann nicht einheitlich char bzw. falls das Vorzeichen relevant ist halt (un)signed char?

weil die Argumente von Funktionen, die ich nutzen möchte, teils sehr unterschiedlich deklariert sind, je nachdem, woher sie stammen. Mal als char, mal als uchar, mal als BYTE, mal als INT8, und letztendlich meinen sie alle dasselbe: Eine Einheit von 8 Bits, die ein Zeichen repräsentieren.

Völlig schnurz. Wenn die CPU irgendwann über den Code herfällt, ist -1 genau dasselbe wie 0xFFFFFFFF, nur handlicher geschrieben.
Darauf kannst du dich allerdings im Allgemeinen nicht verlassen. Dein Code ist hochgradig plattform-spezifisch.

Ja und? Wenn ich eine bestimmte Software schreibe, dann schreibe ich auch für eine bestimmte Plattform bzw. Systemumgebung. Also gehe ich auch auf die Gegebenheiten eben dieser Systemumgebung ein. Wenn eine andere Rechnerarchitektur bzw. ein anderes Betriebssystem ausnahmsweise negative Zahlen *nicht* durchs Zweierkomplement darstellt, muss ich das eben anders schreiben.

Und wer garantiert dir, dass dein Programm nicht später auf einem Rechner mit einem Betriebssystem läuft, auf dem -1 ungleich 0xFFFFFFFF ist?

Zunächst garantiere *ich* das, indem ich sage: Dieser Programmcode ist für Win32 geschrieben. Oder für DOS. Oder für 8051 µCs.

Das kann man machen, du weißt aber schon, dass es auf 32-Bit-Computern deutlich schneller ist, auf je 4-Byte zuzugreifen als auf eines.

Das ist nicht richtig. Zumindest bei x86-CPUs braucht ein BYTE-Zugriff exakt genausoviele Taktzyklen wie ein DWORD-Zugriff. Im Gegenteil: Ein DWORD-Zugriff kann sogar länger dauern, dann nämlich, wenn die Adresse nicht durch 4 teilbar ist. Es gibt also keine Rechtfertigung, byteweise strukturierte Daten auf DWORD aufzublähen und dadurch das Vierfache an Speicher zu verschwenden wie eigentlich nötig.

Schreibst du Programme, die viel Arbeitsspeicher allokieren?

Ja, gelegentlich. Aktuell bin ich dabei, eine vor 2 Jahren begonnene Win32-Applikation auszubauen, die je nach Konfiguration leicht und locker mal 50..100MB RAM belegt. Da ist Speicherökonomie durchaus ein Thema.

Ansonsten denke ich, dass eine Geschwindigkeitsoptimierung sinnvoller ist.

ACK. Aber das, was du vorschlägst, ist keine Geschwindigkeitsoptimierung.

Den Programmcode für den Rest schleppt meine Applikation nachher als Ballast mit.
Abgesehen von C++, macht sich das während der Laufzeit gravierend bemerkbar?

Nein, sicher nicht. Aber ich finde es nicht erstrebenswert, den Ressourcenhunger eines Programms (Plattenplatz und Arbeitsspeicher) unnötig in die Höhe zu treiben.

Ich weiß, wenn jeder Programmierer denkt „heutige Rechner sind schnell genug“, hat der Anwender im Endeffekt wieder nichts davon, aber die Verhältnisse müssen meiner Meinung nach stimmen.

Was für Verhältnisse? Das Problem, das du ansprichst, ist mir durchaus geläufig. Ich habe es bisher immer "elektronische Inflation" genannt: Die Programmierer gehen verschwenderisch mit den Ressourcen um, weil sie ja zur Verfügung stehen, und die Rechnerhersteller sehen den Bedarf für immer mehr Speicher und Rechenleistung, weil aktuelle Applikationen aufgrund der Faulheit der Programmierer die Maschinen bis an die Grenze belasten. Ich würde es begrüßen, wenn sich wieder mehr Programmierer dieses Dilemmas bewusst würden.

Im Übrigen finde ich dein Ballast-Argument nachvollziehbar in der Art, dass mir kleine, schlanke Bibliotheken deutlich lieber sind als „Wir haben die Lösung für alles“.

Naja, wenigstens da sind wir uns einig. ;-)

[...] und dass man günstiger wegkommt, wenn man das Programm (oder zumindest Teile davon) von Grund auf neu aufsetzt.
Dieses Problem ist aus meiner Sicht nicht C++-spezifisch. Ich kenne C-Programme sowie Bibliotheken oder Teile davon, von denen man glaubt, dass man ihre Funktionalität benutzen könnte und nach langem hin und her feststellt, hätte man gleich das Rad neu erfunden, wäre man jetzt schon weiter.

Naja, mir sind solche Sachen bei C++ am häufigsten aufgefallen. Deshalb nehme ich, wenn ich Libs für bestimmte Zwecke suche, auch bevorzugt Plain C.

Da hast du vollkommen Recht. Aber sobald ich anfange, bestimmte Informationen an das letzlich verwendete „Subsystem“ bei jedem Funktionsaufruf mitschleppen zu müssen (File- oder Socket-Handles, Datenbank-Kennungen, …), wird für mich die ganze Sache lästig, weil dieser prozedurale Code objekt-orientiert ist, aber die Objekte und Methoden kompliziert umschrieben werden. Das kann man einfacher und eleganter mit echter OOP lösen.

Für meinen Geschmack ist es eben *nicht* einfacher und eleganter, weil wichtige Mechanismen automatisiert und dadurch verschleiert werden. Ich will aber sehen, was da abläuft!

Vielleicht nicht hauptsächlich. Aber wenn sie es noch begünstigt, oder sogar in Musterlösungen propagiert, finde ich das nicht wirklich okay.
Schau dir mal PHP an, das ist in meinen Augen an Verleitung zur Schlampigkeit nicht zu überbieten.

Kann ich nicht abstreiten. ;-)

Gute Nacht erstmal,

Martin