An welchen Großprojekten seid ihr dran??

[M@tes]

Auszug aus nem anderen Thread:

Bin jetzt an einem Projekt der Extraklasse dran (für mich! Für andere is das vllt Kindergarten.. Es übersteigt meine bisherigen Projekte bei weitem).
Derzeit schreibe ich sowas wien Kernel für meine späteren Projekte.
Der Kernel managet User, Daten/Datenbank und Progamme. Auf diesem wird später alles aufbauen. Reinquelltext rechne ich mit rund 50Kb ohne Oberfläche (Dialoge, Textfelder..). Mit diesem will ich unter anderem auch eine WissensDB aufziehen. Einigen Usern/ Gruppen kann man die Rechte für ein Programm zuweisen aber z.B. Teile vom Programm verweigern (für Adminfunktionen z.B.). Es soll alles vernetzt werden.
Will unteranderem ein Bot schreiben, den User anlernen können. Unteranderem soll dann die Glaubwürdigkeit einzelner User verglichen werden. Dieser Bot könnte z.B. im Forum schon gestellte Fragen beantworten...
Grobe Entwürfe hab ich schon.
Ein Forum hab ich schonmal geschrieben, das is noch relativ leicht, jenachdem welche Funktionen man einbauen will. Der Bot wird schonn wenig schwieriger. Mal schaun ob es so funktionieren wird, wie ich es will. Aber ich weiche vom Thema ab.

[Gast]

Ich kann dir nur sagen dass 50KiB kein Großprojekt ist ;)

[Gnafoo]

Und ich kann nur sagen, dass die Speichermenge welche der Quellcode benötigt ein dämliches Maß für die "Größe"/den Aufwand eines Projektes ist. ;) Und @Gast M@tes sagte ja explizit, dass es für ihn ein großes Projekt sei und für andere evtl. gar nicht. Ist doch ok.
@Topic: Im Moment gar nichts.

Btw. Es heißt "Großprojekt". Wenn ein Mod mal Zeit hat, wäre es nett, wenn er den Titel korrigieren könnte.

[Gast]

Btw. Es heißt "Großprojekt". Wenn ein Mod mal Zeit hat, wäre es nett, wenn er den Titel korrigieren könnte.in der Schweiz ist die Schreibweise korrekt!

[Kabelsalat]

Da ich keine vernünftige Backup-Lösung für Windows-Server (kostengünstig) gefunden habe, arbeite ich nun selber an einer solchen. Hauptsächlich ist das Projekt aber dem Übungszweck gewidmet und daher versuche ich das ganze so gründlich und ordentlich wie nur irgendwie möglich zu erstellen: Ich achte darauf sorgfältig zu kommentieren (nicht zu viel und nicht zu wenig), auch die konsequente Verwendung von XML-Dokumentationskommentaren gehört dazu. Obendrein habe ich mich auch in Unit-Tests eingearbeitet und versuche diese vernünftig einzusetzen.

Das Ziel besteht letztenlich darin eine Backuplösung zu haben, die auf aktuellen Technologien aufbaut (z.B. XAML und .Net 3) und die folgende Rahmenpunkte berücksichtigt.
-> Flexible Add-IN Struktur ähnlich SharpDevelop
-> Unterstützung von ACLs (Access-Control-Lists)
-> Berücksichtigung von Junction-Points (Soft-Links), Hard-Links und weiteren (NTFS) Dateissystembesonderheiten wie Streams etc.
-> Integrierte Backuplösung für Datenbanken. Zunächst sollen MySQL und MsSQL unterstützt werden (zumindest letzteres ist einfach zu realisieren)
-> Sowohl lokales als auch remote Backup möglich. Bei einem Remote-Backup besteht zusätzlich noch die Anforderung, dass darauf verzichtet werden soll, das Backup zunächst temporär auf dem lokalen Rechner zwischenzuspeichern (auch bei einem FTP-Server als Backupziel).
-> Sofern ich mit den bisher genannten Punkten jemals fertig werden sollte, werde ich versuchen das Projekt auch unter Mono und Linux zum laufen zu bewegen. Durch das Add-In-System sollte es ohne weiteres möglich sein Windows-Spezifische Komponenten (die dafür u.a. mehr Komfort bieten können) gegen Platformunabhängige Varianten auszutauschen.

[Djon]

