Vorteile von Delphi

[jbg]

Zitat von Hubble:

Das reine Expception Handling ist dem in C++ ähnlich. Aber nicht in Verbingung mit Objekten.

Dann muss man eben die Compiler-Magic von Delphi mit dem Erzeugen des try/finally beauftragen
Hier mal eine vereinfachte TAutoDelete Klasse.

Delphi-Quellcode:

type
  IAutoDelete = interface
    function This: Pointer;
  end;

  TAutoDelete = class(TInterfacedObject, IAutoDelete)
  private
    FObject: TObject;
  public
    constructor Create(AObject: TObject);
    destructor Destroy; override;
    function This: Pointer;
  end;

{ TAutoDelete }

constructor TAutoDelete.Create(AObject: TObject);
begin
  inherited Create;
  FObject := AObject;
end;

destructor TAutoDelete.Destroy;
begin
  FObject.Free;
  inherited Destroy;
end;

function TAutoDelete.This: Pointer;
begin
  Result := FObject;
end;

function NewOAD(AObject: TObject): IAutoDelete;
begin
  Result := TAutoDelete.Create(AObject);
end;

Zitat:

Hier nochmal im Klartext und für alle:
C:
void IrgendeineFunktion()
{
CMeinObjektTyp A( "irgendein Text");

EinFunktionsaufrufmitexception();
}

Das würde dann so aussehen:

Delphi-Quellcode:

procedure IrgendeineFunktion;
begin
  NewOAD( TMeinObjectTyp.Create('irgendein Text') );

  EinFunktionsaufrufmitexception;
end;

Und die AutoDelete-Klasse muss man nur einmal schreiben.
Will man mit noch Methoden aufrufen oder Eigenschaften abfragen, so würde das so aussehen:

Delphi-Quellcode:

var
  A: TMeinObjektTyp;
begin
  A := NewOAD( TMeinObjektTyp.Create('irgendein Text') ).This;
  A.MachWas;
end;

Zitat:

Es ist nicht möglich diesen übersichtlichen Einzeiler auch in Delhpi zu schreiben.

Gegenbeweis bereits angetreten.

Zitat:

Das Ding landet in Delhpi immer auf dem Heap.

Dann nimm doch das alte object. Das entspricht dem class in C++.

Delphi-Quellcode:

PMyObject = ^TMyObject;
TMyObject = object
private
  m_field: Integer;
public
  constructor Init;
  destructor Done;
end;

Zitat:

Wer diesen Punkt nicht zumindest als sehr ungünstig in Delhpi anerkennt ist für mich diskussionsfäig.

Bin ich jetzt nicht mehr diskussionsfähig für dich, weil ich ein Beispiel gepostet habe, das aus deinem Delphi-3-Zeiler einen 1-Zeilen gemacht hat?

Zitat:

Also braucht man in Delphi zwingend einen try except block, der alle Eventualitäten abhandelt.

Deswegen nutzt man das try/finally und nicht das try/except. try/except wird nur dann verwendet, wenn man die Exception abfangen will (z.B. die allzubekannte EIdConnectionClosedGracefully).

Zitat:

In C ist dies in dieser Form nicht notwendig.

Außer man schaltet den automatischen Destruktor-Aufruf per Compiler-Schalter ab. Aber wer das macht, der sollte schon wissen was er da tut.

Zitat:

Ich habe im Moment das Problem, das bei einigen hundert Buttons in meinem Projekt ein Lock (wie in meinem Beipiel auf Seite 4 beschieben) gemacht werden müßte.
In C währe dies jemeils ein Einzeiler in der Ersten Zeile jedes ClickEvents.
In Delphi sind dies jeweils mindestens 7 Zeilen an 3 Stellen des Events.

Die TAutoDelete Klasse habe ich ja schon gepostet.

Zitat:

Zitat von sakura:

Btw, Dein Bespiel mit automatischer Objektfreigabe kann man auch in Delphi 6 bauen.

Gut dann zeig mir den Einzeiler.

Das habe ich ja schon gemacht. Aber man kann da noch einiges mehr machen. Man muss nur wissen, wie man die Compiler-Magic kontrolliert.

Zitat:

Zitat von Hubble:

schlechte Pointernutzung

Ist eventuell Geschmackssache aber in C hab ich alle Möglichkeiten damit in Delhpi nicht.

Wieso? Was geht mit Zeigern in C++, was in Delphi nicht geht. Zugegeben, man muss in Delphi desöfteren bei Zeigern Typecasten (wenn man nicht von Anfang an die richtigen Datentypen ausgewählt hat), aber man weiß dafür genau was man tut.

Zitat:

Ja auch ich lösche Objekte in Delphi mit free.
Aber ich kann eben auch wie oben beschrieben ein Objekt als Einzeiler erzeugen nutzen und danach Ignorieren weil er sich am Ende der Funktion unter allen Umständen selber löscht.

