3. Objektorientierte Klassenstruktur für Zeichenprogramm - Änfängerproblem

Objektorientierte Klassenstruktur für Zeichenprogramm - Änfängerproblem

  • V

    mireiner schrieb:

    Wie wird der einfache Zugriff von Grafikresourcen nun am elegantesten in so ein Programm implementiert?

    Jede Zeichenfunktion OnDraw eines Dialogs darf den Zeichenklasten kennen. Pro Dialog ein Zeiger auf den Zeichenkasten ist wohl ok. Und die aufgerufenen Funktioinen bekommen den Zeiger auf den Zeichenkasten halt mit.

    0
  • M

    Hallo volkard,

    ah, mit einem Zeiger! Das ist glaube ich die Lösung auf die ich nicht gekommen bin.

    Damit werde ich es erst einmal versuchen.

    Danke und Grüße auch an alle anderen für ihre Ratschläge!
    Bernd

    0
  • N

    gamer8o4 schrieb:

    so wie es ist kann man aber ganz einfach die getColor() funktion umschreiben um z.b. alle farben im farbkasten dunkler zu machen. das kann man nicht im konstruktor machen , weil man sonst die CColor objekte nicht mehr so gut zwischen verschiedenen farbkästen hin-und-her reichen könnte.

    Was hat das mit der Konstruktor-Initialisierungsliste zu tun?

    Die getColor() -Funktion ist komplett überflüssig, da man statt getColor(c, r, g, b, a) immer auch c = Color(r, g, b, a) schreiben kann, was auch weniger verwirrend ist ("get" wird für anderes eingesetzt)...

    gamer8o4 schrieb:

    ich hab mir angewöhnt die sichtbarkeit als float zu speichern, weil sie dann genauer angeben kann und nicht mit werten zwischen 0 und 255 rumhantieren muss.

    Und für RGB gilt das nicht? Davon abgesehen wird die Grafikschnittstelle wahrscheinlich eh nur 256 verschiedene Alpha-Werte akzeptieren...

    gamer8o4 schrieb:

    was gibt es an standartwerten auszusetzen? die hab nur genommen, damit ich keinen standartkonstruktor schreiben muss, der eine standartfarbe setzt.

    Dass man den Konstruktor mit 1 oder 2 Argumenten aufrufen kann, was nicht sinnvoll ist.

    Color c(35, 100); // welche Komponenten sind nun gesetzt?!
