Why is the memory allocated on the heap NOT freed?

[Bilal]

Dear group members,

I am newbie and learning c++ so bear with my posts.

I found a code on internet regarding inserting a node on the linked list. I ran it and it works perfectly. In this code the function 'Insert(data,n)' creates a node in the nth position with a payload 'data'. My question is why the memory allocated on the heap is not freed before the control is returned to the main function.
Here is the 'Insert' function below:

------------------------------
void Insert(int data, int n)
{
int i;
struct Node* temp1 = new Node;
temp1->data = data;
temp1->next = NULL;
if (n == 1)
{
temp1->next = head;
head = temp1;
return;
}
struct Node* temp2 = head; /*Another pointer to Node named temp2. Pointing to head first node*/
for (i = 0; i < n - 2; i++)
{
temp2 = temp2->next;
}

temp1->next = temp2->next;/*set the next or the link of newly created node as the link field of this (n-1) then we can adjust the link of this (n-1) the node point to our newly created node */

temp2->next = temp1;
}
-------------------------------

Thanks in advance.
-Bilal

[Ian Collins]

On 06/ 8/17 07:08 PM, Bilal wrote:
> Dear group members,
>
> I am newbie and learning c++ so bear with my posts.
>
> I found a code on internet regarding inserting a node on the linked
> list. I ran it and it works perfectly. In this code the function
> 'Insert(data,n)' creates a node in the nth position with a payload
> 'data'. My question is why the memory allocated on the heap is not
> freed before the control is returned to the main function.

Simply because you don't explicitly free it!

Dynamic memory has to be manually allocated and freed. More often than
not dynamically allocated memory has a lifetime greater than the
function where it is originally allocated.

--
Ian

[Barry Schwarz]

On Thu, 8 Jun 2017 00:08:43 -0700 (PDT), Bilal
<bilal...@googlemail.com> wrote:

>Dear group members,
>
>I am newbie and learning c++ so bear with my posts.
>
>I found a code on internet regarding inserting a node on the linked list. I ran it and it works perfectly. In this code the function 'Insert(data,n)' creates a node in the nth position with a payload 'data'. My question is why the memory allocated on the heap is not freed before the control is returned to the main function.
>Here is the 'Insert' function below:
>
>------------------------------
>void Insert(int data, int n)
>{

<snip>
>}

If you are asking why the memory was not freed as the function
returns, the same way automatic variables are destroyed at that time,
it is because memory allocated with new remains allocated until it is
specifically freed with delete.

If you are asking why the function does not delete the allocated
memory, it is because then the linked list would be broken. Any code
stepping through the list would cause undefined behavior as soon as it
tried to evaluate or dereference the address of the deleted memory.

--
Remove del for email

[Juha Nieminen]

Bilal <bilal...@googlemail.com> wrote:
> I found a code on internet regarding inserting a node on the linked
> list. I ran it and it works perfectly. In this code the function
> 'Insert(data,n)' creates a node in the nth position with a payload
> 'data'. My question is why the memory allocated on the heap is not
> freed before the control is returned to the main function.

By design. The 'new' keyword allocates memory that's precisely designed
to outlive the scope where it was allocated.

Of course since C++ does not have any sort of garbage collection
mechanism for heap-allocated memory blocks, it's up to the code to
eventually free it explicitly, or else it will remain allocated
for the remaining of the runtime of the program.

(C++ offers several mechanisms to manage that more easily and safely,
such as using std::unique_ptr or std::shared_ptr, or doing the
allocation within a class that automatically manages freeing that
memory, such as what the standard data containers like std::vector
and std::list do.)

[Alf P. Steinbach]

On 12-Jun-17 10:07 AM, Juha Nieminen wrote:
> [snip]

> Of course since C++ does not have any sort of garbage collection
> mechanism for heap-allocated memory blocks,

C++11 added support for garbage collection.

I only know of the Boehm collector.

And sorry, I haven't used it, but as I recall James Kanze had some
experience with it in the C++03 days (yes, before the language added
support for it!).


Cheers & hth.,

- Alf

