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.

[Binärbaum]

Zitat:

Zitat von Hubble

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

Ach wirklich?
Was ist z.B. bei C, wo man (unter Umständen) z.B. in der main-Funktion am Ende das "return 0;" als letzte Anweisung weglassen kann, weil sich die meisten Compiler schon denken, dass es da hin soll. Da gibt es auch noch etliche andere Beispiele, wo man nicht ganz sauber programmieren muss und das Programm trotzdem läuft, weil der Compiler implizit irgendwelche Dinge annimmt, die so eigentlich gar nicht im Quelltext stehen. Da wird man doch zum "schlampigen" Programmieren geradezu animiert. ;)

[Hubble]

Oh weh, das ging ja schnell.

Schönen Gruß an meine 16310 Feinde.
Bin im Moment beschäftigt, werde mich aber dazu äußern.

Hubble

[Der_Unwissende]

16309 maximal :mrgreen:

Stimme dir zwar nicht wirklich zu, aber auch nicht der Meinung der anderen hier (oh man, habe ich jetzt eine eigene Meinung? Muss ich ändern).
Ihr solltet alle mal weniger pauschalisieren, man kann genauso gut in Delphi wie in C/C++, Java, Haskell, wasWeißIch super unsauber programmieren. Das alles hat wenig mit dem Thread und natürlich auch wenig mit der Sprache an sich zu tun. Oder denkt ihr irgendwer kam mal auf die Idee sich eine Sprache auszudenken, die Krypto heißt und so kryptisch ist, dass man garnicht sauber und übersichtlich mit der arbeiten kann?
Und falls ja, habt ihr dann auch eine Idee warum es keine solche Sprache unter den so gern genannten / verwendeten? Sprachen geschafft hat?

Also ich muss sagen, dass man in C/C++ einige Konstrukte hat, die man in Delphi nicht so einzeilig hässlich nachbilden kann, aber die sind einfach super konstruiert. Mag sein das ein paar Hobbyprogrammierer denken, dass so etwas ihren Code individueller macht, aber wenn Code verifiziert werden muss oder erweitert oder verkauft oder oder oder, dann hält man sich auch in der C Welt an guten Stil.
Andersherum garantiert mir niemand, dass mein Delphi Programm wirklich sauber ist. Schon diese Funktion in einer Funktion Zeugs finde ich persönlich so super unübersichtlich (wo genau fängt jetzt eigentlich die Funktion an?), dazu kommt noch, dass ich meine Variablen deklariere bevor ich sie benutze (natürlich in C auch der Fall, aber nicht mehr in C++). Das sind natürlich imperative Überbleibsel um die ich nicht rumkomme. Macht für mich den Code nicht immer lesbarer. Das man Exceptions nicht markieren kann (throws .... á la Java) wäre auch nett und natürlich eine Prüfung ob dieser Fehler behandelt wird (ich kann in Delphi einfach übersehen).

Es gibt wirklich gute (konstruierte) Beispiele, warum C/C++ oder Delphi super schlechten Code haben, den kein Schwein lesen kann, aber wenn man sich etwas bemüht hat jede Programmiersprache das Potenzial sauberen, strukturierten und guten Code zu liefern. Keine Sprache macht einen Entwickler besser oder schlechter. Alle bieten den relativ gleichen Funktionsumfang, die Wahl (und das wurde schon oft genug gesagt) hängt doch eher von persönlichen Referenzen ab.
Und bitte hört endlich mit dem entweder oder auf, es gibt hier unter den 16310 Leuten bestimmt genug, die sowohl Delphi als auch C/C++/C#/Java/HastDuNichtGesehen benutzen und auch wissen wann und warum sie welche der Sprachen nehmen oder eben nicht. Und insbesondere die, der 16310 die auch ihr Geld damit verdienen (nicht alle aber sicherlich die Meisten) sind auch in der Lage sauberen Code zu erzeugen (Wofür gibt es denn Konventionen?)

Gruß Der Unwissende

[Sanchez]

Hallo zusammen,

Zitat:

Zitat von Hubble

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.

