Using auto_ptr for memory allocated by new [] is wrong.
Because auto_ptr will free memory with delete, not delete [].

Quote:Original post by DevFred
Just for reference, from TC++PL §6.2.6.2 "Memory Exhaustion":

Quote:
What happens when new can find no store to allocate? By default, the allocator throws a bad_alloc exception [...]

I could not find anything in the standard after a few minutes of searching. Anyone?

What are you asking exactly?

Quote:Original post by DevFred
I could not find anything in the standard after a few minutes of searching. Anyone?

This is the best I could find from a few minutes of looking through my copy of the standard.

The standard definitions of operator new (3.7.3.2):

Quote:
void* operator new(std::size_t) throw(std::bad_alloc);
void* operator new[](std::size_t) throw(std::bad_alloc);

Followed by 3.7.3.1.3:

Quote:
If an allocation function declared with an empty exception-specification (15.4), throw(), fails to allocate storage, it shall return a null pointer. Any other allocation function that fails to allocate storage shall only indicate failure by throwing an exception of class std::bad_alloc (18.4.2.1) or a class derived from std::bad_alloc.

Quote:Original post by iMalcAs credible as the source might seem, the statement in question is nevertheless false. One would need to quantify the statement with specific old compilers at the very least.

If you'd like to help keep up the credibility of that source, then by all means please contact the site or article author and let them know of the mistake.

The source is just fine, read the article, but more importantly, the context it was written in.

The quote isn't about some weird C++ standard issues, or some obscure platforms. The paragraph comes through as if developer seemed surprised that on embedded hardware it is necessary to check for memory allocation failures (given a console projects, exceptions were probably disabled, or aren't supported).


The article is written from a junior developer's perspective (as stated in article).

Other advice states to validate parameters and expect that sometimes your function will be called with unexpected parameters. Another paragraph says to learn bit flags. And another that requirements change.

The surprise over memory allocation failures is common. Memory allocation is an obscure and arcane topic to majority of new developers, and essentially all that have been raised on cups of Java. Majority of software developers today has no concept of resource cost (memory, disk, CPU - "what, I tested with 5 files, it works fine, what do you mean O(n^5)"), and many (especially IT-centric) practices strictly forbid thinking about cost, which results in gigabyte behemoths where no resources could have been claimed at all.

This isn't limited to small projects either. I ran into problems upgrading eclipse, when something looked fishy after taking 30 minutes with no apparent progress. It turned out, that upgrader was creating hundreds of thousands (100,000+) directories with a handful of files in them (millions of 100 byte file system entries). It was simple design (reflection or something mapped to file system), but it's the absolute worst-case scenario for NTFS. After moving temp location to RAM drive, the whole process took only a few seconds.

Quote:Original post by loufoque

Quote:Original post by DevFred
I could not find anything in the standard after a few minutes of searching. Anyone?

What are you asking exactly?

Since 1998, there is a document that describes C++ in every detail. If new throws an exception, that should be noted somewhere in that document.