Question about using arrays of SDL_Surface

SDL Development
21

I think that the main issue are not the pointers themselves but the that
when using pointers you might easily loose track of who owns the pointer.

On my job nowadays I use mostly higher level languages, or what is called
modern C++, and I am surely glad never to worry about dangling pointers
anymore.

On my area you have to deal with huge projects with several teams scattered
around the globe, and it was always a very stressful situation to
fix pointer related issues, with Customer pressure wanting a fix for
yesterday, while trying to find which module was to blame for the problem.–
Paulo

On Thu, Jan 7, 2010 at 2:15 PM, Anthony T. <goumba_tony at yahoo.com> wrote:

julien CLEMENT wrote:

So one should avoid stl containers just
because it’s not a good practice to put pointers inside them ?

By all means I’m an intermediate programmer at best, however I’ve never
quite understood this logic myself.

I fail to see the difference between a container of pointers and an array
of pointers.

Yes, if you fail to delete the pointers yourself, there will be a memory
leak.

C style arrays do not clean up after themselves. Fail to delete the
pointers, and again, you will have a memory leak.

So, this “good practice” to me is nothing but nonsense.

However, I am an intermediate programmer at best, and just adding my $0.02.
Far better programmers than me would agree its bad practice.

–
Anthony T.

Only two things are infinite, the universe and human stupidity, and I’m not
sure about the former. – Albert Einstein

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

22

I’ve written several parsers in C and never used a goto. While I’ll grant
that, in theory, there may be instances in which a goto is more efficient,
or clearer, or “better” in some way, I’ve yet to see a valid example.

JeffOn Thursday 07 January 2010 01:49, julien CLEMENT wrote:

(try writing a parser in plain C without gotos, what a
pain)

23

In this context, remember the question asker specified that the size
of the array wasn’t known until runtime. This leaves two options,
choosing some large, arbitrary size and hoping you never need more
elements than this, or dynamic allocation.

The container will manage the dynamic allocation, so which you need to
be careful to free the surfaces, the array itself is managed for you.
This is contrast to having to remember to call delete [] on the array.

In practise, we rarely allocate some fixed (but unknown) number of
elements up front. More often you need to be able to dynamically add
and remove elements during the life of the program. std::vector<> and
other containers fit this model better.

Finally, some compiler implementations will include range checking in
Debug builds, which will help verify that your program is correct.

2010/1/7 Anthony T. <goumba_tony at yahoo.com>:> julien CLEMENT wrote:

I fail to see the difference between a container of pointers and an array of
pointers.

24

I think you misunderstood my statement.

Another poster had taken issue against a container of pointers. As far
as I’m concerned in both cases, each pointer must be freed individually
using either an array or container, making them equal in this respect.
delete[] will only free an array created on the heap to objects/types,
such as “new char[15]” - not manage an array of pointers. “*char[15]” will still require you to free the 15 pointers individually.

If you look at my answer to the OP, I’m pro container, you needn’t
point out the advantage to me as far as dynamic allocation and such. :slight_smile:

– Anthony T.On Thu, Jan 07, 2010 at 02:26:37PM +0000, Brian Barrett wrote:

In this context, remember the question asker specified that the size
of the array wasn’t known until runtime. This leaves two options,
choosing some large, arbitrary size and hoping you never need more
elements than this, or dynamic allocation.

The container will manage the dynamic allocation, so which you need to
be careful to free the surfaces, the array itself is managed for you.
This is contrast to having to remember to call delete [] on the array.

In practise, we rarely allocate some fixed (but unknown) number of
elements up front. More often you need to be able to dynamically add
and remove elements during the life of the program. std::vector<> and
other containers fit this model better.

Finally, some compiler implementations will include range checking in
Debug builds, which will help verify that your program is correct.

2010/1/7 Anthony T. <@Anthony_Thomasel>:

julien CLEMENT wrote:

I fail to see the difference between a container of pointers and an array of
pointers.

25

Wow… Original poster here.

I am SOOO sorry I forgot about this thread. I miss the days of using Fort? Agent version 0.99 and just subscribing to threads. With the “new fangled” ADD method of communication that the ?net has come to be, I find forums where people post, “I will be right back, I have to go get something from the fridge,” to be a yawn fest.

