But what if the creation of, say, object 'd' (Object4) fails? Unless I am missing something, in this case object 'a',' b', and 'c' will not be de-allocated (which could cause a memory leak)?
How about looking up std::auto_ptr
If not using exceptions:
- constructor cannot fail (or will set a flag which needs to be checked)
- if allocation fails, pointer will be null
If using exceptions:
- constructor will throw exception
- allocation failure will throw std::bad_alloc
I'm going to go one step further with above example. If avoiding exceptions and not using C++ class life-cycle, we're back to C anyway, so let's use macros:
#define MUST_CREATE(a, b)
auto_ptr<b> a = new b();
if (a->get() == 0 || a.fail) return 0;
...
{
MUST_CREATE(a, Object1);
MUST_CREATE(b, Object2);
MUST_CREATE(c, Object3);
MUST_CREATE(d, Object4);
MUST_CREATE(e, MyClass);
e->a = a->release();
e->b = b->release();
e->c = c->release();
e->d = d->release();
return e->release();
}Code not using exceptions is fairly limited in the extent of using constructors, so the creation will need a convention anyway, might as well make it as clear as possible.
A better question here is what the goal of such construction is. Avoiding exceptions for sake of poor compiler is increasingly rare and allocations from pool where allocations are commonly expected to fail would be done differently and not rely on bad_alloc.
The point about goto though is that it's a valid tool if you know what you're doing.
goto is "unconditional jump" or "unconditional branch".
If algorithm needs it and it isn't better expressed using one of built-in constructs (if/do/for/while), then it's obviously the right tool for the job.
Since majority of languages today emphasize scoping or nesting, jump becomes very limited in where it can be used.
3
