c#

c# (56 Beiträge, 636 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

welche sprache sollte man lernen wenn mal spiele oder 'intellegente systeme' programmieren möchte?
mfg lij

AF - Austrian Forces

20.11.2005, 19:29 Uhr - Editiert von lij, alte Version: hier

das DirectX SDK gibts für C++ und C# (.NET halt generell). Für OpenGL ist imho C++ geeignet

That last wish of yours got the contract broken. Don't you ever read the contract? Article 147, paragraph 9, subsection 3. Selfless redemption.
If you commit one truly benevolent act, it voids the contract. (Bedazzled / Teuflisch)

Obst mit C# scheite Spiele zambringst?
Also ob sich das jemals als Game-Developer-Sprache durchsetzen können wird?

warum nicht ... ist auch nur ein auf dem alten aufbauendes framework ...

sooo lahmarschig ist es auch wieder nicht ...

allerdings hat sich in dem bereich halt C++ extrem hervorgetan ... daher wird das sicher noch eine Weile State-Of-The-Art sein

Doch das geht... Also, computergraphisch soll C# gar nicht so schlecht sein. In der Echtzeitgrafik Übung auf der TU Wien verwenden einige C# und machen damit echte State-of-the-Art Sachen wie etwa Precomputed Radiance Transfer (PRT).

OpenGL ist super, gut dokumentiert (auch freie Online-Handbücher) für 3D. Vorteil: Plattformunabhängig. id-Software baut viel auf OpenGL, daher können's die Spiele auch nach Linux porten.

SDL darunter. SDL ist ähnlich wie Direct* - auch Plattformunabhängig

Sprache: C oder C++. Ich empfehle den gcc als Compiler - seeehr gut und umfangreich, frei und portabel. C finde ich persönlich sympatischer - ist auch performanter wenn man genau weiß, was man tut

Vermutete Schätzung des Zeitaufwands:
C inklusive der gut zu verwendenden libs: 1-2 Jahre minimum.
OpenGL: 1/2 Jahr
SDL: 1/2 Jahr

Summe also 2-3 Jahre, bis du gute Spiele schreiben kannst...

ICH habs eh nicht vor

Sorry...

Finde es nur immer wieder schräg, wie Leutchen noch nicht programmieren können und trotzdem nur eine bestätigung suchen, warum sie gerade in C# und DirectX beginnen sollen

.

Wobei...
Ich hab' in der guten alten Zeit mit Sinclair-Basic begonnen - und nach 1/2 Jahr Assembler auf dem Z80...

Damals war die Welt noch in Ordnung, Sprachen noch lernbar und klein im Umfang..
Aber ausgerechnet mit einem Beast wie C# anfangen... Da kann IMHO nix rauskommen ...

öhhhhhmmm .. da frag ich mich aber wer da hier wirklich das Biest ist .. c# oder C++

Da könnte ich ja jetzt Antworten...

So oder so, Objektorientiert ist zum Anfang IMHO so oder so aber derart von Falsch...

Ist genauso wie wenn du einen, der die Grundrechnungsarten net kennt, gleich mal auf die Uni schickst um Mathe zu studieren... Natürlich könnt's bei Fächern wie Graphentheorie anfänglich wurscht scheinen und ok sein...

Funktionieren wird's nicht oder zumindest wird das Ergebnis schauerlich sein

also ich sehe da eigentlich kein problem ...

klar - zu beginn müssen halt Dinge wie die üblichen Konstruke im Vordergrund stehen, die braucht man ja sowieso ...
aber beispielsweise kann man in C# genauso ein typisches Konsolen - Hello World schreiben, ohne sich um Klassen kümmern zu müssen ...
Natürlich darfst den Anfänger auch nicht gleich mit komplexen UML Diagrammen verärgern - aber im Grossen und Ganzen wage ich zu behaupten, mit C anzufangen ist nicht mehr aktuell ... Ich will mir einfach keine Gedanken mehr darüber machen müssen, ob ein string nun ein null-terminiertes char array ist - das interessiert mich einfach nicht

Muß dich ja auch nicht interessieren... Denn wozu gibt's String-Bibliotheken ?

Nur... Wenn einer mit c++ beginnt (oder einer anderen Objektorientierten Sprache) - dann muß er Design-Patterns gleich mitlernen, sonst kommt Shice raus.

Wenn er aber das Objektoientierte wegläßt - dann kann er IMHO gleich einfacher mit C beginnen... Denn nichts, was er dort lernt, gilt in C++ nicht mehr...

