Fake memory leaks?

Please take the holy war off list.

Thanks! :slight_smile:

It’s not a holy war. That suggests the matter is entirely one
of personal feelings and irrational choice.

Language design is a matter of computer science mixed
with some human psychology.

If we argue that one sort algorithm is faster than another,
it isn’t a matter of opinion. The performance can be calculated
with complexity theory and it can be measure by experiment.

This applies to languages too. But its your list so I’ll shut up now :)On 12/04/2011, at 1:36 AM, Sam Lantinga wrote:


john skaller
@john_skaller

FWIW, I agree with the first part, but not the second part. It is clear though
that C in the hands of non-experts can be dangerous. But that’s true of C++
also.

This is why, despite employers’ desire to hire only young people, they should
hire a few “old pros” to ride herd on the cats. :wink:

JeffOn Tuesday 12 April 2011 07:08, john skaller wrote:

On 12/04/2011, at 1:22 AM, Gordiychuck Oleg wrote:

Definetely C is hard language. But it is only for noobs and for that who
doesn’t understand what he is going to do.

All languages are hard for noobs… C is unique in that its hard for experts
too :slight_smile:

Then get debugging symbols for all of your libraries and re-run Valgrind,
then report the leak. I’ve had to do it once with Xorg, I’m sure you guys
can to. Considering that most of what you’re using is libraries, they are
likely bugs not …features… (i.e. intentional).On Mon, Apr 11, 2011 at 7:52 AM, john skaller <skaller at users.sourceforge.net wrote:

On 11/04/2011, at 3:26 AM, Nikos Chantziaras wrote:

But we’re not talking about a program here, we’re talking about leaky
libraries (since clearly

the OP’s program doesn’t leak).

It’s still the same.

I do not agree. It is legitimate for a program to allocate memory and leave
it
up to the OS to reclaim it on exit.

It is NOT legitimate for a library to do this because the library does not
have the responsibility of deciding the use of the components and
facilities
it supplies.

A library might allocate something that will exist for the whole lifetime
of the program using the library.

Then, we a few special exceptions, that library is bugged and should be
fixed.

Those allocations will be freed too by the OS at program termination.

A real leak is something that should have been freed prior to program
termination.

I can agree with that but only because what this claim
does is delegate the problem to consideration of what "should"
have been freed.

The issue is: “who” makes that decision, and the answer “should” be:
the application, and only the application.

A library which allocates memory must clearly document who is responsible
for making the decision to free it or not, and if so when to do so.

For example , SDL_init() may allocate memory and that
had better be freed by SDL_quit() (or some other specified function).
If some other functions (allocating a display surface for example)
requires the client to release it, or it is safe to call SDL_quit() because
it will do so, then this too must be documented.

IMHO: The root cause of this problem is badly educated programmers using
a bad language (namely C) with a bad library. The problem is greatly
reduced
using constructors and destructors in C++, and even further in languages
with
garbage collectors… so there ARE alternatives.


john skaller
skaller at users.sourceforge.net


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org