3. destruktor Vector

destruktor Vector


  • win8789 schrieb:

    Techel schrieb:

    Da dein Feld immer gleichgroß bleibt, musst du doch nichts dynamisch ändern?

    das Spielfeld ist auch statisch, nur die Anzahl an Steingruppen ist variabel. So gibt es Gruppen die aus 2 Steine, aus 5 Steinen, 9 Steinen usw. bestehen.

    Welche Steine gesetzt wurden interessiert doch nach dem Platzieren keinen mehr. Alleine welche Felder des Spielfelds danach (in welcher Farbe, zur Anzeige) belegt sind, ist relevant.

    win8789 schrieb:

    hustbaer schrieb:

    Vielleicht fehlen win8789 da einfach nur die C++ Grundlagen?

    Was denkst du?

    jup. Und Programmiererfahrung allgemein.

    0
  • W

    Swordfish schrieb:

    win8789 schrieb:

    Techel schrieb:

    Da dein Feld immer gleichgroß bleibt, musst du doch nichts dynamisch ändern?

    das Spielfeld ist auch statisch, nur die Anzahl an Steingruppen ist variabel. So gibt es Gruppen die aus 2 Steine, aus 5 Steinen, 9 Steinen usw. bestehen.

    Welche Steine gesetzt wurden interessiert doch nach dem Platzieren keinen mehr. Alleine welche Felder des Spielfelds danach (in welcher Farbe, zur Anzeige) belegt sind, ist relevant.

    win8789 schrieb:

    hustbaer schrieb:

    Vielleicht fehlen win8789 da einfach nur die C++ Grundlagen?

    Was denkst du?

    jup. Und Programmiererfahrung allgemein.

    Ja da hast du wohl recht. Bin halt noch Schüler und muss auch für die Schule was mache. Aber ich versuche halt besser zu werden und in der Schule können die Lehrer nur Java, deshalb mir dort keiner helfen kann.

    [quote="win8789"]

    Techel schrieb:

    Da dein Feld immer gleichgroß bleibt, musst du doch nichts dynamisch ändern?

    das Spielfeld ist auch statisch, nur die Anzahl an Steingruppen ist variabel. So gibt es Gruppen die aus 2 Steine, aus 5 Steinen, 9 Steinen usw. bestehen.

    Swordfish schrieb:

    Spaßeshalber. Zeig mal. Mir schwant Schreckliches.

    extra für dich hab ich mir Dropbox heruntergeladen und hier der link:

    https://www.dropbox.com/sh/gi1u9o690yq4srj/AADdz_gLxVs5qTwstFaO5cpIa?dl=0

    hoffe es klappt.

    p.s. brauchst QT

    edit hab noch ein bissisch aufgeräumt, sollte jetzt aber kleiner sein

    0

  • win8789 schrieb:

    Vielleicht fehlen win8789 da einfach nur die C++ Grundlagen?

    Was denkst du?

    Ich denke ja. Und ich denke du hast ein "an" am Anfang dieses Satzes vergessen. 😉

    An was denke ich? Na z.B. daran wie das ganze mit Klassen, Konstruktoren, Destuktoren, Basisklassen etc. funktioniert. Also wie das alles ineinandergreift. Genau so was es mit lokalen Variablen und Destruktoren auf sich hat. Was dann erklärt warum behauptet wurde dass nen std::vector mit new Erzeugen wohl nur selten Sinn macht (sinngemäss).

    Das ist aber richtig viel was es da zu wissen gibt, mehr man in einem Thread schnell mal zusammenfasst/erklärt. Also such/kauf/besorg dir ein gutes Buch. "The C++ Programming Language" von Stroustrup soll wohl recht gut sein *. Ansonsten gibt's hier ne Liste:
    https://www.c-plusplus.net/forum/251551-full

    *: Beachte aber die Bewertungen auf Amazon. Die Softcover-Version scheint ein Fehldruck zu sein (fehlen angeblich 40 Seiten, an deren Stelle andere Seiten doppelt gedruckt wurden), und bei der Kindle-Edition scheint wohl die Formatierung der Codebeispiele nicht optimal zu funktionieren.

    0
  • W

    hustbaer schrieb:

    An was denke ich? Na z.B. daran wie das ganze mit Klassen, Konstruktoren, Destuktoren, Basisklassen etc. funktioniert. Also wie das alles ineinandergreift. Genau so was es mit lokalen Variablen und Destruktoren auf sich hat. Was dann erklärt warum behauptet wurde dass nen std::vector mit new Erzeugen wohl nur selten Sinn macht (sinngemäss).

    ok wär es dann besser einen rohen dynamischen array zu erstelllen?

    p.s hast du dir meinen Quellcode angesehen? Eine kleine Rückmeldung wäre sehr nett.

    0
  • W

    ok hab jetzt mal versucht das ganze mit einem statischen vector zu machen.
    Erbebis die Steine werden sofort nach den erseinen gelöscht. Ich denke mal, dass das an Qt liegt.

    Ich hab es so gemacht:

    //im konstruktor:
