Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Newbies don't learn C++

Reply
Thread Tools

Newbies don't learn C++

 
 
Ulrich Eckhardt
Guest
Posts: n/a
 
      01-13-2011
Leigh Johnston wrote:
> A memory leak is the failure to deallocate that which was allocated
> before program termination, end of story.


I recently heard another guy named Paul Reid finishing his claims with
"end of story" and similar absolute claims that forbid any even fruitful
discussion. Your language is reaching deep down the sewer here, sorry.

That said, you may be right or not or both right and wrong, depending on
your definition of "program termination" and what you want to express with
the term leak. When the resources are automatically reclaimed by the OS
during process termination, the memory is not leaked. This definition
would fit your claim above, but is useless, because the OS typically does
a good job to reclaim resources. Building an unlimited list of log
messages in a server process is a memory leak, because the program is not
supposed to be stopped but has to reclaim resources at runtime already,
but doesn't fit your definition.


> A memory leak is a *consequence* of an object becoming unreachable


I'd say that a resource leak is a consequence of resources being neither
used nor released. Obviously, an unreachable object is a resource that can
neither be used nor released.

> and one can argue about the definition of "unreachable" (I would argue
> that a pointer to an object defined at namespace scope becomes
> unreachable during program termination).


I don't understand that statement. Maybe it's just that I don't know what
point in program termination you mean, it's also not clear if the pointer
is at namespace scope or to an object at namespace scope. However,
generally I would object to this claim as I understand it, as the objects
are still reachable, as their destructors are somehow called during
shutdown.

Cheers!

Uli

 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      01-13-2011
On Jan 13, 7:24 pm, Leigh Johnston <(E-Mail Removed)> wrote:
> On 13/01/2011 18:57, Paavo Helde wrote:
> > Leigh Johnston<(E-Mail Removed)> wrote in news:wOOdnWqtq-
> > (E-Mail Removed):


> >> You are also forgetting that an object
> >> can become unreachable and yet not be a leak (delete this).


> > In order to 'delete this' the this pointer value must be known to the
> > executing code so clearly the object is not unreachable. And please don't
> > start to invent new definitions for "unreachable"!


> Following your logic all C++ objects are never unreachable as they all
> effectively have a "this" pointer so can never "leak" according to some
> people's definition of "leak"; this is absurd.


A C++ object is *not* unreachable when executing a member
function. A this pointer does prevent the memory from becoming
unreachable, but C++ objects don't have this pointers. Only
non-static member functions have this pointers, and then only
when they are actually executing.

> A memory leak can be a *consequence* of an object becoming
> unreachable.


One definition of a memory leak is that the object is
unreachable. IMHO, it's not a very useful definition, but some
Java programmers like to use it, in order to claim that memory
leaks are impossible in Java (despite Sun having recognized some
memory leaks as bugs).

> A memory leak is programmer provided allocation with no matching
> programmer provided deallocation.


That's an even more arbitrary definition, and certainly not
applicable in most cases.

> There is no difference between the following two programs as far as what
> the OS (or C/C++ runtime) has to cleanup during program termination
> (they both leak):


> --
> int* leak = new int[4200000];
> int main() {}
> --
> int main() { int* leak = new int[4200000]; }
> --


Who says there is?

--
James Kanze
 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      01-13-2011
On Jan 13, 5:01 pm, Francis Glassborow
<(E-Mail Removed)> wrote:
> On 13/01/2011 14:45, Dilip wrote:


> In which case the Standard C++ Library leaks because std::cout
> etc. are not normally destroyed these days.


The standard explicitly forbids their destruction. And purely
from memory (it was a long time ago), I don't think that they
were destructed in the original USL implementation.

> I was surprised when I discovered
> this because it used not to be the case. The argument is simply that
> letting the OS recover the storage at program termination is OK and it
> avoids problems when dtors of other static objects use them.


The argument is mainly that you don't want order of destructor
issues with them. You can safely use std::cerr in a destructor,
even if it is the destructor of a static object.

