C# Programmierungs fragen! [Archiv]

Archiv verlassen und diese Seite im Standarddesign anzeigen : C# Programmierungs fragen!

hasang321654

2003-02-17, 15:07:36

Hallo,
Ich bin es mal wieder.
Ich will nun anfangen mit der programmierung von C# (sprich: C Sharp)
So nun: Meine Frage ist, kann man Spiele mit C# erstellen?
2.Um wieviel Prozent hat die Sprache mit Java, C/C++ und Visual basic zu tun (als Prozent/ nicht alle drei zusammen sondern einzeln)
3.Empfielt ihr mir die Sprache?

P.S Tut mir leid, wenn meine Texte so Agressiv klingen aber ich habe es "JETZT" eilig und bin gespannt auf eure Fragen.

Demirug

2003-02-17, 15:38:26

hasang321654

2003-02-17, 18:45:46

Naja hauptsächlich für Windows.
Ich habe heute gelesen, dass es seinen größten Anteil an Java und C++ hat. Basic auch( dem Design dieses wie beim Visual Basic6 usw.)
Es ist nur kleiner (die Programme) besser, schneller und flexibler.

Es eignet sich also genau für mich( ich kann einiges von C++, von Java und ich kann mit der leichtigkeit von Basic umgehen.

Merkmale von C++: Durch Zeiger kann das Programm abstürzen.
Erstellt die schnellsten Software Produkte
Programme sind ziemlich gross.

Merkmale von Java: Programme sind ziemlich klein.
"Relativ" Schnell(man hat sogar diskussionen von Proffesoren zu Proffesoren gemacht, welche der beiden Sprachen (java, c++) schneller ist.
Internetprogrammierung.
Script möglichkeit.

Merkmale von Visual Basic: Programme klein
Absolut langsam.
Kann fast NIE abstürzen
Nicht objektorientiert (bei der dotnet version schon aber bei sechs nicht!)

hasang321654

2003-02-17, 18:46:50

Und die Moral der Geschicht:

(C# beherrscht all die positiven Sachen und wurde verknüpft mit allen Sprachen.)

C# kann man, oder nicht!

MeLLe

2003-02-17, 21:40:31

Originally posted by hasang321654
Merkmale von C++: Durch Zeiger kann das Programm abstürzen.
Erstellt die schnellsten Software Produkte
Programme sind ziemlich gross.
1) Durch korrekte Programmierung sind die Zeiger in C/C++ ein gewaltiger Vorteil ggü. anderen Sprachen. Nur dadurch, dass man in C/C++ mit Zeigern arbeiten kann, stürzt kein Programm ab. Es liegt immer an der Weitsicht und Erfahrung des Coders.
2) Glaubensfrage - ASM anyone? ;)
3) Die Benutzung von dynamischen Bibliotheken usw. führt zu sehr schlanken Binaries.

Originally posted by hasang321654
Merkmale von Java: Programme sind ziemlich klein.
"Relativ" Schnell(man hat sogar diskussionen von Proffesoren zu Proffesoren gemacht, welche der beiden Sprachen (java, c++) schneller ist.
Internetprogrammierung.
Script möglichkeit.
1) Nimmt man die Java Runtimes zur Programmbgröße dazu, sieht der Vorteil "Programme sind ziemlich klein" schonwieder ganz anders aus.
2) "Relativ" ;)
3) Das ist nun eine Frage des Einsatzgebiets, das ist IMHO kein Argument zum direkten Vergleich mit andern Sprachen.
4) JavaScript hat mit Java nicht sonderlich viel zu tun.

Originally posted by hasang321654
Merkmale von Visual Basic: Programme klein
Absolut langsam.
Kann fast NIE abstürzen
Nicht objektorientiert (bei der dotnet version schon aber bei sechs nicht!)
1) Veto! VB bläht Code mächtig auf.
2) Ab .net kaum langsamer als VC.net
3) Kann doch. Sogar richtig effektvoll. Wie ganz oben bei C/C++ erwähnt - es liegt IMMER am Coder!
4) Seit wann ist VB nicht objektorientiert? Hmmm. "CreateObject()", "GetObject()", "MyButton.Enabled = True", ... Das schaut mir schon nach einer Spur von Objektorientiertheit aus.

firewars

2003-02-17, 21:47:09

Stichwort ASM (ok, nur gering ASM ;)):

Kann man rein theoretisch direkt "in die Maschine coden"? Gut, klingt seltsam. Was ich meine, ist, ob man noch ein Level tiefer als Assembler gehen kann? Rein theoretisch ;)

Demirug

