Auch wenn die Frage schon älter ist, schau doch mal hier vorbei: (Englischkenntnisse notwendig!) http://www.idroidproject.org/

Der klassische C-style cast ist für die Kompatibilität des C-Kerns zum C-Standard notwendig. Ansonsten könnte man keinen C-Code mit einem C++-Compiler kompilieren.

Die C++-casts haben drei entscheidende Vorteile:

1. Sie führen Prüfungen durch und können Ausnahmen werfen. (Beispiel: std::bad_cast)
2. Sie können sichere Ergebnisse liefern. (Beispiel: dynamic_cast eines Basisklassen-Zeigers auf Kind-Klasse A liefert nullptr/bad_cast, wenn der Zeiger auf Kind-Klasse B zeigt.)
3. Der Code ist seeehr viel übersichtlicher, und du kannst nach den casts suchen.

Anmerkung zu 2.: Der klassische C-Cast würde dir, genau wie ein static_cast die Kind-Klasse B einfach in A umwandeln, mit dem Ergebnis würdest du aber höchst wahrscheinlich nicht sehr froh werden.

Letztendlich ist es absolut nicht "verpönt" C zu benutzen, denn C ist der Sprachkern von C++. Wer das behauptet hat C++ nicht verstanden. In vielen Fällen fährst du mit dem C-Kern sogar besser, als auf jedes noch so kleine Problem mit C++-Klassen zu werfen.

Aber bei den Casts ist die C-Variante ganz einfach die ungeprüfte Presslufthammer-Methode nach dem Motto: "Mach, Compiler, ich weiß was ich tue!".

Das heißt, als kleines Fazit: Wenn du wirklich weißt, was du tust, kannst du natürlich auch den guten alten C-Brechstangen-Cast verwenden. ;)

Zuerst einmal ist Code::Blocks kein Compiler und hat somit nichts damit zu tun.

Die erste Frage lautet: Welchen Compiler verwendest du?

Die zweite Frage lautet: Was kompilierst worin? Also welche Bibliotheken linkst du mit welchen Optionen?

Die zweite Frage zielt auf Folgendes ab: Wenn du dem Linker sagst, er möge doch bitte beim Linken noch eine Menge Kram wegoptimieren, dann kannst du natürlich eine ganze weile warten. (Stichwort LTO) Das Gleiche gilt, wenn du eine Menge unnötiger Bibliotheken linkst, die dann wieder weg-optimiert werden.

Fazit: Solange du nicht schreibts, was du genau tust, kann hier niemand mehr tun, als zu raten.

Folgende Möglichkeiten sind es:

1. Du hast die 32bit-Version von Windows 7 installiert. Lösung: Keine, du kannst kein 64bit emulieren. Oder: Aktualisiere auf eine 64bit-Version von Windows 7.
2. Du hast die 64bit-Version von Windows 7, aber die 32bit-Version von VMware Workstation oder Player. Lösung: Aktualisieren auf die 64bit-Version von VMware Workstation oder Player.
3. Deine CPU ist recht alt, und beherrscht keine LAHF/SAHF Operationen im "long mode". Lösung: Neuere CPU kaufen. Die genannten Operationen werden von allen Prozessoren mit Intel-VT (oder AMD-V) Virtualisierung unterstützt.
4. Du hast eine aktuelle CPU, aber die Virtualisierungsfeatures (Intel-VT oder AMD-V) nicht aktiviert. Lösung: Geh in deine BIOS-Einstellung und aktiviere die entsprechenden Virtualisierungsfeatures.

Nein, sicher nicht. Ich zitiere mal die drei Gründe von http://www.cicero.de/comment/14518 , da ich es definitiv nicht besser formulieren könnte:

