Speicher Problem

@Sussi: du hast natürlich völlig recht, das mein geposteter Code eine Mischung aus C/C++ ist, und ich versuche mal zu erläutern wieso:

Eine reine STL-Lösung ist oft schwerer verständlich, da der Code wesentlich komplexer und viel abstrakter ist. Gerade nachdem das hier eher ein Anfänger-Forum ist, ziehe ich oft eine verständlichere Lösung der "schönen" Lösung vor. Mir ist es wichtiger, dass die Leute die Pointer verstehen, denn der Rest kommt dann von alleine, aber wenn man die Basis (Pointer, Templates, Sichtbarkeit, Speichermanagement, ...) nicht versteht ist es auch schwierig mit der STL effizient zu arbeiten.
Außerdem fehlt mir leider die Zeit, für jedes Problem die beste Lösung zu finden oder mehrere Lösungsvarianten vorzuschlagen. Ich freue mich über jede schöne Lösung die ich sehe, wähle jedoch selber eher den pragmatischen Ansatz.
In einigen sehr großen Projekten in denen ich bis jetzt mitgearbeitet habe, hat sich die STL in Bezug auf Verwendbarkeit, Compiler-Unabhängigkeit und Geschwindigkeit nicht immer als die 100% beste Lösung dargestellt. Viele Teile sind sehr gut und verwende ich auch gerne, aber gerade die String-Klasse ist mir ein Dorn im Auge, da sie in vielen Aspekten nicht dem entspricht, was ich mir erwarte (Speed, Reference Counting falls benötigt, etc.).

Hier noch ein paar Kleinigkeiten bzgl. des Codes:
- den leeren Destruktor würde ich mir sparen - ist hier Overkill.
- Beim überladenen operator () würde ich auch nicht "const char&" machen, da dadurch 4 Bytes übergeben werden im Vergleich zu "const char" mit 1 Byte
- Im Konstruktor könntest du noch ein const hinzufügen

Hier noch ein paar Kleinigkeiten bzgl. des Codes:
- den leeren Destruktor würde ich mir sparen - ist hier Overkill.
- Beim überladenen operator () würde ich auch nicht "const char&" machen, da dadurch 4 Bytes übergeben werden im Vergleich zu "const char" mit 1 Byte
- Im Konstruktor könntest du noch ein const hinzufügen

- leerer Destruktor ist Formsache. Wenn man aber mal richtig ueber die vom compiler generierten DTors und Ctors gestolpert ist, gewoehnt man sich es schnell an, die dinger selbst zu schreiben, bevor es der compiler macht.
Und nochwas. Die definition des Destruktors, virtuell oder nich, ist fuer den Programmierer das Zeichen, ob er von einer Klasse Ableiten kann oder nicht. Aus diesem Grunde, wuerd ich ned auf den destruktor verzichten, auch wenn er in dem fall nur zusaetzliche schreibarbeit ist ....

- char vs referenz ....
DU weisst scho das wir meistens 32 bit prozessoren haben ? und dass mehrere prozessor takte verheitzt werden um ne 1 Byte variable ins register zu bekommen ? nen bool ist ned umsonst intern nen int z.b.
Also ob an der stelle da wirklich was gespart wird, wenn man den char direkt nimmt, wag ich zu bezweifeln.
Ausserdem wuerd ich den funktor selber so nie schreiben, bei mir waer das auch nen template ... wer weiss wass dann fuer typen da stehen
- Constructor / const
also wenn dann constante referenz ....
char_encoder(char OrValue)
char_encoder(const char & OrValue)
warum char_encoder(const char OrValue) gar keinen sinn macht, da solltest du selber drauf kommen !
und ja, haette auch version 2 nehmen koennen

