3. destruktor Vector

destruktor Vector


  • 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