Fake memory leaks?

SDL Development
1

Hi,

This probably is a stupid question, but please bear with me, I’m
relatively new to SDL…

I have this very basic program that just initializes SDL and then
quits it without doing anything. The code looks like this:

#include <SDL/SDL.h>
int main(int argc, char** argv){
SDL_Init(SDL_INIT_VIDEO);
SDL_Surface* screen = SDL_SetVideoMode(640, 480, 16, SDL_HWSURFACE);
SDL_Quit();
return 0;
}

Yet, when I run this program through Valgrind, it reports a memory leak:

==2554== LEAK SUMMARY:
==2554== definitely lost: 440 bytes in 8 blocks
==2554== indirectly lost: 352 bytes in 8 blocks
==2554== possibly lost: 0 bytes in 0 blocks
==2554== still reachable: 58,942 bytes in 884 blocks
==2554== suppressed: 0 bytes in 0 blocks

My question is, what is the cause of this? Is this a real leak? Maybe
Valgrind is reporting something wrong? Or are there some buffers
allocated within the library that deliberately don’t get free()'d? If
yes, what is the motivation of this?

I’d like to hear a library developer’s opinion on this issue.

Thanks!

2

Hi, maybe try calling SDL_FreeSurface after SDL_Quit…

-----Urspr?ngliche Nachricht-----Von: sdl-bounces at lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] Im
Auftrag von Grigory Javadyan
Gesendet: Samstag, 9. April 2011 22:09
An: sdl at lists.libsdl.org
Betreff: [SDL] Fake memory leaks?

Hi,

This probably is a stupid question, but please bear with me, I’m
relatively new to SDL…

I have this very basic program that just initializes SDL and then
quits it without doing anything. The code looks like this:

#include <SDL/SDL.h>
int main(int argc, char** argv){
SDL_Init(SDL_INIT_VIDEO);
SDL_Surface* screen = SDL_SetVideoMode(640, 480, 16, SDL_HWSURFACE);
SDL_Quit();
return 0;
}

Yet, when I run this program through Valgrind, it reports a memory leak:

==2554== LEAK SUMMARY:
==2554== definitely lost: 440 bytes in 8 blocks
==2554== indirectly lost: 352 bytes in 8 blocks
==2554== possibly lost: 0 bytes in 0 blocks
==2554== still reachable: 58,942 bytes in 884 blocks
==2554== suppressed: 0 bytes in 0 blocks

My question is, what is the cause of this? Is this a real leak? Maybe
Valgrind is reporting something wrong? Or are there some buffers
allocated within the library that deliberately don’t get free()'d? If
yes, what is the motivation of this?

I’d like to hear a library developer’s opinion on this issue.

Thanks!

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

3

There are some leaks in the C library, some leaks in the X11 libraries, and
if this is SDL 1.3, there might be some newly introduced leaks.

Can you tell where things were allocated?On Sat, Apr 9, 2011 at 1:08 PM, Grigory Javadyan <grigory.javadyan at gmail.com wrote:

Hi,

This probably is a stupid question, but please bear with me, I’m
relatively new to SDL…

I have this very basic program that just initializes SDL and then
quits it without doing anything. The code looks like this:

#include <SDL/SDL.h>
int main(int argc, char** argv){
SDL_Init(SDL_INIT_VIDEO);
SDL_Surface* screen = SDL_SetVideoMode(640, 480, 16, SDL_HWSURFACE);
SDL_Quit();
return 0;
}

Yet, when I run this program through Valgrind, it reports a memory leak:

==2554== LEAK SUMMARY:
==2554== definitely lost: 440 bytes in 8 blocks
==2554== indirectly lost: 352 bytes in 8 blocks
==2554== possibly lost: 0 bytes in 0 blocks
==2554== still reachable: 58,942 bytes in 884 blocks
==2554== suppressed: 0 bytes in 0 blocks

My question is, what is the cause of this? Is this a real leak? Maybe
Valgrind is reporting something wrong? Or are there some buffers
allocated within the library that deliberately don’t get free()'d? If
yes, what is the motivation of this?

I’d like to hear a library developer’s opinion on this issue.

Thanks!

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

4

AFAIK, you don’t need to call SDL_FreeSurface on the video surface,
since SDL_Quit does it… Anyway, I tried that too and it did not
help.On Sun, Apr 10, 2011 at 1:25 AM, Tobias Leich wrote:

Hi, maybe try calling SDL_FreeSurface after SDL_Quit…