--
James Kanze
 
Reply With Quote
 
Ulrich Eckhardt
Guest
Posts: n/a
 
      01-13-2011
Leigh Johnston wrote:
> On 13/01/2011 14:45, Dilip wrote:
>> On Jan 13, 9:18 am, Leigh Johnston<(E-Mail Removed)> wrote:
>>> A memory leak is the failure to deallocate that which was allocated
>>> before program termination, end of story.

>>
>> A dynamically allocated singleton object whose lifetime extends until
>> the application shuts down is leaking memory? You are stretching the
>> definition of a "leak".

>
> If during program termination the C/C++ runtime or the OS has to cleanup
> a memory allocation due to a lack of a paired deallocation then that
> memory allocation is a leak yes.


If you want to define this term like that, so be it. But then, who cares
if a program leaks? After all, the memory is released on shutdown[0]. Yes,
these "leaks" can be detected automatically and there are easy ways to
avoid them, basically discipline in low-level resource management will do,
but they don't say anything about the runtime behaviour of the program.

Instead, the IMHO important property of a resource leak is that resources
are allocated and not used any more but also not released. In that sense,
I'd say you need at least two stages in the program, one that allocates an
object and a second that neither releases nor uses it. Further, I would
say that some steps are then usually repeated in a loop, causing an
increasing memory consumption with each repetition.

Example:

int main() {
vector<char> f = read_cfg_file();
settings s = parse_cfg(f);
// (1)
run_program(s);
}

At point (1), "f" becomes unused but remains allocated and thus
constitutes a memory leak according to my definition. It is paired with a
proper deallocation on program termination, so it isn't one in your
definition. I find mine more useful when talking about a program.

Even more so when considering a server process:

int main() {
list<connection> clients;
try {
while(true) {
connection c = accept_connection();
if(c)
clients.push_back(c);
service_connections(clients);
}
} catch(...) {
}
}

This program will not terminate on its own but continue to allocate new
connections until it runs out of memory because it fails to clean up or
otherwise limit the number of connections. It will then release existing
connections, so allocations and deallocations are paired.


> You are also forgetting that an object
> can become unreachable and yet not be a leak (delete this).


But if you have a this-pointer, the object is not unreachable. The fact
that the pointer was never explicitly declared anywhere doesn't matter:

struct foo {
void bar() {
delete this;
}
};

int main() {
(new foo)->bar();
}

There is no visible pointer to the allocated object, but it is still
reachable and deleted "correctly". I think this is also what first Paavo
and then James were trying to express.


Cheers!

Uli


[0] Yes, assuming the non-guaranteed but virtually omnipresent support by
the environment.
 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      01-13-2011

"Leigh Johnston" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ...
> On 13/01/2011 20:46, Ulrich Eckhardt wrote:
>> Leigh Johnston wrote:
>>> On 13/01/2011 14:45, Dilip wrote:
>>>> On Jan 13, 9:18 am, Leigh Johnston<(E-Mail Removed)> wrote:
>>>>> A memory leak is the failure to deallocate that which was allocated
>>>>> before program termination, end of story.
>>>>
>>>> A dynamically allocated singleton object whose lifetime extends until
>>>> the application shuts down is leaking memory? You are stretching the
>>>> definition of a "leak".
>>>
>>> If during program termination the C/C++ runtime or the OS has to cleanup
>>> a memory allocation due to a lack of a paired deallocation then that
>>> memory allocation is a leak yes.

