On Tue, Jul 6, 2010 at 8:14 PM, Marcos Douglas wrote:
> On Tue, Jul 6, 2010 at 7:14 PM, Andrew Brunner
> wrote:
>> On Tue, Jul 6, 2010 at 5:09 PM, Graeme Geldenhuys
>> wrote:
>>> Even with a try..except, if you call MyObj.Free and it causes an
>>> exception, you are screwed either way and it wil
On 07/07/2010 02:14, Marcos Douglas wrote:
No, if the nesting is done properly you could guarantee that Obj2.Free
would be called even if Obj1.Free failed with some exception. And
further, nested exception handling offers safeguarding against such
memory leaks during destruction if done proper
On Tue, Jul 6, 2010 at 7:14 PM, Andrew Brunner
wrote:
> On Tue, Jul 6, 2010 at 5:09 PM, Graeme Geldenhuys
> wrote:
>> Even with a try..except, if you call MyObj.Free and it causes an
>> exception, you are screwed either way and it will always cause a
>> memory leak. Best is no notify the user som
On Tue, 6 Jul 2010 17:14:38 -0300
Marcos Douglas wrote:
> Well... I think use a name as CreateSpecialTMyObjectInstance() is very
> especific... but, as you said, in the end it is all about personal
> style.
Perhaps I have not made myself clear.
example (makes not much sense; just to explain my na
On 7 July 2010 00:09, Andrew Brunner wrote:
>>
> Whew, Ok. Years back Delphi (the experience I'm drawing on)
> Object.Free could not be done. Now that I know FPC does the check for
> nil I probably won't be using FreeAndNil anymore. But this raises a
> large concern for me. That is the EXTRA i
On Tue, Jul 6, 2010 at 5:09 PM, Graeme Geldenhuys
wrote:
> Even with a try..except, if you call MyObj.Free and it causes an
> exception, you are screwed either way and it will always cause a
> memory leak. Best is no notify the user some how, or crash out of the
> program, or fire the programmer f
On 7 July 2010 00:04, Andrew Brunner wrote:
>
> You got that right. Which is my point exactly. If free blows out w/o
> a nested exception handle to catch it... The entire object goes into
> limbo and will never be free and thus cause a memory leak.
Even with a try..except, if you call MyObj.Free
Andrew Brunner wrote:
It most certainly is not "safe". LOL. Free calls destroy.. Destroy
may contain other frees and routines... You cannot guarantee that free
will even return.
the point was to call .Free on an object that might not have been
initialized, not what Free ( or destroy, for the
On Tue, Jul 6, 2010 at 5:04 PM, Graeme Geldenhuys
wrote:
> I meant is as in it is safe to call MyObj.Free even if MyObj = nil. I
> answered based on the explicit question.
>
> But yes, in your example where MyObj was an instance, the code in the
> destructor could still trip you up if it caused a
On 6 July 2010 23:59, Andrew Brunner wrote:
>
> It most certainly is not "safe".
I meant is as in it is safe to call MyObj.Free even if MyObj = nil. I
answered based on the explicit question.
But yes, in your example where MyObj was an instance, the code in the
destructor could still trip you up
On Tue, Jul 6, 2010 at 4:41 PM, Graeme Geldenhuys
wrote:
> On 6 July 2010 19:51, Marcos Douglas wrote:
>>> That's the problematic one I think.
>>
>> Can an exception happen in Free method?! :-O
>
> Yes! I often have to debug those in our complex business objects.
>
You got that right. Which is
> Wrong again Andrew. Calling .Free is safe (even if the instance
> variable is nil) because internally it checks if the instance exists
> before continuing with calling .Destroy on that instance. Delphi 101.
> ;-)
It most certainly is not "safe". LOL. Free calls destroy.. Destroy
may contain
On 6 July 2010 19:51, Marcos Douglas wrote:
>> That's the problematic one I think.
>
> Can an exception happen in Free method?! :-O
Yes! I often have to debug those in our complex business objects.
--
Regards,
- Graeme -
___
fpGUI - a cross-plat
On 6 July 2010 18:42, Andrew Brunner wrote:
>>> Nope. If Obj2 failed to create you will have a problem with Obj2.Free.
>>
>> Nope. That's why it is free and not destroy.
>
> Double Nope. You cannot access methods of a nil object. Nil.Free
> will in-it-and-of-it cause a read access violation.
Wr
On Tue, Jul 6, 2010 at 4:09 PM, Reimar Grabowski wrote:
> On Tue, 6 Jul 2010 14:54:29 -0300
> Marcos Douglas wrote:
>
>> Like obj1.CreateObj() ? =)
> Sounds a little generic for my liking, but at least you can guess that
> there is something more going on than just returning a value, so, yes. :)
On Tue, 6 Jul 2010 14:54:29 -0300
Marcos Douglas wrote:
> Like obj1.CreateObj() ? =)
Sounds a little generic for my liking, but at least you can guess that there is
something more going on than just returning a value, so, yes. :)
I'd rather use something like obj2 := obj1.CreateSpecialTMyObjectI
On Tue, Jul 6, 2010 at 12:56 PM, Luiz Americo Pereira Camara
wrote:
> Marcos Douglas escreveu:
>>
>> Better:
>>
>> obj1 := nil;
>> obj2 := nil;
>> Try
>> obj1 := TMyObject.Create;
>> obj2 := TMyObject.Create;
>>
>> obj1.DoSomething1;
>> obj2.DoSomething2;
>> finally
>> obj1.Free;
>> obj2.Fre
On 06 Jul 2010, at 20:06, Marcos Douglas wrote:
> On Tue, Jul 6, 2010 at 2:55 PM, Jonas Maebe wrote:
>>
>> On 06 Jul 2010, at 19:51, Marcos Douglas wrote:
>>
>>> Can an exception happen in Free method?
>>
>> It can happen in Destroy, which is called by Free.
>
> And do not have medicine for
On Tue, Jul 6, 2010 at 2:55 PM, Jonas Maebe wrote:
>
> On 06 Jul 2010, at 19:51, Marcos Douglas wrote:
>
>> Can an exception happen in Free method?
>
> It can happen in Destroy, which is called by Free.
And do not have medicine for that, right?
Marcos Douglas
___
On 06 Jul 2010, at 19:51, Marcos Douglas wrote:
> Can an exception happen in Free method?
It can happen in Destroy, which is called by Free.
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinf
On Tue, Jul 6, 2010 at 2:04 PM, Reimar Grabowski wrote:
> On Tue, 6 Jul 2010 12:05:36 -0300
> Marcos Douglas wrote:
>
>> We talk about just *functions* or we talk about *methods* too?
> It is meant for 'method functions', too. But I don't follow that rule
> strictly and
> try to use a descriptiv
On Tue, Jul 6, 2010 at 1:39 PM, Marco van de Voort wrote:
> In our previous episode, Andrew Brunner said:
>> > obj1 := nil;
>> > obj2 := nil;
>> > Try
>> > ?obj1 := TMyObject.Create;
>> > ?obj2 := TMyObject.Create;
>> >
>> > ?obj1.DoSomething1;
>> > ?obj2.DoSomething2;
>> > finally
>> > ?obj1.Free
On Tue, 6 Jul 2010 12:05:36 -0300
Marcos Douglas wrote:
> We talk about just *functions* or we talk about *methods* too?
It is meant for 'method functions', too. But I don't follow that rule strictly
and try to use a descriptive name that indicates that a function effects
something outside its
In our previous episode, Andrew Brunner said:
> >> > ?obj1.Free;
> >> > ?obj2.Free;
> >> > end;
> >> >
> >> > The objectcs are protected. But is boring... :)
> >> > Everybody codify like that, afraid if resources are not available?
> >> >
> >>
> >> Nope. If Obj2 failed to create you will have a pro
On 06 Jul 2010, at 18:42, Andrew Brunner wrote:
> Double Nope. You cannot access methods of a nil object.
You can, as long as such methods are not virtual (and "free" is not a virtual
method).
> Nil.Free
> will in-it-and-of-it cause a read access violation.
This is what free does:
On Tue, Jul 6, 2010 at 11:39 AM, Marco van de Voort wrote:
> In our previous episode, Andrew Brunner said:
>> > obj1 := nil;
>> > obj2 := nil;
>> > Try
>> > ?obj1 := TMyObject.Create;
>> > ?obj2 := TMyObject.Create;
>> >
>> > ?obj1.DoSomething1;
>> > ?obj2.DoSomething2;
>> > finally
>> > ?obj1.Fre
In our previous episode, Andrew Brunner said:
> > obj1 := nil;
> > obj2 := nil;
> > Try
> > ?obj1 := TMyObject.Create;
> > ?obj2 := TMyObject.Create;
> >
> > ?obj1.DoSomething1;
> > ?obj2.DoSomething2;
> > finally
> > ?obj1.Free;
> > ?obj2.Free;
> > end;
> >
> > The objectcs are protected. But is b
On Tue, Jul 6, 2010 at 10:31 AM, Marcos Douglas wrote:
> Better:
>
> obj1 := nil;
> obj2 := nil;
> Try
> obj1 := TMyObject.Create;
> obj2 := TMyObject.Create;
>
> obj1.DoSomething1;
> obj2.DoSomething2;
> finally
> obj1.Free;
> obj2.Free;
> end;
>
> The objectcs are protected. But is boring.
Marcos Douglas escreveu:
Better:
obj1 := nil;
obj2 := nil;
Try
obj1 := TMyObject.Create;
obj2 := TMyObject.Create;
obj1.DoSomething1;
obj2.DoSomething2;
finally
obj1.Free;
obj2.Free;
end;
The objectcs are protected. But is boring... :)
Everybody codify like that, afraid if resource
On Tue, Jul 6, 2010 at 12:10 PM, Andrew Brunner
wrote:
>> Hum... I do not agree. Why not this? See..
>>
>> obj1:=TMyObject.Create;
>> obj2:=TMyObject.Create;
>> Try
>> Obj1.DoSomething1;
>> Obj2.DoSomething2;
>> Finally
>> FreeAndNil(Obj1);
>> FreeAndNil(Obj2);
>> end;
>>
>
> In your example
On Tue, Jul 6, 2010 at 9:22 AM, Michael Van Canneyt
wrote:
>
>
> On Tue, 6 Jul 2010, Graeme Geldenhuys wrote:
>
>> On 5 July 2010 23:17, Michael Van Canneyt wrote:
>>>
>>> I would even add to this that you need to guard for exceptions:
>>>
>>> A:=TSomeClass.Create;
>>> try
>>> // do stuff
>>> fin
On Tue, Jul 6, 2010 at 3:05 AM, spir wrote:
>> The object Parser creates obj through the line string.
>> If the *line* is broke, Parser do not can create an object and an
>> Exception is created; the *obj* never is nil because there are
>> exception handling.
>
> I do not see the problem, since ob
Michael, what do you think about the following popular nested
try-except-finally construct?
try
try
...
except
...
end;
finally
...
end;
My understanding of your last statement is the above construct is superfluous.
Did it what you mean? If yes, is it only true in objfpc mode?
>> obj1:=TMyObject.Create;
>> Try
>> obj2:=TMyObject.Create;
>> Try
>> Obj1.DoSomething1;
>> Obj2.DoSomething2;
>> Finally
>> FreeAndNil(Obj2);
>> end;
>> Finally
>> FreeAndNil(Obj1);
>> end;
>
> Hum... I do not agree. Why not this? See..
>
> obj1:=TMyObject.Create;
> obj2:=TMyOb
On Mon, Jul 5, 2010 at 9:07 PM, Reimar Grabowski wrote:
> On Mon, 5 Jul 2010 16:51:54 -0300
> Marcos Douglas wrote:
>
>> What do you mean "a function has effects is already bad"?
>> A function/procedure always has effects, don't?
>
> IMHO he means that a function should only return a value and no
On Mon, Jul 5, 2010 at 6:06 PM, Graeme Geldenhuys
wrote:
> On 5 July 2010 22:03, Marcos Douglas wrote:
>> The ask is:
>> If a function creates, inside, a object and there is no variable to
>> receive this pointer, will happen a memory leak?
>
> Yes you will have a memory leak. Easy way to test is
On 07/01/2010 05:46 AM, Simon Webster wrote:
Dear Free Pascallers,
I'm wanting to convert a Turbo Pascal program to fpc, to run
(ultimately) under linux, although I'm actually developing on a mac,
and using virtualbox to run ubuntu. The program in question is a
relatively large non OOP program w
On Tue, 6 Jul 2010, Graeme Geldenhuys wrote:
On 5 July 2010 23:17, Michael Van Canneyt wrote:
I would even add to this that you need to guard for exceptions:
A:=TSomeClass.Create;
try
// do stuff
finally
A.Free; Make sure it is freed, even in case of exception.
end;
Wouldn't it be nice
In our previous episode, Graeme Geldenhuys said:
> Wouldn't it be nice...
Ah, the kiss-of-death phrase for a new feature request :-)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On 5 July 2010 23:17, Michael Van Canneyt wrote:
>
> I would even add to this that you need to guard for exceptions:
>
> A:=TSomeClass.Create;
> try
> // do stuff
> finally
> A.Free; Make sure it is freed, even in case of exception.
> end;
Wouldn't it be nice if we had a try..except..finally st
40 matches
Mail list logo
