Vertändnisfrage zu 'Meldungen'

[himitsu]

So in etwa.
Man kann es sich fast wie die Makros aus anderen Programmiersprachen vorstellen.
Der "Inhalt" dieser Funktion/Prozedur wird an der "Aufrufstelle" eingefügt, an statt einem CALL/Aufruf zu dieser Funktion.
> Es entfällt also ein Sprung, was bei "kurzen" Funktionen den Programmablauf verbessern kann.
(dass dieses "Einfügen" vom Compiler oft/meistens nicht wirklich optimal vorgenommen wird und bei Assembler-Funktionen praktisch garnicht gut geschehen kann, das ist eine andere Angelegenheit)

Und hier sagt der Compiler einfach nur

Zitat:

ich habe an der Stelle keinen Zugriff auf alles, was diese Funktion benötigt und ignoriere daher das INLINE.

PS: Was sich garnicht auflösen lässt, wäre z.B. ein Zugriff auf eine Funktion, globale Variable oder einen Typ, welcher in der Implementation der anderen Unit deklariert wurde.
> Hier geht nur INLINE weglassen oder diesen Teil ins Interface verschieben.

[Fritzew]

Warum aber eine Routine wie MessageDlg inline deklariert wurde erschließt sich mir nicht wirklich.
Inline macht eigentlich nur Sinn wenn die Abarbeitung sich dann "messbar" auf die Ausführungsgeschwindigkeit auswirkt.
Ich bezweifle das für eine Dialogbox.........

[Uwe Raabe]

Zitat von Fritzew:

Inline macht eigentlich nur Sinn wenn die Abarbeitung sich dann "messbar" auf die Ausführungsgeschwindigkeit auswirkt.
Ich bezweifle das für eine Dialogbox.........

Bei inline wird ja nur der zusätzliche function call mit dem Parameterhandling auf dem Stack eingespart. Ob das überhaupt für den Anwender wahrnehmbare Auswirkungen hat ist eh zweifelhaft. Sinnvoll sind inline Deklarationen damit eigentlich nur, wenn der call-Aufwand ähnlich groß ist wie der execute-Aufwand der eigentlichen Funktion und die Funktion in zeitkritischen Anwendungen oft genug aufgerufen wird. Bei MessageDlg ist das allerdings wirklich mehr als fraglich. Hier wurde offenbar einfach nur Cargo-Cult-Programming betrieben, ohne über den Sinn auch nur ansatzweise nachzudenken.

[himitsu]

Und bei großen Programmen, mit viel Programmcode oder verteiltem Programmcode (BPL/DLL) der teilweise schnell ausgeführt werden soll/muss, welcher aber bei wenig freiem Speicher entladen sein kann und zurückgeladen werden muß (PageFault), bzw. wo das Programm sich erst Zugriff auf den anderen Speicherblock holen muß, um da die Funktion aufzurufen .... da kann Inline auch bei größeren Funktion manchmal sinnvoll sein.


Beispiel Taskmanager: Da wäre es schön, wenn er für seine Hauptfunktionen im physischen RAM Speicher reserviert hat und sich nicht einfach so auslagern lässt. (natürlich muß so ein Programm auch möglichst wenig RAM belegen)
Wenn mal wieder was arg hängt, vor allem durch zu wenig freien RAM und man will schnell in den Taskmanager um den Verursacher abzuwürgen .... es nervt schon, dass gerade dann der Taskmanager minutenlang braucht um sein Fenster anzuzeigen und man auch dann noch nur stockend in der Liste navigieren kann. (unter der Bedingung, dass der Taskmanager bereits geladen und nur minimiert war)

[Delbor]

Hi zusammen

Vielen Dank für eure aufschlussreichen Antworten!

@Fritzew

Zitat:

Ich bezweifle das für eine Dialogbox.........

Andrerseits - wenn ich sehe, wielange andere Fenster (nicht unbedingt Delphi) brauchen, um sich aufzubauen... Ob das damit zusammenhängt, weiss ich nicht wirklich, aber ich ahlte es nicht für ausgeschlossen, dass sich das beim Threadmanagment von Windows bemerkbar macht.

Gruss
Delbor