Vorteile von Delphi gegenüber C#

[hanspeter]

Zitat:

Zitat von Luckie

Dann guck dir mal die Größe des Frameworks für Win32 Programme an. ;)

Ein größeres Programm unter D7 bis D2005, hatte so etwa 4 mbyte. Unter D2009 ist dieses Programm auf über 10 mbyte angewachsen.
(Und das, obwohl eine Reihe Programmteile als Modul ausgegliedert wurden.)
Für dieses Programm habe ich allerdings keinen Vergleich.
Ein Tool welches von Delphi auf C# umgeschrieben wurde, benötigt mit Delphi (2009) etwa 2,5 Mbyte und in Net knapp 800 kbyte.
Das Delphi Programm wäre zwar mit Laufzeitbibliotheken minimierbar. Aber gerade mit Laufzeit - BPL bin ich gehörig auf die Nase gefallen.
Im Win32 Fall bin ich für die Bibliotheken verantwortlich. Im Net Fall kann ich auf MS und das aktuelle Update verweisen.


Gruß Peter

[himitsu]

Zitat:

Zitat von HeikoAdams

Mir ist nicht bekannt, das Microsoft an einem BS arbeitet, das in einer .net-Sprache geschrieben ist 8)

Dabei hieß es vor oder nach Vista :thumb:, daß die nächste Windows-Version angeblich "nativ" .NET sein soll und Win32-Programme darauf nicht mehr laufen werden. :nerd:
Und es hieß noch "Wechselt alle zu .NET, denn mit Win32 ist bald Schluß ... denkt doch an eure Zukunft"

(diese Angelegenheit hat sich ja nun spätestens mit Seven wohl doch wieder gegessen)

[mkinzler]

Singularity ist im Besten Fall eine Studie

[HeikoAdams]

Und was man von Studien halten darf, kann man regelmäßig auf Automobilmessen sehen: Die meisten der dort gezeigten Sudien ("Concept-Cars") verschwinden entweder in irgendwelchen Schubladen oder das spätere Serienmodell hat nur noch sehr wenig mit der Studie gemein.

[Bernhard Geyer]

Zitat:

Zitat von himitsu

Dabei hieß es vor oder nach Vista :thumb:, daß die nächste Windows-Version angeblich "nativ" .NET sein soll und Win32-Programme darauf nicht mehr laufen werden. :nerd:
Und es hieß noch "Wechselt alle zu .NET, denn mit Win32 ist bald Schluß ... denkt doch an eure Zukunft"

(diese Angelegenheit hat sich ja nun spätestens mit Seven wohl doch wieder gegessen)

Da hatten wohl einige Berater/Marketingmanager ihre eigene Unfähigkeit versucht mit FUD zu verschleiern.

Aber Win32 stirbt (bzw. ist "nur" ein gut funktionierender Aufsatz in zukünftigen Windows-Versionen) - Es lebe Win64!

[himitsu]

Warum ändert man denn nicht auch mal passend die CPUs?

Also kommt schon, 4 Register sind ja wohl ein Witz, da haben doch viele µCPUs mehr zu bieten.
Und warum nicht der Spielekonsolenindustrie folgen und die 32/64 Bit auf 128, 256, 512 oder gleich 1024 hochschrauben? :stupid:

Es ist doch nur eine Frage der Zeit, bis die ersten HeimPCs mit ExabyteRAMs ausgerüstet sind und dann reicht 64 Bit wieder nicht aus.

[Elvis]

Zitat:

Zitat von HeikoAdams

Zitat:

Zitat von himitsu

oder kann man .NET neuerdings auch pur und als eigenständiges BS installieren? :angel2:

Mir ist nicht bekannt, das Microsoft an einem BS arbeitet, das in einer .net-Sprache geschrieben ist 8)

Das is an sich falsch, denn es gibt bereits Singularity.
Aber das ist nur ein Proof-of-concept, kein Windows-Nachfolger. (Was du wohl meintest ;-) )

Zitat:

Zitat von RedOne

Ps. Anektote am Schluss: Eine mir bekannte Firma hat ihre Software von Delphi auf Java portiert, mit dem Ergebnis, dass sie so unzufrieden waren und auf .Net portierten. Dies befriedigte sie allerdings auch nicht und so portierten sie die gesamte Software wieder auf Delphi zurück :-D Dies wird wohl hoffentlich ein Extremfall bleiben :-)

