Problem mit zwei Objekten



  • Ok, vielen Dank für eure Hinweise. Dann frage ich mich, warum solch eine Lösung in einem doch seriösen Buch vorgestellt wird.

    lg, freakC++



  • freakC++ schrieb:

    @SeppJ: Was meinst Du genau mit dem Mischmasch? Ich finde die Idee der Klasse Random nämlich ansich ganz gut...

    Sie wäre gut, wenn sie nichr rand() benutzen würde.
    So geht der überraschende RandomDestroy-Angriff, wo ich mithilfe eines anderen Objektes Dein Objekt unbrauchbar mache.

    //seeden sei schon repariert. 
    Random rand1;
    rand1.init(0,1000);
    
    {//Angriff aus fremder Funktion
       Random rand;
       rand.init(0,1000);
       int count=0;
       do
          if(rand.random()!=17)//evtl andere zahl nehmen
             count=0;
       while(count<4);//hier hochschrauben, bis es nicht mehr geht
    }
    
    cout<<rand.random();//gar nicht mehr zufällig
    


  • freakC++ schrieb:

    Das ist aber von Ulla Kirch-Prinz und Peter Prinz.

    Achso.
    Das richtige heißt ja auch "C++: Einführung und professionelle Programmierung". Daß der Prinz-Name an das gute Buch erinnert, ist nur Trittbrettfahrerei.

    freakC++ schrieb:

    Dann frage ich mich, warum solch eine Lösung in einem doch seriösen Buch vorgestellt wird.

    Es ist kein seriöses Buch. Keine Ahnung, was euch boons immer wieder dazu bringt, es zu kaufen.



  • Weil es gute Bewertungen hat und ein eigenes Übungsbuch!

    lg, freakC++



  • freakC++ schrieb:

    Weil es gute Bewertungen hat und ein eigenes Übungsbuch!

    Alle Bücher haben gute Bewertungen. Oder wenigstens keine schlechten. Und Programmierbücher kann der Anfänger, der die Bücher liest, noch gar nicht bewerten. Und das eigene Übungsbuch hatte ich neulich in den Flossen, das ist grottig.



  • Was findest Du denn daran grottig. Du als Erfahrender kannst das wahrscheinlich besser sagen. Sonst finde ich, dass all die Übungen genau den Stoff aufgreifen, die im eigentlichen Lehrbuch behandelt worden sind.

    lg, freakC++



  • freakC++ schrieb:

    Was findest Du denn daran grottig.

    Ähm, zum Beispiel das da:

    #include <iostream> 
    #include <ctime> 
    #include "Random.h" 
    using namespace std; 
    
    void Random::randomSeed() 
    { 
        unsigned int seed = (unsigned int)time(NULL); 
        srand(seed); 
    } 
    
    void Random::init(int i_min, int i_max) 
    { 
        max = i_max; 
        min = i_min; 
    
        randomSeed(); 
    } 
    
    int Random::random(void) 
    { 
        return min + rand()%(max+1 - min); 
    }
    


  • was findest du daran denn so extrem grottig?
    Random::randomSeed()
    ist vermutlich geschmackssache

    #include <iostream> ist zugegebenermaßen unnötig
    und
    int Random::random(void) ist auch weder hübsch noch konsistent - noch c++ig^^ aber deshalb gleich grottig? Oo

    bb



  • #include <iostream> 
    //hat hier nichts zu suchen
    
    #include <ctime> 
    
    #include "Random.h" 
    
    using namespace std; 
    
    void Random::randomSeed() 
    { 
        unsigned int seed = (unsigned int)time(NULL); 
    //Kathastrophe I! Mal mindestens static machen und inkrementieren, sonst passiert das Zeit-Auslesen 
    //tausendmal pro Sekunde und das hat dann mit Zufall nichts mehr zu tun. 
    //time(0) wäre auch hübsch
        srand(seed); 
    //KATHASTROPHE II! Hier wird per Random-Klasse ein privater Zustand 
    //vorgetäsucht aber in Wirklichkeit nur ein total verwirrter 
    //Wrapper um srand/rand gebaut. Das führt mit Sicherheit zu Fehlern. 
    //Ein zusätzliches rand() wäre hier angebracht, um die Sekundenhochzählung 
    //zu verschleiern. 
    } 
    
    void Random::init(int i_min, int i_max) 
    //Kathastrophe III, dafür ist der Konstruktor da. 
    { 
        max = i_max; 
        min = i_min; 
    
        randomSeed(); 
    } 
    
    int Random::random(void) 
    //Unnützes void
    { 
        return min + rand()%(max+1 - min); 
    }
    


  • //Kathastrophe I! Mal mindestens static machen und inkrementieren, sonst passiert das Zeit-Auslesen 
    //tausendmal pro Sekunde und das hat dann mit Zufall nichts mehr zu tun. 
    //time(0) wäre auch hübsch
    

    seh ich hier nicht so - man sollte das init natürlich nicht vor jedem rnd() aufruf aufrufen

    //KATHASTROPHE II! Hier wird per Random-Klasse ein privater Zustand 
    //vorgetäsucht aber in Wirklichkeit nur ein total verwirrter 
    //Wrapper um srand/rand gebaut.
    

    find ich nicht all zu schlimm... am anfang kann man, wenn man zufall braucht und oop zeigen will, (imho) nicht viel anderes machen

    //Ein zusätzliches rand() wäre hier angebracht, um die Sekundenhochzählung 
    //zu verschleiern.
    

    wäre nicht schlecht, da hast du recht
    aber an sich ist das auch noch kein fehler...

    void Random::init(int i_min, int i_max) 
    //Kathastrophe III, dafür ist der Konstruktor da. 
    { 
        max = i_max; 
        min = i_min; 
    
        randomSeed(); 
    }
    

    ich nehm mal an, dass man unterschiedliche zufallsspannen braucht und nicht noch den op= erklären will, weil der erst später kommt und zu gleich nicht zeigen will, dass man hier gar keine klasse braucht, weil man immer nur init(), random() aufruft und somit auch ne fkt hätte nehmen können...

    das mit dem void hatten wir schon mal...

    eigtl ist hier "nur" das bsp. (rand/srand) doof gewählt - ansonsten sinds nur kleinere fehler...
    und von einem bsp auf das ganze buch zu folgern ist zumindest fraglich...

    bb



  • unskilled schrieb:

    find ich nicht all zu schlimm... am anfang kann man, wenn man zufall braucht und oop zeigen will, (imho) nicht viel anderes machen

    Objekte zu haben, nur um so zu tun, als würde man OOP nutzen, ist etwas fragwürdig. So tun, weil das Konzept mehrerer Objekte als unterschiedliche Entitäten nicht beachtet wird. Von einer Klasse erwarte ich normalerweise, dass einzelne Instanzen voneinander unabhängig agieren (ungeachtet dessen, dass ich sie natürlich selber verbinden kann oder abhängige Instanzen im Design so vorgesehen sein können).

    Zwei Objekte, die einen gemischten Status haben, bringen hier nicht viel. Da programmiert man lieber prozedural und weiss dafür, dass es sich um ein und dieselbe Sache handelt.

    unskilled schrieb:

    ich nehm mal an, dass man unterschiedliche zufallsspannen braucht und nicht noch den op= erklären will, weil der erst später kommt und zu gleich nicht zeigen will, dass man hier gar keine klasse braucht, weil man immer nur init(), random() aufruft und somit auch ne fkt hätte nehmen können...

    Oben argumentierst du noch mit OOP, und hier soll der Benutzer plötzlich die Initialisierung vergessen dürfen? Konstruktoren sind für mich ein wichtiger Bestandteil der objektorientierten Programmierung und deren Ansatz, korrekte Objektstati sicherzustellen.



  • Ja, klar ists nicht korrekt - aber ich stell es mir relativ trocken vor, erst dann die erste Klasse zu programmieren, bei der man auch mal was sieht, wenn man Konstruktoren usw fertig behandelt hat...

    Wollte ja auch gar nicht sagen, dass das Buch gut ist - aber ist ja auch gut möglich, dass das das einzige fragwürdige bsp war!?

    bb



  • unskilled schrieb:

    Ja, klar ists nicht korrekt - aber ich stell es mir relativ trocken vor, erst dann die erste Klasse zu programmieren, bei der man auch mal was sieht, wenn man Konstruktoren usw fertig behandelt hat...

    Ich hingegen finde es didaktisch unklug, solche zweifelhaften Beispiele zu bringen, auch wenn sie für den Leser einfacher zu sein scheinen. Solche Dinge gewöhnt man sich als Anfänger relativ schnell an. Lieber gleich richtig.

    Konstruktoren muss man auch nicht fertig behandelt haben, um sie einsetzen zu können. Templates kennen wohl relativ wenige C++-Programmierer vollständig (schon nur von der Sprache her), verwenden sie aber trotzdem. Das ist immer ein Abwägen, wieviel Verständnis vorhanden sein muss, um ein Sprachmittel sinnvoll anwenden zu können. Auf Konstruktoren bezogen denke ich, dass man ruhig das Wichtigste erwähnen könnte, besonders viel oder schwierig ist es nicht. Zumindest finde ich dieses Vorgehen besser, als von Anfang an eine falsche Sichtweise auf die Dinge zu vermitteln.


Anmelden zum Antworten