Spiele mit C++ & DirectX programmieren.. wie fange ich an?
-
aber wie gesagt, es gibt noch mehere spezielle auf die sprache bezogenen sachen. belassen wir es jetzt dabei. freuen wir uns des programmierens.
-
kleiner nachtrag
ich sollte erwähnen, das mir nicht darum geht c++ als ganzes vollkommen zu erneuern.
die syntax in c und auch c++ ist an machen stellen vorbildhaft und nicht verbesserungsfähig. z.b. das bilden von blöcken mit {} kann man kaum effektiver darstellen. deshalb wird es selbst in einer perfekten sprache viele dinge geben, die genauso aussehen wie in c/c++.
-
Original erstellt von KXII:
oder wie soll ein compiler z.b. die hintergrundfarbe einer anwendung selbst bestimmen/errechnen?Hä?
Original erstellt von KXII:
früher (teilweise auch heute noch) hat man programme compilert, indem man alle compilereinstellungen als parameter "von hand" der compiler.exe übergeben hat. heute (dem fortschritt sei dank), kann man diese compiler-einstellungen über komfortable steuerlemente (-> radiobuttons, comboboxes) angeben, und der compiler gegneriert automatisch die passende compiler.exe-parameterliste.Hast Du noch nie was von Makefiles gehört? Die gibts schon deutlich länger als DOS-.EXEs.
Original erstellt von KXII:
und eben genau das selbe hat man z.b. auch bei den header dateien. und es ist egal wieviele klassen man hat und wieviel querabhängigkeiten man hat, sie sind alle BERECHENBAR. deshalb kann sie ein compiler selber berechnen und sich darum kümmern, ohne geschwindigkeitsverlust.Was soll der Compiler Deiner Meinung nach denn nun konkret machen?
Alle Header automatisch #includen?
-
Original erstellt von nman:
**Original erstellt von KXII:
oder wie soll ein compiler z.b. die hintergrundfarbe einer anwendung selbst bestimmen/errechnen?Hä?
**
das sollte nur ein beispiel sein. ich gebe zu nicht garade sinnvoll. vielleicht gefällt dir folgendes beispiel besser: ... oder wie soll ein compiler, die farbe einer lichtquelle in einer directx anwendung selbst bestimmen/errechnen?
Original erstellt von KXII:
**früher (teilweise auch heute noch) hat man programme compilert, indem man alle compilereinstellungen als parameter "von hand" der compiler.exe übergeben hat. heute (dem fortschritt sei dank), kann man diese compiler-einstellungen über komfortable steuerlemente (-> radiobuttons, comboboxes) angeben, und der compiler gegneriert automatisch die passende compiler.exe-parameterliste.Hast Du noch nie was von Makefiles gehört? Die gibts schon deutlich länger als DOS-.EXEs.
**
ich kenne sehr wohl makefiles, aber das ist das selbe in grün. man muss die einstellungen auch da "von hand" angeben. wer heute noch mit makefiles programmiert, der tut mir echt leid !!!
Original erstellt von KXII:
und eben genau das selbe hat man z.b. auch bei den header dateien. und es ist egal wieviele klassen man hat und wieviel querabhängigkeiten man hat, sie sind alle BERECHENBAR. deshalb kann sie ein compiler selber berechnen und sich darum kümmern, ohne geschwindigkeitsverlust.
Was soll der Compiler Deiner Meinung nach denn nun konkret machen?
Alle Header automatisch #includen?JA!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
du hast es erkannt. wow! nicht schlecht.
[ Dieser Beitrag wurde am 24.05.2003 um 23:04 Uhr von KXII editiert. ]
-
Original erstellt von KXII:
man muss die einstellungen auch da "per hand" angeben. wer heute noch mit makefiles programmiert, der tut mir echt leid !!!Du musst Deine Einstellungen immer von Hand angeben, und ob Du das jetzt per Maus oder per Tastatur machst ist doch wohl völlig egal.
Wenn Dir Benutzer von Makefiles leidtun dann hast Du selbst noch nie welche verwendet.Original erstellt von KXII:
JA!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!Deine Rufzeichentaste klemmt. (Vielleicht tust Du Dir deswegen mit Mauseingaben leichter?)
Wozu? Damit mir noch mehr Kontrolle über das was ich tue abgenommen wird?
Ein Compiler der sowas macht ist so ziemlich das Gleiche wie einer der "Anwendungshintergrundfarben" oä automatisch "berechnet".[ Dieser Beitrag wurde am 24.05.2003 um 23:09 Uhr von nman editiert. ]
-
KXII: Übrigens: Es gibt nicht DIE perfekte Programmiersprache, es wird sie auch nie geben, alles was es geben kann ist eine gute Programmiersprache für einen bestimmten Zweck. (Vgl.: "When all you have is a hammer, everything looks like a nail.")
-
lol!
man merkt das du dich mit der materie noch nicht auseinandergesetzt hast.
es kommt bei der angabe der compilereinstellungen nicht auf das eingabemedium an, sondern auf die komplexität mit der diese eingaben überhaupt erst gemacht werden können. es ist viel einfach mit der maus ODER AUCH DER TASTATUR aus einer dropdownlistbox mehrere auswahlen zu treffen, als diese einstellungen umständlich per hand einzutippen und durch copy und paste immer wieder an die richtige stelle der makefile zu platzieren. an der uni musste ich lange genug mit makefiles arbeiten, also bitte erzähl mir nichts über makefiles! wenn du es dir beim programmieren gerne umständlich machst; bitteschön, ich möchte ich nicht davon abhalten.
erstellt von nman:
"
Wozu? Damit mir noch mehr Kontrolle über das was ich tue abgenommen wird?
Ein Compiler der sowas macht ist so ziemlich das Gleiche wie einer der "Anwendungshintergrundfarben" oä automatisch "berechnet".
"man gibt überhaupt keine kontrolle an den compiler ab, und zwar überhaupt keine, denn das richtige einbinden der headerdateien musst du sowieso machen, sonst lässt sich dein programm nicht kompilieren.
und es ist absolut nicht das selbe, ob ein programm eine farbe oder änliches erraten kann, oder ob er automatisierbare dinge automatisiert.
tut mir leid, aber deine aussagen sind falsch.
vielleicht gibt es keine ultraperfektemegaprogrammiersprache mit der man alles mit nur einem mausklick programmieren kann, aber ich sehe noch einiges an verbesserungspotential heutiger programmiersprachen.
-
Original erstellt von KXII:
lol!
man merkt das du dich mit der materie noch nicht auseinandergesetzt hast.Durch solche Einwürfe werden Deine Aussagen weder interessanter noch informativer aber wenn Du Spaß daran hast...
Original erstellt von KXII:
es ist viel einfach mit der maus ODER AUCH DER TASTATUR aus einer dropdownlistbox mehrere auswahlen zu treffen, als diese einstellungen umständlich per hand einzutippenWarum? Warum soll ich mich wenn ich weiß dass ich mein Projekt gerne mit "-march=athlon -O3 -fomit-frame-pointer -w -pipe" kompilieren möchte durch diverse Tabs für unterschiedliche Einstellungsarten quälen?
Wenn ich eine Pizza telefonisch bestelle dann läuft das doch auch nicht so ab dass mich eine freundliche Stimme am Telefon fragt "Möchten Sie eine .) Pizza Insalata .) Pizza Quattro Formaggi .) Pizza Spinaci..." und ich am Ende sage "Ich hätte gerne die Spinaci" nachdem ich mir alle Alternativen angehört habe; ich rufe einfach bei der Pizzeria meines Vertrauens an, sage denen meinen Namen und meine Telefonnummer und dass ich eine Margharita mit doppelt Käse, Mais und Zwiebel haben möchte.Original erstellt von KXII:
und durch copy und paste immer wieder an die richtige stelle der makefile zu platzieren.Immer dann wenn in der Beschreibung eines Arbeitsablaufes "Copy & Paste" und "immer wieder" auftauchen sollte man sich überlegen ob man alles richtig gemacht hat, wenn man Makefiles richtig verwendet besteht keine Notwendigkeit für Copy&Paste-Orgien.
Original erstellt von KXII:
an der uni musste ich lange genug mit makefiles arbeiten, also bitte erzähl mir nichts über makefiles!Wenn Du so lange damit gearbeitet hast wäre es wahrscheinlich sinnvoll gewesen wenn Du Dich über die Verwendungsmöglichkeiten genauer informiert hättest.
Original erstellt von KXII:
man gibt überhaupt keine kontrolle an den compiler ab, und zwar überhaupt keine, denn das richtige einbinden der headerdateien musst du sowieso machen, sonst lässt sich dein programm nicht kompilieren.Eben.
Original erstellt von KXII:
und es ist absolut nicht das selbe, ob ein programm eine farbe oder änliches erraten kann, oder ob er automatisierbare dinge automatisiert.Wie ließe sich was automatisieren? Du drischt hier leider nur Phrasen ohne konkrete Beispiele zu bringen.
Original erstellt von KXII:
tut mir leid, aber deine aussagen sind falsch.Wenn Du das so genau weißt warum postest Du dann überhaupt in einem Forum?
Was hat Meinungsaustausch für einen Sinn wenn die anderen sowieso nur falsche Aussagen bringen?Original erstellt von KXII:
vielleicht gibt es keine ultraperfektemegaprogrammiersprache mit der man alles mit nur einem mausklick programmieren kann, aber ich sehe noch einiges an verbesserungspotential heutiger programmiersprachen.Ich auch, aber es gibt in sehr vielen Fällen schon sehr gute Lösungen und wenn man nicht versucht alles mit einer Sprache zu lösen die einfach nicht für alle möglichen Aufgabenstellungen konzipiert ist erleichtert das die Sache maßgeblich.
-
ok, jetzt ist endgültig schluss. hier im forum gibt echt mehr noobs als alles andere. tggc hat mich vor ein paar tagen auch schon genervt und jetzt du.
es ist ein leichtes dinge falsch zu machen oder kaputt zu reden oder anders gesagt, das gegenteil von etwas konkretem zu tun. typisches politikerhandeln... alles kaputtreden. hauptsache dummgelabert!
ich muss niemanden zu seinem glück zwingen und das werde ich auch garantiert nicht tun!
cu
-
@KXII
ich halte mich jetzt einfach mal neutral und geb dir nen hinweis
du hast, so wie ich das sehe, bis jetzt nur das bsp mit den header-files gebracht, das kann aber ja nicht das einzige sein, was du verbessern willst, oder!?
glaub mir: mehr argumente und beispiele machen dich wesentlich "glaubhafter" (ich weiß, das ist das falsche wort, mir fällt nur nix besseres ein -.-)die compilereinstellungen zähln übrigens nicht -> ide
-
Original erstellt von KXII:
**ok, jetzt ist endgültig schluss. hier im forum gibt echt mehr noobs als alles andere. tggc hat mich vor ein paar tagen auch schon genervt und jetzt du.es ist ein leichtes dinge falsch zu machen oder kaputt zu reden oder anders gesagt, das gegenteil von etwas konkretem zu tun. typisches politikerhandeln... alles kaputtreden. hauptsache dummgelabert!**
Ich hab dich doch auch lieb.
-
Ich verstehe KXII schon irgendwie.
Mit MAKE-Files möchte ich auch net hantieren.
Klar, wenn das einmal für ein Projekt steht, is' alles gut.
Aber sobald sich da wieder was ändert, vor allem Abhängigkeiten, kann man das ganze Ding "von Hand" "debuggen"...Compiler-Schalter in den IDEs, die per Klick essentielle Optionen togglen, sind schon Gold wert. Klar wird man damit ggf. nicht das i-Tüpfelchen an Leistung aus einem gut dokumentierten Kommandozeilen-Compiler rausholen.
Wenn man genau weiß, WAS man WIE will, kann man ja ruhig die gute Kommandozeile nehmen und "cl -LEAN_AND_MEAN -fucking_fast -for_AMD_only -rocks -1337" verwenden...
Wer darauf abfährt...Header-Dateien selbst inkludieren wäre schon geil. Hat er recht.
Und vor allem diese INCLUDE-ONLY-ONCE-Gatter automatisieren...
#IFNDEF stuff
#DEFINE stuff...bla...
#ENDIF
Was soll der Scheiß?? Dat is' echt übel.
Da baut man sich am Besten Header-Templates für!Da könnte man noch einiges von Java abschneiden.
Vielleicht Mehrfachvererbung (stattdessen: Interfaces) und Zeiger (stattdessen: Referenzen) ganz rausnehmen. Das funktioniert ja auch ALLES so unter Java, ohne diese Sachen!
Daß man die Zugehörigkeit von Methoden zu Klassen in 'nem Header-File schreibt (mit private etc.), aber die Methoden selber dann im alten strukturierten (nicht-OO) "C-Stil" in die CPP-Datei klatscht und mit dem Scope-Operator übersäht mißfällt mir auch irgendwie...
Aber egal. C++ ist mächtig. Und mit gehörig Disziplin klappt es auch alles so wie man will...
MfG Sarge
-
Original erstellt von <Sgt. Nukem>:
**Header-Dateien selbst inkludieren wäre schon geil. Hat er recht.
Und vor allem diese INCLUDE-ONLY-ONCE-Gatter automatisieren...
#IFNDEF stuff
#DEFINE stuff...bla...
#ENDIF
Was soll der Scheiß?? Dat is' echt übel.
Da baut man sich am Besten Header-Templates für!**#pragma once
Vielleicht Mehrfachvererbung (stattdessen: Interfaces) und Zeiger (stattdessen: Referenzen) ganz rausnehmen. Das funktioniert ja auch ALLES so unter Java, ohne diese Sachen!
Für Flexibilität und Kontrolle nehme ich gerne eine komplexere Syntax auf mich.
Daß man die Zugehörigkeit von Methoden zu Klassen in 'nem Header-File schreibt (mit private etc.), aber die Methoden selber dann im alten strukturierten (nicht-OO) "C-Stil" in die CPP-Datei klatscht und mit dem Scope-Operator übersäht mißfällt mir auch irgendwie...
Ich weiß nicht, was daran C-Stil sein soll. Es ist auch falsch, krampfhaft alles "OOP" machen zu wollen, "alles muss in eine Klasse". Das ist _nicht_ OOP.
Du musst es ja nicht so machen; kannst auch alles in den Header klatschen. Dann hast du aber noch längere Kompilierzeiten und weniger Übersicht.
-
Original erstellt von <OOP>:
#pragma onceWow. Dasselbe in grün.
Für Flexibilität und Kontrolle nehme ich gerne eine komplexere Syntax auf mich.
Gibt's da was spezielles, was Du darunter verstehst...?!
Naja, ich weiß net wie das mit den FunctionPointern is', wie man die ersetzen könnte, o.ä. - aber sonst!?Ich weiß nicht, was daran C-Stil sein soll. Es ist auch falsch, krampfhaft alles "OOP" machen zu wollen, "alles muss in eine Klasse". Das ist _nicht_ OOP.
Du musst es ja nicht so machen; kannst auch alles in den Header klatschen. Dann hast du aber noch längere Kompilierzeiten und weniger Übersicht.
C-Stil im Sinne von strukturiert ausschauend -> Erst die Header-Datei macht die Ansammlung von Methoden zur Klasse.
Daß man auch strukturiert coden kann is' klar. Hab' ich auch nix gegen gesagt.Klar kann ich das! Aber wie sinnvoll ist das? Ich kann auch alles in 'ne TXT-Datei reinschreiben, und diese inkludieren... wow. Tadaaaa...
Naja, egal. Die Syntax is' auf jedenfall sonst ziemlich i.O.
-
also merfachvererbung vermisse ich bei java durchaus, hab mich erst am donnerstag wieder drüber aufgeregt. die sache mit den interfaces verschlimmbessert alles im prinzip ja auch nur...
-
Original erstellt von KXII:
ok, jetzt ist endgültig schluss. hier im forum gibt echt mehr noobs als alles andere. tggc hat mich vor ein paar tagen auch schon genervt und jetzt du.Also verbannst Du mich jetzt endgültig aus dem Forum? :p
es ist ein leichtes dinge falsch zu machen oder kaputt zu reden oder anders gesagt, das gegenteil von etwas konkretem zu tun. typisches politikerhandeln... alles kaputtreden. hauptsache dummgelabert!
Es gibt aber auch die Art Politiker die ständig nur betont dass alles besser und gaanz toll wird und alle zufrieden sein werden wenn man sie wählt...
ich muss niemanden zu seinem glück zwingen und das werde ich auch garantiert nicht tun!
*lol* Wäre mein Glück denn eine überladene IDE?
Wenn Du ein paar echte Argumente/ weniger schwammige Aussagen brächtest könnte man auch auf Deine Posts eingehen, so kann man sich nur fragen ob Du das alles hier Ernst meinst oder nur herumtrollst.
-
@Alle
So wie ich das verstanden habe, sagt KXII ja nicht, dass C++ an sich Schrott ist, sondern dass es durchaus verbesserungsfähige Aspekte gibt. Und da muss ich ihm absolut Recht geben. Ich zähle hier mal ein paar zusätzliche Beispiel auf, die mich persönlich an C++ stören.Bsp. 1
class Object{
private:
Window ownerWnd;
}class Window{
std::list<Object*> li;
};Das klappt z.B. so nicht, da die Klasse Window dem Compiler noch nicht bekannt gemacht wurde, wenn man Sie als Member von Object deklariert. Wenn man die Klassen in der umgekehrten Reihenfolge schreibt hat man dasselbe Problem. Da hilft nur folgendes:
class Object;
class Window;vor den Klassendedeklarationen zu schreiben. Was soll den das ???
Da könnte man doch erwarten, dass des Compiler die entsprechenden Klassendeklarationen in den dem Projekt angehörigen CPP Dateien suchen geht.
Das gleiche sehe ich für die Funktionsprototypen. Natürlich sind Funktionsprototypen sinnvoll bei vorkompilierten statischen oder dynamischen Bibliotheken doch für kleine Projekte sind die nur ärgerlich. Aus diesem Grund könnte man sie ja freiwillig machen ? Der Compiler sucht nach den Prototypen und wenn er diese nicht findet, dann sucht er halt direkt nach den Implementationen.Bsp 2.
D3DPRESENT_PARAMETERS d3dpp = {0};
d3dpp.Windowed = false;
d3dpp.DeviceWindow = hWnd;
d3dpp.FullScreen_RefreshRate = 85;
d3dpp.FullScreen_PresentRate = D3DPRESENT_RATE_ONE;
d3dpp.BackBufferCount = 1;
usw.Andere Sprachen wie z.B. Delphi kennen da ein Schlüsselwort "with". Das würde dann in etwa so aussehen (eine Mögliche Art, das in C++ Synthaktisch zu implementieren):
D3DPRESENT_PARAMETERS d3dpp = {0};
with(d3dpp){
Windowed = false;
DeviceWindow = hWnd;
FullScreen_RefreshRate = 85;
FullScreen_PresentRate = D3DPRESENT_RATE_ONE;
BackBufferCount = 1;
}Bsp. 3
Was ich in C++ aber auch in Java sehr vermisse ist ein ausgeklügeltes System für Mengenangaben wie si z.B. Delphi anbietet.Bsp. 4
Wie währe es mit einer Sprachunterstützen Form von Regular - Expressions ?Bsp. 5
Strings: Brrrrrrrr......Bsp. 6
STL: Brrrrrrrrrrrrrrrrrrrrrrrrrrrrr.Zu den letzten Beiden: Ich habe bisher keine Sprache gesehen (was nicht heissen soll, dass es sie nicht gibt !) Die dynamische Datenstrukturen direkt in der Sprache unterstützen.
Bsp. 7
Diverse Objektorientierte Feauters wie z.B. statische Konstruktoren oder Super Konstuktoren, wie sie Java anbieten:---------------- C++ ----------------
class Object{
private:
static unsigned int cRef;
public:
Object(void);
~Object(void);
};unsigned int Object::cRef = 0;
Object::Object(void){
Object::cRef++;
}Object::~Object(void){
Object::cRef--;
}
------------------------------------------------------- Java ---------------
class Object{
private static int cRef;static{
Object.byte = 0;
}public Object(){
Object.cRef++;
}
protected finalize(){
Object.cRef--;
}
}
--------------------------------------Bsp. 8
Die Datentypen missfallen mir ausgesprochen:
in einem 32 - Bit System ist z.B. ein int gleich lang wie ein long und in 16 - Bit System ist int gleich lang wie ein short. Das finde ich Schwachsinn.
Dann das signed / unsigned :C++
unsigned char kleineVariable;Java
byte kleineVariable;natürlich kann man mit typedef sowas machen
typedef unsigned char byte;
byte kleineVariable;doch wie wir alle wissen, reagiert dann die Synthax - Hervorhebung nicht, weil byte dann kein Schlüsselwort ist.
So ich muss aufhören, doch es sind noch ein paar Sachen !!
Wisst ihr, man könnte nun meinen, dass ich ein C++ Gegner bin, doch das Gegenteil ist der Fall ! Ich liebe doppelte Pointer, Funktionspointer, typenlose Pointer und die ganzen Cast über alles und würde keine Sprache freiwillig anrühren, mit der ich nicht solche "Schweinereien" machen könnte.
Doch es gibt wie gesagt auch Dinge, die mich ziemlich stören !Wie auch immer, ich habe oft das Gefühl das es hier Leute gibt, die extrem versuchen, das zu verteidigen was sie gelernt haben, da sie sonst den Boden unter den Füssen verlieren würden. Wie viele Pfarrer, die um die Kirche fürchten. Denn wenn es die Kirche nicht mehr gibt, dann sind Sie Wertlos. Genauso viele Programmierer. Wenn die Sprache, die sie ein Leben lang gelernt haben von einer anderen übertrumpft wird, dann sind Sie plötlich nicht mehr die Gurus und müssten auch wieder lernen...
So ich wünsche euch eine gute Nacht
Gruss Ishildur
-
danke! du redest mir aus der seele.
-
@!nman
ich muss leider sagen, das die dinge die mich an c++ stören, leider so vielfältig und komplex sind, das ich mehrere seiten bräuchte um sie genau beschreiben zu können. das ist mir zu viel arbeit und vorallem kann man das mündlich wesentlich besser. es geht mir auch gar nicht darum das hier im forum detalliert zu machen. ich bin (mal wieder) auf das thema gestoßen worden (siehe den anfang des beitrags), und müsste nun alles ganz genau erklären, damit ihr mich versteht. hier noch ein kleiner tipp zum besseren verständniss (den könnt ihr als netten hinweis affassen oder einfach ignorieren, mir egal):
c++ ist eine gute sprache, aber längst überfällig für eine version 2.0.
was früher einmal als komfortabel galt, kann zwar für den einzelnen auch heute immer noch gelten, vielleicht weil er noch nie was anderes gemacht, aber keinesfalls für die allgemeinheit (es gibt immer noch freaks, die mit assembler ihre lochkartenleser programmieren und es macht ihnen spass. ok!).
kurz (lol) gesagt. beim programmieren sollte es auf die wesentlichen dinge ankommen, auf genau das was man machen möchte, und nicht auf andere (sinnlose) dinge. wenn ich eine mp3-datei abspielen möchte, dann möchte ich in meinem player lediglich auf play drücken müssen, und nicht noch 100 verschiedene dinge vorher aktivieren, einstellen oder sonst wie konfigurieren müssen (ausser es ist notwendig, weil ich es so will, und der compiler es erraten müsste aus unendlich vielen möglichkeiten). wenn ich ein programm schreiben möchte, dass ein paar klassen hat, die ein paar berechnungen durchführen und diese dann ausgeben, dann möchte ich NUR DAS dem compiler/ide mitteilen müssen, und nicht noch vorher 100 verscheidene sachen aktivieren, einstellen oder sonst wie konfigurieren müssen, aber leider muss man das in c++, auch wenn es leute gibt, die was anderes sagen.
-
Ich zähle hier mal ein paar zusätzliche Beispiel auf, die mich persönlich an C++ stören.
Das sind IMHO alles nur kleine Nickligkeiten, die kein Nachteil der Sprache definieren können. Wie du schon sagst, sie stören nur dich persönlich.
Bsp. 1
kleinere Symboltabelle => schnelleres KompilierenBsp. 2
Ich seh das Problem nicht?Bsp. 3
Sagt mir leider nix, was ist denn das für ein System?Bsp. 4
Benutze eine entsprechende lib, das kann kein Nachteil der Sprache sein.Bsp. 5/6
Sehr gut argumentiert, ich glaube aber, du hast nicht recht.Bsp. 7
Ich seh wiederum das Problem nichtBsp. 8
Beste Anpassung an die Plattform => höchstmögliche Geschwindigkeit
Das ein typedef nicht "gehighlighted" wird, ist kein kein Nachteil der Sprache, liegt ja an deiner IDE.Zum Header / cpp / inkludieren...
Ich finde es gut, das h und cpp getrennt sind. Java-Klassen sind mir zu unübersichtlich, wenn ich nur mal schnell eine Funktionsprototyp anschauen möchte. Man kann so auch erstmal ein Interface nur hinschreiben und es kompiliert schonmal. Ist aber Geschmackssache...
Die #defines als include guards sind sicherlich rückständig, aber obwohl einem z.B. das (kürzere) #pragma once angeboten wird, benutze ich das nie. Ich habe einfach eine Schablone für header und benutze diese jeweils. Diese Sache ist wahrscheinlich auch historisch gewachsen und man kann sie nicht einfach so herausschmeissen, weil C++ ja auch immer C Programme kompilieren sollte. (bzw. war es anfangs ja umgekehrt, ein C++ Programm wurde vorm kompilieren in ein C Programm "umgeschrieben")Für mich ist C++ schon ziemlich genau so straightforward, wie "lediglich auf play drücken", eine Hochsprache ohne Schnörkel, für alles einsetzbar und dabei mit überlegen schnellen Kompilaten. Und gerade diese Geschwindigkeit ist ja in der Spiele-/Grafikprogrammierung heute immer noch gefordert.
