.net-Strategie von Microsoft (?)

[Bernhard Geyer]

Zitat von Chemiker:

Das Problem bei mir ist (ich Denke es geht einigen Anderen auch so), dass man Quellcode vor einiger Zeit geschrieben hat und diesen in seinen neuen Programme einbindet, ohne darüber nachzudenken. Er ist schnell und getestet. Über die Jahre sind diese Bibliotheken relativ groß geworden. Das war ja auch die Grundidee die hinter OOP steht, die Wiederverwendbarkeit.

Man wird ja nicht alle 2-3 Jahre einen Plattformwechsel durchführen (ok, manche M$ werden dies wenn man den Weg ODBC, DAO, RDO, ADO, ADO.NET und ADO.NET 2.0 betrachtet gemacht haben).

Zitat von Chemiker:

Um mit .NET vernünftig arbeiten zu können, muss dieser Quellcode neu geschrieben werden, dass heißt man fängt wieder bei Adam und Eva an.

Nicht ganz. Wenn du deinen Unit/Komponenten/Klassensammlung der letzten Jahre anschaust wirst du feststellen das diverse sachen du heutzutage nicht mehr komplett neu entwickeln müsstest sondern es fertige freie/kommerzielle Bibliotheken gibt die teilweise oder überwiegend diese Sammlung fertig implementiert für die neue Plattform anbieten. Und wenn man wirklich die 10 Schritte zurückgeht und z.B. statt einen Win32-Anwendung auf einmal eine 3-Tier-Anwendung mit SOAP und Browserbasierter Lösung sinnvoll erscheint ist es fraglich ob du überhaupt noch viel der alten Komponentensammlung (auch ohne Plattformwechsel Win32 -> .NET/Java) verwenden könntest.

[OregonGhost]

Ich möchte nochmal ein paar Dinge richtigstellen.

1. Zeiger
   Natürlich gibt es in .NET Zeiger. Die CLR mag sie nicht, aber in C# kann man sie problemlos in einem unsafe-Block verwenden. Mit kompletter C-Murks-Zeigerarithmetik und ohne Bereichsprüfungen.
2. Assembly
   Auch das gibt es. Nämlich in C++/CLI. Das verbindet .NET mit nativem Code, und im nativen Code kann man auch den Inline-Assembler verwenden. Es ist also kein Problem, performance-kritische Routinen in eine C++/CLI-Assembly auszulagern und sie dann aber von außen wie jedes andere .NET-Objekt zu benutzen. Da kommt man dann auch wieder an einen Punkt, wo es heißt: Für jedes Problem das passende Werkzeug.
3. Performance
   String.Format als Vergleich für das Delphi-Format anzubringen ist nicht wirklich sinnvoll. Ebensowenig das "Testprogramm", das da genannt wurde. Wenn ich in meinen Programmen mal schaue, wo die Performance fehlt, ist es äußerst selten eine BCL-Routine und ebensoselten ist es reines Numbercrunching. Meistens ist es ein Problem im Aufbau des jeweiligen Algorithmus. Also String.Format mit Delphi-Format in einer Schleife zu vergleichen und aufgrunddessen zu sagen, dass .NET langsamer ist, ist Blödsinn.
   Und meine aktuelle Windows-Forms-Anwendung hat lediglich eine Schwäche beim Rendern einer komplexen Grafik, weil da sehr viele weiche Rundungen drin vorkommen (aber das ist Sache der GDI+ und hat nichts mit .NET zu tun). Alles andere ist auch nicht langsamer als bei einer typischen Delphi-Anwendung. Und selbst wenn es so wäre, wäre das vollkommen egal, weil die Anwendung 99% ihrer Zeit entweder auf den Anwender wartet oder auf die Drittanbieterkomponente, die das Backend darstellt und die eben einfach langsam ist (übrigens in C++ geschrieben...)
   Die Tatsache, dass es eine rein .NET-basierte 3D-API für Windows und XBox360 gibt, zeigt doch, dass .NET auch performance-seitig ready for primetime ist. Und die ist sogar tatsächlich trotz GC sauschnell. Genau wie viele Beispiele aus dem DirectX SDK, die häufig in C# etwas schneller sind.
4. Enumeratoren
   Sind im Allgemeinen schnell und problemlos. Auf Desktop-Windows räumt der GC die Dinger recht schnell weg, dafür gibt es ja Generation 0. Beim Compact-Framework muss man etwas aufpassen, weil z.B. der GC der XBox360 keine Generationen unterstützt. Folglich sind die meisten Enumeratoren dort implizit Stack-Objekte.

Zitat:

Um mit .NET vernünftig arbeiten zu können, muss dieser Quellcode neu geschrieben werden, dass heißt man fängt wieder bei Adam und Eva an.

Nur wenn man natives Delphi oder Visual Basic ohne COM für den alten Code verwendet hat. Hat man C++ oder COM verwendet, ist eine Einbindung relativ unproblematisch. Und wenn alle Stricke reißen, gibt es auch noch P/Invoke und man kann damit auf alles zugreifen, was außerhalb von .NET liegt. Die Grundidee hinter .NET ist jedoch anders: Du kannst in einer beliebigen Sprache entwickeln und mit beliebigen Objekten in einer anderen Sprache zusammenarbeiten. Versuch mal, in Delphi eine in C++ geschriebene Klasse abzuleiten und du weißt, was ich meine.

