Re: [Vala] Change in 0.23.1 for array ownership and .length parameter

[Tal Hadad <tal_hd hotmail com>]

> That would be a memory leak.
No it wouldn't:
If the "if" statement is false, then it should delete it in the end of the block.

You might afraid the complicity of valac calculation.
That could be resolved - using two C variables - one for owned and one for unowned.
The owned always deleted at the end of the block, the trick is that this C variable is
set to null when transferring ownership.

If an owned "bar" was defined outside the block, I already said you're right and it
should be null in when outside the block(e.g. class field), since there's no way to
automate this safely.

I know it may add a minor complicity, but it just seems rational to use an object with
"unowned" access after transferring it to something else, since passing ownership
privilege doesn't means forgetting a reference.

I suppose that most Vala programmer solve this(including me) problem by saving
this variable in different unowned variable, but this is not intuitive(especially for a
new language) and may raise many bugs.

Tal

Date: Thu, 9 Jan 2014 21:04:16 +0100
Subject: Re: [Vala] Change in 0.23.1 for array ownership and .length parameter
From: lethalman88 gmail com
To: tal_hd hotmail com
CC: vala-list gnome org

That would be a memory leak.

On Thu, Jan 9, 2014 at 7:01 PM, Tal Hadad <tal_hd hotmail com> wrote:

> What about:

>

> if (foo) {

>    bar = (owned) ar;

> }

> // what now

>

> This behavior is confusing.

It would be unowned, even if in "if" statement, just like I suggest.



Tal



> Date: Tue, 7 Jan 2014 09:24:40 +0100

> From: lethalman88 gmail com

> To: vala-list gnome org

> Subject: Re: [Vala] Change in 0.23.1 for array ownership and .length  parameter

>

> On 07/01/2014 06:46, Tal Hadad wrote:

> > This case trigger me a question I wanted to ask before.

> > Why transforming ownership is nulling the original variable?

> >

> > Instead of nulling, maybe just change variable to behave as unowned.

> >

> > You might say that there is a problem in my solution, like this code:

> >

> > uint8[] ar = new uint8[10];

> > if (some_method() != NULL)

> >      another_method((owned)ar);

> > ...

> >

> > Since after the "if" case, valac can't determinate if ownership was given(at compile time).

> >

> > Despite of this, nulling "ar" variable is even worse in my opinion and it's error prone.

> >

> > The user might use "ar" varible later and it will crush he's application.

> > If he was lucky enough, he would realize that ar is null.

> > It's not easy to find that this line causing it.

> >

> > I suggest solution for the last problem from valac side - treat ar as unowned after the

> > (owned) operator, even if this operator was in "if" block!

> >

> > That way, "ar" won't be null, and the user could use it later only as unowned.

> >

> > And for class/struct fields - I do accept that they must be nulled when transferring ownership.

>

> What about:

>

> if (foo) {

>    bar = (owned) ar;

> }

> // what now

>

> This behavior is confusing.

> _______________________________________________

> vala-list mailing list

> vala-list gnome org

> https://mail.gnome.org/mailman/listinfo/vala-list



_______________________________________________

vala-list mailing list

vala-list gnome org

https://mail.gnome.org/mailman/listinfo/vala-list



-- 
www.debian.org - The Universal Operating System