Hallo!!!

Ich bin zur Zeit an der Entwicklung einer Personaleinsatzplanungssoftware beteiligt. Wir haben insg. 5 Entwickler im Team, ich würde es aber von der Grösse her doch wohl als "mittel" bezeichnen. Für mich sind Grossprojekte solche Projekte, wo mehrere Dutzende Mitarbeiter daran beteiligt sind.


Mfg Djon

[Gast]

ich schreib grad nen kleinen C++-Compiler

[Gast]

Mit export Support nehm ich an, oder?

[Gast]

na klar!

[M@tes]

Gast: Der Kernel ist nur ein Teil vom Projekt... Halt der schwierigste.
Hab schon mal ein Forum geschrieben, mit 300Kb Aber is nie fertig geworden, weils eben mehr ein Provisorium war und gewisse Erfahrungen gefehlt haben.
Weiss ja nicht, was ihr unter Reinquelltext versteht.. Ich versteh darunter: alles Kopieren in TextDatei kopieren und Dateigrösse angucken.
VB C++ Projekte brauchen glaubs mehr Speicher als der QUelltext selber gross is oder nich? Kenn mich da nich so aus.

Gast: Ja in der Schweiz hat man kein scharfes S. In demm Fall stimmt das ss :smile: *in der Schweiz wohne*

Djon: Naja für einzelne Personen sind "Mittelgrosse" Projekte von mehreren Leuten eher ein Grossprojekt.

[Gast]

Ich bin momentan dabei eine 3D-Engine zu schreiben mit allem drum und dran. Ich hab mir dabei zum Ziel gesetzt möglichst die Algorithmen etc. zu optimieren und alles in reinem C zu schreiben damit es schön schnell wird. Mal sehen, vielleicht wird daraus ja irgendwann ein Spiel. Da ich ein paar Monate gar nicht daran gearbeitet habe und auch erst seit einem Monat wirklich daran arbeite (neue Graffikkarte gekauft :-)), habe ich noch nicht viel beisammen. Aber immerhin: es sind schon 85kb quelltext ;-)

[tokugawa]

Ich bin momentan dabei eine 3D-Engine zu schreiben mit allem drum und dran. Ich hab mir dabei zum Ziel gesetzt möglichst die Algorithmen etc. zu optimieren und alles in reinem C zu schreiben damit es schön schnell wird. Mal sehen, vielleicht wird daraus ja irgendwann ein Spiel. Da ich ein paar Monate gar nicht daran gearbeitet habe und auch erst seit einem Monat wirklich daran arbeite (neue Graffikkarte gekauft :-)), habe ich noch nicht viel beisammen. Aber immerhin: es sind schon 85kb quelltext ;-)

OK, da ich schon ca. 7 Engine(-versionen) (5 OpenGL, 2 DirectX9) geschrieben habe, hier ein Tipp: eine gute Engine zeichnet nicht die Geschwindigkeit aus, sondern die Wartbarkeit des Codes (das wirft reines C meistens schon mal aus dem Ring), die Erweiterbarkeit sowie die Tools dafür (Toolchain, also wie gut man 3D-Content aus 3D-Programmen in die Engines bekommt, und wie gut die Tools dafür sind).

Im Endeffekt sollte man mit einer guten Engine innerhalb einer Woche einen Spielprototypen schaffen können.

(Grob gezählt hat meine derzeitige Engine, die ich für meine Diplomarbeit geschrieben habe, an die 3-5 MB Quelltext, wobei allerdings die Hälfte sicher an die Doxygen-Dokumentation im Quellcode draufgeht - wobei das auch ein guter Punkt ist, dokumentieren/kommentieren ist auf jeden Fall auch ein Zeichen einer guten Engine - selbst wenn man sie nur selbst benutzt. Ich hab auch schon mal ein halbes Jahr Pause gemacht, und dann nicht mehr genau gewußt, wo was ist. Wenn du das noch dazu in reinem C schreibst, wird das sicher noch viel komplizierter)


Um zum Thema zu kommen: alles was ich als Großprojekt definieren würde, würde wohl sowieso unter eine NDA fallen, und damit könnten die Leute, die tatsächlich an Großprojekten arbeiten, sowieso nicht posten, an welchen sie gearbeitet haben.

[RMC]

