Globaler Variablen-Container

Helium

Namespaces können erweitert werden, Klassen nicht. Deshalb kann von einem Missbrauch der Klasse als Namespace nicht die Rede sein.

Können, müssen aber nicht. Du glaubst also, todo habe absichtlich 'class' statt 'namespace' verwendet, um das Erweitern zu verhindern? Das wage ich zu bezweifeln, vor allem nach der Aussage

das mit dem Namensraum ist eine gute Idee

.

Der Sinn der Übung liegt ja AFAICS gerade darin, die globalen Objekte irgendwo zentral zu kapseln, anstatt sie wild verstreut im Programm liegen zu haben.

Indem ich Sie allen so direkt zur Verfügung stelle, ja gerade zu aufzwinge, kapsel ich sie? Irendwie komme ich it der Ausage nicht klar für mich klingt das volkommen paradox.

Ob das nun sinnvoll ist, ist eine andere Frage Ich tipp mal auf nein, denn das impliziert, dass jeder Programmteil, der eine globale Variable kennt, alle anderen auch kennt.

Um nochmal auf

Das wäre z.B. ein Pointer auf eine Klasse, von der man nur eine Instanz braucht

zu kommen, woraus ja jetzt zumindest teilweise Singletons gebaut werden. Diese werden wohl kaum (so hoffe ich zumindest) alle in einer Datei liegen, sollte nicht tatsächlich eine Enge beziehung zwischen ihnen bestehen.

Bevor wir hier rumraten:
@todo: hast du vielleicht mal ein Beispiel einer solchen "nicht eindeutig zuordenbar"en globalen Variable?

neverbeenhere

Beispiel wäre die Instanz des main-windows (Qt), die andere Klassen brauchen, wenn sie z.b. ein Fenster in dem mainwindow (MDI) öffnen wollen usw.
Das Gleiche mit der Klasse song: Zugriff darauf braucht fast jede andere Klasse, weil song grundlegende Informationen beinhaltet (wie z.b. Patter-names, BPM, ...) Pattern-names braucht der der pattern-manager, in die Klasse pattern-manager will ich den pattern-names-vector aber nicht reinstecken, weil der song ja auch drauf zugreift, nämlich wenn er "sich" in eine Datei speichert... Außerdem hat song nützliche routinen, wie get_channel, get_num_of_patterns usw. die andere Klassen auch brauchen... Ist alles ein ziemlich komplexes Gebilde, das insgesamt unsauber genug ist Deswegen will ich da ja ein bisschen Ordnung reinbringen, in dem ich die Pointer irgendwo zusammenfasse...

Helium

Ob "Song" ein Singelton werden sollte weiß ich nicht. Vielleicht kann man ja mehrere Songs gleichzeitig offen haben?

Pattern-names braucht der der pattern-manager, in die Klasse pattern-manager will ich den pattern-names-vector aber nicht reinstecken, weil der song ja auch drauf zugreift, nämlich wenn er "sich" in eine Datei speichert...

Ich muss mir den Code dazu mal ansehen. Nur nach der Beschreibung könnte der Song ja auch den Pattern-Manager fragen: "Gib mir bitte mal eine Liste mit den Namen der Pattern", wenn er sich speichern will.

neverbeenhere

Also erst einmal: ich hab das jetzt mit den Singletons gemacht, ist wirklich was feines, auch wenn ich noch die die optimale Lösung habe, d.h. ich habe momentan für alle Klassen, die von sich selbst nur eine instanz erzeugen können sollen, das Singleton-Muster einzeln implementiert, besser wäre hier natürlich eine Basisklasse für Singletons, hier habe ich aber das Problem, dass ich die abgeleiteten Klassen nicht zwingen kann, ctor und dtor private oder protected zu halten... Entsprechende Lösungen wären viel zu komplex und für den Anwendungsbereich völlig unangemessen... Außerdem ist das Singleton-Muster ja nicht weiter schwer zu implementieren, einfach dtor und ctor in die private-section stecken, statischen pointer auf sich selbst in der private-section hinzufügen und eine einfache inline funktion zum abfragen der instanz in die public-section...

Helium schrieb:

Ob "Song" ein Singelton werden sollte weiß ich nicht. Vielleicht kann man ja mehrere Songs gleichzeitig offen haben?

