On Thursday, April 21, 2016 at 11:15:10 AM UTC+10, Nicholas Nethercote wrote:
> The only disadvantage I can see is that it looks a bit strange at first. But
> if
> we started using it that objection would quickly go away.
>
> I have some example patches that show what this code pattern looks like in
> practice. See bug 1265626 parts 1 and 4, and bug 1265965 part 1.
>
> Thoughts?
>
> Nick
I too believe that passing a pointer makes a tad more obvious than it's a out
parameter. But maybe I'm too old school.
In the media code, we have a few particular use where we construct and then
initialise. The initialisation itself is typically asynchronous and it is
required to be performed on a specific thread (while the construction can
happen everwhere).
For this we have a Init() member that returns a RefPtr<MozPromise>
I don't see how we could do that in a combined fallible constructor. As such,
so long as we're still left with the flexibility to continue using a separate
init methods..
why not...
Personally, in a few recent classes I actually made an operator bool() method.
This was for objects where fallibility was important.
So you could simply do something like:
T myobject(arg);
if (!myobject) {
HandleOOM();
return;
}
In this particular case, the aim was to replace a UniquePtr<T[]> which would
work like:
UniquePtr<T[]> blah = MakeUniqueFallible<T[]>(arg);
if (!blah) {
HandleOOm();
return;
}
I could then simply find replace all UniquePtr<T[]> blah =
MakeUniqueFallible<T[]>(arg) with T blah(arg)
everything else kept working the same.
I don't know how popular this method would be, nor if people would be shocked
by providing a operator bool() but here it is :)
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
