Umstieg auf .NET/VB/C#

Fragen zu allen anderen Programmiersprachen.
Benutzeravatar
Danilo
-= Anfänger =-
Beiträge: 2284
Registriert: 29.08.2004 03:07

Re: Umstieg auf .NET/VB/C#

Beitrag von Danilo »

Delle hat geschrieben:Kann es sein, dass VB/C# wesentlich mehr Code (eher "Kot" *g*) verursacht? Trotz der ganzen fertigen Dinge?
Wie meinst Du das genau? Weil alles in Namespaces und Klassen ist? Vielleicht ein Beispiel was Du meinst?
cya,
...Danilo
"Ein Genie besteht zu 10% aus Inspiration und zu 90% aus Transpiration" - Max Planck
Benutzeravatar
Delle
Beiträge: 1130
Registriert: 10.05.2005 22:48

Re: Umstieg auf .NET/VB/C#

Beitrag von Delle »

Danilo hat geschrieben:
Delle hat geschrieben:Kann es sein, dass VB/C# wesentlich mehr Code (eher "Kot" *g*) verursacht? Trotz der ganzen fertigen Dinge?
Wie meinst Du das genau? Weil alles in Namespaces und Klassen ist? Vielleicht ein Beispiel was Du meinst?
z.B. das hier (gut ist kein VB sondern C):

Code: Alles auswählen

using System;
using System.Windows.Forms;
using System.Drawing;



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

   private Button info = new Button();
   private Button quit = new Button();


   // Entry Point, ruft Hauptprogramm auf
   public static int Main(string[] args) {
      Application.Run(new MainApp());
      return 0;
   }

   // Hauptprogramm
   public MainApp() {

      // Fenster initialisieren
      this.Text            = "C# Test Window";
      this.ClientSize      = new Size(230,40);
      this.StartPosition   = FormStartPosition.CenterScreen;
      this.FormBorderStyle = FormBorderStyle.FixedDialog;
      this.MaximizeBox     = false;
      this.MinimizeBox     = false;

      // Button "info" initialisieren
      info.Location        = new Point(10,10);
      info.Size            = new Size(100,20);
      info.Text            = "INFO!";
      info.Click          += new System.EventHandler(info_Click);

      // Button "quit" initialisieren
      quit.Location        = new Point(120,10);
      quit.Size            = new Size(100,20);
      quit.Text            = "Quit";
      quit.Click          += new System.EventHandler(quit_Click);

      // Buttons zum Fenster hinzufuegen
      this.Controls.Add(info);
      this.Controls.Add(quit);

   }


   // Event-Handler fuer Button "quit"
   private void quit_Click(object sender, EventArgs evArgs) {
      base.Dispose(); // exit
   }

   // Event-Handler fuer Button "info"
   private void info_Click(object sender, EventArgs evArgs) {
      MessageBox.Show("C# window example by Danilo",
                      "INFO",
                      MessageBoxButtons.OK,
                      MessageBoxIcon.Information);
   }



}
Das dürfte in PB sicherlich kürzer ausfallen...
PB 6.21 | Win 11
Benutzeravatar
Kiffi
Beiträge: 10714
Registriert: 08.09.2004 08:21
Wohnort: Amphibios 9

Re: Umstieg auf .NET/VB/C#

Beitrag von Kiffi »

wenn Du die Form mit dem Designer des Studios erstellst,
dann schrumpft der von Dir zu schreibende Code auf:

Code: Alles auswählen

MsgBox("VB.NET window example by Kiffi", MsgBoxStyle.OkOnly, "INFO")
;-)

Grüße ... Kiffi
a²+b²=mc²
Benutzeravatar
Delle
Beiträge: 1130
Registriert: 10.05.2005 22:48

Re: Umstieg auf .NET/VB/C#

Beitrag von Delle »

Kiffi hat geschrieben:wenn Du die Form mit dem Designer des Studios erstellst,
dann schrumpft der von Dir zu schreibende Code auf:

Code: Alles auswählen

MsgBox("VB.NET window example by Kiffi", MsgBoxStyle.OkOnly, "INFO")
;-)

Grüße ... Kiffi
Na gut das wäre in etwa das gleiche, wie wenn man den PB Formdesigner nimmt ;) Code generieren beide...

