memeory related

[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

[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.

[frame]

Sorry for the typo "Operation"! Please read it as "Operating".

Thanks!

frame wrote:

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.

[Jim Langston]

"subrat" <su***********@in.bosch.comwrote in message
news:el**********@news4.fe.internet.bosch.com...

>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.

[Kai-Uwe Bux]

subrat wrote:

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

[Salt_Peter]

subrat wrote:

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

[Kai-Uwe Bux]

Salt_Peter wrote:

>
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.

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

[Salt_Peter]

Kai-Uwe Bux wrote:

Salt_Peter wrote:

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.

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.

>

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

[Victor Bazarov]

Salt_Peter wrote:

Kai-Uwe Bux wrote:

>Salt_Peter wrote:

>>>
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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Gavin Deane]

Salt_Peter wrote:

Frankly speaking, i couldn't care less what the standard says on this
subject.

Then you're off-topic.

Gavin Deane

[Kai-Uwe Bux]

Salt_Peter wrote:

>
Kai-Uwe Bux wrote:

>Salt_Peter wrote:

>
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