✔ Delphi vs. C#

[Twinsetter]

Ja ich habs jetzt auch mitbekommen, daß diese Komponente nur 1.0 bzw. 1.1 braucht. Die Screenshots waren ja vielversprechend, aber die Handhabung ist einfach nur crottig. Habe jetzt bestimmt 2 Stunden rumprobiert eine leere Tabelle mit 4Zeilen und 6 Spalten zu machen. Es ist mir nicht wirklich gelungen. Zum Schluß war zwar was auf dem Form, daß wie eine Tabelle aussieht, aber es war nicht wirklich brauchbar. Vielleicht stelle ich mich auch nur einfach zu blöd an und denke in falsche Richtung.
Hab jetzt mal probeweise eine freie # IDE eingesetzt, aber da geht es auch nicht besser. Hätt ich mir eigentlich auch denken können, denn die setzt ja letztendlich auch auf .Net auf und wo nichts ist kann die natürlich auch nichts machen.
Jetzt hab ich erstmal keine Lust mehr auf .Net - zumindest heute nicht.

Danke erst mal für Deine Mühe, Du hast mir schon weiter geholfen.

Gruß Twinsetter

 

[Twinsetter]

Kleiner später Nachtrag

Habe jetzt zwischenzeitlich 2 C# Kurse besucht. War alles recht interessant und der Referent hat sein Handwerk auch sehr gut verstanden und alles recht anschaulich erklärt. In C# sind auch einige Features enthalten die ich schon gut finde und wo einige Sachen einfacher als z.B. in Pascal gelöst werden, aber dennoch ist mein Fazit irgendwie ernüchternd:
- C# ist und bleibt C mit allen seinen Nachteilen, auch wenn man das Mäntelchen von OO drüber gehängt hat und einen Garbagecollector gebaut hat der ordentlich zu funktionieren scheint und dem Programmierer viel Arbeit abnimmt
- C# verleitet immer noch zum wilden und unstruktiertem Programmieren. Da werden plötzlich Variablen in Funktionsaufrufen declariert die sonst nirgends vorkommen , aber man braucht sie weil sonst Schrott raus kommt
- das case und while Konstrukt ist nach wie vor crottig. Was soll das bekloppte break in der case Schleife. case heißt eigentlich im Falle von und das interpretiere ich so, wenn eine Bedingung erfüllt ist dann wird diese und keine weitere ausgeführt (obwohl es Aufgaben gibt, wo die Interpretation der case Schleife von C schon Sinn macht - die sind aber - zumindest bei mir- eher selten)
- Mengen kennt C# immer noch nicht. Warum eigentlich ist nämlich eine tolle Sache
- Ich habe bei meinem Programm eine Pluginschnittstelle vorgesehen. Die Plugins (DLL's) können in einer beliebigen Programmiersprache geschrieben sein. Mit C# ist das nur bedingt möglich, da DLL's die in einer anderen Sprache wurden in der i.d.R. als unmanaged Code eingebunden werden müssen und bei unmanaged kann ich derzeit den DLL-Namen nicht ändern. Bei Plugins ein Unding. D.h. ich müßte eine Wrapper DLL in C# (managed Code) dazwischen schalten, die dann die eigentliche DLL (unmanaged) aufruft.
- eine vernünftige Gridkomponente gibt es tatsächlich nicht (Aussage des Instruktors) Hier muß man sich aus der Listenkomponente selbst was zusammenbauen.
- C# Programme sind deutlich langsamer als Programme in C/C++ oder Pascal. Kann ja auch nicht anders sein, da sie ja erst zur Laufzeit kompiliert werden. Vorteil ist natürlich das es hierdurch detailierte Fehlermeldungen gibt (mit Angabe der Zeilennummer)

Also, ich bin nicht so sehr begeistert. Persönlich würde ich dann doch eher zu Java neigen.

 

[sheel]

Ohne dich umstimmen zu wollen, aber nicht wenig davon ist in Java auch der Fall

 

[ComFreek]

- C# verleitet immer noch zum wilden und unstruktiertem Programmieren. Da werden plötzlich Variablen in Funktionsaufrufen declariert die sonst nirgends vorkommen , aber man braucht sie weil sonst Schrott raus kommt

Hast du ein Beispiel? Man kann mit jeder Programmiersprache schlechten Code erzeugen! Einige tendieren da mehr zu, andere nicht. Aber im Endeffekt liegt es beim Programmierer.

- das case und while Konstrukt ist nach wie vor crottig. Was soll das bekloppte break in der case Schleife. case heißt eigentlich im Falle von und das interpretiere ich so, wenn eine Bedingung erfüllt ist dann wird diese und keine weitere ausgeführt (obwohl es Aufgaben gibt, wo die Interpretation der case Schleife von C schon Sinn macht - die sind aber - zumindest bei mir- eher selten)

Überbleibsel. Find ich auch gut so, wenn man als C o. C++-Programmierer zu C# wechselt.

- C# Programme sind deutlich langsamer als Programme in C/C++ oder Pascal. Kann ja auch nicht anders sein, da sie ja erst zur Laufzeit kompiliert werden. Vorteil ist natürlich das es hierdurch detailierte Fehlermeldungen gibt (mit Angabe der Zeilennummer)

Natürlich sind sie minimal langsamer, genau das gleiche Spiel mit Java. Dein angeblicher Vorteil existiert sehr wohl auch, wenn man in oder C++ programmiert. C++ + IDE + Debugger ermöglichen dir auch sehr präzise Angaben über Call Stack, etc.

 

[Cromon]

Hallo Twinsetter

Ich möchte dir kurz meine Gedanken zu den einzelnen Punkten mitteilen, nicht als Korrektur, sondern eher als Zweitmeinung.

- C# ist und bleibt C mit allen seinen Nachteilen, auch wenn man das Mäntelchen von OO drüber gehängt hat und einen Garbagecollector gebaut hat der ordentlich zu funktionieren scheint und dem Programmierer viel Arbeit abnimmt

C# ist nicht mehr wirklich C, ausser von global betrachteten Syntax her. Der grosse Vorteil von .NET allgemein (und auch Java) ist der schier unerschöpfliche Fundus an bereits implementierten (und getesteten) Komponenten und Utilities.

- C# verleitet immer noch zum wilden und unstruktiertem Programmieren. Da werden plötzlich Variablen in Funktionsaufrufen declariert die sonst nirgends vorkommen , aber man braucht sie weil sonst Schrott raus kommt

Ich würde eher sagen: Es ermöglicht es, aber es verleitet nicht dazu. Und den zweiten Teil verstehe ich nicht ganz, bzw kann ich so nicht bestätigen.

- das case und while Konstrukt ist nach wie vor crottig. Was soll das bekloppte break in der case Schleife. case heißt eigentlich im Falle von und das interpretiere ich so, wenn eine Bedingung erfüllt ist dann wird diese und keine weitere ausgeführt (obwohl es Aufgaben gibt, wo die Interpretation der case Schleife von C schon Sinn macht - die sind aber - zumindest bei mir- eher selten)

Dem kann ich für case nur beipflichten. Vor allem da ja der Grundgedanke aus C, dass man durch verschiedene case-Labels implizit durchspringen kann in C# gar nicht möglich ist, du musst ein anderes Label explizit aufrufen, daher hat das break da eigentlich gar keine Daseinsberechtigung. Man hat dies vermutlich eingeführt weil man die Leute von C++ nach C# bringen will aber verhindern will, dass sie einen Kulturschock erleiden

- Mengen kennt C# immer noch nicht. Warum eigentlich ist nämlich eine tolle Sache

Der Support für Mengen ist in der Tat noch nicht wirklich berauschend, es gibt jedoch HashSet.

- Ich habe bei meinem Programm eine Pluginschnittstelle vorgesehen. Die Plugins (DLL's) können in einer beliebigen Programmiersprache geschrieben sein. Mit C# ist das nur bedingt möglich, da DLL's die in einer anderen Sprache wurden in der i.d.R. als unmanaged Code eingebunden werden müssen und bei unmanaged kann ich derzeit den DLL-Namen nicht ändern. Bei Plugins ein Unding. D.h. ich müßte eine Wrapper DLL in C# (managed Code) dazwischen schalten, die dann die eigentliche DLL (unmanaged) aufruft.

Das stimmt so nicht. Du kannst sowohl unverwalteten als auch verwalteten Code einbinden. Eine andere in .NET geschriebene DLL kannst du mit einem Einzeiler laden und dessen Typen verwenden als wären sie in deiner eigenen Applikation drin, hier ist .NET wirklich extrem angenehm. Plugins mit .NET zu machen geht wie ein warmes Messer durch Butter. Auch für unverwalteten Code bieten sich sehr einfache Möglichkeiten an. Eine davon ist PInvoke, die andere ist COM.

- eine vernünftige Gridkomponente gibt es tatsächlich nicht (Aussage des Instruktors) Hier muß man sich aus der Listenkomponente selbst was zusammenbauen.

Es kommt draufan, was "vernünftig" ist, es gibt das DataGridView welches Basisfunktionalitäten bietet, für MsSQL orientierte Applikationen gibt es schon etwas fortgeschrittenere Sachen. Zudem gibt es fast unendlich viele tolle Controls im Netz (auch häufig gleich in Visual Studio über NuGet mit einem Klick hinzufügbar), teilweise auch kostenlos.

- C# Programme sind deutlich langsamer als Programme in C/C++ oder Pascal. Kann ja auch nicht anders sein, da sie ja erst zur Laufzeit kompiliert werden. Vorteil ist natürlich das es hierdurch detailierte Fehlermeldungen gibt (mit Angabe der Zeilennummer)

Dies musst du anders formulieren: Die schnellste Möglichkeit in .NET ist langsamer als die schnellste Möglichkeit in C++. ABER: Die schnellste Möglichkeit in .NET zu implementieren ist kein grosser Aufwand, die schnellste Möglichkeit in C++ zu implementieren ist in der Regel langwierig, zäh und geprägt von viel Frustration was im Endeffekt dazu führt, dass oftmals die .NET Programme schneller sind als vergleichbare C++-Programme, weil man einfach nicht die Zeit und Resourcen hat in C++ das Maximum rauszuholen in .NET jedoch schon.

Persönlich würde ich dann doch eher zu Java neigen.

Zu Java rate ich eigentlich nur noch, wenn du wirklich viel auf verschiedenen Plattformen realisieren willst (mobile/desktop/...). In den von dir genannten Punkten unterliegt .NET Java eigentlich nur bei den Mengen im Rest hat .NET die Nase deutlich vorne. Das wird sich auch in Zukunft noch viel weiter auseinander leben, in der Zeit in der Java kein einziges Sprachupdate erlebt hat gab es bei C# glaub ca 4 Major Releases mit neuen Features und Funktionen.

Und zu guter Letzt:
Parallelität war nie angenehmer als in C#

 

[Twinsetter]

@Cromon

Noch mal kurz zu den DLL's
Hab ich ja geschrieben, daß es mit managed Code kein Problem ist, aber dann zwinge ich den Pluginprogrammierer zu .Net und genau das möchte ich nicht.

Das Einbinden von unmanaged DLL's ist sicher nicht schwierig, das Problem ist an dieser Stelle nur, daß ich zum Einbinden der DLL ja deren Filenamen angeben muß und der ist mehr oder weniger als Konstante (sorry weiß mommentan nicht wie es in C# genau heißt) festgelegt, d.h. ich muß dort einen festen DLL-Namen festlegen und kann diesen nicht als Stringvariable übergeben - so haben wir es zumindest gelernt (kann ja sein, daß sich zwischenzeitlich was geändert hat). Und genau das ist das Problem. Mein Programm schaut beim Programmstart nach welche DLL's vorhanden sind und bietet dann entsprechende Funktionen an. Ich weiß aber vorher nicht welche DLL's installiert sind und welche nicht. Letzendlich läuft es darauf hinaus, daß ich an Hand der geforderten Aufgabe die passende DLL laden muß und das geht nun mal nur über den Namen der DLL.

Ich sehe derzeit keinen entscheidenden Vorteil von C# gegenüber Objectpascal (Delphi), der die Neuimplementierung eines Progammes mit ca. mittlerweile 180000Zeilen Code zu rechtfertigen würde.


Ja warum gab es bei C# denn 4 Majorreleases, weil das was es gab unzureichend war.

..... gar keine Daseinsberechtigung. Man hat dies vermutlich eingeführt weil man die Leute von C++ nach C# bringen will aber verhindern will, dass sie einen Kulturschock erleiden

Man hätte die Chance gehabt was Ordentliches zu machen und alten Ballast über Bord werfen können. Aber man hat es nicht getan, um wie Du schon richtig bemerkt hast die C-Programmierer nicht einem Kulturschock auszusetzen. Aber so schlimm wäre es bestimmt nicht gekommen. Am Anfang hätte es sicher etwas Gezeder gegeben, aber das hätte sich schnell gelegt. So hat man zwar was Neues gemacht, das mit Sicherheit viele gute Ansätze enthält, aber man war eben nicht konsequent.

Was wirklich gelungen ist ist meines Erachtens die IDE sprich Visual Studio - die nutze ich z.B. auch für Fortran.

 

[Cromon]

Hallo Twinsetter

Stimmt, das mit den Plugins habe ich falsch gelesen, ich dachte du meinst es geht allgemein nur mit unmanaged. Aber dein Problem mit den Namen:

var files = System.IO.Directory.GetFiles("MyDirectory", "*.dll");
foreach(var file in files) {
 // load
}

So wie man das kennt, alle Plugins aus einem Ordner laden.

Deine Aussage zu den Majorreleases ist so eine typische unqualifizierte Aussage die jeglichen fundierten Hintergrunds entbehrt, schade eigentlich. Der Grund für die Releases war viel mehr, dass man neue tolle Sachen hatte (7 Jahre sind in der Softwareentwicklung vergleichbar mit einem Jahrtausend in irgendeiner anderen Wissenschaft) und die der Community nicht vorenthalten möchte.

 

[Twinsetter]

Sorry, aber mit meinen DLL's hast Du immer noch nicht verstanden.
Klar geht es mit managed Code, Du hast ja selbst in Deinem letzten Post einen Codeschnipsel beigelegt. Der ist ja auch korrekt und funktioniert ja auch, aber eben nur mit managed Code - also DLL's die in .Net geschrieben sind - und genau das will ich nicht. Ich möchte denjenigen der ein Plugin programmiert nicht auf .Net festlegen wollen, sondern er soll selbst entscheiden, wie und mit welchen Mitteln er die Aufgabe löst - von mir aus auch mit .Net
Deshalb habe ich die Funktionen und Datenstrukturen die die DLL's exportieren offen gelegt. Das ist das einzige woran sich der Programmierer halten muß. Er hat sogar die Freiheit bestimmte Funktionen wegzulassen, wenn sie für sein Plugin nicht erforderlich sind, da ich im Hauptprogramm prüfe ob die angeforderte Funktion vorhanden ist. Sollte sie nicht da sein reagiere ich halt entsprechend.

Noch mal zurück zum DLL-Import (unmanaged Code) unter C#. Das geht leider nicht mit Deinem 2 Zeiler. Laut meinen Kursunterlagen funktioniert das mit PInvoke (irgendeiner hatte das im Thread geschrieben) und das muß so aussehen

//DLL importieren
[DllImport("TEST.DLL", EntryPoint="Summe", CharSet=CharSet.Ansi, ExactSpelling=true, CallingConvention.Cdecl)]
//jetzt die Funktion ausführen
int a = Summe(irgendwas);

Und genau bei der DllImport- Funktion liegt das Problem. Der Dateiname "TEST.DLL" ist statisch bzw. ein Konstantenwert und kann nicht per Stringvariable übergeben werden. Das heißt im Umkehrschluß das Ding muß immer TEST.DLL heißen. Man kann's nur lösen in dem man die gewünschte DLL umbenennt/umkopiert (auf Dateiebene) - eigentlich nicht machbar, oder man schaltet eine .Net-Dll vor, die den Aufruf in einer Klasse kapselt und dann ihrerseits die Funktionen "durchreicht". Diese wäre dann managed und da würde Dein Code greifen. Aber so richtig elegant ist das nicht und ich zwinge den Programmierer doch wieder dazu Code in .Net zu implementieren

Ob meine Aussage bezüglich Majorreleases unqualifiziert ist oder nicht lasse ich mal dahingestellt - ich akzeptiere da Deine Meinung und es mag ja aus Deiner Sicht anders aussehen. Gebe ja zu, daß ich vielleicht etwas zu sehr pauschaliert habe. Fakt ist aber das es in den Releases 2 und 3 relativ wenig Neues gegeben hat. Vielmehr sind in diesen Versionen Funktionen hinzugekommen die in anderen Sprachen (C, C++, Pascal und was es sonst so noch gibt) nichts Neues mehr sind. Einen richtigen und guten Schritt nach vorn hat es mit Version 4 getan, da sind wirklich Sachen dazu gekommen die es so in anderen Sprachen nicht gibt oder die sich dort nur viel aufwändiger umsetzen lassen. Beispiel: Dynamische Programmierung /Dynamischer Quellcode.
Wie Du richtig bemerkt hast gabs da in Java deutlich weniger Majorreleases, aber das liegt meiner Meinung daran, daß man wahrscheinlich von Anfang an ein schlüssiges Konzept hatte und das auch durchgezogen hat, ja und vielleicht hat man auch bewußt auf ein paar "Innovationen" verzichtet und letztendlich gibt der Erfolg Java recht. Leider ist es bei MS immer so, daß die Jungs durchaus sehr innovativ sind, aber eben oftmals Produkte heraushauen die dann beim Enduser reifen. Und so muß halt oft nachgebessert werden. Windows selbst ist das beste Beispiel. Was da z.B. bei XP an Patches und Korrekturen eingespielt wurde geht auf keine Kuhhaut, da muß man sich nur mal die Liste der eingespielten Korrekturen in der Systemsteuerung anschauen, wenn man alle Updates mitgenommen hat. Und Win 7 ist da nicht besser (habe bei einem Bekannten einen neuen Laptop eingerichtet und nach dem der im Netz war hat der erst mal ca. 200 Updates herunter geladen und jede Menge Reboots gemacht - wir haben dann am nächsten Tag weiter gemacht). Aber das ist ein anderes Thema. Ich wollte damit nur sagen, daß ich dies als generelles Problem bei MS sehe.

Ist aber alles meine persönliche Meinung und andere sehen das mit Sicherheit anders, was auch gut so ist. Ich bin halt nicht unbedingt ein Freund von MS. Letztendlich arbeite ich damit weil ich es beruflich tun muß. Privat bin ich schon lange weg davon und fahre auch ganz gut damit.

 

[ComFreek]

Zwei Links (über Google gefunden!), die dir helfen könnten:

http://www.codeproject.com/Tips/75470/Use-dynamic-to-make-PInvoke-simple
http://blogs.msdn.com/b/jonathanswi...nmanaged-dll-from-.net-_2800_c_23002900_.aspx

Was ich nicht verstehe, wie kann man die Qualität einer Software anhand der veröffentlichten Versionen messen? Da kann man nicht von einer direkten Relation ausgehen.


@Windows:
Gut 200 Updates sind viel, aber die Codebasis ist auch extrem groß (~40 * 10^6 LOC bei XP). Es gibt ja auch Tools, welche alle Updates auf eine DVD/USB-Stick exportieren lassen und es ermöglichen von diesem Medium dann zu installieren (bei erstmaliger Installatio nat. nicht möglich).

Er hat sogar die Freiheit bestimmte Funktionen wegzulassen, wenn sie für sein Plugin nicht erforderlich sind, da ich im Hauptprogramm prüfe ob die angeforderte Funktion vorhanden ist. Sollte sie nicht da sein reagiere ich halt entsprechend.

Nur so als Tipp: mach das nicht. Zu viel Freiheit gewähren kann Einbußen bringen.

 

[Twinsetter]

Was ich nicht verstehe, wie kann man die Qualität einer Software anhand der veröffentlichten Versionen messen? Da kann man nicht von einer direkten Relation ausgehen.

Das sehe ich genauso. Die Qualität einer SW macht sich nicht an der Anzahl der Releases fest. Eher im Gegenteil. Wenn eine Software wenige Releases hat und dennoch über einen großen Zeitraum von vielen Anwendern benutzt wird, dann zeigt dies eher das das Konzept gut durchdacht wurde.

Was heißt die Codebasis ist extrem groß? Ist bei anderen Betriebssystemen auch so und die kommen in dieser Beziehung mit wesentlich weniger aus.

Er hat sogar die Freiheit bestimmte Funktionen wegzulassen, wenn sie für sein Plugin nicht erforderlich sind, da ich im Hauptprogramm prüfe ob die angeforderte Funktion vorhanden ist. Sollte sie nicht da sein reagiere ich halt entsprechend.

Nur so als Tipp: mach das nicht. Zu viel Freiheit gewähren kann Einbußen bringen.

Das kommt darauf an, was mit dem Plugin gemacht wird. Mein Programm sammelt u.a. Messwerte ein die bestimmten Kriterien genügen und stellt diese tabellarisch und grafisch dar. Hierbei werden z.B die grafischen Darstellungen von der DLL als Metafile zurückgegeben und vom Hauptprogramm in einen Report, Worddokument HTML-Seite etc. eingearbeitet. Nun gibt es aber Messaufgaben bei denen die grafische Darstellung aus verschiedenen Gründen wenig Sinn macht und diesem Fall benötigt das Plugin die Funktion zur Rückgabe der Grafik nicht und kann demzufolge weggelassen werden. Das Hauptprogramm erkennt die weggelassene Funktion und überspringt diesen Schritt der Grafikausgabe. Wenn es später mal notwendig sein sollte doch die Grafik auszugeben kann es einfach in die DLL implementiert werden.
Die Aufgabe die mein Programm lösen muß ist schon recht komplex und da sich Anforderung auf Grund des technischen Fortschrittes und auf GRund von Normanforderungen immer weiter entwickeln, muß ich an dieser Stelle recht flexibel sein, aber das ist nicht das Problem.


Gruß Twinsetter