2003-02-17, 21:55:50

MeLLe, Zeiger sind in C/C++ ein notwendiges Übel. Ich verzichte bei Programmieren sehr gerne darauf den die meisten Fehler passieren nun mal im Umfeld der dynamischen Speicherverwaltung. Deswegen mag ich ja C# da kümmert sich das System selbst um diese Sachen und Zeiger sind da nicht mehr notwendig.

ja ASM ist schön für Leute die zuviel Zeit haben.

dynamischen Bibliotheken = DLL HELL

Demirug

2003-02-17, 21:59:41

Originally posted by firewars
Stichwort ASM (ok, nur gering ASM ;)):

Kann man rein theoretisch direkt "in die Maschine coden"? Gut, klingt seltsam. Was ich meine, ist, ob man noch ein Level tiefer als Assembler gehen kann? Rein theoretisch ;)

Ja man kann noch tiefer gehen. Zwar nicht mehr viel aber man kann. In diesem Fall schreibt man direkt die Codesequenzen mit Hex oder Binärzahlen. Also genau das was später in der ausführbaren Datei steht. Zeum Teil musste man sich sowas auch wirklich noch abtun. Wenn es zum Beispiel eine neue Befehlserweiterung (MMX, SSE, 3DNOW, ...) gibt und man noch keinen Assembler dafür hat geht es nur damit das man direkt die Processorobcodes benutzt.

firewars

2003-02-17, 22:04:38

Hmm, interessant.
ASM wird ja durchaus "hier und da" gecodet, aber programmiert auch irgendwer so "direkt", wie du es beschrieben hast?

Demirug

2003-02-17, 22:11:45

Originally posted by firewars
Hmm, interessant.
ASM wird ja durchaus "hier und da" gecodet, aber programmiert auch irgendwer so "direkt", wie du es beschrieben hast?

Nein so wahnsinnig ist keiner. Die einzige Ausnahme habe ich ja schon aufgeführt.

Vedek Bareil

2003-02-17, 23:47:06

Originally posted by Demirug
MeLLe, Zeiger sind in C/C++ ein notwendiges Übel. Ich verzichte bei Programmieren sehr gerne darauf den die meisten Fehler passieren nun mal im Umfeld der dynamischen Speicherverwaltung. Deswegen mag ich ja C# da kümmert sich das System selbst um diese Sachen und Zeiger sind da nicht mehr notwendig. hm, ich weiß nicht ganz genau, was du mit dynamischer Speicherverwaltung meinst, aber für solche Sachen wie dynamische Arrays braucht man unter C++ eigentlich nicht notwendigerweise Zeiger. Man kann stattdessen auch Vektor-Klassen verwenden, die muß man noch nichtmal selber programmieren, da gibt's vorgefertigte Bibliotheken für, wie die STL. Solche Vektor-Klassen gelten zwar AFAIK nicht als dynamische Arrays, aber sie erfüllen denselben Zweck ;)
Intern werden die dann zwar wohl auch von Zeigern Gebrauch machen, aber da hast du dann ja nichts mit zu tun, genausowenig wie in C#.

Demirug

2003-02-18, 00:06:29

Vektoren, Linked Listen und solche Dinge sind nur ein Teil wo man mit den Zeigern und der dynamischen Speicherverwaltung in Berührung kommt. Ein grosser andere Teil ist die Verwaltung von dynamisch angelegten objekten auf die von vielen Stellen referenziert wird. Da gibt es immer wieder Probeleme bezüglich der Besitzfrage des Objects was dann oft damit endet das man Refernzcounter in die Objekte einbauen muss.

Die STL ist ganz nett aber sie performt relativ schlecht und war deshalb bisher für meine Zwecke nur bedingt geeignet.

Das Hauptproblem mit dem C++ Heap ist das er ein Longrun Problem hat. Mit zunehmender Laufzeit des Programms fragmentiert er immer stärker was gleichzeitig dazu führt das er immer langsamer wird. Bei den meisten Anwendungen fällt das nicht auf aber wenn man einmal Programme geschrieben hat die nicht nur Stunden sondern Tage (bzw 24/7) laufen müssen lernt man sehr schnell die grenzen des Heaps kennen.

Ein weiteres Problem ist die relativ schlechte allgemeine Performances des Heaps sowie die nicht vorhande skalierung bei Multi-CPU Systemen.

Es gibt zwar für viele dieser Probleme mehr oder minder gute Speziallösungen aber so richtig überzeugen konnte mich da noch keine.

hasang321654

2003-02-18, 16:31:25

Die Moral der Kommentare
C# mag man oder nicht!

