Question about using arrays of SDL_Surface

I realize that the response to this may be, “Go check out your C++ textbook”. However I am completely stumped.

This, of course, compiles as we all know from our textbooks:

int* foo=NULL;
foo=new int[2];
foo[0]=NULL;

But this causes the compiler to complain about no operator that takes a right hand type of int:

SDL_Surface* fooS;
fooS=new SDL_Surface[2];
fooS[0]=NULL;

And this will compile just fine:

SDL_Surface* fooT;
fooT=NULL;

I want a dynamic array of SDL_Surfaces, but while debugging I have got to know whether or not they have been initialized. They are all loaded with crap as they are uninitialized pointers, right? I don’t know the size of the array I need until runtime, so I have to use new to create the array. :frowning:

2009/12/31 rattyboy <dennis.comeaux at gmail.com>:

I realize that the response to this may be, “Go check out your C++
textbook”. However I am completely stumped.

This, of course, compiles as we all know from our textbooks:

int* foo=NULL;
foo=new int[2];
foo[0]=NULL;

yes, but…
foo[0] is an int, not a pointer to int, so it should be

int* foo=NULL;
foo=new int[2];
foo[0]=0;

Also, recommended practice in C++ (since you’re using new) is to use
0, not NULL, for pointers as well.

But this causes the compiler to complain about no operator that takes a
right hand type of int:

SDL_Surface* fooS;
fooS=new SDL_Surface[2];
fooS[0]=NULL;

fooS is an array pointers to stuctures, not an array of structures.

try this:
SDL_Surface* fooS;
fooS=new SDL_Surface*[2];
fooS[0]=NULL;> And this will compile just fine:

SDL_Surface* fooT;
fooT=NULL;

I want a dynamic array of SDL_Surfaces, but while debugging I have got to
know whether or not they have been initialized. They are all loaded with
crap as they are uninitialized pointers, right? I don’t know the size of the
array I need until runtime, so I have to use new to create the array. :frowning:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

rattyboy wrote:

I want a dynamic array of SDL_Surfaces, but while debugging I have got
to know whether or not they have been initialized. They are all loaded
with crap as they are uninitialized pointers, right? I don’t know the
size of the array I need until runtime, so I have to use new to create
the array. :frowning:

Is a std::vector<SDL_Surface*> not suitable for the task?

CE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREKAAYFAktCea8ACgkQwCnbyd7dCqT7UQCfa9I9yjby6yIAN9sVJBG6F9ZV
Mh8AmQEx1IdPMLNX1sQ40DtmwdlfKW93
=AwB+
-----END PGP SIGNATURE-----

Sure, as already answered, what you’re doing is building up
an array of SDL_Surface, and you’re trying to set NULL to
an SDL_Surface, which doesn’t make sense since SDL_Surface
is not an integer but an aggregate type (struct). That’s why the
C++ compiler is expecting for a special operator from int to SDL_Surface.
What you want is to have an array of SDL_Surface* (addresses).
Also, the way you did it, you’d never be able to initialize the surface
properly except by hand …

What you need to do is:######

SDL_Surface** surfaces;
// Or, if you know the size at compile time: SDL_Surface* surface[size];
// Then, initialize each pointer to NULL or directly allocate memory,
// depending on what you want to do.

// If you don’t know the size at compile time, say ‘size’ is a parameter:
surfaces = new SDL_Surface*[size]; // That’s it, initialize an array of ‘size’ pointers

for (int k = 0; k < size; k++) {
surface[k] = NULL; // Ok here, surface[k] is the kth pointer, not an SDL_Surface
// You may also want to do something like:
// surface[k] = SDL_CreateRGBSurface ( /* set your parameters */ );
}

// Of course, somewhere later in the code, you’ll need to free the memory …
for (int k = 0; k < size; k++) {
SDL_FreeSurface(surfaces[k]);
surfaces[k] = NULL;
}
// And finally, free the array of pointers if allocated dynamically
delete surfaces;

Be really careful with what a pointer is and with the notations. Take time to write your code
and understand exactly what’s happening in memory, do charts if necessary.

Regards,

