Ahoi,

habe heute ein paar Slides entdeckt, die zwar schon etwas älter sind, aber zeigen, dass das Gerede um Concurrency, funktionale Programmierung und Garbage Collection kein Werk des Teufels sind und man ohne sein Gesicht zu verlieren, selbiges nutzen kann und auch sollte. Zumindest sieht EPIC das so und dass deren Unreal Engines effizient sind, steht glaube ich außer Frage

Näheres gibt's bei Lambda the Ultimate. Da gibt's auch eine PDF-Version. Die Slides sind von Tim Sweeney.

Grüße
~ Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Can you provide some info what this is about?

Btw garbage collection is evil

_________________
http://3das.noeska.com - create adventure games without programming

Ich habs mir angeschaut. Er beklagt sich darüber, dass die Anforderungen, die an die Macher einer Game-Engine gestellt werden, an die Grenzen des Möglichen stoßen. Und dass die Mittel, die sie (die Programmierer) dafür zur Verfügung haben, nur unzureichend sind. Und er wünscht sich Verbesserungen, und führt an:
** Performance
** Modularität
** Verläßlichkeit
** Concurrency/Multithreading

Die beiden letzten Punkte bespricht er ziemlich ausführlich. Bei der Verläßlichkeit(Reliability) bezieht er sich auf den Compiler, und er schreibt dazu: "If the compiler doesn’t beep, my program should work".

