Zitat von Christian Kusmanow

Sehr interessant. Ich frage mich immer wie ich es dann schaffe Objekte mittels IDisposable und dem using Statement geziehlt aus dem Speicher zu enfernen.

Naja, ich stamme noch aus den malloc() und free-Zeiten, der Gedanke an eine Garbagecollection behagt mir einfach nicht so, weil ich nicht sehe, was im Speicher passiert. Klar kann ich die Objekte freigeben, aber ich bekomme keinen echten Registerzugriff. Nenne es halt Nostalgie, wenn du willst.

Zitat von Christian Kusmanow

Das ist Nonsens.

Ansichtssache, aber prinzipiell - stimmt. Nur, genauso wenig wie .net der letzte Billig-Frickelrotz ist, genauso wenig ist es die Quadratur des Kreises. Mein Gott, selbst wenn .net Krebs heilen könnte, würde es mich nicht wirklich interessieren. Ich muß mit dem Ding arbeiten und es nicht anbeten. Wäre .net so gnadenlos schlecht, daß man damit nicht mal ein "Hello world" hinbekäme, dann könnte ich das sicher auch belegen und entsprechend den großen Tieren gegenüber argumentieren. So etwas hatte ich übrigens schon mal mit Java.
Glaub mir - ich würde mich nichts sch***en, wenn .net so unglaublich Kacke wäre, daß gar nichts ginge. Aber bislang funktioniert hier alles recht gut. Nur von meinem ganz persönlichen Magengrimmen abgesehen. Aber hey - es soll auch Leute geben, die auf Assembler schwören, wo ich mir dann leise mit dem Finger an die Stirn tippe. Also hast du genauso das Recht, meine Aversion gegen .net zu belächeln, weil die faktisch unbegründet ist. Aber der Mensch besteht halt nicht nur aus Fakten...

Zitat von Christian Kusmanow

Sunytaktisch mögen Sie sich vielleicht sehr ähneln aber das wars dann auch schon wieder.
Weiterhin hatte das .NET Framework bereits viele Technologien viel eher mit drin als das Framework von Java.
Zum Beispiel war das XML-DOM schon 3 Jahre früher mit bei und SOAP.

Ansonsten stimme ich Dir zu.

Was ist jetzt innovativer? Ein Fäustel, ein Zimmermannshammer, ein Holzhammer oder ein 08/15-Bastelhammer? Welche Hammerform war zuerst da? Welche hat mehr Tradition?

Ganz ehrlich?

Das geht mir am A**** vorbei, Hauptsache ich kann damit den Nagel versenken (und zur Not auch schrauben ). Wann irgendwo XML-DOM eingeführt wurde ist für mich nicht einmal annähernd so sehr von Bedeutung wie daß es eingeführt wurde.

Zitat von CSANecromancer

Was ist jetzt innovativer? Ein Fäustel, ein Zimmermannshammer, ein Holzhammer oder ein 08/15-Bastelhammer? Welche Hammerform war zuerst da? Welche hat mehr Tradition?

Traditionell gesehen würd ich immer noch die Keule bevorzugen. Einmal ausholen und Ruhe is.

Ansonsten würd ich den Hammer verwenden der sich der größe des Nagels entsprechend am besten eignet.

Und das ist der Punkt. Andauend versuchen die Leute Java mit .NET zu vergeleichen
und vergessen dabei für welches Gebiet diese 2 Sprachen jeweils vorgesehen waren.
Daher macht es auch keinen Sinn darüber zu diskutieren.

Zitat von CSANecromancer

Das geht mir am A**** vorbei, Hauptsache ich kann damit den Nagel versenken (und zur Not auch schrauben ). Wann irgendwo XML-DOM eingeführt wurde ist für mich nicht einmal annähernd so sehr von Bedeutung wie daß es eingeführt wurde.

Man sieht aber dabei sehr gut für welche Einsatzgebiete sich .NET am besten eignet,
da es eben in diesen Gebieten mit aktuellen Technologien aufwarten kann...
(Das soll jetzt aber nicht heißen, dass das bei Java nicht der Fall ist. Ich denke ihr versteht was ich meine...)

> Sehr interessant. Ich frage mich immer wie ich es dann schaffe Objekte mittels
> IDisposable und dem using
> Statement geziehlt aus dem Speicher zu enfernen.

Du weißt aber schon, daß dieses nur eine impliziter Destruktor ist? Das Objekt wird dann nur für den GC freigeben, nicht jedoch wirklich aus dem Speicher entfernt. Es gibt defacto keinen wirklichen Destruktor in .net, daß muß es auch gar nicht. Der GC arbeitet effizient genug und für die paar Fälle in denen ein manuelles Freigeben nötig ist, existiert dann halt ein "dispose" oder halt "IDisposable".