das is nich vorgesehen, wenn man das will, muss man mein Programm einfach noch mal starten... Da ich Clipboard-Funktionen von Qt benutzen will, ist der Inhalt des Clipboards global sichtbar, d.h. man kann danmn z.B. auch in einem Song ein Pattern kopieren und in der anderen Instanz von meinem Programm einfügen... Wozu dann extra Arbeit mit mehreren Songs offen haben... Habs aber trotzdem als Singleton gemacht, weil auch sonst der Song überall gebraucht wird...

Helium schrieb:

Pattern-names braucht der der pattern-manager, in die Klasse pattern-manager will ich den pattern-names-vector aber nicht reinstecken, weil der song ja auch drauf zugreift, nämlich wenn er "sich" in eine Datei speichert...

Ich muss mir den Code dazu mal ansehen. Nur nach der Beschreibung könnte der Song ja auch den Pattern-Manager fragen: "Gib mir bitte mal eine Liste mit den Namen der Pattern", wenn er sich speichern will.

Könnte man sicher machen, da aber der Song aber auch generelle Methoden wie add_pattern usw. hat, bei denen er u.a. auf die Liste der Pattern-Names (schreibend) zugreifen muss, ist es denke ich insgesamt angebrachter, all diese Informationen in der Klasse song zu belassen... (auch wenn man entsprechende methoden im patternmanager realisieren könnte, die referenzen auf die entsprechenden listen usw. zurückliefern)

Shade Of Mine

todo schrieb:

besser wäre hier natürlich eine Basisklasse für Singletons

Nein. Templates sind die bessere Loesung.

otze

singleton vererben funktioniert nicht.
du musst wenn dann einem singleton deine Klasse vererben oder innerhalb eines singletons ein template objekt erstellen, inklusive einer funktion, die auf dieses objekt zugreift.

Helium

singleton vererben funktioniert nicht.

Wenn du es darauf auslegst schon:

class Singleton {
protected:
   Singleton () {}
   Singleton (Singeton const & other);
public:
   static Singleton & instance ()
   {
      static Singleton foo;
      return foo;
   }   
};

class AbgleitetesSingleton : public Singleton {
   AbgleitetesSingleton () {}
   AbgleitetesSingleton (AbgleitetesSingleton const & other);
public:
   static AbgleitetesSingleton & instance ()
   {
      static AbgleitetesSingleton foo;
      return foo;
   }   
};

du musst wenn dann einem singleton deine Klasse vererben

Man vererbt Klassen nicht, sondern Klasen erben einfach von anderen Klasse. Was sie genau erben ist dabei erstmal egal.

oder innerhalb eines singletons ein template objekt erstellen, inklusive einer funktion, die auf dieses objekt zugreift.

template <typename T>
struct Foo {
   T foo;
};

class Singleton {
   Singleton () {}
   Singleton (Singeton const & other);
   Foo<int> foo;
public:
   static Singleton & instance ()
   {
      static Singleton foo;
      return foo;
   }
   void eine_funktion_die_auf_die_Instanz_zugreift ()
   {
       foo.foo = 42;
   }
};

Und was passiert jetzt?

otze

du machst das absichtlich , najo so lern ich wenigstens die fachsprache

template<class T>
class Singleton {
   Singleton () {}
   Singleton (Singeton const & other);
   T bla;
public:
   static Singleton& instance ()
   {
      static Singleton foo;
      return foo;
   }
   T eine_funktion_die_auf_die_Instanz_zugreift ()
   {
       return bla;
   }
};

Helium

du machst das absichtlich

ja klar :p

otze

class Singleton { 
protected: 
   Singleton () {} 
   Singleton (Singeton const & other); 
public: 
   static Singleton & instance () 
   { 
      static Singleton foo; 
      return foo; 
   }   
};

funktioniert das? hier gabs ma nen ähnlichen versuch den dtor protected zu machen, der versuch scheiterte aber kläglich, da protected dtors der basisklasse vom dtor der abgeleiteten klasse aufgerufen werden konnten..

Helium

funktioniert das? hier gabs ma nen ähnlichen versuch den dtor protected zu machen, der versuch scheiterte aber kläglich, da protected dtors der basisklasse vom dtor der abgeleiteten klasse aufgerufen werden konnten..

Das ist bei Konstruktoren nicht anderes, aber wenn du in mein Beispiel guckst, wirst du shenen, dass es in der abgeleiteten Klasse privat ist.