ist cout eine statische Klasse?

[StaticCpp]

Dann schreib: "In C++ gibt es keine statischen Klassen". Deine Aussage: "Es gibt keine statischen Klassen" auch wenn sie im Unterforum von C++ geschirben wird, ist schlicht weg falsch. Da gibt es auch keine Spielraum, das ist Aussagelogik.

Ok, dann nenne mir einen anderen Begriff für C++-Klassen mit komplett statischen Membern und Funktionen der besser passt.

[Nexus]

StaticCpp schrieb:

"Es gibt keine statischen Klassen" auch wenn sie im Unterforum von C++ geschirben wird, ist schlicht weg falsch

Du bist unfähig den Kontext zu berücksichtigen, aber nennst mich Bürokrat.

StaticCpp schrieb:

Ok, dann nenne mir einen anderen Begriff für C++-Klassen mit komplett statischen Membern und Funktionen der besser passt.

Es gibt keinen. Es gibt in C++ wenige Gründe, Klassen nur mit statischen Membern zu füllen, wir haben dafür Namensräume.

[theta]

Nexus schrieb:

...

[volkard]

Neulich sprach einer von virtuellen Klassen. Da hab ich mich gefragt, was das sein soll.

Mit virtueller Vererbung reingeerbt? Nee, das hat gar nicht gepaßt.

Per bedingtem #include Klasseninhalte in eine Gottklasse einfügen und die Inhalte sind quasi Klassen aber doch keine, also virtuell? Nee, hat auch nicht gepaßt.

Haha! Am Ende meinte er damit nur Klassen, die eine virtuelle Funktion haben.

Also lassen wir mal die statischen Klassen weg, das macht nur Bauchweh.

[tntnet]

StaticCpp schrieb:

Dann schreib: "In C++ gibt es keine statischen Klassen". Deine Aussage: "Es gibt keine statischen Klassen" auch wenn sie im Unterforum von C++ geschirben wird, ist schlicht weg falsch. Da gibt es auch keine Spielraum, das ist Aussagelogik.

Ok, dann nenne mir einen anderen Begriff für C++-Klassen mit komplett statischen Membern und Funktionen der besser passt.

Ich würde so eine Klasse einen Designfehler nennen. Welchem Sinn dient eine Klasse, deren Instantiierung keinen Sinn macht? Solche Klassen sind in Sprachen üblich, die keine freien Funktionen kennen. In C++ würde man eher Funktionen in einem namespace implementieren.

[OOOOOOOOPPPPP]

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.

[Nexus]

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.

Du gehst immer noch nicht auf das Argument Namensraum ein, mit dem man das gleiche auf elegantere Weise lösen kann. Zudem wird ein Singleton oft eingesetzt, um den Instantiierungs- und teilweise auch den Zerstörungszeitpunkt festlegen, also die Semantik "erstelle bei erstem Benutzen, sonst nie". Ganz davon abgesehen, dass sowohl Singletons als auch globale Instanzen in sehr vielen Situationen nicht ideal, sondern nur bequem sind, und in durchdachten Designs oft wegfallen.

OOOOOOOOPPPPP schrieb:

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.

Und du kommst mir so vor, als würdest du OOP als das Paradigma ansehen und als Massstab für alle anderen Dinge nehmen. Dass du Namensräume ignorierst und deine ganze Argumentation auf Parolen wie "gegen Schnittstellen programmieren" und "andere Sprachen machen das auch" aufbaust, bestärkt diesen Eindruck zusätzlich. C++-Programmierer sind üblicherweise recht offen, weil die Programmiersprache selbst verschiedene Paradigmen anbietet und keinen Programmierstil vorschreibt. Statische Klassen gibts nur nicht, weil sie keine zusätzliche Funktionalität bringen, genau wie Java-Interfaces.

Davon abgesehen hat niemand über andere Sprachen gelästert. Wir versuchen nur, zu erklären, warum statische Klassen von C# in C++ sehr selten Sinn machen.

OOOOOOOOPPPPP schrieb:

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.

Keine Ahnung, was das Programmieren gegen Schnittstellen damit zu tun hat. Schnittstellen kannst du auch ohne Klassen haben, aber dafür müsstest du von dem OOP-Dogma wegkommen.

[Nathan]

Ich wollte ursprünglich auch antworten, aber Nexus Antwort ist nichts mehr hinzuzufügen.

[OOOOOOOOP]

Nur weil etwas selten Sinn macht, wird es nicht in C++ eingebaut? Wo du solche Logik her nimmst ist mir aber auch schleierhaft. Ich denke es wird viel in C++ geben was eher selten gebraucht wird.

Schnittstellen sind deswegen in anderen OOP-Sprachen drin, weil man damit Mehrfachvererbung vermeiden kann(Diamant-Problem etc.)

Andere Programmiersprachen sind ja nicht so erfolgreich, weil C++ alles so gut macht. Eierlegende Wollmilchsäue sind immer zu meiden, wenn es spezialisierte Werkzeuge gibt, die einem das Leben einfacher machen. Und so ist es schließlich ja auch gekommen, wenn man für was C#, Java, Python, PHP etc. anstelle von C++ nehmen kann macht man dies natürlich und das nicht ohne Grund.

Ich gebe zu von C++ noch nicht viel Ahnung zu haben. Ich sehe C++ halt als die absolute Herausforderung, weil es keine kompliziertere Programmiersprache gibt, nirgends werden einen solche Stolpersteine beim Entwickeln in den Weg gelegt. Nirgends ist die Lernkurve so krass. Das ist wie Auto fahren wo man sogar die Einspritzung manuell per Regler einstellen muss. Die einen sehen dies als den ultimativen Vorteil, die anderen wollen einfach nur so gut wie möglich von A nach B kommen.

