wann managed code für Spiele?

[Gast]

Hallo,

Ich wollte mal fragen wann ihr glaubt, dass sich managed code in der Spieleindustrie "durchsetzen" wird (also das die meisten kommerziellen Entwickler managed code einsetzen), oder ob das überhaupt passieren wird.

Wären die Nachteile (Speicherverbrauch etc.) vielleicht zu groß dafür, oder wäre es doch denkbar, dass zum Beispiel der nächste Doom Teil dann in C# programmiert ist?

[Coda]

Bei Doom ist es eher unwahrscheinlich, weil Carmack schon immer recht konservativ war was neue Sprachen anging. Alles bis Quake 3 war noch pures C.

[ScottManDeath]

AFAIK sind Arena Wars und Alexander the Great (zum Teil) in managed Code geschrieben.

[micki]

ich glaube managed code wird sehr bald das scripting ersetzen und einen teil vom gamecode selbst ebenfalls uebernehmen. Die Firmen werden sich sehr schnell daran anpassen, dass absolventen von unis eher Java/C#/VB koennen als ihnen Jahrelang c++ richtig beizubringen, weil es vollkommen ausreicht um z.b. an die engine ein OnClick weiter zu leiten und dabei ein paar eigenschaften abzufragen z.b. "Is terrain ueberhaupt erreichbar?".
Schon heute nutzt man ja sogar bei gameboy und nds spielen scripting, was noch vor einiger zeit selbst fuer ps2-spiele als vieeel zu langsam, speicherfressent udn fragmentierend usw. angesehen wurde, wieso also nicht anfaenger von grund auf ordentlich produktiv sein lassen ohne dass sie aufgrund der komplexitaet der tools eher das gegenteil vollfuehren wuerden?
Ich frage mich nur wie weit das runtergehen wird, sprich: ob es mal sogar ne engine in c# geben wird. Soweit ich mal gelesen habe soll das naechste OS von microsoft nur noch .NET code ausfuehren koennen, was also zwangsweise managed sein wird. Da bleibt nur zu hoffen, dass die c++ programmierer auf anderen betriebssystemen/Systemen so gute Arbeit leisten, dass es nicht komplett gegen etwas "produktivereres" wie managed code ausgetauscht wird.

[Grestorn]

Es spricht recht wenig dagegen, auch Spiele-Engines in C# zu schreiben.

Das Problem ist aber, dass in managed Code für jeden Scheiß eine fertige API vorhanden sein muss oder der Programmierer muss dann doch wieder selbst Hand anlegen und ein (eventuell unmanaged) C++ Modul schreiben, dass eine bestimmte, durch keine fertige API abgedeckte Funktion realisiert.

Performance dürfte weniger das Problem sein, denke ich.

[Gast]

Soweit ich mal gelesen habe soll das naechste OS von microsoft nur noch .NET code ausfuehren koennen, was also zwangsweise managed sein wird.
Du meinst wohl Singularity.
Das ist aber nur ein Forschungs-OS und selbst MS hat nicht die Marktmacht um C++ in den nächsten 10-15 Jahren vom Markt zu drängen.

C# als Skriptsprache wäre natürlich edel (vorallem wenn man sich anschaut was der Industriestandard LUA für ein absoluter Müll ist). Aber dank Crossplattformtitel, eigenem Speichermanager etc wird das sich das auch nicht so schnell durchsetzen.
Insgesamt seh ich für AAA Schmieden mit einem entsprechenden Codepool auch nicht den großen Vorteil von Managed Code.

[micki]

Du meinst wohl Singularity.nein, ich meine das OS das nach Vista kommen soll. MS hat irgendwo mal gesagt, dass da nur managed code in sandboxes ablaufen soll und c++ dann nur als mittels CLI eingebunden werden koennte.. naja, ist ja noch lange hin



C# als Skriptsprache wäre natürlich edel (vorallem wenn man sich anschaut was der Industriestandard LUA für ein absoluter Müll ist). Aber dank Crossplattformtitel, eigenem Speichermanager etc wird das sich das auch nicht so schnell durchsetzen.
Insgesamt seh ich für AAA Schmieden mit einem entsprechenden Codepool auch nicht den großen Vorteil von Managed Code.
das problem ist wohl eher das AAA schmieden die besten leute von normalen schmieden bekommen und wenn die kein ordentliches c++ gelernt haben, dann wird auch dort C# einzug halten.