>>
>> If you want to define this term like that, so be it. But then, who cares
>> if a program leaks? After all, the memory is released on shutdown[0].
>> Yes,
>> these "leaks" can be detected automatically and there are easy ways to
>> avoid them, basically discipline in low-level resource management will
>> do,
>> but they don't say anything about the runtime behaviour of the program.
>>
>> Instead, the IMHO important property of a resource leak is that resources
>> are allocated and not used any more but also not released. In that sense,
>> I'd say you need at least two stages in the program, one that allocates
>> an
>> object and a second that neither releases nor uses it. Further, I would
>> say that some steps are then usually repeated in a loop, causing an
>> increasing memory consumption with each repetition.
>>
>> Example:
>>
>> int main() {
>> vector<char> f = read_cfg_file();
>> settings s = parse_cfg(f);
>> // (1)
>> run_program(s);
>> }
>>
>> At point (1), "f" becomes unused but remains allocated and thus
>> constitutes a memory leak according to my definition. It is paired with a
>> proper deallocation on program termination, so it isn't one in your
>> definition. I find mine more useful when talking about a program.
>>
>> Even more so when considering a server process:
>>
>> int main() {
>> list<connection> clients;
>> try {
>> while(true) {
>> connection c = accept_connection();
>> if(c)
>> clients.push_back(c);
>> service_connections(clients);
>> }
>> } catch(...) {
>> }
>> }
>>
>> This program will not terminate on its own but continue to allocate new
>> connections until it runs out of memory because it fails to clean up or
>> otherwise limit the number of connections. It will then release existing
>> connections, so allocations and deallocations are paired.
>>

>
> Yes but the connection objects in your example are not unreachable either
> which was my problem with the definition of what constitutes a leak that
> others were espousing. Obviously your use of a try block was deliberate
> to strengthen your position as without it you would likely get an abort()
> on unhandled bad_alloc resulting in list dtor *possibly* not being called
> (as Standard does not require it), sneaky.
>
> I agree that recurring leaks are worse than singular leaks (I have said
> this more than once now).
>

That's not a memory leak , its simply bad programming.

> I think it is impossible to arrive at a definition of what constitutes a
> memory leak that everyone agrees with; that much is obvious.
>

No a memory leak is when you 'lose' a pointer to allocated memory.
Or you could say:
You have unrecoverable memory (within the realm of process).
Your programs useable memory has leaked away.

It's pretty simple. Where does your disagreement lie?

 
Reply With Quote
 
Ulrich Eckhardt
Guest
Posts: n/a
 
      01-13-2011
Paul wrote:
> [...] a memory leak is when you 'lose' a pointer to allocated memory.
> Or you could say:
> You have unrecoverable memory (within the realm of process).
> Your programs useable memory has leaked away.


These are not equivalent. If there is a fixed amount of memory that is
unrecoverable, that is bad, but not something people would call a memory
leak, at least not a grave one. If the amount of unused but reserved
memory grows, the remaining usable memory leaks away, even if it is
recovered at shutdown.

> It's pretty simple. Where does your disagreement lie?


See above.

Uli

 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      01-13-2011

"Ulrich Eckhardt" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)-berlin.de...
> Paul wrote:
>> [...] a memory leak is when you 'lose' a pointer to allocated memory.
>> Or you could say:
>> You have unrecoverable memory (within the realm of process).
>> Your programs useable memory has leaked away.

>
> These are not equivalent. If there is a fixed amount of memory that is
> unrecoverable, that is bad, but not something people would call a memory
> leak, at least not a grave one.

Perhaps you do have a creative side after all . You seem to have created a
new programming term re:
"Grave memory leak", not be confused with a plain old memory leak.


> If the amount of unused but reserved
> memory grows, the remaining usable memory leaks away, even if it is
> recovered at shutdown.
>

I don't see how any reserved memory could just grow into the heap , please
can you elaborate on your theory.

 
Reply With Quote
 
Ulrich Eckhardt
Guest
Posts: n/a
 
      01-13-2011
Paul wrote:
> "Ulrich Eckhardt" <(E-Mail Removed)> wrote in message
>> If the amount of unused but reserved memory grows, the remaining
>> usable memory leaks away, even if it is recovered at shutdown.

>
> I don't see how any reserved memory could just grow into the heap ,
> please can you elaborate on your theory.


Imagine a webserver that appends the IP address and time of every incoming
connection to a list. This list will grow over time, consuming all memory.
Only when you shut down the process, it will be released.