Julien CLEMENT

<<<
I realize that the response to this may be, “Go check out your C++ textbook”. However I am completely stumped.

This, of course, compiles as we all know from our textbooks:

int* foo=NULL;
foo=new int[2];
foo[0]=NULL;

But this causes the compiler to complain about no operator that takes a right hand type of int:

SDL_Surface* fooS;
fooS=new SDL_Surface[2];
fooS[0]=NULL;

And this will compile just fine:

SDL_Surface* fooT;
fooT=NULL;

I want a dynamic array of SDL_Surfaces, but while debugging I have got to know whether or not they have been initialized. They are all loaded with crap as they are uninitialized pointers, right? I don’t know the size of the array I need until runtime, so I have to use new to create the array. :frowning:

Seconded. A standard container is almost always preferable to trying
to manage this manually.On Mon, Jan 4, 2010 at 11:28 PM, Chris Eineke wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

rattyboy wrote:

I want a dynamic array of SDL_Surfaces, but while debugging I have got
to know whether or not they have been initialized. They are all loaded
with crap as they are uninitialized pointers, right? I don’t know the
size of the array I need until runtime, so I have to use new to create
the array. :frowning:

Is a std::vector<SDL_Surface*> not suitable for the task?

It depends, it can decrease performances if not used
accordingly… A list or a set may be the appropriate
choice in some cases, and arrays in some others.

Julien

<<
Seconded. A standard container is almost always preferable to trying
to manage this manually.>>

You could say that about pretty much anything. For a simple dynamic
container with no severe runtime or memory conditions or unusual
access patterns (i.e. a “bag” of objects) std::vector<> is almost
always the best choice.On Tue, Jan 5, 2010 at 7:20 PM, julien CLEMENT wrote:

It depends, it can decrease performances if not used
accordingly… A list or a set may be the appropriate
choice in some cases, and arrays in some others.

Julien

No, the suitable choice would be std::vector<SDL_Surface>.

Using STL containers to store pointers is somewhat missing the point
of using STL containers in the first place.

Also, properly written C++ code should never contain raw pointers anyway.On Mon, Jan 4, 2010 at 18:28, Chris Eineke wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

rattyboy wrote:

I want a dynamic array of SDL_Surfaces, but while debugging I have got
to know whether or not they have been initialized. They are all loaded
with crap as they are uninitialized pointers, right? I don’t know the
size of the array I need until runtime, so I have to use new to create
the array. :frowning:

Is a std::vector<SDL_Surface*> not suitable for the task?

CE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREKAAYFAktCea8ACgkQwCnbyd7dCqT7UQCfa9I9yjby6yIAN9sVJBG6F9ZV
Mh8AmQEx1IdPMLNX1sQ40DtmwdlfKW93
=AwB+
-----END PGP SIGNATURE-----


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

  • SR

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Simon Roby wrote:

No, the suitable choice would be std::vector<SDL_Surface>.

I suggested std::vector<SDL_Surface*> to illustrate the point that there are
better data structure choices than a manually-managed array. This being C++ and all.

Also, I don’t agree with your statement. The SDL API manages the allocation and
deallocation of SDL_SurfaceS. If you check the SDL_FreeSurface function
(SDL_Surface.c), you will see that it indeed frees the memory associated with
the SDL_Surface struct. Your suggestion implies that you’re the owner of the
object, which you aren’t.

Your solution would most likely leak memory (dereferencing a raw pointer to an
SDL_Surface struct returned from one of the creator functions and storing a copy
of the struct in the vector without managing the original raw pointer) and free
memory when it shouldn’t (e.g. let v be a std::vector<SDL_Surface> containing
some surfaces starting at index zero. What are the repercussions of
SDL_FreeSurface(&v[0]) ?).

CE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREKAAYFAktEGQ8ACgkQwCnbyd7dCqTGXwCfV+1YRCRHNiOYArjZByPWc1t2
cO0AoKfwIxHEKDgUXGvnDcEBlD2hFqz7
=T1Zb
-----END PGP SIGNATURE-----