Es spricht recht wenig dagegen, auch Spiele-Engines in C# zu schreiben. eigentlich schon, denn wenn du das letzte bisschen performance haben moechtest, musst du auch auch zugriff auf jeden moeglichen teil haben und gerade da ist z.b. memorymanagement oder assembler sehr wichtig... klar wird das heutzutage nur sehr selten genutzt, aber in diesen seltenen faellen lohnt es sich dann auch ordentlich.


Performance dürfte weniger das Problem sein, denke ich.
speicherverbrauch und performance ist zwar immer weniger ein problem, weil dann halt der kunde mit besserer hardware nachlegen muss, dennoch ist sowas manchen wichtig.

[rotalever]

speicherverbrauch und performance ist zwar immer weniger ein problem, weil dann halt der kunde mit besserer hardware nachlegen muss, dennoch ist sowas manchen wichtig.
Auch wenn Ressourcen immer weniger ein Problem werden. Man könnte diese sinnvoller mit schnelleren Programmen nutzen um mehr Effekte zu erzielen, als bei den alten Effekten zu bleiben und die Programme nur langsamer zu machen.

[SgtTynis]

Geht nicht sogar schon XNA vom M$ stark in Richtung managed oder ist dort nur die verwendete Sprache C#?

[Expandable@work]

XNA ist komplett managed, das ist (u.a.) ja auch der Sinn des ganzen ;)

Abgesehen davon: Wenn eine Spieleschmiede C++ benutzt, und ein Bewerber kein C++, sondern nur C# kann, wird er halt einfach nicht eingestellt. Fertig. Und es wird weiterhin mit C++ programmiert. Auf diese Art und Weise wird C# sicherlich nicht in absehbarer Zeit C++ ablösen ;)

Gruß,
- Expandable@work

[Johnny]

Geht nicht sogar schon XNA vom M$ stark in Richtung managed oder ist dort nur die verwendete Sprache C#?
So isses
http://de.wikipedia.org/wiki/XNA_%28Microsoft%29

[Monger]

Die Frage ist: was fehlt denn überhaupt noch an Schnittstellen, die es nicht als managed Bibliothek gibt? Grafik: Direct3D. Sound: weiß ich ehrlich gesagt nicht. Festplattenzugriffe o.ä. : sowieso, Netzwerk: keine Ahnung...

Was bräuchte es denn noch alles?
Das größte Hindernis ist wohl der ganze alte Ballast, den große Spieleschmieden über die Jahre angehäuft haben. Wobei ich mich frage, wieviel das wirklich ist. Zumindest von meiner Firma weiß ich, dass sich dort keine Bibliothek besonders lange ohne massive Überarbeitung hält (was eigentlich dem Sinn einer Bibliothek widerspricht, aber naja...). Ich glaube eigentlich gar nicht, dass so extrem viel auf Vorgängercode aufbaut. Aber das könnten uns ja gewisse Leute hier ja ganz genau beantworten! ;)

[maximAL]

Was bräuchte es denn noch alles?
konsolen-unterstützung.
die große mehrheit der wichtigen titel ist muli-platform (oder nur konsole) und da siehts mit managed code wohl eher düster aus.