Dazu möchte ich Euch was erzählen. Kennt Ihr den Begriff "Langtons Ameise"? (hier findet man was dazu: http://de.wikipedia.org/wiki/Ameise_%28Turingmaschine%29). Das ist ein Programm, und zwar ein sehr kleines, es hat nur ganz wenige Regeln eingebaut; in der Größenordnung von drei oder vier. Ich bin darüber gestolpert, als ich ein Physikbuch gelesen habe, im Kapitel "Theorie von Allem". Die Physiker sind immer auf der Suche nach einer Theorie, die alles erklärt. Dieses Kapitel schließt mit den Worten: "Vielleicht finden wir die Theorie, die alles erklärt. Aber wir werden sie höchstwahrscheinlich nicht verstehen können." Und er führt Langtons Ameise dafür an.

Wir kennen die "Theorie von Allem" für dieses kleine Programm, das sind die wenigen eingebauten Regeln. Aber trotzdem sind wir nicht in der Lage, vorauszusagen, was das Programm machen wird. Um rauszukriegen, wie die "Ameise" laufen wird (es ist eine Art Wegfindungsroutine), muss man das Programm laufen lassen. Die Ameise baut dabei ein Muster auf, manchmal ist es chaotisch, manchmal nicht, dann baut sie plötzlich eine Art "Straße", aber sie macht es immer anders.

Ich glaube schon, dass man die herkömmlichen Compiler verbessern kann. Aber es ist zuviel von ihnen verlangt, alle denkbaren Fehler vorherzusehen. Der Raum der Möglichkeiten ist einfach zu groß, noch viel größer, als der Möglichkeiten-Raum der Ameise. Man kann keinen unfehlbaren Compiler bauen, genauso wenig, wie man unknackbare Passwörter erfinden kann.

Und dann gibt es auch noch das Problem, dass bei der Verbesserung der Verlässlichkeit manchmal auch die Nützlichkeit des Programms abnimmt. Streich alle Pointer weg, und die Abstürze werden weniger werden. Aber kann ich dann noch das Gleiche mit vergleichbarer Performance machen?

Wie heißt es so schön? Bei der Optimierung von Risiko und Performance gibt es einen Zielkonflikt.

Viele Grüße
Traude

Hallo,

Ich frage mich wie die Leute in den 80ern und frühen 90ern Spiele entwickelt haben. Dort hatte man nur ein paar Kilobyte RAM, eine CPU die um den Faktor 1000 langsamer war als heute und trotzdem haben die Spiele unheimlich Spaß gemacht, auch wenn die Grafik nicht ganz so toll war . Man hatte wahrscheinlich noch nicht mal eine richtige IDE zur Entwicklung (sondern nur einen Texteditor und einen verbuggten Compiler) und von GC und dergleichen war man natürlich auch verschont.

Viele Grüße
dj3hut1

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University

Also Turbo Pascal war schon sehr toll von der Bedienung her. Auch wenn viele gute Spiele der Vergangenheit noch älter sind.

Ich denke, man kann das nicht verallgemeinern. Objektorientierte Programmierung hat ihre Vorteile, genau wie ein Garbage Collector, eine Virtuell Machine, funktionale Programmierung usw. usf. Die Dinge werden nicht (nur) genutzt, weil sie neu und hip sind. Sie haben ihre Daseinsberechtigung und ihre Nische.
Leider gibt es aber das Problem, dass fast jeder ein Lieblingswerkzeug (Hammer, Schraubendreher, Presslufthammer) hat und damit alle Nägel einschlagen, Schrauben drehen und die Straße aufreißen will. Spätestens wenn man die Straße mit dem Schraubendreher aufreißen will, sollte man merken, dass man ein totes Pferd reitet.
Um von der Metapher (seid froh, dass ich keinen Autovergleich gemacht habe, die sind noch schlimmer!) wieder weg zu kommen: Ein heutiges, komplexes Spiel, dass Wert auf ansprechende Grafik und eine gewisse Tiefe legt, wird wahrscheinlich nur schwer an Leistungseinbußen durch verschiedene Pattern und Konzepte vorbeikommen, wenn das Spiel fertig sein soll bevor die nächste Grafikgeneration raus ist. Wie es schon erwähnt wurde, muss man die Mitte zwischen einer gut für Menschen verständlichen Abstraktion und einem optimierten Programm finden.

Bei "kann" geh ich mit, aber warum muss ich wieder Dinge tun, weil du oder eine Firma, die auch eine gute Engine mitentwickelt hat ohne dass du erwähnst, ob sie das Konzept dort angewendet hat, der Meinung ist, dass es die Technik ist?
Und warum musst du uns hier "Rückenschutz" präsentieren, um deine Art und Weise zu programmieren zu rechtfertigen? Schreib dein Spiel zu Ende und zeige uns einfach, dass es geht. Das ist wesentlich überzeugender. Jeder soll tun, was er in der entsprechenden Situation und dem entsprechenden Problem für richtig hält (oder vom Chef aufgebrummt bekommt).

LG Ziz

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

Bevor hier GC gutgeredet wird, hätte ich gerne mal ein paar Vorteile von euch gehöhrt.
In Delphi sieht man zB mit dem integriertem FastMM direkt, wenn etwas nicht freigegeben wird.
Wenn ich beim GC unabsichtlich Referenzen halte müllt sich der RAM immer weiter zu und es wird schwer nachzuvollziehen, wo und warum das geschieht.

Garbage Collection schön geredet? Also ich dieses Thema gelesen und ich kann jetzt nicht behaupten, dass hier (außer Frase im ersten Beitrag) jemand Garbage Collections schön geredet hätte? Dann wüsste ich ja zu gerne wie es aussieht, wenn deiner Meinung nach über was hergezogen wird. Deine Vorderung kann man auch umdrehen. Von allen Leuten die sagen "Bloß keine Garbage Collection" würden mich auch mal interessieren warum solch eine Meinung. Ansonsten fällt es mir sicher nicht leicht solche Aussagen ernst zu nehmen. Und klar Garbage Collections haben wie jede andere Technologie ihr Vor und Nachteile. Und da kommt es dann grundsätzlich immer auf das Einsatzgebiet an.

Dein Argument mit möglichem unsichtbaren Speicherverbrauch lasse ich gelten. Möchte ich aber erweitern. Das Problem besteht hauptsächlich dann, wenn man viel mit globalen Objekten oder Objekten die sich gegenseitig referenzieren zu tun hat. Das kann auf der einen Seite ein Problem von Garbage Collections sein. Auf der anderen Seite kann es auch ein Problem im Objektdesign sein. Warum werden deine Objekte genötigt sich gegenseitig zu referenzieren? Bei Delphi hast du so etwas allerdings auch. Spätestens dann, wenn du mit Interfaces arbeitest haben deine Objekte auch eine automatische Speicherfreigabe. Und da ist es häufiger schon passiert, dass die unter dem Hintern weggezogen wurden. Bzw kannst du dort genau so die Referenzzählung ausstricksen wie wo anders. Und sich nicht um die Freigabe jedes Objektes kümmern zu müssen kann allerdings auch ein Vorteil sein. Kommt immer auf den Standpunkt an.

Ein Vorteil von Garbage Collections in der heuten Zeit sehe ich in dem verzögerten Freigeben der Objekte. Auf der klassischen Weise werden die Objekte dort gekillt wo sie erstellt wurden. Sorgt aber auch dann dafür, dass der Speichermanager keine Wahl hat und das immer sofort machen muss. Mit allem Verwaltungsaufwand der dabei existiert. Nehmen wir mal an die Garbage Collection arbeitet in einem Thread. Die nicht benutzten Objekte werden in die Collection geworfen und irgendwann dann aufgeräumt. Heutige Rechner habe fast alle 2+ Kerne. Wenn das also in einem zweiten Thread statt findet hätte man entsprechend den Hauptthread (Renderthread) dadurch schon entlastet. Was wiederrum dazu führt, dass man etwas mehr Leistung zum Rendern hat. Ein Maß an Leistung was sicherlich nicht übermäßig groß sein dürfte aber immerhin. Ganz zu schweigen von den ganzen Try Finally blöcken. Wobei man das auch da relativieren muss. Wenn ich pro Renderdurchgang unzählich Objekte erstelle und wegschmeiße stellt sich mir die Frage ob mein Design das Richtige ist.

Mir geht es hier nicht darum eine Pro/Contra Garbage Collection Diskussion drauß zu machen. Nur sollte man nicht ohne Begründung irgendwelche Technologien baschen. Es kommt halt immer auf die persönliche Einstellung und den Einsatz an.

Die Sache mit der gegenseitigen Referenzierung ist nach meinem Wissen bei aktuellen GCs kein Problem. Frase kann da ein schönes "Bild" mit Heliumballons bringen .

GCs sind toll und so … Aber wegen denen würd ich nicht unbedingt die Sprache wechseln . Was würde einen Speichermanager in einer Sprache wie Delphi eigentlich daran hindern, so ähnlich zu arbeiten wie ein GC? Also, bei "Free" nicht das Objekt freigeben sondern sich merken, dass es weg kann und dann Freigeben, wenn's gerade passt (z.B. bei einem Aufruf von Sleep).

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Sprache wechseln nur wegen nem GC fände ich auch sinnfrei... wer unbedingt nen GC will, kann sich relativ problemlos ja einfach selber einen basteln.

Zumindest in C++ und ich denke auch in Delphi ist das kein Problem - zumindest solange wie man sich darauf beschränkt das der GC nur für eigene Klassen funktioniert. Es muß eben alles irgendwie von der GC-Klasse abgeleitet sein.

Aya

Ich glaube hier versteift ihr euch an dem GC, welcher nur eines von vielen neueren Werkzeugen ist, die Vorteile und Nachteile haben. Ein GC wird von Programmierern gerne gesehenl, weil er Mögliche Fehlerquellen im Bereich Pointer reduziert. Natürlich hat ein GC auch negative Wirkungen wie z.b. verzögertes Freigeben, CPU Peeks, da alles mit einmal frei gegeben wird und nicht onDemand wie beim herkömmlichen System. Es gibt unterschiedliche GC und einige laufen besser als andere, wie z.B. der GC von Mono, welcher massive Memory leaks erzeugt, wenn es mal zu größeren anzahl an alloc und dealloc's kommt. Das Problem haben allerdings alle GC, dass bei sehr hohen Speicher erstellen und zerstör aufrufen Performance Probleme sowie Memory Leaks entstehen. Java VM hat da z.B. unterschiedliche VM, wegen unterschiedlicher Probleme und VSC#2010 hat dieses Problem auch.
Also GC ist kein Heilmittel gegen unfähige Programmierer, sondern nur ein Werkzeug für bestimmte Einsatzszenarien(Im Spielebereich z.B. nicht ).
Wenn man viel Speicherfoo in kurzen CPU Cycles macht, dann sind Refcounter(eine von mehreren Smartpointer Arten) und auto_ptr(RAII Prinzip) um längen besser und sind genauso sicher gegen Memory Leaks.

Interessante dinge in der Spieleentwicklung sind Toolchains und da muss Epic einfach mal ein Epic fail hin nehmen.
Für ihre Toolchain nutzt man WxWidget und so gut es auch Portable ist, nutzt dieses Feature Epic nicht und das erweitern von der Toolchain ist ein langsamer, schwerer und mit vielen Perforce merges versehender Weg.

Interessante neue Sachen gibt es bestimmt und die Compiler und Sprachen werden regelmässig erweitert.
So z.B. die Vector Extension von gcc, entfernen von Exceptions aus C++, Atomic Operations für CPU, Software Threads für das sparen von stackswitches, Reflections für Scriptanbindungen, JIT für Scripte und vieles mehr.
Intel bietet z.B. ein Online Dienst, welcher gcc fähigen code compiliert, analysiert und dann anhand von einer KI optimierungen aus vorher gemachten Erfahrungen tätigt. Die Ergebnisse aus dem Projekt waren mehr als Überragend.
Dieser hat Spagetticode entwirrt, klassen umgestellt, typen korrigiert, pointer probleme gelöst und noch einiges mehr.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Disclaimer: Der Text geht hauptsächlich an Ziz, ist also bewusst so geschrieben, dass er auch von ihm wahrgenommen wird. Für den Rest mag der daher relativ aggressiv wirken




Wo siehst du da irgend eine Art von "Rückenschutz", mit dem ich verteidigen würde, wie ich mein Spiel schreibe? Das mag dir vielleicht so erscheinen, ich hab aber absolut keine Veranlassung, da was zu verteidigen: Ich weiß, dass die Techniken gut sind. Da gibt's nichts zu verteidigen. Diskutieren gerne, aber nicht grundlos verteidigen.
Ich wollte hier nur aufzeigen, dass durchaus auch große Firmen der Überzeugung sind, dass viele dieser Techniken gut sind. Warum sie das sind, ist in den Slides auch erwähnt.

Ich hab auch nie behauptet, dass du das jetzt alles einsetzen müsstest. Wie käme ich denn auch dazu? Können wir einfach mal bei den Tatsachen bleiben und nicht irgendwelche an den Haaren herbeigezogene Behauptungen aufstellen? Ich vermisse da ein wenig den Ernst bei der Sache.
Ich habe lediglich gemeint, dass man meiner Meinung nach diese Techniken ruhig mal nutzen und ausprobieren sollte, bevor man über sie herzieht, das ist alles. Ziz, dir zwingt bestimmt niemand was beim Computer auf. Keine Angst. Du hast mit C auch sehr gute Chancen, ne ganze Weile von Innovationen verschont zu bleiben

Was ich tatsächlich nicht erwähnt habe, ist, ob Epic diese Konzepte auch angewandt hat. Das hat einen einfachen Grund: Ich weiß es nicht Ich möchte aber zu bedenken geben, dass es ziemlich bescheuert wäre, einen Vortrag über ne ganze Latte an Techniken (Und an den Slides merkt man, da haben sich ne Menge Leute ne Weile Gedanken zu gemacht), einfach so untern Tisch fallen zu lassen und nichts davon umzusetzen. Die Slides sind übrigens aus 2006. Ich gehe also davon aus, dass vieles, was dort angesprochen ist, bereits in der Unreal-Engine 3 implementiert ist.

Und zwecks Spiel fertig schreiben: Auch auf die Gefahr hin, dass ich mich wiederhole, aber die Slides sind keine Rechtfertigung dafür, wie ich mein Spiel schreibe. Ich habe nicht vor, mein Spiel zu schreiben, damit du endlich merkst, dass die Zeit weiterläuft. Dafür wäre mir die Zeit dann doch etwas zu schade.

Grüße
~ Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Manchmal sollte man auf den Lord hören, wenn er Kommentare von einem als zu bissig empfindet, aber gepostet, ist gepostet, schauen wir mal, wo meine Kommentare auf Wahrheit beruhen und wo ich mich ein wenig zu wagen Vermutungen habe verleiten lassen.
Ich sah den Versuch Rückenschutz von Epic zu bekommen, weil du wissen solltest, dass das Erwähnen von funktionaler Programmierung in Form von Scala, vor allem im Chat, dir des Öfteren "ein nettes Lächeln einbringt". Da liegt die Vermutung nahe, wenn du neben deinen Argumenten für die partielle, funktionale Programmierung eine Firma "präsentieren" kannst, die a) bekannt ist und sich b) sehr positiv äußert. Diese Aussage bleibt aber in der Welt der Vermutungen, wie du richtig erkannt und danach die Vermutung verneint hast.
Ich gebe zu, ich habe mir die Slides nicht angeschaut. Auch wenn es nicht so wirkt, habe ich auch keine schlechte Meinung von funktionaler Programmierung, ich finde Haskell sehr cool. Deine Argumentationen reichen mir um ein ungefähres Bild von Scala zu bekommen. Ich mag Java nicht gerne nutzen, da rutsch Scala automatisch mit rein.
Du hast die Stelle selbst zitiert, als du mich zitiertest:
"Sollen" und "Müssen" sind meist synonym zu benutzen.
Habe ich. Nicht Scala, aber Haskell. Des weiteren habe ich mich ein wenig mit den Vorzügen und Nachteilen von Java beschäftigen "dürfen". Nun darfst du mir erklären, wo ich über etwas herziehe. Ich ziehe nicht über die Technik her, ich erwähne sogar explizit dass es ein guter Hammer für seine Nägel ist. Wenn ich über etwas "herziehe", dann über dich, wobei ich das Wort dann zu krass finde, so soll es bitte nicht herüberkommen, ich ziehe also nicht her, sondern kritisiere, dass es so wirkt (um anzudeuten, dass wir uns wieder in der Welt der Vermutungen befinden, was das Grundproblem bei deinem Beitrag an mich ist), als würdest du deinen neuen Lieblingshammer auf so viele Nägel loslassen wollen, wie es geht - auch wenn der Schraubdreher bessere Ergebnisse liefern würde - womit wir wieder bei meiner Grundmetapher wären.
Hehe, du erzählst mir was davon, ich soll ernst bleiben, und fällst selbst in das plumpe Klischee, ich nutze nur C und dessen geringe Features. Mal drüber nach gedacht, dass du keine Ahnung von dem hast, was ich neben Open Party noch so mache, dass ich in einem obskuren "Damals", welches über ein Jahr zurück liegt, einen, wie ich dachte, guten Grund für reines C hatte, was sich zwar als falsch herausgestellt hat, sich nun aber durchgezogen hat und schlicht funktioniert ohne eine extreme Komplexität anzunehmen oder mich vor Probleme zu stoßen, die mit OOP einfacher machbar wären, und dass die meisten Design Pattern auch ohne OOP machbar sind?
Nicht unbedingt. Es ist oft so, dass man von einer Idee, Erkenntnis oder Entdeckung so begeistert ist, dass man wieder den Fehler macht zu glauben den heiligen Hammer für alles entdeckt zu haben. Warum sollte EPIC vor diesem Fehler gefeit sein? Es sind alles nur Menschen und es wäre nicht die erste Firma, die ein totes Pferd reitet bis sie untergeht. Wobei ich das hier weder denke noch wünsche. Immerhin gibt es die Firma ja noch, also scheinen die meisten Pferde noch zu leben.
Wo wir wieder in der Welt der Vermutungen sind.
Du wiederholst dich. Ob es besser wird, wenn du es extra erwähnt, dass dies passieren könnte, sei dahingestellt. Aber ich werde den gleichen Fehler machen und dir abermals unterstellen, dass du deinen Weg als Optimum siehst. Das Wort, dass dies am meisten bekräftigt ist "endlich". Wenn ich deinen Satz lese, gibt er durch dieses Wort, das Gefühl als wäre mein Weg eine Sackgasse und deiner der Richtige. Wir merken: Abermals ein Gefühl, also nur eine emotional gesteuerte Vermutung.

