Code Optimisation: Benutzung von const in prozedur-Köpfen

[jaenicke]

Zitat von Namenloser:

Ja, kannst du. Es schadet zumindest nicht.

So pauschal ist das nicht richtig. Wenn der Parameter eine Interface-Referenz ist und als const deklariert ist, kommt es nicht gut, wenn man ein TXyz.Create dort direkt übergibt. Also ich meine ohne Zwischenvariable vom Typ des Interfaces.

Grund:
Durch das Create selbst wird logischerweise der Referenzzähler nicht erhöht, durch das const ist aber auch die Referenzzählung für den Parameter deaktiviert. Also steht der Referenzzähler auf 0. Übergibt nun der Konstruktor das Interface an eine weitere Routine mit Referenzzählung, wird die Referenz um 1 erhöht und wieder auf 0 gesetzt. Danach ist dann die Referenz ungültig.

Solange man sauber immer mit Zwischenvariablen arbeitet, ist aber alles in Ordnung. So einen Fehler findet man aber leider nicht unbedingt so schnell...

[Namenloser]

Zitat von jaenicke:

Zitat von Namenloser:

Ja, kannst du. Es schadet zumindest nicht.

So pauschal ist das nicht richtig. Wenn der Parameter eine Interface-Referenz ist und als const deklariert ist, kommt es nicht gut, wenn man ein TXyz.Create dort direkt übergibt. Also ich meine ohne Zwischenvariable vom Typ des Interfaces.

Grund:
Durch das Create selbst wird logischerweise der Referenzzähler nicht erhöht, durch das const ist aber auch die Referenzzählung für den Parameter deaktiviert. Also steht der Referenzzähler auf 0. Übergibt nun der Konstruktor das Interface an eine weitere Routine mit Referenzzählung, wird die Referenz um 1 erhöht und wieder auf 0 gesetzt. Danach ist dann die Referenz ungültig.

Solange man sauber immer mit Zwischenvariablen arbeitet, ist aber alles in Ordnung. So einen Fehler findet man aber leider nicht unbedingt so schnell...

Wenn das stimmt, ist das meiner Meinung nach ein Bug in Delphi. Ein Referenzzähler sollte immer mit 1 initialisiert sein, nicht mit 0.

[himitsu]

Zitat von Namenloser:

Wenn das stimmt, ist das meiner Meinung nach ein Bug in Delphi. Ein Referenzzähler sollte immer mit 1 initialisiert sein, nicht mit 0.

In soeinem Fall sollte Delphi besser eine (interne) lokale Variable generieren und Diese an den Parameter übergeben.

Und nein, denn wenn das schon zu Beginn 1 ist und man übergibt das Interface an eine Variable, dann wäre es danach 2.
Ist die Variable dann weg, wäre es aber immernoch 1 und würde niemals freigegeben.

[Namenloser]

Zitat von himitsu:

Zitat von Namenloser:

Wenn das stimmt, ist das meiner Meinung nach ein Bug in Delphi. Ein Referenzzähler sollte immer mit 1 initialisiert sein, nicht mit 0.

In soeinem Fall sollte Delphi besser eine (interne) lokale Variable generieren und Diese an den Parameter übergeben.

Das kommt auf dasselbe raus, was ich meine. Der Referenzzähler sollte immer bei 1 starten, denn irgendjemand muss ja eine Referenz auf das Objekt haben, ansonsten dürfte es gar nicht existieren. Und wenn es keine gibt, dann muss der Compiler eine generieren.

Ich habe in C schon manuelle Referenzzählung implementiert und dort habe ich es immer so gemacht:

Code:

typedef struct RefCounted {
    int refcount;
} RefCounted;

RefCounted* refcounted_new()
{
    RefCounted *obj = malloc(sizeof(RefCounted));
    obj->refcount = 1;
    return obj;
}

void refcounted_destroy(RefCounted *obj)
{
    free(obj);
}

void addref(RefCounted *obj)
{
    ++(obj->refcount);
}

void release(RefCounted *obj)
{
    --(obj->refcount);
    if (obj->refcount==0) {
        refcounted_destroy(obj);
    }
}


int main()
{
    RefCounted *obj = refcounted_new();
    // Hier KEIN addref(obj)

    blablabla_irgendwas_mit_obj_machen(obj);

    release(obj);
}

So sollte es der Compiler auch machen.

[jaenicke]

Das stimmt nicht, denn ein Objekt hat keine Interfacereferenzen.
Deshalb lässt sich das Problem nicht so einfach lösen.

[himitsu]

Zitat von jaenicke:

Das stimmt nicht, denn ein Objekt hat keine Interfacereferenzen.
Deshalb lässt sich das Problem nicht so einfach lösen.

Im ARC hat es das doch.

Wie gesagt, das Problem lässt sich sofort lösen, wenn der Compiler bei Übergabe von irgendwas an einen Const-Parameter eine Variable zwischenschaltet.
Immer wenn es da implizit von TObject zu Interface castet.

Bzw. bei TestFunction(TSomething.Irgendwas.Create) gibt es doch dieses Problem.
Bei TestFunction(Something.GetInterface) geht es, da Delphi aus diesem gemanagten Result einen Var-Parameter macht, welcher über eine generierte lokale Variable läuft.
Und bei TestFunction(Something.GetObject) würde ich jetzt das selbe Problem vermuten, aber hier ist man selber Schuld, da man Objekt- und gezählte Interfacereferenzen niemals vermischen sollte.

procedure TestFunction(const Reference: IInterface);

[Namenloser]

Zitat von jaenicke:

Das stimmt nicht, denn ein Objekt hat keine Interfacereferenzen.

Und?

[Delphi-Laie]

Entschuldigt bitte, daß ich dieses Thema reanimiere, aber ich fand keine Antwort auf meine Frage, und diese Diskussion paßt am besten.

In der Delphi-Hilfe steht, daß der Compiler bei (der Verwendung von) Konstantenpararametern den Code bei strukturierten und String-Parametern optimieren könne. Nur, was bedeutet "strukturiert"? Vermutlich bis wahrscheinlich das, was in C-Sprachen mit/als "struct" deklariert/definiert wird, also Records.

Lange Rede, zählen Arrays (die ja ebenfalls Daten strukturiert enthalten) auch zum Const-Optimierungspotential? Ich vermute, ja.