---

Hej NG

Hvad er egentlig forskellen på Free og Destroy?
Jeg er godt bekendt med, at man godt kan Free en komponent, som tidligere er 'freeed', uden at få
'nogen på hatten', hvilket ikke gælder for Destroy.
Hvorfor har man så også kommandoen Destroy ???

P.L.

---

"P.L." <jessie-peter@get2net.dk> wrote in message
news:9hiqem$5hc$1@news.inet.tele.dk...
> Hej NG
>
> Hvad er egentlig forskellen på Free og Destroy?
> Jeg er godt bekendt med, at man godt kan Free en komponent, som tidligere
er
> 'freeed', uden at få
> 'nogen på hatten', hvilket ikke gælder for Destroy.
> Hvorfor har man så også kommandoen Destroy ???
>

Destroy er den, der gør det hårde arbejde, idet en free (og brug ALTID den)
blot undersøger om p <> nil og kun kalder p.destroy hvis dette er tilfældet
og ellers ikke har nogen effekt, hvis altså programmøren af alle de klasser
der nedarves fra ikke har dummet sig (reimplementeret free).

ex:
procedure TObject.Free;
begin
// Self er jo en parameter der altid overføres implicit!
if self <> nil then self.destroy;
end;

For dem der hellere vil have asm-versione, er free er i virkeligheden
implementeret som:
asm
// EAX indeholder her pointeren, der svarer til
self
TEST EAX,EAX // <> nil kontrollen (nil er pt. defineret som 0
[nul] )
JE @@exit // ...hvis nil så hop ud
MOV ECX,[EAX] // Hvis nogen lige ved hvorfor så...!?!?
MOV DL,1 // ...
CALL dword ptr [ECX].vmtDestroy // Call destroy
@@exit:
end;

Hvilket også vil sige at du altid skal huske at sætte din variabel til nil
efter et kald til free ellers vil det være ligegyldigt om du kalder free
eller destroy - resultatet vil være en fejl! (Dog ikke den samme fejl, men
det er jo for så vidt sagen uvedkommende :) )

Og hvis vi så lige skal forklare hvorfor man ikke blot har lavet en destroy
der fungerer som free (altså undersøger <> nil først) så skyldes det at det
ikke er muligt at lave destroy virtual (hvilket man jo gerne vil så man
senere i hierarkiet har mulighed for at override den oprindelige) og
samtidig give mulighed for at undersøge om self <> nil. - Det var måske ikke
lige den mest forklarende tekst, men det vil vist føre lidt for vidt omkring
hvis det skulle forklares til bunds (måske man skulle forske lidt mere i det
og skrive en artikel om det til pythia.dk).


Claus

PS: Nå det var vist en længere sludder, men hva' f* det skal der jo også
være plads til!

PSPS: Hvis nogen har nogen kommentarer er de meget velkomne, som sagt kunne
jeg godt finde på at skrive en kort artikel om emnet.
--
Claus Christiansen, TeamD member <cch@unipeople.dk>

Pythia: http://www.pythia.dk/
Personal: http://www.bigfoot.com/~kruc
============================================-------------------------
"Computers are useless. They can only give you answers."
-- Pablo Picasso (1881-1973)

---

Tak Claus

Den må jeg hellere tykke på

PL