Es ist scheinbar von Nöten Interpretationen deutlicher als diese zu kennzeichnen, damit man mir keine böse Nachrede unterstellen kann. Diese sind nämlich nicht vorhanden. Ich habe weder etwas gegen dich, noch gegen Scala, Java oder all die Techniken dahinter.
Zumindest solange es mir frei steht selbst zu entscheiden, was ich davon nutze und was nicht und man mir meine Methoden lässt und sie nicht kritisiert, solange sie das gewünschte Ergebnis liefern. Sollte ein Ergebnis nur durch eine bestimmte Methode lösbar sein, so werde ich diese so oder so nutzen (müssen) und sollte es durch eine andere Methode viel einfacher gehen, ist es im Endeffekt meine Sache, ob ich mir unnötigerweise mehr Arbeit mache.
Anmerkung: Ein "Ergebnis" schließt in diesem Fall Dinge wie "simple Vererbung", "gute Verständlichkeit für Projektmitarbeiter", Effizienz, Effektivität und dergleichen ein, so sie gebraucht sind. Es geht nicht um das plumpe Erfüllen eines JUnit-Tests, der meiner Umsetzung funktionelle Richtigkeit bescheinigt.

LG Ziz

PS: Dieser Beitrag ist von Smilies unterbesetzt und könnte deshalb aggressiver wirken als gedacht. Deshalb reiche ich nun ein paar Smilies nach um dem ganzen im Durchschnitt die Schärfe zu nehmen:

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

