Re: Test Dynamic Memory
On 15 Dec., 10:37, James Kanze <james.ka...@gmail.com> wrote:
On Dec 13, 9:16 pm, peter koch <peter.koch.lar...@gmail.com> wrote:
On 13 Dec., 21:10, Immortal Nephi <Immortal_Ne...@hotmail.com> wrote:
I notice that some codes do not have to test dynamic memory to
determine if dynamic memory is available or not. It is said in
Deitel How to Program C++ book.
If it says so, it is a bad book.
Or simply old. (Back when I was learning C++, all good books said to
be
sure to check the results of new for a null pointer. Back when I was
learning C++, there weren't exceptions.)
Right. But in that case it is still a bad book even though it might
have been excellent when published.
Is it necessary to test dynamic memory if memory is very small like
less than 256 bytes? The test should fail and prevent you from
doing class constructor.
If new fails, standard behaviour is to throw std::bad_alloc. Some very
old compilers got that wrong, noticeably VC6.0.
Can't complain too much about VC6.0. It appeared before the standard,
at a time when it wasn't clear what the standard would require of
operator new. (It was fairly clear that an exception was in order,
but
IIRC, the name of the exception changed several times along the way.
And of course, most compilers before VC6.0 didn't throw an exception,
because they didn't support exceptions.)
I agree: my statement was not meant to degrade VC6.0, but rather to
help the OP in case he still uses that old compiler. I believe VC6.0
is the only still used compiler where new does not throw.
If you use that compiler and can't change, you can change a setting to
make it standards-compliant in that respect.
For most applications, the most appropriate solution is probably to
set
the new_handler to abort the program with an error message.
Recovering
from out of memory can be tricky. (There are a number of exceptions,
of
course, but aborting in the case of insufficient memory is an
appropriate response for many applications. And is a lot simpler to
implement than any of the other choices.)
I would prefer a std::bad_alloc exception in the normal case which (if
I remember correctly) a compiler switch can fix.
array class is already constructed before dynamic memory is tested.
If it fails, error message is displayed before exit() function
terminates the program. If I decide to allow the program running
after dynamic memory reported out of memory, then array class should
use destructor to clean up all data members and release array class
from the memory.
You do realize, that you are just creating a dumped-down version of
std::vector? So your class is useless if not as an exercise. Also, you
are missing a lot of stuff - an assignment operator and a copy
constructor needs to be written.
For example:
class array
{
public:
array( int size )
{
m_pArray = new int[ size ];
m_size = size;
if( m_pArray == 0 )
{
// Display Error Mess=
age -- out of memory
ation and try again or
n
This behaviour is better delegated into the new_handler function.
The behavior in comments, yes. Just setting the flag, no, but if
that's
really what is needed (which I doubt), then he needs to use
new(nothrow).
// if( yes )
// exit();
// else ( no and cont=
inue )
ue;
return;
}
}
Prefer initialization rather than assignment. Your constructor should
be
array( int size ): m_size(size),m_pArray(new int[ size =
]) {}
Also notice that m_bOutofMemory only gets initialised in case there is
a memory leak, so you are likely to run into undefined behaviour in
TestMemory.
~array()
{
if( m_pArray != 0 )
There is no need for this check.
{
delete [] m_pArray;
m_pArray = 0;
And no need for this assignment.
}
}
bool TestMemory()
{
return m_bOutofMemory;
}
private:
int m_size;
int *m_pArray;
bool m_bOutofMemory;
That hungarian notation really creeps me out.
Real Hungarian can be useful, seehttp://msdn.microsoft.com/en-us/library/=
aa260976%28VS.60%29.aspx.
What
Simonyi describes, however, is not the Hungarian we generally see (nor
the Hungarian used above). In C++, too, it's generally better to go
one
step further, and create a class (a true type), rather than faking it
with an int and a prefix to the name. And in general, it's also
probably better to write the name out in full, rather than to use a
lot
of succinct abbreviations. (The important point in Simonyi's
Hungarian
is consistency, which is good, and the semantic value: a color is not
an
x coordonate, even if both are represented by an int. Both important
points for readable software.)
};
int main()
{
array *a = new array( 5 );
Why do you want to allocate a dynamically? This is just silly. Use
array a(5);
if( a->TestMemory() == true )
Why do you compare to true - this is just obfuscation. Prefer:
if( a->TestMemory() )
delete a;
// Continue the program after
// exit() function is not invoked.
system( "pause");
return 0;
Here you have a memory leak - because of the dynamic allocation of a.
Technically, you can't have a memory leak if you're returning to the
system. The only way you can have a memory leak is to do something in
a
loop which fails to delete all the memory it allocates.
Technically, you're right, but my understanding is that main simply
was a means to demonstrate usage of the class. From that point of
view, there is indeed a memory leak.
/Peter