Nein nein, C# ist aber weitaus wirklich besser (auf jedenfall gegenüber Java) C++ ist sehr gut ich habe nichts gegen die Sprache aber eine Programmiersprache die drei Programmiersprachen in sich beinhaltet finde ich besser!

Unregistered

2003-02-18, 18:08:43

es gibt leute die coden alles in assembler, zum beispiel geoff cramond (stichwort: grand prix reihe) er codet nur asm

zeckensack

2003-02-18, 20:16:28

Demirug,

Fragmentierung des Heaps ist sicher nicht schön, ist aber eine Frage der Implementierung der STL. Da gibt's ja mehrere Möglichkeiten, und was auf MS-Compilern/Windows nicht gut läuft, könnte mit GCC und passendem Kernel schon ganz anders aussehen (umgekehrt isses natürlich genauso möglich).

Ein richtiges Problem hast du erst dann, wenn du selber mit Zeigern auf dynamisch verwalteten Speicher hantierst. Die Maschine garantiert dir jederzeit, daß 'dein' Speicher mit 'deinem' Zeiger zu benutzen ist. Und das ist auch der (mögliche) Vorteil der STL: die Zeiger werden wegabstrahiert. Der Standard-Library steht es frei, Garbage collection und Reallokationen transparent durchzuführen. Daß das bisher für dich nicht geklappt hat, deutet für mich eher darauf hin, daß der Compiler die STL nicht intelligent genug implementiert.

Demirug

2003-02-18, 20:55:15

Originally posted by zeckensack
Demirug,

Fragmentierung des Heaps ist sicher nicht schön, ist aber eine Frage der Implementierung der STL. Da gibt's ja mehrere Möglichkeiten, und was auf MS-Compilern/Windows nicht gut läuft, könnte mit GCC und passendem Kernel schon ganz anders aussehen (umgekehrt isses natürlich genauso möglich).

Ein richtiges Problem hast du erst dann, wenn du selber mit Zeigern auf dynamisch verwalteten Speicher hantierst. Die Maschine garantiert dir jederzeit, daß 'dein' Speicher mit 'deinem' Zeiger zu benutzen ist. Und das ist auch der (mögliche) Vorteil der STL: die Zeiger werden wegabstrahiert. Der Standard-Library steht es frei, Garbage collection und Reallokationen transparent durchzuführen. Daß das bisher für dich nicht geklappt hat, deutet für mich eher darauf hin, daß der Compiler die STL nicht intelligent genug implementiert.

zeckensack, ich muss mit den Zeigern hantieren weil ich sehr viel COM in der Anwendung habe. Und dort arbeitet man ja zwangsläufig nur mit Zeigern auf Objekte. Um das ganze nun noch richtig kompliziert zu machen komunzieren tausende von COM Objekten teilweise über Zirkelbezüge mit Interfaces miteinader. In den Collections speichere ich dort also fast nur Zeiger auf Objekte (Interfaces). Und zu allem übel müssen dort auch noch im millisekunden bereich ständig Listen aktualisiert werden. So wird zum Beispiel jede Sekunden eine Liste mit mehren hundert einträgen gefüllt und wieder geleert. Die STL Implemetierung vom VC60 ist wirklich nicht gut aber unsere Applikation war nur mit diesem Compiler einigermassen in den Griff zu bekommen (native Compilersupport für COM) und unsere eigenen Speichermangementfunktionen sind inzwischen so genau auf die Application abgestimmt das sie von der Performances kaum noch zu überbieten sind.

Eine Garbage collection ist eine schöne Sache nur wenn sie nicht über den gesamten Heap laufen kann ist und bleibt sie suboptimal. Und da C++ kein strenges Typensystem hat läst sich dort niemals eine Garbage collection einbauen die man als sicher und stabil ansehen kann.

Das mag ich ja an der CLR. Ein streng typisiertes Model. Die Speicherallokation ist sehr schnell und das Aufräumen des Heaps kann auf einen Zeitpunkt verschoben werden wenn die CPU sowieso nichts zu tun hat. Das einzige was ich gernen noch hätte wäre etwas mehr Kontrolle über die Garbage collection. Soll heisen das ich sie temporäre abschalten kann und beim durchführen der Collection eine maximalzeit angeben kann.

zeckensack

2003-02-18, 21:16:08

In Spezialfällen greife ich auch gerne zu eigenem Speichermanagement. Und ich nutze auch sehr gerne Zeiger ;)

Trotzdem halte ich die STL für ein sehr elegantes Design. Manchmal will man sich halt nicht so abplagen, sondern einfach etwas lauffähiges zusammenschmeißen :D

