Jump to content
  • Advertisement
Sign in to follow this  
littlekid

Is STL or array?

This topic is 4833 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Should i use STL::vector<> or an array to store datas. if i use an array everytime i add data, i use the realloc function. vector would be easy as i just need to use the vector.pushback(). However is it faster to retreive data from a array or will the speed be about the same? The data that i need to store is the vertex of the scene. Hence data will be constanly updated/added and reterive to the renderer to render a scene.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by littlekid
However is it faster to retreive data from a array or will the speed be about the same?

Access speed is about the same. And since vectors use a more clever reallocation strategy than you do, insertion will be faster.

Use vectors. Arrays are evil.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Access speed is about the same.

Actually if you use array access syntax (operator[]) the access speed is exactly the same. If you use 'at()' then you pay for overrun checks.

Share this post


Link to post
Share on other sites
Quote:
Original post by littlekid
Should i use STL::vector<> or an array to store datas.

if i use an array everytime i add data, i use the realloc function. vector would be easy as i just need to use the vector.pushback().

However is it faster to retreive data from a array or will the speed be about the same?

The data that i need to store is the vertex of the scene. Hence data will be constanly updated/added and reterive to the renderer to render a scene.


Doing what std::vector does manually (ala C-style arrays in C++) you have no hope what so ever to achieve better & safer or even equivalent on modern C++ compilers, you have proven that by asking such a question.

If you know in advance how many or roughly how many elements you will be adding then use std::vector::reserve (not std::vector::resize) then use std::vector::push_back, std::vector::reserve will allocate a chunk of uninitialized memory all ready to go and suppresses the automatic growing strategy until the capacity becomes full (not size, capacity != size).

If you do not know in advance roughly how many elements you will be adding and elements stored in memory contiguously is insignificant then i suggest trying out std::deque instead as it is more efficient at growing than std::vector as it does not suffer from internal copying that std::vector does when the capacity becomes full then grows.

Also note that all standard library containers are parameterized by allocator type, typically it is the last template type parameter and defaults to use std::allocator. This means you can write/use custom allocator types with it, for example boost libraries provides 2 custom allocator types both of which are pooled allocators, you can get some wonderful preformance with std::deque and boost::fast_pooled_allocator if you don't care for contiguousness but want random access.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!