# C#  & Gameprogramming



## Fireface (26. Februar 2002)

Hi Leute!
Es ist mir zwar schon aufgefallen das C# sehr an OOP hängt und leistungsfähig ist, aber steckt in  C# auch das potential einr leistungsfähigen 3D Engine? Ich kein Freund der OOP, deshalb kann ich mir einfach nicht vorstellen nur mit Klassen und co zu proggen!

CU Fireface


----------



## Matthias Reitinger (26. Februar 2002)

IMHO wird C# durch den JIT-Compiler so abgebremst, dass z.B. ein 'Unreal Tournament' damit nicht realisiert werden könnte.
Außerdem glaube ich, dass der Zugriff auf 3D-APIs wie OpenGL oder Direct3D mit C# nicht so einfach wenn nicht sogar unmöglich ist. Aber glauben heißt nichts wissen, also bitte ich mal um Aufklärung, falls da jemand genaueres weiß


----------



## Xeragon (26. Februar 2002)

Hmm, es ist bestimmt möglich, sofern man es schafft Zugriff auf DirectX zu kriegen *g*.
Wegen dem OOP mach ich mir die wenigsten Sorgen, da schließlich die Engines in C++ auch längst auf OOP (oft sogar COM) basieren.
Das größere Problem sehe ich darin, dass es kaum jemanden interessieren dürfte von C++ auf C# zu wechseln, da C++ vom Sprachumfang her leistungsfähiger ist (Und wenn man schon in C# programmiert wird man dennoch WinAPI & DirectX brauchen, das heißt die CLR ist kein Argument *g* (abgesehen davon gibt's für C++ (standard oder auch zusätzlich) umfangreichere Libraries)


----------



## Fireface (26. Februar 2002)

*compiler*

hast ja recht, der Zugriff auf die Apis ist sicher möglich, ich meinte mit OOP nur, das ich glaube dass wegen ihr einer Ordentlichen Engine das potential fehlt.....
egal jetzt, ich hab mich entschlossen dass ich mir Sprache mal ansehen werde, Probleme hab ich nur mit dem Compiler. Gibts da schon einen Freeware, weil ich will jetzt nicht schon wieder wegen Raubkopien diskutiern....  

cu


----------



## Xeragon (26. Februar 2002)

Im .NET-Framework SDK is AFAIK einer drin.
Wg. OOP: Ich glaube ohne OOP fehlt einer modernen Engine das Potential. (Der Code würde unüberschaubar, Modularität & Erweiterbarkeit ein Fremdwort, "den Code warten" ein Äquivalent zu "am besten wir schreiben's gleich neu")


----------



## Christian Fein (27. Februar 2002)

> Das größere Problem sehe ich darin, dass es kaum jemanden interessieren dürfte von C++ auf C# zu wechseln, da C++ vom Sprachumfang her leistungsfähiger ist



Das ist nur zur haelfte richtig. Das .net Framework liefert jetzt bei der version  1.0 schon 4000  Klassen von haus aus. 
Und da schon  2004 ein  Windows.net geplant ist wird .net die WinAPI wie sie jetzt besteht abschaffen und abstrahieren. 
Sprich zur Zeit stimmt das noch aber in  naher zukunft nicht mehr.



> IMHO wird C# durch den JIT-Compiler so abgebremst, dass z.B. ein 'Unreal Tournament' damit nicht realisiert werden könnte.