Ja, schon des öfteren. Solange du den Hauptthread nich völlig auslastest, brauchst du kein ProcessMessages.
In einem seperaten Thread hat so ein Aufruf überhaupt nix verloren. Vermutlich meinst du damit,
dass synchroninisierte Aufrufe um auf die VCL zuzugreifen den Thread hängen lassen, solange der Hauptthread
im Stress ist. Das ist dann aber IMHO ein Design-Fehler. Wenn ich schon mit Threads arbeite, dann lasse ich den
Hauptthread nicht schuften, sondern einen eigenen Thread.

grüße, daniel

[Hubble]

Zitat:

Zitat von Hubble

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

Ziehe diesen Satz von mir vollständig zurück!

Zitat:

Zitat von 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:

Ich habe nicht bahauptet, daß jeder in Delphi schlampig programmiert sondern das man nur verleitet wird schlecht zu programmieren. In C++ fällt es mir wesentlich leichter Ordnung zu halten.
Die Delphi Projekte an denen ich mirarbeite oder mitgearbeitet habe waren allesamt schlecht durchdacht und unsauber implementiert. Weils eben so einfach ist mal nen neuen Grid mit Schnickschack in den Dialog reinzuhängen der dann auch die Daten darin speichert.
In C++ schreib ich mir immer erst ein Objekt welches die Daten hält und schau dann weiter.
In Delphi kommt erst die Graphik. Ich gebe unverholen zu, daß Delphi VC++ in Sachen Graphik weit überlegen ist, aber das ist auch oft das Problem. Der Chef sieht nen Dilaog und denkt "Ah is ja schon fertig" und schon wird noch mehr gepfuscht.

Zitat:

Zitat von tommie-lie

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.

Ich versuche immer möglichst viel im Stack abzulegen, der is schneller als der heap ist einfacher zu Verwalten vom Betriebssystem.

Zitat:

Zitat von tommie-lie

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?

In C++ wird bei allen auf dem Stack erzeugten Objekten der Destruktor ausgelöst und die Exception automatisch weitergeworfen. (Wie in diesem Beispiel)
Macht man das gleiche in Delphi ohne try except , dann würde das Objekt nicht gelöscht und immer mehr Speicherlöscher entstehen.

Zitat:

Zitat von tommie-lie

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.

Ja das stimmt, aber in Delphi werden alle mit create erzeugten Objekt dann nicht automatisch gelöscht sondern schwirren weiterhin irgendwo im Speicher rum.
Hatte bisher nie Probleme mit Exceptions. Erst seit dem in Delphi code hab ich Probs mit Expetions.

Zitat:

Zitat von tommie-lie

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.

Korrekt

Zitat:

Zitat von tommie-lie

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.

Kein Ahnung was eine ABI ist, auf jeden Fall gibts hier immer Ärger wenn mal wieder neue Versionen von den ganzen Komponenten gibt. Will man dann eine alte Version des Programms damit erstellen dann knallts.
Natürlich gibt's in VC weniger Möglichkeiten und ich habe damals weniger Komponenten in dieser Art verwendet, aber die Thematik ist mit Delpho 6 nicht gut gelöst. Ich hoffe die Neuen Versionen beheben solche Probleme.
Außerdem dauerts Stunden oder Tage bis man einen neuen Entwicklerrechner mit allen Komponenten zu laufen gebracht hat.

Hubble

[alzaimar]

Hubble: Deine Meinung ist fundiert, aber die Argumente sind ungenau und nicht zuende gedacht (imho). Aber so ist das: 2 Leute, 2 Meinungen. So, jetzt aber, Du Schuft :mrgreen: :
1. Mit Delphi schlampig programmieren.
Absolut korrekt. Aber: It's not a bug, it's a feature. Ich kann mit Delphi sehr schnell ein funktionierendes und stabiles Programm zusammenklicken. Wirklich sehr schnell. Neulich habe ich einen Reportgenerator mit 1000 Bells&Whistles in 30 Minuten zusammen geklickt. Auf der anderen Seite wird man in Delphi auch absolut katastrophale Frickelsoftware erstellen können, die nich nicht mal das 'S' in 'Software' wert ist. Ist das eine Schwäche von Delphi? Nun, da kann man geteilter Meinung sein. Programmiersprachen, mit denen man zwangsweise stabile Programme schreibt, sind natürlich für Anfänger und Frickelchaoten die richtige Wahl, aber nicht für mich, denn ich programmiere seit 30 Jahren.