1. Erstens bieten weder der EU-Vertrag noch die Eurogesetze eine rechtliche Handhabe für einen Austritt Deutschlands aus der Währungsunion. Genauso, wie geborene Kinder nicht ungeschehen gemacht werden können, gibt es keinen Plan B, der den Euro beseitigt. Wie die Ehe ist der Euro auf Ewigkeit ausgelegt. Anders als in der Ehe hat man bei ihm bewusst auf ein Scheidungsrecht verzichtet, um den Kapitalmärkten zu signalisieren, dass Austritt und Ausschluss unmöglich sind. Das Ewigkeitsgelöbnis bot Anlegern somit von Anfang an ein Höchstmaß an Sicherheit. Nur deswegen kam es zu den niedrigen Risikoprämien für Eurokredite, von denen alle Schuldner in den Euroländern profitierten – auch jene in Deutschland. Eine Austrittsregel hätte von Beginn an zu Spekulationen an den Märkten und höheren Risikoprämien geführt. Genau das würde nun auch bei einer Rückkehr Deutschlands zur D-Mark geschehen. Die Märkte würden darauf spekulieren, dass es früher oder später doch wieder zu einem neuen Währungsverbund kommen könnte. Oder darauf, dass auch Deutschland aufgrund seiner hohen Verschuldung irgendwann seine heimische Währung abwerten müsste. All das würde für die D-Mark die Kreditkosten nach oben treiben – so oder so.
2. Zweitens könnte Deutschland aus der EU austreten, was seit Inkrafttreten des Lissabonner Vertrags am 1. 12. 2009 möglich wäre. Dann müsste es automatisch auch den Euroraum verlassen. Das aber wäre für Deutschland der ökonomische Gau. Eine Absage an Europa würde bei den Nachbarn die schlimmsten Ängste eines national isolierten Großdeutschlands wiedererwecken. Es wäre wohl das Ende der deutsch-französischen Freundschaft und der Anfang einer nationalen Misstrauenspolitik sowohl bei den westlichen wie auch östlichen Nachbarn.
3. Drittens würde eine Wiedereinführung der D-Mark hohe Umstellungskosten verursachen. Nur zur Erinnerung: Dem Euro ging eine mehrjährige Übergangsphase voran. Genauso müssten bei einer Rückkehr zur D-Mark zunächst neue Noten gedruckt, Münzen geprägt, Umtauschkurse fixiert und eine landesweite Versorgung mit Bargeld zum Stichtag X sichergestellt werden. Das wären technische Herausforderungen, die sich jedoch mit viel Aufwand und Kosten bewältigen ließen.

Ich kann die "Euromüdigkeit" ja verstehen, aber wir sind derzeit nunmal drauf festgenagelt.

Ich verstehe nicht so ganz, wo dein Array "a" ist. Und woher weiß "mergeSort" wo das Array ist, wenn du nur 0 und den höchsten Index übergibst? Kannst du den Quelltext mal auf pastebin.com kopieren?

Edit: Achja: Es wäre fein, wenn du einmal schreiben würdest, in welcher Sprache du das ganze schreibst. Bei "public static" für eine main()-Methode siehts natürlich nach java aus, aber ein Hinweis plus entsprechendem Tag wäre schön.

Es gibt keine spezielle "Game Developer Edition", es gibt Entwicklerversionen, die sind aber ganz schlicht das normale Windows, und gibts im MSDN Abonnement, das reichlich Geld kostet. Allerdings ist das nicht verwunderlich, da das MSDN Abo für Firmen gedacht ist.

Für Lau gibt es Windows garnicht. Sicher, du kannst es dir installieren, auf das Aktivieren verzichten und warten bis es abläuft. Dann darfst du alles neu installieren.

Was es gratis gibt ist zum Beispiel Visual C++ Express.

Schau doch einmal hier rein: http://msdn.microsoft.com/de-de/default.aspx

Zum Thema Entwicklungsumgebung:

Also zuersteinmal glaube ich nicht, dass du "Visual C++", sondern "Visual Studio" meinst. Dieses ist eine Entwicklungsumgebung, genau wie Dev-C++.

Visual Studio ist sowas wie eine Eierlegende Wollmilchsau, mit der du quasi Alles tun kannst. Praktisch ist, dass du verschiedene Sprachen verwenden, und auch mischen, kannst. Zum Beispiel Visual Basic, C, C++, C# und sogar Fortran. In der großen Vollversion sieht Visual Studio am Anfang allerdings eher nach einem Ufo als einer IDE aus.

Dev-C++ ist eine in Delphi geschriebene Entwicklungsumgebung für C++. Welcher Compiler verwendet wird, obliegt deiner Entscheidung, aber meist wird Visual C++ verwendet. nachteil an Dev-C++ ist, dass das Projekt tot ist. Eine aktuelle freie IDE, die auch mit den Dev-Packs von Dev-C++ etwas anfangen kann, ist Code::Blocks. (codeblocks.org)

