[C#] Fragen zu automatisch generiertem Code

[Luckie]

Also, ich habe mir gerade den C# Builder von Borland installiert. Bei einem leeren Projekt generiert die IDE folgendes:

Code:

using System;
using System.Drawing;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
using System.Data;

Klar, entspricht dem gewohntem uses nur dass eben die Namespaces bekannt gegeben werden, die benutzt werden sollen.

Dann:

Code:

   public class WinForm : System.Windows.Forms.Form
   {
      /// <summary>
      /// Required designer variable.
      /// </summary>
      private System.ComponentModel.Container components = null;
      private System.Windows.Forms.Button btnClose;
      private System.Windows.Forms.Button btnAbout;
      private System.Windows.Forms.Label lblBanner;

      public WinForm()
      {
         //
         // Required for Windows Form Designer support
         //
         InitializeComponent();

         //
         // TODO: Add any constructor code after InitializeComponent call
         //
      }

      /// <summary>
      /// Clean up any resources being used.
      /// </summary>
      protected override void Dispose (bool disposing)
      {
         if (disposing)
         {
            if (components != null)
            {
               components.Dispose();
            }
         }
         base.Dispose(disposing);
      }

Fdas ist die Klasse meines Formulares, entspricht TForm. So jetzt fängt es aber schon an. Diese public WinForm() { ... } ist ja eine Methode, was hat di in der Klasse-Definintion zu suchen. Ist das was C++ typisches?
Ebendso verhält es sich mit protected override void Dispose (bool disposing) { ... }. Aber hier stellt sich mir die Frage: Was macht diese Funktion? Wozu ist sie gut?
Dann kommt noch

Code:

#region Windows Form Designer generated code
...
...
...
#endregion

Das ist auch klar, das sind die abweichenden Einstellungen von den standard Einstellungen die man im OI eingestellt hat.

So, wenn mir da doch bitte jemand meine Fragen beantworten könnte und eventuell falsches richtig stellt oder unvollständiges ergänzt, wäre ich dankbar dafür.

[edit=fkerber]Neu gespeichert wg. Code-Highlighting. Mfg, fkerber[/edit]

[CalganX]

Hi,
in C# befinden sich alle Methoden innerhalb der Klassendefinition. Das hat die Sprache so an sich. ;) Und die Methode WinForm ist ein Konstruktor - wie bei C++.
Dispose ist da wohl der Destruktor wenn ich die bisherigen Versuche mit C# richtig deute. ;)

Chris

[Luckie]

Zitat:

Zitat von Chakotay1308

in C# befinden sich alle Methoden innerhalb der Klassendefinition. Das hat die Sprache so an sich.

Das ist aber ein "Kann" kein "Muss", denke ich. Nennt sich dann, glaube ich, [b]inline-Irgendwas oder so.

Zitat:

Dispose ist da wohl der Destruktor wenn ich die bisherigen Versuche mit C# richtig deute. ;)

Also der Destructor[i] für die Klasse? Sieht aber reichlich kompliziert aus. :gruebel:

[Chewie]

Zitat:

Zitat von Luckie

Zitat:

Zitat von Chakotay1308

in C# befinden sich alle Methoden innerhalb der Klassendefinition. Das hat die Sprache so an sich.

Das ist aber ein "Kann" kein "Muss", denke ich. Nennt sich dann, glaube ich, [b]inline-Irgendwas[i] oder so.

Wie sollte es denn sonst aussehen?

[Luckie]

Na so, wie man es eben kennt:

Code:

class Temperatur {
  public int Foo(void)
}

int Temperatur::Foo(void) {
  TuWas;
}

[Chewie]

Ah, wusste nicht, dass das auch geht. OK, meine C#-Kenntnisse sind auch nicht gerade erwähnenswert...

[S - tefano]

Also laut meinem Schulwissen stimmt das mit dem Konstruktor. In den meisten C-verwandten Sprachen handelt es sich bei einer Methode die genauso heißt wie die Klasse der sie angehört tatsächlich um den Konstruktor.
Naja, und dass es bei ner WinForm etwas komplizierter aussieht scheint ja ein bisl logisch. Ist bei einem Win32API-Code für ein Formular -aus meiner Sicht- ja genau das gleiche ;-)

Bis dann,

S - tefano

[Phoenix]

Also es ist definitiv der Constructor :)