[Ian Collins]

The Boehm collector was well supported in the old Sun tools, back before
the first standard! I for one was very disappointed with support was
discontinued.


--
Ian

[Juha Nieminen]

Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
> C++11 added support for garbage collection.

No, it didn't. It allows for the implementation to do some
implementation-specific stuff for garbage collection, but
it's not guaranteed in any way.

[Melzzzzz]

Why all the fuss with GC? Rust dropped it, Apple dropped it, and lot of
people demanding D to have GC free stdlib?

--
press any key to continue or any other to quit...

[Alf P. Steinbach]

On 12-Jun-17 2:59 PM, Juha Nieminen wrote:
> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
>> C++11 added support for garbage collection.
>
> No, it didn't.

Yes it did. E.g. section §20.6.4 called “Pointer safety” is all about
support for garbage collection. In the standard's own words, in §C.2.10,
it's a “Minimal support for garbage-collected regions”.

> It allows for the implementation to do some
> implementation-specific stuff for garbage collection, but
> it's not guaranteed in any way.

That appears to be nonsense, at least as support for the previous
assertion. Can you be more specific? Thank you.


Cheers!,

- Alf

[Juha Nieminen]

Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
> On 12-Jun-17 2:59 PM, Juha Nieminen wrote:
>> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
>>> C++11 added support for garbage collection.
>>
>> No, it didn't.
>

> Yes it did. E.g. section §20.6.4 called ???Pointer safety??? is all about

> support for garbage collection. In the standard's own words, in §C.2.10,

> it's a ???Minimal support for garbage-collected regions???.

So you are saying that if I use a C++11 standard-compliant compiler,
like clang or C++, I don't have to delete what I allocate with new?

Oh wait, I do.

So I suppose C++11 did *not* add garbage collection to the language.

[Alf P. Steinbach]

On 13-Jun-17 9:23 AM, Juha Nieminen wrote:
> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
>> On 12-Jun-17 2:59 PM, Juha Nieminen wrote:
>>> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
>>>> C++11 added support for garbage collection.
>>>
>>> No, it didn't.
>>
>> Yes it did. E.g. section §20.6.4 called ???Pointer safety??? is all about
>> support for garbage collection. In the standard's own words, in §C.2.10,
>> it's a ???Minimal support for garbage-collected regions???.
>
> So you are saying that if I use a C++11 standard-compliant compiler,
> like clang or C++, I don't have to delete what I allocate with new?
>
> Oh wait, I do.
>
> So I suppose C++11 did *not* add garbage collection to the language.
>

You can find a discussion of your argument here: <url:
https://en.wikipedia.org/wiki/Straw_man>.

[Hergen Lehmann]

Am 13.06.2017 um 09:23 schrieb Juha Nieminen:

> So I suppose C++11 did *not* add garbage collection to the language.

C++11 defines all the necessary pointer traits required for GC, as well
as several specific functions and templates for controlling a garbage
collector (e.g. std::declare_reachable). It is possible to write
programs and template libraries in C++11, which will still behave
correctly when used in a runtime environment with GC.

C++11 does not require a specific compiler implementation to actually
provide a garbage collector, though.

Hergen

[Juha Nieminen]

Hergen Lehmann <hlehmann.e...@snafu.de> wrote:
> C++11 does not require a specific compiler implementation to actually
> provide a garbage collector, though.

That's my point.

It's not required by the standard, and to my knowledge none of the major
compilers implement it.

Since you can't rely on compilers supporting garbage collection, you can't
write portable code making that assumption. Or, as it happens to be in
practice, even non-portable code, because the support just isn't there.
At least not without using some third-party library.

[Juha Nieminen]

Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
> You can find a discussion of your argument here: <url:
> https://en.wikipedia.org/wiki/Straw_man>.

I'm getting really tired of your arrogant attitude. Maybe you'll want
to tone it down if you want to have civil discussions with people.

How exactly is what I said a straw man argument? If you allocate something
with 'new', you'll have to make sure it gets destroyed with a correspondent
'delete' (by either writing it yourself, or having some class do it for
you, like eg. unique_ptr). That was true in 2011, and it's still true
today, in 2017. That fact hasn't changed an iota.