std::vector<item_group_item> item(1);
//im anderen konstruktor
std::vector<item_group_item> item(2);
//im anderen
std::vector<item_group_item> item(4);
//im anderen, man könnte man das nicht anders machen
std::vector<item_group_item> item(5);

//als private variable in der Klasse
private:
    std::vector<item_group_item> item;

    Wenn ich keinen fehler gemacht habe, muss ich wohl dynamsiche Objekte für die Spielsteine verwenden.

    Oder um es anders zu Fragen, was ist jetzt nun der beste weg einen dynmamischen Array zu konstruieren. Soll ich eine einfachen Array verwenden:

    //z.B.
int * pointer = new int[irgenwas];

//später
delete [] pointer;

    oder irgendeine Klasse verwenden.

    0

  • win8789 schrieb:

    Oder um es anders zu Fragen, was ist jetzt nun der beste weg einen dynmamischen Array zu konstruieren.

    std::vector

    //im konstruktor:
std::vector<item_group_item> item(1); // ### Das macht eine lokale Variable im Konstruktor, die sofort wieder
                                      // ### zerstört wird wenn der Konstruktor fertig ist
//im anderen konstruktor
std::vector<item_group_item> item(2); // ### -- "" --

(...)

//als private variable in der Klasse
private:
    std::vector<item_group_item> item; // ### Das wäre die Membervariable, die du aber anscheinend nicht verwendest.
                                       // ### Die lokalen Variablen mit dem selben Namen "verdecken" die Membervariable.

    win8789 schrieb:

    Wenn ich keinen fehler gemacht habe, muss ich wohl dynamsiche Objekte für die Spielsteine verwenden.

    Hast du aber. Ich sag ja dir fehlen die Grundlagen. Was ja kein Problem ist, jeder hat mal angefangen. Nur irgendwann solltest du es lernen, und das wird sehr mühsam ohne gute Unterlagen. Kauf dir ein Buch. 🙂

    Als Beispiel wie du nen vector als Membervariable anlegst und im Konstruktor dann Elemente einfügst:

    class MeineKlasse
{
public:
    MeineKlasse();

    void MachWas();

private:
    std::vector<MeinItem> m_items;
};

// Variante 1

MeineKlasse::MeineKlasse()
    : m_items(123) // vector mit Grösse 123 initialisieren. Das erzeugt 123 Items mit dem Default-Konstruktor
{
}

// Variante 2

MeineKlasse::MeineKlasse()
    // Wenn hier nix steht wird m_item mit dem Default-Konstruktor erzeugt, und ist dann erstmal leer
{
    m_items.push_back(MeinItem("foo")); // Ein Item einfügen (wird in den vector rein kopiert)
    m_items.emplace_back("bar");        // Ein Item einfügen ohne dass es dabei kopiert werden muss
                                        // - es wird dabei direkt im vector erzeugt und mit "bar" initialisiert
    // ...
}

void MeineKlasse::MachWas()
{
    // Alte Schreibweise, immer noch oft nützlich z.B. wenn man den Index i irgendwo braucht oder sowas
    for (size_t i = 0; i < m_items.size(); i++) // Alle Items durchgehen ...
         m_items[i].MachWas();                  // ... und was machen

    // Moderne, kürzere schreibweise
    for (auto& item : m_items)  // Alle Items durchgehen ...
        item.MachWas();         // ... und was machen
}
    0
  • W

    hustbaer schrieb:

    win8789 schrieb:

    Wenn ich keinen fehler gemacht habe, muss ich wohl dynamsiche Objekte für die Spielsteine verwenden.

    Hast du aber. Ich sag ja dir fehlen die Grundlagen. Was ja kein Problem ist, jeder hat mal angefangen. Nur irgendwann solltest du es lernen, und das wird sehr mühsam ohne gute Unterlagen. Kauf dir ein Buch. 🙂

    Ok hab es nun verstanden. Wenn die Instanz selber dynamisch ist. So bleiben die Attribute selber so lange erhalten, wie es die Instanz gibt. Weshalb die Atribute einer Instanz fast immer statisch sein können.

    danke, könntest du dir vielleicht noch den rest des Codes ansehen?
    Übersehe hiebei am beseten den Konstruktor und desstroktor der Klasst item_group. Die überarbeite ich noch die tage

    0

  • win8789 schrieb:

    Weshalb die Atribute einer Instanz fast immer statisch sein können.

    Ich hoffe du meinst hier mit statisch dass es halt ganz normale Member sind - nix Zeiger und so.
    Weil static würde nämlich ganz 'was anderes bedeuten.

    win8789 schrieb:

    danke, könntest du dir vielleicht noch den rest des Codes ansehen?

    Welcher Rest?

    0
  • W

    hustbaer schrieb:

    win8789 schrieb:

    Weshalb die Atribute einer Instanz fast immer statisch sein können.

    Ich hoffe du meinst hier mit statisch dass es halt ganz normale Member sind - nix Zeiger und so.
    Weil static würde nämlich ganz 'was anderes bedeuten.

    win8789 schrieb:

    danke, könntest du dir vielleicht noch den rest des Codes ansehen?

    Welcher Rest?

    ich meine damit ganz normal. mit static würde ich doch Attribute erstellen, welche Instanz übergreifende für eine klasse gelten, oder ?

    Ich hab mal eine Dropbox link zum ganzen Programm bereit gestellt.

    https://www.dropbox.com/sh/gi1u9o690yq4srj/AADdz_gLxVs5qTwstFaO5cpIa?dl=0

    nochmal danke.

    Edit noch etwas überarbeitet jetzt

    0

  • main.cpp schrieb:

    #include "window.h"