Nun denn, doch... Tentative Deklarationen gibt's nur in C und nicht C++... Wobei ich nicht glaub, daß die ein Anfänger lernt.

Nur ist halt auch die umgekehrte Gefahr gegeben.... wenn man rein prozedural lernt, und sich darin "versteift", hat man vielleicht mit anderen Konzepten seine Schwierigkeiten. Wobei OOP in Form von C++ (als Erweiterung von pure C) sicher noch leichert ist als etwa gleich in eine Hardcore-OO Sprache wie Smalltalk.

Von komplett anderen Programmierkonzepten wie funktionaler Programmierung will ich gar nicht reden

Wieso denn ?

Innerhalb deiner Klassen bist eh oft prozedural...

Und sauberes OO-Design ist etwas für Leute, die IMHO jahrelang programmiert haben - mit 2stelligen Wochenstundenanzahlen - sonst wird das nix (Kann aber auch an meiner persönlichen Präpotenz liegen

).

Versteh' mich nicht falsch... Objektorientiert Coden hat durchaus seine Berechtigung und einige Aufgabenstellungen (die ich aber nicht direkt am erzeugten Code sondern eher an der Organisation der Entwickler sehen würde) lassen sich so superst lösen... Abgesehen davon läßt sich durch den Verkauf von
Klassenbibliotheken auch wieder Kohle verdienen

Ich liefere Dir aber noch ein Killerbeispiel, warum ich OO nicht für Anfänger gut finde:
http://www.objectmentor.com/resources/articles/Walking_through_A_UML_Design.pdf

Das schöne an dem Beispiel ist:
1.) Es ist logisch
2.) Sie haben Recht
3.) zeige mir zum Vergleich, wie das ein Programmier-Anfänger in seinen ersten 2 Jahren gelöst hätte

Traurig dabei ist, daß ich mir die Aufgabenstellung anfangs selbst zu Gemüte geführt habe - und daß ich bei weitem nicht so weit gekommen wäre wie sie... Wobei ich seit 23 Jahren code (nun gut, viell. bin ich zu alt

) - und immerhin 2-3 Jahre OO gecoded habe (allerdings Turbo-Pascal V5.5

).

Wie auch immer... OO ist ein sehr umfangreiches Instrumentarium, und alleine zum Erlernen der Designpatterns (die nicht einmal zwischen Sprachen portabel sind) - und dem Durchdenken-ausprobieren-Erfahrungen sammeln - braucht man IMHO locker ein Jahr...

Der Vorwurf "sich via proz. Coding falsche Wege einlernen" stimme ich auch nicht zu... Denn jeder, der wie ich in den frühen 80ern auf ZX-81, C=64, ... begonnen hat, lernte sich zwangsweise Spaghetti-Code ein (egal ob Basic oder Assembler) - und ich denke, daß ich inzwischen sauberst prozedural code

Naja, das mit dem "sich via proz Coding falsche Wege einlernen" meinte ich ja nicht verallgemeinernd, aber die Gefahr besteht durchaus - ich kenne einige konkrete Beispiele.

Heißt nicht dass es für jeden so ist.

Ansonsten hast eh recht, OOA/OOD ist schon etwas sehr komplex für einen Anfänger (und eventuell wirklich nur für jemanden etwas, der sowieso in die Richtung geht, etwa durch ein Informatik-Studium).

Trotzdem glaub ich genauso dass es weniger "hingehackte" Lösungen gäbe wenn einige Die-Hard-Procedural-Programmierer, die rein fähigkeitsmäßig durchaus in der Lage wäre, schönen, wartbaren Code zu produzieren, auch mal die Vorteile des OOD einsehen würden.

Ich sehe schon ziemlich oft Open Source Source Code, bei dem sich mir einiges umdreht (und das wird wohl bei Closed Source auch nicht überall besser sein).

Aber gut, ich schweife ab

Echt, ich habe OO vor 1 Jahr wieder eine gute Chance gegeben... Hatte endlich ein Java-Fähiges Handy und wollte das C=64 Spiel "M.U.L.E." /sauber/ in Java schreiben (einen anderen Grund pro Java außer M.U.L.E. porten ist mit bis heute nicht eingefallen, aber da hab' ich inzwischen eine echt festgefahrene Position

)

