C++ globale Objekte erzeugen?

Dann legst du einen oeffentlichen Zeiger in deiner Klasse an, auf den 
die anderen Klassen zugreifen koennen.

Was soll der Code? Geht es dir um eine Klasse fuer den asynchronen 
Buffer?

Georg Fr. schrieb:

> Ich hab da nun vieles von Singleton

Singleton löst ein anderes Problem.
Es geht um die Problemstellung, dass es von einer Klasse nur ein Objekt 
und nur ein einziges Objekt in einem Programm geben soll.

Georg Fr. schrieb:

> ich möchte in einer Klasse ein Objekt der Klasse "BufferedASyncSerial
> erzeugen und auf dieses auch aus einer anderen Klasse heraus zugreifen!

Die allererste Frage lautet hier: Warum?

Eines der wesenetlichsten Grundprinzipien der objektorientierten 
Programmierung ist das Information Hiding in seiner scharfen Form in 
Form von Klassen und dem verstecken von Informationen in diesen Klassen. 
Eine Klasse ist für ihre Internals verantwortlich und lässt keine andere 
Klasse an diese Internals ran. Wenn die andere Klasse etwas von diesem 
BuffereASyncSerial Objekt will, dann soll es sich gefälligst an das 
Objekt wenden, welches dieses Objekt hält. Dieses haltende Vaterobjekt 
vermittelt dann die entsprechenden Aufrufe an die Methoden des Serial 
Objektes.

Einen Zeiger auf ein Member rausrücken - da kannst du dir 
Objektorientierung auch gleich sparen. Denn genau das will man nicht 
tun.

Amöbenrolf schrieb:
> Hmm... Wenn man das Ganze so auslegt, dass die Repräsentation einer
> (physischen) Schnittstelle genau einmal vorhanden und global verfügbar
> ist, wäre die Implementation als Singleton nicht so unüblich. Das
> "gobal" ist zwar kein Muss, aber meist der Fall.

Nur so als kleiner Tipp aber Singletons gelten mittlerweile als 
überholt, da sie auch einige Schwachstellen haben.

Darf ich präsentieren: Dependency Injection ( 
http://de.wikipedia.org/wiki/Dependency_Injection )

Ist sicherer in der Instanziierung und vereinfacht das Testen im 
V-Modell.

Öffentlicher Zeiger kann für Dependency Injection genutzt werden ;)

Arne Maximilian R. schrieb:
> Nur so als kleiner Tipp aber Singletons gelten mittlerweile als
> überholt,

Die die am lautesten "veraltet" schreien und bestimmte Methoden generell 
verteufeln sind meistens Theoretiker, die noch nie einen 
funktionierenden Code über 100 (1000) Dateien weiterentwickeln pflegen 
oder warten mussten, sondern nur kleine neue Projekte gemacht haben.

Ich habe mir Dependecy Injection in Form von Google Juice anschauen 
(müssen) und bin bis jetzt noch nicht davon überzeugt.
Man kauft sich einige Vorteile durch andere Nachteile und erst mal sehr 
viel mehr Komplexität und Unübersichtlichkeit ein.

Mein Spruch ist immer noch "keep it simple".

Udo Schmitt schrieb:
> Die die am lautesten "veraltet" schreien und bestimmte Methoden generell
> verteufeln sind meistens Theoretiker, die noch nie einen
> funktionierenden Code über 100 (1000) Dateien weiterentwickeln pflegen
> oder warten mussten, sondern nur kleine neue Projekte gemacht haben.

Da hast du leider Recht. Meine Erfahrungen mit Dependency Injection ist 
nicht wirklich doll und mehr theoretischer Natur (hatte nach dem Vortrag 
kein Projekt mehr mit Objektorientierung :/ ).
Aber gerade Kernpunkte hören sich für die Wartung und das Testen des 
Systems besser an, als ein Singleton mit festen Abhängigkeiten, die man 
irgendwie für einen Unit Test aushebeln muss. Also ich versuche 
mittlerweile zumindest die Grundlagen des Konzeptes in meine Arbeit 
einfließen zu lassen. Teilweise nicht sehr einfach aber selbst bei VHDL 
macht es die Komponenten besser testbar.

Amöbenrolf schrieb:

> Hmm... Wenn man das Ganze so auslegt, dass die Repräsentation einer
> (physischen) Schnittstelle genau einmal vorhanden und global verfügbar
> ist, wäre die Implementation als Singleton nicht so unüblich.

Durchaus.

> Das
> "gobal" ist zwar kein Muss, aber meist der Fall.

Mich hat das "in einer Klasse ein Objekt der Klasse "BufferedASyncSerial
erzeugen und auf dieses auch aus einer anderen Klasse heraus zugreifen!" 
gestört.

Man kann natürlich die übergeordnete Klasse als eine Art Resource 
Manager auffassen. Aber dann hat die ja sowieso dieses eine Objekt vom 
BuffereASyncSerial in der Verwaltung. OK, man kann das als eine Art 
Singleton auffassen. Aber so richtig üblich ist das meiner Meinung nach 
nicht. Ein Singleton ist eine Klasse, die auf sich selbst insofern 
aufpasst, dass es nur 1 Objekt geben kann, was von vorne herein eine 
gewisse Globalität verlangt.