#include <vector>
#include <functional>
#include <algorithm>

class
ColorCount
{
public:
ColorCount(uint color,uint count):color(color),count(count) {};
uint color;
uint count;
bool operator > (const ColorCount rhs)const{ return(count>rhs.count); }
};

void
top_secret_function_hrhr(const ubyte* const input)
{
uint i;
uint isize=width*height;
//count occurences of each color
std::vector <ColorCount> count;
for (i=0;i<256;++i) count.push_back(ColorCount(i,0));
for (i=0;i<isize;++i) ++count[input[i]].count;
//sort in order of occurence, descending order
std::greater <ColorCount> predicate;
std::sort(count.begin(),count.end(),predicate);
}

Ahh, ein Genuß =)

Unregistered

2003-02-19, 11:58:57

Sorry, dass ich mich an der Entführung des Threads beteilige...

Zeckensack, verwendest Du den Teil der funktionalen Programmierung der STL häufig (Prädikate etc.)? Hast Du da irgendwelche Verweise, wo es dafür so etwas wie best Practices gibt? Ich mir noch nicht so sicher, ob ich die STL in diesem Bereich genial oder total daneben finden soll.

Dein Beispiel zeigt die erste Schwäche: Der Code wird durch zusätzliche Klassen aufgebläht. Für fast jede STL-Methode (wie bei Dir sort) braucht du ein Funktionsobjekt - und das obwohl die Klasse sonst keinen interessiert. Im Falle von sort lasse ich mir das noch eingehen, aber bei for_each gewinnt man fast nix.

Die zweite und viel schwerwiegendere Schwäche: Per se lassen sich nur Funktionen (oder Funktionsobjekte aufrufen) jedoch keine Methoden von Objekten aufrufen - was natürlich im Widerspruch zum objektorientierten Ansatz steht. Die einzige Alternative ist a la mem_fun Templates zu stricken, die das machen.

In Java kann man so etwas durch anonyme Klassen extrem elegant lösen...

Euere Meinung?

zeckensack

2003-02-19, 12:26:37

Originally posted by Unregistered
Sorry, dass ich mich an der Entführung des Threads beteilige...

Zeckensack, verwendest Du den Teil der funktionalen Programmierung der STL häufig (Prädikate etc.)? Hast Du da irgendwelche Verweise, wo es dafür so etwas wie best Practices gibt? Ich mir noch nicht so sicher, ob ich die STL in diesem Bereich genial oder total daneben finden soll. Nutze ich selten (nur wenn's schnell fertig werden soll). Referenzen habe ich leider auch keine zu bieten, mal abgesehen vom Stroustrup. Den kann ich aber ehrlich gesagt auch nicht mal eben so zum Nachschlagen verwenden, dafür isses mir einfach viel zu heavy geschrieben. Im Zweifelsfall einfach in die Header schauen, mehr muß man idR nicht wissen.
Dein Beispiel zeigt die erste Schwäche: Der Code wird durch zusätzliche Klassen aufgebläht. Für fast jede STL-Methode (wie bei Dir sort) braucht du ein Funktionsobjekt - und das obwohl die Klasse sonst keinen interessiert. Im Falle von sort lasse ich mir das noch eingehen, aber bei for_each gewinnt man fast nix.for_each kenne ich nicht persönlich, und ich hoffe daß das auch so bleiben wird. Vor iteratoren graust's mir auch ziemlich.
Aber ... die Annahme daß der Code dadurch aufgebläht wird ist so nicht richtig. Dieses Funktionsobjekt aus meinem Beispiel ist (laut Header) leer, belegt also null Speicher. Einen Konstruktor gibt es auch nicht. Das einzige was interessiert ist der Typ und die Auswertungs-Funktion, die ist wiederum inline und leitet an an den Vergleichs-Operator um. Der ist auch inline ... IMO null Overhead.

Die Sortierung ließe sich (glaube ich) sogar so schreibenstd::sort(count.begin(),count.end(),std::greater <ColorCount> p);Damit wäre das Prädikat dann vollständig temporär. Nur mein Compiler (MSVC6) rafft das leider nicht :(

Wenn ich mit aufsteigender Sortierung zufrieden wäre, darf ich das Prädikat btw gleich ganz weglassen.
Die zweite und viel schwerwiegendere Schwäche: Per se lassen sich nur Funktionen (oder Funktionsobjekte aufrufen) jedoch keine Methoden von Objekten aufrufen - was natürlich im Widerspruch zum objektorientierten Ansatz steht. Die einzige Alternative ist a la mem_fun Templates zu stricken, die das machen.

In Java kann man so etwas durch anonyme Klassen extrem elegant lösen...

Euere Meinung? Sorry, das habe ich nicht richtig verstanden???
1)Meinst du 'die STL kann nur mit globalen Funktionen und Funktionsobjekten umgehen'???
2)Die STL ist ein riesen Haufen Templates. Ich verstehe den Vergleich mit mem_fun (was ist das?) deswegen nicht.