Hmm, you’re right, and to further add to my error I would also mention
that SDL_Surface contains fields managed by SDL, and therefore copying
the struct to a container would probably mess up the internal SDL
state.

Nevertheless I still maintain my claim that putting raw pointers in an
STL container is not a good practice and should be avoided whenever
possible. In this case there are multiple ways around this, but the
more obvious and logical one would be to wrap the SDL_Surface pointer
around a reference-counting class that would call SDL_FreeSurface() on
destruction. It’s bothersome, but since SDL is a plain C API it’s
unavoidable that you have to do a little extra work to write proper
C++ code. (Of course you could also save yourself some trouble and use
one of the many C++ wrappers out there, but that wouldn’t be any fun
now wouldn’t it?)On Wed, Jan 6, 2010 at 00:01, Chris Eineke wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Simon Roby wrote:

No, the suitable choice would be std::vector<SDL_Surface>.

I suggested std::vector<SDL_Surface*> to illustrate the point that there are
better data structure choices than a manually-managed array. This being C++ and all.

Also, I don’t agree with your statement. The SDL API manages the allocation and
deallocation of SDL_SurfaceS. If you check the SDL_FreeSurface function
(SDL_Surface.c), you will see that it indeed frees the memory associated with
the SDL_Surface struct. Your suggestion implies that you’re the owner of the
object, which you aren’t.

Your solution would most likely leak memory (dereferencing a raw pointer to an
SDL_Surface struct returned from one of the creator functions and storing a copy
of the struct in the vector without managing the original raw pointer) and free
memory when it shouldn’t (e.g. let v be a std::vector<SDL_Surface> containing
some surfaces starting at index zero. What are the repercussions of
SDL_FreeSurface(&v[0]) ?).

CE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREKAAYFAktEGQ8ACgkQwCnbyd7dCqTGXwCfV+1YRCRHNiOYArjZByPWc1t2
cO0AoKfwIxHEKDgUXGvnDcEBlD2hFqz7
=T1Zb
-----END PGP SIGNATURE-----


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

  • SR

Baby steps. First, introduce them to the standard containers. Then get
them hooked on boost::shared_ptr<>. Unless you want to depend on
std::tr1::shared_ptr<>. Then they are yours =)

The nice thing about shared_ptr<> is that it allows for a custom
delete function, so you can rig it to work with SDL_FreeSurface very
easily. That or write a RAII wrapper around the SDL surface, and store
shared_ptrs to these wrappers.

That or use a pre-wrapped version, yes.

2010/1/6 Simon Roby <simon.roby at gmail.com>:> Hmm, you’re right, and to further add to my error I would also mention

that SDL_Surface contains fields managed by SDL, and therefore copying
the struct to a container would probably mess up the internal SDL
state.

Nevertheless I still maintain my claim that putting raw pointers in an
STL container is not a good practice and should be avoided whenever
possible. In this case there are multiple ways around this, but the
more obvious and logical one would be to wrap the SDL_Surface pointer
around a reference-counting class that would call SDL_FreeSurface() on
destruction. It’s bothersome, but since SDL is a plain C API it’s
unavoidable that you have to do a little extra work to write proper
C++ code. (Of course you could also save yourself some trouble and use
one of the many C++ wrappers out there, but that wouldn’t be any fun
now wouldn’t it?)

No, the suitable choice would be std::vector<SDL_Surface>.

Using STL containers to store pointers is somewhat missing the point
of using STL containers in the first place.

Nope, sorry. The SDL API is designed around the idea that functions
that create SDL_Surfaces return pointers to them and the function the
frees them takes a pointer. In an SDL program you almost never have
access to a variable declared as

SDL_Surface x;

they are almost always of the form:

SDL_Surface *x;

That means that using a std::vector<SDL_Surface> would require a lot
of structure copying and make it very difficult to ever properly clean
up dynamically allocated surfaces. The lesson here is that C structs
are not C++ structs or classes. When using a C API from C++ you have
to apply C coding idioms and rules. In this case
std::vector<SDL_surface *> is a reasonable choice.

Of course, you would only use a vector for small numbers of items
because the insertion/deletion times are O(n). I’d use a queue or a
priority queue.