Und in C# ist es eigentlich gang und gebe, die Methoden direkt in der Klasse zu implementieren. Eine Klassendefinition vorher zu machen erscheint den meisten die aus dem C-Lager kommen zu viel Tipparbeit zu sein.
C# ist nunmal keine Sprache, die man hinterher sauber lesen kann.

[Generalissimo]

Zitat:

Zitat von Luckie

Na so, wie man es eben kennt:

Code:

class Temperatur {
  public int Foo(void)
}

int Temperatur::Foo(void) {
  TuWas;
}

Eben das geht nicht! Du kannst innerhalb eines Namespaces keine Methoden oder Felder haben.

Zudem ne Frage. Was soll public int Foo(void) für ne Konstruktion sein?

Soll das bedeuten das Foo keine Parameter übergeben werden? Wenn ja dann wird das ohne das Void geschrieben.

[Luckie]

Zitat:

Zitat von Generalissimo

Eben das geht nicht! Du kannst innerhalb eines Namespaces keine Methoden oder Felder haben.

Das ist ja blöd. Aber es stimmt nicht fällt mir da gerade ein:

Code:

namespace Project1
{
   const String APPNAME = "Hello";
   const String VER = "1.0";
   const String INFO_TEXT = APPNAME + " " + VER+"\nCopyright (c) 2004 Michael Puff\n\nhttp://www.luckie-online.de";

      /// <summary>
      /// The main entry point for the application.
      /// </summary>
      [STAThread]
      static void Main() 
      {
         Application.Run(new WinForm());
      }
      
      private void btnClose_Click(object sender, System.EventArgs e)
      {
         Application.Exit();
      }
      
      private void WinForm_Load(object sender, System.EventArgs e)
      {
        this.Text = APPNAME;
          lblBanner.Text = APPNAME;
      }
      
      private void btnAbout_Click(object sender, System.EventArgs e)
      {
         MessageBox.Show(INFO_TEXT, APPNAME, MessageBoxButtons.OK, MessageBoxIcon.Information);
      }
   }
}

Hier liegen eindeutig Methoden von WinForm in einem namespace, nämlich dem von Project1.

Zitat:

Zudem ne Frage. Was soll public int Foo(void) für ne Konstruktion sein?

Soll das bedeuten das Foo keine Parameter übergeben werden? Wenn ja dann wird das ohne das Void geschrieben.

In meinem C++ Buch steht es so drinne und so habe ich schon gerbeitet. Geht wunderbar, keine Warnung, nichts.

[edit=fkerber]Neu gespeichert wg. Code-Highlighting. Mfg, fkerber[/edit]

[Generalissimo]

Zitat:

Zitat von Luckie

Das ist ja blöd. Aber es stimmt nicht fällt mir da gerade ein:

Code:

namespace Project1
{
   const String APPNAME = "Hello";
   const String VER = "1.0";
   const String INFO_TEXT = APPNAME + " " + VER+"\nCopyright (c) 2004 Michael Puff\n\nhttp://www.luckie-online.de";

      /// <summary>
      /// The main entry point for the application.
      /// </summary>
      [STAThread]
      static void Main() 
      {
         Application.Run(new WinForm());
      }
      
      private void btnClose_Click(object sender, System.EventArgs e)
      {
         Application.Exit();
      }
      
      private void WinForm_Load(object sender, System.EventArgs e)
      {
        this.Text = APPNAME;
          lblBanner.Text = APPNAME;
      }
      
      private void btnAbout_Click(object sender, System.EventArgs e)
      {
         MessageBox.Show(INFO_TEXT, APPNAME, MessageBoxButtons.OK, MessageBoxIcon.Information);
      }
   }
}