Das nächste Projekt wird im Rahmen meiner Ausbildung wieder ein 3D Spiel, aber diesmal wahrscheinlich kein Multiplayer sondern eher eine Singleplayer Kampagne.

[Gast]

Wenn du das noch dazu in reinem C schreibst, wird das sicher noch viel komplizierter)
wenn mans objektorientiert schreibt, ist es noch halbwegs nachvollziehbar - aber auf inline assebler würde ich dann doch eher verzichten...

[Kabelsalat]

wenn mans objektorientiert schreibt, ist es noch halbwegs nachvollziehbar - aber auf inline assebler würde ich dann doch eher verzichten...

... wie willst du in reinem C objektorientiert schreiben?

[UliBär]

Java-Internet-Application Projekt, Quellcode ~60 MByte, wird konzern-/weltweit eingesetzt.
Groß genug? =)

[Gast]

... wie willst du in reinem C objektorientiert schreiben?
variablen in structs zusammenfassen und funktionen ensprechend benennen.

new_object() liefert ein struct zurück.

object_tu_was(object o) kriegt eine instanz als erstes argument.

bei vererbung wirds zwar etwas komplizierter, geht aber...

[Kabelsalat]

Ist aber alles andere als OOP...

[Gast]

Das ist sehr wohl OOP. Eine Programmiersprache muss ein Paradigma nicht unbedingt unterstützen um es zu verwenden.

[tokugawa]

Das ist ein OOP-Hack :) alles andere als schön.

Dass man C-Code auch übersichtlich schreiben kann, glaub ich schon, aber bei Projekten die größer werden ist der Aufwand, C zu "OOPifizieren" langsam höher als gleich auf C++ zu setzen. Vor allem macht's keinen Sinn wenn's sowieso C++ gibt.

Vor allem fehlt mir dann trotzdem die Kapselung von Methoden in Klassen. Das müsste man dann über Funktionen im "global scope" machen, die pro Typ implementiert werden, und die damit den global scope verschmutzen (namespaces gibt es ja nicht).

Weiters fehlen mir dann die Templates auch. Die kannst vielleicht irgendwie mit Macros nachbauen, aber schön wird das nicht.

[Kabelsalat]

OOP ist es schon deshalb nicht, da du dein Struct wiederum an eine globale Funkion übergibt, die bei striktem OOP nichteinmal exisitieren dürfte. Aber :btt:

[tokugawa]

Es fehlen außerdem weitere wichtige Aspekte wie Kapselung (dazu gehört dass Methoden Teil einer Klasse sind, sowie dass man Teile "verstecken" kann, Stichwort protected/private), ich bezweifle auch dass sich Vererbung sich wirklich implementieren lässt (klar, mittels "Aggregation" kann man sowas ähnliches machen, das ist aber explizit etwas anderes), und auch Polymorphismus scheint es nur dann zu geben wenn man alles auf einen unglaublich häßlichen (und unsicheren) (void*) Pointer castet.

Alles in allem nur ein Hack-OOP, von echtem OOP ganz weit entfernt. Vor allem da gerade für Design Patterns OOP-Features compiler/sprachenseitig nutzbar sein müssen, d.h. ein Hack reicht da nicht aus, um Design Patterns so umzusetzen dass sie ihre teilweise "Automatik dank der Sprachfeatures" behalten.

[Gast]

OOP ist es schon deshalb nicht, da du dein Struct wiederum an eine globale Funkion übergibt, die bei striktem OOP nichteinmal exisitieren dürfte. Aber :btt:

Nochmal: OOP setzt keine Sprachfeatures vorraus.
Objektorientierte Programmierung (OOP) setzt die Objektorientierung in der Erstellung von Computerprogrammen um. Dabei werden zusammengehörige Daten und die darauf arbeitende Programmlogik zu Einheiten zusammengefasst, zu den so genannten Objekten.

Dafür brauchst du keinen Sprachsupport. Es ist einfach nur ein Paradigma, das in heutigen Sprachen natürlich auch direkt unterstützt wird.

[Kabelsalat]

Um dieses Paradigma wie du es bezeichnest voll umsetzen zu können, fehlen aber schlichtweg einige grundsätzliche Elemente. Siehe auch tokugawas Post.

[HellHorse]

