Re: [Vala] out, ref and GError parameters.

["Alexandre Moreira" <alexandream gmail com>]

On 3/15/07, Jürg Billeter <j bitron ch> wrote:
> On Don, 2007-03-15 at 14:57 -0300, Alexandre Moreira wrote:
> > On 3/15/07, Juerg Billeter <j bitron ch> wrote:
> > > As mentioned before, you can already start implementing by using the
> > out
> > > syntax, you just will have to port the code someday but that shouldn't be
> > > difficult.
> > >
> >
> > I can't see how use the GError stuff with out syntax. Unless I
> > generate a lot of Error variables to use with my code, I can't simply
> > pass on the error handle the user gave me to the functions I call,
> > because the user might have passed it as null, and whenever I try to
> > pass this to the next function, it will dereference it :(
> >
> > I can't check for null, and I can't use it in any way without
> > dereferencing it...
>
> It should work as follows:
>
> Method definition
>         public void test (out Error error) {...}
>
> Checking for null
>         if (out error != null) {...}

The problem with that is that it generates the following code:

if (&(*error) != NULL) { ... }

and this means that error will be dereferenced and then turned back
into an address... Oh well, wait. I just decided to take a look at a
debugger before hitting send.

The thing is, I read the generated code but never actually ran it. It
looks like by some kind of black magic (either that or I really don't
get the meaning of that statement) error never gets dereferenced, even
with the dereference operator acting right in front of it.

I don't know if this is compiler dependent though. Perhaps it is
simply a matter of gcc being smart enough to identify the pointless
mix of operations and ignoring both.

I'll live with that for now, thanks.

Just to be sure, though: Is the pointer support anywhere in the "map
of plans" ? If so, is it near or far from being implemented (based on
your list of priorities).

Thanks for the answer, and I'm looking forward to having pointer
support (I plan on interfacing with a hell lot of non GObject based
code)

Alexandre Moreira.

> Passing to next function
>         foo (out error);
>
> In short, as long as you use `out error` instead of just `error`, it
> shouldn't get dereferenced. I haven't used this workaround for real
> error handling, though, so I might have overlooked something. Please
> report if there are still problems with that scheme.
>
> Jürg