My experience is that stack allocated objects tend to be simpler,
shorter-lived and less prone to accumulating invalid state somewhere and
crash somewhere else. All in all they haven't been a source of pain the
way heap-allocated objects often are when it comes to invalid state
creeping up. There tend to be fewer of them also. So I am perfectly
happy with handling them differently, and I can't think of a stack
allocated object in the code I work with that would need something as
involved as a static creation method or an nsresult& out param, to be
honest.
Cheers,
Nical
On Thu, Apr 21, 2016, at 12:24 PM, Nicholas Nethercote wrote:
> On Thu, Apr 21, 2016 at 7:38 PM, Nicolas Silva <nical.si...@gmail.com>
> wrote:
> > Fallible construction (even with a way to report failure) is annoying if
> > only because the object's destructor has to account for the possible
> > invalid states. I much prefer having a static creation method that will
> > only instantiate the object in case of success, and mark the constructor
> > protected. Something like:
> >
> > static
> > already_AddRefed<Foo> Foo::Create(SomeParams...) {
> > // logic that may fail...
> > if (failed) {
> > return nullptr;
> > }
> > return MakeAndAddRef<Foo>(stuffThatDidNotFail);
> > }
>
> So instead of doing the infallible part in the constructor and the
> fallible part in the Init() function, you're suggesting doing the
> fallible part first and only calling the constructor once it succeeds?
> Interesting. I can see it would work nicely for some heap-allocated
> objects. But I see two possible problems:
>
> - It doesn't appear to work with stack-allocated objects?
>
> - I suspect that in some heap-allocated objects it will be hard to do
> the fallible parts without having an object of the relevant type. I
> don't have specific examples, just a hunch.
>
> Nick
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
