Procedure vs Function, Vor- und Nachteile

[p80286]

Zitat:

Zitat von himitsu (Beitrag 1399364)

Zitat:

Zitat von p80286 (Beitrag 1399360)

nein, mein Virenscanner hat auch einen Trojaner gefunden:

Das liegt aber nur sekundär an diesem Code.
Dein altes Delphi 7 und dass zuviele böse Programme in Delphi geschrieben wurden und weil viele Virensignaturen einfach nur Schrott sind.

https://www.virustotal.com/de/ zur Gegenprobe

Und die eigene Software kann man als False-Positive melden, dann wird die Signatur meist recht schnell angepasst.
https://www.microsoft.com/en-us/wdsi/filesubmission

Da mir das bisher noch nie passiert ist, finde ich es erst einmal nur amüsant. Aber vielen Dank für den Hinweis mit den false-positives.

@Zacherl
Was mir in der Betrachtung fehlt, ist die Schreibschutzprüfung die ja bei

Delphi-Quellcode:

const

irgendwo stattfinden muß.


Gruß
K-H

[Neutral General]

Zitat:

Zitat von p80286 (Beitrag 1399463)

@Zacherl
Was mir in der Betrachtung fehlt, ist die Schreibschutzprüfung die ja bei

Delphi-Quellcode:

const

irgendwo stattfinden muß.

Der Schreibschutz wird nur zur Compilezeit gecheckt. Mit ein bisschen Pointergematsche kannst du const umgehen.

Delphi-Quellcode:

procedure TuWas(const X: Integer);
begin
//  X := 987;   <-- Geht nicht
  PInteger(@X)^ := 987;
  ShowMessage(IntToStr(X));
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  TuWas(123);
end;

[p80286]

Zitat:

Zitat von Neutral General (Beitrag 1399465)

Der Schreibschutz wird nur zur Compilezeit gecheckt.

Ah, danke!

Zitat:

Zitat von Neutral General (Beitrag 1399465)

Mit ein bisschen Pointergematsche kannst du const umgehen.

Auch wenn ich auf der Hochzeit des Öfteren getanzt habe, brauchen tu ich das nicht.


Gruß
K-H

[bernau]

Zitat:

Zitat von p80286 (Beitrag 1399466)

Auch wenn ich auf der Hochzeit des Öfteren getanzt habe, brauchen tu ich das nicht.

Den merke ich mir. :lol::lol::thumb:

[himitsu]

Es gibt Aufrufkonventionen, da landet alles auf dem Stack und nichts in Registern (außer dem Result, der praktisch überall in EAX ist ... abgesehn davon, wo hier der Result zu einem VAR-Parameter gemacht wurde)
Praktisch landen im "Pascal" die ersten 3 Parameter in Registern (EAX, EDX und ECX, wenn möglich) und der Rest immer auf dem Stack.
In Methoden gibt es einen "unsichtbaren" SELF-Parameter, der als Erstes kommt. ("procedure t.x", "class procedure t.x" aber nicht "class procedure t.x static")
Dazu kommt dann noch, ob die Referenz oder der Wert dort gespeichert wird.
Delphi macht bei gemanagten Typen aus aus dem Result einen VAR-Parameter und
Unter 64 Bit gibt es nur noch eine Konvention mit paar mehr Registern.

Delphi-Quellcode:

{ IN .. Kopie . . . . . . . } Xxx: Txxx;
{ IN .. Referenz oder nicht } const Xxx: Txxx;
{ IN .. Referenz . . . . . .} [ref] const Xxx: Txxx;  // relativ neu
{ INOUT Referenz . . . . . .} var Xxx: Txxx;
{ OUT . Referenz . . . . . .} out Xxx: Txxx;

Im Allgemeinen ist das Ganze aber dem Programmierer eigentlich total egal.
Außer man will sowas im Assembler aufrufen und ansonsten gibt es in der neuen RTTI auch die Möglichkeit das von der RTTI via Invoke aufrufen zu lassen.
RTTI.Invoke, TRttiMethod.Invoke, TRttiProcedureType.Invoke und TRttiInvokableType.Invoke

[p80286]

Zitat:

Zitat von himitsu (Beitrag 1399496)

Praktisch landen im "Pascal" die ersten 3 Parameter in Registern (EAX, EDX und ECX, wenn möglich) und der Rest immer in Registern.

Sicher?
Wenn ich mich nicht irre müßte es "...und der Rest immer auf dem Stack" heißen !?
Könnte das bitte jemand verifizieren?

Gruß
K-H

[Zacherl]

Zitat:

Zitat von p80286 (Beitrag 1399616)

Zitat:

Zitat von himitsu (Beitrag 1399496)

Praktisch landen im "Pascal" die ersten 3 Parameter in Registern (EAX, EDX und ECX, wenn möglich) und der Rest immer in Registern.

Sicher?
Wenn ich mich nicht irre müßte es "...und der Rest immer auf dem Stack" heißen !?
Könnte das bitte jemand verifizieren?

