Statische Klassen

Reth

Simon2 schrieb:

Reth schrieb:

...Mit ner statischen Klasse kann ich das umgehen, die kann ich nach dem include von überall aus zugreifen!...

Aber auf Dein private Member soll doch keiner drauf zugreifen !! (sonst wäre es wohl nicht private) ... damit sehe ich nicht ein, warum es alle "sehen" sollten.

Entweder ich verstehs gerad nicht, oder wir reden aneinander vorbei?

Auf das private Member soll natürlich keiner zugreifen (daher private), nur die Methoden der Klasse, in der dieses Member vorhanden ist (also createAddFrame() und getFrames() aus meinem Code)!

Und wieso sieht dieses Member jeder? Es ist doch private (oder hast Du das vllt. so verstanden, dass eine Referenz/ein Zeiger auf dieses Member aus der Klasse herausgegeben werden soll? Das passiert natürlich nicht [s. geposteten Code]!)!

Im Prinzip hast Du recht, es handelt sich hierbei um eine Funktionssammlung für eine spezifische Aufgabe (wie in einem meiner letzten Postings beschrieben), die aber für ihre Erledigung einen Container (daher das private Member) benötigt.
Das private Member musste ich deswegen statisch machen, weil die Methoden der Klasse, welche es benutzen auch statisch sind!

LordJaxom schrieb:

Könnte man. Spart Schreibarbeit und hat technisch fast denselben Effekt.
Ich meine aber auch gelesen zu haben, dass das klassische Meyers-Singleton sich gerade dadurch auszeichnet, dass es die lazy-initialization von funktionslokalen statischen Variablen ausnutzt.
static Factory& instance ()
    {
        static Factory _instance;
        return _instance;
    }

Ich verstehe aber immer noch nicht, wieso die statische Methodenvariable ihren Inhalt nach Verlassen der Methode behält!?

Ciao

LordJaxom

Reth schrieb:

Ich verstehe aber immer noch nicht, wieso die statische Methodenvariable ihren Inhalt nach Verlassen der Methode behält!?

Weil das der Sinn und Zweck von statischen Funktionsvariablen ist. Sie behalten ihren Wert über Aufrufe hinweg.

Reth

Wird dabei der Scope der Variablen total vernachlässigt?
Der wirkt sich ja dann nur noch auf die Zugreifbarkeit aus, aber nicht mehr auf die Gültigkeit, oder?

Ciao

LordJaxom

Genau. Sichtbarkeit ist nur innherhalb der Funktion gegeben, Gültigkeit jedoch während annähernd der gesamten Programmlaufzeit.

Simon2

Hi,

Reth schrieb:

Simon2 schrieb:

Reth schrieb:

...Mit ner statischen Klasse kann ich das umgehen, die kann ich nach dem include von überall aus zugreifen!...

Aber auf Dein private Member soll doch keiner drauf zugreifen !! (sonst wäre es wohl nicht private) ... damit sehe ich nicht ein, warum es alle "sehen" sollten.

Entweder ich verstehs gerad nicht, oder wir reden aneinander vorbei?

Auf das private Member soll natürlich keiner zugreifen (daher private), nur die Methoden der Klasse, in der dieses Member vorhanden ist (also createAddFrame() und getFrames() aus meinem Code)!

Und wieso sieht dieses Member jeder? ...

Ganz einfach: Weil es in Deinem Header steht, den jeder, der Deine Funktionen nutzen möchte, einbinden muss !

Stell Dir einfach vor, dass sich zwischen dem 2. und 3. Release herausstellt, dass Dein ursprünglich gewählter Container verändert werden muss (z.B. bekommt die map einen anderen key oder Du schwenkst auf eine multimap oder ...): Dann muss jeder Nutzer Deiner Lib

einen neuen Header einbringen und
seinen ganzen Code neu compilieren.

Wenn Du die globale Variable in Deiner cpp einführst, compilerst Du einmal neu, bindest Deine lib neu und drückst sie Deinen Kunden in die Hand - fertig. Sie können sogar mit der alten witerarbeiten, wenn sie die neue Version nicht unbedingt brauchen (alter Header ist zu neuer Lib kompatibel).

Prinzipiell sollte man sich bemühen, die Kopplung so gering wie möglich zu halten.

Reth schrieb:

...es handelt sich hierbei um eine Funktionssammlung für eine spezifische Aufgabe (wie in einem meiner letzten Postings beschrieben), die aber für ihre Erledigung einen Container (daher das private Member) benötigt....

"einen Container benötigen": Ja
"ein privates Member benötigen": Nein

Dieser Container muss gemeinsam sein (deswegen global und statisch) - mehr nicht.

Gruß,

Simon2.

hustbaer

Simon2 schrieb:

...
//meineFunktionen.cpp
namespace meineGlobalen {
   int glob1 = 3; // geht genauso wie meine "Hilfsfunktionen" oben
}

namespace meineFunktionen {
   int f(int x) { return x * glob1++; }
}
Jetzt kann nicht nur niemand außerhalb Deines Moduls darauf zugreifen, sondern er sieht sie nicht mal ! Also: Keine Probleme mit Mehrdeutigkeiten, nur Linkabhängigkeit (wenn Du glob1 mal verändern willst), ....
...

Du solltest hier wirklich einen nameless namespace (aka. anonymous namespace) verwenden. Einen nicht dokumentierten namespace "meineGlobalen" zu verwenden in der Hoffnung dass niemand anders einen namespace so nennen wird... jack pfui, wer macht denn sowas.

Und nur damit klar ist was ich meine: es kann *jeder* sofort von aussen darauf zugreifen, und zwar so:

namespace meineGlobalen {
   extern int glob1;
}

void foo()
{
    meineGlobalen::glob1 = 42;
}

Simon2

hustbaer schrieb:

...
Du solltest hier wirklich einen nameless namespace (aka. anonymous namespace) verwenden. ...

Stimmt ! Hatte mich "vertippt" ... in meinem vorherigen Beispiel ("Hilfsfunktionen") war es noch drin.

Danke für den Hinweis,

Simon2.

Reth

.filmor schrieb:

Naja, du hast es ja auch tatsächlich nirgendwo definiert. Im Prinzip sind statische Klassenmember nicht mehr als globale Variablen. Deshalb reicht auch die Deklaration nicht aus (wäre für globale Variablen sowas wie extern int bla;), sondern du musst sie noch in genau(!) einer Quellcodedatei definieren. Deine FrameFactoryC.cpp bietet sich da sehr an:
#include "FrameFactoryC.h"

// Vielleicht auch mit Konstruktorargumenten oder sowas
std::map<const int, std::vector<FrameC *> > FrameFactoryC::frames;

Werden hier schon die Map und der Vector definiert und Speicher für beide belegt, so dass man direkt Werte in den Vector stellen kann, wie z.B.:

FrameFactoryC::frames[3].push_back(...);

?

Ciao