... wie willst du in reinem C objektorientiert schreiben?
ObjVLisp. Ist zwar alles andere als effizent oder elegant aber definitiv OOP.
Und was der Gast als OOP ausgibt zählt nicht, da es definit nicht OOP nach Kay ist (message passing, late binding). GObject kenne ich zu wenig, ist aber hässlich und ineffizent, von dem her könnte es schon OOP sein. ;D

Allgemein zu "C damit es schnell ist":
Gnome Applikationen sind (meist) in C geschrieben, haben sehr lange bis sie gestartet sind und brauchen sehr viel Speicher.

[tokugawa]

Nochmal: OOP setzt keine Sprachfeatures vorraus.

Dafür brauchst du keinen Sprachsupport. Es ist einfach nur ein Paradigma, das in heutigen Sprachen natürlich auch direkt unterstützt wird.

Und genau die Zusammenfassung von Programmlogik und Daten in "Objekte" bzw. Klassen gibt es in C nicht. Die Funktionen bleiben weiterhin außerhalb der "structs".

OOP setzt theoretisch keine Sprachfeatures vorraus, was aber nicht heißt dass man in C nach OOP-Paradigma programmieren kann. Es heißt nur, dass es theoretisch eine Nicht-(primär-)OOP-Sprache geben kann, die OOP-Features ermöglicht. C gehört nicht dazu.

In C würde aufgrund fehlender Compiler-seitiger Unterstützung (etwa Respektierung von Sachen wie "protected") einige Design Patterns nicht mehr funktionieren. Beispiel: wie verhinderst du den Zugriff auf ein struct-Element (ähnlich protected) in C mittels statischer Analyse (d.h. zur Compilezeit)?

Somit ist das im besten Fall "broken OOP", oder wie ich es bereits bezeichnet hab "Hack-OOP" mit allen Nachteilen, aber ohne die Vorteile von OOP.

[Trap]

In C würde aufgrund fehlender Compiler-seitiger Unterstützung (etwa Respektierung von Sachen wie "protected") einige Design Patterns nicht mehr funktionieren. Beispiel: wie verhinderst du den Zugriff auf ein struct-Element (ähnlich protected) in C mittels statischer Analyse (d.h. zur Compilezeit)?
Sourcecode wird vorm kompilieren an den Zugriffsschutzbeauftragten gemailt und nur nach dessen OK wird der Code kompiliert (das ist zumindest zu 1/3 ernst gemeint).

[tokugawa]

Sourcecode wird vorm kompilieren an den Zugriffsschutzbeauftragten gemailt und nur nach dessen OK wird der Code kompiliert (das ist zumindest zu 1/3 ernst gemeint).

Das würde, wenn du mit Zugriffsschutzbeaufragten einen (beliebigen, damit meine ich nicht unbedingt Macros) Präprozessor meinst, für mich genauso zur "Compilezeit" zählen. Oder genauer "Buildzeit".

[Demirug]

Diese Technik hat einen eigenen Namen. Man spricht hierbei von ADTs (Abstrakten Daten Type). Ich habe hier ein Buch rumliegen in dem noch mehr solcher Exoten beschrieben sind.

[tokugawa]

Diese Technik hat einen eigenen Namen. Man spricht hierbei von ADTs (Abstrakten Daten Type). Ich habe hier ein Buch rumliegen in dem noch mehr solcher Exoten beschrieben sind.

Abstrakte Datentypen (ADTs) sind ja auch ein Element in der generellen Algorithmik (z.B. "Lineare Liste" ist ein ADT). Müssen nicht OOP-artig gelöst werden, können aber, sind in gewissem Maße auch eine "Paketisierung" von Algorithmen und Datenstrukturen, also ein ähnliches Ziel wie OOP - aber eben nicht ganz OOP.

[Trap]

Das würde, wenn du mit Zugriffsschutzbeaufragten einen (beliebigen, damit meine ich nicht unbedingt Macros) Präprozessor meinst
Ich meinte einen Mensch der das macht. Man muss nicht immer alles über Automatisierung lösen, regelmäßige Sourcecodereviews können ein genauso wirkungsvolles Mittel sein um Zugriffsschutz zu implementieren. Das ist dann zwar nicht in der Programmiersprache vorhanden, aber im Softwareerstellungsprozess durchaus.

Das geht genauso für die meisten anderen Features, die Frage ist ob es sich in irgendeiner Hinsicht lohnt so Software zu entwickeln.