Das Eventhandling finde ich aber interessant...
PB 6.21 | Win 11
Benutzeravatar
Kiffi
Beiträge: 10714
Registriert: 08.09.2004 08:21
Wohnort: Amphibios 9

Re: Umstieg auf .NET/VB/C#

Beitrag von Kiffi »

Delle hat geschrieben:Na gut das wäre in etwa das gleiche, wie wenn man den PB Formdesigner nimmt ;) Code generieren beide...
jap, so ist es (wobei der Designer vom Studio doch ein Ticken besser ist ;-)).

Und generierten Code musst Du nicht mehr selber schreiben.

Grüße ... Kiffi
a²+b²=mc²
Benutzeravatar
TroaX
Beiträge: 684
Registriert: 08.03.2013 14:27
Computerausstattung: PC: Ryzen 9 3950X, 96 GB RAM, RX6800XT, 2.5 TB SSD, 21:9 Display, Linux Mint | Lappi: Ryzen 7 5800H, 16 GB RAM, 1 TB SSD, Linux Mint
Wohnort: NRW
Kontaktdaten:

Re: Umstieg auf .NET/VB/C#

Beitrag von TroaX »

Auch wenn der Thread schon ein paar Monate alt sind, gebe ich kurz meinen Senf dazu :-D

1. Die .NET Sprachen sind alle strikt objektorientiert. Die Sprachen bzw. die Compiler/Debugger lassen prozedurale (imperative/funktionale etc.) nicht zu. Anders als in PHP sind die Klassen des .NET objektorientiert designed und bieten keine statischen Objekte als Möglichkeit, Methoden funktional ohne Objektinstanz zu nutzen. Bei PHP zum Beispiel die MySQLi Klasse existiert einmal als strikte Klasse und einmal als statische Klasse. Alle Methoden der statischen Klasse sind direkt auf funktionale Weise nutzbar.

2. Die strikte Objektorientierung hat seine Vor- und Nachteile. Zum einen die Datenkapselung in den einzelnen Objekten. Zum anderen Methoden, die auf die Eigenschaften des Objektes zugeschnitten sind. Die Nachteile sind allerdings auch die Datenkapselung. Sie sorgt zwar für eine geringere Fehleranfälligkeit. Allerdings macht es zum Beispiel die Kommunikation zwischen 2 Fenstern fummeliger. Auch ein Nachteil ist, wenn man eine Funktion/Methode extrem häufig brauch, das man sich eine Helferklasse schreiben muss. Das allerdings wäre laut dem objektorientierten Paradigma nicht valide.

3. Sind prozedurale/imperative/funktionale Sprachen wie PB und PHP mit großen eigenen Bibliotheken besser für rapide Programmierung und Einzelgänger geeignet. Natürlich fehlt PB gerade in Zeiten des Web's noch in PB native Funktionen für HTTP/-S Requests oder das wechseln des WebGadgets in ein WebKit Gadget. Aber das bekommt man dann auch noch vernünftig selbst eingebaut ;-)
Objektorientierte Sprachen haben den bitteren Beigeschmack, das Klassen bis sie wirklich final sind gerade als Anfänger ewig brauchen. Beim .NET geht es noch, da 12.000 Klassen bereits fertig sind. Aber wie schon gesagt. Easy to lern, hard to Master. Die Sprachen lernen und verstehen geht schnell und einfach. Aber durch den großen Umfang ist es einfach extrem, damit perfekt um zu gehen. Deswegen bin ich ja auch bei PB hängen geblieben. Ich bin Hobbyprogrammierer. Ich habe keine Zeit, mich durch 12.000 Klassen zu fressen xD

4. .NET Sprachen werden in ByteCode compiliert und mit einem JIT in der Runtime nach und nach während der Ausführung in Maschinencode übersetzt und in einer Sandbox ausgeführt. Ich denke der Performanceunterschied dürfte im Vergleich zu PB schon spürbar sein ;-)
PC: Ryzen 9 3950X | 96 GB RAM | RX6800XT | 2,5 TB NVMe | Linux Mint
Notebook: 16" 3:2 | Ryzen 7 5800H | 16 GB RAM | Radeon Vega | 1TB NVMe | Linux Mint
NAS: Fritz.Box 5690 Pro (Nur für Keepass-DB)
Coding: Purebasic, Spiderbasic, GDevelop, Javascript/Node
Benutzeravatar
Delle
Beiträge: 1130
Registriert: 10.05.2005 22:48

