Newbies don't learn C++

[Paul]

The only reference i made to Java was to suggest it is much more portable
across ALL of the new devices that are the current fashion.
i.e: mobile phones, since you obviously need an example to explain this.

Depends on your technical definition of portable. While there might be
less porting work when taking java from implementation A to
implementation B, I'm pretty sure that C is supported on much more
hardware than Java.

...............................................................


What do you mean by 'supported on hardware'?
I didn't realise hardware was designed to support any specifiic programming
language.

With C you need to learn a whole new API everytime a new device comes into
fashion, not so with Java. I could make a crude mobile phone application,
from scratch, in a few hours with java. If I were to attempt this in C it
would take a week to get compiler and API docs alone.
Additionaly the Java App would work on a ton of different phones, and
require very little tinkering to work on the rest. The C App would work on
one type of phone only.

As they seem to be releasing some new gadget every month it will not be
worth spending the time to learn the API, by the time you create your first
App , someone else will probably have done it and it will be time to learn
something new. The only serious use of C++ will be massive programs such as
video games and lets face it only a very select few programmers will ever
reach the grand level of directX video programmer.

I always supported C++ because I was a speed freak, but with the speed of
processors nowadays is there any real noteable difference in most non speed
critical programs, or network programs that are restricted in speed by the
network anyway. I am now leaning towards Java and there is always ASM for
devices that do not support Java, can always hack a program together in C if
needed.
It seems my idea of C++ are not fitting with the direction C++ seems to be
going anyway. As they seem to be going down the route of more complicated
compilers it will be even more difficult to develop compilers for new
devices.
C++ seems to be trying to expand in all directions at once with no real
direction and as I said elsewhere seems very confused and overly
complicated. Yet at the same time C++ seems to be going back in time to C
with a few bolts ons. The chicken-egg scenario with the standards doesn't
make the picture any prettier.


I used to know what a member function was in C++ but apparently I don't
anymore , and neither does Bjarne Stroustrup

 

[Paul]

in message

[...]

Again this is just clueless guff; how is anybody supposed to
*understand* clueless guff.

SO WHY DO YOU CONTINUE TO FEED THIS NASTY TROLL???

Regards,

Jarrick

There is still a small possibility that he is not a troll just somebody
who holds incorrect opinions and finds it hard being told that said
opinions are incorrect.

I am close to adding an ignore filter though but others will reply even
if I don't and I am not sure ignoring an entire thread is a good idea as
threads often go through a change of subject.

/Leigh

Regardless of anything else, someone who uses gay and homosexual as
insults and hopes that other posters will die in 2011 should be ignored.

Ahaaah a gay conference , can't afford to miss that one lads ;-)

 

[Dilip]

in message

[...]

Again this is just clueless guff; how is anybody supposed to
*understand* clueless guff.

SO WHY DO YOU CONTINUE TO FEED THIS NASTY TROLL???

Jarrick

There is still a small possibility that he is not a troll just somebody
who holds incorrect opinions and finds it hard being told that said
opinions are incorrect.

I find this extremely hard to believe. I am a passive observer on
this newsgroup and I have constantly followed your incoherent attacks
on James Kanze. Mr. Kanze, as anyone in this newsgroup will attest,
is extremely well respected in the C++ community. One of those
handful of people who can quote the C++ standard chatper & verse and
has probably attended many committee meetings that you and I can never
spend time doing. Innumerable times you have called him a troll,
accused him of posting bullshit and such.

So you actually are open to the possibility that Paul might not be a
troll (after he pretty much cursed Francis, another expert in the C++
community, to die in 2011) but you are ready to jump on Mr. Kanze's
throat at the slightest sign of disagreement with him?

Please...

 

[Johannes Schaub (litb)]

I was programming Windows COM Objects 10 years ago , and I'm not
interested in that anymore.Its old tech.
It appears to me that "the C++ community" has become very confused, since
I last visisted the world of C++.

Please tell me where you learned to troll that way. I could never even get
10 people to get in rage about something I write!

 

[Dilip]

Please?  Mr Kanze does spout bullshit occasionally (not always) and
refuses to back down which seems like trolling to me.  Stop appealing to
this mythical "C++ community" authority.  For the record I have also
called Paul obnoxious in addition to asserting that his rants are bullshit.

/Leigh

We should all be thankful that Mr. Johnston is here to mop up all that
bullshit.

Nevertheless I didn't appeal to the C++ community's authority. I said
he is an expert in my mind. I didn't say experts shouldn't be wrong.
My point is the way you deal with stuff that seems to go against your
world view. If you disagree, please go re-read the thread where there
was a lot of noise about what constitutes a memory leak. At any given
point in time, more than 5 people disagreed with your definition of a
memory leak, yet you stood your ground claiming you are right (by
quoting MSDN of all the places) and the rest of the world is on LSD.

In what way are you different from Paul in this regard?

 

[Paul]

On 13/01/2011 11:36, Dilip wrote:

In what way are you different from Paul in this regard?

Please do not compare me to Leigh.
I am correct 99.9% of the time. Leigh is nothing more thna a babbling idiot.


For proof see the outcome of this thread where Leigh argues with a Bjarne
Stroustrup quote then runs away when confronted with some basic asm.

 

[Dilip]

The difference is Paul is spouting bullshit which is in conflict with
the C++ standard and we *all* agree he is spouting bullshit.

What I said regarding the definition of a memory leak was not bullshit;
I gave an example which agreed with my definition (DLL).

That was not the scenario where Mr. Kanze's singleton was supposed to
be used.

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

Anyway.. we don't need to restart this all over again.. One thread was
enough.

 

[Fred Zwarts]

...

In what way are you different from Paul in this regard?

The resemblance of their reactions is indeed surprizing.
Has it occurred to you that it could be one person posting with two names?
Or maybe with a multi-personality problem, so that they really are
communicating with each other using this newsgroup?

 

[Dilip]

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.  You are also forgetting that an object
can become unreachable and yet not be a leak (delete this).




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.

 

[Paul]

It's beyond the realms of your imagination to discuss the technicalities of
a multi process program. Therefore I suggest you only consider a memory leak
within the constraints of a single process PE.
With that, it is correct to say that a memory leak is when you "lose" the
pointer to a block of memory.

A memory leak is not a failure to deallocate on program termination. This is
something a beginner is encouraged to do as an excercise of good practise.

In which case the Standard C++ Library leaks because std::cout etc. are
not normally destroyed these days. 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.

Again multi-process apps are beyond the imagination of most users here.
In the case of a single process PE its not quite a case of "letting" the OS
recover memory . The OS *will* recover the memory.
I will leave you dudes to argue about whether this is OK or not.

 

[Ulrich Eckhardt]

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

 

[James Kanze]

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):

Who says there is?

 

[James Kanze]

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.

 

[Ulrich Eckhardt]

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.

 

[Paul]

On 13/01/2011 14:45, Dilip 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?

 

[Ulrich Eckhardt]

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

 

[Paul]

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

 

[Ulrich Eckhardt]

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

 

[Jorgen Grahn]

["Followup-To:" header set to comp.lang.c++.]

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

 

[Paul]

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