die verfügbarkeit von bibliotheken seh ich da weit weniger als problem, zumindest für net gibts eh schon bindings für jeden mist. und wenn ich an die problemlose interoperabilität zwischen verschiedenen sprachen denke (spiele mit F# und prolog coden :massa: ) läuft mir sowieso das wasser im mund zusammen...

[Monger]

konsolen-unterstützung.
die große mehrheit der wichtigen titel ist muli-platform (oder nur konsole) und da siehts mit managed code wohl eher düster aus.

Zumindest für die XBox360 scheint ja MS eine Menge getan zu haben.

Ich stell mal die bizarre und völlig haltlose These auf, dass wir bei der neuen Generation sogar weniger Crossplatform Titel sehen werden als in der vorigen. Die PS3 ist von den Eckdaten her ein absoluter Exot, die Wii bedient sowieso ihre ganz eigene Zielgruppe. Bleiben also "nur" Plattformtransfers zwischen dem PC und der XBox360, und dafür wird sich MS schon entsprechend stark machen.

Das ist jetzt natürlich sehr wild dahin spekuliert, aber ich sehe die Chancen für Managed Code Spiele als gar nicht mal so abwegig an.

[Gast]

Vielleicht setzt Sony und Nintendo in Zukunft ja auf das Mono Projekt?

[Demirug]

Ich sehe das im Moment nicht ganz so rosig. XNA Game Studio und der XNA Framework sind nicht ready für A/AA/AAA Title. Zudem kommt noch die fehlenden Planungssicherheit hinzu weil MS nach wie vor keine Roadmap veröffentlich und zum Beispiel auch nichts zum Thema managed D3D10 verlauten lässt. XBox Live Arcade und das vielleicht bald entstehende Windows gegenstück sind da schon eher mögliche Ziele.

BTW: XNA wird auch für unmanaged Dinge benutzt. DirectX gehört jetzt auch dazu und möglicherweise werden wir DirectX MVPs bald XNA MVPs.

[Monger]

BTW: XNA wird auch für unmanaged Dinge benutzt. DirectX gehört jetzt auch dazu und möglicherweise werden wir DirectX MVPs bald XNA MVPs.

Für die dumme Frage werde ich jetzt vermutlich ausgelacht, aber DirectX 9 existiert nach wie vor nicht als managed Variante?!?
Dann kann man doch mit C# (zumindest unmittelbar) überhaupt keine Software für DirectX schreiben, oder?
Beziehungsweise: war nicht .NET 3.0 (WPF??) genau dafür gedacht, um Anwendungen gemanagte Klassen für 3D Grafik zur Verfügung zu stellen? Kann man denn darauf keine Spiele aufsetzen?

[Grestorn]

Für die dumme Frage werde ich jetzt vermutlich ausgelacht, aber DirectX 9 existiert nach wie vor nicht als managed Variante?!?
Dann kann man doch mit C# (zumindest unmittelbar) überhaupt keine Software für DirectX schreiben, oder?
Beziehungsweise: war nicht .NET 3.0 (WPF??) genau dafür gedacht, um Anwendungen gemanagte Klassen für 3D Grafik zur Verfügung zu stellen? Kann man denn darauf keine Spiele aufsetzen?

Doch für DX9 gibt es schon seit einigen Jahren eine managed API.

[Neomi]

vorallem wenn man sich anschaut was der Industriestandard LUA für ein absoluter Müll ist

Das interessiert mich aber jetzt genauer. Warum soll Lua Müll sein?

[Demirug]

Für die dumme Frage werde ich jetzt vermutlich ausgelacht, aber DirectX 9 existiert nach wie vor nicht als managed Variante?!?
Dann kann man doch mit C# (zumindest unmittelbar) überhaupt keine Software für DirectX schreiben, oder?

Neben dem von Grestorn schon erwähnte managed DirectX (ein Einmann-Projekt von Tom Miller) baut ja auch der XNA Framework auf DirectX 9 auf.

Beziehungsweise: war nicht .NET 3.0 (WPF??) genau dafür gedacht, um Anwendungen gemanagte Klassen für 3D Grafik zur Verfügung zu stellen? Kann man denn darauf keine Spiele aufsetzen?

WPF ist die neue API für Benutzerschnittstellen welche zur Ausgabe ebenfalls Direct3D 9 nutzt. Zum größten Teil geht es dabei aber um 2D und der 3D Anteil hat nur einen Leistungsumfang im Bereich DX6/7. Im Notfall wird sogar eine Softwaredevice benutzt. Mann kann damit durchaus Spiele schreiben aber mehr im Bereich von Hearts usw. Wobei das WPF Hearts um Welten besser aussieht als das Windows XP Hearts.

[Gast]

Das interessiert mich aber jetzt genauer. Warum soll Lua Müll sein?
Schonmal damit gearbeitet?
Eine Sprache in der ich Klassen als Listen und Metatables nachbauen muss und jeder Depp in seiner Funktion die globale "Klasse" umbauen kann wirkt schon recht veraltet. Dabei ist Lua ja noch recht neu. X-D
Daneben machen solche Kunststückchen wie expliziter Variablenscope solche Dinge möglich:

function foo()
//do irgendwas
end
if y=0 then
a = "hallo"
else
foo = 23
end

Was mir je nach Wert von y global eine neue Variable a einführt oder aber die Funktion foo löscht und den Namen in Zukunft für eine Variable für eine Zahl nutzt. Keiner weiss ob "a" nun existiert oder ob foo noch eine Funktion ist. Die Sprache ist praktisch ungetypt.

Jede halbwegs moderne Sprache sollte heutzutage doch schon getypt sein, OOO bieten und den Variablenscope von allein gebacken kriegen. Lua kann nichts davon und erlaubt keinerlei strukturierte Programmierung. Wenn man manche Skripte in AAA Games sieht, läufts einem eiskalt den Rücken runter und man fragt sich wann es das erste mal crasht.

[Neomi]

Schonmal damit gearbeitet?

Bisher habe ich Lua nicht exzessiv genutzt, aber ich kenne die Sprache schon. Klar ist sie nicht perfekt, aber für ihr Einsatzgebiet durchaus geeignet. "Müll" bedeutet für mich "unbrauchbar", und das ist Lua sicherlich nicht.

Gibt es denn wirkliche Alternativen? Also Scriptsprachen, die plattformunabhängig sind und nach Möglichkeit frei nutzbar? Lua hat immerhin die passende Lizenz und kann auf jeder Plattform genutzt werden, die einen C-Compiler bietet.

[Gast]

Gibt es denn wirkliche Alternativen? Also Scriptsprachen, die plattformunabhängig sind und nach Möglichkeit frei nutzbar? Lua hat immerhin die passende Lizenz und kann auf jeder Plattform genutzt werden, die einen C-Compiler bietet.
Leider nein. Das ist die peinliche Sache daran.
LUA will man eigentlich nicht verwenden. Aber die Kunden wollen es und es gibt momentan keine Alternative.
Aber noch ein Grund mehr demnächst mal nem entsprechenden Lehrstuhl mit ner Wunschliste einen Besuch abzustatten...

[maximAL]

Jede halbwegs moderne Sprache sollte heutzutage doch schon getypt sein, OOO bieten und den Variablenscope von allein gebacken kriegen.
ich glaube, dir ist der sinn einer skript-sprache nicht ganz klar...

[micki]

Die Sprache ist praktisch ungetypt.darum geht es oft bei scriptsprachen, typeless zu sein. wenn man sich dagegen ansieht das scriptsprachen ploetzlich objekte von classen, also datentypen, instanzieren, ist es schon fast witzlos eine scriptsprache zu nutzen.


Jede halbwegs moderne Sprache sollte heutzutage doch schon getypt sein, OOO bieten und den Variablenscope von allein gebacken kriegen.
jo, dann hast du VB, was keine scriptsprache mehr ist, pappst noch nen c++-parser dazu und nennst die VB-VM .NET und schon hast du die sprache der zukunft ;)