[Gast]

Allgemein zu "C damit es schnell ist":
Gnome Applikationen sind (meist) in C geschrieben, haben sehr lange bis sie gestartet sind und brauchen sehr viel Speicher.
Ich glaube nicht dass sie deshalb solange starten weil sie in C geschrieben sind. Hängt eher von der Programmierung ab. Und die Aussage, dass ein C-Programm mehr Speicher braucht als C++ under sonstwas glaub ich nicht. Wo sollte dafür der Grund liegen. Und wenn ich Benchmarks zwischen optimierten C und optimierten C++ - Programmen mache sind die C Programme schneller, weil die Sprache einfacher aufgebaut ist und somit auch leichter vom Compiler kompiliert werden kann. Sicherlich, es gibt bestimmt ein C++-Programm, dass genauso schnell läuft wie das dazugehörige C-Programm. Allerdings weißt dieses dann ein so ähnliche Struktur auf dass C++-Programmelemente gar nicht mehr benötigt werden, und somit direkt in C programmiert werden kann.
Sonst wüsste ich nicht in welche Sprache noch "schnell" ist. Eine "Compiler-Sprache" muss es ja auf jeden Fall sein, alles andere ist langsam (java, python, etc.).
Somit hab ich mich halt dafür entschieden in reinem ANSI C zu programmieren. Ich greifen dabei auch gerne mal auf die "structs" zu, wobei ich das nicht direkt objektorientierte Programmierung nennen will, von der ich aus Geschwindigkeitsgründen sowie abstand nehme.


Und wenn mir hier gesagt wird, dass ich bei ein 3D-Engine eher auf schönen und leserlichen Quelltext achten soll, dann darf man sich nicht wundern das die Engine mit allen Effekten nur auf 4GHz Dualcore mit 7900GTX oder ähnlichem läuft. Nicht umsonst laufen moderne Spiele immer nur auf den neuesten PCs gut. Mit ein paar Algorithmenverbesserungen und sonstigen Optimierungen des Quelltextes könnte man sicher noch einiges an Frames rausholen.

[ollix]

Ich glaube nicht dass sie deshalb solange starten weil sie in C geschrieben sind. Hängt eher von der Programmierung ab. Und die Aussage, dass ein C-Programm mehr Speicher braucht als C++ under sonstwas glaub ich nicht. Natürlich, aber eben auch nicht andersrum. Ein Programm braucht nicht wenig Speicher und ist schnell nur weil es in C geschrieben wurde (ganz egal wie).

[tokugawa]

Ich meinte einen Mensch der das macht. Man muss nicht immer alles über Automatisierung lösen, regelmäßige Sourcecodereviews können ein genauso wirkungsvolles Mittel sein um Zugriffsschutz zu implementieren. Das ist dann zwar nicht in der Programmiersprache vorhanden, aber im Softwareerstellungsprozess durchaus.


Der Mensch übersieht allerdings leicht Sachen.

Was ich meine ist: eine elegante Methode um z.B. Erstellung von Objektinstanzen auf dem Stack zu verhindern, ist es wenn man den Destruktor "protected" macht. Damit kannst du schon By-Design zur Compilezeit (statische Analyse) verhindern, dass dieses Objekt statisch instanziiert wird.

Bei einem "menschlichen Codereview" davor hast du diese Sicherheit nicht. Das ist also weder dasselbe, noch ist es genauso "sicher".


Ich glaube nicht dass sie deshalb solange starten weil sie in C geschrieben sind. Hängt eher von der Programmierung ab. Und die Aussage, dass ein C-Programm mehr Speicher braucht als C++ under sonstwas glaub ich nicht. Wo sollte dafür der Grund liegen. Und wenn ich Benchmarks zwischen optimierten C und optimierten C++ - Programmen mache sind die C Programme schneller, weil die Sprache einfacher aufgebaut ist und somit auch leichter vom Compiler kompiliert werden kann.


Das hat aber nur was mit Compile-Zeit zu tun, nichts mit Laufzeit. Außerdem lassen sich C++ üblicherweise in C-Code kompilieren (bestimmte Multi-Pass C++ Compiler machen das). Optimierung von kompiliertem Code erfolgt ja sowieso nicht auf der Syntaxebene, sondern in der Zwischencodedarstellung - da isses schon egal ob es C++ oder C ist.

