fprawn

If you have time, can you expound on this? Is there, perhaps, an open source project that handles NULL returns from malloc in this way you could point me to?

I'll clarify this. I'm not saying you shouldn't ever check return values, that's obviously not the right thing to do. And of course there are exceptions to the general rule. If you're allocating a large chunk of memory and there's a reasonable expectation that it could fail, that should be reported, of course.

In the general case, however, if allocating 100 bytes fails, reporting that error is also likely to fail. An actual memory allocation failure on a modern computer running a modern OS is a very rare and very bad situation. It's rarely recoverable.

It's not bad to handle allocation failures, but in the vast majority of cases it's very unreasonable to do so. You can write code for it if you want, have fun.

And just to be completely clear, I am ONLY talking about calls to malloc, new, realloc, etc. NOT to OS pools or anything like that. Obviously, if you allocate a 4Mb buffer for something (or the OS does for you), you expect that you might run out. This is ONLY in regards to calls to lower level heap allocators.

I don't think you'll find any experienced programmer recommending that you always check the return from malloc. That's completely absurd. There are always exceptions to the rule, however.

Memory allocation failures are virtually non-existent in modern desktop computers. Good practice is to not test return values from malloc, new, etc.

Memory can be allocated beyond RAM size, so by the time a failure occurs your program really should crash and return its resources.

Embedded systems have fewer resources and some will not have virtual memory and so the situation will be different. But unless you know better, the best practice is still to not check the return from allocators. Running out of memory in a program intended for an embedded platform should be considered a bug.

SEEKING WORK - San Francisco Bay Area or Remote

10+ years C/C++ video game development, scientific visualization, and real time image processing.

Polyglot programmer that works mainly in C/C++, Python, Perl, and PHP on Android/iOS, Windows/Mac/Linux, embedded, game consoles, backend servers.

Looking to help optimize low level code, work on 2D or 3D visualizations and games. I work fast, write clean code and can help mentor junior developers.

contact: ycj@linuxleverage.com

This is amazing. He's come up with completely new ways to do graphics on modern CPUs. This is genuinely impressive stuff and the breadth of it is mind blowing.

It's upsetting how dismissive of his work he can be, he deserves to be proud of this, I certainly would be.

There's a lesson here about how sometimes it's okay to fit your data to your code. This was, afterall, in php for years without causing much, if any, problems for end users.

I guess there won't be much agreement here on HN, but this deserves to be recognized as an amusing and clever solution to a problem. Even if the problem is self created.

PHP is great for doing quick and dirty dynamic web pages. So what if it doesn't scale out to a million line program?

This is true only if the source image is smaller than the destination image. In the article, the source image is shown as the same size as the destination, and includes a large white border that can be clipped without the inner image being affected.

In the event that the destination buffer is much larger than the source, that additional computation is trivial (it's the same calculation that's already being done for each and every pixel). As it only needs to be additionally done on the corners, not per-pixel, the additional time spent should be quite minimal.

The shearing method in the article is genuinely clever and totally cool, but I just can't shake the feeling that even on 1980s hardware, this method would be better. On modern hardware, there's no question, it's still used to this day. Nowhere near as cool, though.

This is really neat, but seems to neglect an alternative (and just as simple) method. Instead of traversing through each pixel of the source buffer, traverse through each pixel of the destination buffer sampling the correct pixels from the source. Using different sampling methods results in various qualities, and efficiencies in cpu use and memory access.

This method is as simple to code and doesn't suffer from the missing-pixel aliasing problem of the simple method of the article, and is also capable of higher quality results than the shearing method.