On Thu, Apr 21, 2016 at 7:57 AM, Nicholas Nethercote <n.netherc...@gmail.com > wrote:
> On Thu, Apr 21, 2016 at 3:05 PM, Eric Rescorla <e...@rtfm.com> wrote: > > The general problem that > > it doesn't alleviate is that failure to check the return value leaves you > > with a reference/pointer to an object in an ill-defined half-constructed > > state. At least for heap allocations, I'd much rather have the property > that > > failures leave you with a null pointer. > > First of all, with neither approach do you end up with a null pointer, > at least not in Gecko where we have infallible new. So let's ignore > that sentence. > No, let's not ignore that sentence. I'm aware that the current idioms don't provide that. I'm saying that if we are going to bother to add a new idiom it should have this property. > So, if we are going to do something along these lines, I would want it to > be > > a convention that if you use MakeUnique and the like (as you should) then > > they automatically validate correct construction and if not return an > empty > > pointer. > > MakeUnique() just allocates and calls the constructor. If you have > fallible steps in your intialization then MakeUnique() won't help you; > you'll still have either call your Init() function afterwards or check > your nsresult& outparam. So that's not relevant. > Yes, what I'm saying is that we should modify MakeUnique so that if a constructor has the form you are recommending, it should end up with an empty UniquePtr<T> rather than requiring you to explicitly check the result. Maybe you're referring to factory methods, I'm not. > like this: > > static T* T::New(); > > which would return null on failure. Such methods can be useful, but > there's two problems. First, they're not applicable to stack-allocated > objects. Second, you still have to do your fallible initialization > *within* the factory method, and so you still have to choose with > either constructor+Init or constructor+outparam, so you still have to > make a choice. > This is why I didn't suggest it. -Ekr > > Nick > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
