Archiv verlassen und diese Seite im Standarddesign anzeigen : C++ Buch
MadmAx1982
2003-01-06, 21:23:23
Hallo kann mir einer Von euch ein gutes Buch zu C++ empfehlen.
Am besten wäre C++.Net.
Ich kann schon in ein wenige Programieren VB,Ada,und ein bissle C.
MFG MadMax
Nagilum
2003-01-07, 01:11:57
Ernstgemeinte Frage:
Was willst du denn mit C++.NET?!
Die Programmmierung des NET-Frameworks mit C++ ist, sagen wir mal, etwas ungewöhnlich. Ich kenn eigentlich niemand, der sich das freiwillig antut.
Schnapp dir VB.NET oder C#, die sind dafür wesentlich besser geeignet.
MadMax69
2003-01-07, 14:37:05
VB. Net behersche ich ja.
Ich wollte eigentlich gemischt schreiben. d.h den Geschwindikeitsrelevanten Teil in C++ und den rest mit VB.
Demirug
2003-01-07, 14:53:20
Originally posted by MadMax69
VB. Net behersche ich ja.
Ich wollte eigentlich gemischt schreiben. d.h den Geschwindikeitsrelevanten Teil in C++ und den rest mit VB.
Was möchtest du den genau programmieren? Weil für normale Sachen ist VB.Net schnell genug. Managed C++ lohnt da nur noch sehr selten und für Spezialfälle.
MadMax69
2003-01-07, 23:10:34
Ich will meine 3D Engine in C++ schreiben die Oberfläche für den Modell Editor und einiges andere habe ich in VB.Net Programmiert.
Die Engine ginge theoretisch auch in VB. Ich benutze DX9 aber ich denke C ist da ein wenig besser und schneller.
Nagilum
2003-01-08, 00:28:37
Wenn du´s schneller willst, dann nützt dir Managed C++ so gut wie nix. Da musst du dich schon in die freie Wildbahn des Unmanaged C++ trauen.
Demirug
2003-01-08, 07:29:24
Originally posted by MadMax69
Ich will meine 3D Engine in C++ schreiben die Oberfläche für den Modell Editor und einiges andere habe ich in VB.Net Programmiert.
Die Engine ginge theoretisch auch in VB. Ich benutze DX9 aber ich denke C ist da ein wenig besser und schneller.
Mit VB.Net habe ich es noch nicht gemessen aber mit C# erreicht man nahezu den gleichen Speed wie mit C++. Bei grösseren mathematischen aktionen schneiden die ganzen .net sprachen derzeit noch etwas schlechter ab als C++ aber an diesem Problem arbeitet MS schon. Also IMO ist es durchaus möglich auch mit VB.Net eine gute schnelle 3D Engine zu schreiben. Wobei ich da eher zu C# tendiere aber das hängt damit zusammen das ich VB nicht besonders mag.
Nasenbaer
2003-01-08, 20:10:30
Was versteht denn unter .NET eigentlich? Jeder spricht von aber ich weiß absolut nicht was damit gemeint ist. Kann mich einer aufklären?
Mfg Nasenbaer
Nagilum
2003-01-08, 20:29:12
Originally posted by Nasenbaer
Was versteht denn unter .NET eigentlich? Jeder spricht von aber ich weiß absolut nicht was damit gemeint ist. Kann mich einer aufklären?
Extrem vereinfacht: Die Microsoft-Variante von SUNs Java.
Eine virtuelle Maschine plus dazugehörigem Framework, mit dem fernen Ziel möglicherweise mal die veraltete WIN32 API abzulösen. IMHO durchaus gut gelungen das Ding. Alles sehr übersichtlich und sauber durchdacht. Liegt wohl daran, dass M$ bei der Entwickling stark mit Universitäten zusammengearbeitet hat. :D
Das Framework SDK gibts übrigens kostenlos, für den Fall, dass du es mal ausprobieren willst. Die enthaltene Doku ist ebenfalls gut und sehr umfangreich.
Nasenbaer
2003-01-08, 20:47:11
Originally posted by Nagilum
Extrem vereinfacht: Die Microsoft-Variante von SUNs Java.
Eine virtuelle Maschine plus dazugehörigem Framework, mit dem fernen Ziel möglicherweise mal die veraltete WIN32 API abzulösen. IMHO durchaus gut gelungen das Ding. Alles sehr übersichtlich und sauber durchdacht. Liegt wohl daran, dass M$ bei der Entwickling stark mit Universitäten zusammengearbeitet hat. :D
Das Framework SDK gibts übrigens kostenlos, für den Fall, dass du es mal ausprobieren willst. Die enthaltene Doku ist ebenfalls gut und sehr umfangreich.
Primär interessiert mich die Spieleprogrammierung. Also scheint .NET für mich eher uninteressant zu sein. Obwohl man damit vielleicht ja nen guten Editor oder ähnliches proggen könnte. Mal sehn. =)
Mfg Nasenbaer
Demirug
2003-01-08, 20:55:23
Was ist .Net?
Eine gute Frage auf die man abhängig davon wenn man fragt unterschiedliche Antworten bekommt.
Ich bevorzuge in der Regel lediglich die Technischen Aspekte die MS verfolgt zu berücksichtigen und die politischen aussen vor zu lassen.
MS hatte vor .Net eine reihe massive Probleme mit den Softwareentwicklungstools die im Laufe der Zeit entstanden sind.
Eines der Hauptprobleme war das für jedes neue Feature das im OS hinzukamm damit es die Entwickler auch nutzen konnten mehrer APIs gebaut werden musste. Eine native API für C/C++, eine für VB, eine für COM usw.
Ein anderes Problem war das es schwer möglich war eine grosse Anwendung mit verschiedenen Sprachen zu schreiben. COM konnte diese Problem zwar lösen aber ist in der benutzung teilweise einfach zu aufwendig und kompliziert.
Ein weiteres Problem das MS wieder auf sich zukommen sah war das Anwendungen in Zukunft wieder auf unterschiedlichen CPUs mit unterschiedlichen Befehlssätzen laufen sollen.
Dazu kommen noch eine Rheie wieterer kleiner Probleme.
.Net soll nun langfristig alle diese Probeleme lösen.
Um zu gewährleisten das eine Anwendung auf verschiedehnen CPUs laufen kann wird eine Anwendung nicht mehr vollständig vom Entwickler erzeugt. Der letzte Pass des Compilers wird auf den Rechner verschoben auf welchem die Anwendung ausgeführt wird. Der Compiler beim Entwickler erzeugt nur einen zwischencode (MSIL). Das ganze kennt man ja von JAVA. Der unterschied zwischen JAVA Bytecode und MSIL ist das JAVA Bytecode damals von SUN primär für Interpreter gedacht war MSIL dagegen ist so aufgebaut das es sich gut und schnell in native CPU-Code umsetzen läst sich aber deswegen nicht so gut für interpreter eignet.
Um nun das Problem der Zusammenarbeit von verschiedenen Sprachen (C++, VB, C#, usw) zu lösen enthalten die von einem .Net Compiler erstellten Dateien (Assemblies) sogenante META-Daten. Diese enthalten eine vollständige Schnittstellenbeschreibung aller Klassen. Damit kann man zum Beispiel mit VB.Net eine Klasse schreiben und diese dann in C# als Basisklasse benutzten und erweiteren.
Das Problem mit den verschiedenen APIs hat sich damit von aleine gelöst da ja jetzt jede .Net sprache auf die gleiche API zugreifen kann.
Dazu kommen noch eine ganze Reihe anderer Dinge die mit .Net das Leben der Programmierer einfacher machen. Und mit der neuen Version die denächst kommen soll gibt es noch mehr erleichterungen.
Demirug
2003-01-08, 21:01:01
Originally posted by Nasenbaer
Primär interessiert mich die Spieleprogrammierung. Also scheint .NET für mich eher uninteressant zu sein. Obwohl man damit vielleicht ja nen guten Editor oder ähnliches proggen könnte. Mal sehn. =)
Mfg Nasenbaer
Für Editoren ist es auf jeden Fall brauchbar aber auch für eine Engine ist es gut zu benutzen. Da Spiele heute immer scriptlastiger werden hat .Net den Vorteil das diese Scripts in einer .Net Sprache schreiben kann. Dadurch harmonieren diese natürlich sehr gut mit der Engine. Und dank des JIT-Compilers werden die Scripte auch sehr schnell in der Ausführung. MS hat das auch schon erkannt und hat DX9 entsprechend um eine API für .Net erweitert.
Nasenbaer
2003-01-08, 21:43:15
@Demirug
Das klingt richtig interessant. Vielleicht sollte ich mich doch mal beizeiten näher damit befassen.
Mfg Nasenbaer
MadMax69
2003-01-09, 13:45:35
Originally posted by Nagilum
Wenn du´s schneller willst, dann nützt dir Managed C++ so gut wie nix. Da musst du dich schon in die freie Wildbahn des Unmanaged C++ trauen.
Sag mir wen ich mich täusche, aber ich dachte man könnte auch mit .Net unmaneged C++ Code schreiben. Mit Zeigern und solchen Späßen. Mir geht es in erster Linie nicht darum mit C++ Net Framework anwendungen zu schreiben sondern normale rotinen die ich dan in VB.Net oder auch C# verwendne kann.
Nagilum
2003-01-09, 14:26:58
Originally posted by Demirug
Da Spiele heute immer scriptlastiger werden hat .Net den Vorteil das diese Scripts in einer .Net Sprache schreiben kann. Dadurch harmonieren diese natürlich sehr gut mit der Engine. Und dank des JIT-Compilers werden die Scripte auch sehr schnell in der Ausführung.
Hat nur das Problem, dass du auf dem Rechner des Spielers dann auch das komplette Framework installieren musst. Dafür werden die wenigstens Verständnis haben.
Originally posted by Demirug
MS hat das auch schon erkannt und hat DX9 entsprechend um eine API für .Net erweitert.
Was aber auch nicht mehr ist, als ein ziemlich lustloser Wrapper.
Originally posted by MadMax69
Sag mir wen ich mich täusche, aber ich dachte man könnte auch mit .Net unmaneged C++ Code schreiben.
Verfluchte Marketing-Abteilung bei Microsoft...
Meinst du mit 'NET' jetzt Visual Studio.NET oder das NET-Framework? Natürlich kannst du mit VS.NET auch weiterhin ganz "normale" (aka unmanaged) C++ Programme schreiben. Nur kannst du dann eben nicht mehr auf die Klassen des NET-Frameworks zugreifen.
Was aber geht ist:
Du schreibst deine performancerelevanten Teile in Unmanaged C++ (also ohne NET-Support) und bindest diese dann in deine VB.NET Anwendung ein. Nur ist das dann eben 'Unamanged C++', und nicht 'C++.NET'.
Demirug
2003-01-09, 14:34:03
Originally posted by Nagilum
Hat nur das Problem, dass du auf dem Rechner des Spielers dann auch das komplette Framework installieren musst. Dafür werden die wenigstens Verständnis haben.
Wo ist das Problem? Einfach den Framework mit auf die CD und über kurz oder lang hat es sowieso auf dem Rechner weil es MS mit in die SP reinpackt.
Was aber auch nicht mehr ist, als ein ziemlich lustloser Wrapper.
Wieso lustlos? Hast du schon damit gearbeitet? Bis auf ein paar kleinere Dinge finde ich Managed DX nicht schlecht.
Verfluchte Marketing-Abteilung bei Microsoft...
Meinst du mit 'NET' jetzt Visual Studio.NET oder das NET-Framework? Natürlich kannst du mit VS.NET auch weiterhin ganz "normale" (aka unmanaged) C++ Programme schreiben. Nur kannst du dann eben nicht mehr auf die Klassen des NET-Frameworks zugreifen.
Was aber geht ist:
Du schreibst deine performancerelevanten Teile in Unmanaged C++ (also ohne NET-Support) und bindest diese dann in deine VB.NET Anwendung ein. Nur ist das dann eben 'Unamanged C++', und nicht 'C++.NET'.
Ein paar Dinge muss man dabei aber noch beachten sonst wird das ganze durch den Interop Overhead am Ende langsamer als wenn man es direkt in C# schreiben würde.
@MadMax69: Was hast du überhaupt vor das du so um die Performances fürchtest?
Nagilum
2003-01-09, 14:45:28
Originally posted by Demirug
Wo ist das Problem? Einfach den Framework mit auf die CD und über kurz oder lang hat es sowieso auf dem Rechner weil es MS mit in die SP reinpackt.
Leider kriegen die meisten Otto-Normal-User beim Namen DOT.NET aber schon Panikattacken. Dank des hundsmiserablen M$-Marketings wissen ja selbst viele Programmierer nicht, was NET eigentlich ist.
Heinz Hanselmann wittert da (dank Computerbild & Co) sofort irgendwelche gemeingefährliche Spionagesoftware, DRM oder eine Plattform für Leasing-Software.
Der normale Benutzer lehnt NET strikt ab. Eben weil er´s nicht kennt. Schau dir mal an, was aus dem GUI-Client von Overnet geworden ist. Erst für NET geschrieben, und dann sind die User solange Sturm dagegen gelaufen, bis die Entwickler sich gezwungen sahen, wieder alles auf ne "normale" WIN32 Applikation umzustellen.
Ich bin von NET auch recht begeistert, aber die Akzeptanz ist im Moment mehr als mau.
Demirug
2003-01-09, 15:33:54
Nagilum, das mit Overnet ist auch irgendwie dumm gewesen. Entweder alles managed oder gar nichts. Bei diesem komischem Mischmasch war mir auch etwas unwohl.
Ansonsten habe ich es ja bereits gesagt über kurz oder lang bekommt es sowieso jeder untergeschoben (SP, IE, Office, usw) und Heinz Hanselmann merkt es gar nicht was er da mitinstalliert hat. Das gleiche wäre der Fall wenn man bei einer Game Installation mal schnell das Redistpacket des Frameworks mit intstalliert. Der grösste Teil würde es gar nicht merken.
Nagilum
2003-01-09, 15:53:36
Hmm, ob sich das beim Kunden so gut macht, wenn man ihm - quasi durch die Hintertür - das NET Framework auf den Rechner knallt? Das weckt ja nur noch mehr Misstrauen.
Aber du hast schon recht. An NET wird man in Zukunft sicher nicht mehr vorbeikommen. Nicht weil die Kunden danach schreien, sondern weil M$ das Ding mit aller Gewalt in den Markt pressen wird. Als Programmierer solls mir nur recht sein. :)
Huchs, gerade bei Heise gesehen: Die neue Server-Linie von Microsoft heisst nichtmehr ".NET Server", sondern "Windows Server 2003". Was wohl der Grund ist? :D
Unregistered
2003-01-09, 18:39:03
Originally posted by Demirug
@MadMax69: Was hast du überhaupt vor das du so um die Performances fürchtest?
Wie gesagt wollen wir eine 3D Engine schreiben.(Wir das sind meine Komilitonen der Uni Stuttgart und ich.). Das Ding sollte natürlich schnell sein.Und ausserdem würde ich gerne Zeiger verwenden.
Ausserdem schreiben wir einen Modell Editor, einen Worldeditor und noch einiges andere. Das ganze soll also mehr ein SDk alls eine Engine werden.
Am Ende haben wir dann ein paar Editoren und einige dutzend Klassen die man dann in eien belibige Net Sprache einbinden kann und sich sein Spiel dann zusammenklicken.
Im Prinzip hat Nagilum recht ich brauche woll eher ein gutes Buch über C++ als C++.Net.
MadMax1982
2003-01-09, 18:39:49
Das war ich.
Demirug
2003-01-09, 18:54:44
Stimmt das mit der 3d engine hast du ja schon gesagt.
Warum um alles in der Welt willst du Zeiger verwenden? Zeiger machen mehr Ärger als sie es Wert sind.
Meine Empfehlung wäre erst mal C# oder VB.Net (wenn es unbedingt Basic sein soll) für alles zu benutzten. Wenn es dann mal läuft mit einem Profiler schauen wo die meiste CPU-Zeit verbraucht wird. Dann als erstes fragen ob das benutzte Verfahren überhaupt das richtige ist und erst wenn man kein besseres findet darüber nachdenken native Code (C++) einzusetzen. In der Regel sind die Performances unterschiede zwischen C# und C++ nur minimal so das durch das einbinden von C++ kaum Performancesgewinne zu erzielen sind. Da muss man dann schon eher den Assembler (für MMX, 3dNow, SSE, usw) auspacken.
Nasenbaer
2003-01-09, 20:02:40
Mit dem misstrauen habt ihr vollkommen recht. Bevor es das Progger-Forum hier gab und ich deshalb hin und wieder mal von .NET hörte, vermutete ich auch nichts gutes dahinter. Und die Installation des Frameworks wegen Overnet war mir auch nicht geheuer.
Aber nun habt ihr mich ja eines besseren belehrt.
@MadMax1982
He das mit dem SDK hört sich richtig interessant an.
Unis verbreiten sowas doch immer kostenfei? :D
Zumindest ne Techdemo würd ich dann mal gerne sehen.
Halt uns hier im Forum mal auf den laufenden darüber. :-)
Mfg Nasenbaer
MadMax1982
2003-01-09, 21:47:00
@ Nasenbaer.
Unis tun dies schon. Aber wir sind privat Personen die nur zusammen studieren.
Aber wen es was wird und ich ein paar beta tester brauche post ich
es sicher hier im Forum.
Unregistered
2003-01-09, 21:48:52
@ Demirug
Ich glaube du hast gar nicht mal so unrecht.Den Modell Editor werde ich auf jeden Fall in VB fertig schreibe. Jetzt wo DX9 drausen ist brauch ich wenigstens keien Software Rendere mehr.
Wuzel
2003-01-11, 15:36:05
Naja ein wichtiges Ding bei .Net fehlt hier.
Es geht um verteilte Anwendungen, kommunikation übers I-Net.
Grund : COM+ ( DCOM ) oder der ATL Server sind zwar mächtig, skalieren wie sau, aber sind doppelt so schwer zu verwalten wie z.B servlets von J2.
Daneben ist der ganze COM Syntax für die Schnittstellen extrem komplex, es muss meist immer erst sehr viel konvertiert werden, Arrays sind Hooror, ZeigerZeiger ( BSTR** ) biss zum abkotzen etc.
Tja und als Schnittstelle nimmt man jetzt halt einfach XML.
Im prinzip gesehen hat MS einfach die Java Konzepte nachgebaut.
Kann man aber so nicht stehen lassen, wäre unfair.
Das 'einfache' pendant zum ATL Server heisst jetzt Webservice.
Der Webservice nutzt wie gesagt XML als schnittstelle, ist COM+ kompatibel ( alte Projekte mit .NET zu bestücken ist kein prob ), einigermassen lesitungsfähig und extremst gut wartbar, grade in verbindung mit C#.
Daneben hat MS auch gleich noch ASP verbessert um bei aktiven Websites endlich wieder eine Option zu sein.
Und mit verlaub, ASP .NET ist verdammt gut.
Über ASP .NET kann man locker 200 Din A4 Seiten schreiben nur um die neuerungen zu erläutern.
In Verbindung mit webservices, ASP, macht managed C++ Sinn.
Grund : Ich schreib das meiste in schnellem C++, Klassenschnittstellen werden verwaltet ( ja , man kann C++ mit verwaltetem c++ mischen ! ), tadaa ich habe meine High-Speed skalierende Web Anwendung.
Damit ist's ein leichtes sehr dynamische Seiten aufzubauen, die regelrecht mit dem User interagieren, genauso wie geleichzeitig das ganze für jedes X-beliebiges XML Progi verfügbar zu machen.
Man schaue sich mal nur den webservice von Amazon oder Google an.
Ich kann wie DCOM üblich von nem ganz normalen WinProg zu greifen, ohne Schnittstellen entwerfen/anpassen zu müssen.
Gleichzeitig kann ich aber auch auf ner webpage alles zur Verfügung stellen, oder einen kleinen Handheld dafür entwickeln -> keine Grenzen !
Das schönste : So einfach wie Pizza essen !
Infomationen überall, zu jederzeit, mit jedem Toaster der XML kann.
XML wurde so gut ins .NET integriert, das es schon schier atemberaubend ist.
In C# kann man wie auf jede X-belibige Klasse drauf zu greifen, man merkt den Unterschied zu lokalen Klassen garnicht, keine probietären Datenformate, keine konvertiererei.
Für reines C++ wurden Proxies geschrieben auf die man wie bei ATL Servern zugreift, also alles beim alten.
Erst mit managed C++ kommt man in den Genuss wie bei C# auf die daten zuzugreifen.
Tja .NET halt, ich bin ernsthaft ! am überlegen von J2 / Cobra auf .NET zu imigrieren.
Ich wäre bescheuert nur wegen meiner politischen Einstellung doppelte Arbeit zu haben.
Naja mal kucken wie's weitergeht, aufm IIS 5 mach ich das jedenfalls nicht, das ist sicher. Aber wenn mal nen gescheiter IIS zur Verfügung steht ist die sache beschlossen.
Demirug
2003-01-11, 15:50:11
Wuzel:
Kennst du das schon? http://www.covalent.net/products/rotate.php?page=93
Wuzel
2003-01-11, 16:19:28
Originally posted by Demirug
Wuzel:
Kennst du das schon? http://www.covalent.net/products/rotate.php?page=93
Das sieht gut aus.
Werd ich mir mal genauer anschauen, wäre eine Option.
Nasenbaer
2003-01-11, 18:01:33
@Wuzel
Wenn du etwas von MS derart lobst dann muss es wirklich einwandfrei sein. =)
Andererseits interessieren mich Webanwendungen im Moment absolut nicht wodurch es für mich nicht interessant ist.
Aber wie du im Thread "Erst C, dann C++" schon richtig sagtest sollte man sich wohl erstmal auf das konzentrieren was man später unbedingt braucht. Aus heutiger Sicht wäre das für mich C++. :)
Mfg Nasenbaer
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.