But… We have web based forums now. No real way around that. And email is so spammed that its a pointless way to get new messages without coding your own organization tool.

So, that’s how I forgot (in 100 words). My apologies.

I ended up using a pointer to a pointer to solve my problems. In the meantime I have found some strange behavior in my compiler (Visual C++ 8 from Micro$oft). I am definitively NOT an expert programmer. I also have never made a living programming (which some say is a blessing). I have ALWAYS wanted to make a living programming but well, the card haven?t been there for me. So, as mentioned earlier, I code for fun.

I found this discussion to be fascinating. Especially something that Bob said. He mentioned that you should catch yourself when you internalize “using X is not a good idea” to mean “avoid X like the plague”. I remember when I took a pascal class in college. Wow! I graduated from BASIC. And I learned that goto was BAD. And years have passed and I still hesitate to use it. But I have never, until reading this thread, questioned WHY I never used it. It was bad advice to say, “Never use X” to a student.

I have been training a guy at work to get him ramped up to where he can be a good assistant sysadmin (linux / AIX dominated network). I have been careful to never say never. Example: do you use bash or perl to script something? Or do you just use the record function (?q?) in vim to accomplish your task? Instead, I tell him, “Use what you think will be easiest.” Sometimes I use PERL, sometimes BASH, sometimes ksh. It just depends on my mood and what I need to accomplish. Complicated multi-field file? PERL. Small, easy text manipulation of hundreds of lines? Maybe cat and awk.

Many thanks to all of you more experienced coders. And I absolutely loved seeing the different opinions about how to accomplish the array I was after. I am always fascinated at the way things can be done many different ways and when in my opinion, none are 100% correct.

26

I have yet to find a relevant use for
goto in a language that does have exceptions, though.

Exceptions are heavyweight. I find it hard to argue against goto’s for a
failure case inside a function.

Also if the exceptions don’t support some kind of final clause.

Cheers,
Dustin

27

On the contrary, exceptions are a very elegant solution to failure cases. If
you use a goto to take care of a failure case, then you have to return a result
indicating an error, and you place the burden of analyzing the result and
handling the possible error on the calling function. And if it can’t, then it
needs to return an error code… and so on. Well-implemented exception handling
moves all of this work to the compiler.

Simply because C++'s implementation of exceptions is a horrible mess doesn’t
mean the concept in general isn’t a good one.________________________________
From: dustin@mize.org (Dustin Dettmer)
Subject: Re: [SDL] Question about using arrays of SDL_Surface

I have yet to find a relevant use for

goto in a language that does have exceptions, though.

Exceptions are heavyweight. I find it hard to argue against goto’s for a
failure case inside a function.

Also if the exceptions don’t support some kind of final clause.

Cheers,
Dustin

28

On the contrary, exceptions are a very elegant solution to failure cases. If
you use a goto to take care of a failure case, then you have to return a result
indicating an error, and you place the burden of analyzing the result and
handling the possible error on the calling function. And if it can’t, then it
needs to return an error code… and so on. Well-implemented exception handling
moves all of this work to the compiler.

longjmp() ? :slight_smile:

ZoltanOn Thu, 21 Oct 2010, Mason Wheeler wrote:

29

zoltan wrote:> On Thu, 21 Oct 2010, Mason Wheeler wrote:

On the contrary, exceptions are a very elegant solution to failure cases. If
you use a goto to take care of a failure case, then you have to return a result
indicating an error, and you place the burden of analyzing the result and
handling the possible error on the calling function. And if it can’t, then it
needs to return an error code… and so on. Well-implemented exception handling
moves all of this work to the compiler.

longjmp() ? :slight_smile:

Zoltan

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

Not much different from using goto. It still provides all the minor burdens described above. I personally feel that the minor burdens do not outweigh the inherent inefficiency of having to wrap every function call (or collection of function calls) that may throw an exception with a try { } catch.
I personally think SDL’s method of storing a global string is a very good way to handle the matter, and even better would be if all SDL functions that may set an error returned an SDL_RetError constant on failure.

EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/