Vorteile von Delphi

[cruso]

Zitat:

Zitat von mumu

bei VB musste man immer bestimmte dlls mitliefern, damit die applikation lauffähig ist. delphi hingegegen kompiliert alles in die exe. oder was meint ihr?

Das stimmt schon allerdings werden so, wenn man nicht besonders aufpasst Programme größer als sie sein müssten! Da müsste eine Optimierung eingebaut werden... das würde ich mir von Delphi 2006 wünschen (das und vieles andere z.B. ein paar Fehler weniger).

MfG
Cruso

[tommie-lie]

Zitat:

Zitat von noidic

Das stimmt so nicht, es sind zwei verschiedene Sprachen mit teilweise disjunktem Funktionsumfang. C++ ist auf Basis von C entwicklet worde, ist aber keinesfalls eine Erweiterung von C, damit ist C auch keine Untermenge von C++.

C++ bestitzt meines Wissens nach auch sämtliche Sprachfeatures von C, auch die Standard Library von C ist immer noch Teil des C++-Standards (natürlich aufgebohrt durch die STL).
Legales C ist AFAIK immer auch legales C++, was umgekehrt nicht der Fall ist.

[Tubos]

Zitat:

Legales C ist AFAIK immer auch legales C++

Nicht "immer".
Folgender C-Code lässt sich als C++ Code nicht kompilieren:

Code:

int new=0;

new ist ein Schlüsselwort in C++, aber nicht in C.

[tommie-lie]

Zitat:

Zitat von Tubos

new ist ein Schlüsselwort in C++, aber nicht in C.

Da ist was dran... Gibt es noch weitere "richtige" Unterschiede, auf die ich nicht gekommen bin (man sollte seine Variablen ohnehin nicht "new" und "delete" nennen)?
Antwort per PN, da das in diesem Fred offtopic ist.

[malo]

Zitat:

Zitat von mumu

bei VB musste man immer bestimmte dlls mitliefern, damit die applikation lauffähig ist. delphi hingegegen kompiliert alles in die exe. oder was meint ihr?

Kann man in Delphi jedenfalls einstellen. Und ich bin mir sicher, dass es in VB auch eine ähnliche Einstellung dazu gibt ;)

Zitat:

Zitat von Tubos

Folgender C-Code lässt sich als C++ Code nicht kompilieren:

Code:

int new=0;

new ist ein Schlüsselwort in C++, aber nicht in C.

Wie du selbst geschrieben hast, ist new in C++ ein Schlüsselwort, und in C nicht. Das Problem dabei ist aber, dass C++ deutlich mehr Sprachfeatures hat als C. Und viele Sprachfeatures verlangen einfach ein Schlüsselwort (jedenfalls, wenn man sauberen Code haben will, meiner Meinung nach). Allerdings wurde in C++ auch versucht, so viele verschiedene Schlüsselwörter wie möglich einzubauen. So werden beispielsweise einige Schlüsselwörter in verschiedenen Situationen verwendet, wie beispielsweise auch das Schlüsselwort new. Auch hier kann man drüber streiten, ob das ein Segen oder ein Fluch ist... aber es ist halt so. Dadurch kann es auch gelegentlich zwischen den beiden Sprachen knallen, wenn so etwas passiert ;)

Daher an alle C-Programmierer: Informiert euch vorher über die C++-Schlüsselwörter, und versucht die bitte so weit wie möglich zu verhindern. Einfach, damit die eventuelle Kompatiblität zu C++ bestehen bleibt :)

Zitat:

Zitat von pajofego

ich meinte, das die Nichtunterscheidung mich nervt...aber zum Glück ist das Geschmackssache...

