Creating std::vector of sf::Image/Sound

[Laurent]

Laurent -> I already gave you an example of that, and if you look at the last paragraph in Nexus' post, you can find even more reasons. You, however, have not stated one single reason why an olden timey array would be better for anything. :shock:
Luckily, Nexus was kind enough to do so, so don't worry about it.

Sorry, I didn't mean to be unsympathetic.
I gave you that answer on purpose, I wanted to reach the same conclusion as Nexus that there's nothing in std::vector that you need for static arrays, and that all this "cool extra stuff" that you get is in fact unnecessary overhead. The best solution is to use something that adds stuff on top of static arrays, like boost::array or std::tr1::array, not to use dynamic arrays.

Sometimes I answer to people with dumb questions to make them think and then show them why they're wrong, rather than writing the big, thorough comprehensible explanation (english is not my mother tongue and it takes me more time to write long answers -- it took me 30 min to write this one :lol:).

[model76]

That's OK, you are forgiven But I really had already thought about it..

I understand about the language barrier, as English isn't native to me, either. In fact, http://www.tfd.com/ is probably in the top 5 of my most visited sites, even tough I consider myself to be pretty good at English...


To get back on topic, I still feel that a vector is a good choice, in most cases, even if you don't necessarily need a dynamic array (still assuming that we stick to standard C++).
The only cases I can think of, where it would not make sense, is if

1) You just need it to hold data, that you don't ever intend on accessing, after initialization (or maybe if you plan to access it with an enum).

Or 2) The extra overhead of the vector gets in the way of the workings of your program (you need the array for optimization).

If you ever need to simply loop through the array, or pass it to a function, the size method, safety, and nice STL interface should be worth the extra bit of overhead, or what?
And if you know the size at compile time, then it is really easy to tell the vector to preallocate the memory it will need, so that should take care of at least some of the overhead.

So maybe I am wrong. Maybe my cost/benefit analysis is off, due to lack of experience, but I still haven't heard a good argument for not using vector by default, except for a few special cases.
So if there truly is one, I will be most happy to hear it, since I am always interested in correcting bad habits.

[Nexus]

If you ever need to simply loop through the array, or pass it to a function, the size method, safety, and nice STL interface should be worth the extra bit of overhead, or what?

What if all of the mentioned features would come without any overhead? I.e. take all the advantages and pay nothing? Sound like a good deal, doesn't it?

That's exactly where std::tr1::array comes into play. You should have a look at it (or at boost::array, which is actually the same). Of course, raw arrays can't be directly compared to std::vector, even though they support iterators.

[model76]

Sure, that would be very nice, but tr1 is not standard, and boost is a huge, complicated external library. In my opinion, that is, quite frankly, not very good advice for someone who is just getting ready to get their feet wet with STL containers, and maybe feeling a bit anxious about it.
That is how I read the opening post.

ahem, I realize now that this might not have been aimed at the original poster, but directly at me, in which case you are right. It is about time I finally take another crack at unlocking the mystery that is boost.
But as it happens, someone once suggested boost to me, when I was clearly not ready. That lead to many hours of frustration and reading of technical manuals, that I had zero chance of understanding. So I have been somewhat reluctant to go back on that path, you see.

I will look into it as soon as my current project is done. Thank you for reminding me!

[Nexus]

but tr1 is not standard

But it's an official extension to C++98 that has already existed seven years. All modern standard library implementations support TR1.

It is about time I finally take another crack at unlocking the mystery that is boost.

Yes, Boost is a great library and offers very interesting concepts. Even though I don't like all implementations (some of them tend to be overengineered), many libraries make daily work a lot easier (for example Bind, SmartPtr or PointerContainer).

[model76]

But it's an official extension to C++98 that has existed already seven years. All modern standard library implementations support TR1.

Really? I had no idea! I thought it was just a kind of preview of what the next installment of C++ has to offer, that compiler vendors could implement at their own leisure. That's a whole new set of toys to play with, so thanks for pointing that out!

[Nexus]

No problem.

If you use Microsoft Visual Studio, you can include std::tr1::array from <array>, G++ uses <tr1/array>. I don't know about other compilers...

By the way, Bind and Function are also in TR1, as well as Unordered Map/Set or Random Number Generators. I especially like std::tr1::bind and std::tr1::function.

[Laurent]

If all you need is begin(), end() and size(), then they can easily be implemented from scratch for static arrays

Code: [Select]

template <typename T, std::size_t N>
std::size_t size(T(&)[N])
{
    return N;
}

template <typename T, std::size_t N>
T* begin(T(&array)[N])
{
    return &array[0];
}

template <typename T, std::size_t N>
T* end(T(&array)[N])
{
    return begin(array) + N;
}

You can even write your own minimal version of tr1/boost array, it's just a matter of minutes.

[Nexus]

You can even write your own minimal version of tr1/boost array, it's just a matter of minutes.

That's true, but it's nothing compared to a fully tested and optimized container class (ok, the case here is not too complex since tr1::array is a rather thin wrapper, but anyway). What I really like at the MSVC++ implementation are the debug assertions and checked iterators. Such features depend on one's needs, I'm glad I don't have to abandon them...

[Laurent]

I know, I was just trying to provide an alternative that would still be better than std::vector, for those who want a standard/portable solution without using boost

[asdatapel]

Absolutely. The only thing that you must keep in mind is that some operations (such as adding an element) may move all the vector elements elsewhere in memory, invalidating all the sprites that previously pointed to them.

Okay, so I have an object that has a Image member and a Sprite member.
I create one of those objects, change a few options, and push it into a an vector, change a few options, push it into a vector, repeating until I have enough.The sprites that I draw all turn white. Is it because of what you're talking about?, and if so, how do I fix it?

[Nexus]

Please don't revive old threads.

You must be sure that the sprite's pointer refer to valid images. So call SetImage() at last, or use containers like boost::ptr_vector or std::list that don't invalidate their element references.