c++ vs delphi

[Hansa]

Zitat von Mephistopheles:

...Außerdem kann man in C++ Klassen wie Stackvariablen benutzen - will heißen, wenn "out-of-scope" wird die Klasse freigegeben.

Ist das jetzt ein feature, oder ein Bug ? Wichtiger noch wäre es, zu wissen, wo so was unbedingt gebraucht wird und wozu. 8)

[mael]

Zitat von Mephistopheles:

Dir ist schon klar, was die UNICODE_STRING-Struktur ist?

Meine Frage sollte bedeuten: Warum braucht man eine UNICODE_STRING-Struktur, wenn ich WideString habe?
Zuerst macht man es umständlich und dann verwendet man Operator-Überladung um es wieder komfortabler zu machen.

Zitat:

Präprozessor-Makros gibt es neben Operator-Overloading auch nicht bei Delphi.

Was sehr gut ist. Schade ist eher, daß Delphi keine Templates unterstützt.

Zitat von Hansa:

Zitat von Mephistopheles:

...Außerdem kann man in C++ Klassen wie Stackvariablen benutzen - will heißen, wenn "out-of-scope" wird die Klasse freigegeben.

Ist das jetzt ein feature, oder ein Bug ? Wichtiger noch wäre es, zu wissen, wo so was unbedingt gebraucht wird und wozu. 8)

Es ist natürlicher: vermeidet try-finally-Blöcke so daß man Objekte wie Variablen primitiven Typs (also Integer, Char, Boolean) verwenden kann. Dynamische Allokation geht ja immer noch mit new.

[Hansa]

Antworten auf so was wie diese Frage :

Zitat von Hansa:

...Wichtiger noch wäre es, zu wissen, wo so was unbedingt gebraucht wird und wozu. 8)

die vermisse ich. Da wird immer ausgewichen. 8) Wieso das ?

[mael]

Zitat von Hansa:

die vermisse ich. Da wird immer ausgewichen. 8) Wieso das ?

Man kann damit nicht mehr machen, aber man kann eleganteren Code schreiben (siehe mein vorigen Beitrag). Und es ist weniger fehleranfällig, als die dynamische Allokation und der späteren expliziten Freigabe, also das wozu man in Delphi gezwungen ist.
Die übliche Idee ist doch wenn eine Variable ihren Gültigkeitsbereich verläßt wird sie freigegeben.
In den allermeisten Fällen braucht man nicht dynamisch zu allozieren...

Z.B. ist es sehr lästig wenn man sowas wie mathematische Vektoren in einer Klasse gekapselt hat und dann eine Berechnung vornimmt. Dynamisch wird das sehr unübersichtlich.

[jbg]

Zitat von mael:

Es ist natürlicher: vermeidet try-finally-Blöcke so daß man Objekte wie Variablen primitiven Typs (also Integer, Char, Boolean) verwenden kann. Dynamische Allokation geht ja immer noch mit new.

Na, dann nimm doch "object" statt "class", was das eigentliche Pendant zu C++'s "class" ist.

[mael]

Aber virtuelle Methoden gehen nicht:

Das hier kompiliert nicht

Delphi-Quellcode:

  TBla = object
  public
    procedure Blubb; virtual;
  end;

  TBlo = object(TBla)
  public
    procedure Blubb; override;
  end;

  procedure TBla.Blubb;
  begin
  end;

  procedure TBlo.Blubb;
  begin
  end;

ersetzt man object durch class geht es.

[Mephistopheles]

Zitat von Hansa:

Zitat von Mephistopheles:

...Außerdem kann man in C++ Klassen wie Stackvariablen benutzen - will heißen, wenn "out-of-scope" wird die Klasse freigegeben.

Ist das jetzt ein feature, oder ein Bug ?

Ein Feature, denn in Delphi muß man ein try-finally-Konstrukt oder ein implementiertes Interface (als Workaround) benutzen.
In C++ kann man mit new hingegen das übliche Delphiverhalten ebenfalls bekommen.

Zitat von Hansa:

Wichtiger noch wäre es, zu wissen, wo so was unbedingt gebraucht wird und wozu. 8)

Autsch

Zitat von mael:

Meine Frage sollte bedeuten: Warum braucht man eine UNICODE_STRING-Struktur, wenn ich WideString habe?
Zuerst macht man es umständlich und dann verwendet man Operator-Überladung um es wieder komfortabler zu machen.

Man benutzt UNICODE_STRING und z.B. LSA_UNICODE_STRING so oft, wenn man sich tiefgehender mit Windowsprogrammierung beschäftigt, daß ich diese Frage nicht erwartet hätte. Das "umständlich machen" obliegt nämlich in Sachen UNICODE_STRING nicht dir (sondern MS). Und das was du als "komfortabler machen" bezeichnest, nenne ich Abstraktion .

Zitat von mael:

Was sehr gut ist. Schade ist eher, daß Delphi keine Templates unterstützt.

Da würde ich nur teils zustimmen. Wenn, wie das manche C/C++-Programmierer machen, mehr Programm in Präprozessorstatements als in C/C++-Code steht, stimme ich voll zu. Aber ein Präprozessor könnte manchmal so einiges erleichtern - auch in Delphi - er müßte ja nicht gleich so vieles können wie der in C . Zum Beispiel könnte der globale #defines erlauben, was man aktuell relativ umständlich machen muß.
Templates wären allerdings die Krönung - da stimme ich voll mit dir überein.
Aber wie schriebst du so schön:

