Ab jetzt sollte man nicht mehr weiterentwickeln. Der restliche Teil von C++, der noch nicht unterstützt wird, ist offensichtlich völlig überflüssig und nutzloser Ballast, und man sollte ihn aus dem C++-Standard herauswerfen. Dann hätte man vielleicht etwas, das in die Richtung geht wovon Stroustrup mal sprach:
"Within C++, there is a much smaller and cleaner language struggling to get out." -- Bjarne Stroustrup
Interessante Frage. Damit hätte C++ einen Nachteil weniger. Ist das technisch möglich und umgesetzt oder können im Header zuviele Sachen wie z.B. Art der Klasse (abstrakt und so) drinstehen, die ein solches Programm nicht wissen kann?
EDIT: Ich denke aber nicht, dass es möglich ist, andernfalls wäre es längst in alle größeren IDEs implementiert.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 05. Feb 2010 um 18:48.
> Keine das ist lediglich historischer Ballast aus der Zeit einer Rechen- und Speicherbegrenzten PDP-7 Kiste. Natürlich gibt es Unterschiede. Mithilfe von Headern ist es möglich, so etwas wie die Trennung von Deklaration und Definition vorzunehmen. Angenommen, Du hast zwei Bibliotheken, die die gleichen Klassen grundverschieden implementieren und eine Anwendung, die diese Klassen verwendet.
Du compilierst Deinen gesamten Anwendungscode gegen einen Satz Headerfiles. Damit wird es möglich, die Entscheidung, welche der beiden Bibliotheken zur Verwendung kommt, erst ganz am Ende, zur Link-Zeit, zu treffen.
Ich kann deine Argumentation absolut nicht nachvollziehen. Ich kann ja z.B. in Java auch gegen die eine SAX Implementierung programmieren obwohl am Zielsystem eine andere zur Verfügung steht (welche die selben Features bietet). Das Konzept der Schnittstelle einer Bibliothek hat nix mit Headern zu tun.
Aber warum müssen auch die privaten Attribute im Header stehn? Ganz einfach, weil der Kompiler das Speicherlayout der Klassen kennen muss. Überall wo ein new steht oder schlimmer noch ein Objekt am Stack angelegt wird muss der Kompiler wissen wie groß das Objekt ist. Und wenn irgendwo auf ein (auch nicht privates) Attribut zugegriffen wird muss der Kompiler den Offset dieses Attribut kennen. Das kann er nur kennen wenn er weiß wie viele und wie große Attribute im Objekt vor kommen und wie diese sortiert sind.
Wenn man Objekte nur über new anlegen können würde dann könnte man zumindest die Größe des Objekts in eine Methode herausheben (allocator). Aber C++ kann Objekte ja auch am Stack anlegen und muss zumindest dort schon zur Compiletime die Größe kennen. Bei Java ist das anders. In Java gibts nur new. Theoretisch könnten jedoch JVMs den Controllflow analysieren und Objekte, die garantiert nur so lange leben wie die Methode in der sie erzeugt werden am Stack anlegen und nicht dem Garbage Collector überlassen (z.B. oft bei StringBuilder/StringBuffer). Das würde gehen weil Java einen JIT hat un erst den endgültigen nativen Code generiert wenn die entsprechende Klasse geladen wurde und die JVM somit das Speicherlayout/Größe der Klasse kennt. (Würde die Klasse entladen und aus anderer Quelle neu geladen werden müsste nochmal der JIT angeworfen werden. Aber ich glaub zu so einen Fall wirds wohl nicht kommen, da die Klasse mit dem neu zu JITeten Code ja noch eine Referenz auf den z.B. StringBuilder hält und somit wird die Klasse auch nicht entladen.) Und auch in Java sind die privaten Attribute "sichtbar". Man kann sie per Reflection auflisten und wenn das Programm nicht in einen speziellen Security Context (z.B. Sandbox) läuft, können private Attribute auch ausgelesen und gesetzt werden (ebenfalls per Reflection).
Sprich es hat einen guten Grund warum private Attribute im Header stehn. Wer sich über so etwas wundert sollte mal Konzepte des Kompilerbau wiederholen.
> Ich kann ja z.B. in Java auch gegen die eine SAX Implementierung programmieren obwohl am Zielsystem eine andere zur Verfügung steht Das ist halt der Punkt: Du brauchst mit Headern zum Programmieren noch nicht einmal eine Implementierung. Ein Textfile mit ein paar Forward-Deklarationen, schon kompiliert Dein Sourcefile zu einem Objektfile.
Das man das nutzen kann um gegen mehrere Libs linkbar zu sein, solange sie die API des Headerfiles erfüllen, ist lediglich eine denkbare Anwendung dafür. Mock-up prototyping wäre eine andere, die ich persönlich zum Beispiel recht gern nutze.
> Aber warum müssen auch die privaten Attribute im Header stehn? Das wurde doch schon weidlich diskutiert.
> oder schlimmer noch ein Objekt am Stack angelegt wird Daran ist gar nichts schlimmes.
> Das geht aber auch wenn der Kompiler selbst die API aus der Sourcecode entnimmt Und wenn auch mein Code schon geschrieben ist, muss ich morgens gar nicht erst aufstehen. Auch richtig, geht aber ebenfalls an der Grundaussage vorbei.
Header sind deklarative Konstrukte, sie haben doch gerade den Sinn, dass man den Code an sich nicht zur Verfügung haben muss.
> Händisch verwaltete Headers sind einfach nur schlecht, kompliziert, fehleranfällig Man kann sich auch dumm anstellen.
> und auch insbesondere langsam. Also die anderen Argumente lasse ich ja noch unter "Geschmackssache", "Designphilosophie" oder ähnlichen Stichworten durchgehen, langsamer ist es mit Headern aber definitiv nicht. Ob Du die Symbolinformationen nun aus einem oder einem anderen Format entnimmst, ist diesbezüglich vollkommen irrelevant.
Private Variablen/Member stehen drin, damit der Compiler weiß, wieviel Speicherplatz ein Objekt der Klasse braucht (deswegen können Klassen der privaten Member auch nicht nur forward deklariert sein). So könntest Du in Deinem Code z.B. kein sizeof() machen von einer Klasse aus einer anderen Bibliothek oder ein Objekt davon anlegen.
Das könnte er aber auch wissen wenn er einfach den source code zusätzlich parst. Genau wie private virtuelle Methoden. Und wie diese völlig merkbefreiten Forward Declarations. Nur weil das Drecksding immer noch ein single parse compiler ist der nicht weiss was 3 zeilen später passiert.
Ach muss meinen Blutdruck wieder runtergehen lassen - C++ ist einfach Drecksmist.
Tja, klingt, als wurdest Du gezwungen, c++ zu benutzen oder einen Compiler zu entwickeln.;)
Oh, OT: Ich muss eine Fehlinformation richtig stellen, die ich in den Umlauf gebracht habe. Irgendwo in den PyGame Docs stand, dass die Performance von PyGame so grottig sei, dass man damit keine Anwendungen bauen könnte, bei denen der ganze Bildschirm neugezeichnet wird, was ich bei der LÖVE-Nachricht mal erwähnt hatte.
Nun meinte Kiba aus dem Forum von Freegamer dass das Ganze weder mit PyGame noch mit RubyGame ein Problem sei, selbst mit einem 1Ghz Rechner käme er damit auf eine brauchbare Framerate, obwohl PyGame kein OpenGL benutzt. Wahrscheinlich sind einfach die Dokumente veraltet.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 06. Feb 2010 um 00:08.
"source code zusätzlich parst" Haha, dann bräuchtest Du ja für alle Bibliotheken, die Du in Deinem Code verwendest, auch die Quellen. Scheint wohl nur unter Linux unterwegs, auch nett.
C++ Drecksmist? Und dann mit Begriffen wie Single-Parse-Compilern um Dich werfen? Lebenslanges Lernen scheint angesagt...
Vielleicht meint Lothar ja den Quelltext der vorliegenden Datei. Würde ja auch Sinn machen, im Sinne von welche "Verbindungen" der Compiler zu den Klassen/Variablen der Bibliothek bauen muss. Private Sachen würden halt keine Verbindung bekommen.
Nur so ne Theorie. Nicht, dass ich mich mit Compilern groß auskennen würde.
Um zum Beispiel eine statische Instanz einer Klasse auf dem Stack anzulegen, musst Du deren Layout ja vollständig zur Compile-Zeit kennen. Deshalb müssen auch alle Datenmember Bestandteil der Deklaration sein - und deren Datenmember in deren Deklaration. Oder eben auch allgemein, um die Größe einer Instanz oder den Offset von Membern zu kennen.
Wenn Du gern ganz privat mit deinen privaten Datenstrukturen sein willst, mache es doch wie die KDE-Entwickler: In die Deklaration packst Du einen Pointer auf eine private Datenstruktur, die Du in lediglich benennst. Das funktioniert,. weil auf einer Plattform die Breite eines Pointers fest und daher zur Compile-Zeit bekannt ist. In der Implementierung schließlich legst Du im Konstruktor eine dynamische Instanz Deiner dort vollständig bekannten privaten Klasse an und referenzierst einfach deren Member.
Es wurde doch bereits weidlich diskutiert, warum es Vorteile haben kann, Header zu verwenden und warum ich dann auch private Strukturmember im Header deklarieren muss. C++ ist nun einmal eine Programmiersprache, die Headerdeklarationen unterstützt und nutzt.
Bestimmte Designentscheidungen haben eben Konsequenzen, mit denen man leben muss. Darüber kann man sich jetzt echauffieren oder ersatzweise Sprachen verwenden, die eine andere Herangehensweise haben. Vielleicht solltest Du letzteres in Betracht ziehen.
Ja ja sollte "Single-Pass" Compiler heissen, aber diesen Typo sollte iegentlich jeder erkennen der was von Compilern versteht. Und das C++ kein Drecksmist ist sagen nur Leute mit weniger als 10 Jahren C++ Erfahrung.
Dann hast du noch nicht genug Erfahrungen mit C++. Nach 10 Jahren C++ ist man noch in der Begeisterten-Phase, weil man stolz ist, dass man Template-Metaprogramming durchstiegen hat und man vermurkste Dinge, die man hart erlernt hat toll findet, weil ist ja "mächtig" (TM). Wart's ab, du wirst C++ auch noch hassen lernen.
"If you like C++, you don't know C++. There's a mutual exclusion going on here, and I've yet to see a counter-example other than possibly a few of the members of the standards committee."
C++ ist, man staune, so wie jede andere Sprache nicht perfekt. Sie hat ihre Ecken und Kanten.
Und genau hier liegt der Unterschied zu den Leuten, die immer an ihrem Platz stehen bleiben werden, obwohl sie sich bewegen und die Zeit fortschreitet. Trotz oder genau wegen seiner - von vielen gehassten - Nachteile hat man die Möglichkeit das Beste aus der Sprache rauszuholen. Man hat weiterhin die Möglichkeit Tugende wie Geduld oder gar Beharrlichkeit zu entwickeln, die sich auf das übrige Leben positiv auswirken. Hassen bringt einen also nirgends weiter.
Wie will man sonst die Nachteile einer Sprache erkennen, wenn man 'die vermurksten Dinge' nicht begreift? Obwohl ich das Wort Nachteile durch Schwächen ersetzen würde.
Wenn man mit der Zeit eine Zuneigung zu der Sprache entwickelt, weil man die Sprache besser beherrscht oder Teile davon verstanden hat und diese Zuneigung Liebe nennt, dann ist es doch perfekt! Wird man auch noch mit den Schwächen der Sprache besser vertraut und versteht sie zu hantieren, dann hat man sich weiterbewegt. Unabhängig von Zeit um Raum.
> Dann hast du noch nicht genug Erfahrungen mit C++. Nach 10 Jahren C++ ist man noch in der Begeisterten-Phase Es sind bereits mehr als 10 Jahre. Aktuell sind es genau genommen 14 Jahre. Davor mehrere Jahre andere Programmiersprachen.
> Wart's ab, du wirst C++ auch noch hassen lernen. Ich kenne die Tiefen von C++ bereits. Die Vorteile sind jedoch unbestreitbar und - je nach Kontext - verglichen mit den sogenannten "Alternativen" unverzichtbar. Es gibt einfach Umgebungen, in denen Du das Layout des Speichers, die Architektur, das Footprint Deines Codes, das Verhalten des Compilers und andere Spezifika genau kennen musst. Hier gibt es einfach keinen Ersatz zu C/C++.
Ja kommt drauf an, wo man es einsetzt. In der Systemprogrammierung hat es sicher noch einen festen Platz. Aber für GUI-Desktopanwendungen ist es wohl denkbar ungeeignet...
Ich kann zwar mittlerweile nicht mehr sagen, dass ich C++ besonders mag, aber so schlimm finde ich es auch nicht. Manchmal kommt man halt nicht drum rum...
Aber für GUI-Desktopanwendungen ist es wohl denkbar ungeeignet...
Ja ist sie, aber jetzt komm mir bitte nicht mit den anderem Müll der sich C# und Java nennt. Es gibt auch ein Leben ausserhalb der heiligen Dreifaltigkeit.
Ich würde alle 3 Sprachen jedenfalls nicht nutzen. Schade nur das es keinen MFC Wrapper für Objective-C gibt, nichtmal einen vernünftigen Objective-C Compiler.
Daher nehme ich auch weiterhin Eiffel für alle GUI Anwendungen.
Es ist einfach, private Variablen in Headern zu vermeiden, wenn man das denn für nötig hält (in der Regel ist es das nicht, da man sie zwar sehen, aber nicht in irgendeiner Form darauf zugreifen kann). Dazu deklariert man in der Headerdatei eine abstrakte Basisklasse, die das Interface spezifiziert. Außerdem braucht man noch eine statische Methode, die dazu dient, Instanzen der Klasse zu erzeugen: class B { public: virtual void f() = 0; static B *create(); }; In der Implementierungsdatei leitet man von dieser Basisklasse die Klasse ab, die das Interface implementiert. class D : public B { public: void f() { //Code hier } };
B *B::create() { return new D(); } Und schon hat man alle private-Variablen aus den Headern entfernt.
Leider ist diese D Backend genau wie der Rest von D sowas von Buggy das du schon mit dem Klammerbeutel gepudert sein müsstest um damit ernsthaft eine Mission Critical Anwendung zu schreiben.
D's Drang besser zu sein als C/C++ um sich damit endlich mal zu etablieren führt leider zum Gegenteil. Hoffentlich wird nach D 2.0 endlich mal 5 Jahre ein Sprachweiterentwicklungsverbot verhängt - ähnlich wie bei Python 3
D 2.0 gibt es deswegen, weil es bei D 1.0 dazu kam, daß neben der Standardlibrary noch eine zweite von der Community entwickelt wurde, die genau das gleiche macht, nur halt auf eine andere Weise. Das eigentliche Problem dabei war nur, daß man nicht beide gleichzeitig verwenden kann, da sie inkompatibel zueinander sind. Mit D 2.0 ist nun geplant, diese zu vereinen.
Und dann gibt's natürlich hier und da noch ein paar kleinere Verbesserungen für D 2.0. Was aber für D 2.0 viel wichtiger wäre, wäre meiner Meinung nach, daß man D in etwas anderes umbennt, z.B. D++, damit man danach auch suchen kann ohne Ständig "Programming Lanuage" dem Suchmuster hinzuügen zu müssen.
Wenn du ein paar kleinere Programme mit D schreiben willst, dann nimmst du moment besser den Compiler von Digital Mars, denn der ist ausgereift. Zumindest gilt das für D 1.0.
Ich glaube ja, daß der schnell kompiliert, aber seine Kompilate, wie sieht es mit deren Laufzeit-Effizienz aus?
Ist primär gar nicht wichtig. Für das Release Build kann man immer noch einen anderen Kompiler nutzen.
Weil man mit dem anderen Compiler bisher keine Tests gefahren hat, fällt man dann auf die Fresse.
Mehrere Compiler für einen Zweck einzusetzen ist ganz großer Schwachsinn.
Umgekehrt wird ein Schuh draus: sich auf die Eigenheiten irgendeines Compilers zu verlassen, das ist Schwachsinn.
isbn dazu: 3540495967
ich hab das much gelesen und glaube, mich zu erinnern, dass darin genau diese methode des compilerbaus beschrieben wird.
PS: Diese Kontrollwörter sind ja teilweise nicht mal für einen Menschen lesbar.
Ab jetzt sollte man nicht mehr weiterentwickeln. Der restliche Teil von C++, der noch nicht unterstützt wird, ist offensichtlich völlig überflüssig und nutzloser Ballast, und man sollte ihn aus dem C++-Standard herauswerfen. Dann hätte man vielleicht etwas, das in die Richtung geht wovon Stroustrup mal sprach:
"Within C++, there is a much smaller and cleaner language struggling to get out." -- Bjarne Stroustrup
Mit dem äußeren, fiesen Teil meinte er sicher das Headerkonzept.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 05. Feb 2010 um 18:07.Gibt es da eigentlich IDEs/Scripte, die die Header automatisch erstellen können?
Interessante Frage. Damit hätte C++ einen Nachteil weniger.
Ist das technisch möglich und umgesetzt oder können im Header zuviele Sachen wie z.B. Art der Klasse (abstrakt und so) drinstehen, die ein solches Programm nicht wissen kann?
EDIT: Ich denke aber nicht, dass es möglich ist, andernfalls wäre es längst in alle größeren IDEs implementiert.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 05. Feb 2010 um 18:48.Bei C++ stehen sogar die privaten Variablen in den Headern. Da fragt man sich schon, was das soll.
Ok, das passiert, wenn man Kernkonzepte wie Kapselung irgendwo dranschustert.
Aber jetzt mal ne konstruktive Frage: Gibt es ein Tool, mit dem man eine Anbindung von C/c++ bibliotheken zu D bauen kann?
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 05. Feb 2010 um 20:06.D benutzt nämlich Module.
D kann doch C Bibliotheken direkt verwenden.
Lediglich für C++ Bibliotheken müßtest du dir etwas überlegen.
Danke.
Hmja, man kann ja so komische Übergänge für C entwickeln, die man dann in D verwendet. SFML macht das anscheinend so.
Eine private Variable heißt privat weil man nicht auf sie zugreifen können soll, nicht, weil man nichts von ihrer Existenz wissen soll.
Möglicherweise, aber übersichtlicher wird der Header dadurch nicht.
Welche Vorteile bietet ein Header gegenüber Modulen?
Keine das ist lediglich historischer Ballast aus der Zeit einer Rechen- und Speicherbegrenzten PDP-7 Kiste.
> Keine das ist lediglich historischer Ballast aus der Zeit einer Rechen- und Speicherbegrenzten PDP-7 Kiste.
Natürlich gibt es Unterschiede. Mithilfe von Headern ist es möglich, so etwas wie die Trennung von Deklaration und Definition vorzunehmen. Angenommen, Du hast zwei Bibliotheken, die die gleichen Klassen grundverschieden implementieren und eine Anwendung, die diese Klassen verwendet.
Du compilierst Deinen gesamten Anwendungscode gegen einen Satz Headerfiles. Damit wird es möglich, die Entscheidung, welche der beiden Bibliotheken zur Verwendung kommt, erst ganz am Ende, zur Link-Zeit, zu treffen.
lg
Erik
Ich kann deine Argumentation absolut nicht nachvollziehen. Ich kann ja z.B. in Java auch gegen die eine SAX Implementierung programmieren obwohl am Zielsystem eine andere zur Verfügung steht (welche die selben Features bietet). Das Konzept der Schnittstelle einer Bibliothek hat nix mit Headern zu tun.
Aber warum müssen auch die privaten Attribute im Header stehn? Ganz einfach, weil der Kompiler das Speicherlayout der Klassen kennen muss. Überall wo ein new steht oder schlimmer noch ein Objekt am Stack angelegt wird muss der Kompiler wissen wie groß das Objekt ist. Und wenn irgendwo auf ein (auch nicht privates) Attribut zugegriffen wird muss der Kompiler den Offset dieses Attribut kennen. Das kann er nur kennen wenn er weiß wie viele und wie große Attribute im Objekt vor kommen und wie diese sortiert sind.
Wenn man Objekte nur über new anlegen können würde dann könnte man zumindest die Größe des Objekts in eine Methode herausheben (allocator). Aber C++ kann Objekte ja auch am Stack anlegen und muss zumindest dort schon zur Compiletime die Größe kennen. Bei Java ist das anders. In Java gibts nur new. Theoretisch könnten jedoch JVMs den Controllflow analysieren und Objekte, die garantiert nur so lange leben wie die Methode in der sie erzeugt werden am Stack anlegen und nicht dem Garbage Collector überlassen (z.B. oft bei StringBuilder/StringBuffer). Das würde gehen weil Java einen JIT hat un erst den endgültigen nativen Code generiert wenn die entsprechende Klasse geladen wurde und die JVM somit das Speicherlayout/Größe der Klasse kennt. (Würde die Klasse entladen und aus anderer Quelle neu geladen werden müsste nochmal der JIT angeworfen werden. Aber ich glaub zu so einen Fall wirds wohl nicht kommen, da die Klasse mit dem neu zu JITeten Code ja noch eine Referenz auf den z.B. StringBuilder hält und somit wird die Klasse auch nicht entladen.) Und auch in Java sind die privaten Attribute "sichtbar". Man kann sie per Reflection auflisten und wenn das Programm nicht in einen speziellen Security Context (z.B. Sandbox) läuft, können private Attribute auch ausgelesen und gesetzt werden (ebenfalls per Reflection).
Sprich es hat einen guten Grund warum private Attribute im Header stehn. Wer sich über so etwas wundert sollte mal Konzepte des Kompilerbau wiederholen.
> Ich kann ja z.B. in Java auch gegen die eine SAX Implementierung programmieren obwohl am Zielsystem eine andere zur Verfügung steht
Das ist halt der Punkt: Du brauchst mit Headern zum Programmieren noch nicht einmal eine Implementierung. Ein Textfile mit ein paar Forward-Deklarationen, schon kompiliert Dein Sourcefile zu einem Objektfile.
Das man das nutzen kann um gegen mehrere Libs linkbar zu sein, solange sie die API des Headerfiles erfüllen, ist lediglich eine denkbare Anwendung dafür. Mock-up prototyping wäre eine andere, die ich persönlich zum Beispiel recht gern nutze.
> Aber warum müssen auch die privaten Attribute im Header stehn?
Das wurde doch schon weidlich diskutiert.
> oder schlimmer noch ein Objekt am Stack angelegt wird
Daran ist gar nichts schlimmes.
lg
Erik
lg
Erik
Das geht aber auch wenn der Kompiler selbst die API aus der Sourcecode entnimmt wie bei D, Pascal, Eiffel oder Java.
Händisch verwaltete Headers sind einfach nur schlecht, kompliziert, fehleranfällig und auch insbesondere langsam.
> Das geht aber auch wenn der Kompiler selbst die API aus der Sourcecode entnimmt
Und wenn auch mein Code schon geschrieben ist, muss ich morgens gar nicht erst aufstehen. Auch richtig, geht aber ebenfalls an der Grundaussage vorbei.
Header sind deklarative Konstrukte, sie haben doch gerade den Sinn, dass man den Code an sich nicht zur Verfügung haben muss.
> Händisch verwaltete Headers sind einfach nur schlecht, kompliziert, fehleranfällig
Man kann sich auch dumm anstellen.
> und auch insbesondere langsam.
Also die anderen Argumente lasse ich ja noch unter "Geschmackssache", "Designphilosophie" oder ähnlichen Stichworten durchgehen, langsamer ist es mit Headern aber definitiv nicht. Ob Du die Symbolinformationen nun aus einem oder einem anderen Format entnimmst, ist diesbezüglich vollkommen irrelevant.
lg
Erik
Private Variablen/Member stehen drin, damit der Compiler weiß, wieviel Speicherplatz ein Objekt der Klasse braucht (deswegen können Klassen der privaten Member auch nicht nur forward deklariert sein).
So könntest Du in Deinem Code z.B. kein sizeof() machen von einer Klasse aus einer anderen Bibliothek oder ein Objekt davon anlegen.
Das könnte er aber auch wissen wenn er einfach den source code zusätzlich parst. Genau wie private virtuelle Methoden.
Und wie diese völlig merkbefreiten Forward Declarations. Nur weil das Drecksding immer noch ein single parse compiler ist der nicht weiss was 3 zeilen später passiert.
Ach muss meinen Blutdruck wieder runtergehen lassen - C++ ist einfach Drecksmist.
Tja, klingt, als wurdest Du gezwungen, c++ zu benutzen oder einen Compiler zu entwickeln.;)
Oh, OT: Ich muss eine Fehlinformation richtig stellen, die ich in den Umlauf gebracht habe. Irgendwo in den PyGame Docs stand, dass die Performance von PyGame so grottig sei, dass man damit keine Anwendungen bauen könnte, bei denen der ganze Bildschirm neugezeichnet wird, was ich bei der LÖVE-Nachricht mal erwähnt hatte.
Nun meinte Kiba aus dem Forum von Freegamer dass das Ganze weder mit PyGame noch mit RubyGame ein Problem sei, selbst mit einem 1Ghz Rechner käme er damit auf eine brauchbare Framerate, obwohl PyGame kein OpenGL benutzt. Wahrscheinlich sind einfach die Dokumente veraltet.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 06. Feb 2010 um 00:08."source code zusätzlich parst"
Haha, dann bräuchtest Du ja für alle Bibliotheken, die Du in Deinem Code verwendest, auch die Quellen. Scheint wohl nur unter Linux unterwegs, auch nett.
C++ Drecksmist? Und dann mit Begriffen wie Single-Parse-Compilern um Dich werfen? Lebenslanges Lernen scheint angesagt...
Vielleicht meint Lothar ja den Quelltext der vorliegenden Datei. Würde ja auch Sinn machen, im Sinne von welche "Verbindungen" der Compiler zu den Klassen/Variablen der Bibliothek bauen muss. Private Sachen würden halt keine Verbindung bekommen.
Nur so ne Theorie. Nicht, dass ich mich mit Compilern groß auskennen würde.
Um zum Beispiel eine statische Instanz einer Klasse auf dem Stack anzulegen, musst Du deren Layout ja vollständig zur Compile-Zeit kennen. Deshalb müssen auch alle Datenmember Bestandteil der Deklaration sein - und deren Datenmember in deren Deklaration. Oder eben auch allgemein, um die Größe einer Instanz oder den Offset von Membern zu kennen.
Wenn Du gern ganz privat mit deinen privaten Datenstrukturen sein willst, mache es doch wie die KDE-Entwickler: In die Deklaration packst Du einen Pointer auf eine private Datenstruktur, die Du in lediglich benennst. Das funktioniert,. weil auf einer Plattform die Breite eines Pointers fest und daher zur Compile-Zeit bekannt ist. In der Implementierung schließlich legst Du im Konstruktor eine dynamische Instanz Deiner dort vollständig bekannten privaten Klasse an und referenzierst einfach deren Member.
lg
Erik
Na super, dann operiert man also bei KDE das Gehirn nicht durch den Arsch (GObject) sondern durch den Bauchnabel.
Es wurde doch bereits weidlich diskutiert, warum es Vorteile haben kann, Header zu verwenden und warum ich dann auch private Strukturmember im Header deklarieren muss. C++ ist nun einmal eine Programmiersprache, die Headerdeklarationen unterstützt und nutzt.
Bestimmte Designentscheidungen haben eben Konsequenzen, mit denen man leben muss. Darüber kann man sich jetzt echauffieren oder ersatzweise Sprachen verwenden, die eine andere Herangehensweise haben. Vielleicht solltest Du letzteres in Betracht ziehen.
lg
Erik
Ja ja sollte "Single-Pass" Compiler heissen, aber diesen Typo sollte iegentlich jeder erkennen der was von Compilern versteht.
Und das C++ kein Drecksmist ist sagen nur Leute mit weniger als 10 Jahren C++ Erfahrung.
Ich habe mehr als 10 Jahre C++-Erfahrung. C++ ist kein Drecksmist.
lg
Erik
Dann hast du noch nicht genug Erfahrungen mit C++. Nach 10 Jahren C++ ist man noch in der Begeisterten-Phase, weil man stolz ist, dass man Template-Metaprogramming durchstiegen hat und man vermurkste Dinge, die man hart erlernt hat toll findet, weil ist ja "mächtig" (TM). Wart's ab, du wirst C++ auch noch hassen lernen.
"If you like C++, you don't know C++. There's a mutual exclusion going on here, and I've yet to see a counter-example other than possibly a few of the members of the standards committee."
C++ ist, man staune, so wie jede andere Sprache nicht perfekt. Sie hat ihre Ecken und Kanten.
Und genau hier liegt der Unterschied zu den Leuten, die immer an ihrem Platz stehen bleiben werden, obwohl sie sich bewegen und die Zeit fortschreitet.
Trotz oder genau wegen seiner - von vielen gehassten - Nachteile hat man die Möglichkeit das Beste aus der Sprache rauszuholen. Man hat weiterhin die Möglichkeit Tugende wie Geduld oder gar Beharrlichkeit zu entwickeln, die sich auf das übrige Leben positiv auswirken. Hassen bringt einen also nirgends weiter.
Wie will man sonst die Nachteile einer Sprache erkennen, wenn man 'die vermurksten Dinge' nicht begreift? Obwohl ich das Wort Nachteile durch Schwächen ersetzen würde.
Wenn man mit der Zeit eine Zuneigung zu der Sprache entwickelt, weil man die Sprache besser beherrscht oder Teile davon verstanden hat und diese Zuneigung Liebe nennt, dann ist es doch perfekt! Wird man auch noch mit den Schwächen der Sprache besser vertraut und versteht sie zu hantieren, dann hat man sich weiterbewegt. Unabhängig von Zeit um Raum.
> Dann hast du noch nicht genug Erfahrungen mit C++. Nach 10 Jahren C++ ist man noch in der Begeisterten-Phase
Es sind bereits mehr als 10 Jahre. Aktuell sind es genau genommen 14 Jahre. Davor mehrere Jahre andere Programmiersprachen.
> Wart's ab, du wirst C++ auch noch hassen lernen.
Ich kenne die Tiefen von C++ bereits. Die Vorteile sind jedoch unbestreitbar und - je nach Kontext - verglichen mit den sogenannten "Alternativen" unverzichtbar. Es gibt einfach Umgebungen, in denen Du das Layout des Speichers, die Architektur, das Footprint Deines Codes, das Verhalten des Compilers und andere Spezifika genau kennen musst. Hier gibt es einfach keinen Ersatz zu C/C++.
lg
Erik
> Hier gibt es einfach keinen Ersatz zu C/C++.
Doch, D!
http://en.wikipedia.org/wiki/D_%28programming_language%29
D 2.0 braucht zwar noch ein bischen, aber so lange ist der Weg auch nicht mehr.
Und die Compiler werden auch immer besser.
Rein von der Sprache her ist D aber unglaublich elegant und schön.
Es macht einfach Spaß damit zu programmieren.
Ich finde D auch sehr nett, die Aussage, dass es aber (noch) kein Ersatz ist, stimmt aber.
lg
Erik
Ja kommt drauf an, wo man es einsetzt. In der Systemprogrammierung hat es sicher noch einen festen Platz. Aber für GUI-Desktopanwendungen ist es wohl denkbar ungeeignet...
Ich kann zwar mittlerweile nicht mehr sagen, dass ich C++ besonders mag, aber so schlimm finde ich es auch nicht. Manchmal kommt man halt nicht drum rum...
Aber für GUI-Desktopanwendungen ist es wohl denkbar ungeeignet...
Ja ist sie, aber jetzt komm mir bitte nicht mit den anderem Müll der sich C# und Java nennt.
Es gibt auch ein Leben ausserhalb der heiligen Dreifaltigkeit.
Ich würde alle 3 Sprachen jedenfalls nicht nutzen. Schade nur das es keinen MFC Wrapper für Objective-C gibt, nichtmal einen vernünftigen Objective-C Compiler.
Daher nehme ich auch weiterhin Eiffel für alle GUI Anwendungen.
Es ist einfach, private Variablen in Headern zu vermeiden, wenn man das denn für nötig hält (in der Regel ist es das nicht, da man sie zwar sehen, aber nicht in irgendeiner Form darauf zugreifen kann). Dazu deklariert man in der Headerdatei eine abstrakte Basisklasse, die das Interface spezifiziert. Außerdem braucht man noch eine statische Methode, die dazu dient, Instanzen der Klasse zu erzeugen:
class B {
public:
virtual void f() = 0;
static B *create();
};
In der Implementierungsdatei leitet man von dieser Basisklasse die Klasse ab, die das Interface implementiert.
class D : public B {
public:
void f() {
//Code hier
}
};
B *B::create() {
return new D();
}
Und schon hat man alle private-Variablen aus den Headern entfernt.
http://chaosradio.ccc.de/cre114.html
http://www.dsource.org/projects/ldc
Leider ist diese D Backend genau wie der Rest von D sowas von Buggy das du schon mit dem Klammerbeutel gepudert sein müsstest um damit ernsthaft eine Mission Critical Anwendung zu schreiben.
D's Drang besser zu sein als C/C++ um sich damit endlich mal zu etablieren führt leider zum Gegenteil. Hoffentlich wird nach D 2.0 endlich mal 5 Jahre ein Sprachweiterentwicklungsverbot verhängt - ähnlich wie bei Python 3
Dieses D Backend ist ja auch noch in Entwicklung.
D 2.0 gibt es deswegen, weil es bei D 1.0 dazu kam, daß neben der Standardlibrary noch eine zweite von der Community entwickelt wurde, die genau das gleiche macht, nur halt auf eine andere Weise.
Das eigentliche Problem dabei war nur, daß man nicht beide gleichzeitig verwenden kann, da sie inkompatibel zueinander sind.
Mit D 2.0 ist nun geplant, diese zu vereinen.
Und dann gibt's natürlich hier und da noch ein paar kleinere Verbesserungen für D 2.0.
Was aber für D 2.0 viel wichtiger wäre, wäre meiner Meinung nach, daß man D in etwas anderes umbennt, z.B. D++, damit man danach auch suchen kann ohne Ständig "Programming Lanuage" dem Suchmuster hinzuügen zu müssen.
Und bevor ich es vergesse.
Wenn du ein paar kleinere Programme mit D schreiben willst, dann nimmst du moment besser den Compiler von Digital Mars, denn der ist ausgereift.
Zumindest gilt das für D 1.0.
Gerüchte behaupten, den gäbe es nur für 32-bit.