Korrekt. Bestimmt ein Schreibfehler :P

[p80286]

Danke!
klar hat er sich da vertan (aber sicher war ich mir nicht!), aber wenn ein Anfänger darüber stolpert... Falschinformationen haben ein zähes Leben!

Gruß
K-H

[himitsu]

Jupp, war der Stack. (hatte grade schonwieder "Jupp, waren Register" geschrieben :oops:)
Aber so steht es bestimmt schon immer da oben drin. :angle2:

[Dennis07]

Zitat:

Zitat von freimatz (Beitrag 1399456)

Echt jetzt? Wozu? Also wenn Du das als Hobby machst ok.
Wenn Ihr aber professionell programieren wollt dann lasst den ...
Macht lieber schönen lesbaren code der sich schnell verstehen lässt und das tut was der Anwender will. Die Optimierungen hier sind marginal und merkt der Anwender nicht. Ich behaupte nicht mal in 1% der Fälle spielt das eine Rolle. Selbst wenn es mal ein Geschwindigkeitsproblem gibt, dann liegt das meist woanders. (Ich selber habe früher viel mit Assembler gemacht.) Und wenn Ihr schönen Code habt dann kann man viel leichter mal einen Cache o.a. dazwischenschieben wenn es nötig ist. Das bringt dann z.B. Faktor 5 und nicht nur 5%.
Es es hat schon seinen Grund warum EMB da (fast) nichts dokumentiert - sie würden sich ja selbst einen Klotz für künftige Optimierungen ans Bein binden.

Also da fehlen mir ehrlich gesagt die Worte... Warum um alles in der Welt soll es denn bitte "unleserlich" sein, Parameter, die einen bestimmten Zweck erfüllen sollen (var, out, const) als solche zu deklarieren? Kann ich beim besten Willen nicht nachvollziehen. Ich bin ja auch kein 5-jähriger, der nicht weiß wo oben und unten ist. :D
Also grundsätzlich, und da ist es mir völlig egal welche "Authorität" in seinem "CleanCode" guide irgendwas meint schreiben zu müssen, halte ich es im Gegenteil für eine enorm schlechte Praxis, die Features, die man besitzt (zB. "const" und "out") nicht zu benutzen, wenn dies angebracht wäre. Mal ganz abgesehen davon, dass es eben zumindest im Falle von "const" die Performance deutlich beeinflussen kann. Und selbst wenn es nur 5% sind, und man gleichzeitig noch die Übersicht durch den eingeschränkten Zugriff erhöht...
Im Grunde kann ich Bernau da nur zustimmen. Wollte es aber nochmal selbst mit eigenen Worten gesagt haben.

Zitat:

Zitat von p80286 (Beitrag 1399463)

Was mir in der Betrachtung fehlt, ist die Schreibschutzprüfung die ja bei

Delphi-Quellcode:

const

irgendwo stattfinden muß.

Hatte ich zwar schon weiter oben erklärt, aber Danke an Neutral General, dass er es nochmal praktisch untermauert hat ;)

Zitat:

Zitat von himitsu (Beitrag 1399496)

Es gibt Aufrufkonventionen, da landet alles auf dem Stack und nichts in Registern (außer dem Result, der praktisch überall in EAX ist ... abgesehn davon, wo hier der Result zu einem VAR-Parameter gemacht wurde)
Praktisch landen im "Pascal" die ersten 3 Parameter in Registern (EAX, EDX und ECX, wenn möglich) und der Rest immer auf dem Stack.
In Methoden gibt es einen "unsichtbaren" SELF-Parameter, der als Erstes kommt. ("procedure t.x", "class procedure t.x" aber nicht "class procedure t.x static")
Dazu kommt dann noch, ob die Referenz oder der Wert dort gespeichert wird.
Delphi macht bei gemanagten Typen aus aus dem Result einen VAR-Parameter und
Unter 64 Bit gibt es nur noch eine Konvention mit paar mehr Registern.

Jo, kann man aber auch alles im DocWiki unter Assembler-Prozeduren und -Funktionen nachlesen, wens interessiert. Anmerken würde ich hier nur, dass nur kurze Strings und Records, nicht aber andere Stringtypen (zB. OpenString, AnsiString oder UnicodeString), diese werden direkt in EAX zurückgegeben, da sie ja bereits Zeiger/Referenzen sind. ;)

Zitat:

Zitat von himitsu (Beitrag 1399496)

{ IN .. Referenz . . . . . .} [ref] const Xxx: Txxx; // relativ neu

WWWAAS? Etwas in Delphi, das ich noch nicht kenne? Wow, ist mir das schon ewig nicht mehr passiert. Kannst du mal genau erklären, was das genau ist bzw. hast du einen Link zu dem Thema? Würde mich mal echt interessieren.

An dieser Stelle würde ich Zacherl gern noch für seinen Aufwand und die Erklärungen danken! :)