mael schrieb (Hervorhebung Mephisto):

Freepascal hat Operatorueberladung, aber wie schon gesagt, bei Delphi fehlt die Weiterentwicklung der Sprache.

Zitat von jbg:

Zitat von mael:

Es ist natürlicher: vermeidet try-finally-Blöcke so daß man Objekte wie Variablen primitiven Typs (also Integer, Char, Boolean) verwenden kann. Dynamische Allokation geht ja immer noch mit new.

Na, dann nimm doch "object" statt "class", was das eigentliche Pendant zu C++'s "class" ist.

object ist seit mindestens Delphi 4 "deprecated" (verworfen, sollte nicht benutzt werden, nicht mehr dokumentiert). Du kommst also mit diesem Tip mindestens 7 Jahre zu spät (D4 kam 1998 raus). Eigentlich ist diese Methode ein Relikt aus BP-Zeiten, deren Benutzung absolut nicht empfohlen und diversen Einschränkungen unterworfen ist - sie existierte zur einfacheren Portierbarkeit alten Codes. Siehe dazu mael's Ausführungen oben.

[Hansa]

Zitat von Mephistopheles:

Zitat von Hansa:

Wichtiger noch wäre es, zu wissen, wo so was unbedingt gebraucht wird und wozu. 8)

Autsch

Da vermute ich nur : "keine Antwort ist auch eine Antwort" Normalerweise genügt ein einfaches Beispiel. Oder das ganze ist eben tatsächlich unwichtig.

[mael]

Zitat von Mephistopheles:

Aber wie schriebst du so schön:

mael schrieb (Hervorhebung Mephisto):

Freepascal hat Operatorueberladung, aber wie schon gesagt, bei Delphi fehlt die Weiterentwicklung der Sprache.

Manchmal wünsche ich mir einen FreePascal Compiler der das alles macht, direkt Delphi-Code kompilieren kann (also vollständig kompatibel), auf SSE und 64 Bit optimiert und die Entwickler von FreePascal sich einen ordentlichen Codingstil angewöhnen

Zitat von Mephistopheles:

Man benutzt UNICODE_STRING und z.B. LSA_UNICODE_STRING so oft, wenn man sich tiefgehender mit Windowsprogrammierung beschäftigt, daß ich diese Frage nicht erwartet hätte. Das "umständlich machen" obliegt nämlich in Sachen UNICODE_STRING nicht dir (sondern MS). Und das was du als "komfortabler machen" bezeichnest, nenne ich Abstraktion .

Obwohl ich mich intensiv mit direkter Windows-Programmierung beschäftige, muß ich zu meiner grenzenlosen Schande gestehen, daß ich das nie gebraucht habe.
Ursprünglich komme ich von Win9x, da gibt es keine Sicherheit

Irgendwie lies dieses MaximumLength mich schon vermuten daß irgendwo ein buffer overrun verhindert werden soll. Aber mal ehrlich, warum verwendet MS nicht die WideStrings, da hätten die solche Probleme nicht , das könnte man dann einfach casten.

Bevor man mir sagt C++ hat keine WideStrings: Ich weiß, aber die Struktur/Record hätten die ja nur ein klein wenig anders machen müssen und dann wäre das kompatibel.

[tommie-lie]

Zitat von mael:

Manchmal wünsche ich mir einen FreePascal Compiler der das alles macht, direkt Delphi-Code kompilieren kann (also vollständig kompatibel), auf SSE und 64 Bit optimiert und die Entwickler von FreePascal sich einen ordentlichen Codingstil angewöhnen

Ein Delphi-Compiler, der das könnte, würde mir schon reichen

Zitat von mael:

Irgendwie lies dieses MaximumLength mich schon vermuten daß irgendwo ein buffer overrun verhindert werden soll. Aber mal ehrlich, warum verwendet MS nicht die WideStrings, da hätten die solche Probleme nicht , das könnte man dann einfach casten.

Bevor man mir sagt C++ hat keine WideStrings: Ich weiß, aber die Struktur/Record hätten die ja nur ein klein wenig anders machen müssen und dann wäre das kompatibel.

Warum sollte Microsoft zu etwas kompatibel sein, was sie nicht erfunden haben, was allein der Konkurrent unterstützt und was in ihrer eigenen Haussprache nicht unterstützt wird? Außerdem verhindern auch WideStrings keinen Buffer-Overrun, falls du das andeuten wolltest (die beiden Sätze stehen so verdächtig im gleichen Absatz ).
Und "einfach" Casten ist dank Compiler-Magic bei Strings auch so eine Sache

MaximumLength sagt Windows übrigens wie groß der Buffer ist, den deine Anwendung allokiert hat und ist eigentlich nur dafür da, wenn Windows Daten in den Buffer schreiben soll. Es selbst weiß ja nicht, wie groß der Buffer ist, deswegen muss man es ihm mitteilen. Das wirst du bei allen C-Konstrukten finden, die irgendwie mit Strings zu tun haben.