Deine Argumentation impliziert, das ein DBMS eine Haufen Sch*** ist und SQL die schlimmste und unperformanteste DB-Sprache überhaupt. Warum? Weil ich mit SQL so dermassen langsame und grottenschlechte Datenbanken entwickeln kann, das jedes ordendliche Gericht die Todesstrafe (oder zumindest lebenslange Verachtung) verhängen würde. Ich hab hier gerade einen Studenten der kennt sich mit MySQL aus und hat eine MSSQL-DB hingezimmert, die mich wirklich verzweifeln lässt. "Man kann mit SQL ganz leicht hochperformante, elegante, robuste und leicht wartbare DB erstellen." man kann aber auch den größten Mist hinzimmern, den man sich vorstellen kan.

Es kommt nicht auf das Werkzeug an, sondern auf den Anwender. Die besten Küchenmesser (ich bin auch Koch) sind sauscharf und man kann sich damit mal eben den Arm abschnippeln, ohne das man es merkt (nun ja). Sie sind aus weichem Stahl, sodass die Klinge unbrauchbar wird, wenn man damit das falsche Material bearbeitet. Ist damit das Messer Schrott? Nein! Der Anwender! Denn weichen Stahl kann ich am schärfsten schärfen. Idiotensichere Messer sind zwar idiotensicher, aber dafür kannst Du sie nach 2 Monaten wegschmeissen.

Zurück zu Delphi: Gerade die Freiheit, zu frickeln, globale Variablen zu verwenden (was ist daran verwerflich? soll ich eine dämliche Klasse für eine globale Variable verwenden?), Assembler einzuschleusen etc. etc. etc. macht Delphi doch zu einem professionellen Tool, so wie eine SQL-DBMS oder ein richtig gutes Küchenmesser. Ich habe die Wahl! Hurra! Ich bin autark! Frei in der Wahl der Waffeln! Bei Java und den anderen reinen OOPS bin ich eingezwängt und muss zeitaufwändig auch die kleinesten Frickeltools 'designen', :kotz: .

Die besten Werkzeuge lassen dem Anwender die größte Freiheit!

2. Die vielen Komponenten
Ich hatte früher 100+ Komponentensammlungen installiert und fand mich richtig cool. Bis ich auf D4 wechseln musste. Dann war Schluss. Ich verwende eine 2 Sammlungen, aber die Richtigen. Ähnliches für C++ (VC++) kosten das 10 fache und sind dann nur halb so gut, ehrlich.
Wie gesagt, ich muss die vielen Features nicht verwenden, aber ich kann. Ich kenne andere IDE nicht, aber die Komponentensammlungen sind nicht so verbreitet, oder? Mit .NET kann Alles anders werden (.NET wurde übrigens vom VCL-Erfinder Anders Heijlsberg entwickelt. Der wurde *gerade wegen der Eleganz der VCL* von Microsoft abgekauft, das nur mal so am Rande).

Ich glaube, der VCL-Ansatz (eine ordendlich durchstrukturierte Klassenbibliothek) macht Code erst stabil. Was Du meinst, sind die 'SysUtils' etc. Units, die eben Prozeduren anbieten. Mein Gott, muss Alles gleich OO sein?

Noch was zu OOP: "Die reine Leere, ist meistens die reine Lehre"

[Sanchez]

Zitat:

Zitat von Hubble

Außerdem dauerts Stunden oder Tage bis man einen neuen Entwicklerrechner mit allen Komponenten zu laufen gebracht hat.

Diese Zeit kann man sich allerdings verkürzen indem man einmalig etwas Zeit investiert und sich ein eigenes Package mit allen benötigten Komponenten basteöt. Das macht allerdings wieder Mehraufwand bei Versionswechsel der Komponenten.

[Hubble]

@alle

Wollte Euch nicht Euer Delphi nehmen sondern nur mal die echten Probs ansprechen.
Mir ist egal ob ich begin oder { schreibe.
Selbst an die komische Syntax beim else mit und ohne Strichpunkt kann ich mich gewöhnen.

Da gibt andere Probs:
mäßiges exception handling
schlechte Pointernutzung
VCL nicht Threadfest
Objekte können nur mit .create erzeugt werden und wieder gelöscht werden
Klassen und Ausprogrammierung sind immer getrennt
nicht ausgereifte Projektverwaltung
keine STL
keine echten Templates

Das sind die Fakts die mir in Summe Delphi verleidet haben. Denn anfangs war ich durchaus begeistert von Delphi weil alles zu schnell und einfach ging. Aber mit der Zeit...

Hubble

[sakura]

Zitat:

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.

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

Zitat:

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.

Zitat:

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.

Zitat:

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 ;)