Zum Thema Spieleentwicklung:

Bevor man anfangen kann sein Traumspiel zu programmieren, sollte man neben einer Programmiersprache auch die Grundlage des Software Design und Mathematik, besonderes im dreidimisionalen Raum, beherrschen.

Welche Programmiersprache am besten für die Spieleentwicklung geeignet ist, lässt sich nicht festlegen, da die Entscheidung oft auch die Entscheidung von der Engine abhängt, welche man benutzten will.

Weit verbreitete Programmiersprachen sind C, C++, C#, Lua, Python und Java. Ein guter Programmierer kann in so gut wie jeder Sprache programmieren, wenn er eine Sprachreferenz oder das Internet hat, da sich die Sprachen teilweise sehr ähnlich sind und die Regeln des Softwaredesign für alle gleich sind.

Wenn man dann soweit ist, dass man die Grundlagen des Programmierens beherrscht, kann man sich auf die Suche nach einer Engine begeben. Deren Wahl hängt auch immer davon ab, was für ein Spiel man entwickeln will. Auch haben verschiedene Engines wieder Vor- und Nachteile und teilweise auch völlig unterschiedlich Einsatzgebiete. Oft ist es auch eine Frage des Preises, welche Engine man nimmt, bzw. nehmen kann, da die Preisspanne von kostenlos bis zu mehreren hundertausend Euro reicht. Einen guten Überblick bekommst du hier: http://www.devmaster.net/engines/

Der Linux-Kernel ist in reinem C geschrieben. Unterstützt wir dieses durch 137 Dateien in include/asm-generic, hierbei handelt es sich um Helfer für, Macros für und auch Quelltext in Assembler.

Insgesamt besteht der Kernel (Zumindest die Version 3.0.4, die ich verwende) aus 16.440 Quelltext- und 14.871 Header-Dateien. Hinzu kommen 1.424 make-Skripte (Makefile), 43 Shell-Skripte.

Einschränkend ist, das es 34 Plattformspezifische Unterordner mit Assemblercode gibt. Für die gewöhnliche x86-Plattform finden sich darin gleich mal 326 Header mit Plattformabhängigem Code in und für Assembler.

Fazit: Der Kernel ist in C und Assembler geschrieben.

Es ist also eine Unmöglichkeit anzunehmen, du könntest "mal eben" ein eigenes Betriebssystem "programmieren".

Wenn du mehr über das Thema wissen möchtest, dann suche in deiner Lieblingssuchmaschine einmal nach "Minix" ;-) ! Außerdem könntest du zum Beispiel diese Buch lesen: http://www.amazon.de/Betriebssysteme-Eine-Einf%C3%BChrung-Hans-J%C3%BCrgen-Siegert/dp/3486582119 (Ist aber, wie auch das Thema an sich, starker tobak!)

Weit verbreitete Programmiersprachen unter Linux sind C, C++, Lua, Perl, Python und Java. Ein guter Programmierer kann in so gut wie jeder Sprache programmieren, wenn er eine Sprachreferenz oder das Internet hat, da sich die Sprachen teilweise sehr ähnlich sind und die Regeln des Softwaredesign für alle gleich sind.

Mit dreizehn würde ich an deiner Stelle zuerst einmal , vor Allem da du es ja auf Linux machen möchtest, mit Perl oder Python anfangen. Beide sind vergleichsweise einfach zu lernen, und du kannst schon nach kurzer Zeit sinnvolle Programme damit schreiben. Bevor jetzt jemand anfängt mit "Aber Lua ist doch viel einfacher", ja richtig. Lua hat aber auch ein paar Extrakonzepte, die es woanders nicht gibt, was hinderlich wäre. Außerdem ist Lua eigentlich dazu gedacht C/C++-Programme modular zu erweitern.

Sobald du in Perl oder Python (oder besser Beides) einigermaßen fit bist, könntest du entweder Ruby lernen oder gleich zu C übergehen.

Wichtig: Fang mit C an. Mach erst weiter wenn du dich mit C auskennst. Glaube mir, dass erleichtert dein Leben und Lernen ungemein, da der Kern von C++ eben C ist.