Hier liegen eindeutig Methoden von WinForm in einem namespace, nämlich dem von Project1.

Also da musst du sowas irgendwie ausversehen gelöscht haben:

Code:

public class Form1 : System.Windows.Forms.Form
   {

Zitat:

Zudem ne Frage. Was soll public int Foo(void) für ne Konstruktion sein?

Soll das bedeuten das Foo keine Parameter übergeben werden? Wenn ja dann wird das ohne das Void geschrieben.
In meinem C++ Buch steht es so drinne und so habe ich schon gerbeitet. Geht wunderbar, keine Warnung, nichts.

Bei mir macht VS2003 ne Meldung

[OregonGhost]

Zitat:

Dispose ist da wohl der Destruktor wenn ich die bisherigen Versuche mit C# richtig deute.

Es gibt in C# keine Destruktoren. Wenn überhaupt, gibt es nur Finalizer, die mit derselben Syntax geschrieben werden wie in C++ Destruktoren (also ~Classname()).
Dispose ist generell die einzige Methode der IDisposable-Schnittstelle. Sie dient dazu, dem Benutzer die Möglichkeit der deterministischen Zerstörung von Objekten zu geben, die .net ansonsten nicht anbietet. Sie wird meist verwendet, um nicht gemanagete Ressourcen freizugeben. Im .net SDK zu finden unter "Cleaning Up Unmanaged Resources".
In diesem besonderen Fall handelt es sich aber um eine Methode, die bereits in Component definiert wird. Wie im Code zu sehen, ruft sie auch die Dispose-Methoden aller Unterkomponenten auf. Mehr dazu unter Component.Dispose im .net SDK.

Zitat:

Das ist aber ein "Kann" kein "Muss", denke ich. Nennt sich dann, glaube ich, [b]inline-Irgendwas oder so.

Das ist in C++ so. Nicht in C#.

Zitat:

C# ist nunmal keine Sprache, die man hinterher sauber lesen kann.

Dafür gibt es zum einen die Regions und das Folding und zum anderen den Object Browser.

Zitat:

Soll das bedeuten das Foo keine Parameter übergeben werden? Wenn ja dann wird das ohne das Void geschrieben.

In C ist es erforderlich, für eine Funktion ohne Parameter explizit void in die Klammern zu schreiben. Diese Schreibweise ist in C++ nicht nötig, aber möglich. In C# ist sie nicht möglich.

Noch etwas generelles: In C# gibt es nichts "under the hood", also Code, der automatisch vom Compiler erzeugt wird wie in Delphi. Der gesamte Verwaltungscode ist mit drin. Deshalb wurden für C# 2.0 auch partial classes eingeführt, die man also innerhalb mehrerer Dateien definieren kann. Die Designer legen hierzu eine eigene Datei für den gesamten generierten Code an.

[Nachtrag]

Zitat:

Code:

   const String APPNAME = "Hello"; 
   const String VER = "1.0"; 
   const String INFO_TEXT = APPNAME + " " + VER+"\nCopyright (c) 2004 Michael Puff\n\nhttp://www.luckie-online.de";

Übrigens entspricht es in .net nicht der Norm, Konstantennamen (oder andere Bezeichner) groß zu schreiben. Siehe hierzu "Design Guidelines for Class Library Developers" im .net SDK (zu finden unter "Documentation Map by Technology").

[Luckie]

Zitat:

Zitat von Generalissimo

Zitat:

Zitat von Luckie

Das ist ja blöd. Aber es stimmt nicht fällt mir da gerade ein:

Code:

namespace Project1
{
   const String APPNAME = "Hello";
   const String VER = "1.0";
   const String INFO_TEXT = APPNAME + " " + VER+"\nCopyright (c) 2004 Michael Puff\n\nhttp://www.luckie-online.de";

      /// <summary>
      /// The main entry point for the application.
      /// </summary>
      [STAThread]
      static void Main() 
      {
         Application.Run(new WinForm());
      }
      
      private void btnClose_Click(object sender, System.EventArgs e)
      {
         Application.Exit();
      }
      
      private void WinForm_Load(object sender, System.EventArgs e)
      {
        this.Text = APPNAME;
          lblBanner.Text = APPNAME;
      }
      
      private void btnAbout_Click(object sender, System.EventArgs e)
      {
         MessageBox.Show(INFO_TEXT, APPNAME, MessageBoxButtons.OK, MessageBoxIcon.Information);
      }
   }
}

