ist cout eine statische Klasse?
-
Arcoth schrieb:
typenamevor abhängige Namen zu schreiben ist leicht zu erlernen - jeder Anfänger tut das mittlerweile nachdem er die Regel kennt.Und dann kommt noch template dazu, und wie ist das eigentlich mit Alias Templates?
Selbst wenn die Regeln einfach waeren - was sie nicht sind - ist es trotzdem eine Schnapsidee.
-
Und dann kommt noch template dazu
Trivial.
, und wie ist das eigentlich mit Alias Templates?
Beziehst du dich auf diesen Thread?
Nur um das gleich klarzustellen: Ja, es ist halt nicht ganz einfach, das ist recht offensichtlich. Aber ihr übertreibt alle ein wenig, findet ihr nicht?
-
-
Arcoth schrieb:
Aber ihr übertreibt alle ein wenig, findet ihr nicht?
Nein. In der Begeisterung über gewisse Möglichkeiten tendiert man dazu, Unschönheiten zu verharmlosen. Manchmal erkennt man die Tragweite auch erst, wenn man sieht, wie es anderswo viel einfacher geht.
C++ hat durchaus seine Probleme. Und nicht wenige. Dazu sollte man stehen
-
staticClass schrieb:
cout kann ich ja einfach benutzen, ohne immer extra überall erst eine Instanz davon erzeugen zu müssen. Wie macht man so eine Klasse?
cout ist eine Instanz von ofstream:
Die Deklaration findest du in der Form: extern ostream cout;
-
<a href= schrieb:
LLVM Coding Standards">The use of
#include <iostream>in library files is hereby forbidden, because many common implementations transparently inject a static constructor into every translation unit that includes it.
-
OOOOOOOOPPPPP schrieb:
Welchen Sinn statische Klassen machen? Na, wenn man im gesamten Projekt eh nur eine Instanz braucht, aber trotzdem Kapseln will. Einmal global instanzieren und dann noch mit Singleton wäre der schlechte Weg, der schöne ist dann einfach eine statische Klasse zu nehmen.
Mir kommt es langsam so vor, als wenn einige C++ler hier selten über den Tellerrand schauen und OOP wirklich nur von C++ her kennen und den Rest mit einer riesen Ignoranz gegenübertreten und es als Kindersprachen etc. abtun. Es gibt schon gute Gründe für statische Klassen und dem Programmieren gegen Schnittstellen, sonst hätte viele OOP-Sprachen das gar nicht eingebaut.
Erst mal danke für die Antwort.
Ich bin an einer gepflegten Diskussion durchaus interessiert. Dafür möchte ich aber nicht vorgeworfen bekommen, dass ich selten über den Tellerrand schaue. Das ist nicht sachlich.
Es kann sein, dass es Argumente für statische Klassen gibt. Und genau die habe ich angefragt.
Dafür sollten wir erst mal feststellen, was statische Klassen sind. Das sind Klassen, die ausschließlich statische Member haben. Richtig?
Eine Klasse ist etwas, was ich instantiieren kann. Bei so einer statischen Klasse macht das aber keinen Sinn. Daher halte ich eine statische Klasse für unlogisch. Was von der statischen Klasse übrig bleibt sind Memberfunktionen ohne Instanz. Und welche Vorteile haben diese Memberfunktionen nun gegenüber freien Funktionen in einem Namensraum?
Ich würde mich über eine gepflegte Antwort freuen, in der ich nicht beschimpft werde, dass ich unwissend bin oder engstirnig bin.
-
Man müsste dazu noch sagen: In C++ machen "statische Klassen" durchaus Sinn, aber nicht in dem von "OOP" vorgesehenen Anwendungsfall. Weil es diesen Anwendungsfall in anderen Sprachen gar nicht gibt.
Die sinnvollen Anwendungen fallen hauptsächlich in den Bereich der Template-(Meta-)Programmierung. Type Traits, Policies, Tag Dispatchers, etc. haben sehr selten nicht-statische Member.
-
Und welche Vorteile haben diese Memberfunktionen nun gegenüber freien Funktionen in einem Namensraum?
Sichtbarkeit und Kapselung fallen mir da spontan ein.
-
OOOOOOOOOP schrieb:
Und welche Vorteile haben diese Memberfunktionen nun gegenüber freien Funktionen in einem Namensraum?
Sichtbarkeit und Kapselung fallen mir da spontan ein.
Dafür gibt's ja praktischerweise anonyme namespaces*. Wurde hier im Thread auch schon gesagt. Dann sieht man die Implementierungsdetails nicht einmal mehr in der Klassendefinition.
*: Mit leichten Abstrichen kann man das auch mit static erreichen.
-
OOOOOOOOOP schrieb:
Und welche Vorteile haben diese Memberfunktionen nun gegenüber freien Funktionen in einem Namensraum?
Sichtbarkeit und Kapselung fallen mir da spontan ein.
Kapselung verstehe ich. Man kann Member teilweise privat machen, so dass nur andere Member darauf zugreifen dürfen. Die Sichtbarkeit sehe ich aber eher als Nachteil.
Alternativ kann man ja, wie SeppJ sagt, anonyme namespaces verwenden und Daten und Funktionen vor anderen komplett zu verbergen.
Bei statischen Klassen geht genau das nicht, da die Deklaration von privaten membern auch an der öffentlichen Schnittstelle bekannt sein muss. Das ist natürlich eine Eigenschaft von C++, die an sich als Nachteil von C++ angesehen werden kann.
Jetzt würde ich gerne noch erfahren, was der Vorteil von statischen Klassen gegenüber Funktionen im namespace mit anonymen namespaces ist.