Ich bin auch durch andere Sprachen daran gewöhnt "sauber" zu arbeiten, also alles was ich nicht mehr brauche auch vernünftig wegzuräumen. .Net nimmt mir aber die Arbeit ab, ohne das ich jedoch weiß *wann* der Speicher wirklich wieder frei ist. In kleinen Projekten macht das rein gar nicht, in großen perfomanten aber sollte man deswegen kein .Net einsetzen. (Ähnliches gilt ja auch für Java).

Letztendlich steht .Net im Ruf eine hervorragende Sprache zu sein, da man sich um vieles keine Gedanken machen zu braucht. Zum Lernen einer Sprache ich zwar Nachteile dadurch, aber im Bereich der Softwareentwicklung für Leistungsunkritische Bereiche ist es bis jetzt ideal.

BTW: In der aktuellen iX steht ein wunderbarer Artikel über Aspektorientiertes Programmieren. Zwar ein "alter" Hut, aber vom konzeptionellen her würde es wunderbar in die Idee von .Net passen.

@Dispose:
Wenn man das IDisposable Interface implementiert muss man dessen Methode Dispose implementieren,
in der man nach dem Bereinigungsprozessen GC.SuppressFinalize( this ) aufruft.
Menn man nun die Methode Dispose nur händisch aufgeruft, wird das Objekt für den GC freigegeben, das stimmt.
Wenn man aber das Objekt mittels using verwendet, wird die Dispose Methode nach dem Block automatisch aufgerufen
und anschließend verschwindet das Objekt aus dem Speicher. Teste es doch mal aus.

[destruktor]

Ich muß eingestehen, daß kannte ich noch nicht. Mann kann also Objekte indirekt sofort löschen, indem man dem GC anweist sofort loszulegen. Jetzt mach das aber mit ein paar tausend (oder hundert) Objekten und schon wird das Programm gnadenlos in die Knie gehen, da der GC dann ständig läuft.

Für Büroanwendungen vielleicht zu vernachlässigen, wenn sowas aber in mehreren Instanzen auf einem Server laufen muß, würde ich C++/Coder gar Delphi bevorzugen.

Es kommt letztendlich sowieso auf die Aufgabe und das Umfeld an, in der das Programm laufen soll. :)

Zitat von Navy

Ich bin auch durch andere Sprachen daran gewöhnt "sauber" zu arbeiten, also alles was ich nicht mehr brauche auch vernünftig wegzuräumen. .Net nimmt mir aber die Arbeit ab, ohne das ich jedoch weiß *wann* der Speicher wirklich wieder frei ist. In kleinen Projekten macht das rein gar nicht, in großen perfomanten aber sollte man deswegen kein .Net einsetzen. (Ähnliches gilt ja auch für Java).

Für Java gibt es, wenn man Zeitkritische Programme ausführen muss, sogenannte Realtime VM's. Diese setzt zB die Bundeswehr bei ihrer neuen Drohne ein.
Laut Hersteller der VM ist, mit deren JamicaVM eine Vorhersage über das Speicherverhalten möglich. Die Standart VM die dein PC mitbringt ist da etwas unberechenbarer.
Nur mal aus interresse gibt es für .net Sprachen auch soetwas?

Ich bin der Meinung das man mit .NET perfomante Programme schreiben kann,
solange man alle Möglichkeiten nutzt in dem man dem GarbageCollector durch die genannten Funktionen unter die Arme greift.

@RealTime VM:
Meinst jetzt Java RTS? Der Begriff ist mir geläufig nur hab ich damit keine Erfahrung.
Sicherlich kann uns der Tom was dazu sagen...

Zitat von Thomas Darimont

Hallo!

Zitat von AKST

@Thomas, ist Google Earth wirklich in .Net geschrieben? Wo steht das?

Okay, ziehe meine Behauptung zurück, hab mich da auf hören sagen verlassen Finde im moment auch keine Referenz die das eindeutig bestätigt.

Naja, knapp daneben ist auch vorbei. NASA World Wind ist in .NET implementiert.

Gruß

Dass ich hier nur ein bisschen Trollerei provozieren und den .Net-Guru Norbert etwas ägern wollte sollte wohl klar sein.

Zum Thema Java und .Net kann ich nur sagen, dass ich im Serverbereich nur Java nehmen würde wobei ich bei Windowsanwendungen dann doch eher darüber nachdenken würde ob ich es meinen potentiellen Kunden zumuten kann eine JRE zu installieren. Da ist dann .Net oder C++ evtl. doch die bessere Wahl, wenn man bei .Net von einem Windows-Rechner mit installiertem .Net ausgeht.

Zum Thema, "In .Net gibt es ja das und das", kann ich nur sagen, dass wir solche Dinge schon in diversen Open-Source-Frameworks haben. Mit der Apache-Foundation steht eine qualitativ sehr hochwertige Auswahl an Frameworks und Libs zur freien Verfügung. Ob jetzt dies oder jenes im Standard JRE dabei ist interessiert mich als Entwickler von Webanwendungen nicht die Bohne.

