Soll man diese Meldung beachten?

[Vbxler]

Hallo Leute!

Ich bekomme beim Kompilieren eines Programms folgenden Hinweis vom Compiler:
udm.pas(250,3) Hint: Call to subroutine "GetAnlageDaten(LongInt):<record type>;" marked as inline is not inlined
udm.pas(259,3) Hint: Call to subroutine "SetAnlagedaten(LongInt;TAnlageDaten);" marked as inline is not inlined
Die Meldung betrifft einfache Methoden mit Get und Set Property:

Code: Alles auswählen

//----------------------------------------------------------
function TuDM.GetAnlageDaten(Index: Integer): TAnlageDaten;
begin
  result := m_aAnlageDaten[Index];  //result wird unterstrichen markiert
end;
//----------------------------------------------------------
procedure TuDM.SetAnlagedaten(Index: Integer; AValue: TAnlageDaten);
begin
  m_aAnlageDaten[Index] := AValue;  //aAnlageDaten wird unterstrichen markiert
end;   

Das Programm funktionert ohne Probleme, aber trotzdem die Frage:
Was meint der Compiler damit, bzw. soll man das beachten?

Danke für eure Hilfe!

[Mathias]

Kannst mal folgendes versuchen:

Code: Alles auswählen

function TuDM.GetAnlageDaten(Index: Integer): TAnlageDaten; inline;
...
procedure TuDM.SetAnlagedaten(Index: Integer; AValue: TAnlageDaten); inline;

[Vbxler]

Danke für die Antwort.
Das bringt noch mehr Hint-Meldungen.
Ich werde die Meldung mal derzeit einfach ignorieren.
Vielleicht gehe ich dem mal nach wenn ich mehr Zeit habe.

[Achtzig]

Ich bekomme diese Meldung beim Aufruf von DebugLn(). In der Hilfe wird Folgends angezeigt:

The directive inline is only a hint to the compiler. Sometimes the compiler ignores this hint, a subroutine marked as inline is not inlined. In this case, this hint is given. Compiling with -vd might result in more information why the directive inline is ignored.

Sollte also eigentlich nur den Kompiler interessieren.

[wp_xyz]

Die Meldung ist ein Hint, also ein Hinweis. Du wirst darauf hingewiesen, dass du die beiden Methoden als "inline" deklariert hast, diese aber nicht so kompiliert werden können. Aus irgendwelchen Gründen. Ich habe gerade etwas ähnliches geschrieben, und da kam die Meldung nicht.

Dass die Getter/Setter-Routine nicht "ge-inline-d" worden ist, hat zur Konsequenz, dass das Programm einen Hauch langsamer wird; wenn du diese Routinen aber nicht in einer langen Schleife viele Male hintereinander aufrufst, wirst du davon nichts merken. Du kannst den Hint also ignorieren.

Falls dich der Hinweis an sich stört, weil dadurch evtl. wichtigere Meldungen nicht mehr ins Auge stechen, kannst du auf den entsprechenden Meldungstext rechts klicken und den Punkt "Hide message by creating IDE directive [%H-}" wählen; dann wird diese Meldung unterdrückt. Muss ggfs. für andere Meldungen wiederholt werden. Aber Achtung: Meldungen und Warnungen geben oft einen Tipp für verborgene Fehler. Durch die Hints/Warnings habe ich schon öfter die entscheidende Idee bekommen und konnte mir eine evtl stundenlange Fehlersuche sparen.

[Achtzig]

Ich habe mein Programm gerade mit -vd kompiliert und gleich ein paar Meldungen mehr erhalten, die sich auf Zugriffe wie String[Index] und Str() beziehen. Inline ist bei mir keine der Funktionen.

[fliegermichl]

Mir stellt sich die Frage wieso der Compiler der Meinung ist, daß die Methoden inline sein sollen. Das hat der OP nicht angegeben.

Übrigens bedeuted "inline", daß der Compiler keine Prozedur erzeugt, die an den entsprechenden Stellen aufgerufen wird, sondern den in der Prozedur enthaltenen Code an den Stellen, wo du die Prozedur aufrufst, dupliziert.

Der Vorteil ist eine schnellere Programmausführung, der Nachteil redundanter Code.

[wp_xyz]

Mir stellt sich die Frage wieso der Compiler der Meinung ist, daß die Methoden inline sein sollen. Das hat der OP nicht angegeben.

Woher weißt du das? Das steht nirgends. Wenn der Compiler meldet, dass die Routine "inline" deklariert ist, dann nehme ich an, dass das "inline" halt oben im Interface-Teil steht, da wo es ja auch hingehört. Aber du hast recht: Leider sind die Posts hier oft so unvollständig, so dass man ohne Kristallkugel nicht weiterkommt.

[Mathias]

