ist cout eine statische Klasse?

[Nathan]

Arcoth schrieb:

Klassen, die nur pure virtuelle Funktionen haben.

Nein, Klassen die mindestens eine pur virtuelle Funktion haben. Das sind dann abstrakte Basisklassen, oder eben Schnittstellen.

AFAIK haben Interfaces in Java und Co auch nur pure virtuelle Funktionen oder irre ich mich?

die Name Lookup Rules in Templates mit Vererbung sind bescheuert

Wieso sind die bitte bescheuert? Wovon redest du da!?

kkaw schrieb:

Aktuelles Beispiel:

typedef typename soundso<T>::template foo<T> blah_t;

Dass man manchmal "typename" und "template" in solchen Fällen braucht, ist halt peinlich.

Ist das schön? Und in Vererbung kommt da dann noch ein this-> bzw. BaseClass:: vor.

SeppJ schrieb:

@Nathan: Man kann und sollte(!) in C auch sehr gut OOP machen. Die Sprache kommt einem bloß nicht mit direkter Unterstützung direkt entgegen. C ist viel größer und besser, als einem die kleinen Beispielprogramme in Programmierhandbüchern vorgaukeln.

Genau das meinte ich: Die Sprache kommt nicht mit direkter Unterstützung entgegen. Deshalb muss man in C Destruktoren, Vererbung, virtuelle Funktion, Kapselung etc. ziemlich umständlich implementieren. Und in Java/C# sind das eben die freien Funktionen.

[Columbo]

Ist das schön?

Darum geht es nicht.
Sie sind nicht nicht bescheuert, sondern eine voll funktionsfähige Methode, die Ambiguitäts-Probleme zu lösen.

Unter bescheuert verstünde ich folgendes: Überhaupt nicht intuitiv, extrem schwer zu erlernen - Compiler implementieren es dank der vielen komplizierten Regeln meistens im Detail unterschiedlich bzw. falsch, es ließe sich leicht zu einem viel besseren System umändern, usw.
~Edit: Das ist doch nicht etwa eine Liste, die Templates heutzutage ausmacht, oder?~

typename vor abhängige Namen zu schreiben ist leicht zu erlernen - jeder Anfänger tut das mittlerweile nachdem er die Regel kennt.
Der Rest ist ebenfalls einfach eine Regel die man sich einmal merken muss, und nicht merkbar komplizierter. Es gibt auch relativ wenig Inkonsistenz oder Ausnahmen.

[Kellerautomat]

Arcoth schrieb:

typename vor 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.

[Columbo]

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?

[Kellerautomat]

http://www.c-plusplus.net/forum/325410

[Nexus]

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

[cacscdfdfs]

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;

[cout=designfehler]

<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.

[tntnet]

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.

[Nexus]

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.

[OOOOOOOOOP]

Und welche Vorteile haben diese Memberfunktionen nun gegenüber freien Funktionen in einem Namensraum?

Sichtbarkeit und Kapselung fallen mir da spontan ein.

[SeppJ]

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.

[tntnet]

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.