#include <QApplication>

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    window * w = new window;
    w->show();
    w->test();
    return a.exec();
}

    Wozu new window ? Wozu auf dem Heap? Bitte, bitte lern mit einem guten(tm) Buch die Grundlagen anstatt mit Qt herumzuspielen.

    0
  • W

    Swordfish schrieb:

    main.cpp schrieb:

    #include "window.h"
#include <QApplication>

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    window * w = new window;
    w->show();
    w->test();
    return a.exec();
}

    Wozu new window ? Wozu auf dem Heap? Bitte, bitte lern mit einem guten(tm) Buch die Grundlagen anstatt mit Qt herumzuspielen.

    Ok danke für den Hinweis,
    auch wenn die main immer automatisch von qt erstellt wurde.
    Ich hab jetzt die anzahl an dynamischen objektetn so verringert, dass nur noch objekte, welche zerstört werden, aber ihre klasse nicht, dynamisch sind. Wie
    z.B die item_gruppen, welche immer wieder gelöscht und neu erstellt werden müssen.

    Bitte, bitte lern mit einem guten(tm) Buch die Grundlagen anstatt mit Qt herumzuspielen.

    Ich hab bis jetzt mit dem Buch der c++ Programmierer gearbeitet.
    Gibt es noch weitere definziete (in hinblick auf vererbung usw.)

    Wie schon erwähnt in der Schule hab ich keinen der sich meine c++ Programme genauer ansehen kann.

    Jedenfalls werde ich jetzt viel vorsichtiger mit dynamischen Objekten sein.

    Nochmals danke

    0
  • ?

    Swordfish schrieb:

    Wozu new window ? Wozu auf dem Heap? Bitte, bitte lern mit einem guten(tm) Buch die Grundlagen anstatt mit Qt herumzuspielen.

    Qt hat ein eigenes Objekt-Verwaltungssystem (vielleicht über überladene new-Operatoren realisiert). Für die Oberklasse von Window (in main.cpp nicht sichtbar) ist das statische Attribut QT::WA_DeleteOnClose gesetzt.

    0

  • Hm. Auf meinem Qt 5.6 ...

    auto wa = new QMainWindow();
	if( wa->testAttribute( Qt::WidgetAttribute::WA_DeleteOnClose ) )
	{
		::MessageBoxA( nullptr, "yay", "yay", MB_OK );
	}

    nix yay, nope.

    ?

    0
  • F

    Swordfish schrieb:

    Hm. Auf meinem Qt 5.6 ...

    auto wa = new QMainWindow();
	if( wa->testAttribute( Qt::WidgetAttribute::WA_DeleteOnClose ) )
	{
		::MessageBoxA( nullptr, "yay", "yay", MB_OK );
	}

    nix yay, nope.

    ?

    Jupp da macht Qt nichts automatisch. Das Flag muss man schon extra setzten.
    Z.b. in diesem Beispiel aus der Qt docu wird die MainWindow instanz auf dem stack angelegt.
    http://doc.qt.io/qt-5/qtwidgets-mainwindows-application-example.html
    Und auch die sonstigen QWidget basierenden Beispiel in der Qt docu legen das Haupt Widget/Window immer auf dem Stack an (in der main methode)
    http://doc.qt.io/qt-5/widgets-tutorial.html

    0
  • ?

    So ist es - nicht automatisch, da hat sich der TE wohl vertan. Aber wenn es gesetzt ist, MUSS das Objekt auf dem heap angelegt werden, sonst gibtes einen Crash. Minimalbeispiel für die Klasse Window, die in obigen main.cpp verwendet wird:

    class Window : public QMainWindow {
public:
  Window() {
    // erforderlich, wenn Window mit new erzeugt wird
    // und delete in main.cpp fehlt!
    setAttribute(Qt::WA_DeleteOnClose);
  }
};
    0

  • cute? schrieb:

    [...] wenn es [Qt::WA_DeleteOnClose] gesetzt ist, MUSS das Objekt auf dem heap angelegt werden, sonst gibtes einen Crash. [...]

    Ja. Das ist klar wie Kloßbrühe? Darum gehts ja wohl nicht?

    Der Punkt ist, daß man als Anfänger gut daran tut, alles was man an Quellcode in seinem Projekt sieht, verstehen zu wollen. Bei dem von mir an offensichtlicher Stelle angekreidetem new sollte man sich eben Fragen: wozu? Das führt dann zum Nachschlagen im Lehrbuch und zur Qt-Dokumentation und falls Fragen bleiben ins Forum. Der OP kümmert sich aber darum nicht. Schlecht.

    0
Anmelden zum Antworten