Hier liegen eindeutig Methoden von WinForm in einem namespace, nämlich dem von Project1.

Also da musst du sowas irgendwie ausversehen gelöscht haben:

Versehentlich nicht. Aber kuck dir doch mal die Klammern des Namespace Project1 an. Innerhalb des Namespces liegen eindeutig die Methoden von WinForm. Womit deine Aussage nicht stimmt.

[edit=fkerber]Neu gespeichert wg. Code-Highlighting. Mfg, fkerber[/edit]

[OregonGhost]

Code:

namespace Project1 
{ 
   const String APPNAME = "Hello"; 
   const String VER = "1.0"; 
   const String INFO_TEXT = APPNAME + " " + VER+"\nCopyright (c) 2004 Michael Puff\n\nhttp://www.luckie-online.de"; 
    
      ...
     
      private void btnAbout_Click(object sender, System.EventArgs e) 
      { 
         MessageBox.Show(INFO_TEXT, APPNAME, MessageBoxButtons.OK, MessageBoxIcon.Information); 
      } 
   } 
}

Da fehlt ja wohl 'ne Klammer auf. Ich garantiere dir, dass dieser Code nicht kompiliert. Namespaces können keine Funktionen beinhalten.

Nachtrag:
Noch ein Tipp - der C# Builder bringt doch ein kurzer C#-Tutorial mit. Darin wird eigentlich alles geklärt ;c)

[Luckie]

OK, hier der gesamte Code:

Code:

namespace Project1
{
   /// <summary>
   /// Summary description for WinForm.
   /// </summary>
   public class WinForm : System.Windows.Forms.Form
   {
      /// <summary>
      /// Required designer variable.
      /// </summary>
      private System.ComponentModel.Container components = null;
      private System.Windows.Forms.Button btnClose;
      private System.Windows.Forms.Button btnAbout;
      private System.Windows.Forms.Label lblBanner;

      public WinForm()
      {
         //
         // Required for Windows Form Designer support
         //
         InitializeComponent();
         //
         // TODO: Add any constructor code after InitializeComponent call
         //
      }

      /// <summary>
      /// Clean up any resources being used.
      /// </summary>
      protected override void Dispose (bool disposing)
      {
         if (disposing)
         {
            if (components != null)
            {
               components.Dispose();
            }
         }
         base.Dispose(disposing);
      }

