Auswertung von übergebenen Parametern an Exe ?!



  • Glauben ist NICHT Wissen schrieb:

    if(argv[2] == "eins\n")
    

    nein ^^

    Um die das mal zu erklären:
    argv[2]=="eins"
    hier werden 2 Pointer verglichen - einmal der, der auf "eins\0" zeigt und einmal der, der auf argv[2] zeigt - dieser vergleich wird also niemals true zurückgeben...
    c-strings (char* bzw char[]) vergleicht man mit strcmp
    allerdings verwendet man std::string - immer (weil bequemer, sicherer und vrmtl schneller als du es mit c-strings bekommen würdest ^^)
    also sind hier mal nen paar möglichkeiten:

    #include <string>
    if (argv[2] == std::string("eins"))
    
    #include <string>
    if (std::string(argv[2]) == "eins")
    
    #include <string>
    if (std::string(argv[2]) == std::string("eins"))
    
    if (! strcmp (argv[2], "eins"))
    

    Ich würde entweder 1 oder 4 nehmen ^^ wahrscheinlich eher die erste variante weil die übersichtlichste ^^

    bb



  • drakon schrieb:

    #include <string>
    ...
    std::string a2 ( argv[2] );
    if ( a2 == "eins" )...
    

    aua. 😮
    warum wollen neuerdings so viele dafür sorgen, daß c++-programme noch langsamer als java-programme sind? 😉
    das hier ist doch pure rechenzeitverschwendung.
    😞



  • volkard schrieb:

    aua. 😮
    warum wollen neuerdings so viele dafür sorgen, daß c++-programme noch langsamer als java-programme sind? 😉
    das hier ist doch pure rechenzeitverschwendung.
    😞

    Weil niemand einen nocopy string in den standard aufnimmt 😢



  • volkard schrieb:

    drakon schrieb:

    #include <string>
    ...
    std::string a2 ( argv[2] );
    if ( a2 == "eins" )...
    

    aua. 😮
    warum wollen neuerdings so viele dafür sorgen, daß c++-programme noch langsamer als java-programme sind? 😉
    das hier ist doch pure rechenzeitverschwendung.
    😞

    Da hast du zwar recht, aber 1. wertet man übergebene parameter ja sicherlich nicht an rechenintensiven stellen aus und 2. würde ich meinem compiler da einfach mal vertrauen, der dort bestimmt eh optimieren kann (hat jmd bock, das zu testen? ^^) - ums ihm einfacher zu machen hatte ich aber auch if (argv[2] == std::string("eins")) vorgeschlagen ^^

    bb



  • unskilled schrieb:

    volkard schrieb:

    drakon schrieb:

    #include <string>
    ...
    std::string a2 ( argv[2] );
    if ( a2 == "eins" )...
    

    aua. 😮
    warum wollen neuerdings so viele dafür sorgen, daß c++-programme noch langsamer als java-programme sind? 😉
    das hier ist doch pure rechenzeitverschwendung.
    😞

    Da hast du zwar recht, aber 1. wertet man übergebene parameter ja sicherlich nicht an rechenintensiven stellen aus und 2. würde ich meinem compiler da einfach mal vertrauen, der dort bestimmt eh optimieren kann (hat jmd bock, das zu testen? ^^) - ums ihm einfacher zu machen hatte ich aber auch if (argv[2] == std::string("eins")) vorgeschlagen ^^

    bb

    nimm doch einfach strcmp. oder bau dir eine bool gleicheStrings(char const* a,char const* b){return strcmp(a,b)==0;}. nocopy strings, ich nehme an, damit ist sowas wie template<size_t size> String(char const (&a)[size]):_begin(a),_end(a+size)... gemeint, sind auch sehr unterhaltsam.



  • Ich bezweifle stark dass ein Compiler das optimieren kann... Er muesste ja die Logik des Codes aendern...

    Fuer solche Anwendungen hat man immer eine String Klasse bei der Hand die nicht kopiert sondern auf prae-allokiertem Speicher arbeitet.

    Das Problem ist nicht dass man jetzt einmal sinnlose Allokationen hat, sondern dass das zur Gewohnheit wird. Dauernd wird sinnlos allokiert und gerade das string handling mit std::string verursacht da oft sehr viele Allokationen.

    Weil std::string fuer sehr viele Anwendungen einfach nicht die richtige Klasse ist.



  • volkard schrieb:

    nocopy strings, ich nehme an, damit ist sowas wie template<size_t size> String(char const (&a)[size]):_begin(a),_end(a+size)... gemeint, sind auch sehr unterhaltsam.

    Denk ich nicht ^^
    ich denke, es ist gemeint einfach nen paar funktionen zu bündeln und als member dann eben nur den pointer auf den char* ptr zu haben, also so was:

    class nocopystring
    {
    private:
       char* content;
    public:
       nocopystring(const char* _content) : content(_content) {}
    
       bool operator == (nocopystring rhs) //hier dürfte sich ne const ref kaum lohnen?!
       {
        return ! strcmp(content, rhs.content);
       }
    };
    

    bb

    edit: quote gebaut ^^
    @shade: ok - haste wohl recht - mit allem ^^



  • unskilled schrieb:

    Denk ich nicht ^^
    ich denke, es ist gemeint einfach nen paar funktionen zu bündeln und als member dann eben nur den pointer auf den char* ptr zu haben, also so was:

    Ne, volkard hat schon recht.

    Du hast eine Klasse die im Prinzip 2 Zeiger speichert: einen auf den ersten Char und einen hinter den letzten.

    So bist du zB deutlich schneller als strcmp weil du die laenge beider Strings ja vorher schon kennst.

    Wirklich toll werden solche nocopy Strings bei exzessiven String gebraucht - zB wenn du eine Datei per memory mapping in den speicher laedst. Dann kannst du ohne zu kopieren auf dem speicher operieren.



  • Also ich arbeite nicht wirklich oft mit strings an kritischen Stellen und somit habe ich mir nie wirlich Gedanken über die Performance von std::string gemacht. Auch wenn mir bewusst ist, dass es nicht die beste Möglichkeit ist.

    Mit was arbeitet ihr den so (@shade und volkard), wenn es auf Performance bei Textverarbeitung ankommt? (mal abgesehen von den C-Mitteln..)

    In boost gibt es ja keine Alternative string-Klasse.. Algos gibts zu Hauf, aber keine Klasse. 🙂



  • Shade Of Mine schrieb:

    Wirklich toll werden solche nocopy Strings bei exzessiven String gebraucht - zB wenn du eine Datei per memory mapping in den speicher laedst. Dann kannst du ohne zu kopieren auf dem speicher operieren.

    jau. so eine hatte ich mal. und sie hat sich verflixt schnell angefühlt.
    später hab ich mir einreden lassen, ich müßte unbedingt die besitzverhältnisse mitschreiben oder sowas. weils ja crashen könnte, wenn das mapping stirbt. aber damit habe ich nur alles kaputtgemacht.



  • drakon schrieb:

    Mit was arbeitet ihr den so (@shade und volkard), wenn es auf Performance bei Textverarbeitung ankommt? (mal abgesehen von den C-Mitteln..)

    eigentlich immer mit std::string. mit char* nur, wo sie nicht verarbeitet werden, sondern nur durchgereicht.
    wenns mal echt schnell sein soll, bau ich mir wohl eine geeignete klasse. die bietet dann auch gleich was tolles an, was nur für dieses eine programm lecker ist, zum beispiel in einem unsigned int32 auch noch ein bitfeld, welche buchstaben im string überhaupt vorkommen, da kann man mit bitweise-zeugst wwieder eine ganze menge von anagramm-kandidaten rauswerfen. solche spezialklassen sind übrigens beispiele dafür, wo c++-programme regelmäßig schneller sind als die pendants in c, weil man die ganzen trick einfach einbauen *kann*, ohne komplett wahnsinnig zu werden.



  • Vielen Dank für die zahlreichen Beiträge!
    Das hat mir wirklich sehr geholfen. Ich glaub ich schau da jetzt deutlich besser durch, auch was strings an sich betrifft! 🙂


Anmelden zum Antworten