[Kellerautomat]

An Mehrfachvererbung ist erstmal ueberhaupt nichts boese und das Diamantproblem (das in maenchen Faellen sogar erwuenscht sein kann btw) tritt nur auf, wenn man sich besonders dumm anstellt. Immer die selbe von Java/C#-Marketingspruechen gezeichnete, gequirlte Kacke. "Oh wir sind so toll, bei uns kann das Diamantproblem nicht auftreten!" - Anstatt es einfach zur Compilezeit zu verbieten, hat man gleich Mehrfachvererbung verboten. Kein Wunder, dass solche Leute nur schreckliches C++ produzieren.

Zum Rest nehme ich nicht Stellung, dazu enthaelt mir der Post zu viel Blahblah.

[nwp3]

OOOOOOOOP schrieb:

Das ist wie Auto fahren wo man sogar die Einspritzung manuell per Regler einstellen muss. Die einen sehen dies als den ultimativen Vorteil, die anderen wollen einfach nur so gut wie möglich von A nach B kommen.

Es gibt da ein Wort wobei ich wiedersprechen würde. Man muss in C++ die Einspritzung nicht per Regler einstellen, die ist von Hause aus auf einen sinnvollen Wert eingestellt. Es gilt als guter Stil den Regler nicht anzufassen wenn man ihn nicht unbedingt braucht.

Auf deine Situation angewendet: Wenn du eine Klasse willst, die nur statische Funktionen hat, dann schreib sie halt. Ich habe sowas auch schon gebraucht, weil Namensräume nicht gereicht haben, weil man in Namensräumen kein private hat. Später habe ich dann festgestellt, dass anonyme Namensräume das Problem besser lösen.

C++ hat als Grundprinzip, dass der Programmierer tun kann wie er lustig ist. Es gibt Hilfen, die verhindern sollen, dass man sich versehentlich vertut, aber wenn man will kann man praktisch alles aushebeln, was es an Sicherheitsmechanismen gibt. Mit steigender Erfahrung stellt man aber fest, dass es sich im Nachhinein als schlecht heraus stellt, wenn man es tut. Deshalb wettern die Leute hier, dass static Klassen Blödsinn sind, weil es dafür bessere Möglichkeiten gibt.

[Nathan]

OOOOOOOOP schrieb:

Nur weil etwas selten Sinn macht, wird es nicht in C++ eingebaut? Wo du solche Logik her nimmst ist mir aber auch schleierhaft. Ich denke es wird viel in C++ geben was eher selten gebraucht wird.

selten Sinn machen != selten gebraucht werden
Und wie schon öfters gesagt, statische Klassen sind C++ Namespaces, nur die Aufrufsyntax ist anders.

Schnittstellen sind deswegen in anderen OOP-Sprachen drin, weil man damit Mehrfachvererbung vermeiden kann(Diamant-Problem etc.

Es gibt auch so etwas wie Schnittstellen in C++: Klassen, die nur pure virtuelle Funktionen haben. Das SIND Schnittstellen.

Andere Programmiersprachen sind ja nicht so erfolgreich, weil C++ alles so gut macht. Eierlegende Wollmilchsäue sind immer zu meiden, wenn es spezialisierte Werkzeuge gibt, die einem das Leben einfacher machen. Und so ist es schließlich ja auch gekommen, wenn man für was C#, Java, Python, PHP etc. anstelle von C++ nehmen kann macht man dies natürlich und das nicht ohne Grund.

Jede Programmiersprache, die turing complete ist, ist eine Eierlegende Wollmilchsau. Und C# und Java sind imo genauso allgemein wie C++, da man damit auch so gut wie alles programmieren kann. Python und PHP sind spezialisierte Werkzeuge, aber nicht C# oder Java.
Und das Blöde an C# und Java ist halt: Die Sprache ist auf OOP ausgelegt. Nicht-OOP zu machen ist genauso blöd wie OOP in C. Es ist möglich, aber aufwendig. In C++ kann man so programmieren wie man möchte. Das ist das tolle daran. Du willst OOP? Kein Ding: Vererbung, Interfaces und dynamische Polymorhpie. Du willst prozedural? Kein Ding: Keiner zwingt dich irgendeine Klasse zu nutzen. Du willst funktional? Kein Ding.
Aber wirklich ausnutzen nutzt man die Sprache nur, wenn man all diese Dinge vereint. Ja, dazu muss man alle Features beherrschen. Aber wenn man es kann, macht es richtig Spaß darin zu programmieren. Dann merkt man richtig, wie gut die einzelnen Features ineinander greifen und wie toll diese komplexen Regeln doch sind.

Ich gebe zu von C++ noch nicht viel Ahnung zu haben. Ich sehe C++ halt als die absolute Herausforderung, weil es keine kompliziertere Programmiersprache gibt, nirgends werden einen solche Stolpersteine beim Entwickeln in den Weg gelegt.

Wenn du versuchst, wie in C zu programmieren ohne Destruktoren und Klassen aus der Standardbibliothek, dan ja.

Nirgends ist die Lernkurve so krass.

C++ hat ein Imageproblem. Mit einem guten Tutorial, was die Container etc. nutzt, ist die Lernkurve nicht so krass. Gut, die virtuelle Funktionsüberschreibung in Mehrfachvererbung ist kompliziert, die Name Lookup Rules in Templates mit Vererbung sind bescheuert und die Konversionregeln komplex, aber ansonsten...

[Columbo]

Klassen, die nur pure virtuelle Funktionen haben.

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

die Name Lookup Rules in Templates mit Vererbung sind bescheuert

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

[SeppJ]

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

[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