Vorteile von Delphi

[malo]

Zitat:

Zitat von Oxmyx

Operatorüberladung fehlt mir auch noch in Win32-Delphi.

Dann freu dich auf Dexter ;)

[jbg]

Zitat:

Zitat von malo

Es gibt natürlich auch diverse Sprachfeatures, die in Delphi nicht vorhanden sind.

Es gibt auch Sprachfeatures, die in Delphi vorhanden sind, aber nicht in C++ :wink:
Schon mal mit COM gearbeitet? Oder bei einem Interface die Implementierung dessen auf eine andere Klasse delegiert?

Zitat:

Dazu gehört (bis einschl. D2005) Operatoren-Überladung

So allgemein kannst du das nicht über Delphi 2005 sagen. Delphi.NET beherrscht Operator-Überlagung. Delphi.Win32 noch nicht.

Zitat:

auch Templates und ähnliches

Was meinst du mit "ähnliches". Mir fällt da nichts weiteres ein.

Zitat:

Das macht Delphi unflexibler, was Problemlösungen angeht.

Die fehlende Operator-Überladung macht Delphi sicherlich nicht unflexibler. Vielleicht unleserlicher, aber nicht unflexibler. Bei Templates sieht die Sache schon anders aus. Wobei einem da meisten mehr die "Generics" statt die ausgewachsenen Templates (z.B. Rekursive Templates) abgehen. Es wäre schon schön, wenn man "TList<TMyClass>" schreiben könnte und nicht jedesmal die Klasse TMyClassList neu schreiben muss (mit den kommenden Live-Templates wird einem dann wenigstens mal die Schreibarbeit abgenommen).

Zitat:

So hat Delphi beispielsweise Probleme mit Treiberprogrammierung

Da du das in den selben Absatz geschrieben hast, wie die beiden oben Zitierten Sätze, hatte ich das erstmal so verstanden, dass wegen der fehlenden Operator-Überladung und Templates mit Delphi keine Treiber möglich sind.
Treiber lassen sich prinzipiell nur mit dem Microsoft C++ Compiler schreiben. Ich habe noch keinen Windows-Treiber von bcc32 oder gcc (Mingw) gesehen. Also ist Delphi da nicht alleine. Treiber brauchen einen speziellen Linker, der die Datei so markiert, dass der Kernel sie auch akzeptiert.

Zitat:

Das ist aber eine der wenigen Ausnahmen von Dingen, die mit Delphi schwieriger sind als mit C++.

Wieviel Prozent der Programmierer schreiben denn einen Treiber? Mich hat es bis heute noch nicht gestört, dass ich keinen Treiber schreiben kann. Dazu gehört auch ein ganzes Stück an Wissen und dieses Wissen brauche ich mir nicht anzueignen, weil ich wahrscheinlich in meinem ganzen Leben nie einen Windows-Treiber schreiben werde.

[malo]

Zitat:

Zitat von jbg

Zitat:

Dazu gehört (bis einschl. D2005) Operatoren-Überladung

So allgemein kannst du das nicht über Delphi 2005 sagen. Delphi.NET beherrscht Operator-Überlagung. Delphi.Win32 noch nicht.

Naja, ich hab auch nur vom Win32-Teil geredet. Wenn ich .NET meine, schreibe ich es i.d.R. seperat nochmal hin. Aber im Grunde hast du Recht. Ich sollte demnächst etwas besser aufpassen, was ich genau schreib ;)

Zitat:

Zitat von jbg

Die fehlende Operator-Überladung macht Delphi sicherlich nicht unflexibler. Vielleicht unleserlicher, aber nicht unflexibler. Bei Templates sieht die Sache schon anders aus. Wobei einem da meisten mehr die "Generics" statt die ausgewachsenen Templates (z.B. Rekursive Templates) abgehen. Es wäre schon schön, wenn man "TList<TMyClass>" schreiben könnte und nicht jedesmal die Klasse TMyClassList neu schreiben muss (mit den kommenden Live-Templates wird einem dann wenigstens mal die Schreibarbeit abgenommen).

Mit unflexbiler meinte ich, dass man weniger Möglichkeiten hat, ein Problem zu lösen. Bei C++ gibt es ja für alles und für jeden mehrere Möglichkeiten, etwas zu machen (verglichen mit Win32-Delphi bis D2005). Ob das jetzt ein Segen oder ein Fluch ist, ist ein anderes Streitthema.
Allerdings ist man schon gewissermaßen beschränkt, wenn man auf die Prozeduren/Funktionen zurückgreifen muss. Einigen wird das egal sein, aber es gibt auch einige große Fans von Operatoren, die da viel lieber einen Operator für schreiben würden. Ist hauptsächlich eine Geschmacksfrage. Und mit D2006 kann man in Delphi (Win32) auch Operatoren überladen :firejump:

Zitat:

Zitat von jbg

Da du das in den selben Absatz geschrieben hast, wie die beiden oben Zitierten Sätze, hatte ich das erstmal so verstanden, dass wegen der fehlenden Operator-Überladung und Templates mit Delphi keine Treiber möglich sind.
Treiber lassen sich prinzipiell nur mit dem Microsoft C++ Compiler schreiben. Ich habe noch keinen Windows-Treiber von bcc32 oder gcc (Mingw) gesehen. Also ist Delphi da nicht alleine. Treiber brauchen einen speziellen Linker, der die Datei so markiert, dass der Kernel sie auch akzeptiert.