An automated leak checker will find no unreleased memory after shutdown.
Still, the program has a problem due to unreleased and unused memory. The
question where opinions differ is whether this should be called a memory
leak or not.

Uli

 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      01-13-2011
["Followup-To:" header set to comp.lang.c++.]

On Thu, 2011-01-13, Leigh Johnston wrote:
> On 13/01/2011 15:40, Dilip wrote:
>> On Jan 13, 9:56 am, Leigh Johnston<(E-Mail Removed)> wrote:
>>> On 13/01/2011 14:45, Dilip wrote:

....
>>>> Anyway.. we don't need to restart this all over again.. One thread was
>>>> enough.
>>>
>>> Why reply then?

>>
>> Because, believe it or not, I find most of your posts terribly
>> illuminating. You obviously know your stuff. If you could only stay
>> away from that occasional ad-hominem, I can actually learn a thing or
>> two everyday.
>>

>
> This is the Internet; occasional ad-hominems are the Internet's lifeblood.


No it isn't. It's rather the vampire sucking the blood.

I might as well bring it up here: I think the overall tone on
comp.lang.c++ has deteriorated a lot in the past year or so. Even from
people I respect -- people who are perhaps not the *best* C++
programmers out there, but the best ones who also have some time to
spare and like to discuss their work.

My own postings have probably deteriorated too.

Two patterns I dislike:

- Arguments between regulars who know the language. These too often go
quickly from arguments to an unwillingness to understand, to trench
warfare, and then into ad hominem attacks.

- Newbie (often from .in or .cn) comes with misguided question based
on false assumptions, archaic compilers, bad teachers, failure to
read the FAQ, etc. We are too eager to jump on such postings -- you
can have half a dozen people point out the various flaws ... with
rather obvious malice.

I don't even count this Paul incident. Some flame wars with
unreasonable people are expected, and the best you can do is to use
your killfile.

We're using one of the best programming languages out there. Even
though all programming is 80% pure frustration, we shouldn't be this
frustrated and easily offended when we discuss it.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      01-13-2011

"Ulrich Eckhardt" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)-berlin.de...
> Paul wrote:
>> "Ulrich Eckhardt" <(E-Mail Removed)> wrote in message
>>> If the amount of unused but reserved memory grows, the remaining
>>> usable memory leaks away, even if it is recovered at shutdown.

>>
>> I don't see how any reserved memory could just grow into the heap ,
>> please can you elaborate on your theory.

>
> Imagine a webserver that appends the IP address and time of every incoming
> connection to a list. This list will grow over time, consuming all memory.
> Only when you shut down the process, it will be released.
>
> An automated leak checker will find no unreleased memory after shutdown.
> Still, the program has a problem due to unreleased and unused memory. The
> question where opinions differ is whether this should be called a memory
> leak or not.
>
> Uli
>

I thought you meant memory reserved by an OS in a simple one process PE,
when you said 'reserved memory'.

Your talking about shuting down processes and stuff, I specificaly said that
it was beyond this newsgroup to discuss multi process applications and I was
only talking about single process apps , so it doesnt apply to my defintion
..

In a multi-process setup I guess its all controlled by the process-owner or
whatever processes have access to the memory regions allocated to the
processses by the app. If you are talking about a server OS then pppffffft,
beyond me


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Some information for the one who decided to learn C++, and now wantsto learn at least a bit of C? Alexander C Programming 20 09-11-2010 01:04 AM
How we recognize newbies as newbies Alf P. Steinbach C++ 31 08-21-2007 05:12 PM
Learn the language before you learn the GUI. CoreyWhite C++ 1 03-31-2007 08:56 PM
Re: Newbies? - Usenet don't need no steenking newbies! =?iso-8859-1?Q?=B1?= Digital Photography 2 07-17-2004 02:26 PM
newbie question: should I learn TKinter or skip it and learn more advanced toolkit? Porky Pig Jr Python 3 05-12-2004 08:58 AM



Advertisments