1

I'm having trouble implementing an ImageManager into my program. I had success using this method with references:

//definition in Brick.h
ImageManager &imgr;

//constructor taking &imgr as a reference upon creation of object
Brick::Brick(ImageManager &im) : imgr(im){
//imgr is now a reference in my class, so it points to the same object that imgr in another class would point to
//this essentially makes one "static" instance of imgr, so all my graphic objects are dealing with the same instance of my ImageManager
    imgr.doStuff()
}

This method of passing around my imgr used to work, until I started trying to remove obejcts from vectors. For instance, in my Level class I try to remove elements from a vector of Brick objects,

void Level::RemoveLine(int line){
    //loop through every piece, loop through given piece's rects, if the rect falls on the removed line, then remove the piece
    for(int i = 0; i < gamePieces_.size(); i++){
        //crt new iterator per each gamepiece
        auto write = gamePieces_[i].GetPieceRectangles().begin();
        int j = 0;
        for(auto read = write; read != gamePieces_[i].GetPieceRectangles().end(); read++){
            if(gamePieces_[i].GetPieceRectangles()[j].GetActiveLine() != line){
                if(read != write){
                    write = std::move(read);
                }
                write++;
            }
        }
        gamePieces_[i].GetPieceRectangles().erase(write, gamePieces_[i].GetPieceRectangles().end());
    }
}

but this doesn't work because ImageManager &imgr declared in Brick.h doesn't have a copy constructor, so it can't be copied in vectors when I try to .erase() the element. My goal is to implement one static ImageManager object to be used throughout all my classes. How would I go about doing this?

jww
  • 97,681
  • 90
  • 411
  • 885
jburn7
  • 125
  • 2
  • 3
  • 15
  • If your attempt is getting rid of a global `ImageManager` (which is good), use a std::shared_ptr, which you can pass around, easily. –  Oct 15 '14 at 18:37
  • Well, my attempt is to make it global, really, but I see your point. I actually switched the reference defintion `ImageManager &imgr` to a pointer `ImageManager *imgr` and changed all the instances of imgr accordingly. Is that fine or should I implement a std::shared_ptr? – jburn7 Oct 15 '14 at 18:55

2 Answers2

1

"My goal is to implement one static ImageManager object to be used throughout all my classes"

You can implement ImageManager as Singleton class. But I have learnt to use singleton only if there's no other option.

You can also use static data members in your class. In this way only one copy of your class's data members would be in circulation.

ravi
  • 10,994
  • 1
  • 18
  • 36
  • A global is a global, it does not matter if it is a singleton, static member or whatever global member variable. –  Oct 15 '14 at 18:59
  • @DieterLücking http://stackoverflow.com/questions/1463707/c-singleton-vs-global-static-object. There's no definite answer which is better but static has some advantage over singletons. – ravi Oct 15 '14 at 19:08
0

Generally speaking this kind of code isn't what you want. Take a look at the Singleton design pattern.

https://en.wikipedia.org/wiki/Singleton_pattern

Tim
  • 4,560
  • 2
  • 40
  • 64
  • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. – ArtOfWarfare Oct 16 '14 at 00:55
  • 1
    Actually it does answer his question. It points out that a direct answer isn't what he should be going for (i.e. a direct answer would be an anti-pattern in 99.9% of cases), and secondly that if he wants a single, static, instance accessible in a structured way from wherever, there is a pattern for that, and it is called "Singleton". – Tim Oct 16 '14 at 01:29
  • "this kind of code isn't what you want" sounds like you're arguing with the person who posted the question, which would indicate that this isn't an answer, but perhaps a critique which would be better left as a comment. Either way, @BrianCarlton is correct - this seems to be a link only answer even if it isn't, as I asserted, a comment. – ArtOfWarfare Oct 16 '14 at 11:43