On Monday, July 4, 2016, Quincey Morris
<quinceymor...@rivergatesoftware.com> wrote:
I don’t know the answer, but it seems to me at least possible that it
didn’t fail. It’s at least possible that it gave you an unmapped
virtual allocation of the size you asked for.
In fact this is likely, at least on x86_64. I suppose it's
possible that when targeting i386, you'd get a different outcome.
I've seen situations in which code like this:
T *foo = new T[n]; // for some large integer value "n"
if (nil != t)
{
/*...*/
}
ends up with the (nil != t) optimized away in release builds,
because the compiler assumes that operator new[] will either
succeed or throw a bad_alloc. This, in any case, operator new
never returns nil, so there's no need to check its result.
On the other hand:
T *foo = new(std::nothrow) T[n];
if (nil != t)
{
/*...*/
}
Here, the compiler knows that operator new will explicitly *not*
throw and *may* fail (again, at least on i386).
It may be that when targeting x86_64, checking for nil (or NULL)
results from allocations is passé and gets optimized away,
because as we all know, "malloc() never fails"...
R.
--
Rich Siegel Bare Bones Software, Inc.
<sie...@barebones.com> <http://www.barebones.com/>
Someday I'll look back on all this and laugh... until they
sedate me.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (Xcode-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
