From the beginning, I always used new pretty much like malloc with some extra machinery. Let me say that my 'beginning' means many years ago. At the time, exceptions were still somewhat clunky, and although they worked in theory, I have to say their implementation were terrible. So, new at the time just returned NULL on failure, which was fine to me at the time, although we all know how much the subsequent pointer checking is.

float *vec = new float[nComps * nvtx];
if(!vec) return false; // how boring

In 2009 I started to think that I could transition to the new exception-based new (which happens to be the standard even for MS libs now): after all, this is an excellent application for exceptions, which in the meanwhile have matured alot. So I started to drop the pointer checking. Today, I read: A call to new may return NULL if the platform has run out of memory, so test the return value before dereferencing it.. Uh-oh. So, is the throwing new standard or not? Is he referring non-PC platforms? I admit that I have no multiplatform experience at all and minimal multi-OS experience.

Yes, a throwing 'new' is standard C++ '98, though it took some years before Microsoft released a new C++ compiler after their, uhm, "groundbreaking" MSVC++ 6.0.

edit: ninja'd++.

Thank you both for your fast reply,
however, I am sort of unsure I am communicating correctly my concerns.

The non-throw'ing null is well known to me. It is not something I want to see around in my code. I actually don't want new to NOT throw exceptions, I want to migrate to the throwing null, which implies always valid pointers out of it.

And, yes, I know the throwing NULL is standard since years, as well as my refusal to use exceptions in most situations is probably not justified those days.

Yet the article I linked comes from a source I personally find trustable and if they write that new can still return NULL I am left wondering what they're talking about.

I have tens of thousands of line of code using NULL-new accumulated for reuse over the years. Although inelegant by my current likings, they will work with throwing NULL. It is forward compatible.
By contrast, the throwing null approach is not back compatible. Although the possibility I port to some esoteric or closed platform is minimal, I still like to believe it is not zero.
Now, in the admittedly low chance this happens, if the platform doesn't support throwing new, all this code will turn unsafe.
Seeying it in perspective, knowing that MSVC will play nice and that "it is standard since" ten years ago, leaves me at the start - I don't think this example was random.

Then, what exactly is your question if it's not

Quote:So, is the throwing new standard or not?

because a throwing new is standard. If new doesn't throw an exception upon out-of-memory, then that behaviour is compiler specific and non-standard. In that case, you must check the manual of the compiler you are going to use. Imho, it isn't worth the effort to take into account all possible compiler specifics until you use that compiler, and until you write a library. Fr instance, if you look at boost, you will see that they coded their library to be compatible to many compilers, and that lead to total code uglyness in some parts of their files.

If you ask me, yagni. The less you have to write, the less error prone is your code.

Out of curiosity: Does the guy say that "in C++, new can return NULL", or does he say "under the compiler foo, new can return NULL"? Because the former is false, and would have to be rephrased to the latter.

Since the article mentions programming for the Wii it's probably that they've turned off exceptions since they have a non-trivial amount of overhead. Given this it's probably that the compiler switches to no-throw new everywhere, or they're using a custom allocator which returns NULL instead of throwing an exception.

That was exactly my line of thinking. Thank you very much for confirming my fears were real.

I think I will just keep NULL-new convention for another couple of years.