Also Java gelernt (Ist ja echt nicht so schwer, wenn man ein paar Sprachen hat... Mich erinnerte es an ein "kastriertes C++", wobei mir bei einigen Konzepten nicht klar wurde, warum sie kastrierten (zB Kinder von mehreren Eltern) - aber egal.

Nun denn, also auf in die Design-Patterns (Gerade wenn ich mit einer Sprache beginne, will ich echt alles nach Lehrbuch machen - wurscht, wenn's Overkill ist

. Besser man tut sich das früher an, als man schreibt eh nachher alles um, weil einem (a) das kotzen kommt (b) das wirklich unwartbar wurde und (c) man sich falsches einlernt (da bin ich bei Dir).

Also 3 Bücher über Java-Design-Pattern gelesen - und dann die Beispiele von objectmentor durchgeackert...

Dann mit dem Design begonnen - und hier passierte was einmaliges:
Trotz der einfachen Aufgabe habe ich nach rd. 40h Design einfach drauf gshissen... Brrr... Ist mir bei einer neuen Sprache noch nie passiert...

OO ist wirklich gerechtfertigt - soweit sogut. Nur... Einfach und Anfängertauglich... IMHO NOPE.

Wobei du bei J2ME/MIDP 2.0 sowieso sehr viel optimieren mußt und da sehr viel schönes Design opfern mußt - Resourcen sind halt auf einem Handy recht begrenzt.

Und mir ging's eigentlich nur drum, zu zeigen, dass von prozedural auf OOP doch auch ein Anstieg besteht - und umgekehrt auch.

Die Frage ist welche Richtung die zielführendere ist, da prozedural doch gewissermaßen ein Subset von zumindest C++ und Java-style OOP ist.

Als Tutor für Computergraphik auf der TU Wien merk ich das zumindest die ganze Zeit, in beide Richtungen. Ich tät also weder dem prozeduralen noch dem OOP für einen Anfänger "per se" empfehlen, da der Anstieg auf das andere diskutabel schwer sein kann (wohlgemerkt nicht muß - ich merk's nur bei meinen Studenten).

Da gibt's die einen die haben als erstes Java gelernt, für die kann man prozedural noch leicht als "alles sind statische Funktionen" erklären.

Und dann gibt's die anderen die vorher schon in der Demoszene in Assembler und C rumgehackt haben, jedes CPU-Cycle gezählt haben, aber dann mit high-level Konzepten des Objektorientierten Designs Probleme haben.

28.11.2005, 18:38 Uhr - Editiert von tokugawa, alte Version: hier

Natürlich kostet der Umstieg /immer/ Zeit... Keine Frage. [Habe ich eh mit meinem Beispiel auch bestätigt

]

Nur hat ein absoluter Anfänger im Programmieren eben IMHO die Wahl:
Variante 1:
-) Syntax lernen
-) "Zerlegen von Problemen lernen" - sinnvolle functions
-) Trial-und-Error der Implementierung

oder
Variante 2:
-) mehr Syntax lernen (zB scheint mir OO ohne Templates wenig zielführend... Sie erscheinen mir aber weder portabel noch trivial [noch etwas, wo ich Java als sinnlos kastriert empfinde

])
-) Design-Patterns lernen
-) UML lernen (wie soll er sonst designen)
-) in UML dann das "Zerlegen von Problemen lernen":
Was kommt in eine Factory, was wird Abstract, ...
-) Trial-und-Error der Implementierung

Also die "erste Hürde" scheint mir bei Prozedural geringer

Und zu deinem "Im Prozeduralen ist alles statisch"... Nun ja, dann wird's aber schwierig, Callbacks unterzubringen... Als möglicher Ersatz eines Delegates, ...

Im Gegenzug könntest den Prozedural'lern ja beim Wechsel zu OO sagen "Jetzt kommt nur noch eine andere Art von Callbacks" und fertig sind wir mit OO

.

OO verwendet IMHO größtenteils einen sehr marketingwirksamen neuen Namen für alte Konzepte... Nur zwingt dich OO von Haus aus zu Objekten - also zu /mehr/ zum Lernen.

Anyways, wer schon ein paar Sprachen kennt, hat so oder so leichter lachen... Ich will ihm ja auch nicht OO komplett ausreden - nur als allererster Programmieransatz ist's hart (da war aber IMHO auch schon das von allen so gelobte Lisp hart... An die Listen muß man sich erst mal gewöhnen

Versuch mal Haskell

Jedenfalls hast du recht... "richtiges" sauberes OO kostet natürlich die in der Variante 2 erwähnten Dinge.

