memeory related

S

subrat

I have allocated memory dynamically and I am not at all using delete[]. Now
suppose my application is demanding for more memory. And I allocate it again
without using delete[].
What all can happen eventually? Can anyone help.

Thanx
 
F

frame

If exception handling for std::bad_alloc isn't done around the memory
allocation statement, then the application would run out of memory
allocated to it and would be abnormally terminated by the Operation
System; else std::bad_alloc exception would be thrown.
 
K

Kai-Uwe Bux

subrat said:
I have allocated memory dynamically and I am not at all using delete[].
Now suppose my application is demanding for more memory. And I allocate it
again without using delete[].
What all can happen eventually? Can anyone help.

Eventually you will run out of memory. In that case, new() will fail and
throw (unless you use the no-trow version, in which case it will return 0).
How you handle that situation is up to you.

Some operating systems allow for overcommitment of memory. In this case,
your program may not notice that it is running out of memory and the OS
might kill the process. However, this is outside the scope of the C++
standard and outside the scope of this news group, as well.


Best

Kai-Uwe Bux
 
J

Jim Langston

subrat said:
I have allocated memory dynamically and I am not at all using delete[]. Now
suppose my application is demanding for more memory. And I allocate it
again
without using delete[].
What all can happen eventually? Can anyone help.

Thanx

Just run this program and you'll see. After you run it you might want to
reboot your computer.

int main()
{
int* p;
while (true)
{
p = new int[10000];
}
}

What will happen is that you will run out of memory. Since the memory is
newed and not deleted it's never released back to the program (or the OS) so
eventually you'll run out of memory.
 
S

Salt_Peter

subrat said:
I have allocated memory dynamically and I am not at all using delete[].

Stop! Thats undefined behaviour. There is no need to read the rest of
your question.
Since you are both removing the compiler's responsability to recover
that allocation and you have chosen to ignore the discipline of
deallocating what you new, what happens from this point on could be
anything. It might crash your computer, format your hard drive and even
maybe succeed. Regardless: it is not defined and therefore the only
answer is that its UB.
Now
suppose my application is demanding for more memory. And I allocate it again
without using delete[].
What all can happen eventually? Can anyone help.

Thanx

It still puzzles me why a smart_ptr isn't at least considered in a case
like this. These are easier and safer to use than new/delete.
Example:
std::auto_ptr - if you don't need copies
boost::shared_ptr - if you do need the above with a ref count but its
not an array
boost::shared_array - if you need to allocate an array
 
K

Kai-Uwe Bux

Salt_Peter said:
I have allocated memory dynamically and I am not at all using delete[].

Stop! Thats undefined behaviour.

No, it isn't. It may or may not be a memory leak, but there is, as far as I
know, no requirement in the standard that memory allocated has to be
released. What is undefined is releasing the memory using a non-matching
mechanism, e.g., using free for new()ed memory or delete for new[]ed
memory.
There is no need to read the rest of
your question.
Since you are both removing the compiler's responsability to recover
that allocation and you have chosen to ignore the discipline of
deallocating what you new, what happens from this point on could be
anything.

Now, at which line of the program would the undefined behavior start in the
following example:

#include <iostream>
int main ( void ) {
int * ip = new int ( 5 );
std::cout << *ip << '\n';
}
It might crash your computer, format your hard drive and even
maybe succeed. Regardless: it is not defined and therefore the only
answer is that its UB.

If you really think it's UB, please provide a quote from the standard.


Of course, none of this does addresses the question whether deallocating
memory is good programming practice.


Best

Kai-Uwe Bux
 
S

Salt_Peter

Kai-Uwe Bux said:
Salt_Peter said:
I have allocated memory dynamically and I am not at all using delete[].

Stop! Thats undefined behaviour.

No, it isn't. It may or may not be a memory leak, but there is, as far as I
know, no requirement in the standard that memory allocated has to be
released. What is undefined is releasing the memory using a non-matching
mechanism, e.g., using free for new()ed memory or delete for new[]ed
memory.

Frankly speaking, i couldn't care less what the standard says on this
subject.
If you allocate with new and fail to take the responsability to
deallocate, its UB. Period.

Surely, we aren't going to start telling newbies that newing
allocations and relying on the process to end for recovery is
accepteable or even pheaseable.
Sorry, i disagree with that doctrine emphatically.

If you feel that the standard is the ultimate rule-book that dictates
what is and what ain't, then get the standard changed. Ignoring the
discipline of newed allocations in Java is fine, but not C++ and i
don't need a standard to tell me otherwise.

You might need a standard to tell you when Monday is Monday, but i
don't.
 
V

Victor Bazarov

Salt_Peter said:
Kai-Uwe Bux said:
Salt_Peter said:
subrat wrote:
I have allocated memory dynamically and I am not at all using
delete[].

Stop! Thats undefined behaviour.

No, it isn't. It may or may not be a memory leak, but there is, as
far as I know, no requirement in the standard that memory allocated
has to be released. What is undefined is releasing the memory using
a non-matching mechanism, e.g., using free for new()ed memory or
delete for new[]ed memory.

Frankly speaking, i couldn't care less what the standard says on this
subject.
If you allocate with new and fail to take the responsability to
deallocate, its UB. Period.

The term "undefined behavior" is used in this newsgroup with a very
specific meaning: the behavior of a program, which not defined by the
*Standard*. You cannot use "UB" in the same paragraph where you say
that you don't care what Standard says. That's plain nonsense.

If you meant to say that not deallocating is "bad", or "frowned upon",
or "foolish", or "dangerous", then use those terms. Do not use the
term "undefined behavior". Period.

V
 
K

Kai-Uwe Bux

Salt_Peter said:
Kai-Uwe Bux said:
Salt_Peter said:
subrat wrote:
I have allocated memory dynamically and I am not at all using
delete[].

Stop! Thats undefined behaviour.

No, it isn't. It may or may not be a memory leak, but there is, as far as
I know, no requirement in the standard that memory allocated has to be
released. What is undefined is releasing the memory using a non-matching
mechanism, e.g., using free for new()ed memory or delete for new[]ed
memory.

Frankly speaking, i couldn't care less what the standard says on this
subject.
If you allocate with new and fail to take the responsability to
deallocate, its UB. Period.
Nope.

Surely, we aren't going to start telling newbies that newing
allocations and relying on the process to end for recovery is
accepteable or even pheaseable.
Sorry, i disagree with that doctrine emphatically.

Me too. But that is not the claim at issue. The claim at issue is not
whether such code is acceptable. The question is whether it is UB.
If you feel that the standard is the ultimate rule-book that dictates
what is and what ain't, then get the standard changed. Ignoring the
discipline of newed allocations in Java is fine, but not C++ and i
don't need a standard to tell me otherwise.

You might need a standard to tell you when Monday is Monday, but i
don't.
[snip]

You are missing the point entirely. You do need the standard to tell when
something is undefined behavior: this term is defined by and only by the
standard. You do not need the standard to tell that not deleting what you
new()ed is _bad_. But that is an entirely different matter (as I already
indicated in my first response).


Best

Kai-Uwe Bux
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top