stefan42

2003-02-19, 13:02:20

(So, jetzt also auch eingeloggt...)

Das mit dem aufgeblähten Code war rein auf den Sourcecode bezogen - die Laufzeit ist bei STL wohl fast immer in Ordnung. ( Da merkt man, wie einen Literatur über OO den Blick verstellen kann ;) )

Zum zweiten Punkt ein Beispiel. Eine Klasse A Objekt hat eine geschützte (z.B. private) Methode print() die irgendwas kompliziertes macht und du hast einen iterator über eine Collection von Objekten vom Typ A. Schreit doch nach for_each. Nur wie aufrufen? Ein Funktionsobjekt schreiben, das dann print für das übergebene Objekt aufruft? Bäh, eine Klasse zusätzlich und einen neuen Freund für A, das ist nicht schön. Das Problem ist, dass die meisten stl Funktionen als Parameter auch Funktionen wollen. Und da kann man dann nur globale Funktionen oder Funktionsobjekte verwenden.

Ich wüsste zu gerne wie man so etwas in einem ästhetisch ansprechenden, objektorientierten Ansatz unterbringt.

Xmas

2003-02-19, 13:20:46

Originally posted by zeckensack
Die Sortierung ließe sich (glaube ich) sogar so schreibenstd::sort(count.begin(),count.end(),std::greater <ColorCount> p);
Dies sollte klappen:
std::sort(count.begin(),count.end(),std::greater <ColorCount> () );

Xmas

2003-02-19, 13:22:18

Originally posted by stefan42
Ich wüsste zu gerne wie man so etwas in einem ästhetisch ansprechenden, objektorientierten Ansatz unterbringt.
C# Delegates ;)

zeckensack

2003-02-19, 13:27:03

Wenn du print() von außerhalb benutzen willst, wieso machst du es dann private?

Davon abgesehen verstehe ich jetzt was du meinst :)
Wie wär's mit einer Template? ;)
Also ein typisiertes Funktionsobjekt (oder vielmehr eine Klasse), das mit jeder anderen Klasse zusammenarbeitet, das die Funktion 'print()' zu bieten hat.

Das ist natürlich auch nicht wenig Arbeit, aber die könntest du dann wenigstens für mehrere verschiedene Klassen nutzen.

hasang321654

2003-02-19, 22:51:14

Wer von euch allen ist mit C# (auch dotnet) vertraut?

grakaman

2003-02-19, 23:07:23

... bisher aber nur im Bezug auf Webforms.

MfG

Xmas

2003-02-19, 23:46:01

Ich beschäftige mich erst seit kurzem richtig mit C#, aber dank der Ähnlichkeit mit C++ ist die Eingewöhnung einfach.
Was allerdings ein bisschen nervt ist dass es keine globalen Elemente mehr gibt und man stattdessen statische Member und Methoden nehmen muss ;)

zeckensack

2003-02-28, 07:20:53

Originally posted by Xmas

Dies sollte klappen:
std::sort(count.begin(),count.end(),std::greater <ColorCount> () ); Nope.
Weder MSVC6, noch GCC3.2 fressen dieses Konstrukt.
Ich muß std::greater <_T> explizit vorher instanzieren.

stabilo_boss13

2003-02-28, 08:50:52

Originally posted by hasang321654
Hallo,
Ich bin es mal wieder.
Ich will nun anfangen mit der programmierung von C# (sprich: C Sharp)
So nun: Meine Frage ist, kann man Spiele mit C# erstellen?
2.Um wieviel Prozent hat die Sprache mit Java, C/C++ und Visual basic zu tun (als Prozent/ nicht alle drei zusammen sondern einzeln)
3.Empfielt ihr mir die Sprache?

P.S Tut mir leid, wenn meine Texte so Agressiv klingen aber ich habe es "JETZT" eilig und bin gespannt auf eure Fragen. Natürlich kann man mit C# auch Spiele erstellen. Das kann man aber auch mit GWBasic! ;) Ob es allerdings jemals ein Spiel wie Splinter Cell in C# geben wird, ist einen ganz andere Frage. Neben der Problematik der Performance, kommt natürlich noch hinzu, dass bei C# der Disassembler gleich mitgeliefert wird. Wenn man daneben die Lizenzkosten für eine gute 3D-Engine stellt, muss man sich fragen, ob das Kapital der Entwicklungsstudios (der Sourcecode!) wirklich herausgegeben werden wird. Bis heute ist mir jedenfalls keine einzige professionelle kommerzielle Applikation in C# bekannt.