[Macci]

@OregonGhost:

Nein, es gibt keine Zeiger in C#. Natürlich kann man in C++ wenn man da mit .NET arbeitet Zeiger verwenden. Gar keine Frage. Visual C++ is ja auch ein echter Compiler, und erstellt reine Windowsanwendungen.
C# ist was anderes, ein plattformunabhängiges System für virtuelle Maschinen. Es gibt keine Zeiger in C#.
Nehmen wir z.B. mal diese C-Code-Schnippsel:
(1) int (*arrayXYZ)[10];
(2) int *(arrayXYZ[10]);
(3) int *arrayXYZ[10];

Wo sind da die Unterschiede? Diese Frage wirst du mit C# nicht lösen können, weil C# keine Zeiger unterstützt. Probiers ruhig aus. In C++ funktionieren diese 3 Anweisungen einwandfrei, in C# lässt sich der Code nicht compilern.

Noch ein Beispiel, das in C# nicht funktioniert:

pi = arrayXYZ;
*(pi + 12) = 178;

Viele Grüße,
Macci

[Dax]

Zitat von Macci:

Noch ein Beispiel, das in C# nicht funktioniert:

pi = arrayXYZ;
*(pi + 12) = 178;

Satz: Macci hat Unrecht

Beweis:

Code:

class Program {
  unsafe public static void Test(int[] arrayXYZ) {
    fixed(int* pi = &arrayXYZ[0]) {
      *(pi + 12) = 178;
    }
  }

  public static void Main() {
    int[] bar = new int[13];
    foreach(int i in bar) Console.Write("{0}:", i);
    Console.WriteLine();
    Test(bar);
    foreach(int i in bar) Console.Write("{0}:", i);
  }      
}

Ausgabe

0:0:0:0:0:0:0:0:0:0:0:0:0:
0:0:0:0:0:0:0:0:0:0:0:0:178:

q.e.d.

[Macci]

Ja, jedoch ist das nicht der Code, den ich geschrieben habe. Denn ...

Zitat:

unsafe public static void Test(int[] arrayXYZ)
{
int *pi;
pi = arrayXYZ;
*(pi + 12) = 178;
}

int[] bar = new int[13];
Test(bar);

... führt zu:

Zitat:

Fehler CS0029: Eine implizite Konvertierung vom Typ "int[]" in "int*" ist nicht möglich.

In C++ klappt es dagegen wunderbar.

Außerdem funktioniert dein Code nur in einem als unsafe gekennzeichnetem Bereich, und ein extra Compilerschalter ist erforderlich, damit das überhaupt erlaubt ist.

Aus der C#-Hilfe:

Zitat:

In der Common Language Runtime (CLR) wird unsicherer Code als nicht überprüfbarer Code bezeichnet. Unsicherer Code in C# ist nicht zwangsläufig gefährlich. Es handelt sich vielmehr um Code, dessen Sicherheit nicht durch die CLR überprüft werden kann. Die CLR führt deshalb unsicheren Code nur dann aus, wenn er sich innerhalb einer vollständig vertrauenswürdigen Assembly befindet.

[phXql]

Und? Du hast behauptet es geht nicht, aber es geht doch, wenn man unbedingt will.

Wenn man abartiges Zeugs wie Zeiger verwenden will, dann geht das doch. Aber MS legt einem halt Steine in den Weg, weil die wohl auch endlich drauf gekommen sind, das Zeiger Schrott sind.

[jfheins]

Nur so rein aus Interesse - ist das schlimm?

Also geht dadurch Funktionalität verloren, sodass man bestimmte Aufgaben nicht in C# erledigen kann?
imho nein

Zitat:

Fehler CS0029: Eine implizite Konvertierung vom Typ "int[]" in "int*" ist nicht möglich.

Ja Mensch ... dann ist halt in dieser Sprache ein Array nicht direkt einem Pointer zuweisbar (bzw. nur durch &arr[0]) aber soo schlimm kann das doch nicht sein

Nur weil man etwas in einer verwandten Sprache machen kann, aber in dieser nicht, sollte man nicht gleich die Sprache als schlecht beiseite legen.

Dann dürte ja z.B. Java gar nicht existieren

[Macci]

Zeiger sind eine nützliche Sache Man kann damit sehr viel Gutes machen, allerdings auch sehr verwirrende Sachen.
Aber an einen unsafe-Block hatte ich gar nicht gedacht, da geht es natürlich schon, hast recht.

@jfheins: Naja wollte damit auch nicht sagen, dass es sooo schlimm ist, sondern nur dass mir die schöne Zeigerarithmetik irgendwie fehlt. Viele Programmierer lassen sich halt nicht gern was wegnehmen, dass sie liebgewonnen haben *g*

[mkinzler]

Referenzen sind aber Zeigern vorzuziehen auch unter Win32