      #region Windows Form Designer generated code
      /// <summary>
      /// Required method for Designer support - do not modify
      /// the contents of this method with the code editor.
      /// </summary>
      private void InitializeComponent()
      {
         this.btnClose = new System.Windows.Forms.Button();
         this.lblBanner = new System.Windows.Forms.Label();
         this.btnAbout = new System.Windows.Forms.Button();
         this.SuspendLayout();
         // 
         // btnClose
         // 
         this.btnClose.Location = new System.Drawing.Point(208, 144);
         this.btnClose.Name = "btnClose";
         this.btnClose.TabIndex = 0;
         this.btnClose.Text = "&Schließen";
         this.btnClose.Click += new System.EventHandler(this.btnClose_Click);
         // 
         // lblBanner
         // 
         this.lblBanner.BackColor = System.Drawing.Color.White;
         this.lblBanner.Font = new System.Drawing.Font("Microsoft Sans Serif", 14.25F, System.Drawing.FontStyle.Bold, System.Drawing.GraphicsUnit.Point, ((byte)(0)));
         this.lblBanner.Location = new System.Drawing.Point(0, 0);
         this.lblBanner.Name = "lblBanner";
         this.lblBanner.Size = new System.Drawing.Size(296, 72);
         this.lblBanner.TabIndex = 2;
         this.lblBanner.Text = "lblBanner";
         this.lblBanner.TextAlign = System.Drawing.ContentAlignment.MiddleCenter;
         // 
         // btnAbout
         // 
         this.btnAbout.Location = new System.Drawing.Point(232, 8);
         this.btnAbout.Name = "btnAbout";
         this.btnAbout.Size = new System.Drawing.Size(48, 23);
         this.btnAbout.TabIndex = 3;
         this.btnAbout.Text = "&Info";
         this.btnAbout.Click += new System.EventHandler(this.btnAbout_Click);
         // 
         // WinForm
         // 
         this.AutoScaleBaseSize = new System.Drawing.Size(5, 13);
         this.ClientSize = new System.Drawing.Size(292, 175);
         this.Controls.Add(this.btnAbout);
         this.Controls.Add(this.lblBanner);
         this.Controls.Add(this.btnClose);
         this.FormBorderStyle = System.Windows.Forms.FormBorderStyle.FixedDialog;
         this.MaximizeBox = false;
         this.Name = "WinForm";
         this.StartPosition = System.Windows.Forms.FormStartPosition.CenterScreen;
         this.Text = "Foo";
         this.Load += new System.EventHandler(this.WinForm_Load);
         this.ResumeLayout(false);
      }
      #endregion


   const String APPNAME = "Hello";
   const String VER = "1.0";
   const String INFO_TEXT = APPNAME + " " + VER+"\nCopyright (c) 2004 Michael Puff\n\nhttp://www.luckie-online.de";

      /// <summary>
      /// The main entry point for the application.
      /// </summary>
      [STAThread]
      static void Main() 
      {
         Application.Run(new WinForm());
      }
      
      private void btnClose_Click(object sender, System.EventArgs e)
      {
         Application.Exit();
      }
      
      private void WinForm_Load(object sender, System.EventArgs e)
      {
        this.Text = APPNAME;
          lblBanner.Text = APPNAME;
      }
      
      private void btnAbout_Click(object sender, System.EventArgs e)
      {
         MessageBox.Show(INFO_TEXT, APPNAME, MessageBoxButtons.OK, MessageBoxIcon.Information);
      }
   }
}

Wie man sieht gehört die letzte schließende Klammer zu ersten öffnenden Klammer. Und somit liegen die Methoden von WinForm eindeutig im Namespace von Project1.

[edit=fkerber]Neu gespeichert wg. Code-Highlighting. Mfg, fkerber[/edit]

[Chewie]

Da liegt alles im Namespace Project1. Aber viel wichtiger ist, dass alles innerhalb der Klassendeklaration passiert.

[OregonGhost]

Ich sag's mal so:
Natürlich ist alles im Namespace. In .net kann nichts außerhalb des Namespace existieren.
Aber DIREKT im Namespace können nur Typen definiert werden (class, enum, struct). Nur strukturierte Typen können auch Methoden enthalten. Das gilt für ALLE, selbst für aus Windows-DLLs importierte Funktionen. Es gibt keine Funktionen in .net, nur Methoden. Objektorientiert halt.

[Generalissimo]

@Luckie: Wieso denn? Nur die Klasse Winform liegt innerhalb des Namespaces. Die Methoden liegen alle innerhalb der Klasse

Code:

namespace Project1
{
   /// <summary>
   /// Summary description for WinForm.
   /// </summary>
   public class WinForm : System.Windows.Forms.Form
   {
      /// <summary>
      /// Required designer variable.
      /// </summary>
      private System.ComponentModel.Container components = null;
      private System.Windows.Forms.Button btnClose;
      private System.Windows.Forms.Button btnAbout;
      private System.Windows.Forms.Label lblBanner; 

      private void btnAbout_Click(object sender, System.EventArgs e)
      {
         MessageBox.Show(INFO_TEXT, APPNAME, MessageBoxButtons.OK, MessageBoxIcon.Information);
      }
   }
}