Re: Umstieg auf .NET/VB/C#

Beitrag von Delle »

TroaX hat geschrieben:Auch wenn der Thread schon ein paar Monate alt sind, gebe ich kurz meinen Senf dazu :-D
War eher Ketchup als Senf! ;)
TroaX hat geschrieben:1. Die .NET Sprachen sind alle strikt objektorientiert. Die Sprachen bzw. die Compiler/Debugger lassen prozedurale (imperative/funktionale etc.) nicht zu.
Ernsthaft? Keinerlei Funktionen/Prozeduren???
TroaX hat geschrieben:3. Sind prozedurale/imperative/funktionale Sprachen wie PB und PHP mit großen eigenen Bibliotheken besser für rapide Programmierung und Einzelgänger geeignet.
Ja damit fahre ich persönlich auch besser, es gibt aber größere Kunden die auf z.B. ASP.NET bestehen und auch "viel" zahlen würden.
TroaX hat geschrieben:Objektorientierte Sprachen haben den bitteren Beigeschmack, das Klassen bis sie wirklich final sind gerade als Anfänger ewig brauchen. Beim .NET geht es noch, da 12.000 Klassen bereits fertig sind.
Ich hasse Klassen (auch in PHP), weswegen ich ASP-Quelltexte auch nichtmal ansatzweise verstehe.
PB 6.21 | Win 11
Benutzeravatar
TroaX
Beiträge: 684
Registriert: 08.03.2013 14:27
Computerausstattung: PC: Ryzen 9 3950X, 96 GB RAM, RX6800XT, 2.5 TB SSD, 21:9 Display, Linux Mint | Lappi: Ryzen 7 5800H, 16 GB RAM, 1 TB SSD, Linux Mint
Wohnort: NRW
Kontaktdaten:

Re: Umstieg auf .NET/VB/C#

Beitrag von TroaX »

Ernsthaft? Keinerlei Funktionen/Prozeduren???
Nein keine! Jede Funktion/Prozedur liegt als Methode in den Klassen vor. Selbst jeder Datentyp ist eine Klasse und jede Variable ein Oblekt. Die Prozedur Str() aus PB zumn Beispiel ist das gleiche wie in .NET INTEGERVARIABLENNAME.toString().

INTEGERVARIABLENNAME ist im Grunde ein Objekt der Klasse Integer, in der die Methode toString das gleiche wie in PB Str() macht.
PC: Ryzen 9 3950X | 96 GB RAM | RX6800XT | 2,5 TB NVMe | Linux Mint
Notebook: 16" 3:2 | Ryzen 7 5800H | 16 GB RAM | Radeon Vega | 1TB NVMe | Linux Mint
NAS: Fritz.Box 5690 Pro (Nur für Keepass-DB)
Coding: Purebasic, Spiderbasic, GDevelop, Javascript/Node
Benutzeravatar
Danilo
-= Anfänger =-
Beiträge: 2284
Registriert: 29.08.2004 03:07

Re: Umstieg auf .NET/VB/C#

Beitrag von Danilo »

TroaX hat geschrieben:1. Die .NET Sprachen sind alle strikt objektorientiert. [...] Anders als in PHP sind die Klassen des .NET objektorientiert designed und bieten keine statischen Objekte als Möglichkeit, Methoden funktional ohne Objektinstanz zu nutzen.
Statische Methoden brauchen keine Objektinstanz, und somit ist prozedurale Programmierung auch möglich.
Ganz simples Beispiel, wobei die Funktion "WriteLine" der Klasse Console statisch ist:

Code: Alles auswählen

using System;

class Program {
   static void Main() {
       Console.WriteLine("Hallo!");
   }
}
So kannst Du auch selbst programmieren und statische Methoden erstellen, die das Gleiche sind wie eine
Procedure in PureBasic:

Code: Alles auswählen

using System;

class Program {
   static void Main() {
       int x = mul(3,5);
       Console.WriteLine( sub(x, 12) );
       Console.WriteLine( sub(add(3,6), 12) );
   }
   
   static int add(int a, int b) {
       return a + b;
   }

   static int mul(int a, int b) {
       return a * b;
   }
   