-----Urspr?ngliche Nachricht-----
Von: sdl-bounces at lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] Im
Auftrag von Grigory Javadyan
Gesendet: Samstag, 9. April 2011 22:09
An: sdl at lists.libsdl.org
Betreff: [SDL] Fake memory leaks?

Hi,

This probably is a stupid question, but please bear with me, I’m
relatively new to SDL…

I have this very basic program that just initializes SDL and then
quits it without doing anything. The code looks like this:

#include <SDL/SDL.h>
int main(int argc, char** argv){
?SDL_Init(SDL_INIT_VIDEO);
?SDL_Surface* screen = SDL_SetVideoMode(640, 480, 16, SDL_HWSURFACE);
?SDL_Quit();
?return 0;
}

Yet, when I run this program through Valgrind, it reports a memory leak:

==2554== LEAK SUMMARY:
==2554== ? ?definitely lost: 440 bytes in 8 blocks
==2554== ? ?indirectly lost: 352 bytes in 8 blocks
==2554== ? ? ?possibly lost: 0 bytes in 0 blocks
==2554== ? ?still reachable: 58,942 bytes in 884 blocks
==2554== ? ? ? ? suppressed: 0 bytes in 0 blocks

My question is, what is the cause of this? Is this a real leak? Maybe
Valgrind is reporting something wrong? Or are there some buffers
allocated within the library that deliberately don’t get free()'d? If
yes, what is the motivation of this?

I’d like to hear a library developer’s opinion on this issue.

Thanks!

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

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

5

I’m using SDL version 1.2 patchlevel 14 if that matters. I’ve run
valgrind with --leak-check=full and saw that some of the unattended
allocations apparently happen within Xlib. Maybe the problem is there.On Sun, Apr 10, 2011 at 1:29 AM, Sam Lantinga wrote:

There are some leaks in the C library, some leaks in the X11 libraries, and
if this is SDL 1.3, there might be some newly introduced leaks.

Can you tell where things were allocated?

On Sat, Apr 9, 2011 at 1:08 PM, Grigory Javadyan <@Grigory_Javadyan> wrote:

Hi,

This probably is a stupid question, but please bear with me, I’m
relatively new to SDL…

I have this very basic program that just initializes SDL and then
quits it without doing anything. The code looks like this:

#include <SDL/SDL.h>
int main(int argc, char** argv){
?SDL_Init(SDL_INIT_VIDEO);
?SDL_Surface* screen = SDL_SetVideoMode(640, 480, 16, SDL_HWSURFACE);
?SDL_Quit();
?return 0;
}

Yet, when I run this program through Valgrind, it reports a memory leak:

==2554== LEAK SUMMARY:
==2554== ? ?definitely lost: 440 bytes in 8 blocks
==2554== ? ?indirectly lost: 352 bytes in 8 blocks
==2554== ? ? ?possibly lost: 0 bytes in 0 blocks
==2554== ? ?still reachable: 58,942 bytes in 884 blocks
==2554== ? ? ? ? suppressed: 0 bytes in 0 blocks

My question is, what is the cause of this? Is this a real leak? Maybe
Valgrind is reporting something wrong? Or are there some buffers
allocated within the library that deliberately don’t get free()'d? If
yes, what is the motivation of this?

I’d like to hear a library developer’s opinion on this issue.

Thanks!

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

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

6

This is very common. That doesn’t make it OK, of course, but it is
common nonetheless. The reason is that many developers don’t bother
checking if everything is deallocated at the end of a program, since
that’s not really necessary; when the program ends, the operating system
will free all its memory.

Best thing you can do is bugger the packagers of your Linux distribution
about it, so that they can add this leak to the default valgrind
suppression list. The suppression lists shipped by distros are huge,
exactly because this kind of thing is very common.On 04/09/2011 11:08 PM, Grigory Javadyan wrote:

[…]
Yet, when I run this program through Valgrind, it reports a memory leak:

==2554== LEAK SUMMARY:
==2554== definitely lost: 440 bytes in 8 blocks
==2554== indirectly lost: 352 bytes in 8 blocks
==2554== possibly lost: 0 bytes in 0 blocks
==2554== still reachable: 58,942 bytes in 884 blocks
==2554== suppressed: 0 bytes in 0 blocks

My question is, what is the cause of this? Is this a real leak?

7