Dann haben sie es einfach nur geschafft durch pure blödheit ihre Delphi-Denkweise in Java ausleben zu wollen und danach in .Net.
Jeder erfahrene Java oder .Net Dev hätte ihnen vorher sagen können, dass das nix werden kann.
Die durchschnittle Delphi-App hat in etwa soviel OO-Design wie die durchschnittliche DBase-App hatte.
Wer also jahr(zehnt?)elange Erfahrung darin hat es "falsch" zu machen, kann nicht plötzlich eine neue Entwicklungsplatform(Java) mit all den neuen Bibliotheken und Herangehensweisen und gleichzeitig moderne Softwareentwicklung lernen.
Und, lol, dann auch noch so blind zu sein um es gleich noch mal bei der nächsten Platform (.Net) zu versuchen.

@Topic und ein "shameless plug" ;-)
Es gab mal einen Vorteil von Delphi über C#:
Man konnte in C# keine Funktionen exportieren, so dass sie einfach von native Apps verwendet werden können.
Aber ich denke, das Problem habe ich hiermit erstmal gelöst. ;-)

[Luckie]

Zitat:

Zitat von Elvis

Die durchschnittle Delphi-App hat in etwa soviel OO-Design wie die durchschnittliche DBase-App hatte.

Wie kommst du denn darauf?

[mkinzler]

Es kommt darauf an, wessen Durchschnitt er meint. Man kann in Delphi.Win32 halt auch nich OOP-Programme erstellen, wie in jeder anderen Hybrid-Sprache ( z.B. C++) auch.

[SebE]

Hallo,
ich folge evtl nicht dem Faden, da ich nicht alles gelesen habe.

Was ich aber, auch wenn es nicht reinpassen sollte, sagen wollte.

Pascal hat einen riesigen Vorteil (für mich zumindest): Verschachtelte Routinen.
Ein MUSS für meine Projekte.

Ich hab nirgens gelesen, dass das jemanden bei c-basierenden Sprachen fehlt - stört euch das nicht?
oder gibt es womöglich besser Konzepte, die ich nicht kenne?

[Bernhard Geyer]

Zitat:

Zitat von SebE

Pascal hat einen riesigen Vorteil (für mich zumindest): Verschachtelte Routinen.
Ein MUSS für meine Projekte.

Ich hab nirgens gelesen, dass das jemanden bei c-basierenden Sprachen fehlt - stört euch das nicht?
oder gibt es womöglich besser Konzepte, die ich nicht kenne?

Veschachtelte Routinen sind schön bequem, aber nicht unbedingt nötig. Und bei zu intensiven gebrauch auch kontraproduktiv da man hier dann kreuzweise Variablen von höheren Ebenen nehmen kann/darf. Besser bei komplexen angelegenheiten eine Workerklasse definieren.

[SebE]

Ich weiß leider nicht, was eine Workerklasse sein soll, noch was du mit KREUZweisem Zugriff meinst.

[Bernhard Geyer]

Zitat:

Zitat von SebE

Ich weiß leider nicht, was eine Workerklasse sein soll,

Klasse die die Arbeit für dich übernimmt. Jede lokale Prozedur wir eine Methode

Zitat:

Zitat von SebE

noch was du mit KREUZweisem Zugriff meinst.

Delphi-Quellcode:

function MixIt(Param1, Param2: Integer): Integer;

  function Sub1(Param3, Param4: Integer): Integer;

    function SubSub(Param1, Param4: Integre): Integer;
    begin
      result := Param1 + Param2;   // <- Zugriff auf Übergabeparameter der äusersten Ebene. Evtl. schon geändert, sowie lokaler übergabeparameter der zufällig gleichen Namen wie Parameter auf äußerster Ebene hat.
    end;

  begin
    Param2 := 2 * Param2;
    result := Param1 SubSub(Param3, Param4);
  end;

begin
  Param1 := Param1 div 2;
  result := Sub1(Param3, Param4);
end;

[Elvis]

Zitat:

Zitat von SebE

Ich hab nirgens gelesen, dass das jemanden bei c-basierenden Sprachen fehlt - stört euch das nicht?
oder gibt es womöglich besser Konzepte, die ich nicht kenne?

Wenn man es unbedingt haben will geht das mit anonymen Methoden:

Code:

var irgendWasAusDeinerMethode = ...;
Func<Int32, String> doSomething = delegate(Int32 someValue)
{
   return irgendWasAusDeinerMethode.EineMethode(someValue) + "...";
};