C# ist eher eine Mischung aus C++ und Pascal. Das kommt einfach daher, dass der maßgebliche Entwickler von Borland zu Microsoft gewechselt ist und dort vorher für Delphi zuständig war. Diese Wurzeln kann C# imho nicht verbergen.

Auf die Frage, ob ich dir die Sprache empfehlen würde, folgt ein ganz klares jein.
Einerseits ist die Sprache gut gemacht und die üblichen Fallstricke der C++ Programmierung sind weitgehend entfernt. Auf der anderen Seite ist sicher eine gewisse Skepsis gegenüber einem von Microsoft allein neu eingeführten Standard angebracht.
Der erzeugte IL-Code ist identisch mit dem von VB.net. Du kannst also exakt das gleiche Ergebnis mit Visual Basic erreichen. In der Performance gibt es da keinerlei Unterschied.
Ob C# eine grosse Zukunft bevorsteht, kann momentan wohl niemand beurteilen. Aber schau doch mal bei http://www.planetsourcecode.com/ vorbei. Auf der rechten Seite ist immer eine Aufstellung, wieviele Codezeilen für die einzelnen Sprachen vorhanden sind. Das ist ganz sicher nicht repräsentativ, aber lässt vielleicht einen Trend erkennen.

Der weltweit am meisten vorhandene kommerziell eingesetzte Sourcecode ist übrigens in Cobol geschrieben! Das liegt nicht etwa daran, dass das eine so tolle Sprache ist. Vielmehr ist Sourcecode im Laufe der Zeit zum Kapital der Firmen geworden. Und wer kann es sich schon leisten, alle paar Jahre seinen Code wegzuschmeissen und neu zu schreiben. Das ist nicht nur ein finanzielles Problem. Jeder neu geschriebene Code hat Fehler und die sind in den jahrealten Cobolprogrammen mittlerweile größtenteils beseitigt. Für Cobol gibt es aber auch reichlich Entwickler.

Einen Konverter für C++ nach C# o.ä. gibt es nicht. Microsoft hat es nicht einmal geschafft, dass VB6 Programme nach VB.net übernommen werden können. Es gibt zwar einen Importfilter, aber der hat bei mir noch bei keinem Projekt funktioniert. Vermutlich wird daher nur neuer Code in .net Sprachen eingesetzt werden. Bis sich C#, falls überhaupt, durchgesetzt hat, werden sicher noch einige Jahre ins Land ziehen.

Die Zukunft der .net Sprachen sehe ich eher im Bereich der Webservices.

Also: Falls du nur für dich zum Spaß eine Programmiersprache lernen willst, dann liegst du mit den .net Sprachen sicher nicht falsch. Willst du aber etwas lernen, was du später auch noch beruflich verwenden kannst, rate ich dir eher zu C++ oder Java. Schau einfach mal in einer Fachzeitschrift die Stellenanzeigen an, dann weisst du, was ich meine.

Demirug

2003-02-28, 09:08:26

Originally posted by stabilo_boss13
Natürlich kann man mit C# auch Spiele erstellen. Das kann man aber auch mit GWBasic! ;) Ob es allerdings jemals ein Spiel wie Splinter Cell in C# geben wird, ist einen ganz andere Frage. Neben der Problematik der Performance, kommt natürlich noch hinzu, dass bei C# der Disassembler gleich mitgeliefert wird. Wenn man daneben die Lizenzkosten für eine gute 3D-Engine stellt, muss man sich fragen, ob das Kapital der Entwicklungsstudios (der Sourcecode!) wirklich herausgegeben werden wird. Bis heute ist mir jedenfalls keine einzige professionelle kommerzielle Applikation in C# bekannt.

Die Performances ist gar nicht so schlecht. Die Performanes bei Fliesspunktberechnung ist noch etwas schlecht aber das ist ein Problem des Jiters und es wird daran gearbeitet.