Also, properly written C++ code should never contain raw pointers anyway.

Ok, entering pedantic mode, beware…

As someone who has made their living teaching C++ in the past and who
hopes to do the same thing in the future I’m rather attuned to this
kind of statement. It is usually the result of a student hearing
something like, “you should avoid pointers when you can” and
internalizing it as “Thou Shalt Not Use Pointers!” and never thinking
about it again.

Striking yourself with a stick across the back whenever you notice
your self expressing beliefs about programming like that is a good way
to break that habit. (A yard stick or a meter stick works well. Zen
monks also have a special stick for just this purpose.) OTOH, simply
slapping your self and yelling “Doh!” works pretty well and doesn’t
hurt as much. :slight_smile:

OK, bad joke…

But seriously, whenever you find your self expressing an opinion like
that please stop and think about why you hold that opinion and whether
it applies in this situation. Avoiding pointers is a good rule of
thumb, but like all such rules following them blindly is a good way to
get your thumb cut off. I saw a guy cut his thumb of once, not a nice
thing to see, much less fun to experience.

Ask me some day about how many years it took me to realize that “Thou
Shalt Not Goto!” really meant, don’t write spaghetti code and the
difference between spaghetti code and the reasoned and proper use of
gotos in languages without reasonable control and error handling
structures. And for good measure maybe you’ll get a good laugh out of
how we faked structs in Fortran IV and 66 :slight_smile:

Seriously, unreasoned belief is the death of the programming mind. The
trouble is learning to notice when you believe something rather than
understanding it.

Bob PendletonOn Tue, Jan 5, 2010 at 6:12 PM, Simon Roby <simon.roby at gmail.com> wrote:

On Mon, Jan 4, 2010 at 18:28, Chris Eineke wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

rattyboy wrote:

I want a dynamic array of SDL_Surfaces, but while debugging I have got
to know whether or not they have been initialized. They are all loaded
with crap as they are uninitialized pointers, right? I don’t know the
size of the array I need until runtime, so I have to use new to create
the array. :frowning:

Is a std::vector<SDL_Surface*> not suitable for the task?

CE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREKAAYFAktCea8ACgkQwCnbyd7dCqT7UQCfa9I9yjby6yIAN9sVJBG6F9ZV
Mh8AmQEx1IdPMLNX1sQ40DtmwdlfKW93
=AwB+
-----END PGP SIGNATURE-----


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

  • SR

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


±----------------------------------------------------------

No, the suitable choice would be std::vector<SDL_Surface>.

Using STL containers to store pointers is somewhat missing the point
of using STL containers in the first place.

Nope, sorry. The SDL API is designed around the idea that functions
that create SDL_Surfaces return pointers to them and the function the
frees them takes a pointer. In an SDL program you almost never have
access to a variable declared as

SDL_Surface x;

they are almost always of the form:

SDL_Surface *x;

That means that using a std::vector<SDL_Surface> would require a lot
of structure copying and make it very difficult to ever properly clean
up dynamically allocated surfaces. The lesson here is that C structs
are not C++ structs or classes. When using a C API from C++ you have
to apply C coding idioms and rules. In this case
std::vector<SDL_surface *> is a reasonable choice.

No, check my previous post. Chris had already pointed out that
std::vector<SDL_Surface> would be wrong and I acknoledged it, but I
still maintain that a container of pointers is not a good practice.

The trick here is to consider SDL_Surface pointers as resources. They
are not managed directly by the application and must therefore be
surrounded by resource handling facilities, such as smart pointers or
the like. By doing std::vector<SDL_Surface *> you are leaving out the
management of that resource to whoever is using the vector, which
somewhat breaks RIIA. Bjarne talks about the notion of a generic
resource handle that maintains strict RIIA on externally-managed data
in his Style and Technique FAQ:
http://www2.research.att.com/~bs/bs_faq2.html#memory-leaks

Of course, you would only use a vector for small numbers of items
because the insertion/deletion times are O(n). I’d use a queue or a
priority queue.

Agreed. I was following up on Chris initial suggestion and didn’t take
the time to suggest a better container.