Zitat:

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 ;)

Zitat:

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.

Zitat:

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.

Zitat:

Zitat von Hubble

keine echten Templates

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

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

...:cat:...

[alzaimar]

Es *gibt* ja IDE die das eine oder Andere besser machen z.B. Templates, oder wenigstens einen Präprozessor, aber automatische Objektfreigabe ist ja wohl der größte Dreck, den ich kenne. Eine Java Applikation eines Praktikanten ist gerade deshalb nicht zu gebrauchen. Und das einzige Projekt, das ich nicht bugfrei bekomme, arbeitet mit automatischer Objektfreigabe.

Trotzdem sind die Argumente durchaus eine Überlegung wert, aber leider fängst Du mit der Sprache Delphi an und hörst dann mit der Borland IDE auf. Imho sind z.B. Templates keine Spracheigenschaft, sondern doch ehere eine Eigenschaft eines Präprozessors, oder?

Welche IDE ist denn nun wirklich Besser? Ich steig ja gerne um, zumal D2005 wohl etwas wackelig daher kommt und D2006 die Marktreife noch nicht bewiesen hat....

[Hubble]

So langsam wirds stressig. Ich glaub das nächste mal stell ich mich in unser Statdion und schweke die Bayern-Fahne, da gibts nicht so viel Haue. ;)
Mache erst mal Pause.

Cu Hubble

[malo]

Zitat:

Zitat von Hubble

mäßiges exception handling

Bitte genauer beschreiben, ich weiß grad nicht, was du meinst.

Zitat:

schlechte Pointernutzung

In C++, ja :mrgreen:

Zitat:

VCL nicht Threadfest

Zitat:

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

Das find ich auch gut. Ich hab noch nie etwas anderes gebraucht.

Zitat:

Klassen und Ausprogrammierung sind immer getrennt

It's not a bug, it's a feature. Das ist eine der Vorteile in Delphi.

Zitat:

nicht ausgereifte Projektverwaltung

Redest du gerade von der IDE oder von der Sprache?


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

Was ich damit sagen will: Sowohl in Delphi, als auch in C++ wird man irgendwie zur schlampigen Programmierung verleitet. Aber das kann man weniger der Sprache zuordnen, sondern eher den Entwickler selbst. Denn der entscheidet ja, wie der Code aussehen soll. Und wenn er schlampig programmiert, ist das nicht die Schuld der Sprache, sondern die des Entwicklers. Und im Endeffekt ist Vieles auch noch eine Geschmacks- bzw. Gewohnheitsfrage... ;)

[supermuckl]

Zitat:

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

und genau das zeichnet delphi positiv aus, da man damit produktiver sein kann.

[Daniel Schuhmann]

Zitat:

Zitat von Hubble

In C++ schreib ich mir immer erst ein Objekt welches die Daten hält und schau dann weiter.
In Delphi kommt erst die Graphik. Ich gebe unverholen zu, daß Delphi VC++ in Sachen Graphik weit überlegen ist, aber das ist auch oft das Problem. Der Chef sieht nen Dilaog und denkt "Ah is ja schon fertig" und schon wird noch mehr gepfuscht.

Das ist dann aber wohl eher ein Kommunikationsproblem als ein Problem der Programmiersprache bzw der IDE. Ich finde die Reihenfolge Oberfläche bauen und dann ausprogrammieren wesentlich intuitiver.

[tommie-lie]

Zitat:

Zitat von Hubble

Ich habe nicht bahauptet, daß jeder in Delphi schlampig programmiert sondern das man nur verleitet wird schlecht zu programmieren.

Ich weiß, was du behauptet hast. Dennoch sehen es wohl die wenigsten gerne, wenn "ihre" Sprache als eine Sprache bezeichnet wird, die Unordnung anzieht ;-)

Zitat:

Zitat von Hubble

In C++ fällt es mir wesentlich leichter Ordnung zu halten.