"Claus Christiansen" <cch@unipeople.dk> skrev i en meddelelse
news:eP7%6.575$DJ5.80311@news010.worldonline.dk...
> "P.L." <jessie-peter@get2net.dk> wrote in message
> news:9hiqem$5hc$1@news.inet.tele.dk...
> > Hej NG
> >
> > Hvad er egentlig forskellen på Free og Destroy?
> > Jeg er godt bekendt med, at man godt kan Free en komponent, som tidligere
> er
> > 'freeed', uden at få
> > 'nogen på hatten', hvilket ikke gælder for Destroy.
> > Hvorfor har man så også kommandoen Destroy ???
> >
>
> Destroy er den, der gør det hårde arbejde, idet en free (og brug ALTID den)
> blot undersøger om p <> nil og kun kalder p.destroy hvis dette er tilfældet
> og ellers ikke har nogen effekt, hvis altså programmøren af alle de klasser
> der nedarves fra ikke har dummet sig (reimplementeret free).
>
> ex:
> procedure TObject.Free;
> begin
> // Self er jo en parameter der altid overføres implicit!
> if self <> nil then self.destroy;
> end;
>
> For dem der hellere vil have asm-versione, er free er i virkeligheden
> implementeret som:
> asm
> // EAX indeholder her pointeren, der svarer til
> self
> TEST EAX,EAX // <> nil kontrollen (nil er pt. defineret som 0
> [nul] )
> JE @@exit // ...hvis nil så hop ud
> MOV ECX,[EAX] // Hvis nogen lige ved hvorfor så...!?!?
> MOV DL,1 // ...
> CALL dword ptr [ECX].vmtDestroy // Call destroy
> @@exit:
> end;
>
> Hvilket også vil sige at du altid skal huske at sætte din variabel til nil
> efter et kald til free ellers vil det være ligegyldigt om du kalder free
> eller destroy - resultatet vil være en fejl! (Dog ikke den samme fejl, men
> det er jo for så vidt sagen uvedkommende :) )
>
> Og hvis vi så lige skal forklare hvorfor man ikke blot har lavet en destroy
> der fungerer som free (altså undersøger <> nil først) så skyldes det at det
> ikke er muligt at lave destroy virtual (hvilket man jo gerne vil så man
> senere i hierarkiet har mulighed for at override den oprindelige) og
> samtidig give mulighed for at undersøge om self <> nil. - Det var måske ikke
> lige den mest forklarende tekst, men det vil vist føre lidt for vidt omkring
> hvis det skulle forklares til bunds (måske man skulle forske lidt mere i det
> og skrive en artikel om det til pythia.dk).
>
>
> Claus
>
> PS: Nå det var vist en længere sludder, men hva' f* det skal der jo også
> være plads til!
>
> PSPS: Hvis nogen har nogen kommentarer er de meget velkomne, som sagt kunne
> jeg godt finde på at skrive en kort artikel om emnet.
> --
> Claus Christiansen, TeamD member <cch@unipeople.dk>
>
> Pythia: http://www.pythia.dk/
> Personal: http://www.bigfoot.com/~kruc
> ============================================-------------------------
> "Computers are useless. They can only give you answers."
> -- Pablo Picasso (1881-1973)
>
>

---

> blot undersøger om p <> nil og kun kalder p.destroy hvis dette er
tilfældet
> og ellers ikke har nogen effekt, hvis altså programmøren af alle de
klasser

Det er nu egentligt lidt underligt at man ikke bliver straffet for at kalde
"free" gentagne gange.
Hvis det givne object er blevet freed burde det ikke gå godt at kalde "free"
på den igen (det gør det så heller ikke, man får fejl, men ikke helt så
konsekvent som man umiddelbart forestiller sig man burde). Oh well.

Thomas

---

> Det er nu egentligt lidt underligt at man ikke bliver straffet for at
kalde
> "free" gentagne gange.
> Hvis det givne object er blevet freed burde det ikke gå godt at kalde
"free"
> på den igen (det gør det så heller ikke, man får fejl, men ikke helt så
> konsekvent som man umiddelbart forestiller sig man burde). Oh well.


Nej, det er *så udpræget* en fejl at kalde Free 2 gange efter hinanden,
men det er jo klart for enhver

Problemet er, at man ikke kan se om man har at gøre med en død pointer, når
man
kalder Free. Til gengæld vil du aldrig få en fejl når du kalder Free fra en
Nil
pointer.

TObject(Nil).Free; // Giver ingen fejl.

TObject(Pointer(243)).Free; // Giver grumme fejl

Så der er faktisk tale om en konsekvent måde at gøre tingene på.

