You're right, this only really shows up when you end up spawning many threads across the lifetime of the program. My initial use case involved a lazy image loader that spawned a separate thread for each image I wanted to use. Something like this:
class MyImageLoader : public Thread {
MyImageLoader(string imageName);
void Run() {
image = new Image();
// load the image data and do some moderate processing on it
ready = true;
}
};
class MyImage {
MyImage(string imageName) {
myImage = NULL;
myLoader = new MyImageLoader(imageName);
myLoader->Launch();
}
void Draw(RenderWindow window) {
// If loader is done, take our image and cleanup the loader.
if (myLoader && myLoader.ready) {
myImage = myLoader->image;
delete myLoader;
myLoader = NULL;
}
// If we have our image, draw it. Otherwise, it must be
// loading -- draw nothing.
if (myImage) {
window.Draw(new Sprite(*myImage));
}
}
};
I intended to eventually go back and rework it into some sort of single-threaded worker queue, but this did the job for the time being and it seemed to work fine until I started hitting the GL errors. SFML2 appears to have cleared those up, but by the time I had boiled it down to a minimal example, I realized it was susceptible to this memory consumption issue as well.
Even though it may be poorly architected, I don't think there's anything really wrong with the code above, and if someone wanted to write such code, I don't see why SFML should prevent or discourage them from doing so.