C++11 doesn't have any more support for garbage collection than C++98
has for export templates. In fact, it has even less. Export templates
were a requirement of the C++98 standard; it's just that no major
compiler implemented it (and thus no compiler was standard-compliant).
Garbage collection isn't even a requirement in C++11, so compilers
having no support doesn't technically mean they aren't standard-
compliant.

Saying "C++11 added support for garbage collection" is, at the very
least, highly misleading. It makes it sound like you don't need to
worry about deleting what you allocate anymore. Just allocate and
forget, the garbage collector (which is "supported by C++11") will
take care of it.

[Alf P. Steinbach]

On 14-Jun-17 9:23 AM, Juha Nieminen wrote:
> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
>> You can find a discussion of your argument here: <url:
>> https://en.wikipedia.org/wiki/Straw_man>.
>
> I'm getting really tired of your arrogant attitude. Maybe you'll want
> to tone it down if you want to have civil discussions with people.

How about toning down both the ad hominem attacks, the strawman
arguments, and the counter-factual assertions?

By “toning down” I mean /less/ of it, not just weaker versions.


[snip]

>
> Saying "C++11 added support for garbage collection" is, at the very
> least, highly misleading.

Look at the section titled “Garbage collector support”: <url:
http://en.cppreference.com/w/cpp/memory>.

You can use your browser's find functionality to find that very quickly,
as an alternative to scrolling down.

Earlier I referred you to the C++ standard, which also calls it that.

> It makes it sound like you don't need to
> worry about deleting what you allocate anymore. Just allocate and
> forget, the garbage collector (which is "supported by C++11") will
> take care of it.

May I suggest you context some committee members about your strong
disagreement with what the garbage collection support is called?

Write up a proposal.

Find someone or some group of committee members to champion it.

[Hergen Lehmann]

Am 14.06.2017 um 09:14 schrieb Juha Nieminen:

>> C++11 does not require a specific compiler implementation to actually
>> provide a garbage collector, though.
>
> That's my point.
>
> It's not required by the standard, and to my knowledge none of the major
> compilers implement it.

GC is more of a runtime environment feature than a compiler feature. If
it was implemented by the compiler itself, you could no longer link
against modules written in other languages.

And when it comes to the runtime environment, there are always language
features you can't really use in a certain environment. For example, you
likely won't be able to use IO streams and C++-style concurrency on
small embedded systems, even when cross-compiling with clang or gcc. You
will have a hard time using some of the legacy C99 features (e.g.
sprintf and strftime) on Windows systems, where their implementation
traditionally defies the standard.

> Since you can't rely on compilers supporting garbage collection, you can't
> write portable code making that assumption.

You can, as long as you are using smart pointers as you should do.
The garbage collector interface is only of relevance when implementing
low-level algorithms like within the STL itself.

Hergen

[Bo Persson]

The standard doesn't guarantee any specific size of the available memory
for dynamic allocations. So how do you write portable programs in the
first place, garbage collected or not?


Bo Persson

[Öö Tiib]

On Wednesday, 14 June 2017 10:15:05 UTC+3, Juha Nieminen wrote:
> Hergen Lehmann <hlehmann.e...@snafu.de> wrote:
> > C++11 does not require a specific compiler implementation to actually
> > provide a garbage collector, though.
>
> That's my point.
>
> It's not required by the standard, and to my knowledge none of the major
> compilers implement it.

All major compiler's have features that are needed for implementing GC.
So it is library thing not compiler thing.

> Since you can't rely on compilers supporting garbage collection, you can't
> write portable code making that assumption. Or, as it happens to be in
> practice, even non-portable code, because the support just isn't there.
> At least not without using some third-party library.

Adding GC to standard library would be doable. It is just that no one
bothers. Seems that ref counting is more popular right now than GC and
so some would ref count even with GC and so since C++ is no-one's
property it is up to fans of GC. ;-)

[Melzzzzz]

Well, GC would be nice, but it is antipod for RAII.