//oder als lambda:
Func<Int32, String> doSomething = someValue => irgendWasAusDeinerMethode.EineMethode(someValue) + "...";

var a = doSomething(1);
var b = doSomething(2);

Zitat:

Zitat von Luckie

Zitat:

Zitat von Elvis

Die durchschnittle Delphi-App hat in etwa soviel OO-Design wie die durchschnittliche DBase-App hatte.

Wie kommst du denn darauf?

Man entwickelt da ein Gefühl nach all den Apps, die man so nutzt und die sich als Delphi Apps herausgestellt haben und wie sie RAD-ifiziert sie gestrickt sind.

Ich habe bisher noch keine Delphi App benutzt, die COM-Automatisierbar war, oder die es erlaubt in einer Config einen eigenen Logger reinzuklinken, geschweige denn dort eine andere Datenzugriffsstrategie zur Verfügung zur stellen.

[himitsu]

Workerklasse:
einfach eine Klasse, wo alle deine lokalen/verschachtelten Prozeduren drin sind.

KREUZweiser Zugriff ... z.B.:

Delphi-Quellcode:

Procedure AAAA;
  Var x: Integer;

  Procedure BBBB;
    Begin
      x := 2;
    End;

  Begin
    x := 1;
    BBBB;
    If x = 2 Then ....;
  End;

[edit]
zu langsam

[Bernhard Geyer]

Zitat:

Zitat von Elvis

Zitat:

Zitat von Luckie

Wie kommst du denn darauf?

Man entwickelt da ein Gefühl nach all den Apps, die man so nutzt und die sich als Delphi Apps herausgestellt haben und wie sie RAD-ifiziert sie gestrickt sind.

Und wird durften (mit Delphi für native/Java für Web) eine .NET-Anwendung ablösen die sich nach Win 3.1 angefühlt hat.

Zitat:

Zitat von Elvis

Ich habe bisher noch keine Delphi App benutzt, die COM-Automatisierbar war,

Geht aber, und wird auch bei einigen Kunden von uns im 24x7-Betrieb verwendet.

[Elvis]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von Elvis

Zitat:

Zitat von Luckie

Wie kommst du denn darauf?

Man entwickelt da ein Gefühl nach all den Apps, die man so nutzt und die sich als Delphi Apps herausgestellt haben und wie sie RAD-ifiziert sie gestrickt sind.

Und wird durften (mit Delphi für native/Java für Web) eine .NET-Anwendung ablösen die sich nach Win 3.1 angefühlt hat.

Zitat:

Zitat von Elvis

Ich habe bisher noch keine Delphi App benutzt, die COM-Automatisierbar war,

Geht aber, und wird auch bei einigen Kunden von uns im 24x7-Betrieb verwendet.

Ich schrieb nicht "jede". Darfst dich also als überdurchschnittlich anpreisen. :mrgreen:

[SebE]

Das mit dem KREUZenden Zugriff verstehe ich nicht als Proble:
Immer das am nächsten stehende Symbol wird gewählt.

Deshalb ist es ja kein Kreuz, es geht ja nur in eine Richtung (nach oben).

Zu Workerklassen -> heißt das, ich habe für jede Ebene eine Klasse?

[Bernhard Geyer]

Zitat:

Zitat von SebE

Zu Workerklassen -> heißt das, ich habe für jede Ebene eine Klasse?

Kommt auf die Komplexität an. I.d.R. wird eine Klasse reichen.

[Delphi-Laie]

Mir fielen bisher zwei Dinge in C (++/#) auf, die ich bisher bei Delphi vermißte:

1. Step-Option in Zählschleifen (oder gibt es das in neueren Delphi-Versionen?). Gibt es auch und sogar in Basic. Ohne ist es eine geringe zusätzliche, aber eigentlich unnötige Variablenfummelei mithilfe einer while-Schleife.

2. Alternativ statt oder noch besser zusätzlich zu repeat until wäre, wenn es ein do while gäbe, die Programmierung ein Quentchen flexibler (muß man eben statt der Abbruchbedingung diese logisch negieren, dann wird es eine Fortsetzbedingung). Ob es in C (++/#) Iterationen mit End-Abbruchbedingung gibt, weiß ich allerdings nicht.

[mkinzler]

Zu 1. einfach durch Entkopplen von Laufvariable und Nutzvariable

Delphi-Quellcode:

for i := 1 to 4
begin
    j := i * 2; // Step 2
end;

Zu 2. es gibt doch eine While-Schleife in Delphi

[Delphi-Laie]

Zitat:

Zitat von mkinzler

Zu 1. einfach durch Entkopplen von Laufvariable und Nutzvariable

Delphi-Quellcode:

for i := 1 to 4
begin
    j := i * 2; // Step 2
end;

Genau da haben wir doch die Variablenfummelei!

Zitat:

Zitat von mkinzler

Zu 2. es gibt doch eine While-Schleife in Delphi

Ja, while-do, aber eben nicht do-while (letzteres schrieb ich oben eben genau in dieser Reihenfolge).

[Meflin]

Zitat:

Zitat von Delphi-Laie

Ja, while-do, aber eben nicht do-while (letzteres schrieb ich oben eben genau in dieser Reihenfolge).

tauft sich repeat ... until

[Delphi-Laie]

Zitat:

Zitat von Meflin

Zitat:

Zitat von Delphi-Laie

Ja, while-do, aber eben nicht do-while (letzteres schrieb ich oben eben genau in dieser Reihenfolge).

tauft sich repeat ... until

Sag bloß - wer hätte das gedacht?!

Doch auch hier hilft genau(er)es Lesen meines obigen Beitrages weiter: repeat-until und do-while haben konträre, aus Sicht der Logik zueinander negierte Abbruchbedingungen. Muß man, da eben nicht beide Schleifen mit Endabbruchbedingung verfügbar sind, manchmal umdenken. Ist an sich trivial, doch auch bei solchen Gedanken gibt es Fehler (manchmal bei den einfachsten Dingen, und solche Fehler finden sich keinesfalls immer am schnellsten).

[mkinzler]

Die ien ist halt eine Entry Condition Loop und die andere eine Exit Condition Loop, deshalb sind die Bedingunegn auch gegensätzlich

[Elvis]

Zitat:

Zitat von Delphi-Laie

1. Step-Option in Zählschleifen (oder gibt es das in neueren Delphi-Versionen?). Gibt es auch und sogar in Basic. Ohne ist es eine geringe zusätzliche, aber eigentlich unnötige Variablenfummelei mithilfe einer while-Schleife.

Oxygene kann das:

Delphi-Quellcode:

for i : Int32 := 0 to 1000 step 100 do
  Console.WriteLine(i);
0
100
200
300
...

Es hat sogar externe iteratoren (in C# foreach) mit index variable:

Delphi-Quellcode:

for item in someList index i do
   Console.WriteLine(item.Abc + i);

"i" ist hierbei Int32, "item" ist vom Element-Typ von "someList", beide existieren nur innerhalb des loops.

Oder wenn man nur Elemente eines bestimmten Types will:

Delphi-Quellcode:

for matching e : Employee in persons do
  ...

Natürlich geht damit auch "index i".

Aber in native Delphi gibt das alles natürlich nicht, oder erst 5 Jahre später.
Da muss man eben immer noch alles dem Compiler vorkauen, damit der auch ja nix ein zweites Mal ankieken muss. :roll:

[Delphi-Laie]

Zitat:

Zitat von Elvis (Beitrag 951514)

...Aber in native Delphi gibt das alles natürlich nicht, oder erst 5 Jahre später.
Da muss man eben immer noch alles dem Compiler vorkauen, damit der auch ja nix ein zweites Mal ankieken muss. :roll:

Das ist m.E. ein wenig ungerecht. Sooo dumm ist der Delphi-Compiler keinesfalls - er ist schließlich kein Assembler. Z.B. optimiert er Zählschleifen (bzw. er versucht es wenigstens), indem er sie nach Möglichkeit, abweichend vom Quellcode, wo es meistens umgekehrt ist, abwärtszählen läßt (was beim Debuggen gelegentlich verwirrend ist, einige diesbezügliche Fragen, bei denen man das nicht wußte oder es einem nicht bewußt war, zeigen das). Einen Compiler so zu optimieren, das eine vom anderen treffsicher zu unterscheiden, ist vermutlich nicht ganz trivial (ich wüßte es auf Anhieb nicht, wie man das zuverlässig voneinander separiert).

Sicher gibt es noch viele andere Dinge, mir unbekannte Dinge, die Borland & seinen Nachfolgern exzellent gelungen sind.