Use valgrind’s result with caution, as most of what it reports is harmless.
I’ve never seen a case where “still reachable” blocks are a problem, they
usually are deallocated after the valgrind log.
Also most of the time you can’t make sense of it without an understanding of
the API. A leak originating in X11 may be caused by a driver, X11, or by SDL
who forgot to free a struct returned by an xlib method, or by you who forgot
to free something returned by a method. Check the documentation of the
libraries you use, but don’t worry about it too much.
What’s most important to fix in valgrind are leaks that originate in your
code (the top line of the stack is in your code). As for other errors, if
they bother you, you can create a custom suppression file to hide them,
especially if they clutter your result :
http://valgrind.org/docs/manual/manual-core.html#manual-core.suppress

2011/4/9 Grigory Javadyan <grigory.javadyan at gmail.com>> I’m using SDL version 1.2 patchlevel 14 if that matters. I’ve run

valgrind with --leak-check=full and saw that some of the unattended
allocations apparently happen within Xlib. Maybe the problem is there.

On Sun, Apr 10, 2011 at 1:29 AM, Sam Lantinga wrote:

There are some leaks in the C library, some leaks in the X11 libraries,
and
if this is SDL 1.3, there might be some newly introduced leaks.

Can you tell where things were allocated?

On Sat, Apr 9, 2011 at 1:08 PM, Grigory Javadyan <grigory.javadyan at gmail.com> wrote:

Hi,

This probably is a stupid question, but please bear with me, I’m
relatively new to SDL…

I have this very basic program that just initializes SDL and then
quits it without doing anything. The code looks like this:

#include <SDL/SDL.h>
int main(int argc, char** argv){
SDL_Init(SDL_INIT_VIDEO);
SDL_Surface* screen = SDL_SetVideoMode(640, 480, 16, SDL_HWSURFACE);
SDL_Quit();
return 0;
}

Yet, when I run this program through Valgrind, it reports a memory leak:

==2554== LEAK SUMMARY:
==2554== definitely lost: 440 bytes in 8 blocks
==2554== indirectly lost: 352 bytes in 8 blocks
==2554== possibly lost: 0 bytes in 0 blocks
==2554== still reachable: 58,942 bytes in 884 blocks
==2554== suppressed: 0 bytes in 0 blocks

My question is, what is the cause of this? Is this a real leak? Maybe
Valgrind is reporting something wrong? Or are there some buffers
allocated within the library that deliberately don’t get free()'d? If
yes, what is the motivation of this?

I’d like to hear a library developer’s opinion on this issue.

Thanks!

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

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

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

8

As an anecdote, I should mention that on some operating systems, one can not expect the OS to clean up after an exiting application.

AmigaOS verions 1.x-3.x (not sure about 4.x) are one such case, where only free memory is tracked, and programs share a single memory space and allocation system, this lead to an amazing level of
paranoid debugging and careful program design.On 04/09/2011 02:01 PM, Nikos Chantziaras wrote:

This is very common. That doesn’t make it OK, of course, but it is common nonetheless. The reason is that many developers don’t bother checking if everything is deallocated at the end of a program,
since that’s not really necessary; when the program ends, the operating system will free all its memory.

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

9

I’m using SDL version 1.2 patchlevel 14 if that matters. I’ve run
valgrind with --leak-check=full and saw that some of the unattended
allocations apparently happen within Xlib. Maybe the problem is there.

Yeah, Xlib has some small allocations it fails to free (it’s not a bug
in SDL, last time I checked). It’s been that way for years,
unfortunately, but it’s only a few bytes for something that probably is
meant to live as long as your process in most cases anyhow.

–ryan.

10

There are some leaks in the C library,

Really? Do you know where? I ran some code with Valgrind on my system which
uses C and a garbage collector (to check the GC) and at the end of the program
Valgrind reported zero leaks.On 10/04/2011, at 6:29 AM, Sam Lantinga wrote:

–
john skaller
@john_skaller

11

[…]
Yet, when I run this program through Valgrind, it reports a memory leak:

==2554== LEAK SUMMARY:
==2554== definitely lost: 440 bytes in 8 blocks
==2554== indirectly lost: 352 bytes in 8 blocks
==2554== possibly lost: 0 bytes in 0 blocks
==2554== still reachable: 58,942 bytes in 884 blocks
==2554== suppressed: 0 bytes in 0 blocks

My question is, what is the cause of this? Is this a real leak?

This is very common. That doesn’t make it OK, of course, but it is common nonetheless. The reason is that many developers don’t bother checking if everything is deallocated at the end of a program, since that’s not really necessary; when the program ends, the operating system will free all its memory.

Best thing you can do is bugger the packagers of your Linux distribution about it, so that they can add this leak to the default valgrind suppression list. The suppression lists shipped by distros are huge, exactly because this kind of thing is very common.