Stimmt, zum Glück ist das Geschmackssache. Ich wär nämlich für Case-Sensetivity in Delphi extrem böse :evil:
Es kann nämlich auch gelegentlich kommen, dass man Fehler sucht, und die nicht findet, und später erfährt, dass das an Groß/Kleinschreibungs-Problemen liegt. Sowas hatte ich in C++ mal. Extrem nervig :(
Ich bin außerdem auch froh, wenn ich mir die Schreibweise von bestehenden Methoden/Properties/Funktionen/Konstanten etc. selbst aussuchen kann :) Auch wenn meine Schreibweise sich kaum in einem Projekt ändert, aber sie unterscheidet sich gelegentlich von der Borland-Schreibweise...
Übrigens, lieg ich richtig, dass C++ direkt keine Properties unterstützt (außer vielleicht speziell bei Borland-C++ mit __property [oder wie ging das noch?])? Nur so als Zwischenfrage nebenbei, ich glaube mich nämlich entfernt an sowas erinnern zu können...

[merlin17]

http://www.marcocantu.com/papers/ooplang.htm

alt aber sicherlich tw. immer noch lesenswert;


:-) thomas

[jbg]

Zitat:

Zitat von cruso

Das stimmt schon allerdings werden so, wenn man nicht besonders aufpasst Programme größer als sie sein müssten! Da müsste eine Optimierung eingebaut werden... das würde ich mir von Delphi 2006 wünschen (das und vieles andere z.B. ein paar Fehler weniger).

Was habt ihr immer mit der Dateigröße? Übrigens die Optimierung gibt es schon seit TurboPascal und sie nennt sich Smart Linking. Dabei werden alle nicht benutzen Symbole komplett aus dem Kompilat entfernt bzw. gar nicht erst aufgenommen.
Das ein leeres Formular in Delphi bereits 300-400 KB Exe-Dateien erzeugt liegt darin, dass der Compiler ja nicht ahnen kann, dass mann keine weiteren Features braucht. Und wenn das Objekt TForm, TControl, TWinControl, TApplication und die halbe Classes Unit benötigt werden, kann der Compiler sie nicht entfernen. Natürlich braucht man da nicht alles, aber if-Anweisungen kann der Compiler halt nicht zur Kompilierzeit auswerten, wenn sie nicht gerade aus einem konstanten Ausdruck bestehen. Deswegen kommt eben auch alles mit in die Exe, das zur Laufzeit nicht ausgeführt wird, aber zur Kompilierzeit "referenziert/aufgerufen" wird.

Und wenn wir schon bei Dateigrößen sind. Schon mal ein VC++ Programm statisch gegen die MSVCRT und MFC gelinkt? Da werden dir die 400 KB von Delphi wie ein Segen vorkommen.

[pajofego]

Wo kann ich eine Featureliste für Delphi 2006 sehen?

Wird es statische Klassenvariablen geben bzw. gibt es diese schon? Operatorüberladung auch für nativen Code oder nur wieder für managed OP?

[Hubble]

Schöne Diskussion. Werde mich darum mal einklinken und ein paar neue Punkte liefern.

Ich bin seit ca. 3-4 Jahren gezwungen teilweise in Delphi 6.0 zu coden.
Komme von Visual C++6.0 (ja ich weiß da gibts auch einige himmelschreiende Probleme und Haken) aber
aus meiner Sicht ist Delphi eine Katastrophe.

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

Bevor jemand in Delphi eine neue Klasse erzeugt macht er sich lieber 3 globale Variablen.
Und mit so einem alten Müll muß ich mich rumschlagen und schwupp sind's 100 globale Variablen.
Alles wird unübersichtlich.
Und die VCL ist nur für procedurale Vorgehensweise aus dem letzten Jahrhundert geeignet.


Beispiel:
Ich schreibe mir eine kleine Hilfsklasse welche Zugriffe sperrt.

C:

Delphi-Quellcode:

class BLABLA
{
private:
   BLABLA(){sperrewas();}
   ~BLABLA(){gibwiederFrei();}
   ...
};

// jetzt kann ich an jeder Stelle einfach eine Instanz erzeugen

int neFunktion()
{
   BLABLA bla();
   ..
}
//  eine Zeile und alles ist gut. Die Klasse wird erzeugt, macht alles und
//  am Ende der Funktion is se wieder wech

das gleiche in Delphi:

Delphi-Quellcode:

