Checking an sf::image vector

[lesshardtofind]

Hey!

   I am writing a texture manager that uses the sf::Image to load its textures.  I have a vector of images that will be used as I know each project will have a varying number of Textures.  I also have a GLuint vector that communicates the textures back to Open GL. Basicly I want the AddTexture(string FileName) function to be able to tell if the last data position in the vector has an image stored in it.  If there is already an image loaded then I wanted it expand both vectors by one and load the new image and bind the new texture.

   Most of the logic is already done I just couldn't easily find a way to test a given sf::Image and see if it already had a loaded file.  Sorry if the answer is somewhere obvious I have been looking for a while, and will continue to do so even after I post this.  )

Thanx for your time and happy new years to all!

[Laurent]

Why would your vector contain unloaded images? If your image is already loaded then use the corresponding element, if not then push_back a new instance and load it. When you unload an image, swap it with the last element and erase it, so that you avoid gaps in the vector.

[lesshardtofind]

Well obviously no images are loaded after the class is constructed unless I provide a filename as an argument in its construction (which I have not) so I wondered if I could test the vector for this initialization condition so that I didn't leave the first data position open and I didn't want to leave the last one empty either so the best way to keep the vector to the exact size of the number of textures was to just do a quick test to see if the vector[vector.size()-1] was loaded.  If there is no functionality for this I could also use a boolean in the class that was set to true on initiation and then set as false after the first load, but if there was built in functionality for this test I would be wasting memory by doing so. 

  So I asked ;o).  I'm am guessing by your answer there is no such functionality so I will revert to my other solution to the problem.  Thanks, and I do like the library you have developed so far.
 

[Laurent]

I still don't get why you have images that are not loaded in your array. Why doesn't it contain only the loaded images?

[lesshardtofind]

Well I initialize everything in a constructor including vector sizes being set to 1, to prevent undefined behavior.  So the first time I add a texture then the Image vector data position 0 is empty so I just load the image.  The second time I call it I need to expand and then load and bind textures.. 

Maybe code would be more clear than words subject to interpretation:

void TextureManager::AddTexture(std::string FileName){
  if(Birthing)
    Birthing = false;
  else
    Expand();
  int x = NumberOfTextures-1;
  Textures[x].LoadFromFile(FileName);
  glGenTextures(1, &TextureID[x]);
  glBindTexture(GL_TEXTURE_2D, TextureID[x]);
  glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, Textures[x].GetWidth(), Textures[x].GetHeight(),
               0, GL_RGBA, GL_UNSIGNED_BYTE, Textures[x].GetPixelsPtr());
  glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
  glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
}
 

[Josh]

If you're using an std::vector, and iterating over it with a for loop like

for(unsigned int i = 0; i < myVector.size(); i++)
  //...code...

Having an empty vector will not cause any problems. It won't run any of the code inside the for loop.

Then, when you want to add a new texture, in your AddTexture function you .push_back() a new element into the vector and set it up

[lesshardtofind]

Having an empty vector will not cause any problems.

Cool I did not know if that was true.  Since I had never been told so before I just avoided ever having an empty vector in any program as it seemed undefined which is where most bugs seem to come from.

[lesshardtofind]

And I feel real dumb 2 hours later when I realize the sf::Image is only needed for the loading process.
So I only needed one sf::Image to begin with and after all textures are loaded with handles it is pointless as well.

[Nexus]

Generally: To story heavyweight objects like sf::Image, std::vector is a bad choice because of its reallocations. std::list is a good alternative, references to its elements remain always valid (unless the element is removed).

[Laurent]

To story heavyweight objects like sf::Image, std::vector is a bad choice because of its reallocations

This is not true anymore with movable classes, right?

[Nexus]

Right.

If you don't define any of the Big Five (copy constructor, move constructor, copy assignment operator, move assignment operator, destructor), newer compilers can even generate them implicitly. Also, by using = default or = delete, you can specify exactly which functions you want to have, without writing the implementation. A default-generated move constructor moves the member variables element-wise, which is not always what you want.

The user still has to take care to allow move semantics. For example, here the compiler must perform a copy

sf::Texture texture;
texture.loadFromFile(...);

std::vector<sf::Texture> textures;
textures.push_back(texture);
// better:
textures.push_back(std::move(texture));

In other cases, move semantics happen automatically:

sf::Texture createTexture()
{
    sf::Texture texture;
    texture.loadFromFile(...);

    return texture;
}