Thema Objektorientierung: Danach kannst du anfangen dich mit Klassen zu beschäftigen. Falls du oben "Python" ausgewählt hast, wirst du schon mal in die Objektorientierte Programmierung reingeschaut haben, aber jetzt wirds spätestens Zeit.

Was die Foren angeht, so kenne ich keine illegalen. Sich über Programmierung zu unterhalten ist wohl kein Problem. ;-)

Du hast dich selbst völlig unnötigerweise in eine extreme Abhängigkeit begeben, ja quasi versklavt. Aber du hast einen riesigen Vorteil: Du weißt es.

Aber dein Nachteil: Du willst nicht agieren. Geh zurück in deine Wohnung und zieh einen Schlussstrich. Denn wenn du das alles weißt, was tust du dann noch dort? Geh! Jetzt!

Letztendlich kann es aber durchaus sein, dass du ihm einfach nur hörig bist. Dann wirst du ohne professionelle Hilfe vielleicht nicht wegkommen? Die Frage ist, ob du dir etwas vormachst, und dich in deine Tatenlosigkeit einfach ergibst.

Das ist zwar etwas viel zu dem Thema, aber lies dir einmal den folgenden Artikel durch, und überprüfe für dich, was auch dich zutrifft.

http://arbeitsblaetter.stangl-taller.at/SUCHT/Hoerigkeit.shtml

Das bedeutet, dass du keinen Compiler hast, oder Code::Blocks nicht richtig eingestellt ist.

Code::Blocks hat keinen Compiler. Du kannst eine Menge Compiler damit verwenden. Falls du Linux benutzt, die Anbindung von gcc + gdb ist sehr gut. Unter Windows kannst du problemlos MinGW, Visual C++ 2008 oder Vidual C++ 2010 verwenden.

Die Anleitung dazu ist sehr gut, allerdings nur auf Englisch:

http://wiki.codeblocks.org/index.php?title=Installingasupported_compiler

Du schreibst "Kürzlich wurde im TV eine Mogoloide vorgestellt, die einen Studienabschluss geschafft hat." und fragst allen Ernstes ob "Mongoloide" (Menschen mit Down-Syndrom) studieren können?

Bitte stell doch keine Fragen die du gleich im ersten Satz selbst beantwortest.

Darüber hinaus: "Mongoloid" oder auch "Mongo" sind Schimpfwörter. Nutze sie nicht. "Mongolismus ist eine veraltete Bezeichnung für das Down-Syndrom, dessen Träger als „mongoloid“ bezeichnet wurden. Der Begriff wird heutzutage als abwertend verstanden." (Quelle: Wikipedia)

Also wenn du mehr über PI, die Geschichte, wie es berechnet werden kann und so weiter wissen möchtest, dann ist dieses Buch eine sehr interessante (und amüsante) Lektüre dazu:

http://www.amazon.de/Magie-einer-Zahl-David-Blatner/dp/3499611767

Falls du dich jetzt über diese Antwort wunderst, in dem Buch wird genau das beschrieben, wonach du fragst:

Ich verstehe jetzt aber nicht wie man die Formeln anwendet bzw. welche Schritte ich genau machen muss um eine Stelle zuerrechnen.

Hoffe ihr hab davon Ahnung und könntet mir erklären wie ich vorgehen muss. (Möchte eig. kein fertiges Programm sondern eine Erklärung, Rechen Bsp.)

Kleiner Nachtrag:

Mathematiker: Pi ist die Zahl, die das Verhältnis vom Umfang eines Kreises und seinem Durchmesser angibt.

Physiker: Pi ist 3,1415927 plus/minus 0,00000005.

Ingenieur: Pi ist ungefähr 3.

Vier Dinge sind mir beim durchschauen von Server.cpp aufgefallen: (*)

1.: Wenn du das Ergebnis einer Zuweisung testen möchtest, dann mache besser Klammern um die Zuweisung. (Zeile 69)

if ( (connectedsocket = accept(acceptsocket, NULL, NULL)) != INVALID_SOCKET)

2.: Du schaust zwar ob eine Verbindung besteht, aber in deiner "while" Schleife sollte stehen: (Zeile 79)

while ((INVALID_SOCKET != connectedsocked) && (SOCKET_ERROR != rc))