type
BLABLA = class
  ...


// Soweit OK aber dann:In delphi muß ich erst mal var schreiben dann die Instanz erzeugen,
// initialiseiren dann wieder löschen und zu allem Überfluß hockt das
// blöde Teil nicht auf dem schnellen Stack sondern auf dem lahmen heap

procedure neFunktionInDelphi();
var
   bla:BLABLA;
begin
   bla:=BLABLA.create;
   ...

   FreeAndNil(bla);
end;

// das wars? Nein denn was is wenn ne Exception ausgelöst wird also

procedure neFunktionindelphi();
var
   bla:BLABLA;
begin
   try
     bla:=BLABLA.create;
   ...

   except
   finally
     FreeAndNil(bla);
   end;
end;

Damit hätten wir 7 unübersichtliche Zeilen in Delphi und 1 Zeile in C++.
Und falls die Exception weiter geworfen werden muß, dann kommen noch ein paar Zeilen dazu.
In Delphi muß man einfach in jeder Routine Exceptions fangen, falls auch nur ein
Objekt benutzt wird, und diese Exception weiterschmeißen.
Dies ist das krasseste Problem und meine persönliches Hauptproblem.


Hat jemand mal versucht mit der VCL in verschiedenen Threads zu arbeiten?
Is nich einfach, wenns überhaupt geht. Man muß immer drauf achten zyklisch ein ProzessMessages
auszuführen sonst steht das ganze Programm 100 Jahre falls eine VCL Event nicht beendet wird.
Wird dann ein zweites ausgelöst, dann ist das erste Event unterbrochen bis das zweite fertig ist.

Also: Man drückt auf Button 1 und bevor dieser fertig ist auf Button 2. Grande Problema in VCL.
Natürlich gibt es da einen Workaround, ist aber sehr umständlich und man muß fast alles umstellen.

Es gibt keine STL:(OK wurde schon erwähnt aber ist sehr wichtig für mich)
Dieses geniale Tool um mal eben eine Map,Liste,Vektor oder seit einigen Jahren auch einen Hash Table zu erzeugen steht in Dephi einfach nicht zur Verfügung.

Habt Ihr schon mal mit Komponenten in Delphi geschafft. Is echt supi. Alles schnell und schön.
Aber wehe es gibt ein Update und die Entwickler müssen mit verschiedenen Versionen arbeiten.
Ist schlicht nicht möglich.

Dazu kommt eine Projektverwaltung in Delphi 6 die mich zum heulen bringt.

Des weiteren folgen noch so undurchsichtige Sachen wie end mit Punkt mit Stichpunkt oder ohne was.
Je nachdem obs gerade am Ende der Seite oder vor einem else Zweig auftaucht.
Oder die Sache mit den Pointern.
Jeder der auch nur einmal in Delphi mit Pointern umgehen mußte und den Vergleich
zu C/C++ kennt verflucht dieses im Nachhinein in Pascal eingeführete Notkonstrukt.

Nartürlich hats in Delphi auch aus meiner Sicht gute Dinge.
z.B. Ein = Zeichen für den Vergleich (vermeidet viele Fehler), ein Case Statement ohne break.
Die ganze Interface Geschichte ist in Delphi gut gelöst während man sich in C mit leicht in den
Headern verirrt.


Mein Fazit welches ich nach mehreren Jahren gezogen habe.

Für einen kleinen Dreizeiler mit eine paar Dialogen ist Delphi genial einfach.
Um aber auch nur ansatzweise komplexe Stukturen zu erzeugen, eventuell auch noch mit mehreren Leuten,
ist das das schlechteste Mittel der Wahl.

Hubble

P.S. Sollte nun jemand glauben, daß ich mich zum Delhpihasser emtwickelt habe, hat er Recht.

[tommie-lie]

Zitat:

Zitat von Hubble

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

Mit dieser Aussage hast du dir in diesem Forum jetzt circa 16310 Feinde geschaffen :mrgreen:

Zitat:

Zitat von Hubble

