On 02/12/2010 18:26, David Emerson wrote:
Wouldn't it be nice if we had a try..except..finally statement
supported in FPC. All-in-one.
We do: it is called "try try"
try try
// ...
except
// ...
finally
// ...
I wonder where the *big* advantage of this "try..except..finally" is?
Look
> Wouldn't it be nice if we had a try..except..finally statement
> supported in FPC. All-in-one.
We do: it is called "try try"
try try
// ...
except
// ...
finally
// ...
Okay, so maybe that's slightly nonstandard, but I'd rather use this awkwardness
than add an even more awkward extra in
On Wed, 7 Jul 2010, Andrew Brunner wrote:
Well... I think CGI gateway is a good way. If the real app (FCGI) have
troubles, I can change the URL that the CGI (gateway) uses to call the
real app and to point to another app (in other server, e.g.). What do
you think about it?
I think it would b
In our previous episode, Andrew Brunner said:
> > Well... I think CGI gateway is a good way. If the real app (FCGI) have
> > troubles, I can change the URL that the CGI (gateway) uses to call the
> > real app and to point to another app (in other server, e.g.). What do
> > you think about it?
>
>
On 7 July 2010 15:09, Graeme Geldenhuys wrote:
> On 7 July 2010 15:44, Andrew Brunner wrote:
>>
>> As far as *HUGE* problem. Having to restart my server would be huge..
>> Especially in high scale, high available production environments.
>
> You don't have to restart the server (hardware), only t
On Wed, Jul 7, 2010 at 12:37 PM, José Mejuto wrote:
> Hello FPC-Pascal,
>
> Wednesday, July 7, 2010, 4:49:03 PM, you wrote:
>
> MD> Exactly.
> MD> I just wonder how you do in web apps that are not CGI. As I said
> MD> earlier in an email here:
> MD> http://lists.freepascal.org/lists/fpc-pascal/201
Hello FPC-Pascal,
Wednesday, July 7, 2010, 4:49:03 PM, you wrote:
MD> Exactly.
MD> I just wonder how you do in web apps that are not CGI. As I said
MD> earlier in an email here:
MD> http://lists.freepascal.org/lists/fpc-pascal/2010-July/025902.html
MD> ...but I guess that is to be reviewed, perha
On Wed, Jul 7, 2010 at 11:50 AM, Andrew Brunner
wrote:
>> Well... I think CGI gateway is a good way. If the real app (FCGI) have
>> troubles, I can change the URL that the CGI (gateway) uses to call the
>> real app and to point to another app (in other server, e.g.). What do
>> you think about it?
> Well... I think CGI gateway is a good way. If the real app (FCGI) have
> troubles, I can change the URL that the CGI (gateway) uses to call the
> real app and to point to another app (in other server, e.g.). What do
> you think about it?
I think it would be worth discussing what can be done or a
On Wed, Jul 7, 2010 at 11:35 AM, José Mejuto wrote:
> Hello FPC-Pascal,
>
> Wednesday, July 7, 2010, 3:48:13 PM, you wrote:
>
> AB> Martin, I didn't get to the end of your email because I find that
> AB> first major part - part and parcel of why Delphi failed as a language.
> AB> It became unviab
On Wed, Jul 7, 2010 at 10:44 AM, Andrew Brunner
wrote:
>
> Grame, no more caveats. If Unmount had memory that needed to be
> released then the same methodology stands. Disk1.Unmount was placed
> there to prove a point. That w/o handling Obj2.Free would never be
> called in context (the outstand
On Wed, Jul 7, 2010 at 10:28 AM, Martin wrote:
> On 07/07/2010 14:14, Marcos Douglas wrote:
>>
>> Here we have a big problem if the program is a web app using FastCGI.
>> In this case, what we do?
>>
>
> Write as much info as you have to the servers log file => so you can fix the
> app.
> Return a
Hello FPC-Pascal,
Wednesday, July 7, 2010, 3:48:13 PM, you wrote:
AB> Martin, I didn't get to the end of your email because I find that
AB> first major part - part and parcel of why Delphi failed as a language.
AB> It became unviable because exception handling and blow-outs. Which
AB> in turn we
On 7 July 2010 15:44, Andrew Brunner wrote:
>
> As far as *HUGE* problem. Having to restart my server would be huge..
> Especially in high scale, high available production environments.
You don't have to restart the server (hardware), only the application
or service (app server software). As in a
On Wed, Jul 7, 2010 at 8:34 AM, Martin wrote:
> Had you only read to the end of my mail. You are deliberately ignoring
> part of what I wrote and the blame me for the remainder being incomplete?
>
> I clearly stated that there are cases where "free" can raise a valid
> exception, and that the
On Wed, Jul 7, 2010 at 8:37 AM, Graeme Geldenhuys
wrote:
>> procedure TObj1.Free;
>> begin
>> Try
>> Disk1.Unmount;
>> Except
>> On E:Exception do begin
>> // Some case stuff here
>> end;
>> end;
>> Inherited Destroy;
>> end;
>>
>
> With the exception of a possible memory leak
On 7 July 2010 15:25, Andrew Brunner wrote:
>
> procedure TObj1.Free;
> begin
> Disk1.Unmount; <<< The disk object is missing now b/c a network failure;
> Inherited Destroy;
> end;
>
> procedure TObj1.Free;
> begin
> Try
> Disk1.Unmount;
> Except
> On E:Exception do begin
> // Some
On 07/07/2010 14:25, Andrew Brunner wrote:
On Wed, Jul 7, 2010 at 8:05 AM, Martin wrote:
if " obj1.free; " crashes, then yes obj2 is not going to be released. But as
explained in this and my last mail: It should not be attempted to be
released.
Martin, I can't disagree more. I find
On 07/07/2010 14:14, Marcos Douglas wrote:
On Wed, Jul 7, 2010 at 9:54 AM, Martin wrote:
[...snip...]
With an exception like this, the rule is: Do as little as you can.
Everything you do can make it worse. Call a function that relies on as
little data as possible, and tries to simple save
On Wed, Jul 7, 2010 at 10:05 AM, Martin wrote:
> On 07/07/2010 13:54, Martin wrote:
>>
>> On 07/07/2010 13:30, Andrew Brunner wrote:
>>>
>>> Ok. I think I understand the discrepancy in our reasoning. The issue
>>> is when exceptions are raised during Obj.Free. I think it would help
>
>
>>
On Wed, Jul 7, 2010 at 8:05 AM, Martin wrote:
>
> if " obj1.free; " crashes, then yes obj2 is not going to be released. But as
> explained in this and my last mail: It should not be attempted to be
> released.
>
Martin, I can't disagree more. I find it completely ludicrous that if
obj1.free rais
On Wed, Jul 7, 2010 at 9:54 AM, Martin wrote:
>
> [...snip...]
>
> With an exception like this, the rule is: Do as little as you can.
> Everything you do can make it worse. Call a function that relies on as
> little data as possible, and tries to simple save all user-data to an
> emergency file. T
On 07/07/2010 13:54, Martin wrote:
On 07/07/2010 13:30, Andrew Brunner wrote:
Ok. I think I understand the discrepancy in our reasoning. The issue
is when exceptions are raised during Obj.Free. I think it would help
UninitializedPointerToRandomAddress := SomeValue;
You may have change
On 07/07/2010 13:30, Andrew Brunner wrote:
On Wed, Jul 7, 2010 at 2:09 AM, Graeme Geldenhuys
wrote:
Op 2010-07-07 03:32, Martin het geskryf:
And in the 2nd case, mem leaks are no worry => the app is going to be
closed, mem will be freed by the OS.
[...snip...]
The whole memory man
On Wed, Jul 7, 2010 at 9:30 AM, Andrew Brunner
wrote:
> Ok. I think I understand the discrepancy in our reasoning. The issue
> is when exceptions are raised during Obj.Free. I think it would help
> if you would assume that all exceptions raised in Obj.Free were
> handled - since my assertion is
On Wed, Jul 7, 2010 at 2:09 AM, Graeme Geldenhuys
wrote:
> Op 2010-07-07 03:32, Martin het geskryf:
>>
>> And in the 2nd case, mem leaks are no worry => the app is going to be
>> closed, mem will be freed by the OS.
>>[...snip...]
>>
>> The whole memory management could be corrupted. Trying to fre
Op 2010-07-07 05:25, Andrew Brunner het geskryf:
> So just make sure the Destroy methods free what they are supposed to free.
What if that was the cause of the exception in the first place. :-)
eg: Exception occurs in the destructor before all resource could be freed.
Regards,
- Graeme -
--
Op 2010-07-07 03:32, Martin het geskryf:
>
> And in the 2nd case, mem leaks are no worry => the app is going to be
> closed, mem will be freed by the OS.
>[...snip...]
>
> The whole memory management could be corrupted. Trying to free
> memory could just cause more and more exceptions.
That
Op 2010-07-07 00:14, Andrew Brunner het geskryf:
>
> No, if the nesting is done properly you could guarantee that Obj2.Free
> would be called even if Obj1.Free failed with some exception.
No matter how many nested try..except or try..finally blocks you have, if
you are trying to free the instance
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
?
Thanks.
- Original Message
From: Michael Van Canneyt
To: FPC-Pascal users discussions
Sent: Tue, July 6, 2010 7:22:36 PM
Subject: Re: [fpc-pascal] methods of an object to create others objects
On Tue, 6 Jul 2010, Graeme Geldenhuys wrote:
> On 5 July 2010 23:17, Michael Van Cann
>> 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 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
On Mon, 5 Jul 2010 16:51:54 -0300
Marcos Douglas wrote:
> >> Why I ask this:
> >> If not exists the variable obj2 in call obj1.createObj will happen a
> >> memory leak, right? Because there is not variable to release.
> >
> > Do you mean using a function as a statement? (for its so-called "side
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 not change the
state of an object, a variable or any other program s
If Memory allocation is the point of discussion and you need to create
objects ...
You should nest the creations in order of usage.
In your declarations you needed bot Object1 and Object2 as TMyObject;
That said the proper usage would be:
obj1:=TMyObject.Create;
Try
obj2:=TMyObject.Create;
T
On Mon, 5 Jul 2010, 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 to enable the
heaptr
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 to enable the
heaptrc unit (compiler option -gh). On terminating t
On Mon, 5 Jul 2010 17:46:39 -0300
Marcos Douglas wrote:
> On Mon, Jul 5, 2010 at 5:30 PM, Mattias Gaertner
> wrote:
> >
> > No. This will create a mem leak.
>
> Thanks Mattias, I expect that...
>
>
> On Mon, Jul 5, 2010 at 5:39 PM, Martin wrote:
> >
> > that is the same as if you wrote
> >
>
On Mon, Jul 5, 2010 at 5:30 PM, Mattias Gaertner
wrote:
>
> No. This will create a mem leak.
Thanks Mattias, I expect that...
On Mon, Jul 5, 2010 at 5:39 PM, Martin wrote:
>
> that is the same as if you wrote
>
> TsomeObject.create;
>
> without assigning the created object to a variable. Both
On 05/07/2010 21:26, Marcos Douglas wrote:
If I have a variable myObj, I can do this:
someObj := myObj.createObj;
This is the same:
someObj := TsomeObject.create;
Rigth?
But if a remove the variable *someObj* and call like this:
myObj.createObj; // I _removed_ the *someObj* here!!!
What will
On Mon, 5 Jul 2010 17:26:52 -0300
Marcos Douglas wrote:
>[...]
> But if a remove the variable *someObj* and call like this:
> myObj.createObj; // I _removed_ the *someObj* here!!!
>
> What will happen with the "result" variable? Is it released by the compiler?
No. This will create a mem leak.
On Mon, Jul 5, 2010 at 5:14 PM, Martin wrote:
>
> That would be, if a crash happens inside obj1.createObj? Because otherwise
> the obj is stored in obj2.
>
> If it happens in there, then handle it in there => there is result as
> variable.
>
> function TMyObject.creatObj : TSomeObj;
> begin
> res
On 05/07/2010 21:03, Marcos Douglas wrote:
I use this technique a lot, but thanks :) Unfortunately, this is not
the *problem*.
The ask is:
If a function creates, inside, a object and there is no variable to
receive this pointer, will happen a memory leak?
In my eg before, this is Okay:
obj2 :=
Hi Martin
On Mon, Jul 5, 2010 at 4:33 PM, Martin wrote:
> On 05/07/2010 19:48, Marcos Douglas wrote:
>>
>> We can to use methods of an object to create others objects, or this
>> is a bad programming practice?
>> eg:
>> var
>> obj1, obj2: TmyObject;
>> begin
>> obj1 := tobj1.create; //ok
>>
On Mon, Jul 5, 2010 at 4:07 PM, spir wrote:
> On Mon, 5 Jul 2010 15:48:40 -0300
> Marcos Douglas wrote:
>
> Questions of style: just a personal opinion.
>
>> We can to use methods of an object to create others objects, or this
>> is a bad programming practice?
>> eg:
>> var
>> obj1, obj2: TmyOb
On 05/07/2010 19:48, Marcos Douglas wrote:
We can to use methods of an object to create others objects, or this
is a bad programming practice?
eg:
var
obj1, obj2: TmyObject;
begin
obj1 := tobj1.create; //ok
obj2 := obj1.createObj; // is this recommended?
This is used very often like
On Mon, 5 Jul 2010 15:48:40 -0300
Marcos Douglas wrote:
Questions of style: just a personal opinion.
> We can to use methods of an object to create others objects, or this
> is a bad programming practice?
> eg:
> var
> obj1, obj2: TmyObject;
> begin
> obj1 := tobj1.create; //ok
> obj2 := o
We can to use methods of an object to create others objects, or this
is a bad programming practice?
eg:
var
obj1, obj2: TmyObject;
begin
obj1 := tobj1.create; //ok
obj2 := obj1.createObj; // is this recommended?
try
//...
finally
obj1.free;
obj2.free;
end;
end;
Why I ask this
84 matches
Mail list logo