--
Regards, Christian Iversen [FIDUSO]
Flawless.Dk: [http://domains.flawless.dk]
Do you have a (broken?) IBM75GXP Drive?
Please go to [http://ibm.flawless.dk]

---

"Christian Iversen" <iversen@it.dk> wrote in message
news:9hns82$18js$1@news.cybercity.dk...
>> Det er nu egentligt lidt underligt at man ikke bliver straffet for at
>> kalde "free" gentagne gange.
>> Hvis det givne object er blevet freed burde det ikke gå godt at kalde
>> "free" på den igen (det gør det så heller ikke, man får fejl, men ikke
>> helt så konsekvent som man umiddelbart forestiller sig man burde).
>> Oh well.
>
>
> Nej, det er *så udpræget* en fejl at kalde Free 2 gange efter hinanden,
> men det er jo klart for enhver

Ja!! :)

> Problemet er, at man ikke kan se om man har at gøre med en død pointer,
> når man kalder Free.

Med mindre altså at det var muligt at lave en metode, der kunne ændre i
indholdet af den variabel, der blev brug til at kalde den med. Det ville
umiddelbart være noget rod, hvis det var lavet på den måde - så det er jo
nok årsagen til at det ikke er det :)

ex:
procedure TObject.Free(var AObject: TObject)
begin
if self = AObject then
begin
if self <> nil then self.destroy;
AObject := nil;
end
else raise Exception...
end;

...
var
p: TObject;
begin
...
p.free(p);
...


> Til gengæld vil du aldrig få en fejl når du kalder Free fra en Nil-
> pointer.

Fordi free er en static (ellers ville det jo kræve et opslag i VMT'en, der
jo netop tilhører den instans af klassen, der netop er free'et og så...)
metode, der kan kaldes uden at at der eksisterer en instans af klassen.


> TObject(Nil).Free; // Giver ingen fejl.
>
> TObject(Pointer(243)).Free; // Giver grumme fejl
>
> Så der er faktisk tale om en konsekvent måde at gøre tingene på.

Korrekt!! - netop pga. implementeringen af free.

--
Claus Christiansen, TeamD member <cch@unipeople.dk>

Pythia: http://www.pythia.dk/
Personal: http://www.bigfoot.com/~kruc
============================================-------------------------
"Computers are useless. They can only give you answers."
- Pablo Picasso (1881-1973)

---

> >> Det er nu egentligt lidt underligt at man ikke bliver straffet for at
> >> kalde "free" gentagne gange.
> >> Hvis det givne object er blevet freed burde det ikke gå godt at kalde
> >> "free" på den igen (det gør det så heller ikke, man får fejl, men ikke
> >> helt så konsekvent som man umiddelbart forestiller sig man burde).
> >> Oh well.
> >
> >
> > Nej, det er *så udpræget* en fejl at kalde Free 2 gange efter hinanden,
> > men det er jo klart for enhver
>
> Ja!! :)

Ellers ville det også se dumt ud :)

>
> > Problemet er, at man ikke kan se om man har at gøre med en død pointer,
> > når man kalder Free.
>
> Med mindre altså at det var muligt at lave en metode, der kunne ændre i
> indholdet af den variabel, der blev brug til at kalde den med. Det ville
> umiddelbart være noget rod, hvis det var lavet på den måde - så det er jo
> nok årsagen til at det ikke er det :)

Præcis!

Alle ejer-/ansvarsforhold ville jo blive ødelagt

> ex:
> procedure TObject.Free(var AObject: TObject)
> begin
> if self = AObject then
> begin
> if self <> nil then self.destroy;
> AObject := nil;
> end
> else raise Exception...
> end;
>
> ...
> var
> p: TObject;
> begin
> ...
> p.free(p);
> ...

Ja netop... hvis nu nogen har taget en kopi af din pointer undervejs...
BOOOM!

> > Til gengæld vil du aldrig få en fejl når du kalder Free fra en Nil-
> > pointer.
>
> Fordi free er en static (ellers ville det jo kræve et opslag i VMT'en, der
> jo netop tilhører den instans af klassen, der netop er free'et og så...)
> metode, der kan kaldes uden at at der eksisterer en instans af klassen.

Ellers kunne man lave den sådan:

Class Procedure TObject.Free(Const AObject : TObject);
Begin
If Assigned(AOBject) Then
AObject.Destroy
End;

DET ville virke, men se godt dumt ud

>
> > TObject(Nil).Free; // Giver ingen fejl.
> >
> > TObject(Pointer(243)).Free; // Giver grumme fejl
> >
> > Så der er faktisk tale om en konsekvent måde at gøre tingene på.
>
> Korrekt!! - netop pga. implementeringen af free.

Just eksakt :)

