Hallo zusammen,
ich gebe mal direkt zu, dass ich kein Programmiergenie bin und nur c++
grundlagen beherrsche. Kann mir jemand kurz und knapp anhand folgendem
Code erklären, wie ein Singleton muster genau funktioniert ? Ich weiß
nur, dass es darum geht eine Instanz zu managen und auf eine Instanz zu
begrenzen was tut genau der Singleton & operator=... ? und was ist mit
implizit aufrufbar gemeint ?:
1
classSingleton{
2
3
public:
4
5
staticSingleton*Exemplar(void);// Klassenmethode
6
7
protected:
8
9
Singleton(void);// Konstruktor, nur implizit aufrufbar
1. Das sind keine Hausaufgaben sondern die implementierung vom Singleton
2. Solche Kommentare solltest du dir lieber sparen, weil es hier darum
geht sich gegenseitig zu unterstützen und nicht zu versuchen jeden
runter zu machen. Wieso schaust du überhaupt in die Foren rein wenn eh
nur blödsinn geschrieben wird ?
Du hast mit dem Blödsinn angefangen...
Zumindestens ist der Code Blödsinn, und nicht compilierbar. Was genau
soll man daran also erklären ?
Wer hält irgendwelchen planlos zusammenkoppelten Kram hier einstellt,
den dabei noch falsch abschreibt, der bekommt nicht immer die Antworten,
die er sich erhofft.
Oliver
Viel wichtiger ist das Konzept. Ein Singleton ist ein Konstruk, das nur
einmal instanziert werden kann. Das erreicht man zB mit einer Semaphore.
Wenn sie weg ist, ist sie weg.
>Ein Singleton ist ein Konstruk, das nur einmal instanziert werden kann.
Vielleicht sollte man es so formulieren: Es muss nicht instantiiert
werden, sondern es ist schon da.
Bei Objektorientierung gibt es normalerweise Klassen, die beschreiben,
wie ein Objekt aussieht und was für Eigenschaften ein Objekt hat. Also
z.B. so was
Klassendefinition Dreieck
var: Kantenlänge
var: xPos
var: yPos
function: zeichne Dreieck
Instantiieren heißt, dass man mit Hilfe dieser Beschreibung eine Objekt
erst erzeugen muss. Das geschieht normalerweise mit dem New-Operator.
Dreieck d=new Dreieck();
Schaut man sich den obigen Code an, sieht man keinen New-Operator,
sondern das Objekt ist gleich da. Es ist ein Singleton.
chris_ schrieb:> sondern das Objekt ist gleich da. Es ist ein Singleton.>> void main(){>> Singleton *a, *b;>> a=Singleton::Exemplar();>> b=Singleton::Exemplar();>> }
welchen Objekt soll denn schon da sein? Das einzige was man hier sieht
ist das eine Statik Funktion aufgerufen wird mehr nicht. In der Funktion
kann das New gemacht werden.
> Instantiieren heißt, dass man mit Hilfe dieser Beschreibung eine Objekt> erst erzeugen muss. Das geschieht normalerweise mit dem New-Operator.
stimmt auch nicht so, das New braucht man sogar recht selten. OBjekte
werden einfach wie variablen angelegt.
Wenn ich solche "Experten" Diskussionen lese, ist mir klar, wieso ich
die Finger von C++ lasse!
Es gibt leider viele C++ Programmierer, die nicht wirklich und/oder
verstehen oder wissen was sie tun..
unknown schrieb:> Hallo zusammen,>> ich gebe mal direkt zu, dass ich kein Programmiergenie bin und nur c++> grundlagen beherrsche. Kann mir jemand kurz und knapp anhand folgendem> Code erklären, wie ein Singleton muster genau funktioniert ? Ich weiß> nur, dass es darum geht eine Instanz zu managen und auf eine Instanz zu> begrenzen was tut genau der Singleton & operator=... ? und was ist mit> implizit aufrufbar gemeint ?:> class Singleton {
Das wichtige beim singleton ist wie schon gesagt, dass von der
entsprechenden Klasse maximal ein Objekt gleichzeitig existieren kann.
> public:>> static Singleton* Exemplar (void); // Klassenmethode
Mit dieser statischen Methode wird das Objekt erzeugt. Es kann nicht auf
anderem Weg erzeugt werden, weil der Standard- und Kopierkonstruktor
gesperrt sind, einen allgemeinen Konstruktor gibt es ebenfalls nicht.
Man kann dieses Objekt also weder dynamisch noch über eine Deklaration &
Initialisierung erzeugen. Außerdem wird über diese Methode auch auf das
Objekt zugegriffen, denn sie gibt den Zeiger auf das Objekt
"theExemplar" zurück.
> protected:>> Singleton (void); // Konstruktor, nur implizit aufrufbar
Standardkonstruktor ist gesperrt!
> Singleton (const Singleton&); // kopieren verhindern
Kopierkonstruktor ist auch gesperrt.
> Singleton& operator= (const Singleton&); // zuweisen verhindern
Zuweisungsoperator ist auch gesperrt.
> ~Singleton (void); // Destruktor, nur implizit aufrufbar>> private:>> static Singleton* theExemplar; // Klassenvariable}
Diese Variable enthält den Zeiger auf das Objekt und wird beim Aufruf
der Methode "Exemplar" zurückgegeben. Über diesen Zeiger kann man auf
das Objekt zugreifen.
> Singleton::Singleton(void){ // Konstruktor>> }>> Singleton::~Singleton(void){ // Destruktor>> }>> Singleton* Singleton::theExemplar = 0; // Init Klassenvariable>> Singleton* Singleton::Exemplar() { // Erzeugung Exemplar>> if (theExemplar == 0){
Hier wird das Objekt dynamisch erzeugt, denn innerhalb der Klasse kann
auf die Konstruktoren zugegriffen werden.
> }>> return (theExemplar);>> }>> Void main(){>> Singleton *a, *b;>> a=Singleton::Exemplar();>> b=Singleton::Exemplar();
Über die statische Methode wird der Zeiger auf das singleton angefordert
und kann dann verwendet werden. a und b zeigen auf die selbe Adresse.
> }
Hat dir das geholfen?
So schnell wie du dieses Pattern kennen gelernt hast, so schnell
vergess' es auch wieder. Die Benutzung wird zwar gerne diskutiert, meine
Erfahrung hat aber gezeigt das man besser darauf verzichtet.
Weiterführendes Material:
http://stackoverflow.com/a/138012/3045049
Vernon D. schrieb:> So schnell wie du dieses Pattern kennen gelernt hast, so schnell> vergess' es auch wieder. Die Benutzung wird zwar gerne diskutiert, meine> Erfahrung hat aber gezeigt das man besser darauf verzichtet.> Weiterführendes Material:>> http://stackoverflow.com/a/138012/3045049
Du solltest die Links auch mal lesen und verstehen, bevor du generell
etwas verdammst. Zitat aus deinem Link:
"In practice the Singleton pattern is just a programming technique that
is a useful part of your toolkit of concepts. From time to time you
might find it is the ideal solution and so use it. But using it just so
you can boast about using a design pattern is just as stupid as refusing
to ever use it because it is just a global."
Wo habe ich es denn generell verdammt? Ich habe lediglich gesagt und
erfahren, dass man sich in der Regel damit Probleme verschafft, auf die
man am Anfang gar nicht gekommen wäre. Das man bei der Benutzung wissen
sollte was man macht versteht sich von selbst.
Vernon hatte schon recht,
Der Andere schrieb:> Du solltest die Links auch mal lesen und verstehen, bevor du generell> etwas verdammst. Zitat aus deinem Link:
Da tust Du Vernon unrecht. Stackoverflow ist in etwa dasselbe wie dieses
Forum einfach für andere Themen. Dass da auch eine andere Meinung
auftaucht, ist ja wohl normal.
Allgemein gilt schon, dass das Singleton Patter der GoF zu vermeiden ist
wenn möglich, resp. man muss sich das schon gut überlegen, ob es
wirklich nötig ist. Unter den Entwicklern ist es auch kein besonders
beliebtes Pattern.
Früher habe ich das auch oft gebraucht, heute versuche ich es aus den
genannten Gründen zu vermeiden.
Eine sehr gute Antwort finde ich zum Thema die von Aaronaught:
http://programmers.stackexchange.com/questions/40373/so-singletons-are-bad-then-what.
Allerdings geht es da mehr um Java und die Alternative sieht in Java
natürlich anders aus (C++ bietet leider/zum Glück kein Injection).
Grüsse,
René
>> Instantiieren heißt, dass man mit Hilfe dieser Beschreibung eine Objekt>> erst erzeugen muss. Das geschieht normalerweise mit dem New-Operator.>stimmt auch nicht so, das New braucht man sogar recht selten. OBjekte>werden einfach wie variablen angelegt.
Ich muss zugeben, dass ich zwar viel objektorientiert habe, aber kaum in
C++. Wenn man es lernen will, sollte man das auf keinen Fall mit C++
tun, sondern mit Python.
Meine Vorstellung ist, das mit
1
Testobjekt a;
Ein Nullpointer auf 'a' erzeugt wird, wenn 'a' keine Singleton ist.
Es gibt eigentlich dann noch keine Instanz des Objekts, sonder nur einen
Nullpointer.
Wird mit
a=new Testobjekt();
dieser Nullpointer einer initailisierten Objektstruktur zugeordnet, dann
gibt es ein Objekt bzw. eine Instanz der Klasse.
chris_ schrieb:> Meine Vorstellung ist, das mit> Testobjekt a;>> Ein Nullpointer auf 'a' erzeugt wird, wenn 'a' keine Singleton ist.> Es gibt eigentlich dann noch keine Instanz des Objekts, sonder nur einen> Nullpointer.
das ist aber bei C++ nicht so. So eine Variabel kann NIE NULL sein. Nur
Zeiger können NULL sein.
Erzeugt ein objekt:
1
Testobjekta;
Erzeugt kein Objekt, variabel ist undefiniert - also auch nicht zwingend
NULL
chris_ schrieb:> Vielleicht sollte man es so formulieren: Es muss nicht instantiiert> werden, sondern es ist schon da.
Sorry chris_, das stimmt so nicht. Man muss jede Klasse instanzieren,
auch ein Singleton. Das hat damit nichts zu tun.
Rene H. schrieb:> Da tust Du Vernon unrecht. Stackoverflow ist in etwa dasselbe wie dieses> Forum einfach für andere Themen. Dass da auch eine andere Meinung> auftaucht, ist ja wohl normal.
Nur dass auf Stackoverflow nicht jede Trivialfrage eines Anfängers in
eine sinnfreie Grundstzdiskussion wie diese ausartet.
...
Sven B. schrieb:> Nur dass auf Stackoverflow nicht jede Trivialfrage eines Anfängers in> eine sinnfreie Grundstzdiskussion wie diese ausartet.
Die Überlegung, dass das nach Hausarbeit aussieht war durchaus
vernünftig. Verstärkt durch die für Ertappte heute typische Haltung
nochmal nachzulegen, statt Buße zu tun.
unknown schrieb:> 2. Solche Kommentare solltest du dir lieber sparen, weil es hier darum> geht sich gegenseitig zu unterstützen und nicht zu versuchen jeden> runter zu machen. Wieso schaust du überhaupt in die Foren rein wenn eh> nur blödsinn geschrieben wird ?
So motiviert man erstklassig.
PS: Das Plenken und der Ton des Schreibers kommt mir bekannt vor:
Beitrag "Nach Abschlussarbeit keine Übernahme"
Sven B. schrieb:> Nur dass auf Stackoverflow nicht jede Trivialfrage eines Anfängers in> eine sinnfreie Grundstzdiskussion wie diese ausartet.
Das liegt aber auch daran, dass das Bewertungssystem der Antworten IMHO
wirklich gut ist, und die Moderatoren ein Topic sehr schnell schließen
wenn die Antwort schon vorhanden ist oder es zu Glaubenskriegen kommt.
Sonst wären dort die gleichen unendlichen Diskussionen vorhanen.
(Wäre das nicht was für hier...?)
Jay schrieb:> Die Überlegung, dass das nach Hausarbeit aussieht war durchaus> vernünftig. Verstärkt durch die für Ertappte heute typische Haltung> nochmal nachzulegen, statt Buße zu tun.
Ob es eine Hausaufgabe ist oder nicht, ist in dem Fall wirklich wurscht,
da es keine "Lösung" gibt. So wie ich das verstanden habe, geht es um
das Verständnis und hat somit durchaus seine Berechtigung hier zu
fragen.
Grüsse,
René
Um wieder Richtung Thema zu kommen:
Kann mir jemand ein typisches Beispiel in einem "normalen" Embedded
System geben, in dem das Singleton pattern eine praktische/gute Lösung
ist?
Ich finde, Pattern ohne praxisbezogenes Beispiel sind wie
Hardwareentwicklung ohne Hardwareaufbauten...
Marc schrieb:> Kann mir jemand ein typisches Beispiel in einem "normalen" Embedded> System geben, in dem das Singleton pattern eine praktische/gute Lösung> ist?
Kontrolle des Speichers/Anzahl Instanzen.
Oder, wenn nur ein LCD vorhanden ist, reicht es auch eine Instanz für
die LCD Ansteuerung zu haben. a.s.o.
Ob das eine gute Lösung ist? Ich würde mal sagen, Geschmacksache.
Ein vertretbare Lösung ist die Implementierung des Logging per Singleton
Pattern. Es gibt eine Instanz einer Klasse des Loggings, welche im
gesamten Projekt benutzt wird um Daten wegzuschreiben.
Marc schrieb:> Ich finde, Pattern ohne praxisbezogenes Beispiel sind wie> Hardwareentwicklung ohne Hardwareaufbauten...
Das dumme an Beispielen ist, dass sie immer konstruiert sind. Da kann
man dann beliebig am Beispiel rumstreiten. Meine
Mikrocontroller-Anwendungen zum Beispiel bilden immer limitierte
Resourcen durch Singletons ab. Es gibt also einen Kontext, der global
zur Verfuegung steht und da haengt dann zum Beispiel Serial drin und LCD
und was eben noch so an Umgebung zur Verfuegung steht. Pattern-Anbeter
wuerden jetzt schon wieder einen Streit vom Zaun brechen, dass Serial
und LCD gar keine Singletons sind, sondern nur der Kontext. Whatever...
effektiv sind das global verfuegbare, nur einmal existierende Resourcen.
Was uebrigens nicht automatisch bedeutet, dass auch jede Komponente vom
Code ueber den globalen Kontext darauf zugreifen wuerde. Nehmen wir zum
Beispiel an, das sei ein seriell angebundenes LCD, dann muss es ja
Serial benutzen. Da es aber eine generische Komponente ist, sollte es
besser nichts vom Kontext wissen. Also ist LCD so implementiert, als
waere Serial kein Singleton, es bekommt dieses Injected.
Dagegen, wenn du ueber deinen ganzen Code hinweg Serial als
Debug-Ausgabe benutzen willst, wirst du es kaum ueberall uebergeben
wollen.
Kurzum: Die Frage Singleton oder nicht, ist so trivial nicht zu
beantworten. Es kommt auf den Scope und auf die Anwendung an. Und vor
allem sollte man sich seine eigenen Gedanken machen und nicht sklavisch
irgendwelchen Mustern folgen - so waren sie auch nicht gedacht.
Jodel schrieb:>Meine Mikrocontroller-Anwendungen zum Beispiel bilden immer limitierte
Resourcen durch Singletons ab.
OK, bei LCD ist das OK. Aber Controller haben in der Regel mehrere
UARTs. Habe ich mit Singleton gearbeitet, und habe beim nächsten
Controller acht statt eine uart muss ich umstellen.
> Kurzum: Die Frage Singleton oder nicht, ist so trivial nicht zu beantworten. Es
kommt auf den Scope und auf die Anwendung an.
Klar, das verstehe ich und ich will ja nicht unüberlegt ein Pattern
einsetzen.
Trotzdem nochmal meine Frage: Hat jemand ein Scope / eine Anwendung in
einem Mikrocontroller System, für die das Pattern Singleton geradezu
prädestiniert ist?
Marc schrieb:> Trotzdem nochmal meine Frage: Hat jemand ein Scope / eine Anwendung in> einem Mikrocontroller System, für die das Pattern Singleton geradezu> prädestiniert ist?
Wie oben schon mal erwähnt: Logging/Tracing in einem RTOS-Kontext.
Anstattdass alle Prozesse/Tasks direkt deren Ausgaben auf die UART
spucken, schreiben sie ihre Logging in eine dafür vorgesehene
Loggingklasse, die dann die Ausgabe über den UART übernimmt. Dass könnte
man über einen Singleton machen. Muss aber nicht - eine Klasse mit
statischen Methoden ginge da auch.
Also:
> Kurzum: Die Frage Singleton oder nicht, ist so trivial nicht zu beantworten.> Es kommt auf den Scope und auf die Anwendung an.
>>chris_>> Ein Nullpointer auf 'a' erzeugt wird, wenn 'a' keine Singleton ist.>> Es gibt eigentlich dann noch keine Instanz des Objekts, sonder nur einen>> Nullpointer.> Peter II (Gast)>das ist aber bei C++ nicht so. So eine Variabel kann NIE NULL sein. Nur>Zeiger können NULL sein.
Kann es sein, dass Du nicht weißt, was ein Nullpointer ist?
chris_ schrieb:> Kann es sein, dass Du nicht weißt, was ein Nullpointer ist?
Dein Kommentar ist ohne Erklärung, was falsch ist, wertlos, es sei denn,
du möchtest provozieren.
Rene H. schrieb:> Oder, wenn nur ein LCD vorhanden ist, reicht es auch eine Instanz für> die LCD Ansteuerung zu haben. a.s.o.
Dann erzeug ich halt nur eins davon, dafür braucht man kein spezielles
Pattern. Und schon gar nicht im Displaytreiber selbst! Es wäre extrem
ungeschickt dem Displaytreiber hart einzubleuen daß es überhaupt immer
nur eines geben kann, was machst Du wenn Du mal zwei hast?
Ich hab schon genug ehemals schnell hingehackten Gerätetreibern
nachträglich beigebracht daß sie beliebig oft instantiiert werden können
für beliebig viele Geräte der selben Art. Aber den umgekehrten Weg zu
gehen und dieses Feature kaputtzumachen wenns schonmal vorhanden war
würde mir in tausend kalten Wintern nicht einfallen.
Naja, Bernd. Ich habe nicht geschrieben, dass ich das so machen würde.
Singleton brauche ich nie, da es meiner Meinung nach ein längst
überholtes und obsoletes Pattern ist.
>Dein Kommentar ist ohne Erklärung, was falsch ist, wertlos, es sei denn,>du möchtest provozieren.
Gut, es war ein wenig kurz. Aber lies doch einfach mal die zwei Sätze:
>> Es gibt eigentlich dann noch keine Instanz des Objekts, sonder nur einen>> Nullpointer.>das ist aber bei C++ nicht so. So eine Variabel kann NIE NULL sein. Nur>Zeiger können NULL sein.
Siehst Du da keinen Widerspruch zwischen Satz 1 und 2?
Peter || schrieb
>> Instantiieren heißt, dass man mit Hilfe dieser Beschreibung eine Objekt>> erst erzeugen muss. Das geschieht normalerweise mit dem New-Operator.>stimmt auch nicht so, das New braucht man sogar recht selten. OBjekte>werden einfach wie variablen angelegt.>Singleton a;
Peter Du hast Recht. Ich habe gerade folgendes mit Atmle Studio
probiert:
1
#include<avr/io.h>
2
#include<stdio.h>
3
4
classDreieck
5
{
6
public:
7
intxPos;
8
intyPos;
9
};
10
11
DreieckglobalesDreieck;
12
13
intmain(void)
14
{
15
globalesDreieck.xPos=11;
16
globalesDreieck.yPos=12;
17
18
printf("%d",globalesDreieck.xPos);
19
20
21
while(1)
22
{
23
}
24
}
Es wird tatsächlich eine Instanz des Dreiecks an Adresse 0x104 des
Atmega angelegt.
>>stimmt auch nicht so, das New braucht man sogar recht selten. OBjekte>werden einfach wie variablen angelegt.>Singleton a;
(bin auch kein C++ Programmierer)
beides (also mit und ohne New) hat aber vor/Nachteile
und ist NICHT das selbe..
siehe die 2 Antworten hier:
http://stackoverflow.com/questions/6337294/creating-an-object-with-or-without-new
chris_ schrieb:> Es wird tatsächlich eine Instanz des Dreiecks an Adresse 0x104 des> Atmega angelegt.
Diese Erfahrung sollte dich zur Erkenntnis bringen, daß ein gutes Buch
über C bzw. C++ dich sehr viel weiter bringen kann. Ohne die
allereinfachsten Grundlagen einer Programmiersprache geht es nunmal
nicht.
Oliver
Nun denn, außer Klammern, Semikolons, und sonstigem syntaktisch
erforderlichem Kleinkram fehlt dem Code oben mindestens eine ganz
entscheidende Zeile. So, wie der da steht, funktioniert er nicht. Was
soll man also daran erklären?
Ansonsten ist ein Singleton u.a. dann hilfreich, wenn man sicherstellen
will, daß eine Klasse nur einmal instanziiert wird, man aber nicht so
genau weiß, wo und wann das passiert. Das deutet dann zwar auf ein
kaputtes Softwaredesign hin, aber sowas kommt halt auch mal vor.
Im normalen Leben, und gar auf einem Mikrocontroller, braucht man das
selten bis nie.
Oliver
warum code der nicht 100% "funktioniert" (weils eh nur ums Prinzip geht)
nicht "erklärbar" ist, ist aber schon fragwürdig?
natürlich ist ein Singleton so etwas wie eine "globale Variable"
und damit per-se schon mal "böse"...
>Mikrocontroller
naja, gerade dort, kommt das eigentlich schon recht oft vor..
(also das "PRINZIP Singleton" , nicht die konkrete Implementierung, die
auf biegen und brechen das doppelte erstellen verhindern will..)
erstbestes Beispiel:
https://github.com/jcw/ethercard/blob/master/EtherCard.h>extern EtherCard ether; //!< Global presentation of EtherCard class
auf einem PC wäre das tödlich (2. Netzwerkkarte ist jetzt nicht soo
selten)
am µC mit beschränkten Ressourcen, und einer Programmierumgebung die
eher auf Einfachheit denn auf "muss alles können" ausgelegt ist, sind
(entgegen deiner Behauptung) Singleton viel eher anzutreffen..
Robert L. schrieb:>extern EtherCard ether; //!< Global presentation of EtherCard class>> auf einem PC wäre das tödlich
Da ist doch gar nichts tödlich, denn der Code "instaziiert" ja gar
nichts.
Wie weiter oben schon ganz richtig stand: Wenn man nur eine Instanz
benötigt, legt man halt nur eine an. Dafür braucht es kein Singleton.
Oliver
es geht um Dinge, die es nur einmal geben DARF!
man stellt Code zur Verfügung und will verhindern dass jemand anderer
eine 2. Instanz erstellt
alleine z.b. um Support anfragen zu minimieren)
oder auch wenn es um Sicherheit geht (z.B. will man jetzt eher nicht,
dass sich jeder einen Java "SecurityManager " selber erstellen kann..)
mit dem selben Argument: wenn man etwas nicht darf, dann macht man es
eben nicht.., könntest auch die Sinnhaftigkeit von Sichtbarkeit
(Private, Protected..) in Frage stellen
Robert L. schrieb:> es geht um Dinge, die es nur einmal geben DARF!
Was aber gerade bei deinem Beispiel einer Bibilipthek für
Hardwarekompnenten nicht per es gegeben ist, denn sie du selber
schreibst, gibt es da halt manchmal mehrere. Das Argument, so etwa
benötigt man gerade auf Mikrocontrollern, passt nicht.
Bezüglich solcher globalen Sydtemkomponenten wie einem Security Manager,
u.ä. stimme ich dir natürlich zu.
Oliver
Das Singleton Pattern imho genauso(wenig) "böse" wie bspw. ein cast oder
ein goto. Es ist einfach ein Pattern.
Sinnvolle Anwendung (im lokalen Kontext) kann caching von bereits
berechneten (konstanten) Werten sein (anstatt Neuberechnung).
Zum Caching von (konstanten) Werten nutze ich oft den statischen Scope
in Funktionen (imho die einfachste Form von Singletons).
1
staticTmakeT(...);
2
Tconst&getT()
3
{
4
staticautoTconstsingleton=makeT(...);
5
returnsingleton;
6
}
Bei der Anwendung im globalen Kontext ist die Diskussion die gleiche wie
beim Für/Wider globaler Variablen. (Wer möchte bspw.
stdin/out/err/clocale/... als Argument für jede Funktion mitschleppen?!)
Falls dann das Singleton Pattern zum Zugriff auf einen globalen Kontext
genutzt wird (Logging wird gerne genommen), do we blame the Singleton?
Bei bereits existierenden umfangreichen Code kann die Einführung eines
zusätzlichen globalen Kontextes der einzig praktische Weg für die Lösung
eines Problems sein. Wenn diese Entscheidung dann einmal getroffen
wurde, und das Singleton Pattern passt, warum nicht?
Oliver S. (oliverso)
>Nun denn, außer Klammern, Semikolons, und sonstigem syntaktisch>erforderlichem Kleinkram fehlt dem Code oben mindestens eine ganz>entscheidende Zeile. So, wie der da steht, funktioniert er nicht. Was>soll man also daran erklären?
Im Gegensatz zu Dir schreibe ich aber den Code hier herein, damit ich
und die anderen was lernen können. Anstatt dass Du nur Text absonderst,
könntest Du Dir auch die Mühe machen, die Sache an Codebeispielen zu
erläutern, die Deiner Meinung nach passen.
Am genauesten kann man erkennen was passiert, wenn man darstellt, was im
Speicher passiert und das habe ich oben gemacht.
Thread beobachten
Seitenaufteilung abschalten