fragen zu strcpy() und strcat()

.filmor

Es ist ziemlich egal, ob du nun 20 KB oder 200 KB benutzt.
Darüber gibts einen ganzen Wust an Diskussionen hier im Forum. Hast du schonmal versucht die Binärdatei zu strippen? Dann bleibt meist auch nicht mehr viel übrig. Außerdem hat (scheinbar) das PE-Format mit MinGW auch einen (in diesem Bereich) nicht unerheblichen Einfluss auf die Größe.
Wenn du C++ lernen willst, dann benutz auch die C++ Möglichkeiten (hier wären imho Stringstreams angebracht), erst recht jetzt, da du das ganze schon einmal von Hand implementiert hast.

THX 1138 schrieb:

Weil die Zeiten mit 64kB RAM vorbei sind!

Ne sorry, es gibt bei PC Anwendungen eigentlich keinen Grund, auf Grösse zu optimieren. Mach das ruhig so, um zu lernen. Aber benutz dann lieber die std::strings und ihre Methoden, die sind sicherer und einfacher zu nutzen weil du dich nicht ums Speichermanagment kümmern brauchst.

1. meine <string> version klappt 100% ist mir aber bei großen datenmengen zu langsam da immer der shic copy-constructor aufgerufen wird
2. ich will auch was über dynamische speicherverwaltung lernen, rate mal warum ich c++ lerne und nicht delphi

THX 1138

neomic schrieb:

1. meine <string> version klappt 100% ist mir aber bei großen datenmengen zu langsam da immer der shic copy-constructor aufgerufen wird
2. ich will auch was über dynamische speicherverwaltung lernen, rate mal warum ich c++ lerne und nicht delphi

1. ev. kannste da was mit call-by-reference optimieren
2. dann lern c und nicht c++
3. nicht böse werden, sind gut gemeinte tipps

THX 1138 schrieb:

1. ev. kannste da was mit call-by-reference optimieren
2. dann lern c und nicht c++
3. nicht böse werden, sind gut gemeinte tipps

zu 1: wie geht das denn?^^
zu 2: new und delete sind doch erst mit c++ dazugekommen oder irre ich? o.0
zu 3: ich werd nich böse nur ernst, weil ihr die ganze zeit um den heißen brei drumrumredet... also nich denken ich mag euch net oder so (das stimmt nämlich net)

THX 1138

3. easy
2. ja, ersetzen malloc und free
1. zeig mal deine Standard-C++ Lösung, dann kann ich dir vielleicht helfen.

Ansonsten kurz erklärt

Call by Value:

void do_something_with_it( HugeClass it );  // Copy-Ctor wird aufgerufen

Call by Reference:

void do_something_with_it( HugeClass& it );  // Copy-Ctor wird nicht aufgerufen, it kann verändert werden

Call by Const-Reference:

void do_something_with_it( const HugeClass& it );  // Copy-Ctor wird nicht aufgerufen, it kann nicht verändert werden

.filmor

neomic schrieb:

meine <string> version klappt 100% ist mir aber bei großen datenmengen zu langsam da immer der shic copy-constructor aufgerufen wird

Und du glaubst, das lässt sich nicht optimieren? Zeig mal den Code!

neomic schrieb:

2. ich will auch was über dynamische speicherverwaltung lernen, rate mal warum ich c++ lerne und nicht delphi

Der Trick an der dynamischen Speicherverwaltung ist, dass sie richtig eingesetzt extrem effizient ist, der Programmierer aber trotzdem nicht viel davon sieht. Man kapselt den Zeigerkram einfach weg. Direkt am Speicher rumzuwurschteln machst du eigentlich nur in der Kapselung und in C.

neomic schrieb:

zu 1: wie geht das denn?^^

Du benutzt Referenzparameter. Das erspart die Kopie.

neomic schrieb:

zu 2: new und delete sind doch erst mit c++ dazugekommen oder irre ich? o.0

Ja und? malloc und free sind die äquivalenten Funktionen in C. Der Bedarf nach new und delete kam daher, dass bei C++ Objekten auch der Konstruktor aufgerufen werden muss (wobei das denke ich auch mit Templates gelöst werden kann, die gabs damals aber noch nicht).

neomic schrieb:

zu 3: ich werd nich böse nur ernst, weil ihr die ganze zeit um den heißen brei drumrumredet...

Nein, wir suchen nur ein einfacher und schöner lösbares Problem. Und strcpy und Konsorten sind nunmal nicht der C++ Weg.

Werner Salomon

neomic schrieb:

hab ich auch schon und es klappt...

int Find(char *pchar,char *pcharsearch){
// ..
    while(!done){
            while(pchar[i]==pcharsearch[j]){
                if(j==GetLength(pcharsearch))done=true;

Dieses Find hat mindestens O(n^2)-Komplexität. Und damit lieferst Du ein schönes Beispiel, dass man sowas eben nicht tun sollte. Also bei Verwendung von langen 'search-strings' wird Deine Lösung gegenüber einem std::string::find furchtbar langsam.

Dass ein Exe um sehr viel größer wird, wenn man einen #include <string> einfügt, muss nicht sein, ist aber leider oft (oder immer?) so. Da haben es sich die Entwickler der einschlägigen IDE's irgendwie einfach gemacht.

Ansonsten gilt die Regel: Speicherplatz und CPU-Zeit werden immer billiger, aber (Programmierer-)Arbeitszeit wird immer teurer. Damit ist ein einfaches Programm - im Sinne von wenig Source-Code billiger als ein einfaches Programm im Sinne einer geringen Größe.

Gruß
Werner

string Int2Hex(int integer,int length=2) {
    char strlength[0];
    sprintf(strlength,"%i",length);
    string modifiers="%0";
    modifiers+=strlength;
    modifiers+="x";
    char hexadecimal[0];
    sprintf(hexadecimal,modifiers.c_str(),integer);
    return hexadecimal;
}
string String2Hex(string input) {
    string output;
    for(int i=0;i<input.size();i++){
        output+=Int2Hex(static_cast<unsigned char>(input[i]));
        if (i!=input.size()-1) {
            output+=',';
        }
    }
    return output;
}

THX 1138

Was sicher mal geht:

string String2Hex(const string& input) {

Spart dir den Copy-Ctor

Edit:
*blödsinnweggemacht*

ich denke der knackpunkt ist bei "output+="