--
Regards, Christian Iversen [FIDUSO]
Flawless.Dk: [http://domains.flawless.dk]
Do you have a (broken?) IBM75GXP Drive?
Please go to [http://ibm.flawless.dk]

---

"Christian Iversen" <iversen@it.dk> wrote in message
news:9ho4h9$1lm6$1@news.cybercity.dk...
<klip>
> Alle ejer-/ansvarsforhold ville jo blive ødelagt
>
> > ex:
> > procedure TObject.Free(var AObject: TObject)
> > begin
> > if self = AObject then
> > begin
> > if self <> nil then self.destroy;
> > AObject := nil;
> > end
> > else raise Exception...
> > end;
> >
> > ...
> > var
> > p: TObject;
> > begin
> > ...
> > p.free(p);
> > ...
>
> Ja netop... hvis nu nogen har taget en kopi af din pointer undervejs...
> BOOOM!

Præcis!, - men vi kan jo dårligt blive med at sidde og give hinanden ret
hele tiden (selv det jo er meget rart at blive bekræftiget en gang i
mellem - så jeg vil nok insistere på at det resulterer i BOOOOM!!! i stedet
:) )


> > > Til gengæld vil du aldrig få en fejl når du kalder Free fra en Nil-
> > > pointer.
> >
> > Fordi free er en static (ellers ville det jo kræve et opslag i VMT'en,
der
> > jo netop tilhører den instans af klassen, der netop er free'et og så...)
> > metode, der kan kaldes uden at at der eksisterer en instans af klassen.
>
> Ellers kunne man lave den sådan:
>
> Class Procedure TObject.Free(Const AObject : TObject);
> Begin
> If Assigned(AOBject) Then
> AObject.Destroy
> End;
>
> DET ville virke, men se godt dumt ud

Men det bliver den jo sådan set ikke mindre static af! ;)

> >
> > > TObject(Nil).Free; // Giver ingen fejl.
> > >
> > > TObject(Pointer(243)).Free; // Giver grumme fejl
> > >
> > > Så der er faktisk tale om en konsekvent måde at gøre tingene på.
> >
> > Korrekt!! - netop pga. implementeringen af free.
>
> Just eksakt :)

Ja, ikke!!

Claus

--
Claus Christiansen, TeamD member <cch@unipeople.dk>

Pythia: http://www.pythia.dk/
Personal: http://www.bigfoot.com/~kruc
============================================-------------------------
"Computers are useless. They can only give you answers."
-- Pablo Picasso (1881-1973)

---