[OregonGhost]

Der Punkt ist, die Methoden befinden sich in der Klasse, die sich wiederum im Namespace befindet. Somit befindet sich INDIREKT die Methode auch im Namespace. DIREKT im Namespace liegt hingegen nur die Klasse.

Nachtrag: Ich sehe jetzt erst das "@Luckie", sorry ;c)

[Luckie]

@OG: Ja so wird ein Schuh draus, also mit dem DIREKT und INDIREKT. ;)

[sharkx]

Zitat:

Zitat von Luckie

Das ist aber ein "Kann" kein "Muss", denke ich. Nennt sich dann, glaube ich, [b]inline-Irgendwas[i] oder so.

Absolut Falsch ! Du befindest dich mit Csharp in absoluter OOP, hier befindet sich alles in einer Klasse!

Zitat:

Zitat von Luckie

const String INFO_TEXT = APPNAME + " " + VER+"\nCopyright (c) 2004 Michael Puff\n\nhttp://www.luckie-online.de";

Man fügt keine Strings mit dem + zeichen zusammen, denn es wird dann eine neue Instanz mit diesem String pro + erzuegt, was somit langsam und speicherlastig ist. Der Garbace Collector wird zwar diesen Speicher wieder freigeben, jedoch liegt er zeitweise unnötig auf dem Heap herum.

Zitat:

Zitat von OregonGhost

Es gibt in C# keine Destruktoren. Wenn überhaupt, gibt es nur Finalizer, die mit derselben Syntax geschrieben werden wie in C++ Destruktoren

Falsch! Es gibt in c# Destrukor, das liest man in jedem Anfänger Tutorial im ersten kapitel ;)

Gruß
Torsten

[Generalissimo]

Zitat:

Zitat von sharkx

Man fügt keine Strings mit dem + zeichen zusammen, denn es wird dann eine neue Instanz mit diesem String pro + erzuegt, was somit langsam und speicherlastig ist. Der Garbace Collector wird zwar diesen Speicher wieder freigeben, jedoch liegt er zeitweise unnötig auf dem Heap herum.

Wenn schon so ne Aussage, dann gib doch auch gleich den Lösungsweg an!
Also man kann es so machen (Strings mit + verbinden) jedoch passiert dann das, was sharkx gesagt hat.
Man sollte die StringBuilder-Klasse dazu verwenden

Zitat:

Zitat von sharkx

Zitat:

Zitat von OregonGhost

Es gibt in C# keine Destruktoren. Wenn überhaupt, gibt es nur Finalizer, die mit derselben Syntax geschrieben werden wie in C++ Destruktoren

Falsch! Es gibt in c# Destrukor, das liest man in jedem Anfänger Tutorial im ersten kapitel ;)

Gruß
Torsten

Stimmt. Nur soll man ihn nicht wirklich bzw. nur in speziellen Fällen einsetzen. Sprich in Situationen wo man genau wissen muss, wann ein Objekt freigegeben wird. Ohne Destruktor macht das der Garbage Collector selbst, jedoch ist dabei der Zeitpunkt der Freigabe unbekannt.

[sharkx]

Hallo !

Entschuldige Generalissimo, mir wird diesere Fehler nicht mehr unterlaufen ;)

Code:

 StringBuilder sb = new StringBuilder();
sb.Append("Dein Text");

Gruß Torsten

[OregonGhost]

Nur um das nochmal klarzustellen:
Es gibt in C# keine Destruktoren wie in z.B. C++ oder Delphi. Destruktoren werden für die deterministische Zerstörung von Objekten eingesetzt und sind in .net sowie in C# so NICHT vorhanden.
Das, was man in C# als Destruktoren bezeichnet und was auch aussieht wie ein C++-Destruktor, ist in Wirklichkeit ein Finalizer! Es hat dieselbe Semantik wie die Finalizer der anderen .net Sprachen. Hierbei sollen die Objekte auch zerstört werden, aber der Vorgang ist nicht deterministisch!
Genauer ist ein so genannter Destruktor in C# also nur eine bequeme Methode, die Object.Finalize()-Methode zu überschreiben und dabei implizit (was man sonst von Hand machen müsste) base.Finalize() aufzurufen.
Managed C++ hingegen unterstützt zusätzlich einen deterministischen Destruktor, der aber vom Compiler erzeugt wird und keine CLR-Unterstützung genießt.