Das ist richtig. Aber fuer Spieleprogrammierung ist C# auch nicht entwickelt worden. Genausowenig spielte auch  Visual  Basic in Gameprogrammierung keine!! rolle. 
Ist wie bei allen anderen Werkzeugen auch:
Mann kann mit ner  Schere(C#) Papier zerschneiden, mit der Motorsaege (C/C++) wohl eher nicht dafuer aber Baeume(Spiele ) faellen...

In allen faellen sei gesagt :
C# und  .net allgemein ist fuer Windowsanwendungen und Webanwendungen entwickelt worden und auf k einen Fall fuer Spiele !


----------



## Xeragon (27. Februar 2002)

> _Original geschrieben von HolyFly _
> *Das ist nur zur haelfte richtig. Das .net Framework liefert jetzt bei der version  1.0 schon 4000  Klassen von haus aus.
> Und da schon  2004 ein  Windows.net geplant ist wird .net die WinAPI wie sie jetzt besteht abschaffen und abstrahieren.
> Sprich zur Zeit stimmt das noch aber in  naher zukunft nicht mehr.
> *



Es geht nicht um die Klassen, schon gar nicht um die vom .NET-Framework (die sind ja schließlich auch in C++) verfügbar und es drüfte kein Problem sein Millionen von Klassen für C++ aufzutreiben... (Schon allein die STL is ja auch nicht gerad klein).
Es geht primär um den Umfang der Sprache selbst, hier mal ein paar Stichworte (wenn du willst kriegst du mehr auch ): Templates, Multiple-Inheritance, Pointer & Referenzen (ich weiß dass C# das "intern" handlet, was aber meiner Meinung nach dadurch die Typsicherheit von C# weit unter die von C++ absenkt), generelle Container-Klassen (-> STL, ich hab sowas unter C# zumindest noch nicht gefunden) ...


----------



## Christian Fein (27. Februar 2002)

Schau dir ArrayList 
Stack Quoe Klasse an und insgesammt im Verzeichniss :
System.Collections

Wegen Typsicherheit laesst sich streiten,  denn  C++ ist ebenso bekannterweise nicht unbedingt sooo typsicher.

Aber wie gesagt: 
C# ist ein  Werkzeug fuer Windows Anwendungen genauso wie es  z.b auch  Delphi ist. In delphi wirst du als C++  Programmierer auch nicht gluecklich weil Templates usw in der Form nicht auffindbar sind (oder sindses ? Delphi knowledge == false)
Doch wenns darum geht  fuer einen Kunden nen DB Admin aufzusetzen dann ist  Delphi die perf. wahl  ...klick klick ...fertig 

Es ist eine Frage der Aufgabe. Ne die STL ist nicht klein. Aber die STL ist als  einzige als eine "allgemein" gueltige Library enthalten also das was dem "mitgelieferten" Framework am nahesten kommt.

Ich geh aufgrund deinem Textes davon aus das du grad C# bzw .net lernst ?
Was sind deine "sonstigen" Eindrueck ?


----------



## Thomas Kuse (27. Februar 2002)

> _Original geschrieben von HolyFly _
> Mann kann mit ner  Schere(C#) Papier zerschneiden, mit der Motorsaege (C/C++) wohl eher nicht dafuer aber Baeume(Spiele ) faellen...



ich glaub ich fall vom stuhl vor lachen


----------



## Xeragon (27. Februar 2002)

Hmm, Vergleich mal das "kleine" System.Collections mit der STL (z.B. http://www.sgi.com/tech/stl/).

C++ konvertiert zwar implizit z.b. 32-Bit auf 16-Bit oder real -> integerm allerdings MIT WARNUNG (sofern du den Warn-Level nicht runterdrehst )

Wohingegen das meiner Meinung nach absolut falsch für eien Programmiersprache ist:

System.Int32 eineZahl; // Wert, wie erwartet
MeineKlasse eineKlasse; // Referenz?? woher, wieso??

Während Referenzen in C++ mit '&' eindeutig gekennzeichnet werden:

int eineZahl; // Wert
MeineKlasse eineKlasse; // Wert
MeineKlasse& refEineKlasse; // Referenz
MeineKlasse* ptrEineKlasse; // Pointer

Nur damit du nmich nicht falsch verstehst: Für Webanwendungen ist C# IMO gut geeignet, aber so "stark" wie C++ wird es sicher nie sein.
(Ich persönlich sehe C# gern als "kleiner Bruder" von C++ (kompakt, aber eben nicht so umfangreich) )

* EDIT: *
Ich habe C# mal vor nem halben Jahr oder so ein wenig programmiert, aber bin eigentlich bei C++ geblieben und hab nur nebenbei ein wenig mit C# "rumgespielt" (für ASP.NET ist es wirklich nützlich).
In letzter Zeit hatte ich wieder ein wenig mehr damit zu tun, da meine COM Objekte unter allen Sprachend ei COM unterstützen funtkionieren sollen (allerdings teste ich sie nur unter C++, C#, VB(.NET) und evtl. SmallTalk)


----------



## Christian Fein (27. Februar 2002)

Nun Xeragon du verursachst mir ein Problem  und zwar das ich deine Posts immer nur zur haelfte zustimmen oder nicht zustimmen kann 

"aber so "stark" wie C++ wird es sicher nie sein"

Ohm es komt drauf an wie du Stark definierst ?
Ist es die Geschwindigkeit dann ist Assembler staerker
Ist es Moeglichkeit dann ist C++ staerker als C# (ja Geschw auch)
Ist es Kostenguenstige Programmierung ist C# staerker als C++
Ist es die Wartung von Programmen ist C# staerker
Ist es Plattformunabhaengigkeit und damit verbundene Produktionseinspaarungen -> C#
....
Insgesammt nach der Wertung wie mann eine Programmiersprache am meisten Bewertet :
Nutzen + Geschwindigkeit 
gewinnt C++ klar.

aber wenn jetzt folgendes gerechnet wird:
Nutzen + Geschw / Produktionskosten
bin ich mir da nicht mehr so sicher

Auch wenn Joki lacht  aber hinter dem Motorsaegen Papierschneidem beispiel steh ich immer noch.

"mal das "kleine" System.Collections mit der STL"
Wie lange ist das .net Framework released ? glaube das ist jetzt 1 Monat her. Wie lange gibts die STL ? Die Standart Library der beliebtesten Programmiersprache ? 
Das ich diesen Vergleich im Augenblick noch nicht zaehlen will versteht sich....

int eineZahl; // Wert 
MeineKlasse eineKlasse; // Wert 
MeineKlasse& refEineKlasse; // Referenz 
MeineKlasse* ptrEineKlasse; // Pointer 


Richtig ich habe keine Sorgen mit Pointer und Referenzen in c++. Auch keine in  C# denn es gibt ein schlaues buechlein das einem  verraet wo was wie uebergeben wird 
Auch wird einem das ganz schnell klar.

(Ich persönlich sehe C# gern als "kleiner Bruder" von C++ (kompakt, aber eben nicht so umfangreich) 

agree

Nun  lass uns mal ein paar Jahre zurueckblicken in die  Java Boom zeiten.
(Nein ich habe dort noch nicht gecodet aber man liest ja gern )
Die Leute waren davon ueberzeugt das Java das bessere C++ ist. Nun das hat sich nicht ganz  bewahrheitet aber schau mal auf  http://www.entwickler.com/jobs und suche nach Java so sieht mann das in der industrieellen Produktion Java durchaus seine Fans hat.
C# und .net ist ziiemlich Jung noch und das  erklaerte Ziel von MS ist da. Und  dieses ist  u.a. das .net die WinAPI abloest und damit wird die  Bedeutung von  einer  reinen .net  Sprache ganz klar groesser 

Finger ausruh ...


----------



## Xeragon (27. Februar 2002)

stark (im sinne von Programmiersprachen): möglichst vielseitieg (sowohl high-level als auch low-level funktionalität), effizient (ok, handgeschriebenes Assembler ist meistens (sprich: bei einem erfahrenem Programmierer) das effizienteste, aber Assembler hat in keinem der anderern Bereiche Vorteile), eindeutig (was "implizite Referenzen" ja nicht unbedingt sind...), gute Syntax, vielleicht noch ein paar Sachen die ich vergessen habe, in der Praxis nützlich.

Ist es Kostenguenstige Programmierung ist C# staerker als C++ 
Ist es die Wartung von Programmen ist C# staerker 

Das sehe ich nicht unbedingt so... Wartung & Kosteneffizienz kommt weniger auf die Programmiersprache als auf Coding-Standards & das Design an (bzw. Projektplannung). In C++ stehen dir genausoviele OOP-Möglichkeiten offen.

Ist es Plattformunabhaengigkeit und damit verbundene Produktionseinspaarungen -> C# 

Hmm... bei C# wären da: 
- Windows
- (bald?) Linux

Bei C++:
- so ziemlich jede Plattform die ich kenne (ich hab hier einen uralten IBM RISC 6000 rumstehen und er hat einen C++-Compiler...)
(natürlich muss darf man nur Standard-Funktionalität verwenden, is aber bei C# auch nicht anders )

Da du jetzt gleich damit kommen wirst, dass C# nicht neu kompiliert werden muss: Das hängt ja nur mit .NET zusammen (IL) und du kannst auch mit C++ auf .NET/CLR basierend programmieren 

Nutzen + Geschw / Produktionskosten 
... Naja Produktionskosten sollten bei erfahrenen Programmieren nicht unbedingt durch die Programmiersprache entstehen *g* ... So gesehen hätte C++ mit den mehreren verfügbaren Libraries (incl. .NET) bessere Chancen ...

Auch keine in C# denn es gibt ein schlaues buechlein das einem verraet wo was wie uebergeben wird 
Auch wird einem das ganz schnell klar. 

Hmm, wenn du Typsicherheit danach definierst, dass es mit Hilfe des Standards deutlich hervorgeht was da los ist, dann ist wohl jede Sprache typsicher (du kannst auch mit dem C++-Standard in der Hand deinen ganzen Code durchgehen und wirst feststellen, dass es ganz eindeutig ist).
Ich persönlich sehe die praktischere Definition von Typsicherheit darin, dass ich ohne Buch (zumindest ungefähr) sehe, mit welchem Datentyp ich es zu tun habe. (Allerdings ist C# zugegebenermaßen bis auf das Zeug mit den Referenzen relativ typsicher, C++ allerdings auch )

Wie lange ist das .net Framework released ? glaube das ist jetzt 1 Monat her

Hmm, das hat schon ein paar Jährchen (2, 3?) Entwicklungszeit hinter sich, ich persönlich glaube, dass sie die entsprechenden Klassen schon beim Release drin hätten, wenn sie es vorhätten. Auf lange Zeit kann ich aber leider keine Prognose stellen. (Nebenbei bemerkt: Es gibt auch Diskussionen über einige andere Libraries in C++ die nach Meinung vieler in den Standard sollten)

Java:
Es ist immer das Problem mit dem ersten Hype... jeder denkt die neue Sprache ist ideal um alle Probleme aus der Welt zu schaffen, wenn das allerdings mal verflogen ist, taucht die Frage auf "Wo bringt es jetzt wirklich Vorteile?".
Die Plattformunabhängigkeit von Java ist ja angeblich auch nicht sooo toll wie anfangs gesagt. Dennoch hat es sich zumindest im Web als recht nützlich erwiesen.
(Etwas in eigener Sache: Sollte irgendjemand schon einmal ein Java-Applet mit halbwegs vernünftigem/dem Standard entsprechenden UI gesehen haben, so möge er es mir bitte verraten, ich bin nämlich immer noch auf der Suche ).


----------



## Fireface (27. Februar 2002)

Ich bin der meinung das C# im Windows Bereich sehr wohl durchsetzen wird gerade wegen der einfachheit. Gerade beim Widows Programmieren ist C# hervorragend. Alles Basiert schön auf Klassen und ist bis in die letzte kleine Ausgabe komplett verkapselt. 

Leider fehlen aber die lieben Pointer. Ausserdem ist der Compiler schon fast zu genau: man kann z.B. kleine Tricks wie z.B. eine if-anweisung nicht mehr als Variablendeklaration "missbrauchen" ....

Ich als 3D und 2D Grafik programmierer bleib voerst bei C++ und wart bis ohne .net gar nicht mehr geht. Das dürfte aber noch eine Weile dauern. (Schätz mal 2005-2006)


----------



## Xeragon (27. Februar 2002)

Das mit WindowsForms ist wohl kein Argument für C#, da es ja genauso unter C++ funktioniert...
Warum C# nehmen wenn man C++ & .NET haben kann?
(und wiedermal: Webanwendungen sind wohl besser in C# zu schreiben)


----------



## Fireface (27. Februar 2002)

@Xeragon:

schau dir mal C# an dan wirst du schnell sehen, dass 
C# & .NET viel mehr Sinn ergibt!
WindowsForms mit C# ist schon ein gutes Argument weil du einfach mit C# Klassen dein Programm schneller fertig hast!

am besten du schaust dir mal ein Tut drüber an....dann bist auch du meiner Meinung.  Wetten?!


----------



## Xeragon (27. Februar 2002)

Ich würde nicht darüber urteilen, hätte ich es mir nicht schon angeschaut.

Warum sollten C#-Klassen besser als C++-Klassen sein? C++-Klassen bieten noch mehr Möglichkeiten als C#-Klassen.


----------



## Christian Fein (28. Februar 2002)

Hmm... bei C# wären da: 
- Windows 
- (bald?) Linux 

Naja erste Beta von Linux/UNIX ist gerade erschienen.

- MacOs ist gerade in Arbeit.

- so ziemlich jede Plattform die ich kenne (ich hab hier einen uralten IBM RISC 6000 rumstehen und er hat einen C++-Compiler...) 

Richtig nur dann versuch mal  dein Graphischen Oberflaeche Programm das du mit nutzung von  WinSockets auf deinem Win rechner geschrieben hast und pass das mal an KDE an.  mhhhh

-  C++ auf .NET/CLR basierend programmieren

Kannst du aber das ist dann nicht schneller als  C#  somit geht ein  C++ vorteil damit verloren.


... Naja Produktionskosten sollten bei erfahrenen Programmieren nicht unbedingt durch die Programmiersprache entstehen *g* 

Richtig aber genau dieser Erfahrene Programmierer kostet ne menge geld 
Mal ehrlich C++ ist wenn mann nicht jahrelange erfahrung hat noch sehr Laufzeitfehler anfaellig. Es dauert eine Weile und einige Debug Zeiten bis ein Programm ausgeliefert werden kann. Aber wer gibt schon zu das er  fehler reinprogrammiert. 
C# ist in diesem Bereich wirklich kostenguenstiger da viele Fehler erst gar nicht erstehen und wenn doch so werden sie zur kompilierzeit abgefangen (natuerlich nicht alle )

Ach PS:
Das soll kein C++ vs C# vs Java vs Assembler | ASP vs PHP vs JSP |
Windows vs Linux |  BMW vs  Mercedes | Shiffer vs Meine Freundin (hehe gewinnt eh) Thread sein.
C++ ist eine klasse / leistungsfaehige Sprache doch unterschaetz mir die Zukunft von .net und C# nicht 

sie die entsprechenden Klassen schon beim Release drin hätten, wenn sie es vorhätten.

Ich gehe eher davon aus das die 50 % veroeffentlicht haben und  50% nach und  nach veroeffentlichen nach dem Motto :
Schau schau wir tun was 

(Etwas in eigener Sache: Sollte irgendjemand schon einmal ein Java-Applet mit halbwegs vernünftigem/dem Standard entsprechenden UI gesehen haben, so möge er es mir bitte verraten, ich bin nämlich immer noch auf der Suche ).

Wuerde mich auch interressieren *g 
Das Java Look & Feel war der Hauptgrund weshalb ich mir doch nicht Java angeeignet habe.


----------



## Xeragon (28. Februar 2002)

*Naja erste Beta von Linux/UNIX ist gerade erschienen.*

Hmm, das heißt bald trifft es eh recht gut .

*Richtig nur dann versuch mal  dein Graphischen Oberflaeche Programm das du mit nutzung von  WinSockets auf deinem Win rechner geschrieben hast und pass das mal an KDE an.  mhhhh*

Es gibt auch Cross-Plattform Graphics-Libraries für C++ wenn du unter C# auf die WinAPI zugreifst is es genausowenig plattformunabhängig. Und: Wenn ich plattformunabhängige Sockets brauch, verwend ich nur die Berkley-Socket (ich glaub es war berkley? hmm, lange nicht mehr Sockets programmiert *g*) 

*Kannst du aber das ist dann nicht schneller als  C#  somit geht ein  C++ vorteil damit verloren.*

Wegen der Schnelligkeit hab ich ja auch nichts gesagt. Bloß du hast dann die Funktionalität von C++ .


*Richtig aber genau dieser Erfahrene Programmierer kostet ne menge geld 
Mal ehrlich C++ ist wenn mann nicht jahrelange erfahrung hat noch sehr Laufzeitfehler anfaellig. Es dauert eine Weile und einige Debug Zeiten bis ein Programm ausgeliefert werden kann. Aber wer gibt schon zu das er  fehler reinprogrammiert.*

Sollte der Programmiere nicht den Grad an Erfahrung haben, solltest du idhcn evtl. nach einem anderen umschauen... schließlich ist in der Praxis Programmierung die Lösung eines Problems, nicht die Lösung in eine Programmiersprache zu formulieren.

*Ach PS:
Das soll kein C++ vs C# vs Java vs Assembler | ASP vs PHP vs JSP |
Windows vs Linux |  BMW vs  Mercedes | Shiffer vs Meine Freundin (hehe gewinnt eh) Thread sein.
C++ ist eine klasse / leistungsfaehige Sprache doch unterschaetz mir die Zukunft von .net und C# nicht *

Das sehe ich auch so... allerdings sollte man die Zukunft auch nicht überschätzen.

*Ich gehe eher davon aus das die 50 % veroeffentlicht haben und  50% nach und  nach veroeffentlichen nach dem Motto :
Schau schau wir tun was *

Die Wahrscheinlichkeit, das Microsoft plötzlich auf diese Strategie umstellt ist ungefähr... ähm... 0,0000001% (und das aufgrund von Rundungfehlern *g*). Sie werden es sicher erweitern, aber sie halten bestimmt keinen Teil zurück, das würde sich nur negativ für sie selbst auswirken.


----------



## Christian Fein (28. Februar 2002)

Das glaub ich nicht Tim 

Ja WinSockets ist die  Windows implementierung dieser Berkly geschichte die zuerst fuer UNIX FreeBSD (? glaub) rauskam und am 
MIT (Massachusets Institute for Technologie) entwickelt wurde (Hab wirklcih nicht nachgeschaut  keine ahnung wieso ich das noch weis)
Aber wie mann Win implementierungen kennt ist es mit  Portabilitaet nicht weit her.
Nein C++ ist wirklich nicht plattformunabhaengig.

Wegen der Schnelligkeit hab ich ja auch nichts gesagt. Bloß du hast dann die Funktionalität von C++

Aber dann ueberwiegen die nachteile. Bin der letzte der fuer  .net C++ hernehmen wuerde. C++ -> Nativ Code 

Sollte der Programmiere nicht den Grad an Erfahrung haben, solltest du idhcn evtl. nach einem anderen umschauen... schließlich ist in der Praxis Programmierung die Lösung eines Problems, nicht die Lösung in eine Programmiersprache zu formulieren. 

Nun es werden immer mehr Programmierer gebraucht werden in der Zukunft. Immer mehr betriebe gruenden eine eigene IT Abteilung wenn sie sie nicht schon haben. Und dies auch immer mehr bei kleineren Firmen.
Daher wird eine Programmiersprache benoetigt mit der die anfallende Arbeit erledigt werden kann ohne diesen Riesigen Overhead an  Lernaufwand. Wer  sagt C++ ist leicht zu lernen ist entweder , Genie,  Angeber oder Besoffen


----------



## Talla (21. März 2002)

Hi 

Wollt auch mal was zu dem Thema sagen

Noch nie war es so leicht eine Anwendung zu schreiben wie in C#.
Da haben die Leute von Microsoft tolle Arbeit geleistet.
Zum eigentlichen Thema, Gameprogramming.
C# ist auf keinen Fall zu langsam für Games.
Die Ausrede das C# durch den Jitter verlangsamt wird im Gegenstaz zu voll kompilierten Programmen zählt nicht, bei großen Anwendungen die modular aufgebaut sind(was games nun mal sind) kann C# sogar um einiges Schneller sein als C++. Warum? weil der Jitter den Code ständig zur "Laufzeit" optimiert und ihn so immer besser den umständen anpassen kann, außerdem wird nur der Teil eines Programms kompilert der benötigt wird, also nicht das gesamte Programm, und das bringt zusamemn enorme Geschwindigkeitssteigerungen. Und durch Com/Interop ist es schon längst möglich OpenGlide/DirectX zu benutzen und b DirectX9 werden auch native .Net Komponenten zur verfügung sein.

wollt da nur mal sagen, weil doch einiges falsches heir gesagt wurde

bye talla


----------



## Christian Fein (22. März 2002)

> _Original geschrieben von Talla _
> *Hi
> Da haben die Leute Die Ausrede das C# durch den Jitter verlangsamt wird im Gegenstaz zu voll kompilierten Programmen zählt nicht, bei großen Anwendungen die modular aufgebaut sind(was games nun mal sind) kann C# sogar um einiges Schneller sein als C++. Warum? weil der Jitter den Code ständig zur "Laufzeit" optimiert und ihn so immer besser den umständen anpassen kann,  *



Das ist falsch.

C# ist nach meinen eigenen Benchmarks noch etwas langsamer als Java. Und nicht mal annaehenrnd so schnell wie C++.
Kann es auch gar nicht. Mit C++ nutzt du direkt die WinAPI, sprich du kommunizierst mit dem Betriebssystem in der Sprache in der es auch geschrieben wurde (C)  somit ist auch gerade bei grossen Projekten C# langsamer.
Wieso grade bei grossen Projekten ?

Der JIT kompiliert den Code vor der Benutzung und verwirft wieder. Das heisst wenn eine Funktion genutzt wurde die vor einiger Zeit genutzt wurde dann verharrt dein Programm um eben zu kompilieren.
Ich habe  einen  DB Mananger in  C# gecodet.  Ist nicht allzugross (ca. 7000 Zeilen) aber schon an diesem erkennt mann wenn man eine option aufruft das er kompiliert.

Sorry aber geschwindigkeitsmaessig kommt nur assembler ueber C ( C++ ist geringfuegig langsamer als C) und daran wird sich die naechste Zeit nichts aendern.

C++ ist sehr nah an der Maschine C# recht weit entfernt.
Wenn .net unc C# die Geschw. von Delphi erreicht koennen wir froh sein.


----------



## Christian Fein (22. März 2002)

Uebrigends 
kann mann C++ Code auch vom Kompiler auf geschwindigkeit optimieren.


----------



## Talla (22. März 2002)

Hallo

Das stimmt so nicht. Das .Net Framework hat 3 verschiedene Jitter, die unterschiedlich aufgerufen werden, je nachdem wie 

benötigt:
1. Vor dem ersten Programmstart --> Programm wird vor dem Start vollständig kompiliert und dann ausgeführt
2. beim Start --> Programm wird beim Starten vollständig kompiliert und gleichzeitig ausgeführt
3. wenn beötigt wird --> nur die Funktionen werden kompiliert die benötigt werden

Der 1. Jitter ist der schnellste, da merkt man keinen Unterschied in welcher Sprache das Programm geschrieben ist, 
Der zweite ist da langsamer weil ja beides gleichzeitig passiert, also kompilieren und ausführen, das ist aber der 
Standardjitter, deshalb brauchen .Net Programme relativ lange zum Start.
Deshalb kommen .Net Programme einen so langsam vor obwohl sie es gar nicht sind.
Und der Dritte kommt wirklich nur bei modular aufgebauten großen Programmen zum Einsatz und das ist der Fall den ich 
meinte. Es werden nur die Funktionen kompiliert die benötigt werden. Das spart Resourcen weil zB Programme in der 
Größenordnung Word nur Bruchteile ihrer ganzen Funktionen wirklich immer benutzen und Word in C# wäre dadurch um einiges 
schneller als Word in normalen C++(wetten das nächste Word wird in c# geschrieben sein oder wenigstens c++.net)
und außerdem ist da immer noch der Fakt das .net Programme ständig zur Laufzeit optimiert werden, daher der Code ändert 
sich ständig in Richtung Optimum und entspricht immer dem besten code für die Funktion. Natürlich gilt das auch wieder 
ab ner bestimmten Codegröße. Es ist klar das so nen Einzeilen Code wohl kaum optimiert werden kann. Aber trozdem ein 
Beispiel:Nen paar kleine Berechnungen in denen C# aufgrund der Optimierung während des ausführens ganze 20!!! Sekunden 
schneller ist als optimierter C++ code.Ich geb zu die ergeben keinen Sinn die Berechnungen aber die sind optimierbar und 
dauern auch ne Weile also wo der Jitter auch Zeit hat was zu optimieren. 

C#

```
using System;

class ForTest {
	public static void Main() {
		double a = 0;
		for(double i = 1;i<=100000000;i++) {
		a += Math.Sin(i);
		a += Math.Cos(i);
		a += Math.Tan(i);
		}
		Console.WriteLine(a);
	}
}
```
Dauer bis zum Ergebniss : 73 Sekunden

C++


```
#include <iostream.h>
#include <Math.h>

void main() {
	double a = 0;
	for(double i = 1;i <= 100000000; i++) {
		a += sin(i);
		a += cos(i);
		a += tan(i);
	}
	cout << a << endl;
}
```
Dauer bis zum Ergebniss : 97 Sekunden

Ich denke die Quellcodes nutzen die vergeleichbaren Funktionen, das dürfte also kein Problem sein.
Kannste ja selber ausprobieren, der c# Code ist um einiges schneller.
hab die Messungen bei mir gemacht, kann sein das wenn du nen schnelleren Pc hast die Zeiten abweichen.
Glaub mir bei großen Anwendungen wird C# ziemlich schnell C++ ablösen.
Das C++ näher an der Maschiene ist, ist klar und da wird C# auch nicht C++ ablösen, denn C# wurde ja hauptsächlich für 

Anwendungen entwickelt.

ciao


----------



## Xeragon (22. März 2002)

also mal zum thema COM-Interop: Das ganze System funktioniert solange man nichts wirklich sinnvolles damit machen muss... dann darf man de IL-Code per hand nachbearbeiten, wenn was sinnvolles rauskommen soll (einfachstes Beispiel: Array von Interface-pointern -> kommt bei jedem COM-Enumerator vor).
Nebenbei bemerkt werden pointer in referenzen verwandelt -> NULL-Pointer generieren fröhlich Exceptions.

Achja: "Jitter" heißt sinngemäß übersetzt in etwa "Zerstreuer", ich denke du meinst damit den JIT-Compiler

Der Geschweindigkeitsvergleich ist lächerlich:
- Weder Compiler noch Einstellungen sind genannt
- Der Messvorgang fehlt
- Die Trig-Funktionen der beiden Sprachen sind unterschiedlich implementiert
- Der C++-Code ist ... naja ... "anfängermäßig", willst du C++ tatsächlich mit C# vergleichen musst du auch entsprechende Optimierungen vornehmen z.b. intrinsic-SSE. OK, das ist nicht C++ Standard (aber in C# AFAIK gar nicht möglich), aber ich hab noch ein besseres Argument: In C++ kann die gesamte Schleife auf exakt EINE mov-Instruction reduziert werden... (template-metaprogramming; setzt entsprechende Compilereinstellungen bzw. Optimiermöglichekiten des Compilers vorraus), in C# unmöglich.

Ich für meine Teil werde auf C++ & Java (und vielleicht ein bisschen Smalltalk?) setzen.

EDIT: Ich habe deine beiden progrämmchen mal kurz mit dem VC++7 und aktuellem C# Compiler getestet (standardeinstellungen, release): ergebnis: c# ~32s C++: ~28s (mehrmals verifiziert)

Wenn der Code auch noch die Sprachfeatures von C++ ausnutzen würde (es ist ja ein Vergleich zwischen den beiden Sprachen, also warum bitte C++ nicht ausnutzen?) wäre es u.U. wie gesagt möglich das ganze auf eine mov-instruction zu reduzieren


----------



## Talla (22. März 2002)

Hallo

klar mein ich den Jit Compiler , der wird aber auch Jitter genannt im Englischen , aber des ist ja nebensächlich.

zu den Compilern die ich verwendet hab
C# --> den des VS.Net Beta 2, Deutsche Final wird ja erst im April ausgeliefert
C++ --> die des VS 6 warum? weil das die letzte Version ist die Vollständig ohne .Net auskommt

Messbedingungen:
P3 500
192MB Ram
Win XP Professional
keine weiteren Programme laufen
Release/nicht optimiert!

zu der Zeitmessung, die war einfach per Uhr *gg*
mag unprofessionel klingen, aber grade weil die Messfunktionen der Sprache so unterschiedlich sind hab ich das so 
gewählt und meineserachten ist das nicht ungenau.

Warum ich diesen Billigstcode verwendet hab?
Weil die Programme vergleichbar sein müssen, klar ich hätte den c++ code auch per inline assambler nen bisschen 
schneller machen können(Hast du ja schon implizit gesagt durch die Reduktion auf einen mov Befehl), aber das hätte ich 
denn auch bei dem C# Code machen müssen, oder am besten gleich auf IL Ebene optimieren  Warum kompliziert wenn auch 
einfach? Hauptsache die Programme bleiben vergleichbar!!! Es ging ja nicht wie du im letzten Satz gesagt hast um den 
Vergleich der Sprachen in Hinsicht Funktionalität, da ist C++ C# aufgrund des Alters und der damit vorhandenen 
Bibliotheken klar überlegen, aber das wird sich mit der Zeit ändern, es ging nur um die reine Geschwindigkeit.
Deine Messergebnisse kann ich leider nicht nachvollziehen, habe meine auch mehrmals verifiziert.
Aber ich denke mal an der Ähnlichkeit der Zeiten das du mit dem Vs.Net kompiliert hast,denn das verwendet bei beiden 
Sprachen die .Net Runtime, auch bei C++, das muss man ihr explizit sagen das das nativer Code werden soll.
Und das C++ schneller ist kommt wohl daher das der Compiler beim Release automatisch optimiert, im Gegensatz zum C# 
Compiler. 

Zu Com/Interop:
Klar gibt es auch Probleme, aber die treten beim normalen Benutzen nicht auf, es ist ohne Probleme möglich das zu 
benutzen, und die Fehler die du gesagt hast deuten eher auf schlampiges Programmieren hin.
Da lob ich mir doch die Typensicherheit von C# und die lieben Delegates


----------



## Xeragon (22. März 2002)

Der VC7-Compiler generiert ebenfalls standardmäßig native-code.
Und nein, man sollte nicht in beiden Sprachen den selben Code verwenden, das ist kein Compiler-Vergleich sondern ein Sprach-Vergleich: C# und C++.
Man sollte auch kein Inline-Assembler verwenden (genauso wie keinen IL-Code ändern) sondern nur C++ bzw. C#, in C++ ist es per template-metaprogramming möglich das ganze auf ein mov zu bringen, in C# meines Wissens nach nicht (kein ASM, rein C++).
Das einzige Problem, das sich in C++ dabei stellt ist ein Compiler der genügend inline-recursions auflöst, was allerdings in diesem Vergleich kein Problem ist, da es ja um die Sprache geht, nicht um den Compiler (d.h. Sprachstandard).


----------



## Xeragon (22. März 2002)

Bzgl. COM-Interop: Wenn C# nicht einmal in der Lage ist ein COM-Interface (das nebenbei ein Standard-Enumerator ist) richtig zu wrappen, dann ist das nicht von mir schlampig programmiert sondern, ein grober Fehler zu behaupten, dass C# COM verwenden kann.

Und sie treten beim normalen Benutzen auf!
Enumeratoren & NULL als Rückgabe od. Übergabe-Wert kommen häufig vor (und stellen keinen Fehler auf Seiten des COM-Objekts dar).

Das "nette" Verstecken sämtlicher COM-Funktionalität hinter new/delete stellt IMO ebenfalls einen schweren Design-Fehler dar: Versuch einmal ein COM Objekt das IClassFactory2 implementiert zu erstellen (oder direkt bei der Erstellung ein anderes als das default-interface zu bekommen). 

Genauso die sog. Typsicherheit: Sie verhindert sinnvolle und eindeutige Umwandlungen von z.b. int -> bool, bei ungültigen Casts gibt es allerdings erst zur Laufzeit!!! eine Exception, nicht einmal eine Warning zur Compile-Time!

Meines Erachtens ist C# eine ziemliche designtechnische Fehlkonstruktion, die ich in Zukunft besser vermeiden werde.


----------



## Talla (22. März 2002)

Hallo

Ok, kann sein das se bei Com nen paar Fehler gemacht haben, trotzdem würde ich durch eine Einzelheit nicht ne ganze Sprache verurteilen.

Zu der Typensicherheit: Was du gesagt hast ist wieder mal typisch C/C++, Welcher Idiot kommt schon auf die Idee Integer in bool zu casten? Solche Fehlkonstrukte sind die größte Fehlerquelle in nem Programm, das bekommen wir sogar in der schule zu hören(denk jetzt nicht hab keine erfahrung in c++, mach ich schon 3 jahre obwohl ich erst 11 klasse bin)und unsere Infolehrer könne das zeug echt gut, wären die nicht lehrer wären die auf garantie programmierer geworden.
also auf die kann man hören.
sowieso find ich ist C++ ziemlich überladen mit teilweise uralten zeugs und die abwärtskompatibilität zu C macht ne Menge an dem Potential zu ner schönen sprache weg.


----------



## Return FALSE (22. März 2002)

auf gut walliserdeutsch: 'was fer än scheiss hängert'

gut, ich hab nur die ersten einträge gelesen...

3D-(Game-)Engine ohne OOP????

was C# betrifft, kann und will ich nicht viel sagen, ich 'steh' auf C++ mit dem OOP... ein Spiel ohne OOP, unmöglich. Ich hab am anfang strukturiert geproggt... kam schnell an den anschlag.


----------



## Return FALSE (22. März 2002)

@talla

doch, den letzten beitrag hab ich mir auch gelesen...

ach, was hast du während den 3 jahren gemacht???

was für ein bullshit... das wegen deinem inf-lehrer ist mir kein argument. 
C++ sei alter schrott, und hänge zusehr an C... häng bitte noch 3 jahre drauf...  

C# gibts noch nicht so lange, und du schwörst schon darauf... C++ gibt es so viel... DirectX + C++ ist DIE plattform fürs gameprogramming, und wird es auch bleiben. jedenfalls wird C# in dieser hinsicht C++ nicht das Wasser reichen...


----------



## Xeragon (22. März 2002)

Die "kleinen Fehler bei COM" werden schnell ganz große Fehler, weil praktisch alles als COM-Objekt implementiert ist.
Einen int in bool zu casten erscheint sinnvoll nachdem false = 0; true = !false gilt, ist es einfach, eindeutig, nützlich und kommt häufig vor (if-conditions auf == 0).


----------



## Christian Fein (23. März 2002)

So erstmals ist dieser Code absolut inkorrekt.

Zweitens sind deine Ergebnisse auch incorrekt.

Drittens ist allein die Behauptung das C# nur auch nur in die  naehe von C++ kommt der absolute witz.

Sorry aber ich glaub da mehr meinen eigenen Benchmarks und ich glaube auch mehr Eric Gunnerson (einer der Haupt C# Compiler entwickler) der ebenfalls von geschwindigkeitsnachteilen spricht.

Die Optimierung ist ein Witz und ich waehre allgemein vorsicht bei C# die Optimierung einzuschalten.
Bei J++ gabs auch nen Optimierungsschalter dieser Bewirkte das J++ nicht in der Lage war eine einfache Rechnung richtig durchzufuehren.

"Welcher Idiot kommt schon auf die Idee Integer in bool zu casten"

Viele Entwickler seid einigen Jahren die die Software (inc. UNIX, Linux, Windows) geschrieben haben auf die dein geliebtes C# (auch der Compiler der dir dein C# kompiliert wurde teile in C gecodet) aufbaut.
Kommischerweise arbeitet sogar dein Computer mit 1,0. 

C++ ist nunmal einfach schwieriger so das du halt bei C++ / C
if(a)
schreiben kannst. Bei C# heisst das halt
if(a!=null)
schoen aber meinung nach ist der ausdruck if(a) korrekt. 
Wenn a was ist dann ist es was also true 
Ist nur fuer anfaenger ne Falle:
if(a=3) // Kann boese Falle werden

"Solche Fehlkonstrukte sind die größte Fehlerquelle in nem Programm, das bekommen wir sogar in der schule zu hören"

Wie ich gesagt habe bei anfaenger. Mit ein Bischen erfahrung passiert das nicht.  Ich wuerde mich niemals einen absolut profi schimpfen aber mir passiert das ueberhaupt nicht mehr.

"und unsere Infolehrer könne das zeug echt gut, wären die nicht lehrer wären die auf garantie programmierer geworden"

Da habe ich andere Erfahrung  
 Ich bin nun 26 und dementsprechend war als ich in der Schule war noch Pascal angesagt, das ne Zeit her ist.

""sowieso find ich ist C++ ziemlich überladen mit teilweise uralten zeugs und die abwärtskompatibilität zu C macht ne Menge an dem Potential zu ner schönen sprache weg.""

Naja wenn ich Windows API Programmier rufst du C funktionen auf. 
WinProc z.B. 
Die Abwaertskompatibilitaet ist gerade gut wenns um Zugreifen aufs OS geht.

Bedenke Windows 95,98,NT,2000 UNIX Linux alles C  nix OOP


----------



## Christian Fein (23. März 2002)

ach zu:

"ist C++ ziemlich überladen"

Es gibt ne schoene Sache in C++ die du selber schon in deinem komischen Schnipsel genutzt hast 

#include ! 

Du kannst alles schoen einbinden oder auch nicht einbinden. 

Du hast zuviel Microsoft Literatur gelesen 
Ich programmiere seid 6 Monaten auch C#. Und bin von der Sache recht ueberzeugt aber wer dir so nen Floh ins Ohr gesetzt hat das C# schneller als C++ ist den wuerd ich in ne Irrenanstallt einliefern.

C# ist sogar noch langsamer als Java ! Und Java kommt zu 80 % an C++ ran  (C++ Progger behaupten 70, Java Progger 90 % ) . 
Das kann sich in der naechsten Zeit noch aendern.
PS: Balmer (Ja der Microsoft - cheffe) hat saemtliche oeffentlichen Benchmark vergleiche zwischen Java und  C# verboten.


----------



## Talla (24. März 2002)

Hm verstehe deine Denkweise nicht

Erstmal hat Eric Gunnerson mit die Sprache designed, mit dem Compiler an sich hat er weniger zu tun.

Und wieso schließt du Rückschlüße von J++ auf C#, die überhaupt nicht stimmen.

Das mit dem casten: klar arbeitet der Computer mit 0 und 1(zwar nicht mehr soo lange aber ok*gg*) und wirklich nur mit 0 
und 1 und das ist der Unterschied zu C++. Bei 0 und 1 würde ichs ja noch notfalls einsehen, aber sobald jemand irgend 
nen anderen Integer castet ist das Schwachsinn zB. 

```
int a = 5;
if(a) {
..
}
```
das ist doch hohl, solche Schlußfolgerungen, Ist genauso als wenn man vergleichen würde(ziemlich kindisch aber passend)
true  = Ente
false = Hund
was ist mit Katze?
in c++ ist ne Katze nen Hund weil sie ja keine Ente ist :=)
das ist das Problem dabei, sie ist nunmal kein Hund 
Wenn es nur Enten und Hunde geben würde dann ok, aber so nicht
aber der letzte fall den du gesagt hast
if(a=3) ist wirklich nen blutiger Anfängerfehler, mach den auch nicht obwohl ich auch kein Profi bin.

Das mit meinen Infolehrer war nicht so gemeint bloß weil se Lehrer sind muss man auf sie hören, zu mal die auch auf C++ 
schwören  weil denen Pascal zu alt ist aber die haben schon halt Erfahrung und wissen von was die reden.

Mit überladen meinte ich nicht den Quellcode, so wie du mit #include gesagt hast, kann man schon recht ordentlich 
strukturieren, aber an das using von C# kommts nicht ran , höchstens Java mit import, nur doof das der Name auch dem 
reelen Dateinamen entsprechen muss , sondern hab mich eher auf die Sprachvielfalt bezogen.
Es gibt für C++ unzählige Libs und Klassen und kein normaler Mensch sieht da durch, und das ist schon kein Vorteil mehr 
wenn man für nen Problem zigtausend Möglichkeiten hat, nach Murphy's Computergesetzen nimmt man sowieso die falsche  

Und das Java auf 80 prozent an C++ rankommt, glaub ich dir nie, das musst du beweisen. Ich kann dir zig seriöse Quellen 
zeigen die von viel niedrigeren Zahlen sprechen. 
Und das mit dem Verbot von Benchmarks mit C#. Das stand in der Eula zu den Beta Versionen, wie es jetzt im Release ist 
weiß ich nicht.


----------



## Xeragon (24. März 2002)

Hmm, es macht durchaus Sinn auf bool zu casten, stimmt ja mit der binären Logik überein: 0 ist FALSE, alles andere ist TRUE, ich seh hier nichts verwirrendes oder Sinnloses?
Der Fakt, dass PCs mit 0 & 1 arbeiten hat damit allerdings nur geringfügig zu tun.
Man könnte hunderte Möglichkeiten finden um so einen Cast zu rechtfertigen (auch z.b. die Menge der natürlichen Zahlen usw.).

Wg. deinem Tier-Vergleich: Du machst dabei einen schweren Fehler:
Es würde NICHT gelten:
true = Ente
false = Hund

SONDERN:
false = Hund
true = !false


----------



## Talla (24. März 2002)

Ne da ist nix falsch in der Denkweise.
so wie du es geschrieben hast ist es in C++ implementiert.
false = Hund 
true = !false

Aber das wiederspricht voll der boolschen Logik
da gibt es nun mal nur zwei Zustände true oder false, und nicht das alles was nicht false ist true ist.Deshalb stimmt das so wie ich das geschrieben hab.


----------



## Xeragon (24. März 2002)

Hmm, es macht durchaus Sinn auf bool zu casten, stimmt ja mit der binären Logik überein: 0 ist FALSE, alles andere ist TRUE, ich seh hier nichts verwirrendes oder Sinnloses?
Der Fakt, dass PCs mit 0 & 1 arbeiten hat damit allerdings nur geringfügig zu tun.
Man könnte hunderte Möglichkeiten finden um so einen Cast zu rechtfertigen (auch z.b. die Menge der natürlichen Zahlen usw.).

Wg. deinem Tier-Vergleich: Du machst dabei einen schweren Fehler:
Es würde NICHT gelten:
true = Ente
false = Hund

SONDERN:
false = Hund
true = !false

Katze -> true ist also vollkommen logisch & korrekt ("nicht Hund").

Warum du deine Infolehrer erwähnt hast weiß ich zwar noch immer nicht, jedenfalls kann ich dir versichern, dass unsere aus der Praxis kommen, nicht evtl. beruflich Programmierer geworden wären.
(auch wenn das ganze hiermit so rein gar nichts zu tun hat...)

Die using-Direktive sagt nebenbei bemerkt nur aus, das dieser namespace ohne namespace-angabe verwendet werden kann, was so rein gar nichts mit dem physischen Include/Library-System zu tun hat.
(using gibts übrigens auch in C++).
usign ist eher eine Verletzung der Kapselung (wenn in zwei namespaces die selben Namen existieren ist das normalerweise kein Problem, using hebt die namespaces allerdings auf und die beiden namen kollidieren).

C#-technisch werden physische Beziehungen beim kompilieren/linken als Parameter angegeben.

Allerdings sei gesagt, dass sowohl C++ als auch C# nicht unbedingt eine ideale Lösung bieten.

Die Libraries von C++ seh ich keineswegs als Nachteil: jede hat einen bestimmten Zweck, die wichtigsten kennt man bald, uns man benutzt sie eben nur wenn man sie braucht.
Außerdem: der C++-Standard sieht AFAIK nicht viel mehr als die STL vor, also würde ich das nicht als "überladen" bezeichnen.
In C# darfst halt alles selber programmieren...

Das Java inzwischen 80% von C++ erreicht erscheint mir übrigens durchaus realistisch, vielmehr als 20% wird die VM wohl nicht wegnehmen.

Ahja: Es geht hier um den Vergleich der Sprachen nicht Compiler, was das angeht kannst du C# getrost vergessen (ich glaube es gibt ähmm... einen .. Compiler oder?)


----------



## Christian Fein (25. März 2002)

Talla hat gesagt.:
			
		

> Erstmal hat Eric Gunnerson mit die Sprache designed, mit dem Compiler an sich hat er weniger zu tun.


Wenn der Leiter Compiler Entwicklerteams wenig mit dem Compiler zu tun hat gebe ich dir  recht 



> Und wieso schließt du Rückschlüße von J++ auf C#, die überhaupt nicht stimmen.


Dieser Rechenfehler in J++ stimmt. War ein grosser Skandal. Ich kann dir gern ein paar Links raussuchen zu der Geschichte. Ich sage nicht das dies beim C# Compiler & Optmiriere genauso ist aber solange C# Compiler nicht einige Zeit gezeigt hat das es nicht so ist, bleib ich skeptisch.


> Es gibt für C++ unzählige Libs und Klassen und kein normaler Mensch sieht da durch, und das ist schon kein Vorteil mehr


Es gibt x tausend librarys, aber wenn ich  einen Datenbankfrontend  fuer eine mysql Db schreiben will, schau ich mir  mysql++ Library an (naheliegend).
Will ich fuer Linux eine Datenbankfrontend  entwickeln schau ich mir mysql++ und z.B. Qt Biblothek (KDE) an.
Will ich ein Spiel programmieren habe ich mit mysql++ library gar nix zu tun.
PS: Die using Direktive kommt von C++. Namespaces kommen von  C++.  



> Und das Java auf 80 prozent an C++ rankommt, glaub ich dir nie, das musst du beweisen. Ich kann dir zig seriöse Quellen
> zeigen die von viel niedrigeren Zahlen sprechen.


Kenne zig "serioese" Quellen die  Sprechen von mehr als 80 %. Aber glaub mal nicht serioesen Quellen und wenn du  serioese Quellen beziehst schau auch auf das Datum wann dieser serioese Test durchgefuehrt worden ist. 
Wir haben hier in der Firma in der ich arbeite eine Firmeninterne Studie gemacht zu Java und dieser glaube ich mehr.
Ausserdem verwendet C# eine Java aehnliche Technik.
Du behauptest das C# schneller als C++ ist aber Java nicht die 80 % von C++ erreicht. 
Sorry aber da geb ich mal nc. 



> Und das mit dem Verbot von Benchmarks mit C#. Das stand in der Eula zu den Beta Versionen, wie es jetzt im Release ist
> weiß ich nicht.


Meiner Info nach:
 nicht widerrufen.




> Aber das wiederspricht voll der boolschen Logik
> da gibt es nun mal nur *zwei Zustände* true oder false



Du schreibst es ja selber : 
2 Zustaende. Das heist 



> und nicht das alles was nicht false ist true ist.



Nach deiner Rechnung waehren wir bei  3 zustaenden.
True
False
Nicht True aber auch nicht False (undefined?)

2 Zustaende sind nunmal True / False !
Das beeinhaltet das wenn etwas nicht True ist ist es  False 
Wenn etwas nicht False ist kann es nur True sein.


----------



## Kimble (7. April 2002)

hi,
Ich programmier schon länger in C++ und muss sagen, wenn ich ein Programm schreib, mach ich das ganz sicher in C++ und nicht C#.
C# ist zwar leichter, was jeder sagt, aber letztendlich kommt es bei manchen Sachen auf die Geschwindigkeit (C++ IST SCHNELLER ALS C# ) an und darauf was man besser findet!!!
Die einen finden vielleicht C++ besser, die andern C#. 

Deshalb isses Schwachsinn, dauernd zu schwätzen was geil am C# oder C++ ist, jeder sollte das nehmen, was er besser findet!


----------