Also, properly written C++ code should never contain raw pointers anyway.

Ok, entering pedantic mode, beware…

As someone who has made their living teaching C++ in the past and who
hopes to do the same thing in the future I’m rather attuned to this
kind of statement. It is usually the result of a student hearing
something like, “you should avoid pointers when you can” and
internalizing it as “Thou Shalt Not Use Pointers!” and never thinking
about it again.

Well, I never said that pointers should never be used, only that
proper modern C++ code shouldnt have any, but that is an hypothetical
notion at best because there is no such thing as 100% proper code. But
when you do have pointers, they should be carefully isolated by the
appropriate facilities (directly storing them in an STL container is
not).

I do understand your dislike of my statement though, because I also
believe that novice programmers usually mix up “what is not a good
practice” with “what is forbidden”, which causes very harmful results.

Striking yourself with a stick across the back whenever you notice
your self expressing beliefs about programming like that is a good way
to break that habit. ?(A yard stick or a meter stick works well. Zen
monks also have a special stick for just this purpose.) OTOH, simply
slapping your self and yelling “Doh!” works pretty well and doesn’t
hurt as much. :slight_smile:

OK, bad joke…

But seriously, whenever you find your self expressing an opinion like
that please stop and think about why you hold that opinion and whether
it applies in this situation. Avoiding pointers is a good rule of
thumb, but like all such rules following them blindly is a good way to
get your thumb cut off. I saw a guy cut his thumb of once, not a nice
thing to see, much less fun to experience.

Point taken. For a moment I took my own advice too litterally, and
responded too soon with incorrect information because I missed an
important detail which screwed up what I was trying to explain.
Thankfully I was corrected fast, and didn’t lose any thumbs, lol.

Ask me some day about how many years it took me to realize that “Thou
Shalt Not Goto!” really meant, don’t write spaghetti code and the
difference between spaghetti code and the reasoned and proper use of
gotos in languages without reasonable control and error handling
structures. And for good measure maybe you’ll get a good laugh out of
how we faked structs in Fortran IV and 66 :slight_smile:

Yeah, I hate when people claim that goto is a forbidden evil, as it
can serve as a very useful poor man’s exception handling in languages
that lack proper exceptions. I have yet to find a relevant use for
goto in a language that does have exceptions, though.

Seriously, unreasoned belief is the death of the programming mind. The
trouble is learning to notice when you believe something rather than
understanding it.

Again, I fully agree.On Wed, Jan 6, 2010 at 09:32, Bob Pendleton wrote:

On Tue, Jan 5, 2010 at 6:12 PM, Simon Roby <@Simon_Roby> wrote:

  • SR

@Simon: Off-topic, but I recently decided to use ‘goto’ whenever I need a
multilevel break (until g++ implements C++0x, I guess) instead of the
messier bool-handling.

Jonny DOn Wed, Jan 6, 2010 at 11:15 AM, Simon Roby <simon.roby at gmail.com> wrote:

Yeah, I hate when people claim that goto is a forbidden evil, as it
can serve as a very useful poor man’s exception handling in languages
that lack proper exceptions. I have yet to find a relevant use for
goto in a language that does have exceptions, though.

Simon Roby wrote:

The trick here is to consider SDL_Surface pointers as resources. They
are not managed directly by the application and must therefore be
surrounded by resource handling facilities, such as smart pointers or
the like. By doing std::vector<SDL_Surface *> you are leaving out the
management of that resource to whoever is using the vector, which
somewhat breaks RIIA.

<unscrupulous_ad>
SDL++ uses tr1::shared_ptrS for SDL resources as necessary.
<unscrupulous_ad>

I think I need to release the next version of SDL++ soon. Also, is anybody
interested in working on SDL2++ with me? I could need some help. :slight_smile:

CE

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

I think it’s just a matter of words here. For the guy who asked
the question in the first place, it can be quite confusing to read this.
Again, we may all agree but I don’t like the “good practice” or
"bad practice" approach because it highly depends on the knowledge
and experience of each other.