Meine Meinung als Programmierer, der sich einbildet, beide Sprachen gut zu können (der aber trotzdem C++ sympathischer findet): Bei C++ ist es auch nötiger, Ordnung zu halten.

Zitat:

Zitat von Hubble

Die Delphi Projekte an denen ich mirarbeite oder mitgearbeitet habe waren allesamt schlecht durchdacht und unsauber implementiert. Weils eben so einfach ist mal nen neuen Grid mit Schnickschack in den Dialog reinzuhängen der dann auch die Daten darin speichert.

Das ist in der Tat ein Problem.

Zitat:

Zitat von Hubble

Ich versuche immer möglichst viel im Stack abzulegen, der is schneller als der heap ist einfacher zu Verwalten vom Betriebssystem.

Der Stack ist beim Zugriff weder schneller noch langsamer, iss ja auch nur Speicher, der die gleichen Zugriffszeiten hat wie der Chip daneben ;-)
Wie gesagt, die Allokierung mag beim Stack tatsächlich größer sein, ich würde den STack aber nicht für etwas größeres missbrauchen.Was mir an den Objekten auf dem Stack gefällt, ist, daß ich einfach mit arbeiten kann, ohne mir Gedanken zu machen. Ein wenn man sich einen Huafen Hilfsklassen deklariert hat, verwaltet man sich in Delphi erstmal einen Wolf. In C++ schreibt man einfach die Variable hin und gut iss, das ist sehr angenehm.

Zitat:

Zitat von Hubble

Ja das stimmt, aber in Delphi werden alle mit create erzeugten Objekt dann nicht automatisch gelöscht sondern schwirren weiterhin irgendwo im Speicher rum.

Stimmt, jetzt, wo du's sagst... Steht in der Hilfe anders, im Quellcode ist es aber so (das dürfte der Unterschied zwischen Theorie und Praxis sein ;-)). Sakura, ein paar tröstende Worte von dir dazu?

Zitat:

Zitat von Hubble

Kein Ahnung was eine ABI ist

Application Binary Interface. In Delphi sind dir vielleicht DCUs aufgefallen, das sind vorkompilierte Pascal-Dateien. Kommt Borland auf die Idee das Binärinterface dieser Dateien zu ändern, kannst du eine solche DCU nicht mehr mit zur nächsten Compilerversion mitnehmen. Ähnlich sieht es mit C++ aus. Als mit dem G++ 4.0 eine neue ABI eingeführt wurde, durften C++-Bibliotheken neu kompiliert werden, weil die Datenstrukturen schlichtweg nicht mehr kompatibel waren.

Zitat:

Zitat von Hubble

Will man dann eine alte Version des Programms damit erstellen dann knallts.

Ja aber inwiefern knallt es denn? Was sind die Effekte? Fehlermeldungen? Mir fällt auf Anhieb nichts diesbezüglich ein, deswegen frage ich.

Zitat:

Zitat von alzaimar

Zurück zu Delphi: Gerade die Freiheit, zu frickeln, globale Variablen zu verwenden (was ist daran verwerflich? soll ich eine dämliche Klasse für eine globale Variable verwenden?), Assembler einzuschleusen etc. etc. etc. macht Delphi doch zu einem professionellen Tool, so wie eine SQL-DBMS oder ein richtig gutes Küchenmesser. Ich habe die Wahl! Hurra! Ich bin autark! Frei in der Wahl der Waffeln! Bei Java und den anderen reinen OOPS bin ich eingezwängt und muss zeitaufwändig auch die kleinesten Frickeltools 'designen', :kotz: .

Ich kann bei C++ ebenfalls globale Variablen einführen und Assembler-Code inlinen. Globale Variablen halt ich persönlich für unschön. Ja, ich führe meine Variablen lieber als Member meiner Fenster-Klasse hinzu, wenn ich keine andere Wahl habe, bevor ich im globalen var-Bereich meine eigenen Variablen unter Form1 deklariere. Daß die Form aber auch nur eine Klasse ist (in die eigentlich alles rein sollte, was mit dem Fenster zu tun hat), realisieren am Anfang die wenigsten.

Zitat:

Zitat von sakura

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 persönlich finde es einfach unübersichtlicher.

Zitat:

Zitat von alzaimar

Imho sind z.B. Templates keine Spracheigenschaft, sondern doch ehere eine Eigenschaft eines Präprozessors, oder?

