Vorteile von Delphi

[alzaimar]

Zitat von tommie-lie:

Zitat von alzaimar:

ich bin auch Koch

Gibt es auch was, was du nicht kannst?

Ordnung und/oder mal die Schnautze halten und beim Thema bleiben.

Wenn Hubble der Ansicht ist, das Objekte auf dem Stack toll und schnell sind, kann ich ihm nicht widersprechen, aber ist nicht ein Zusammenhang mit diesem Speichermodell und den Exploits, die doch gerade versuchen, den Stack zu manipulieren?

Aber grundsätzlich geht es hier hoffentlich nicht schon wieder um den C++ vs. Delphi Krieg, bzw. was man womit alles machen kann, oder nicht, sondern primär (jedenfalls für mich) um die Frage, ob eine Progammiersprache (inkl. IDE!!!) ein gutes oder ein sicheres Werkzeug sein soll. Leider geht beides (noch) nicht, denn Sicherheit geht immer auf Kosten der Freiheit (Gruss an unsere Innenminister, gell?).

Ich meine, sowohl C++ als auch Delphi sind doch gleich gut. Was die eine (Templates, Mehrfachvererbung bla bla) hat, macht die andere durch eine bessere Struktur wieder wett. Früher oder später werden die sowieso entweder von D# (was immer das ist) o.ä. abgelöst bzw. so lange weiterentwickelt, bis der einzige Unterschied zwischen C++ und D++ das '{' vs. 'begin' ist.

Wenn ich mir diverse Skriptkomponenten so anschaue, die es einem ermöglichen den Code wahlweise als C,Delphi oder Basic Quellcode anzeigen zu lassen, dann sehe ich, wohin die Reise gehen wird.

Das Problem ist nicht die Sprache, sondern die Entwickler. Leider kann jeder mit den hübsch bunten Klicki-GUIs der IDE mal eben etwas zusammenfrickeln, was so aussieht, als ob es eine Anwendung wäre.

An den Unis wird bedauerlicherweise das 'Handwerk' des Programmierens, also das reine Hacken, Suchen nach Algorithmen, Optimieren, Einhalten von Regeln und Disziplinen nicht mehr gelehrt, sondern irgendwelcher anderer Quark. Ich meine, nicht jeder ist zum Entwickeln geboren, aber ich muss doch auch als 'IT-Entscheider' wissen, ob und wann ein Problem NP-komplett ist, und wann nicht. Als IT-Fuzz, der über Millionen-Anschaffungen entscheidet, muss ich doch einschätzen können, ob der Preis für eine SW gerechtfertigt ist, oder nicht und ggf. dem Anbieter mal auf den Zahn fühlen. In meinen 25 Jahren Berufserfahrung hat mich ein IT-Manager genau 2x vorgemacht, das mein Angebot zu teuer ist, weil man das einfacher hinbekommt. Und das war im Ausland! Den Deutschen muss man nur Dick daher kommen und schon nehmen die einem Alles ab.

Na, ja wieder mal OT.

Zurück zum Thema: Hubble, hör mir auf mit der BDE, das war wirklich Nichts. Aber wer aufgepasst hat, hat schon vor 5 Jahren die Finger von gelassen (als nämlich ADO aufkam, was auch wieder nicht besonders ist).

Dein Ansatz, für jedes Problem das richtige Werkzeug zu verwenden ist, glaube ich, das Richtig: Wer Webseiten mit Delphi abbildet, der ist fleissig, hat sie aber nicht mehr alle. Umgekehrt, wer einen performanten Algo in PHP abbildet auch.

Abschließend noch ein Wort zu A.Koch: Der ist der COM/ADO-Pabst und damit kann er ruhig in Richtung Visual Studio. Das ist doch ein gutes Produkt, oder nicht?