Übrigens bedeuted "inline", daß der Compiler keine Prozedur erzeugt, die an den entsprechenden Stellen aufgerufen wird, sondern den in der Prozedur enthaltenen Code an den Stellen, wo du die Prozedur aufrufst, dupliziert.

Der Vorteil ist eine schnellere Programmausführung, der Nachteil redundanter Code.

Dies ist nicht immer der Fall.

Bei so einer kleine Funktion, wird es mehr Speicher verbrauchen, wen man Variablen auf den Stack speicher muss, und dann kommt noch call und ret.

Code: Alles auswählen

function add(a, b:Integer):Integer; inline;
begin
  Result := a + b;
end;

Leider sind die Posts hier oft so unvollständig, so dass man ohne Kristallkugel nicht weiterkommt.

Wen man mal das Problem mit den Anhängen reparieren würde, dann haben die User wieder die Möglichkeit den ganzen Code als Anhang zu posten.

[m.fuchs]

Wen man mal das Problem mit den Anhängen reparieren würde, dann haben die User wieder die Möglichkeit den ganzen Code als Anhang zu posten.

Es gibt zwanzigtausend Dienste, bei denen man Quellcode parken kann. Daran sollte es nun nicht scheitern.
Und auch als Anhänge noch möglich waren zeichneten sich viele Anfragen durch unvollständigen/fehlenden Quellcode aus. Das Problem ist so neu nicht.

[Achtzig]

Woher weißt du das? Das steht nirgends. Wenn der Compiler meldet, dass die Routine "inline" deklariert ist, dann nehme ich an, dass das "inline" halt oben im Interface-Teil steht, da wo es ja auch hingehört. Aber du hast recht: Leider sind die Posts hier oft so unvollständig, so dass man ohne Kristallkugel nicht weiterkommt.

Die sind nicht wirklich unvollständig, zumindest meiner nicht. Und ich nehme an, bei Vbxler auch nicht. Er wird, wie ich, ganz einfach nirgends inline verwendet haben, wie er schreibt (Mathias machte den Vorschlag, es zu probieren). Bei mir wird, wie ich schreibe, die Meldung auch bei DebugLn, Str() und ähnlichen ausgegeben. Folgender kleiner (unsinniger) Quelltext hat bei mir die oben genannte Meldung bei Result[1] zur Folge:

Code: Alles auswählen

function Test(const AString:String):String;
begin
  Result:=AString;
  if Length(AString)>0
  then Result[1]:='#';   // Hint: Call to subroutine "Test(const AnsiString):AnsiString;" marked as inline is not inlined
end;
 

Auch bei einem einfachen Aufruf von DebugLn kommt die Meldung

Code: Alles auswählen

procedure Test2(const ADebug:String);
begin
  DebugLn(ADebug); // Hint: Call to subroutine "Test2(const AnsiString);" marked as inline is not inlined
end;
 

Diese beiden Testfälle stehen hier nur in der Implementation, im Interface tauchen sie nicht auf, was aber keinen Unterschied macht.

Die Meldung kann man ignorieren, aber es wäre schon interessant zu wissen, warum die ausgegeben wird. DebugLn ist in LCLProc wie folgt deklariert:

procedure DebugLn(const s: string = ''); inline; overload;

womit schon mal ein inline da wäre. Beim Zugriff auf Result[1] könnte auch eine interne inline-Funktion beteiligt sein. Bei Vbxler werden die Meldungen auch bei Zugriffen auf ein Array ausgegeben (jeweils die Ergebnisseite).

Nachtrag: FPC 3.1.1, Lazarus 1.9.0 - 57432M

[m.fuchs]

Nachtrag: FPC 3.1.1, Lazarus 1.9.0 - 57432M

Das könnte doch der entscheidende Hinweis sein, da gab es vor kurzem eine passende Änderung im Code: https://bugs.freepascal.org/view.php?id=31717

Vielleicht hat dieses neue Feature ein Problem?

[Achtzig]

Danke für den Hinweis, m.fuchs.

Das erklärt auch, warum mir die Meldung vorher nicht begegnet ist, ich mach nur so einmal im Monat ein Update.

Ich werde das dann einfach mal ausblenden. Ein Problem besteht aus meiner Sicht darin, daß Meldungen angezeigt werden, wo man selbst mal vollkommen unschuldig ist und nichts an dem Umstand ändern kann

[wp_xyz]

Du solltest jetzt einen Bug-Report darüber schreiben und auf den von m.fuchs genannten Report verweisen. Sonst bleibt das so bestehen, bis sich jemand anders daran stößt, und da nur wenige Leute die Hints und Warnings prüfen, wird das dauern.

[FPK]

Du solltest jetzt einen Bug-Report darüber schreiben und auf den von m.fuchs genannten Report verweisen.

Ist schon behoben, es wird nun der richtige Unterprogramm-Name ausgegeben.