aber ne scriptsprache ist es nicht mehr.

Wenn man manche Skripte in AAA Games sieht, läufts einem eiskalt den Rücken runter und man fragt sich wann es das erste mal crasht.
das tut es mir auch, bei jeder scriptsprache und auch bei dem meisten code von C#, java, flash usw. bei dem die leute ueberhaupt keine ahnung haben was darunter passiert.


Vielleicht setzt Sony und Nintendo in Zukunft ja auf das Mono Projekt?ganz sicher nicht, ein guter entwickler kann aus c++ mehr rausholen als mit c# moeglich ist und deswegen weigern sich 99.9% von denen auch umzusteigen. Es besteht im Prof bereich kein verlangen dafuer.
Ist wie mit dem autofahren, jeder kann taxi oder oeffentliche verkehrsmittel benutzen, hat fast nur vorteile, und trotzdem will so gut wie jeder ab 18 seinen wagen fahren.
(Nicht prof entwickler sind da eher wie urlauber, man geniesst es gefahren zu werden und alles moegliche serviert zu bekommen ;) )


btw, fuer alle die urlaub gebrauchen koennen: http://www.dreambuildplay.com/main/Default.aspx
:)

[Gast]

darum geht es oft bei scriptsprachen, typeless zu sein. wenn man sich dagegen ansieht das scriptsprachen ploetzlich objekte von classen, also datentypen, instanzieren, ist es schon fast witzlos eine scriptsprache zu nutzen.
Gut ok.
Vielleicht ist Skriptsprache dann der falsche Ausdruck.
Aber ist Unrealskript keine Skriptsprache? Bis auf die Geschichte mit dem Variablenscope, der auch dort auftaucht, find ich die Sprache wesentlich besser.