Das ist ein eigenes Thema, darüber gibt es genug Threads. Treiber
Übrigens meinte ich nicht, dass Treiber wegen Templates oder Operatorüberladung nicht möglich seien (nur als Info) ;)

Zitat:

Zitat von jbg

Wieviel Prozent der Programmierer schreiben denn einen Treiber? Mich hat es bis heute noch nicht gestört, dass ich keinen Treiber schreiben kann. Dazu gehört auch ein ganzes Stück an Wissen und dieses Wissen brauche ich mir nicht anzueignen, weil ich wahrscheinlich in meinem ganzen Leben nie einen Windows-Treiber schreiben werde.

Ich hab nicht gesagt, dass es schlimm ist, mit Delphi keine Treiber entwickeln zu können. Ich habe es einfach als Beispiel aufgeführt, was mit Delphi nicht geschickt möglich ist. Wie wichtig das ist, ist eine andere Frage ;)

[Christian Seehase]

Moin Andreas,

hast Du Dir das hier schon einmal angesehen:

object_pascal_templates
TCollection und TCollectionItem
TObjectList-Descendant mit Templates

[jbg]

Zitat:

Zitat von Christian Seehase

hast Du Dir das hier schon einmal angesehen:

Klar. Ich habe da sogar was eigenes mal angefangen, dass mir aus

Delphi-Quellcode:

type
  TTemplateList = class(TList){template<T>}
  private
    function GetItem(Index: Integer): T;
  public
    property Items[Index: Integer]: T read GetItem;
  end;

  TIntegerList = TTemplateList{template<Integer>};

folgendes macht/machen sollte:

Delphi-Quellcode:

type
//  TTemplateList = class(TList){template<T>}
//  private
//    function GetItem(Index: Integer): T;
//  public
//    property Items[Index: Integer]: T read GetItem;
//  end;

  {$INCLUDE TTemplateList__Integer__.tpl}//TIntegerList = TTemplateList{template<Integer>};

Mit TTemplateList__Integer__.tpl:

Delphi-Quellcode:

  // [der Delphi-Parser im Forum zieht die erste Zeile immer nach ganz links]
  TTemplateList = class(TList){template<Integer>}
  private
    function GetItem(Index: Integer): Integer;
  public
    property Items[Index: Integer]: Integer read GetItem;
  end;

Das Projekt hatte ich aber aus Zeitmangel recht schnell eingestampft. Übrig blieb der Delphi language Preprocessor (dpp32), der nichts anderes macht als Makros per {$DEFINE Concat(x, y) x##y} einzuführen.

[pajofego]

In den letzten Jahren habe ich nur noch in C++ programmiert. Vorgabe vom Arbeitgeber! Nun gut, ich habe mich an die Macken eines C/C++ Compilers gewöhnt und irgendwann versteht man ihn dann auch. Die Syntax von C finde ich im Vergleich zu Pascal günstiger bzw. ich muss weniger schreiben...ist aber wie schon allseits diskutiert wurde eine reine Geschmaksfrage! Ansonsten fand ich Delphi schlichtweg geil! Der compiler ist/war sauschnell, meine Berechnungen liefen meistens sogar schneller als in C++! Das einzige was mich heute an Delphi nervt - verzeiht wenn ich nicht mehr auf dem neuesten Stand bin, vielleicht hat sich ja dahingehend etwas geändert-, ist:

Die Unterscheidung von Klein und Großbuchstaben (vielleicht arbeite ich zuviel mit LINUX)
Kann man heute endlich in Delphi Operatoren überladen?
begin/end -> das sind 6 Zeichen mehr als "{ }"
sowie keine Makros

Aber wie gesagt, falls der native compiler von delphi immer noch so sauschnell ist wie zu Zeiten von Delphi 6, dann finde ich das heute - zumindestens ist das für mich ein wichtiges Kriterium - verdammt gut!

Schade nur, dass ich nichts mehr in Delphi mache...vielleich ändert sich das ja mal irgendwann wieder! Wenn man einmal in C++ steckt kommt man da nicht mehr so schnell wieder raus.

Gruß

pajofego

[malo]

Zitat:

Zitat von pajofego

Die Unterscheidung von Klein und Großbuchstaben (vielleicht arbeite ich zuviel mit LINUX)

Versteh ich nicht. Delphi ignoriert Groß/Kleinschreibung.

Zitat:

Kann man heute endlich in Delphi Operatoren überladen?

In der nächsten Version geht das, in Dexter ;)

Zitat:

begin/end -> das sind 6 Zeichen mehr als "{ }"

Stört mich eigentlich nicht wirklich... denn begin/end fällt viel leichter ins Auge als { }. Die eckigen Klammern sind viel unauffälliger. Da schreib ich lieber 6 Zeichen mehr.

[noidic]

Zitat:

Zitat von sniper_w

Ja, grossteils stimmt das, aber C ist NUR eine Untermenge von C++.

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

[mumu]

jo also genau so ne diskussion hab ich erhofft :-)

hab absichtlich die frage nicht genauer formuliert, da mir die verschiedensten eindrücke interessieren.

was ich noch klasse in delphi find:
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?

[pajofego]

Zitat:

Zitat von malo

Zitat:

Zitat von pajofego

Die Unterscheidung von Klein und Großbuchstaben (vielleicht arbeite ich zuviel mit LINUX)

Versteh ich nicht. Delphi ignoriert Groß/Kleinschreibung.

Sorry, ich meinte, das die Nichtunterscheidung mich nervt...aber zum Glück ist das Geschmackssache...Delphi hat verdammt viele Vorteile