Irgendwie immer das selbe Kriterium: Ok, dann eben wieder: NewOAD( blabla.Create ); Übrigens OAD steht für ObjectAutoDelete. Das AutoDeleteObject wollte ich da nicht nehmen weil sonst NewADO draus würde und ADO ist bereits vergeben.

Zitat:

Wenn das ne kleine Hübesche Klasse ist dann schreibe ich eben lieber den Einzeiler direkt in die Deklaration und nicht erst 700 Zeilen später.

Das ist ein Unterschied im Sprachkonzept. Bei C++ muss ich deswegen immer diese zig Millionen Zeilen an Headers einbinden. Und manche Headerdateien können nicht vorkompiliert werden weil sie Code enthalten. Borland C++ sagt einem das wenigstens. Aber MSVC lässt die Datei einfach mal aus und der Programmierer darf sich selbst fragen, warum die Kompilierung so lange dauert.
Delphi/Pascal nutzt hingegen das Unit-Konzept. Alles was im implementation-Abschnitt steht, kann jederzeit geändert werden, ohne dass die von dieser Unit abhängigen Units neu kompiliert werden müssen. Interface entspricht also den .h-Dateien und Implementation den .cpp Dateien, mit dem unterschied, dass Units immer "vorkompiliert" sind.

Zitat:

Außderdem kann ich kleine Klassen (z.B. Miniparser) direkt über der Funktion als 10 Zeiler im .cpp File implementieren.
In Delphi lass ich dass und schreib mir lieber ein ungekapselte Funktion die zwar das gleiche kann, aber unangenehmer ist im Handling.

Klar ist das in diesem Fall eleganter. Mache ich auch regelmäßig in C++. Für Einzeiler ist das auch gut. Nur eben wenn man dann auf die Idee kommt, alles da reinzupacken, wie manche Programmierer, dann wird das sehr unübersichhtlich. Und dann habe dieses Feature lieber gar nicht, denn was nicht möglich ist, kann auch nicht "falsch" benutzt werden.

Zitat:

Natürlich geht in Delhpi auch irgendwie. Ist aber umständlicher kostet mehr Zeit und Übersicht.

Code-Navigation, Klassenvervollstänndigung und neuerdings Live-Templates sei dank.

Natürlich nur für den Fall das diese Klasse ausschließlich in dieser Funktion verwendet wird.
Ein mehrfach verwendetes Objekt würde ich nie mitten in den C++ Code hocken.

Zitat:

Zitat von sakura:

Zitat von Hubble:

nicht ausgereifte Projektverwaltung

Die ist bestimmt noch nicht alles was es sein könnte, aber schon viel besser in der aktuellen Version.

Mein Hauptproblem mit der Projektverwaltung ist das es keine Ordner gibt. Alle 100 Files liegen in einer Liste. In VCC kann ich Unterordner machen.

Die Galileo-IDE (C#Builder, Delphi 8, Delphi 2005, Delphi 2005) hat Ordner. Und für die alten Versionen gibt es Abhilfe in Form von IDE Experten.

Zitat:

Zitat von sakura:

Zitat von Hubble:

keine STL

Nun gut, und warum brauche ich die in Delphi - oder anders, was machst Du mit der, was Du in Delphi nicht tun kannst.

Man merkt das du noch nie die Vorzüge der STL genossen hast.

In Delphi brauche ich die auch nicht. Wenn ich eine Map happen will, dann gibt es zu aller erst mal TStringList. Und wenn das dann nicht reicht, kann man auf die JCL (JEDI Code Library) zurückgreifen und bekommt da so einiges geliefert. Für dein map<> Beispiel kann man z.B. die Klassen aus der Unit JclHashMaps nutzen. Für einfache Sachen gibt es auch noch die TBucketList und TBucketObjectList.

Zitat:

Diskutiere auch gerne und wäre dankbar wenn Ihr mich von Delphi überzeugt.

Ich denke, dass sollte nicht das Ziel dieses Threads sein. Überzeugen kann man sich nur selbst. Ich z.B. Arbeite gerne mit Delphi. Aber verabscheue C++ und C# nicht. Sogar mit VB komme ich unter gewissen Umständen zurecht.



Und noch ein "Wort" zum "Klicki bunti - fertig ist die Anwendung".
Das ein Chef meint, die Anwendung wäre fertig, wenn man schon Screenshots sieht, halte ich für ein gerücht. Es ist eher der Fall, dass man gelobt wird, weil man mit minimalen Aufwand/Zeit (=Kosten) eine präsentierfähige Oberfläche hat. Und wenn man dann das Rennen verliehrt, hat man nicht zig Manntage (bzw. Frautage) investiert.
Das trennen zwischen Oberfläche und Code ist dann ein anderes Thema, das vom jeweiligen Programmierer abhängt. Ich fange z.B. immer erst mit der Datenstruktur an, habe aber die Oberfläche im Hinterköpfchen damit ich die notwendigen Events bereits einbaue.