Aber es ist sicher nicht verkehrt eine "prozedural-objektorientierte" Sprache wie Object Pascal (Delphi) oder Java zu erlernen. Von C/C++ würde ich als Anfänger fast abraten - die Pointer können für Anfänger eher frustrierend sein als motivierend.

Java hat übrigens mittlerweile Templates bzw. Generics.

Und java hat seit der 1.2er (glaublich ,-) ) auch weak References.. Also eh wieder Pointer

Nachdem man ohne die net sauber coden kann (und Pointer angeblich für Anfänger Frustrierend sind)- rätst Du also jedem [Anfänger] von Java ab ? Hey, wir treffen uns doch noch

Nein, nicht Pointer oder Referenzen sind das was Anfänger abschreckt, sondern die PointerSYNTAX von C/C++. Das sehe ich fast täglich ("was heißt jetzt * wieder in diesem Kontext?").

Schon mal versucht was in OpenGL zu portieren auf
-) verschiedene Plattformen (mit verschiedenem OS-Layer, also WGL, GLX, usw)
-) verschiedene Grafikchiparchitekturen (etwa GeForce 4, Radeon 8500/9000, Radeon neueren Datums, GeForce FX/6/7?)

Die Portabilität ist nur für wirkliche Core-Funktionen wirklich gegeben. Spätestens bei Offscreen-Rendering (Stichwort PBuffer) wird man einsehen müssen bei OpenGL, dass die "Portabilität" ganz sicher _kein_ eindeutig positives Kriterium für OpenGL ist. Obwohl da mit den Framebuffer Objects sich sicher einiges tun wird - aber die sind zur Zeit nicht wirklich breit verfügbar in den OpenGL-Treibern.

Trotzdem ist OpenGL um einiges einfacher zu erlernen als Direct3D. Und DAS ist dann der wirkliche Vorteil.

Zu dem C vs C++... wenn man genau weiß was man tut, ist C++ genauso performant. Der Vorteil von C++ ist schönes wartbares objektorientiertes Design, inklusive schöner Strukturen wie den Design Patterns (werden auch in Spielen immer wichtiger).

glut et al würde ich auf dem Zielsystem voraussetzen... Damit hast schon eine saubere, portable Basis....

Das mit dem "genauso performant" kann hingegen nicht stimmen - die Frage ist nur, ob es Relevanz hat

Ad design patterns siehe mein voriges Posting... Bei Spielen machen sie absolut Sinn - zB austauschbare AI und ähnliches - nur ist das eben /gleichwertig/ zum registrieren von Callbacks (was anderes ist ja eine VMT eh nicht).

Tatsächlich kosten aber VMT-Aufrufe ordentlich Zeit - die man bei prozedural sparen kann...

IMHO machen die OO-Freunde immer folgenden Fehler:
Sie vergleichen die Performance einer APP, die einer in C++ geschrieben hat (unter impliziter Ausnutzung aller "Beschleunigungen", die saubere, mitgelieferte Klassen schon brachten wie zB perfect hashes) - und stellen die Performance einer C-App gegenüber, wo der Programmierer viel "selbstgestrickt" hat bzw. nicht die passenden gnu-libs verwendet hat...

Das Ergebnis von sowas ist klar: C++ zumindest gleich schnell bei großen Daten - und definitiv besser wartbar. Tatsächlich sehen sauber optimierte C-Programme aber meist komplett anders aus als in den Vergleichen

Ein Beispiel, das IMHO für mich spricht:
Eclipse mit Swing. Eclipse ist auf meinem 1GHz-Lappy mit 512MB Ram IMHO saulangsam - verglichen mit Delphi (brav prozedural geschrieben) auf meinem Pentium133 mit 64MB Ram... Und das /trotz/ JIT, ...
Und ich denke schon, daß die Jahre an Entwicklungszeit, die dazwischen liegen, eigentlich bewirken müßten, daß bei gleicher Funktionalität des Outputs, zumindest gleich guten Entwicklern und gleich performanten Ansätzen Eclipse heute flotter sein müßte...

GLUT mag das WGL und GLX wrappen.... PBuffer sind trotzdem immer noch ein Saukrampf, und definitiv nötig für diverse Effekte (Render-to-Texture-basierte). Aber es gibt wie gesagt die neue Framebuffer Objects (FBO) Extension, die die PBuffer ersetzen soll, aber die ist immer noch eine EXT und keine ARB Extension, und daher noch nicht so verbreitet.