Zitat:

Zitat von Microsoft

Hinweis Trotz der scheinbaren Ähnlichkeit haben die Destruktoren in C# und den verwalteten Erweiterungen nicht die gleiche Semantik wie Destruktoren in nicht verwaltetem C++. Verwalteter Code unterstützt keine Semantik für Destruktoren, die der von C++ gleicht.

Es gibt also in C# Destruktoren, aber diese sollten nicht mit Destruktoren aus nicht gemanageten Sprachen verglichen werden. Dispose (wie weiter oben geraten) ist zudem weder Finalizer noch Destruktor.

Zitat:

Zitat von Generalissimo

Stimmt. Nur soll man ihn nicht wirklich bzw. nur in speziellen Fällen einsetzen. Sprich in Situationen wo man genau wissen muss, wann ein Objekt freigegeben wird. Ohne Destruktor macht das der Garbage Collector selbst, jedoch ist dabei der Zeitpunkt der Freigabe unbekannt.

Falsch! In C# gibt es keine deterministische Zerstörung von Objekten. Der Garbage Collector macht es IMMER selbst. Er ruft auch den Finalizer auf, falls die Klasse ihn überschrieben (sprich einen so genannten Destruktor definiert) hat! Man kann den Garbage Collector mit ein paar Tricks beeinflussen oder Objekte am Leben erhalten, aber man kann nicht die Zerstörung von Objekten selbst einleiten. Man kann maximal Ressourcen freigeben, indem man die Dispose-Methode, falls die Klasse IDisposable implementiert, aufruft. Das Objekt wird hierbei nicht zerstört.

Ein wesentlicher Unterschied ist: Bei einem herkömmlichen Destruktor sind alle Referenzen in der Klasse noch gültig, denn Kindobjekte werden erst später freigegeben. Bei einem Finalizer sind die Kindobjekte aber möglicherweise schon zerstört worden, soweit sie gemanaged sind.
Darüberhinaus ist es anders als z.B. in C++, wo jede Klasse einen Destruktor hat (gegebenenfalls vom Compiler generiert), in .net eine aufwändige Sache, einen Finalizer auszuführen und somit generell zu vermeiden.




Edit:

Zitat:

Man fügt keine Strings mit dem + zeichen zusammen, denn es wird dann eine neue Instanz mit diesem String pro + erzuegt, was somit langsam und speicherlastig ist. Der Garbace Collector wird zwar diesen Speicher wieder freigeben, jedoch liegt er zeitweise unnötig auf dem Heap herum.

Das stimmt generell, aber Luckie hat das mit const-Strings gemacht. Ein Blick in ildasm zeigt, dass die Objekte wirklich const sind, es wird also nicht pro + eine Instanz erzeugt, sondern nur pro Konstante - also genau das, was man will. Darüberhinaus ist der Garbage Collector gerade für kurzlebige, also z.B. temporäre Objekte optimiert.

[sharkx]

Nochmals zum Thema Destruktor:
Microsoft empfiehlt in seinen Dokumenten, eine entsprechende Methode (z.b. mit dem Namen Dispose()) zu erstellen, welche die aufräumarbeiten unabhängig vom Destruktor bei Bedarf durchführt.

Einen Destruktor in C# erstellt man, in dem man eine Methode mit dem Namen der Klasse, aber einem vorangstellten ~ erzeugt. Aufgrund der Automatischen Speicherverwaltung ist aber nicht sicher, wann der Destruktor aufgerufen wird, da der Speichermanager der .NET-Umgebung dies Eigenständig entscheidet.


Gruß
Torsten