Die abschließende große Frage für mich ist die:
Warum hat Borland Anders Heijlsberg zu MS ziehen lassen? Weil MS zu viel geboten hat? Nee, da war ein Deal mit im Spiel, der beide Seiten befriedigen muss: MS hat eine .NET Klassenbibliothek alleine nicht hinbekommen und eine gute IDE auch nicht. Borland dagegen sah wegen .NET und C# die Felle davon schwimmen. Früher waren die Beiden spinnefeind und heute fragt man sich, wann sie denn Kinder kriegen. Dämmerts?

Ich prophezeie ein D# (ist ja auch schon da), das 100% kompatibel zum C# sein wird: MS und Borland teilen sich die Welt auf und jagen Java zum Teufel, schätze ich.

Vermutlich werden wir uns per Options-Dialog unsere eigenen Keywords 'begin','{' etc. zusammenklicken können, so das nun wirklich Keiner mehr meckern kann

In diesem Sinne: An die Arbeit!

[r_kerber]

Zitat von alzaimar:

Wer Webseiten mit Delphi abbildet, der ist fleissig, hat sie aber nicht mehr alle. Umgekehrt, wer einen performanten Algo in PHP abbildet auch.

Dann nutze mal Delphi (oder auch VC#) und ASP.Net...
BTW: Und kennst Du Intraweb?

[Hubble]

Zitat von sakura:

Zitat von Hubble:

mäßiges exception handling

Stimmt imo nicht, aber wenn man nicht weiß, wann man try..except und wann try...finally nutzt, dann mag man das so sehen.

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

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

EinFunktionsaufrufmitexception();
}

Es ist nicht möglich diesen übersichtlichen Einzeiler auch in Delhpi zu schreiben.
In Delhpi brauche ich alleine dafür
var
A:TMeinObjektTyp ;
...
A:=TMeinObjektTyp.Create(..);
EinFunktionsaufrufmitexception();
freeannil(A);

Das sind Minimum 3 Zeilen.
Absolutes minimum und falls ich ignoriere, daß die Instanz A in Delphi nicht freigeben wird und in C wird dies automatisch passiert.

@alzaimar ich nehme an du meinst ein garbage collector. Das hat absolut nix damit zu tun. Es gibt keine schnelle Möglichkeit in Delhi so ein Objekt zu erzeugen. Das Ding landet in Delhpi immer auf dem Heap. Und wenn da ein kleiner Fehler passiert weil immer wieder ein Objekt nicht freigegeben wird ist den Speicher bald voll.

Natürlich würde ich auf den Stack keine großen Objekte ablegen welche für die ganze Laufzeit des Programms zur Verfürgung stehen müssen.
Aber sehr oft brauch man diese Objekte eben nur innerhalb dieser Funktion.
Wer diesen Punkt nicht zumindest als sehr ungünstig in Delhpi anerkennt ist für mich diskussionsfäig.

Also braucht man in Delphi zwingend einen try except block, der alle Eventualitäten abhandelt.
In C ist dies in dieser Form nicht notwendig.
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.
Ich weiß das hätte man voher besser coden müssen aber ich hab das Projekt eben so übernommen.

Zitat von sakura:

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

Gut dann zeig mir den Einzeiler.

Zitat von sakura:

Zitat von Hubble:

schlechte Pointernutzung

Wieso? Nur weil der Compiler hin und wieder weiß, womit er es zu tun hat und einem einige Dinge verzeiht... Was ist daran so schlecht.

Ich Programmiere oft Hardwarenah und dann gibts eben einen Pointer zurück.
Ist eventuell Geschmackssache aber in C hab ich alle Möglichkeiten damit in Delhpi nicht.
Sonst versuche ich auch Pointer so wenig wie möglich zu nutzen.

Zitat von sakura:

Zitat von Hubble:

VCL nicht Threadfest

Ist WinForms auch nicht, und das ist richtig neu Da muss man auch aufpassen wer wann welche Control manipulieren darf. Es ist aber, zugegeben, schon viel eleganter gelöst.

Jo

Zitat von sakura:

Zitat von Hubble:

Objekte können nur mit .create erzeugt werden und wieder gelöscht werden