Womit wir eh beim erwähnten Hauptproblem der Portabilität sind... GLUT mag Anwendungscode kapseln (also generelle WGL/GLX Initialisierung), aber Extensions können immer noch ein Krampf sein, und zwar nicht nur Cross-Platform (also Betriebssystemübergreifend), sondern auch Cross-GPU (ATI/NVIDIA/andere).

Die Situation ist mit OpenGL 2.0 und dem ARB-ratifizierten ARB Fragment/Vertex Programs sowieo der GL Shading Language (GLSL) schon besser geworden als zu Zeiten wo jede GPU-Architektur eigene vendor-spezifische Extensions mitbrachte für Shader.

Trotzdem gibt es immer noch Punkte wo genau dieser Faktor ziemliche Kopfschmerzen bereitet. Das geht soweit dass selbst die Default-Werte für die States in OpenGL oft anders sind bei ATI/NVIDIA (wobei hier generell eher vermutet wird dass hier ATI pfuscht).

Ad C vs C++:
Dein Argument ist, dass man in C viel optimieren kann wenn man selbst strickt (und quasi die Wartbarkeit verschlechtert) - nur, dann kann man genauso das Argument gelten lassen, dass man in C++ dieselben Optimierungen anwenden kann (da C++ ja großteils eine Obermenge von C ist)... wenn man eh auf Wartbarkeit schei*t, kann man ja beides in derselben Weise optimieren. Obwohl man da natürlich diskutieren kann ob ein C++ Code der großteils gleich wie C Code ist noch C++ Code ist... aber C++ ist wie gesagt definiert als (großteils) Obermenge von C (Natürliche Zahlen sind ja auch Reele Zahlen, da Reele Zahlen eine Obermenge der Natürlichen ist - nur um mal ein mathematisches Beispiel zu bringen).

Ad Delphi: Die Delphi IDE wurde auch objektorientiert programmiert, und zwar in der Delphi-eigenen VCL Library.

Ad Delphi...
Delphi wurde mal in Assembler geschrieben... Zumindest steht das als protzig im Delphi(1)-Manual

[was ich ihnen aber auch nicht so glaubte, hehe]

C ist IMHO (und hier zugegeben sehr IMHO

) eine Obermenge von C++, weil du mehr Möglichkeiten hast.

C++ ist einfach in vielen Punkten restriktiver - was ja Sinn macht.... Aber nachdem sich C++ in C transformieren läßt (Bin mir jetzt unsicher, aber war g++ nicht gaaanz am Anfang ein C++ -> C-Converter ???) aber C nicht in C++ (weil's dasselbe bleibt

) ... Nun ja, IMHO eine Frage des Blickpunktes.

IMHO bringen objektorientierte Sprachen die saubere Kapselung der Objekte mit Members und Methoden... Nur erkenne ich oft erst auf den 2. Blick (und mit viel gutem Willen, hehe) den Unterschied zur Kapselung von priv. Variablen und Funktionen in Bibliotheken. IMHO lassen sich oft (und sogar aus derselben Abstraktionsschicht) dieselben Probleme auf demselben Weg in C lösen (wo du halt Libraries verwendest) oder in C++ (Wo du halt Klassen verwendest).

Wobei C und C++ hier natürlich nur beliebige Repräsentanten für Proz. vs. OO sein sollen....

Zu meinem Beispiel mit dem C/C++-Source:
In OO verwendest du oft automatisch fertige Klassen, die schon brav optimieren - weil du es oft gar nicht anders sinnvoll realisieren kannst (zB Java-Hashtable). Bei proz. Source mußt du halt (zB) die gnu-Bibliotheken kennen, sonst schreibst halt schnell sinnlosen Schrott.