Der einzige Grund warum C++ als "langsamer" oder "bloated" gilt, liegt daran, dass virtuelle Methodenaufrufe geringfügig länger brauchen als wenn man eine Funktion aufruft. Das ist gerade bei Spielen aber selten der Flaschenhals. Weiters gibt es natürlich Dinge, die durchaus Resourcen (Performance, Speicher) fressen, wie etwa Runtime-Type-Information, oder Exceptions.


Sicherlich, es gibt bestimmt ein C++-Programm, dass genauso schnell läuft wie das dazugehörige C-Programm. Allerdings weißt dieses dann ein so ähnliche Struktur auf dass C++-Programmelemente gar nicht mehr benötigt werden, und somit direkt in C programmiert werden kann.


Wie gesagt, der Unterschied aufgrund der virtuellen Funktionsaufrufe ist gerade in Spielen genau 0.


Sonst wüsste ich nicht in welche Sprache noch "schnell" ist. Eine "Compiler-Sprache" muss es ja auf jeden Fall sein, alles andere ist langsam (java, python, etc.).


Auch gerade für Spiele sind python und Java durchaus Alternativen (gerade mit Just-In-Time-Compiling), weil der Flaschenhals ganz einfach woanders liegt. Es gibt praktische Beispiele dafür, dass auch Java oder C# für Spiele geeignet ist.


Somit hab ich mich halt dafür entschieden in reinem ANSI C zu programmieren. Ich greifen dabei auch gerne mal auf die "structs" zu, wobei ich das nicht direkt objektorientierte Programmierung nennen will, von der ich aus Geschwindigkeitsgründen sowie abstand nehme.


Wie gesagt, wenn du ein Spiel programmierst, ist dieses Argument nichtig, weil das Performance-Penalty für virtuelle Funktionsaufrufe sowieso schon gering ist, und in Spielen sowieso von anderen Flaschenhälsen verdeckt wird.


Und wenn mir hier gesagt wird, dass ich bei ein 3D-Engine eher auf schönen und leserlichen Quelltext achten soll, dann darf man sich nicht wundern das die Engine mit allen Effekten nur auf 4GHz Dualcore mit 7900GTX oder ähnlichem läuft.


Wenn du nicht auf schönen und leserlichen (wartbaren - ein wichtiges Kriterium! in jeder Software) Quelltext achtest, dann läuft deine Engine mit großer Wahrscheinlichkeit gar nicht, da niemand ein Spiel damit programmieren möchte, geschweige denn vorhandenen Source Code um Features erweitern.

Außerdem widerspricht sich Wartbarkeit nicht zwingend mit Performance. Die grundlegendsten Optimierungen geschehen auf algorithmischer Ebene (denke O-Notation). Die CPU-Zyklen-Optimierung machen heutige Compiler prinzipiell schon gut, und wenn man etwas nachhilft mit händischer Optimierung, dann kann man noch etwas rausholen.

Dabei ist allerdings wichtig, dass man nicht zu früh optimiert (d.h. wenn die Engine noch nicht mal annähernd komplett ist, und man daher nicht weiß wo es sich beißt), und "die häufigsten Fälle" optimiert (die man etwa durch Profiling-Tools herausfindet).

Jedenfalls ist es wirklich niemals so, dass eine Engine deswegen langsam ist, nur weil man statt reinem C auf C++ & Wartbarkeit gesetzt hat (zumindest wenn man nicht komplett was idiotisches macht).

Der Bottleneck liegt normalerweise woanders (API-limitiert, etwa durch Drawcalls, oder ineffiziente Algorithmen unabhängig ob OOP oder nicht, oder einfach dass die Effekte so teuer sind). Moderne Spiele sind außerdem eher grafiklimitiert, d.h. da holst du mit Optimierung von CPU-Zyklen sowieso genau 0 raus.


Nicht umsonst laufen moderne Spiele immer nur auf den neuesten PCs gut. Mit ein paar Algorithmenverbesserungen und sonstigen Optimierungen des Quelltextes könnte man sicher noch einiges an Frames rausholen.

Algorithmenverbesserungen ja. Optimierungen des Quelltextes auch ja, bedingt. Aber das hat nichts mit C++ vs C zu tun.

Ich finde es auch immer lustig dass Leute meinen dass heutige Engines so ineffizient wären. Diese Leute haben keine Ahnung davon was heutige Engines überhaupt alles machen. Klar, wenn man ein kleines Demo oder eine Mini-Hack-Engine schreibt, die die API direkt anspricht (statt über einen abstrakten Rendering-Layer), dann wird man vielleicht für die Größe des Demos schneller sein, no na ned.

Aber eine gute Engine heutzutage (und damit kommen wir wieder zum Thema zurück: mit guter Engine mein ich etwas, was ich als Großprojekt gelten lassen würde, also eine Engine von kommerzieller Qualität) bietet die vorher erwähnten Qualitätsmerkmale:
- Wartbarkeit
- Erweiterbarkeit
- Gute Toolchain
- Gute Dokumentation

Performance ist natürlich auch ein Ziel, und widerspricht sich mit diesen obigen Zielen nicht - viele Leute vergessen aber (vor allem wenn die über angeblich "ineffiziente Engines" schimpfen, was einfach nicht stimmt), dass eine kommerzielle Engine viel mehr ausmacht als nur die Performance.

Um es kurz auszudrücken: "Nicht umsonst laufen moderne Spiele immer nur auf den neuesten PCs gut." ist eine Trivialaussage. Bei den Effekten die heute verwendet werden, ist das normal, und eben nicht auf ineffiziente Programmierung oder gar Beachtung von Wartbarkeit zurückzuführen.


Übrigens, Beispiel aus der Realität: RenderWare ist eine Engine die in reinem C geschrieben wurde. Jetzt schauen RenderWare-Spiele alle nicht besonders toll aus, warum? Weil niemand Erweiterungen von Features in dieser Engine machen will. Frag mal einen Entwickler, der schon mal mit RenderWare gearbeitet hat, was er davon hält. Das ist so ziemlich die häßlichste Engine mit der man arbeiten kann, und letztendlich ist es ein Riesenkrampf, überhaupt irgendwas schönes aus der Engine zu bekommen.

Ich würde mir wünschen dass das inkompetente Gelaber über die Ineffizienz heutiger Engines endlich aufhört - wenn man bedenkt was heutige Engines alles leisten, sind heutige Engines nämlich sauschnell - gut, kann man nicht verallgemeinern, ich denke aber an Engines wie FEAR oder CryEngine. Klar brauchen die schnellere Computer - weil sie zaubern auch wesentlich mehr auf den Bildschirm!

Eine moderne State-of-the-Art-Engine wie die FEAR-Engine in reinem C wär komplett unbenutzbar.

[Trap]

Was ich meine ist: eine elegante Methode um z.B. Erstellung von Objektinstanzen auf dem Stack zu verhindern, ist es wenn man den Destruktor "protected" macht. Damit kannst du schon By-Design zur Compilezeit (statische Analyse) verhindern, dass dieses Objekt statisch instanziiert wird.
Das verhindert in C++ nur statische Instanzen die auf dem üblichen Weg erzeugt werden, per placement-new kann man sich daran vorbeischummeln.

Grade solche Zugriffskontrolldinger und Nutzungseinschränkungen kann man fast immer irgendwie umgehen, auf der anderen Seite ist es nicht schwer sie einzuhalten auch wenn der Compiler sie nicht testet.

Zugriffsschutz ist konzeptionell verwandt mit der statischen Typprüfung und sowohl Common Lisp als auch Smalltalk haben weder private/protected noch statische Typprüfung, sind aber zweifellos OOP-unterstützende Sprachen.
Python und Ruby genauso.

[tokugawa]

Das verhindert in C++ nur statische Instanzen die auf dem üblichen Weg erzeugt werden, per placement-new kann man sich daran vorbeischummeln.

Grade solche Zugriffskontrolldinger und Nutzungseinschränkungen kann man fast immer irgendwie umgehen, auf der anderen Seite ist es nicht schwer sie einzuhalten auch wenn der Compiler sie nicht testet.

Zugriffsschutz ist konzeptionell verwandt mit der statischen Typprüfung und sowohl Common Lisp als auch Smalltalk haben weder private/protected noch statische Typprüfung, sind aber zweifellos OOP-unterstützende Sprachen.
Python und Ruby genauso.

Ja, und? Was hat das damit zu tun was ich geschrieben habe?