Wie auch immer man es bezeichnet, was man eigentlich benötigt, ist eine Embedded Language (so bezeichnet sich auch LUA), in die ich vernünftig meine Spielobjekte mappen kann (als Objekte), dort einfache Dinge machen kann, die aber getypt sein sollten.
Nen ordentlichen Variablenscope sollte aber wirklich jede Sprache haben, egal ob Skriptsprache oder was anderes...

jo, dann hast du VB, was keine scriptsprache mehr ist, pappst noch nen c++-parser dazu und nennst die VB-VM .NET und schon hast du die sprache der zukunft ;)
Der .Net Kram ist wieder alles zu mächtig und es gehört ein zu großer Unterbau dazu.
Ne Sprache zu der ich nen C++ Konverter für den Release hab, wäre traumhaft. Steht auch schon länger auf meiner Wunschliste. ;)
aber ne scriptsprache ist es nicht mehr.
Wie man es nennt ist eigentlich egal. So etwas bräuchte man einfach für viele Einsatzzwecke, wofür man heute Lua nutzt.

Eine Erfahrung von mir ist es auch, dass man Programmierer dazu zwingen muss, die Architektur einzuhalten und ihn direkt automatisch bestrafen muss, wenn er sich nicht daran hält.
Dann kann ich aber auch keine Skriptsprache gebrauchen, die dann selbst Designer machen lässt was sie wollen, ohne wirklich eine Möglichkeit zu haben restriktiv einzuwirken oder nichtmal Typsicherheit bietet.

[micki]

Gut ok.
Vielleicht ist Skriptsprache dann der falsche Ausdruck.
Aber ist Unrealskript keine Skriptsprache? Bis auf die Geschichte mit dem Variablenscope, der auch dort auftaucht, find ich die Sprache wesentlich besser. nicht mehr wirklich, zum teil scriptsprache aber auch zum teil codegenerator wenn ich das richtig sehe.


Wie auch immer man es bezeichnet, was man eigentlich benötigt, ist eine Embedded Language (so bezeichnet sich auch LUA), in die ich vernünftig meine Spielobjekte mappen kann (als Objekte), dort einfache Dinge machen kann, die aber getypt sein sollten.
Nen ordentlichen Variablenscope sollte aber wirklich jede Sprache haben, egal ob Skriptsprache oder was anderes... vs.
Der .Net Kram ist wieder alles zu mächtig und es gehört ein zu großer Unterbau dazu.[/quote]
das ist meist das problem, auf der einen seite moechte man ja was sehr hochqualitatives und integriertes, also nicht so ein flexibles LUA das sozusagen immer ein stueck knete bleiben wird, egal was man daraus formt, wenn auch es jede Form annehmen kann (ein grund fuer LUAs beliebtheit).
Andererseits moechte man ja auch auch keine VM wie VB/.Net bzw JVM, wenn auch sehr schoen zu integrieren, wirkt es auf mich wie overkill. (vor allem speichermanagement maessig, LUA begnuegt sich da ja hingegen mit ein paar KB beim start und der code hat auch <100kb compiliert.

ich denke sehr nett sind da einfach visuelle scriptsprachen, man selektiert sich ein 3d objekt, verbindet es mit irgendwelchen logischen bausteinen und diese dann wieder mit anderen 3dobjekten. z.b. lichtschalter -> OnKlickLogik --(trigger)-->Animation der tuer


Ne Sprache zu der ich nen C++ Konverter für den Release hab, wäre traumhaft. Steht auch schon länger auf meiner Wunschliste. ;)macht das UScript nicht so?