   static int sub(int a, int b) {
       return a - b;
   }
}
Nicht einmal ein 'Declare' ist hier nötig, wie praktisch. ;)
TroaX hat geschrieben:Die Prozedur Str() aus PB zumn Beispiel ist das gleiche wie in .NET INTEGERVARIABLENNAME.toString().
ToString() gibt es für absolut JEDE Klasse, da diese Methode der Basisklasse 'Object' entstammt.
Somit kann man ToString() mit allen Klassen aufrufen und ist nicht wie bei PB auf ein paar einfache
Datentypen beschränkt. Das funktioniert auch mit float und double usw., also kein StrF() oder StrD() oder gar StrU() nötig.
Man nutzt immer ToString() - wie einfach!

Code: Alles auswählen

using System;

class Program {
   static void Main() {
       int x = 12;
       Console.WriteLine( x.ToString() );
       
       double d = 1.23456;
       Console.WriteLine( d.ToString() );

       address adr = new address() {
           name    = "John Boy",
           street  = "Karl-Marx-Allee 27",
           zip     = "12345",
           town    = "Potslin",
           country = "Germany"
       };
       
       Console.WriteLine( adr.ToString() );

       Console.WriteLine( new Window().ToString() );
   }
   
}

class address {
    public string name="";
    public string street="";
    public string zip="";
    public string town="";
    public string country="";
    
    public override string ToString() {
        return name + ", " + street + ", " + zip + " " + town + ", " + country;
    }
}

class Window {
}
Wenn eine Methode einen String erwartet oder entspr. überladen wurde,
wird die Methode ToString() automatisch aufgerufen:

Code: Alles auswählen

using System;

class Program {
   static void Main() {
       int x = 12;
       
       double d = 1.23456;

       address adr = new address() {
           name    = "John Boy",
           street  = "Karl-Marx-Allee 27",
           zip     = "12345",
           town    = "Potslin",
           country = "Germany"
       };
       
       //
       // Wenn eine Methode einen String erwartet oder entspr.
       // überladen wurde, wird .ToString() automatisch aufgerufen:
       //
       Console.WriteLine( x );
       Console.WriteLine( d );
       Console.WriteLine( adr );
       Console.WriteLine( new Window() );
   }
   
}

class address {
    public string name="";
    public string street="";
    public string zip="";
    public string town="";
    public string country="";
    
    public override string ToString() {
        return name + ", " + street + ", " + zip + " " + town + ", " + country;
    }
}

class Window {
}
TroaX hat geschrieben:4. .NET Sprachen werden in ByteCode compiliert und mit einem JIT in der Runtime nach und nach während der Ausführung in Maschinencode übersetzt und in einer Sandbox ausgeführt. Ich denke der Performanceunterschied dürfte im Vergleich zu PB schon spürbar sein ;-)
Natürlich kann der Unterschied spürbar sein. PB optimiert nicht viel, und ist deshalb -im Vergleich zu anderen Compilern- recht "langsam".
Ein JIT-Compiler dagegen kann für die aktuelle CPU optimieren, auf der das Programm gerade läuft, und somit ist das Ergebnis meist schneller
als PB-generierter Code, der auf 386er Prozessoren laufen soll und MMX, SSE(1,2,3,4) usw. nicht nutzt. Das ist ja der Sinn von Just-in-time Kompilierung.
Trotzdem läuft PB ja recht gut und wir können einigermassen zufrieden sein - für viele Anwendungen ist es vollkommen ausreichend, und
wer einen High-End Raytracer schreiben möchte, nimmt eben spezialisierte, hoch optimierende Compiler und eine geeignetere Sprache.



Die C# Beispiele kann sich jeder selbst kompilieren, wenn er das .NET Framework auf Windows installiert hat.
Der C# Compiler ist gleich kostenlos dabei. Test.cs in EXE kompilieren und ausführen (Den Pfad an installiertes Framework anpassen):

Code: Alles auswählen

c:\windows\microsoft.net\framework\v4.0.30319\csc /t:exe Test.cs
test.exe
Auf Mac OS X mit installiertem Mono:

Code: Alles auswählen

mcs test_01.cs -out:test_01
mono ./test_01
cya,
...Danilo
"Ein Genie besteht zu 10% aus Inspiration und zu 90% aus Transpiration" - Max Planck
Antworten