Ich fände es im Übrigen sehr schön, wenn man sich über Programmiertechniken, neue Sprachen, Projektmanagement (XP vs. Prozess, vs. GutGlück) etc. sachlich unterhalten könnte ohne auf persönliche Vorlieben des anderen abzuzielen.

Ich fand die Folien sehr interessant, und es freut mich, dass die Jungs bei Epic noch Zeit finden sich ausführlicher Gedanken darüber zu machen, wie ihre Arbeit besser laufen könnte, wenn man andere Technologien zur Verfügung hätte.
Die Syntax-Vorschläge die sie bringen sind aber mindestens zweifelhaft - Lesbarkeit war da sicher kein Argument.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich habe mir die Slides nun auch mal angeschaut und was gesagt wird, deckt sich im Prinzip mit meinen Aussagen.
Ich finde es interessant, dass sie in der Unreal Engine (so ich es richtig verstanden habe) wirklich Haskell genutzt haben. Mir war nicht bewusst, dass Haskell die Uni verlassen hat. Ich find's cool.
Die Folien ansich fand ich irgendwie total bunt. Aber wahrscheinlich sollte das auflockern und die eher "düsteren" Spiele (siehe die Screenshots) konstrastieren.
Ich hätte auch nicht gedacht, dass Engine und Spiel an sich "nur" jeweils 250.000 Zeilen Code sind. Ich hätte da mit mehr gerechnet.

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

Hat es auch nicht, ist alles c und c++ in UE3.


Ich traue nur der Statistik, die ich selbst gefälscht habe. Die Zahl hat nicht viel mit der Realität zu tun, wenn die noch ne 0 ran hängen kommt es schon eher hin.

Man kann viele angesprochende Dinge, auch in c++ per templates und macros lösen, das macht boost z.B. so.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004