Sie sind Teil des Standards und somit der Sprache. Ob das nun durch einen getrennten Präprozessor, einen Multipass-Compiler oder durch eine Glaskugel implementiert wird, ist erstmal egal. Makros und Templates sind aber nicht eine Eigenschaft des Präprozessors, sondern definierter Teil der Sprache.

Zitat:

Zitat von Hubble

So langsam wirds stressig. Ich glaub das nächste mal stell ich mich in unser Statdion und schweke die Bayern-Fahne, da gibts nicht so viel Haue. ;)

Du kriegst hier keine Haue. Wenn du das so empfindest, hast du andere Theads zu diesem Thema noch nicht gesehen :mrgreen:
Ich bin beispielsweise eher auf deiner Seite als auf der der Delphianer, aber ich bin kein Fanatiker, in keine der beiden Richtungen.

Zitat:

Zitat von malo

Ich bekomme jedenfalls das Grauen, wenn ich einen C++-Quelltext sehe, in dem in jeder 15. Zeile eine Variable deklariert wird.

Du liest die falschen Quelltexte von den falschen Personen.

Zitat:

Zitat von malo

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.

Du liest immer noch die falschen Quelltexte.

Zitat:

Zitat von malo

Aber das kann man weniger der Sprache zuordnen, sondern eher den Entwickler selbst. Denn der entscheidet ja, wie der Code aussehen soll.

Das sagte schon Der_Unwissende.

Zitat:

Zitat von alzaimar

ich bin auch Koch

Gibt es auch was, was du nicht kannst? :mrgreen:

[malo]

Zitat:

Zitat von supermuckl

Zitat:

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

und genau das zeichnet delphi positiv aus, da man damit produktiver sein kann.

Betonung auf kann. Es kann auch zu einem schlimmen Albtraum werden, wenn man nicht aufpasst, und man eventuell noch "normalen Quelltext" mit GUI vermischt. Das ist einer der Nachteile. Allerdings geb ich dir insofern auch recht: Ich persönlich bastle auch oft die GUI schnell zusammen und kümmere mich dann um den Rest. Allerdings sollte man auf jeden Fall darauf achten, alles strikt zu trennen, sonst wird es schnell unübersichtlich. Ich denke, das ist es, was unser C++-Freund damit ausdrücken wollte ;)

[Daniel G]

Zitat:

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.... :stupid:

Es liegt an dieser komischen Eiweißstruktur, die da vor dem Bildschirm an der Tastatur sitzt, ob das Endprodukt eine Katastrophe wird. Da hilft auch die schönste Sprache nichts, wenn der Programmierer ein Chaot ist. Übrigens habe ich schon einige Beispiele in C++ gesehen, wo mir schlichtweg die Galle hochkam. Es ist (meiner bescheidenen Meinung nach) wesentlich einfacher in C++ irgendetwas zu schreiben, das keiner mehr durchblickt, als in Delphi.

[Hubble]

Oh man Jungs(und Mädels)
Ist ja echt klasse was man mit ein paar Kommentaren aus einem eingeschlafenem Thread alles machen kann.

Geh jetzt schlafen und träum von C++ Monstern die gegen Delphi Mutanten kämpfen. :spin2:

Hubble

[Hubble]

Zitat:

Zitat von Sanchez

Zitat:

Zitat von Hubble

Außerdem dauerts Stunden oder Tage bis man einen neuen Entwicklerrechner mit allen Komponenten zu laufen gebracht hat.

Diese Zeit kann man sich allerdings verkürzen indem man einmalig etwas Zeit investiert und sich ein eigenes Package mit allen benötigten Komponenten basteöt. Das macht allerdings wieder Mehraufwand bei Versionswechsel der Komponenten.

Danke für den Tip, werde das bei Gelegenheit versuchen.

Hubble

[Hubble]

Zitat:

Zitat von alzaimar

Deine Argumentation impliziert, das ein DBMS eine Haufen Sch*** ist und SQL die schlimmste und unperformanteste DB-Sprache überhaupt. Warum? Weil ich mit SQL so dermassen langsame und grottenschlechte Datenbanken entwickeln kann, das jedes ordendliche Gericht die Todesstrafe (oder zumindest lebenslange Verachtung) verhängen würde. Ich hab hier gerade einen Studenten der kennt sich mit MySQL aus und hat eine MSSQL-DB hingezimmert, die mich wirklich verzweifeln lässt. "Man kann mit SQL ganz leicht hochperformante, elegante, robuste und leicht wartbare DB erstellen." man kann aber auch den größten Mist hinzimmern, den man sich vorstellen kan.