> Fordi free er en static (ellers ville det jo kræve et opslag i VMT'en, der
> jo netop tilhører den instans af klassen, der netop er free'et og så...)
> metode, der kan kaldes uden at at der eksisterer en instans af klassen.

Det tænkte jeg også først..
Men free er ikke elkæret Virtual i TObject.
Og hvis den var statisk ville self også kun referere til klasse navnet
(chekkede hjælpen).

> > Så der er faktisk tale om en konsekvent måde at gøre tingene på.

Jeg testede det på at "free" en button 2 gange...
Jeg fik ikke en fejl før jeg lukkede programmet.


Thomas

---

"Thomas Schulz" <dk_sz@hotmail.com> wrote in message
news:9hpmq6$7o8$1@news.inet.tele.dk...
> > Fordi free er en static (ellers ville det jo kræve et opslag i VMT'en,
der
> > jo netop tilhører den instans af klassen, der netop er free'et og så...)
> > metode, der kan kaldes uden at at der eksisterer en instans af klassen.
>
> Det tænkte jeg også først..
> Men free er ikke elkæret Virtual i TObject.

Det er jo sådan set også det vi siger! - og når den ikke er virtual/dynamisk
er den statisk.

> Og hvis den var statisk ville self også kun referere til klasse navnet
> (chekkede hjælpen).

I min D4P hjælp står der ingen steder (AFAIK) noget om at self i en statisk
metode ikke skulle henvise til objektet. Men der står derimod at self i en
class method vil henvise til klassen, men class methods og static er ikke
det samme.

> > > Så der er faktisk tale om en konsekvent måde at gøre tingene på.
>
> Jeg testede det på at "free" en button 2 gange...
> Jeg fik ikke en fejl før jeg lukkede programmet.

Hvilket OS???

Claus

--
Claus Christiansen, TeamD member <cch@unipeople.dk>

Pythia: http://www.pythia.dk/
Personal: http://www.bigfoot.com/~kruc
============================================-------------------------
"Computers are useless. They can only give you answers."
-- Pablo Picasso (1881-1973)

---

> > > > Så der er faktisk tale om en konsekvent måde at gøre tingene på.
> >
> > Jeg testede det på at "free" en button 2 gange...
> > Jeg fik ikke en fejl før jeg lukkede programmet.
>
> Hvilket OS???

Næænej, hvis man prøver at kalde Free på en bestemt TButton 2 gange,
er problemet at den TForm der ejer den givne knap, bagefter prøver
at kalde Free på selvsamme reference. Dette går aldrig godt, da det
ikke er en Nil-pointer, men en død pointer!!

BOOOM!

--
Regards, Christian Iversen [FIDUSO]
Flawless.Dk: [http://domains.flawless.dk]
Do you have a (broken?) IBM75GXP Drive?
Please go to [http://ibm.flawless.dk]

---

> Næænej, hvis man prøver at kalde Free på en bestemt TButton 2 gange,
> er problemet at den TForm der ejer den givne knap, bagefter prøver
> at kalde Free på selvsamme reference. Dette går aldrig godt, da det
> ikke er en Nil-pointer, men en død pointer!!
>
> BOOOM!


Ja

men hvorfor sker det samme "boom" ikke når du selv kalder free 2 gange på en
tbutton e.g. created runtime


Thomas

---

> > Næænej, hvis man prøver at kalde Free på en bestemt TButton 2 gange,
> > er problemet at den TForm der ejer den givne knap, bagefter prøver
> > at kalde Free på selvsamme reference. Dette går aldrig godt, da det
> > ikke er en Nil-pointer, men en død pointer!!
> >
> > BOOOM!
>
> Ja
>
> men hvorfor sker det samme "boom" ikke når du selv kalder free 2 gange på
en
> tbutton e.g. created runtime


2 muligheder:

- RENT held!

- Du har ikke angivet DinForm som Owner til din TButton, og derfor er det
dit ansvar
at kalde Free på den (men naturligvis ikke to gange). Der er her tale om
50% held!

--
Regards, Christian Iversen [FIDUSO]
Flawless.Dk: [http://domains.flawless.dk]
Do you have a (broken?) IBM75GXP Drive?
Please go to [http://ibm.flawless.dk]

---

> Det er jo sådan set også det vi siger! - og når den ikke er
virtual/dynamisk
> er den statisk.


sorry
det er fordi jeg vorveksler statisk med static i C++ og Java
my bad


> > Jeg testede det på at "free" en button 2 gange...
> > Jeg fik ikke en fejl før jeg lukkede programmet.
>
> Hvilket OS???

Win2K SP2
Delphi5 Pro SP1 (den nyeste)


Thomas
>
>
>

---

"Thomas Schulz" <dk_sz@hotmail.com> wrote in message
news:9hqsin$3hs$1@news.inet.tele.dk...
> > Det er jo sådan set også det vi siger! - og når den ikke er
> virtual/dynamisk
> > er den statisk.
>
>
> sorry
> det er fordi jeg vorveksler statisk med static i C++ og Java
> my bad

Det forventede jeg også :)

> > > Jeg testede det på at "free" en button 2 gange...
> > > Jeg fik ikke en fejl før jeg lukkede programmet.
> >
> > Hvilket OS???
>
> Win2K SP2
> Delphi5 Pro SP1 (den nyeste)

hmm, W2K SP1 D4P, og her går den ned umiddelbart efter 2. free

Claus