Andernfalls wird deine while-Schleife durchlaufen, auch wenn connectedsocket gar kein Socket ist, und schon schmiert recv() ab.

3.: Ich glaube da ist ein Tippfehler: Zeile 94:

sprintf(buf2, "Du mich auch \s", buf);

Kann es sein, dass du "%s" meintest?

4.: Deine beiden Aufräumer (Zeile 98 + 99) sollten Bedingen vorangestellt werden. closesocket(INVALIDSOCKET)_ (Falls accept() fehlschlug) ist keine gute Idee:

if (INVALID_SOCKET != acceptsocket)
    closesocket(acceptsocket);
if (INVALID_SOCKET != connectedsocket)
    closesocket(connectedsocket);

(*) Ich werde das Ganze nochmal mit VC++2010 ausprobieren, dazu komme ich aber erst später. Daher alle Angaben oben nur nach Sichtung und ohne Gewähr. ;-)

Eine Versionsverwaltung (rsync würde aber eventuell auch reichen) wäre sicherlich sinnvoll. Ich persönlich würde allerdings nicht svn sondern Mercurial oder Git verwenden, da mann bei diesen "offline" bereitstellen kann. Bei subversion muss man immer eine online-Verbindung zum Server haben um bereitstellen ("commit") zu können.

Mercurial ist schnell und sehr einfach. Git bietet weit mehr, aber die Lernkurve ist sehr steil, und es wäre vielleicht zu viel des Guten.

Es soll ja zum Wegsichern bzw. Synchronisieren verwendet werden. Wenn die Versionierung kein Problem ist, würde auch rsync (Linux) oder SyncToy (Windows) reichen. Wenn Versionierung (Bei LaTeX bietet es sich ja an) ein Thema ist, würde ich zu Mercurial raten. Es reicht und es geht schneller als bei Git, da man nicht vor jeder Bereitstellung mehr oder weniger umständlich die Dateien auswählen muss die berücksichtigt werden.

Was ich sehr interessant finde ist diese Blog-Diskussion über Subversion vs Git vs Mercurial (vs Bazaar) : http://thadeusb.com/weblog/2009/3/15/svnvshgvsgitvsbzr

1. Inkludiere <cmath> wenn du in C++ schreibst, math.h ist ein C-header.
2. sqrt() liegt im Namensraum std.
3. sqrt() liefert das ergebnis zurück, das musst du noch irgendeiner Variable zuweisen

Meine persönliche Lieblingskombination wäre C++ und CrystalSpace. CS ist eine echte GameEngine, das heißt, sie wurde für die Spieleentwicklung geschrieben.

Aber bevor man anfangen kann sein Traumspiel zu programmieren, sollte man neben einer Programmiersprache auch die Grundlage des Software Design und Mathematik, besonderes im dreidimisionalen Raum, beherrschen.

Welche Programmiersprache am besten für die Spieleentwicklung geeignet ist, lässt sich nicht festlegen, da die Entscheidung oft auch die Entscheidung von der Engine abhängt, welche man benutzten will.

Weit verbreitete Programmiersprachen sind C, C++, C#, Lua, Python und Java. Ein guter Programmierer kann in so gut wie jeder Sprache programmieren, wenn er eine Sprachreferenz oder das Internet hat, da sich die Sprachen teilweise sehr ähnlich sind und die Regeln des Softwaredesign für alle gleich sind.

Wenn man dann soweit ist, dass man die Grundlagen des Programmierens beherrscht, kann man sich auf die Suche nach einer Engine begeben. Deren Wahl hängt auch immer davon ab, was für ein Spiel man entwickeln will. Auch haben verschiedene Engines wieder Vor- und Nachteile und teilweise auch völlig unterschiedlich Einsatzgebiete. Oft ist es auch eine Frage des Preises, welche Engine man nimmt, bzw. nehmen kann, da die Preisspanne von kostenlos bis zu mehreren hundertausend Euro reicht. Einen guten Überblick bekommst du hier: http://www.devmaster.net/engines/

was möchtest du denn in welcher Sprache programmieren? Und für welches Betriebssystem?

Also die Info steht auf den ersten Blick gut sichtbar und groß da. Was mich jetzt noch interessieren würde wäre, was deine Frage bitteschön mit "Linux" zu tun hat?