und c vs c++ bei "Anfängern" generell
Ja klar isses aufn ersten blick anders, aber fuer leute die c++ richtig koennen isses definitiv einfacher zu verstehen als irgendwelches zeigergemoerkse ...
In deinem fall klar, auch ned unverstaendlich weil es quasi standard c schleifen sind ...d as muss auch jeder c++ programmierer lesen koennen. Trotzdem sollte das c++ nicht wirklich unverstaendlicher sein .
Und dann kommt genau das ... Uebung.
Und jetzt scheiden sich hier die geister ....
Was bringt man den leuten zuerst bei .... C und Zeiger, was jeder c++ler soweiso auch braucht, oder gutes c++, womit man grad am anfang schnell ins stocken geraet, weil man doch immer auf Stellen stoesst wo man dann C aehnlich vorgehen muss.
Aber grad Weg 1 birgt auch so viele gefahren ... Wie viele Vorurteile gegen C++ gibt es denn, propagiert von angeblichen C++ rogrammierern, die bei Weg 1 einfach auf halben weg stehen geblieben sind weil sie mit C und zeigern in c++ soweiso alles auch erreichen koennen. Nur den code dann warten, das koennens ned.

Erinner dich an den Beitrag in der CT, wo nen vergleich der Programmiersprachen war, wo C++ gegen Java !!!! und C# mit .Net 1.0 in der Performance verloren hat. Klar, wenn man das beispielprogramm gesehen hat, hats auch keinen gewundert
Oder wer behauptet in den Foren den immer, das gute und schnelle 3D eingines in c geschrieben werden muessen ?

der basic_string der stl ist natuerlich ned der weisheit letzter schluss. Es gibt aber fuer jede sache ihre vor und nachteile, und als guter Programmierer hasst du dir um Gottes Willen vorher gedanken zu machen, was du verwendest und was bessere Alternativen sind.
Klar, z.b. der CString der MFC ist komfortabel und performanter, durch sein ref counting und cow, aber weiss ich als user noch was das ding in wirklich keit noch macht ? Wann ich mich auf sachen verlassen kann und wann nich ?

Schon mal mit dem ding unter multithreading gearbeitet ?

Oder schon mal mit Libs gearbeitet, die dir schnittstellen z.b. mit QStrings zur verfuegung gestellt haben, obwohl du gar keine QT verwendest (verwenden willst) ...
das ding so unhandlich es manchmal mal auch daherkommt, hat auch paar ganz gravierende vorteile. Und in unserem fall sprach ja wohl ned wirklich was gegen den std::string .....

Ciao ...

write: Puts characters in a stream.

Im gegensatz zum string koennen streams auch 0 zeichen beinhalten (std::strings theorethisch auch, aber seltener verwendet, und alle die nur die C Strings kennen bekommen dann nur den teil bis zum 1. nullzeichen mit).

f.write nimmt dementsprechend nen zeiger auf das array des Charactertypes (char) auf, und ne laengenangabe, wie gross das ding ist. Damit kann man zum beispiel ganze ketten von strings in einen stream aufs mal schieben, wenn die hinterainander liegen und durch nullzeichen getrennt sind. (einige C-Api funktionen diverser BS arbeiten mit sowas)

der << operator hingegen ist fuer mehrere Typen ueberladen, ist quasi ein komfort operator. Der kann also nicht nur std::strings, C-Strings sondern auch Zahlen, die je nach typ in ein Standard Format als String konvertiert werden, was man mit entsprechenden Formatierungsflags steuern kann.
Er "vertraegt " aber immer nur einen parameter, also ohne jegliche laengenangabe. Also werden c-Strings nur bis zum ersten Nullzeichen in den Stream geschrieben, bei std::string was drinnesteht (weil der hat ne interne laengenangabe) ....

read und write nimmt man generell auch wenn man den Stream binaer behandelt, also an eine interpretation der daten nicht intressiert ist ...

aber prinzipiell in deinem Fallmacht ein :

const char [] strTest = "XXX";

stream << strTest;
und ein
stream.write(strTest, strlen(strTest));
das selbe.

Wenn kannst nimm den << operator, wenn musst das write.
Arbeitet man mit Text Streams (also dateien mit text nach ansinorm, die man in jeglichen editor betrachten kann) braucht man read und write eigentlich seltener ....

Ciao ...