Das Problem mit dem "lesbaren" IL-Code ist bekannt (hat Java ja auch) und es gibt extra Obfuscator dafür. Ansonsten muss ich aber auch sagen das bei einer so komplexen Sache wie einer Grafikengine (bzw das ganze Spiel) der reine IL-Code noch lange nicht reicht um das Gesamtsystem zu verstehen. Das Kostbare an einer Engine-Lizenz ist auch nicht unbedingt der Sourcecode (der mehr enthält als der ILCode) sonder der Support. Wenn man die Vorlaufzeiten bei der Softwareentwicklung bedenkt ist es nicht verwunderlich das es derzeit noch keine kommerzielle Massenmarkt-Applikationen gibt.

Auf die Frage, ob ich dir die Sprache empfehlen würde, folgt ein ganz klares jein.
Einerseits ist die Sprache gut gemacht und die üblichen Fallstricke der C++ Programmierung sind weitgehend entfernt. Auf der anderen Seite ist sicher eine gewisse Skepsis gegenüber einem von Microsoft allein neu eingeführten Standard angebracht.

C# wird nicht von Microsoft kontroliert. Die Kontrolle hat das ECMA.

Der erzeugte IL-Code ist identisch mit dem von VB.net. Du kannst also exakt das gleiche Ergebnis mit Visual Basic erreichen. In der Performance gibt es da keinerlei Unterschied.
Ob C# eine grosse Zukunft bevorsteht, kann momentan wohl niemand beurteilen. Aber schau doch mal bei http://www.planetsourcecode.com/ vorbei. Auf der rechten Seite ist immer eine Aufstellung, wieviele Codezeilen für die einzelnen Sprachen vorhanden sind. Das ist ganz sicher nicht repräsentativ, aber lässt vielleicht einen Trend erkennen.

Der C# Compiler erzeugt etwas besseren IL-Code was dann auch in einer minimal besseren Performances endet. Das hängt aber mit bestimmen Sprachenelementen in VB zusammen.

Einen Konverter für C++ nach C# o.ä. gibt es nicht. Microsoft hat es nicht einmal geschafft, dass VB6 Programme nach VB.net übernommen werden können. Es gibt zwar einen Importfilter, aber der hat bei mir noch bei keinem Projekt funktioniert. Vermutlich wird daher nur neuer Code in .net Sprachen eingesetzt werden. Bis sich C#, falls überhaupt, durchgesetzt hat, werden sicher noch einige Jahre ins Land ziehen.

Ja bei C++ hat es ja auch sehr lange gedauert.

Die Zukunft der .net Sprachen sehe ich eher im Bereich der Webservices.

Also: Falls du nur für dich zum Spaß eine Programmiersprache lernen willst, dann liegst du mit den .net Sprachen sicher nicht falsch. Willst du aber etwas lernen, was du später auch noch beruflich verwenden kannst, rate ich dir eher zu C++ oder Java. Schau einfach mal in einer Fachzeitschrift die Stellenanzeigen an, dann weisst du, was ich meine.

Im Serverbereich in Verbindung mit ASP.Net werden die .Net Sprachen schon fleisig eingesetzt. Was nun das lernen einer Sprache angeht so sage ich immer das es erst mal wichtig ist das Programmieren zu lernen der Syntax einer Sprache ist dann nur noch nebensachen.

stabilo_boss13

2003-02-28, 09:51:37

Stimmt alles, was du sagst!

Für mich stellt sich aber nach wie vor die Sinnfrage für C#.

Wer bisher seine Applikationen in C++ entwickelt hat, wird wohl auf managed/unmanaged C++.net weiterentwickeln. Visual Basic Programmierer setzten vermutlich eher auf VB.net.

Also werden wohl im Bereich der Softwareentwicklung nur Neueinsteiger auf C# setzen. Aber warum sollten sie das tun? Für C++ und VB gibt es unendlich Unterstützung und Sourcecode. Das ist imho für einen Einsteiger nicht unwesentlich.

Ich selbst entwickle nur zu Weiterbildungszwecken in C#.

Dass der erzeugte IL-Code von C# und VB praktisch identisch sei, hat übrigens Ralf Westphal auf einer der letzten Microsoft Entwicklerkonferenzen behauptet!

Demirug

2003-02-28, 10:13:11

Originally posted by stabilo_boss13
Stimmt alles, was du sagst!

Für mich stellt sich aber nach wie vor die Sinnfrage für C#.

Die Sinnfrage ist relative leicht zu beantworten. C# ist am besten auf die Möglichkeiten der CLR abgestimmt.

Wer bisher seine Applikationen in C++ entwickelt hat, wird wohl auf managed/unmanaged C++.net weiterentwickeln. Visual Basic Programmierer setzten vermutlich eher auf VB.net.

Wir nicht. Die alten Anwendungen werden zwar noch C++ gepflegt. Die neue Version ist aber eine komplette neuentwicklung auf .net Basis und dort kommt C# zum Einsatz. Mit managed C++ will ich hier keinen bestrafen.

