MS Visual Studio - Sprachen und Designer

[Jürgen Thomas]

Zitat von F.W.:

Noch eine Sache: Wie groß werden eigentlich die Exen von durchschnittlich großen und "leeren" Projekten? ("leer" --> also wie bei Delphis Startzustand - ein leeres Formular -> kompilieren)

16 bis 32 kB sind gängige Größen. Der größte Teil der Funktionalität steckt in den Assemblies (DLLs) des NET Framework unter C:\Windows\Microsoft.NET\Framework\v3.5 oder so. Das entspricht etwa dem Konzept von Delphi mit separaten .bpl, aber wegen der MSIL viel konsequenter. Achtung: Das ist eine stark vereinfachte Erklärung, bitte keine Diskussion darüber.

Gruß Jürgen

[F.W.]

Zitat von jfheins:

Delphi Prism ist eine .net Sprache in Pascal-Syntax

Sprachen sind im .net Framework quasi beliebig austauschbar - du kannst eine Klasse in vb.net schreiben, sie in c# ableiten und diese dann in Prism verwenden

Ach ja, ist schon irgendwie geil

Aber das wirft jetzt noch eine andere Frage auf: Gibt es da jetzt zwischen den verschiedenen eingesetzten Sprachen noch Unterschiede, die dazu beitragen eine "für das Projekt geeignete" Programmiersprache zu wählen? (also ganz vorsichtig formuliert sowas wie: C++ ist schneller als Delphi)
Wobei mir natürlich klar ist, dass High-Performance-Anwendungen wie Spiele vlt nicht unbedingt in .NET geschrieben werden sollten, durch die VM. Aber gibt es zwischen den eingesetzten Sprachen z.B. Geschwindigkeitsvorteile oder andere Vorteile?

Zitat von Jürgen Thomas:

16 bis 32 kB sind gängige Größen.

Ich war mir nicht ganz sicher, ob die 19 kb wirklich alles sind, als ich nach der EXE im Projektverzeichnis gesucht hatte. Aber dann ist ja gut
Nur im Gegensatz

Zitat von Jürgen Thomas:

Der größte Teil der Funktionalität steckt in den Assemblies (DLLs) des NET Framework unter C:\Windows\Microsoft.NET\Framework\v3.5 oder so. Das entspricht etwa dem Konzept von Delphi mit separaten .bpl, aber wegen der MSIL viel konsequenter.

Und wenn man eine Delphi-Exe mit Laufzeit Packages ausliefert, dann ist zwar die Exe klein, aber die Packages sind größer als das Bündel in einer Datei. Lohnt sich also nur bei umfangreicheren Programmen wie TuneUp, wo viele Exen ausgeliefert werden. Aber der gravierendste Unterschied ist wohl, dass das .NET Framework auf sehr viel mehr Computern drauf sein dürfte, als die Delphi Laufzeit Packages, weshalb die Dateien so klein werden.

Das ist ja mal n netter Vorteil. Auch wenn im Zeitalter von DSL vielleicht vernachlässigbar. Aber ich finds nicht schön, wenn meine Delphi DLL mit einem Formular knapp 600 kb groß ist ^^

[Phoenix]

Zitat von F.W.:

Aber das wirft jetzt noch eine andere Frage auf: Gibt es da jetzt zwischen den verschiedenen eingesetzten Sprachen noch Unterschiede, die dazu beitragen eine "für das Projekt geeignete" Programmiersprache zu wählen? (also ganz vorsichtig formuliert sowas wie: C++ ist schneller als Delphi)
Wobei mir natürlich klar ist, dass High-Performance-Anwendungen wie Spiele vlt nicht unbedingt in .NET geschrieben werden sollten, durch die VM. Aber gibt es zwischen den eingesetzten Sprachen z.B. Geschwindigkeitsvorteile oder andere Vorteile?

Naja, eigentlich eignet sich .NET hervorragend, um Spiele zu schreiben. Schau Dir z.B. mal XNA an, womit man mit .NET Spiele für PC, die XBox 360 und den Zune schreiben kann. Da gibt es auch einige komplett fertige Spiele, anhand derer man sowas lernen kann.


Zu den .NET Programmiersprachen: Ja, es gibt Unterschiede. Sogar ganz gravierende. Das beruhigende 'Aber' ist allerdings: Diese Unterschiede machen sich nur in absoluten Grenzfällen bemerkbar.

Es gibt z.B. F#. Das ist eine Programmiersprache, die besonders für funktionale Entwicklung ausgelegt ist. Das geht zwar auch mit C#, ist dort aber relativ unangenehm zu schreiben.

Delphi Prism hat im Bereich Threading / Parallel Programming dank einiger Keywords gegenüber anderen Sprachen die Nase ganz weit vorne. Auch das kann man in anderen Sprachen von Hand machen - muss man aber nicht wenn man Prism nimmt.

Wer dynamische Sprachen benötigt greift zu IronPython, IronRuby oder Phalanger.

Nur sind funktionale Entwicklung, Aspektoriente Entwicklung, Dynamische Sprachen oder eben Parallel Programming doch eher 'Randgebiete' in der Entwicklung. Bei allem anderen, also die 08/15 OOP-Entwicklung, schenken sich die Sprachen gegenseitig eigentlich nichts. Da kommt es dann ganz auf die eigene Vorliebe (oder die vom Team) an, welche Sprache man da nimmt.

[F.W.]

Ok danke für die Infos

[Meflin]

Zitat von Phoenix:

Naja, eigentlich eignet sich .NET hervorragend, um Spiele zu schreiben.

Naja, jetzt lehnste aber weit aus dem Fenster Vieleicht sollte man das präzisieren zu "es geht" - "herrvorragend geeignet" ist mit Sicherheit übertrieben. Man denke sich mal so etwas wie GTA etc ohne Assembler-Optimierungen, da kann man sich gleich noch ne zusätzliche CPU in den PC denken...

Und derartiges ist mit dem .Net-Framework einfach ein Ding der Unmöglichkeit.

[Elvis]

Zitat von Meflin:

Zitat von Phoenix:

Naja, eigentlich eignet sich .NET hervorragend, um Spiele zu schreiben.

Naja, jetzt lehnste aber weit aus dem Fenster Vieleicht sollte man das präzisieren zu "es geht" - "herrvorragend geeignet" ist mit Sicherheit übertrieben. Man denke sich mal so etwas wie GTA etc ohne Assembler-Optimierungen, da kann man sich gleich noch ne zusätzliche CPU in den PC denken...
Und derartiges ist mit dem .Net-Framework einfach ein Ding der Unmöglichkeit.

Ein Großteil der kommerziellen Spiele ist eine wilde Mischung unterschieldicher Sprachen und Runtimes.
Oft gibt es eine (zugekaufte) Grafik/Physik-Engine, die so effizient geschireben ist, wie es möglich war.
Aber das Spiels selbst ist oft alles andere als hoch effizient geschrieben. Viele Spiele nutzen Skriptsprachen für NPCs, oder dynamische Levels, ...
Einige Spiele Vendor steigen auf Mono um, da es genauso flexibel und einfach zu programmieren ist, aber schneller als Scripting Srachen.

Wenn du auf eine Enige setzt, die Physik und Grafik mitbringt, kannst du sehr wohl in .Net/Mono games schreiben.
Der Performance untershied von dem, was du selbst schreiben würdest, wird sich kaum/gar nicht auswirken.
Verglichen mit nativen Sprachen kannst du aber in krüzerer Zeit, mitweniger Aufwand mehr stabileren Code schreiben.