But we’re not talking about a program here, we’re talking about leaky libraries (since clearly
the OP’s program doesn’t leak).On 10/04/2011, at 7:01 AM, Nikos Chantziaras wrote:

On 04/09/2011 11:08 PM, Grigory Javadyan wrote:

–
john skaller
@john_skaller

12

[…]
Yet, when I run this program through Valgrind, it reports a memory leak:

==2554== LEAK SUMMARY:
==2554== definitely lost: 440 bytes in 8 blocks
==2554== indirectly lost: 352 bytes in 8 blocks
==2554== possibly lost: 0 bytes in 0 blocks
==2554== still reachable: 58,942 bytes in 884 blocks
==2554== suppressed: 0 bytes in 0 blocks

My question is, what is the cause of this? Is this a real leak?

This is very common. That doesn’t make it OK, of course, but it is common nonetheless. The reason is that many developers don’t bother checking if everything is deallocated at the end of a program, since that’s not really necessary; when the program ends, the operating system will free all its memory.

Best thing you can do is bugger the packagers of your Linux distribution about it, so that they can add this leak to the default valgrind suppression list. The suppression lists shipped by distros are huge, exactly because this kind of thing is very common.

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. A library might allocate something that will exist
for the whole lifetime of the program using the library. 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.On 04/10/2011 08:32 AM, john skaller wrote:

On 10/04/2011, at 7:01 AM, Nikos Chantziaras wrote:

On 04/09/2011 11:08 PM, Grigory Javadyan wrote:

13

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.On 11/04/2011, at 3:26 AM, Nikos Chantziaras wrote:

–
john skaller
@john_skaller

14

Sorry for off-topic, but what is your opinion of C being a "bad"
language based on? :)On Mon, Apr 11, 2011 at 5:52 PM, john skaller wrote:

On 11/04/2011, at 3:26 AM, Nikos Chantziaras wrote:
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

15

Move that to the game programmer mailing list or private, perhaps?

Jonny DOn Mon, Apr 11, 2011 at 10:39 AM, Grigory Javadyan <grigory.javadyan at gmail.com> wrote:

Sorry for off-topic, but what is your opinion of C being a "bad"
language based on? :slight_smile:

On Mon, Apr 11, 2011 at 5:52 PM, john skaller wrote:

On 11/04/2011, at 3:26 AM, Nikos Chantziaras wrote:
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

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

16

Experience? Let’s see, just off the top of my head:

Security holes.
Worst string type ever, with the possible exception of Erlang’s.
Array/pointer confusion.
Security holes.
No boolean type/everything is a boolean, leading to…
Assignment can return a result, leading to…
Ugly “Yoda conditionals” (if 5 == variable) as a “best practice”.
Security holes.
Duplicate logical/bitwise versions of all boolean operators (necessary because
everything is a boolean).
No exception support, making convoluted goto spaghetti necessary for proper
error handling.
Complicated, unintuitive syntax.
Weird variable declaration. (What does “int* a, b;” declare? Not what you’d
intuitively expect…)
Oh, and did I mention it’s directly responsible for billions of dollars lost due
to the exploitation of all the SECURITY HOLES inherent in the C language?>----- Original Message ----

From: Grigory Javadyan <grigory.javadyan at gmail.com>
Subject: Re: [SDL] Fake memory leaks?

Sorry for off-topic, but what is your opinion of C being a "bad"
language based on? :slight_smile:

On Mon, Apr 11, 2011 at 5:52 PM, john skaller wrote:

On 11/04/2011, at 3:26 AM, Nikos Chantziaras wrote:
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.

17

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 you said before is just “difference” or i may say even a “feature” of C, that you should understand when you’re going to use it. C is synonym of such words as stability, portability and speed. This was proven by years of work applications such as linux kernel’s, ffmpeg and etc.

I love holywars :D.

11 ???. 2011, ? 17:59, Mason Wheeler ???(?):> Experience? Let’s see, just off the top of my head:

Security holes.
Worst string type ever, with the possible exception of Erlang’s.
Array/pointer confusion.
Security holes.
No boolean type/everything is a boolean, leading to…
Assignment can return a result, leading to…
Ugly “Yoda conditionals” (if 5 == variable) as a “best practice”.
Security holes.
Duplicate logical/bitwise versions of all boolean operators (necessary because
everything is a boolean).
No exception support, making convoluted goto spaghetti necessary for proper
error handling.
Complicated, unintuitive syntax.
Weird variable declaration. (What does “int* a, b;” declare? Not what you’d
intuitively expect…)
Oh, and did I mention it’s directly responsible for billions of dollars lost due
to the exploitation of all the SECURITY HOLES inherent in the C language?