Und die VCL ist nur für procedurale Vorgehensweise aus dem letzten Jahrhundert geeignet.

Sie erschwert es, zum Beispiel auch wegen der TApplication-Klasse, aber die VCL *ist* objektorientiert, es ist ungewohnt mit ihr prozedural zu arbeiten.

Zitat:

Zitat von Hubble

Soweit OK aber dann:In delphi muß ich erst mal var schreiben dann die Instanz erzeugen,
initialiseiren dann wieder löschen und zu allem Überfluß hockt das
blöde Teil nicht auf dem schnellen Stack sondern auf dem lahmen heap

Schnell/Lahm? Wenn der Speicher einmal allokiert ist, ist mir das auch egal.
Außerdem ist die Geschichte mit "var" nur eine Syntaxeigenschaft von Pascal. Du legst da übrigens eine lokale Variable an, soviel zu globalen Variablen.

Zitat:

Zitat von Hubble

das wars? Nein denn was is wenn ne Exception ausgelöst wird

Was, wenn in deinem C++-Beispiel eine Exception ausgelöst wird?

Zitat:

Zitat von Hubble

Damit hätten wir 7 unübersichtliche Zeilen in Delphi und 1 Zeile in C++.
Und falls die Exception weiter geworfen werden muß, dann kommen noch ein paar Zeilen dazu.
In Delphi muß man einfach in jeder Routine Exceptions fangen, falls auch nur ein
Objekt benutzt wird, und diese Exception weiterschmeißen.

Exceptions werden auch in Delphi bis zur nächstinnersten Exception-Behandlung weitergereicht.

Zitat:

Zitat von Hubble

Also: Man drückt auf Button 1 und bevor dieser fertig ist auf Button 2. Grande Problema in VCL.
Natürlich gibt es da einen Workaround, ist aber sehr umständlich und man muß fast alles umstellen.

Ja, ziemlich eklig, ist aber in C++ prinzipiell nicht anders, wenn du eine Bibliothek zum Anzeigen von grafischen Controls benutzt, die nicht multi-threaded ist. Oder du spaltest dir gleich beim Drücken von Button1 ein ganz sauber einen Thread ab und lässt den werkeln, dann sollte auch Button2 reagieren, und wenn du dort selbiges machst, laufen am Ende zwei Threads. Dabei sind selbstveränstlich die üblichen Vorkehrungen gegen Race Conditions und anderweitige Synchronisierungprobleme zu treffen.

Zitat:

Zitat von Hubble

Habt Ihr schon mal mit Komponenten in Delphi geschafft. Is echt supi. Alles schnell und schön.
Aber wehe es gibt ein Update und die Entwickler müssen mit verschiedenen Versionen arbeiten.
Ist schlicht nicht möglich.

Inwiefern? Wenn sich die ABI ändert, bist du unter C++ genauso verloren, wenn deine Bibliothek lediglich als binary-only vorliegt.

Zitat:

Zitat von Hubble

Des weiteren folgen noch so undurchsichtige Sachen wie end mit Punkt mit Stichpunkt oder ohne was.

Ohne was?!? Mit Punkt gibt's nur einmal am Ende einer Unit, "end." beendet eine logische Pascal-Einheit. Mit Semikolon ist end das Gegenstück zu begin, "begin .. end;" ist als "{ .. }" zu sehen, wahlweise auch Brace mit Semikolon dahinter ("{ .. };") ;-)

[quote="Hubble"]Oder die Sache mit den Pointern.
Jeder der auch nur einmal in Delphi mit Pointern umgehen mußte und den Vergleich
zu C/C++ kennt verflucht dieses im Nachhinein in Pascal eingeführete Notkonstrukt.[quote]Wenn du auf die implizite Dereferenzierung hinaus willst: ACK!

Zitat:

Zitat von Hubble

ein Case Statement ohne break.

Ich hätte nie gedacht, daß ich ein Case-Statement ohne break mal brauchen würde, aber kürzlich hat es einen C-Code tatsächlich kürzer gemacht, die breaks in den Zweigen wegzulassen.