Mit Create löscht man keine Objekte. Aber ich denke mal, Du hast Dich hier beim Schreiben überrannt. Und wie gesagt, wer sich mit Delphi auskennt, der weiß auch, wie man die von Dir aufgeführte Limitierung umgeht. Zugegeben, der Ansatz über den Stack hätte Delphi auch nicht schlecht getan, aber dann wiederum gibt es auch Gegenargumente

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.

Zitat von sakura:

Zitat von Hubble:

Klassen und Ausprogrammierung sind immer getrennt

Das ist die strukturierte Sprache Pascal und einfach eine Glaubenssache. Da kann man nicht diskutieren - so ist es einfach

Grundsätzlich ja, aber:
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.
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.

Beispiel mitten im cpp file :

....
class CZeilenParser
{
public:
CZeilenParser(char* Text){ /*machwasmittext;*/}

int gibtDurchschitt(){return (Max-Min)/2;}
private:
int Min,Max;
};
void NeKlasse::neFunktion(char* geparsterText)
{
CZeilenParser P(geparsterText);
P.gibtDurchschitt();
...

Fertig:
Natürlich geht in Delhpi auch irgendwie. Ist aber umständlicher kostet mehr Zeit und Übersicht.
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 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.

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.

z.B.
eine Map mit 456.456 Nachnamen aus Holland. Die haben alle eine Nummer. Und ich möchte diese Nummer mit Angabe des Namens herausfinden (ohne Datenbank)

C:
map<string,int>Nachnamen; // Die Map
Nachnamen["Van Deutz"]=154568; // Einfügen der Namen
Nachnamen["Van Irgendwer"]=1568; // und noch 456.454 andere Van's ....

//Jetzt mach ich einfach
int NrvonD=Nachnamen["Van Deutz"];
// Und schon hab ich mit der Schnelligktiet von Ln(n) Vergleichen die Nummer von "Van Deutz";

Mir ist keine auch nur annähernd so elegante und schnelle Lösung in Delhpi bekannt.
Natürlich kann ich anstatt des Strings auch ein beliebiges anderes Objekt verwenden.

Zitat von sakura:

Zitat von Hubble:

keine echten Templates

Stimmt, aber kommt Zeit kommen Lösungen. Und da habe ich schon perverse für gesehen

Ja es werden Lösungen kommen. Dieser Punkt ist auch nicht so wichtig.

Zitat von sakura:

Zugegeben, ich liebe Delphi, aber ich diskutiere auch gerne die Für und Wider von Delphi. Also, ich warte auf Deine Antworten

Diskutiere auch gerne und wäre dankbar wenn Ihr mich von Delphi überzeugt. Ich sehe ja auch die Vorteile, diese sind für mich aber nur eingeschränkt nutzbar.
Und egal was passiert ich werden die nächste Zeit noch Delhpi nutzen müssen.

Hubble

[Hubble]

Zitat von Daniel G:

Zitat von Hubble:

Was ich in den letzten Jahren lernen mußte:
In Delphi wird man zum schlampigen Programmieren verleitet.

Und ein Ferrari verleitet mich zum Rasen....

Natürlich verleitet ein Ferrari zum rasen. Das soll er auch auf Formel1 Strecken. Aber als Entwickler wird mach auch mal in die Dörfer geschickt und muß ne Abkürzung durch den Wald nehmen.
Da nehm ich lieber den soliden Golf 1 und komm damit fast überall hin.
Und der rasende allround-Jeep als Programmiersparache ist noch nicht erfunden worden.

Hubble (wenn Methaphern mir in den Kram passen find ich sie klasse)

[tommie-lie]

Zitat von alzaimar:

Wenn Hubble der Ansicht ist, das Objekte auf dem Stack toll und schnell sind, kann ich ihm nicht widersprechen, aber ist nicht ein Zusammenhang mit diesem Speichermodell und den Exploits, die doch gerade versuchen, den Stack zu manipulieren?

Prinzipiell ist es egal, ob ich den Stack oder den Heap eines fremden Prozesses ändere. Was aber richtig ist, ist, daß der Stack überlaufen kann, dann nämlich, wenn das Frame zu klein ist. Idealerweise sollte man dann 'ne Exception um die Ohren geworfen kriegen. Was auch richtig ist, ist, daß man prinzipiell durch Injizierung von Code den Stack durch manipulieren kann, beispielsweise auch den Call-Trace manipulieren. Ob dann meine Objekte auf dem Stack liegen oder ob auf dem Heap, ist egal, wenn ich mal Code injiziert habe, habe ich mehr oder weniger freies Spiel.
Für mich haben daher Objekte auf dem Stack nur einen echten Vorteil: Ich brauche mich nicht um sie zu kümmern.

Zitat von alzaimar:

denn Sicherheit geht immer auf Kosten der Freiheit (Gruss an unsere Innenminister, gell?).

Big Brother Award für Borlands Lebenswerk?

Zitat von alzaimar:

Vermutlich werden wir uns per Options-Dialog unsere eigenen Keywords 'begin','{' etc. zusammenklicken können, so das nun wirklich Keiner mehr meckern kann

Das wäre mal was... Ein selbstprogrammierbarer Lexer für den Compiler. Lass dir das patentieren, sonst macht noch jemand 'ne Raubkopie von der Idee

Zitat von Hubble:

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

'n Bleistift:

Delphi-Quellcode:

begin TSomeType.SomeMethod(someparams: TSomeOtherType): TSomeResult;
type
  TLocalClass = class
    public blubb();
  end;
var
  LocalInstance: TLocalClass;
begin
  LocalInstance := TLocalClass.Create();
  FreeAndNil(LocalInstance);
end;

Das einzige, was bleibt, ist, daß man die Instanz eben nicht auf dem Stack haben kann, aber von der Übersichtlichkeit her macht dieses Beispiel kaum einen Unterschied zu deinem. Plus: Hier ist die Klasse tatsächlich nur innerhalb dieser einen Methode zu sehen, bei dir wäre die Klasse auch für alle nachfolgenden Klassen als Typ sichtbar.

Zitat von Hubble:

Ein mehrfach verwendetes Objekt würde ich nie mitten in den C++ Code hocken.

Das beruhigt mich sehr! Bei deiner ersten Ausführung habe ich schon einen leichten Schock gekriegt.

Zitat von Hubble:

Mir ist keine auch nur annähernd so elegante und schnelle Lösung in Delhpi bekannt.

Hier im Forum schwirrt irgendwo 'ne Hashtable rum, die ist ebenfalls elegant, wenn es darum geht, ein String-indiziertes Array zu basteln.

Zitat von Hubble:

Natürlich kann ich anstatt des Strings auch ein beliebiges anderes Objekt verwenden.

Das kann diese Stringklasse nicht, stimmt, es sei denn man castet alles anch TObject und wieder zurück.

Prinzipiell gebe ich dir vollkommen Recht, die STL ist eine enorme Erleichterung, wenn man sich mal eben 'ne Datenstruktur basteln will, die vollständig typsicher ist (und zwar garantiert typsicher, schon zur compile-time).

[EccoBravo]

HiGi,

und einen wesentliche Punkt habt Ihr in Euren Erklärungen vergessen, der nicht unwesentlich für den späteren Einsatz der Programme ist.

Compilierte Delphi-Programme (wenn nicht .net, oder XML Framework vwerwendet) bringen ihren eigenen vollständigen Kernel mit, dass heisst, sie laufen im wesentlichen unabhängig von allen anderen Betriebssystem- und Programme-Ressourcen deines Computers.

Das ist aus zweierlei Hinsicht wichtig.

1.
Du bist nicht der erfahrenste Programmierer und kannst mit Deinen Programmen den Lauf anderer Programme auf Deinen Computer stören.

2.
Nehme an, auf Du läßt Deine Programme in einem System laufen, auf dem Zertifizierte Software betrieben wird, die in der Medizin oder Bankwesen.
Haben Deine Programme keinen eigenen Kernel, kommst Du in Teufels Küche, weil Du die Zulassungsbedingungen der Zertifizierten Programme verletzt.

--> Also, sei unabhängig, lasse mögliche Fehler in Deinem eigenen Käfig.

Traurig ist nur, daß sich Delphi mit seinen Entwicklungen von diesem Prinzip lösen wird, in dem es mehr auf FrameWorks, .NET und XML setzt.
Hier hätte Delphi sonst eine eigene Sparte und Berechtigung, die von keiner anderen Sprache so schnell streitig gemacht werden kann.

Einen fleißigen Weihnachtsmann

E. B.

[Luckie]

Zitat von EccoBravo:

Compilierte Delphi-Programme (wenn nicht .net, oder XML Framework vwerwendet) bringen ihren eigenen vollständigen Kernel mit, dass heisst, sie laufen im wesentlichen unabhängig von allen anderen Betriebssystem- und Programme-Ressourcen deines Computers.

Bitte was? Ich wußte bisher nicht, dass jedes Delphi Programm ein eigenes Betriebssystem ist. Man kann Delphi Programme so compilieren, dass sie keine weiteren Laufzeitbibliotheken benötigen, wie zum Beispiel VB. Aber das geht mit C/C++ und der MFC auch. Macht nur niemand, weil sie bei Windows automatisch dabei sind.

Zitat:

1.
Du bist nicht der erfahrenste Programmierer und kannst mit Deinen Programmen den Lauf anderer Programme auf Deinen Computer stören.

Ich verstehe kein Wort. Unter 32-Bit Windows und speziell unter NT ff. sind die Speicherbereiche von Prozessen sowieso gegeneinander abgesichert. Greife ich aus Unwissenheit versehentlich auf einen ungültigen Adressbereich zu, strürzt mein Programm ab und das war es auch schon.

Zitat:

2.
Nehme an, auf Du läßt Deine Programme in einem System laufen, auf dem Zertifizierte Software betrieben wird, die in der Medizin oder Bankwesen.
Haben Deine Programme keinen eigenen Kernel, kommst Du in Teufels Küche, weil Du die Zulassungsbedingungen der Zertifizierten Programme verletzt.

???

[dfried]

Zitat von EccoBravo:

Traurig ist nur, daß sich Delphi mit seinen Entwicklungen von diesem Prinzip lösen wird, in dem es mehr auf FrameWorks, .NET und XML setzt.

Was hat das mit XML zu tun?

[tommie-lie]

Zitat von EccoBravo:

Compilierte Delphi-Programme (wenn nicht .net, oder XML Framework vwerwendet) bringen ihren eigenen vollständigen Kernel mit, dass heisst, sie laufen im wesentlichen unabhängig von allen anderen Betriebssystem- und Programme-Ressourcen deines Computers.

YMMD!
Das ist das Beste, was ich in diesem Fred lese.

Zitat von EccoBravo:

Du bist nicht der erfahrenste Programmierer und kannst mit Deinen Programmen den Lauf anderer Programme auf Deinen Computer stören.

Frag mal Nico, Olli, Michael, uall, BenBE oder mich. Die können dir alle zeigen, wie du mit einem Delphi-Programm ein anderes manipulierst.

Zitat von EccoBravo:

Nehme an, auf Du läßt Deine Programme in einem System laufen, auf dem Zertifizierte Software betrieben wird, die in der Medizin oder Bankwesen.
Haben Deine Programme keinen eigenen Kernel, kommst Du in Teufels Küche, weil Du die Zulassungsbedingungen der Zertifizierten Programme verletzt.

ROFL. Als ob es niemanden stören würde, wenn du auf einem Bankrechner ein nicht-zertifiziertes Programm mit einem eigenen Kernel (das ist ja das beste *kicher*) laufen lassen würdest. Dann besorgst du dir halt ein passendes Zertifikat für dein Delphi-Programm, Zertifizierungsstellen gibt's beim Staat.


"Programme mit eigenem Kernel"... *sichgarnichtmehreinkrieg*

[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.