Dann kann ich aber auch keine Skriptsprache gebrauchen, die dann selbst Designer machen lässt was sie wollen, ohne wirklich eine Möglichkeit zu haben restriktiv einzuwirken oder nichtmal Typsicherheit bietet.das ist aber der sinn davon, der layer darunter muss die restriktion bringen, die sprache selbst muss einfach sein und nicht soo restriktiv

[Coda]

macht das UScript nicht so?
UnrealScript? Ne, das is ne VM. Das is recht lahm auch soweit ich weiß - zumindest in der UE2 noch.

C++ ist trotzdem irgendwie böse. Was ist denn das z.B. bitte:
#include <iostream>

class Number
{
public:
Number(int x) {};
void test() { std::cout << "Hallo, Welt!" << std::endl; }
};

int main()
{
Number(a)(2);
a.test();
}

Ja, das kompiliert. Ich kannte das nicht, und ich beschäftige mich schon ewig mit der Sprache.

[Grestorn]

#include <iostream>

class Number
{
public:
Number(int x) {};
void test() { std::cout << "Hallo, Welt!" << std::endl; }
};

int main()
{
Number(a)(2);
a.test();
}


Hab etwas grübeln müssen, aber dann ist es klar:

Du deklarierst eine Instanz von Number namens a. Dass der Name bei der Deklaration in Klammern steht, spielt keine Rolle. Als Parameter gibst Du dem Konstruktor den Wert 2 mit.

Dann rufst Du die Methode test der neuen Instanz a auf.

Das einzig überraschende ist hier, dass man den Namen der neuen Instanz auch in Klammern setzen kann. Nun ja, wenn man sich die Sprachdefinition von C/C++ ansieht nicht so sehr überraschend, wenn natürlich auch in der Praxis recht unsinnig.

Böse ist das eigentlich nicht. In praktisch jeder Sprache kann man sehr "obfuscated" schreiben. Für einige ist das ja geradezu eine Herausforderung :)

[tokugawa]

Hallo,

Ich wollte mal fragen wann ihr glaubt, dass sich managed code in der Spieleindustrie "durchsetzen" wird (also das die meisten kommerziellen Entwickler managed code einsetzen), oder ob das überhaupt passieren wird.

Wären die Nachteile (Speicherverbrauch etc.) vielleicht zu groß dafür, oder wäre es doch denkbar, dass zum Beispiel der nächste Doom Teil dann in C# programmiert ist?

Konsolenunterstützung.

Fast kein Entwickler kann sich's leisten auf nur ein Pferd zu setzen. Richtig absetzen kann man sich erst wenn man für alle Plattformen offen ist.

Und auch dann zahlt es sich aus eine gewisse Codebase zu haben. Wir haben z.B. eine ziemlich gute Asset Pipeline dank unserer in jedem Projekt (von DS über PS2 über Wii bis PC) verwendete Codebase, die noch dazu mit fremden (Grafik-)Engines verbindbar ist.