Color c = 200; // wtf!? auch möglich, da nicht explicit

    gamer8o4 schrieb:

    warum soll man erst ein neues object von CColor erstellen, wenn man auch einfach ein vorhandenes nehmen kann? anders sehe der code so aus und das ist ineffizienter:

    Es spielt genau gar keine Rolle, ob du das ganze Objekt oder dessen Member einzeln zuweist. Abgesehen davon sollte der Code zuerst einen vernünftigen Stil befolgen, bevor du an solche Mikrooptimierungen überhaupt denkst. Selbst wenn du hier 2 Nanosekunden herausholen solltest (was du nicht tust), wäre das komplett irrelevant, weil du andernorts viel mehr verbrätst. Was du hingegen nicht berücksichtigst, ist die Referenz und deren Dereferenzierung, was ohne Optimierung auch nicht gratis ist.

    Fazit: Code erst schön schreiben. Nur schnell, wenn nötig.

    gamer8o4 schrieb:

    was willst du denn da private machen?

    Ich würde gar keine Klasse machen, die nur andere enthält. Allenfalls ein Namensraum, aber hier kommt man gut ohne aus.

    gamer8o4 schrieb:

    aber wie ich immer sage, mit 16 hab ich noch genug zeit das zu lernen 🙂

    Schau dir vielleicht auch ein gutes Buch wie den C++ Primer (nicht Primer Plus) an. Nur durch Programmieren lernt man -- gerade in C++ -- vieles nicht.

    0
  • M

    Mir ist gerade noch eine Idee gekommen, weiß aber nicht, ob sie möglich ist?

    Eine Basisklasse mit einem Element "Baukasten", von dem zur Laufzeit nur 1 Instanz erzeugt wird und alle von dieser Basisklasse abgeleiteten Klassen können auf einfachem Wege auf diesen EINEN Baukasten der Basisklasse zugreifen.

    Gibt es in C++ Sprachelemente die so etwas möglich machen?

    Funktioniert das womöglich, wenn das Element "Baukasten" in der Basisklasse als statisch deklariert wird?

    0
  • N

    Ja, static ermöglicht sowas. Führst du das weiter, kommst du zum Singleton-Pattern. Hier gabs gerade ne Diskussion darüber, warum das üblicherweise verpönt ist 😉

    0
  • O

    gamer8o4 schrieb:

    zurückgibt und eine Referenz als Parameter nimmt

    warum soll man erst ein neues object von CColor erstellen, wenn man auch einfach ein vorhandenes nehmen kann? anders sehe der code so aus und das ist ineffizienter:

    CColor c = getColor(100,10,75,1.0f);

    Oh aha. Also gibt es in deiner Welt kein inlining und RVO? Hast du gebnchmarkt? compilierst du mit simpelsten optimierungen? Machen das coole Kids heute so?

    0
  • G

    mireiner schrieb:

    Eine Basisklasse mit einem Element "Baukasten", von dem zur Laufzeit nur 1 Instanz erzeugt wird und alle von dieser Basisklasse abgeleiteten Klassen können auf einfachem Wege auf diesen EINEN Baukasten der Basisklasse zugreifen.

    Gibt es in C++ Sprachelemente die so etwas möglich machen?

    Funktioniert das womöglich, wenn das Element "Baukasten" in der Basisklasse als statisch deklariert wird?

    klingt nach globalen variablen (sehr schlechter stil) oder Singletons (wurde mir heute gesagt, dass man die auch nicht zu oft verwenden sollte) 😃
    mit static würde theoretisch auch funktionieren, aber naja, das könnte man in diesem fall als schlechte singleton implementierung oder auch als komische globale variable bezeichnen 😕

    0
  • G

    otze schrieb:

    gamer8o4 schrieb:

    zurückgibt und eine Referenz als Parameter nimmt

    warum soll man erst ein neues object von CColor erstellen, wenn man auch einfach ein vorhandenes nehmen kann? anders sehe der code so aus und das ist ineffizienter:

    CColor c = getColor(100,10,75,1.0f);

    Oh aha. Also gibt es in deiner Welt kein inlining und RVO? Hast du gebnchmarkt? compilierst du mit simpelsten optimierungen? Machen das coole Kids heute so?

    okay ich gebe auf 🤡

    0
  • V

    [quote="mireiner"]Mir ist gerade noch eine Idee gekommen, weiß aber nicht, ob sie möglich ist?

    Es ist möglich.

    [quote="mireiner"]Eine Basisklasse mit einem Element "Baukasten", von dem zur Laufzeit nur 1 Instanz erzeugt wird und alle von dieser Basisklasse abgeleiteten Klassen können auf einfachem Wege auf diesen EINEN Baukasten der Basisklasse zugreifen.

    ALso eine globakle Variable Baukasten.

    mireiner schrieb:

    Gibt es in C++ Sprachelemente die so etwas möglich machen?

    Ja, tausende.
    Am einfachsten, Du machst eine globale Variable, wenn Du eine meinst.

    mireiner schrieb:

    Funktioniert das womöglich, wenn das Element "Baukasten" in der Basisklasse als statisch deklariert wird?

    Klar. Aber warum dafür Vererbung anstrengen? Vererbung ist doch der echt nichtnaheliegende Weg, eine globale Variable zu deklarieren.

    0
  • M

    Hallo Nexus!

    War nur so eine Idee von mir. Wenn das wirklich möglich ist, hört sich das in meinen Ohren erst mal als die ultimative Lösung für mein Problem an.

    Das werde ich dann gleich einmal anhand eines einfachen Praxisbeispiels ausprobieren. Danke auch für den Hinweis auf den Singeton Pattern Thread, davon habe entfernt schon einmal etwas gehört.

    Grüße,
    Bernd

    0
  • M

    @volkard

    Klar. Aber warum dafür Vererbung anstrengen? Vererbung ist doch der echt nichtnaheliegende Weg, eine globale Variable zu deklarieren.

    Mmh, ich dachte ein statisches Element einer Basisklasse wäre vielleicht besser gekapselt als ein globales Objekt. Da es sich ja um sehr viele (statische) Grafikresource-Elemente handelt, wäre der Zugriff, für die von dieser Basisklasse abgeleiteten Klassen, auch denkbar einfach...

    0
  • V

    mireiner schrieb:

    die ultimative Lösung für mein Problem

    Davon habe ich vielleicht eine im Jahr.
    Sonst immer habe ich etliche sehr gute Lösungen und muss abwägen, welche wohl vermutlich mich langfristig nicht umbringt. Wer abschätzen kann, was einen nicht innerhalb eines Tages umbringt, ist ein Programmierer; wer abschätzen kann, was einen nicht in einer Woche umbringt, ist ein Entwickler; wer 3 Monate schafft, ist ein Software-Architekt; und wer ein Jahr schafft, ist ein Angeber.

    0
  • M

    volkard schrieb:

    mireiner schrieb:

    die ultimative Lösung für mein Problem

    Davon habe ich vielleicht eine im Jahr.
    Sonst immer habe ich etliche sehr gute Lösungen und muss abwägen, welche wohl vermutlich mich langfristig nicht umbringt. Wer abschätzen kann, was einen nicht innerhalb eines Tages umbringt, ist ein Programmierer; wer abschätzen kann, was einen nicht in einer Woche umbringt, ist ein Entwickler; wer 3 Monate schafft, ist ein Software-Architekt und wer ein Jahr schafft, ist ein Angeber.

    Sehr schön formuliert.

    Leider habe ich nur selten den wirklichen Überblick, über die Möglichkeiten, die mir die Sprachmittel zur Verfügung stellen. Denn als Anfänger und mäßig begabter Hobbyprogrammierer bewege ich mich allzu oft nur entlang der bisher vertrauten und bewährten Trampelpfade.

    0
Anmelden zum Antworten