Thema Datenbank und Borland: War ja alles klasse auf den ertsten Blick(Ich spreche immer noch von Delphi 6).
So wurde vor ca. 6-7 Jahren die Entscheidung getroffen die BDE mit Paradox zu verwenden.
Die BDE war damals State of the art und sollte bis in alle Ewigkeit mit sämtlichen Datenbanken der Welt kompatibel und super wartbar sein.
Jetzt haben wir die Kiste voll mit graphischen Elementen welche die BDE nutzen. Irgendwann sind wir aber gezwungen mal auf eine richtige Datenbank umzusteigen und das heißt das Superdelphitool von damals bricht uns jetzt den Hals.
( ich bin übrigens ein häufiger Nutzer von SQL und finde gute Datenbanken klasse )

Zitat:

Zitat von alzaimar

Es kommt nicht auf das Werkzeug an, sondern auf den Anwender. Die besten Küchenmesser (ich bin auch Koch) sind sauscharf und man kann sich damit mal eben den Arm abschnippeln, ohne das man es merkt (nun ja). Sie sind aus weichem Stahl, sodass die Klinge unbrauchbar wird, wenn man damit das falsche Material bearbeitet. Ist damit das Messer Schrott? Nein! Der Anwender! Denn weichen Stahl kann ich am schärfsten schärfen. Idiotensichere Messer sind zwar idiotensicher, aber dafür kannst Du sie nach 2 Monaten wegschmeissen.

Diese Methapher passt übebrigens super. Du kannst dasselbe Messer nicht zum Braten aufschneiden und Spargel schälen (bin kein Koch) verwenden.
Ich sehe auch die Vorzüge von Delhpi. Schnelle kleine Tools welche ein Aufgabe erledigen. Ein Bericht, eine Datenbankeingabe oder ein Scannertool für Barcode.
Ich habe sogar schon überlegt ein Projekt mit Delphi und VC++ zu mixen und so beide Vorteile zu nutzen.
Meiner Erfahrung nach, sobald man am Ende mit den Großen Aktionen ist und Übersicht und Flexibilität mehr zählt als Schnelligkeit, hab ich noch nie gute Ergebnisse mit Delphi gemacht.
Liegt eventuell an den verschiedenen alten Projekten die mir verpasst wurden, ist bei mir aber so.

Ich liege im übrgigen gar nicht so extrem weit von Deiner Position weg werde wohl aber nie ein überzeugter Delphianer werden.
Wir haben uns gerade die neue Version bestellt, diese wird im neuen Jahr auch eingesetzt werden und ich hoffe auf Besserung aber überzeugt muß ich noch werden.

Ich hab da was gehört: Ist Andreas Kosch nicht gerade vom Delphi Papst zum Visual Studio konvertiert? (korrigiert mich falls das falsch ist)

[alzaimar]

Zitat:

Zitat von tommie-lie

Zitat:

Zitat von alzaimar

ich bin auch Koch

Gibt es auch was, was du nicht kannst? :mrgreen:

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

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!

:coder2:

[r_kerber]

Zitat:

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:

Zitat von sakura

Zitat:

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:

Zitat von sakura

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

Gut dann zeig mir den Einzeiler.

Zitat:

Zitat von sakura

Zitat:

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:

Zitat von sakura

Zitat:

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:

Zitat von sakura

Zitat:

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:

Zitat von sakura

Zitat:

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:

Zitat von sakura

Zitat:

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:

Zitat von sakura

Zitat:

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:

Zitat von sakura

Zitat:

Zitat von Hubble

keine echten Templates

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

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

Zitat:

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 :mrgreen:

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:

Zitat von Daniel G

Zitat:

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.... :stupid:

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:

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:

Zitat von alzaimar

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

Big Brother Award für Borlands Lebenswerk? :mrgreen:

Zitat:

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 :mrgreen:

Zitat:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

Zitat von sakura

Zitat:

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:

Zitat von sakura

Zitat:

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.