Und auch in Zukunft wird Multiplattform-Entwicklung wichtig sein. Ich glaub ihr denkt hier viel zu sehr an direkte Ports... aber Spiele die auf mehreren Plattformen sind, und auf jedem sehr unterschiedlich (was weiß ich, Wii und PC z.B. oder PC und DS gar - Beispiele gibt's dafür) können trotzdem einen großen Teil an Code sich teilen.


Nichtsdestrotrotz finde ich C# und Managed DirectX sehr reizvoll. Schöne Sprache, und sehr angenehm zum programmieren. Für reine PC-Entwickler und vor allem für Hobbyisten (auch mit XNA und dem Xbox360 XNA Creators Club) wird das auf jeden Fall interessant.

[Gast]

C++ ist trotzdem irgendwie böse. so böse wie ein Messer oder ein Mensch. Es ist ein Wekrzeug, dass dir alle Wege offen lässt und was dabei rauskommt ist dann nicht die Schuld des Werkzeugs. Ansonsten kannst du auch mit C# fehler einbauen, dann würde ich also Wordpad vorschlagen, da kann man alles reinschreiben was man möchte, da Wordpad aber keinen Compiler hat, erzeugt man nie etwas "Böses" ;)

[Gast]

C++ ist trotzdem irgendwie böse. Was ist denn das z.B. bitte:
#include <iostream>

class Number
{
public:
Number(int x) {};
void test() { std::cout << "Hallo, Welt!" << std::endl; }
};

int main()
{
Number(a)(2);
a.test();
}

Ja, das kompiliert. Ich kannte das nicht, und ich beschäftige mich schon ewig mit der Sprache.

Hast du dich auch wirklich ernsthaft mit Konstruktoren beschäftigt?
Im gegensatz zu Destruktoren kann man diesen Parameter übergeben und das funktioniert nunmal so wie das in dem Code oben steht. Es stimmt allerdings schon, dass diese Zeile nicht wirklich gut lesbar ist, man sollte aber schon etwas damit anfangen können wenn man sich wirklich schon "eine Ewigkeit" mit C++ beschäftigt.

[ScottManDeath]

float a[3];

assert(2[a] == a[2]);


ist auch gültiger C++ Code =)



*(a + b) = =a[b] == b[a]

[Coda]

Mir ist schon klar, was der Code macht, aber das man Deklarationen auch mit Klammern machen kann find ich seltsam. Das verwirrt doch nur.

Number(a)(2); sieht nun wirklich nicht danach aus. Alternativ könnte Number ja auch eine Funktion sein, die eine Klasse zurückgibt o.ä.

[Gast]

Die Klammern sind an dieser Stelle etwas unsinnig. Klammern verwendet man ja normalerweise um die Priorität der Operatoren zu beeinflussen. In der Zeile gibt es allerdings keinen Grund wieso man sie nicht weglassen könnte.

[Xmas]

Überflüssige Klammern kann man an den meisten Stellen verwenden. Bei Funktionspointer-Deklarationen muss man sogar Klammern verwenden. Überflüssige Semikolons kann man ja auch häufig haben (wie in deinem Beispiel).

[mickii]

float a[3];

assert(2[a] == a[2]);



hab mich schon die ganze zeit gefragt wann dieses default-c++-krass bsp kommt :D

[aths]

C# als Skriptsprache wäre natürlich edel (vorallem wenn man sich anschaut was der Industriestandard LUA für ein absoluter Müll ist).Warum sollte LUA absoluter Müll sein? Das einzige Problem was ich mit LUA habe ist, dass es zu schlampiger Programmierung verführt.

[ScottManDeath]

hab mich schon die ganze zeit gefragt wann dieses default-c++-krass bsp kommt :D

I couldn't resist ;D Da find ich das Number(a)(2) aber irgendwie krasser...

[Chris Lux]

Warum sollte LUA absoluter Müll sein? Das einzige Problem was ich mit LUA habe ist, dass es zu schlampiger Programmierung verführt.
warum das? ich glaube lua ist in der hinsicht nicht anders als python usw...

[Elemental]

Hier steht übrigens auch was zu managed DX10:
http://www.mdxinfo.com/index.php

[Expandable]

Hier steht übrigens auch was zu managed DX10:
http://www.mdxinfo.com/index.php

Meinst Du den Wrapper, den Demirug schreibt? Das ist aber nix Offizielles...

[Elemental]

Ja, den meinte ich...

Ist DirectX eigentlich abwärtskompatibel?
Ich arbeite mich gerade durch Tom Miller's Buch für managed Dx9 (kann jetzt schon einen Cube rotieren :D). Laufen die Programme dann auch unter Dx10?

[Demirug]

Ja, den meinte ich...

Ist DirectX eigentlich abwärtskompatibel?
Ich arbeite mich gerade durch Tom Miller's Buch für managed Dx9 (kann jetzt schon einen Cube rotieren :D). Laufen die Programme dann auch unter Dx10?

Nein.

Aber Vista unterstützt ja nach wie vor DX9 und damit laufen alle DX9 Anwendungen.