Lernen mußt du da wie dort zum sinnvoll Coden - hier die Klassenbibliotheken, dort die "normalen" Libs - wobei in der proz. Welt gerne und oft die Libs nicht genutzt werden... Leider. Insoferne bietet OO durch manche Restriktionen gerne auch oft mal saubereren Code... Zugegeben (so eben in öfters gesehenen "Vergleichstests".

Trotz allem erscheint es logisch und einsichtig, daß VMT-Zugriffe, late-Binding, ... Zeit kosten /müssen/ - und nicht zu knapp.

Aber ich gab' eh schon anfangs zu: Die Frage ist nur, ob das Performance-Delta Relevanz hat

Ad Delphi...Delphi wurde mal in Assembler geschrieben... Zumindest steht
das als protzig im Delphi(1)-Manual [was ich ihnen aber auch nicht so
glaubte, hehe]

Der Compiler, ja. Der ist auch wirklich sauschnell. Die IDE wurde aber mit dem Delphi-Compiler selbst sowie der mitgelieferten Visual Component Library (VCL) gemacht.

C ist IMHO (und hier zugegeben sehr IMHO ) eine Obermenge von
C++, weil du mehr Möglichkeiten hast.C++ ist einfach in vielen Punkten
restriktiver - was ja Sinn macht....

Das halte ich für absolut falsch

C++ ist definitiv eine sprachliche Obermenge von C, da in C++ die meisten C Sprachkonstrukte genauso funktionieren.

C++ ist nur dann restriktiv wenn du es so machst (was oft Sinn macht), aber es ist kein Zwang dazu.

Aber nachdem sich C++ in C transformieren
läßt (Bin mir jetzt unsicher, aber war g++ nicht gaaanz am Anfang ein C++ ->
C-Converter ???) aber C nicht in C++ (weil's dasselbe bleibt ) ... Nun ja,
IMHO eine Frage des Blickpunktes.

Ich spreche jedenfalls von der sprachtheoretischen Obermenge die auch etwa in Compilerbau sowie Theorie der Informatik diskutiert wird (kontextfreie Grammatiken usw.).

IMHO bringen objektorientierte Sprachen die
saubere Kapselung der Objekte mit Members und Methoden... Nur erkenne ich oft
erst auf den 2. Blick (und mit viel gutem Willen, hehe) den Unterschied zur
Kapselung von priv. Variablen und Funktionen in Bibliotheken. IMHO lassen sich
oft (und sogar aus derselben Abstraktionsschicht) dieselben Probleme auf
demselben Weg in C lösen (wo du halt Libraries verwendest) oder in C++ (Wo du
halt Klassen verwendest).

Libraries hast du in C++ genauso, das ist eigentlich eine andere Ebene. Die Kapselung an sich ist ja noch nicht wirklich das OO Kriterium per se (sondern nur die mittlerweile fast 30 Jahre alte OO-Grundidee, "reale Objekte" auf Software-Strukturen abzubilden). Erst die Vererbung bzw. das Superkonzept/Subkonzept Prinzip ist das wirklich entscheidende.

Wobei C und C++ hier natürlich nur beliebige
Repräsentanten für Proz. vs. OO sein sollen....

Wobei wie gesagt C++ sowohl prozedural als auch objektorientiert ist, also C quasi miteinschließt...

Zu meinem Beispiel mit dem
C/C++-Source:In OO verwendest du oft automatisch fertige Klassen, die schon
brav optimieren - weil du es oft gar nicht anders sinnvoll realisieren kannst
(zB Java-Hashtable). Bei proz. Source mußt du halt (zB) die gnu-Bibliotheken
kennen, sonst schreibst halt schnell sinnlosen Schrott.Lernen mußt du da wie
dort zum sinnvoll Coden - hier die Klassenbibliotheken, dort die "normalen"
Libs - wobei in der proz. Welt gerne und oft die Libs nicht genutzt werden...
Leider. Insoferne bietet OO durch manche Restriktionen gerne auch oft mal
saubereren Code... Zugegeben (so eben in öfters gesehenen "Vergleichstests".
Trotz allem erscheint es logisch und einsichtig, daß VMT-Zugriffe,
late-Binding, ... Zeit kosten /müssen/ - und nicht zu knapp.Aber ich gab' eh
schon anfangs zu: Die Frage ist nur, ob das Performance-Delta Relevanz hat

Wie gesagt, bei einfachen Sortierprogrammen mag dieses Performance-Plus Relevanz haben, heutige Software ist in der Regel komplex genug, dass man eher das Nachsehen hat wenn man wirklich alles selber programmiert oder "allzu low-level" programmiert (ich denk nur an Multithreading).

Und nachdem C++ eine Obermenge von C ist, also die C-Konstrukte mehr oder weniger komplett einschließt, lassen sich für performance-kritische Abschnitte durchaus Dinge "in C" lösen.

Außerdem ist algorithmische Effizienz um einges wichtiger heutzutage als die paar CPU-Zyklen, die man durch C-Rumhackerei einspart (speziell bei heutigen Rechnerarchitekturen, wo Instruktionen nicht mehr unbedingt sequentiell abgearbeitet werden bzw bei Parallelverarbeitung).

Außerdem ist algorithmische Effizienz um einges wichtiger heutzutage als die paar CPU-Zyklen, die man durch C-Rumhackerei einspart (speziell bei heutigen Rechnerarchitekturen, wo Instruktionen nicht mehr unbedingt sequentiell abgearbeitet werden bzw bei Parallelverarbeitung).

Aber genau drum geht's mir ja im Beispiel... Durch die Implizite Verwendung von Hashtables hast halt ein O(ld(n)) oder so... wärend du beim Standard-faulen-C-Coder halt oft ne primitiv verkettete Liste siehst (so auch gelernt in Algodat

) - mit O(1).

VMT kann teuer werden, wenn du wirklich am Ende der Leistungsfähigkeit des Proz. codest... zB die guten alten 3D-Spiele mit Raycasten via Vesa-Treiber oder ModeX... Oder beim Kernel schreiben... Funktionen, die 1000x/sec aufgerufen werden, würde ich ungern sauber in OO sehen..

Anyways, wir kommen ab - und ich will ja OO nicht verteufeln, mag es aber auch nicht als den heiligen Gral sehen

.

Außerdem habe ich den Verdacht, daß die große Reusability, die in OO als /das/ Marketingargument gesehen wird, in Wirklichkeit so ein dickes, fettes, ausgefressenes trojanisches Pferd ist - daß sich die unschuldigen Programmierer eingetreten haben

Denn /natürlich/ ist das besser reusable... Allerdings mußtest Du dann um soviel mehr Zeit in das Design stecken, daß du ein Produkt, das Du sonst nur 1x hättest verkaufen müssen (um die Kosten reinzukriegen) nun in mind. 4x verkaufen mußt

Für StandardSW scheint OO weiter sehr gut - bei IndividualSW wird's wohl noch schwieriger, den Aufwand zu rechnen...

War auf jeden Fall ein netter Thread mit Dir!

Naja, man sollte immer wissen - auch wenn man die STL verwendet - was jetzt der Aufwand für diverse Operationen ist.

Und für so Messungen welche Funktionen jetzt häufig aufgerufen werden gibt's ja diverse Tools (Profiler u.ä.).

Das ist übrigens bei Computergrafik-Anwendungen wiederum komplizierter, da es hier ja noch die GPU als "Zusatzprozessor" gibt, und da der Flaschenhals in verschiedenen Stufen dieser Pipeline sitzen kann (und es logischerweise nur dort wo der Flaschenhals liegt, Sinn macht, zu optimieren).

C/C++/Assembler und dann noch die entsprechenden Grafik"sprachen" (DirectX...).

kann ich also alleine mit der sprache direktX ein spiel schreiben?

AF - Austrian Forces

Nein.

ok... c# und directX... dann kann ein spiel entstehen... ok
thx

AF - Austrian Forces

DirectX ist keine Sprache, sondern eine API (Programmierschnittstelle). Auf die kannst du über Programmiersprachen zugreifen.

interessant... schon mal damit 'programmiert'?

AF - Austrian Forces

Ja, zur Zeit programmiere ich in DirectX.

Managed DirectX 9 von Tom Miller
falls wer das buch kennt... gibts das auch auf deutsch? ich find im intanet nur englische exemplare...
thx

AF - Austrian Forces

wenn du ernsthaft programmieren willst wirst um englische literatur leider nicht herumkommen..

() ascii ribbon campaign - against html in mail and news
/\ - against microsoft attachments

... naja... dann eben auf englisch... ^^
danke, mfg

AF - Austrian Forces

Wieso gerade DirectX oder C# ?

Wenn du noch keine Sprache kennst - wieso hast Dich schon festgelegt ? Schwer unklar...

ich hab mir gedacht... c# ist die 'neuste' sprache, und darum 'zukunftssicher', was ich aber nur vermuten kann, weil ich mich in diesem gebiet noch nicht so richtig auskenne...
was würdest du vorschlagen?
mfg

AF - Austrian Forces

http://forum.geizhals.at/t377567,2967201.html#2967201

Bei nur-Microsoft-Sprachen zu bleiben ist IMHO das allerallerunsicherste...
Ich habe mich durch die diversen Office-Sprachen gequält (zB Word-Basic mit DDE-Unterstützung, ...) - in der nächsten Version gab's die so nicht mehr - alles Sinnlos

.

Dann der OLE-Kram... - jetzt ist aber ActiveX aktuell - wieder umsonst

Wenn du aber bei einer Sprache bleibst, die es auf vielen Systemen gibt, hast mehr Chancen, daß es die in 5 Jahren auch noch gibt...

Ach ja, mit Objektorientierten Sprachen wie Java, C#, Smalltalk, C++ würde ich sowieso nicht anfangen - denn da solltest erst programmieren können, damit du die Konzepte, gelösten Probleme und mit diesem Ansatz neu entstandenen Probleme überhaupt nutzen kannst.

Beginne lieber Prozedural - zum Lernen am Besten mit Pascal (fpc ist gratis) oder C...
Und verabschiede dich mal die ersten 1-2 Jahre von GUI-Programmierung. Du wirst zwar was hinkriegen - die Tool-Unterstützung ist da, keine Frage. Nur /was/ du hinkriegst wird grotesk

Beginne mit C, wenn du die Syntax hast, lies dich zB in http://www.gnu.org/software/libc/manual/
ein... Dann hast du einen Super Startpunkt - und die Konzepte gelten auf praktisch allen OSsen... Dann hast du mal das "Big Picture" - und dann mach weiter, wo's Dir wirklich Spaß macht..

Just my 2 cents

danke für deinen professionellen rat! ^^
ich werd mich bemühen... und irgndwann schreib ich ein spiel! *g*
mfg

AF - Austrian Forces

May the source be with you, Luke...

Anfangs solltest echt viel Source lesen... Schnapp dir sourcen von sf.net...
Vielleicht beginnst du ja mal einfach am Mitentwickeln von Spielen dort...

viel Glück !
gepeinigter

Ich stimme zu, allerdings sollte man dann trotzdem nicht zu lange warten darauf, sich objektorientierte Konzepte anzueignen.

Ich komm nämlich immer wieder drauf dass "Die-Hard"-Prozedural-Programmierer es mit der Zeit immer schwerer haben, "objektorientiert" zu denken.

C# ist nicht die "neueste Sprache"... es werden die ganze Zeit neue Sprachen erfunden.

C# mit Managed DirectX ist sicher kein schlechter Eintrittspunkt.

"Zukunftssicher" bist allerdings eher mit C++. Ist halt doch Industriestandard, und es sind Tonnen an vorhandenem Code dafür vorhanden.

Ich tät mir an deiner Stelle mal einlesen:

http://www.gamedev.net
http://www.gamasutra.com
nehe.gamedev.net

Und falls du kurz vor einem Studium in Wien bist, würd ich mir das Studium "Medieninformatik" (Zweig Computergraphik) auf der TU Wien anschauen - da tut man solche Sachen. Das Institut für Computergraphik der TU Wien hat auch einen Spieleschwerpunkt.

wow, danke! ^^
ja... hab nämlich schon an so ein studium gedacht!
computitional intelligence... was ist das eigntllich für eines?
danke, mfg

AF - Austrian Forces

In Computational Intelligence geht's eher um so Sachen wie künstliche Intelligenz, Expertensysteme, Semantische Netze, usw.

Hat eher nur am Rand mit Spielen zu tun (obwohl die AI-Forschung sicher auch was für Spiele bringt).

cool... i geh ameu davon aus das de studien zweige überhäuft sind? stimmt des? oda san de so schwa das es sowieso wenig schoffn?

danke, mfg

AF - Austrian Forces

Des sollt eigentlich wurscht sein. Wenn's einen wirklich interessiert sollt des ka Grund sein, des ned zu studieren.

Informatik ist zwar generell schon sehr "beliebt" als Studium, aber die Überhäufung legt sich mit der Zeit (ist hauptsächlich im Grundstudium so).

asooo... na, des wird mi eh net hindern! ^^

danke, mfg

AF - Austrian Forces

eine frage hätt i nu: wie oder mit welchen sprachen kau ma physik engine programmieren?
danke, mfg

AF - Austrian Forces

in jeder - aber die mathematik dazu sollte dir bestens bekannt sein ..

Student: Wäre das z.B. ein Thema für eine Dissertation?
Vortragender: Wenn Sie dieses Problem lösen, können Sie die Abkürzung über den Nobelpreis nehmen.

Physikengine macht man nicht selber:

http://de.wikipedia.org/wiki/Physikengine

Freunde von mir verwenden die Novodex/PhysX

mfg Switi
--
Gibts noch Leute, die die Signatur nicht blocken?
C++, Mono, C#, Java, XML, Open Source developer
Ubuntu - Linux for Human Beings

thx!

AF - Austrian Forces

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung