Vorteile von Delphi

[Hubble]

Zitat:

Zitat von malo

Von wegen "unsauberes Programmieren" kann man sich jedoch auch streiten. Jede Sprache hat ihre Vorteile. In Delphi ist IMHO, dass man strukturiert Variablen immer an den Anfang setzen muss, für alles einen eigenen Bereich hat, und nichts "mal eben irgendwo" machen kann etc. Ob es ein Fluch oder ein Segen ist, soll jeder selbst entscheiden. Ich bekomme jedenfalls das Grauen, wenn ich einen C++-Quelltext sehe, in dem in jeder 15. Zeile eine Variable deklariert wird. Wenn ich ein wenig weiterlese, weiß ich gar nicht mehr, welche Variable was genau machen soll. Und wenn ich es nachlesen will, muss ich den gesamten Quelltext durchstöbern und suchen.

In C/C++ schreibe ich z.B. in Zeile 36 einer Funktion:

for(int i=0;i<5;i++)

Mich interessiert die Variable i nur hier an dieser Stelle. Kommt die Schleife weg, dann ist auch die Variable weg.
Deswegen will ich nicht normal 36 Zeilen vorher var i schreiben.

Der Übersicht halber schreibe auch ich einen Großteil der Objekte und Variablen an den Anfang einer Funktion.

Zitat:

Zitat von malo

Zitat:

Zitat von hubble

In Delphi ist ein Nachteil (bei größeren Projekten hauptsächlich), dass man alles "mal eben" zusammenklicken kann. Da friemelt man irgendwie eine GUI zusammen, baut hier noch was ein, und da noch was ein...

Aber wird man trotzdem in Delphi dazu verleitet, schlampig zu programmieren (im Vergleich zu C++)?
Ich denke, ich C++ ist das noch schlimmer. Hingeschmierte Einzeiler sind oft schwerer zu lesen oder zu warten als ein strukturierter Delphi-Quelltext, finde ich.

z.B. bei der Verquickung von Daten und GUI. Passiert in Delphi Projekten häufiger.
Bei einem Projekt von mir wird eine graphische LED-Komponente verwendet um den Zustand eines Ausgangs anzuzeigen und zu speichern.
Ist schrecklich wenn überall in den Uses ein Bezug auf main sein muß damit man den Zustand des Ausgangs erfährt.
Ist fehlerträchtig weil unübersichtlich und kann z.B. bei 2 schnellen Clicks hintereinander wegen der Art der Implementierung zu Ungleichheit von elektrischem Ausgang und der Komponente führen. (ist aktuell eins meine Probs und wär in VC++ selbst bei mäßigen Programmierern warscheinlich so nicht passiert.)

Hubble

[Luckie]

Zitat:

Zitat von Hubble

(ist aktuell eins meine Probs und wär in VC++ selbst bei mäßigen Programmierern warscheinlich so nicht passiert.)

Und warum benutzt du dann Delphi, wenn es so schlecht ist und dein Problem nur unnötig verkompliziert (angeblich)?

[Hubble]

Zitat:

Zitat von Luckie

Zitat:

Zitat von Hubble

(ist aktuell eins meine Probs und wär in VC++ selbst bei mäßigen Programmierern warscheinlich so nicht passiert.)

Und warum benutzt du dann Delphi, wenn es so schlecht ist und dein Problem nur unnötig verkompliziert (angeblich)?

Stimmt ich kann ja einfach mal meinen Chef fragen ob ich meine andere Arbeit mal für 16 Monate liegen lassen kann um die alten lauffäigen Programme auf eine meiner Ansicht nach schöne Programmiersprache umzustellen.



@jbg
Schöner Ansatz, werds mal testen obs geht.
Falls ja, dann hast Du mir sehr geholfen.

Hubble

[Hubble]

@jbg
Is ja Wahnsinn das AutoDelete geht echt. Ich brech ab :wall::wall::wall: :gruebel: :smile2: :roteyes: :spin2: :hello: :duck:
Damit is eins meiner Hauptargumente gegen Delhpi baden gegangen.

Hubble

[malo]

Zitat:

Zitat von Hubble

In C/C++ schreibe ich z.B. in Zeile 36 einer Funktion:

for(int i=0;i<5;i++)

Mich interessiert die Variable i nur hier an dieser Stelle. Kommt die Schleife weg, dann ist auch die Variable weg.
Deswegen will ich nicht normal 36 Zeilen vorher var i schreiben.

Glücklicherweise kann man ab D2006 mit Live-Templates arbeiten. Dann deklariert Delphi dir die Variable automatisch :)
Wobei mich die Schleifenvariablen in Delphi auch nerven. Ich fänd beispielsweise eine automatisch generierte, nur innerhalb der Schleife sichtbare Variable für Schleifenvariablen in Delphi ganz praktisch. Sowas in der Art wäre noch was, was ich mir wünschen könnte... Aber ansonsten: D2006 holen und Templates nutzen. Sonst hat man da halt Pech gehabt (ich auch) :(

Zitat:

z.B. bei der Verquickung von Daten und GUI. Passiert in Delphi Projekten häufiger.

Wie gesagt: Das sind Probleme des Programmierers. Es gibt auch viele, die unsauber mit C++ programmieren. Ist deshalb C++ schlecht?

[sakura]

Zitat:

Zitat von Hubble

Is ja Wahnsinn das AutoDelete geht echt. Ich brech ab :wall::wall::wall: :gruebel: :smile2: :roteyes: :spin2: :hello: :duck:

Nur sollte man object nicht mehr benutzen, und ich empfehle es Dir daher auch nicht. Aber keine Sorge, Autodelete geht trotzdem. Siehe Anhang. Der Code zum Aufruf selbst ist folgender:

Delphi-Quellcode:

procedure TForm6.Button1Click(Sender: TObject);
begin
  ShowMessage('Wir werden die Klasse gleich erstellen. Warte nur.');
  // HIER WIRD DAS OBJEKT ERSTELLT
  TFreeMyself.GetInstance;
  ShowMessage('Die Klasse existiert jetzt als Objekt und wird gleich frei gegeben. Sage Tschüß!');
  // UND ZERSTÖRT WIRD ES AUTOMATISCH. STICHWORT: REFERENCE-COUNTING
end;

Und der eigentliche Trick sind die Interfaces unter Win32

Delphi-Quellcode:

type
  IFreeMyself = interface
  end;

  TFreeMyself = class(TInterfacedObject, IFreeMyself)
  public
    constructor Create;
    destructor Destroy; override;
    class function GetInstance: IFreeMyself;
  end;

Der Rest ist im Anhang. Zugegeben, etwas mehr Arbeit, aber ein Code-Template hilft da schon weiter :mrgreen:

...:cat:...

[Insider2004]

Delphi macht glücklich.

[jbg]

Zitat:

Zitat von sakura

Nur sollte man object nicht mehr benutzen

Wieso object ? Das nutze ich doch gar nicht. Oder hat Borland etwa das class als Makro neu definiert und es mit object initialisiert? Wäre mir ehrlich gesagt neu. :lol:

[sakura]

Zitat:

Zitat von jbg

Wieso object ? Das nutze ich doch gar nicht. Oder hat Borland etwa das class als Makro neu definiert und es mit object initialisiert? Wäre mir ehrlich gesagt neu. :lol:

:wall: Ich war doch leicht verrutscht. Nun gut, damit war Deine Lösung essentiell die gleiche :oops: :duck:

...:cat:...

[jbg]

Zitat:

Zitat von sakura

Zugegeben, etwas mehr Arbeit, aber ein Code-Template hilft da schon weiter :mrgreen:

Mein Ansatz mit dem AutoDelete ist da flexibler. Er erlaubt es auch bereits existierende Klassen mit AutoDelete (RefCount) zu versehen. Und man hat nicht das Problem, dass man nicht mehr an das Objekt selbst herankommt. Bei deinem Ansatz müsste man zu aller erst mal ein "Interface extrahieren" drauf anwenden.

[jbg]

Zitat:

Zitat von sakura

Ich war doch leicht verrutscht.

Dachte ich mir schon. Ich hatte irgendwo in meinem Roman ja auch das object erwähnt. Nur wird da natürlich der Destruktor nicht automatisch aufgerufen.

Was man beim AutoDelete noch machen könnte, wäre den VMT Zeiger des Destruktors auf eine Funktion umzubiegen, die dann die Referenz in TAutoDelete auf NIL setzt und dann den original-Destruktor aufruft. Dafür bräuchte man dann aber eine TBucketList, weil ja vom Objekt zum TAutoDelete Objekt eine Rückverbindung vorhanden sein muss. Der Vorteil dabei wäre dann, dass myobj.Free aufgerufen werden kann, ohne das es dann beim Verlassen des Interface-Cleanup-Blocks kracht.