That’s also the reason why I posted a little bunch of code with a plain
old school array of pointers, which led to a debate on stl containers
just because he said he was doing C++ programming …

Guys, again, this is a very general remark and brings nothing more
to the debate, but each tool is made for a particular purpose,
and in some cases stl containers are better, even with pointers in it,
and in other cases arrays are the best (at least, you know what’s going
on for you have to do everything by yourself).

I dont’ see it as a bad practice at all. If you read the stl documentation
(what you should do in the first place …), you will know what’s happening
when a container gets destroyed and then you’ll know that a leak could
occur if you’re not careful. Else, either the guy was too in a hurry and should
avoid computer programming, or he should learn C/C++ first.

Then, where is the bad practice here, stl are templates, so they
allow for putting what one wants inside, and nobody said that pointers
should be avoided. B.Stroustrup is not the god of programming, btw.
The real problem here is not good practices or STL or whatever, it’s more
how the C++ language itself is built. It pretends beeing object while still
beeing unclear and allowing everything to happen, which is both practical and
a problem. If one really wants a clear language, with a smart memory management
policy, one could try Objective C instead. This is the language behing OpenStep and
more recently Mac OS X::Cocoa.

So, Simon, it’s not a personal attack. I’m rather making a remark on the words
you used. Instead of talking about what’s “good” or “bad” better showing
the advantages and drawbacks of the technics, which allows the reader to
make its own judgement based on his degree of understanding. Good and bad
is a way to cut off good reflexion and constructive debate, IMHO. Like what has been
said, we could list a lot of useful tools/technics which are considered as bad practice
like mutual referencement (through pointers), gotos (try writing a parser in plain C without
gotos, what a pain), etc.

Btw I personally use stl containers of pointers and I really appreciate to
have the power of those containers, and clearly understand what’s happening
with them, so — no danger in using std::vector<SDL_Surface*> —

Off-Topic, can someone point me to a good book on the architecture of modern
computer graphics ? (not opengl red book/orange book, but something really
oriented architecture, memory, etc.)

Regards,

Julien CLEMENT.

<<<
No, check my previous post. Chris had already pointed out thatstd::vector<SDL_Surface> would be wrong and I acknoledged it, but I
still maintain that a container of pointers is not a good practice.>>>

Simon Roby wrote:

In this case there are multiple ways around this, but the
more obvious and logical one would be to wrap the SDL_Surface pointer
around a reference-counting class that would call SDL_FreeSurface() on
destruction.

I did just that in one of my projects. After the trial and error and
headache of using a non ref-counting smart pointer type class with an
SDL_Surface*.

On that note, I wrote my own class, but later on learned about
shared_ptr. Has anyone tried tr1::shared_ptr (or likewise
boost::shared_ptr) with an SDL_Surface pointer? It allows the
association of a “deleter” function, which I would guess you could use
SDL_FreeSurface.–
Anthony T.
Only two things are infinite, the universe and human stupidity, and I’m not sure about the former. – Albert Einstein

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

Everyone wanted to post about bad practice, no one gave an example to
the OP how to use the vector in what he wanted:

std::vector<SDL_Surface*> fooS(2, static_cast<SDL_Surface *>(0));

You could maybe get away with leaving out the static_cast<SDL_Surface
*>(0) and just use 0. I just try to be safe.

Now you’ve got a vector of 2 surfaces, all initialized to 0. std::vector
behaves like an array, so:

if (0 == fooS[1])
fooS[1] = SDL_CreateSurface(…);–
Anthony T.
Only two things are infinite, the universe and human stupidity, and I’m not sure about the former. – Albert Einstein

Anthony T. wrote:

On that note, I wrote my own class, but later on learned about
shared_ptr. Has anyone tried tr1::shared_ptr (or likewise
boost::shared_ptr) with an SDL_Surface pointer? It allows the
association of a “deleter” function, which I would guess you could use
SDL_FreeSurface.
Nevermind, I just saw Chris Eineke’s buried post :-)–
Anthony T.
1990 Trans Am LB9 4L60
Only two things are infinite, the universe and human stupidity, and I’m not sure about the former. – Albert Einstein