V4CC - Leaks

[Erne]

Il giorno 01-apr-10, alle ore 08:14, Ruslan Zasukhin ha scritto:

> On 3/30/10 12:33 PM, "Erne" <ernestogiannotta at tiscalinet.it> wrote:
>
> Erne,
>
> I need check this self deeply before comment.
> Few days please.

I know they'll be well spent! :-)

Meanwhile let me wish you and your cared ones an easter of serenity &  
happiness.

>
>
>>> Will be interesting to see this TIPs on the list Thorsten :)
>>
>> Here's the big problem, from what I've learned from Thorsten  
>> Valentina
>> DOES NOT abide by the memory management rules well estabilished for
>> the Cocoa environment.
>>
>> That is (from docs):
>> You take ownership of an object if you create it using a method whose
>> name begins with “alloc” or “new” or contains “copy” (for example,
>> alloc, newObject, or mutableCopy), or if you send it a retain  
>> message.
>
> This is apple docs :)
> About apple frameworks...

Of course... but every cocoa class (even self made) is expected to  
conform to these rules.
This is quite simple to accomplish I guess and can avoid confusion and  
uncertain behaviour for developer.

All this is going to become obsolete as more and more choose to drop  
support for 10.4 (Tiger) and decide to use garbage collection (I'm not  
yet using it but I've read that it has its gotchas too, expecially  
when it comes to dealloc resources)

>
>> If there's no clear rule it's very hard to play nice...
>
>> As you know I'm a big fan of Vale, so will take the pain to learn  
>> what
>> it takes to take good care of her
>> but if you are eager to lure others into her charms I strongly
>> recommend you teach her how to behave ;-)
>
> Well, I'd like to read tips from Thorsten here :)
>
> Because so far I do not see good where problem is.
>

Of course I'm not big expert, more of an absolute beginner expecially  
in this cocoa thing
but what I'm asking for is to simply follow the naming convention rules

> By your picture in mantis I see that was not unlocked objects of  
> class way,
> such as Table -> Field
>

for what I understand the responsible column of the instrument points  
to where the leak is generated

I solved my simple leak cases by releasing or autoreleasing the  
leaking object, it was straightforward as this

of course I can't be so sure it will be as simple for your much more  
complex code, but simple things such as NSUrl I guess not too hard to  
take care of ;-)

> We do this locks internally to get better speed.
>
> We do the same locks in V4RB.
>
> It needs to see if objects live, because top level object - db was not
> killed, or some bug in our destructors.
>
> Anyway, if all works right, this internal locks should be  
> transparent for
> you.
>


thanks always for you patient listening

Cool Runnings,
Erne.