> Zum Thema Java und .Net kann ich nur sagen, dass ich im Serverbereich nur Java nehmen
> würde wobei ich bei Windowsanwendungen dann doch eher darüber nachdenken würde ob
> ich es meinen potentiellen Kunden zumuten kann eine JRE zu installieren. Da ist dann
>.Net oder C++ evtl. doch die bessere Wahl, wenn man bei .Net von einem
> Windows-Rechner mit installiertem .Net ausgeht.

Wenn der Kunde nur halbwegs clever ist, wird er sich nicht abhängig von einem BS machen lassen. Viele unserer Kunden haben in den letzten Jahren zumindest schon über eine Migration (zur hellen Seite -sprich unix(itär) ) nachgedacht. In Zeiten von KDE/Gnome, Java, Mozilla, OpenOffice und anderen Opensourcearbeitswerkzeugen ist das im Grunde auch vernünftig.

.net hat zwar vom programmiertechnischen einen wichtigen Schritt nach vorne gemacht, die unzureichende Umsetzung für andere Systeme und dem diesen zugrunde liegenden Portierungsproblem macht es für viele Bereich aber uninteressant.

Im Übrigen mußt Du für .net auch die Laufzeitumgebung runterladen und installieren.

In Vista wird es wohl aber schon wieder integriert sein, mal sehen ob Sun sich das gefallen läßt. (OT: Wenn ich ein verspieltes Fensterdesign mit echter Transparenz (auch ohne DX9) will, dann starte ich meinen XServer mit XGL/Compiz Oberfläche. Hach ist das schön)

So, ein paar Antworten auf Fragen:

Windows Vista und .NET
In Windows Vista wird .NET 3 integriert sein. Und das wird sich SUN wohl gefallen müssen, sind doch viele Microsoft-eigenen Entwicklungen in .NET gemacht.

Betriebssystem-Unabhängigkeit
Java-Jünger wollen einfach nicht verstehen, dass .NET ebenfalls betriebssystem-unabhängig ist. Wer dies vorsehen möchte, greift eben zu Mono und gut ist die Geschichte. Läuft auf jedem System, für welches es eine CLI Implementierung gibt. Und aus eigener Erfahrung: Anwendung unter Visual Studio 2005 entwickelt, durchkompiliert, auf ein Debian System gespielt und Überraschung: Es läuft :P

> In Windows Vista wird .NET 3 integriert sein. Und das wird sich SUN wohl gefallen
> müssen, sind doch viele Microsoft-eigenen Entwicklungen in .NET gemacht.

Genau wie sich Nestcape damals mit der Implementiertung des MSIE in Win98 abgefunden hat, ja?

> Java-Jünger wollen einfach nicht verstehen, dass .NET ebenfalls
> betriebssystem-unabhängig ist.

Nein, ganz und gar nicht. Per se ist es das nicht.

> Wer dies vorsehen möchte, greift eben zu Mono und gut
> ist die Geschichte. Läuft auf jedem System, für welches es eine CLI Implementierung
> gibt. Und aus eigener Erfahrung: Anwendung unter Visual Studio 2005 entwickelt,
> durchkompiliert, auf ein Debian System gespielt und Überraschung: Es läuft :P

Nur kommt Mono nicht von M$ sondern von Novell und beinhaltet auch nicht dessen kompletten Funktionsumfang, bzw weicht von den Vorgaben ab (was in diesem Fall hinreichende begründet ist). Unter dem Gesichtspunkt Crosscompatibilität schneidet Java deutlich besser ab als .net, was auch klar ist denn .net wurde auch nie wirklich dafür konzipiert, auch wenn M$ sein halbherziges Rotor versucht hat schmackhaft zu machen.

Zitat von Norbert Eder

Und aus eigener Erfahrung: Anwendung unter Visual Studio 2005 entwickelt, durchkompiliert, auf ein Debian System gespielt und Überraschung: Es läuft :P

Das gilt aber nicht für alle Bibliotheken.

Programme die die System.Windows.Forms Bibliothek benötigen wirst du zB unter Mono nicht zum laufen bringen

*gähn*

Also, die CLI ist freigegeben. Wer immer diese implementieren will, kann das auch tun. Novell hat das mit Mono eben gemacht. Und wie sieht es mit grafischer Oberfläche aus? Wird es sauber gemadcht, dann hab ich dahinter ein Framework, welches unabhängig funktioniert. Bei der GUI muss man sich dann für einen Weg entscheiden. Entweder auf das System zugeschnitten oder eine GUI die einmal für alle Systeme entworfen wird. Das geht, wenn man will.

Zu yan1: Danke für deine Wortmeldung. Mir ist schon klar, dass es keine Winapi32 unter Linux gibt.