----- Original Message ----
From: Grigory Javadyan <grigory.javadyan at gmail.com>
Subject: Re: [SDL] Fake memory leaks?

Sorry for off-topic, but what is your opinion of C being a "bad"
language based on? :slight_smile:

On Mon, Apr 11, 2011 at 5:52 PM, john skaller wrote:

On 11/04/2011, at 3:26 AM, Nikos Chantziaras wrote:
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.

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

18

Please take the holy war off list.

Thanks! :slight_smile:

2011/4/11 Gordiychuck Oleg > 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 you said before is just
"difference" or i may say even a “feature” of C, that you should understand
when you’re going to use it. C is synonym of such words as stability,
portability and speed. This was proven by years of work applications such as
linux kernel’s, ffmpeg and etc.

I love holywars :D.

11 ???. 2011, ? 17:59, Mason Wheeler ???(?):

Experience? Let’s see, just off the top of my head:

Security holes.
Worst string type ever, with the possible exception of Erlang’s.
Array/pointer confusion.
Security holes.
No boolean type/everything is a boolean, leading to…
Assignment can return a result, leading to…
Ugly “Yoda conditionals” (if 5 == variable) as a “best practice”.
Security holes.
Duplicate logical/bitwise versions of all boolean operators (necessary
because
everything is a boolean).
No exception support, making convoluted goto spaghetti necessary for
proper
error handling.
Complicated, unintuitive syntax.
Weird variable declaration. (What does “int* a, b;” declare? Not what
you’d
intuitively expect…)
Oh, and did I mention it’s directly responsible for billions of dollars
lost due
to the exploitation of all the SECURITY HOLES inherent in the C language?

----- Original Message ----
From: Grigory Javadyan <grigory.javadyan at gmail.com>
Subject: Re: [SDL] Fake memory leaks?

Sorry for off-topic, but what is your opinion of C being a "bad"
language based on? :slight_smile:

On Mon, Apr 11, 2011 at 5:52 PM, john skaller wrote:

On 11/04/2011, at 3:26 AM, Nikos Chantziaras wrote:
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.

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

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

19

Sorry for off-topic, but what is your opinion of C being a "bad"
language based on? :slight_smile:

30 years of computer science and experience with other languages.
including 10 years as a member of ISO/IEC SC22/WG21 (C++ committee)
and a couple on the C committee.

Please try Haskell or Ocaml to understand. Even C++ is
superior and has the advantage of retaining compatibility with
C libraries without dramas.

in fact, experience with extending C to C++ shows just how bad C
really is (particularly generalising by templates):
it gets just about everything wrong that you could
possible get wrong: automatic conversions, casts, unsafe dereference
and array operations, ridiculously weak type system without polymorphism,
unsafe linkage, exceptionally hard to optimise due to bad semantics (cf Fortran
and “restrict” added to C99 to try to fix this), lack of sum types,
lack of anonymous product types, lack of closures, lack of control inversion
(control exchange primitive) absurdly difficult
type syntax … do I have to go on? Unsafe and non-reentrant libraries,
static/global variables … macros, non-platform independent code,
… Is there anything at all C did right?

It’s not entirely off topic in that whilst SDL library is C, you don’t
have to write C to use it. C++ binds seamlessly, Felix binds almost
seamlessly, and there are many other languages with SDL bindings.

On the topic of control inversion (lightweight threads) Felix has
channels and cooperative threads ideally suited for games;
basically every actor can have its own thread and be in control
of its actions (a control master) without a performance penalty.
Go also has channels though I’ve never tried it. The language comes
with some SDL demos using this technique. So far it works but is
still a bit clumsy to use. The model is akin to using chips and wiring
them together. The wiring is still difficult but the chips (actors)
can be programmed independently. In a similar way to a functions
only actors have state. Like an object. Only, with ordinary objects
you have to use callbacks which makes object methods slaves:
actors are just like threads (they’re masters) but control exchange
is done by reading/writing channels instead of pre-emptively.

So there are alternatives to C, although C is of course more
mature … or is that just more polite than senile? :)On 12/04/2011, at 12:39 AM, Grigory Javadyan wrote:

–
john skaller
@john_skaller

20

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 :)On 12/04/2011, at 1:22 AM, Gordiychuck Oleg wrote:

–
john skaller
@john_skaller