Also werden wohl im Bereich der Softwareentwicklung nur Neueinsteiger auf C# setzen. Aber warum sollten sie das tun? Für C++ und VB gibt es unendlich Unterstützung und Sourcecode. Das ist imho für einen Einsteiger nicht unwesentlich.

Für C# gibt es inzwischen auch schon recht viel Sourcecode und aus der täglichen Praxsis muss ich sagen das ich mit C# viel schneller entwickle als mit C++. Sicherlich sind wir hier aber kein Musterbeispiel.

Dass der erzeugte IL-Code von C# und VB praktisch identisch sei, hat übrigens Ralf Westphal auf einer der letzten Microsoft Entwicklerkonferenzen behauptet!

Dann sollte er sich mal mit seinem Kollegen Bernd Marquardt unterhalten der hat mal einen schönen Vortrag darüber gehalten wo der VB.Net und der C# Compiler unterschiedlichen IL-Code erzeugen. Aber viel macht es nicht aus (VB.Net baut teilweise ein paar IL-Anweisungen mehr ein) so das Performancesgründe in der Praxsis sicherlich kein Entscheidungsgrund zwischen VB.Net oder C# sind.

Unregistered

2003-02-28, 10:24:45

Originally posted by Demirug Mit managed C++ will ich hier keinen bestrafen.Die ganze Wahrheit in einem Satz!!!!

Xmas

2003-02-28, 12:48:39

Originally posted by zeckensack
Nope.
Weder MSVC6, noch GCC3.2 fressen dieses Konstrukt.
Ich muß std::greater <_T> explizit vorher instanzieren.
Da hat sich der Template-Support in VC.net ja doch ein wenig verbessert.

Xmas

2003-02-28, 13:32:01

Originally posted by stabilo_boss13
Für mich stellt sich aber nach wie vor die Sinnfrage für C#.

Für mich ist C# so ziemlich das was ich mir schon lange gewünscht habe. Perfekt für die schnelle Entwicklung von Windows-GUI-Anwendungen geeignet, aber eben zum großen Teil mit C++ Syntax, nicht Delphi oder VB. Außerdem dank des Assembly-Konzepts perfekt für leicht erweiterbare Anwendungen geeignet. Negativ ist natürlich, dass man zum Ausführen der Programme die .net Runtime benötigt. Außerdem wächst die Sprache noch, es fehlen also noch ein paar Dinge.

Wenn ich absolute Performance will, nehme ich C++ mit ein wenig Inline-Asm.

hasang321654

2003-02-28, 23:13:48

Eine Frage an xMas gewidmet aber auch an alle anderen natürlich.
Also heißt das jetzt, wenn ich ein Programm entwickle, dass der Benutzer das .Net Runtime haben muss?

Wie kann man das umgehen?
Wie groß ist das Runtime?
Geht die Software dann nicht, wenn man sie nicht hat?

Demirug

2003-03-01, 00:18:23

Originally posted by hasang321654
Eine Frage an xMas gewidmet aber auch an alle anderen natürlich.
Also heißt das jetzt, wenn ich ein Programm entwickle, dass der Benutzer das .Net Runtime haben muss?

Ja

Wie kann man das umgehen?
Gar nicht

Wie groß ist das Runtime?
ca 20 MB

Geht die Software dann nicht, wenn man sie nicht hat?
Ohne die Runtime läuft sie nicht

In Zukunft wird die Runtime aber sowieso Bestandteil von Windows und man braucht sich darum keine Sorgen mehr zu machen.

hasang321654

2003-03-01, 09:41:14

Allo in Longhorn wird sie drinne sein?
Und für alle anderen Betriebssysteme wird es ein Uptdade geben?
Und woher kann man das Runtime runterladen (als LINK BITTE)?

Demirug

2003-03-01, 11:01:43

Ja bei Longhorn wird es sehr wahrscheinlich direkt dabei sein.

Lauffähig ist die Runtime:

Microsoft Windows® 98
Microsoft Windows NT® 4.0 (SP 6a required)
Microsoft Windows Millennium Edition (Windows Me)
Microsoft Windows 2000 (SP2 Recommended)
Microsoft Windows XP Professional
Microsoft Windows XP Home Edition

Download Englisch: http://www.microsoft.com/downloads/details.aspx?FamilyID=d7158dee-a83f-4e21-b05a-009d06457787&DisplayLang=en

Download Deutsch z.B: http://www.soft-ware.net/system/steuerung/runtime/p02903.asp