String concat in c++

[Der Martin]

moin Robert,

Wie gesagt, die Freiheit weiß ich zu schätzen, und der Risiken bin ich mir größtenteils bewusst, weil ich maschinennah denke und intuitiv den zu meiner C-Anweisung gehörenden Assembler-Code vor Augen habe.
Warum programmierst du dann in C und nicht in Assembler?

*seufz*  das frage ich mich auch immer wieder...

Warning: Mixing Pointers to signed and unsigned char (mir doch egal, ich mach doch keine Arithmetik damit!)

Und was passiert beim Dereferenzieren? Du vergleichst einen signed mit einem unsigned char, also einen Datentyp mit Wertebereich [-128,127] mit einem Datentyp des Wertebereiches [0,255].

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.

DWORD n;
  if (n==-1)
   { ... }
Warning: Constant out of range in comparison  (Scheißcompiler! Du sollst nicht denken, sondern machen!)

Du kannst doch die Warnungen deaktivieren. Diese Meldung ist gut, es gibt Compiler, die behandeln -1 bei einem DWORD als UINT32MAX-1, also eine sehr große Zahl.

Völlig schnurz. Wenn die CPU irgendwann über den Code herfällt, ist -1 genau dasselbe wie 0xFFFFFFFF, nur handlicher geschrieben.

BYTE  *b;
DWORD *d;
  d = b;
Error: Type mismatch  (Herrje! Pointer ist pointer! Was ich damit mache, ist doch mein Problem!)

Wieso willst du so etwas machen, abgesehen davon, dass BYTE und DWORD unterschiedliche Größen haben? In diesem Beispiel zeigt d nach der Zuweisung nicht nur auf b, sondern auch noch auf die 3 Byte dahinter.

Das ist doch gerade das Schöne! Z.B. wenn ich -je nach Programmkontext- in bestimmten Speicherbereichen mal byteweise, mal doppelwortweise organisierte Daten habe.

OK, ich würde Assembler als die Mutter aller Sprachen bezeichnen, weil jeder Compile-Vorgang, jede virtuelle Maschine später bei einer Assembler-Art landet, und natürlich habe ich deshalb alles unter Kontrolle, aber wofür? In den meisten Fällen kann man meiner Meinung nach auf die Hersteller von Betriebssystemen, Bibliotheken und Programmiersprachen vertrauen, dass sie keinen groben Schrott anbieten.

Nein, das nicht. Aber gerade die "Hersteller" von vorgefertigten Standardbibliotheken packen meist jede Menge tolle Flexibilität in ihre Funktionen, von der ich in einer bestimmten Anwendung vielleicht, wenn's viel ist, 10% ausnutze. Den Programmcode für den Rest schleppt meine Applikation nachher als Ballast mit.

Mit diesem Argument würde ich übrigens nie Windows benutzen, weil es viel zu viele Seiteneffekte hat, die man nicht in die Hand nehmen kann. Gentoo dürfte das richtige Linux für dich sein.

Zu dieser Erkenntnis bin ich auch schon gekommen, und das werde ich demnächst -vielleicht im Weihnachtsurlaub, wenn ich mal wieder ein paar Tage Zeit habe- einmal angehen. ;-)

Soweit ich weiß, wurde OOP auch nicht erfunden, um mit weniger Maschinencode performantere (und buntere) Programme erstellen zu können, sondern aus praktischen Überlegungen wie Wiederverwendbarkeit, Modularisierung, Wartbarkeit, Portabilität.

Hm, ja - Punkt für dich. Aber dann nehme ich die Modularisierung und Dokumentation zugunsten höherer Effizienz doch lieber selbst in die Hand.

Dazu kommt, dass meiner Ansicht nach gerade durch die Kapselung bei der OOP der Überblick über die Zusammenhänge verlorengeht - ist jedenfalls mein persönlicher Eindruck.
Das soll er ja auch in gewisser Weise.

Ja, und das ist das Problem, wenn man mal fremde C++-Programme bekommt und erweitern oder anpassen möchte. Dann verbringt man Stunden und Tage damit, die Zusammenhänge zwischen den zahlreichen Klassen zu analysieren, um dann irgendwann festzustellen, dass die Struktur schon zu verfilzt ist, um die gewünschte Änderung mit vertretbarem Aufwand noch realisieren zu können, und dass man günstiger wegkommt, wenn man das Programm (oder zumindest Teile davon) von Grund auf neu aufsetzt.

Schau dir z.B. mal das Stream-Konzept von C++ an: Unabhängig davon, mit was für einem Ausgabe-„Gerät“ [...] später auf ein anderes „Gerät“ umsteige, brauche ich nur wenige Code-Zeilen zu ändern.

Das kann ich bei klassischer prozeduraler Programmierung aber auch, wenn ich die Aufrufschnittstellen meiner Funktionen sinnvoll festgelegt habe.

Aber wie auch sonst kannst du nicht das schlampige Kodieren hauptsächlich der Programmiersprache anlasten.

Vielleicht nicht hauptsächlich. Aber wenn sie es noch begünstigt, oder sogar in Musterlösungen propagiert, finde ich das nicht wirklich okay.

Mit Assembler kann man wahrscheinlich eher nen Obfuscated-…-Contest gewinnen als mit C.

Zweifellos. Andererseits ist Assembler-Code oft leichter nachvollziehbar, weil er schon sequentialisiert ist und nicht unzählige verschachtelte Ausdrücke enthält. Der Aufwand, solche Strukturen aufzudröseln, liegt hier beim Programmierer selbst und nicht beim Compiler.

Mit %n kannst du in die korrespondierende Integervariable schreiben, wieviele Elemente printf bislang bearbeitet hat:

Du liebe Güte - wo ist das denn her? Das habe ich hier auch zum ersten Mal gelesen. Abgesehen davon ist mir absolut unklar, wozu das gut sein soll.

D.h. mit %n schreibst du auf dem Stack! Bei dem schicken Speicherlayout der Intel-CPUs bzw. diverser Betriebssysteme ist damit (fast) alles möglich, z.B. Code zur Ausführung vorlegen oder Rücksprungadressen umbiegen.

Ja, da hast du natürlich Recht. Aber wer implementiert auch solche kranken Funktionen. Boah...

In diesem Sinne noch einen schönen Regentag,

Martin