strange behaviour where an object changes

I call this in draw (more, but this is where it goes from good to bad):

  
        stImplementation->convertToAppropriateType(gTangibleList.getTangibles());  
        const vector<ofxDTangibleBase *> tangs4 = gTangibleList.getTangibles();  
        printf("break\n");  

I call the 2nd line from above also at the last line of the method convertToAppropriateType.
If i look there at const vector<ofxDTangibleBase *> then it contains 1 object.
There everything is still ok. If you look on the first attachment you can see next, previous are NULL and className is STSequencer just like there suppose to.

After that nothing get’s excecuted anymore untill where in draw again.
There i also get the vector<ofxDTangibleBase *> with still 1 object, like it should be. The pointer to the object is also the same. But if we look now at next, previous and className then it’s totally messed up.

How is this possible?

here is the method:

  
void STImplementation::convertToAppropriateType(const vector<ofxDTangibleBase *> &tangibles) {  
      
      
    printf("break in convertToAppropriateType\n");  
      
    for (int i = tangibles.size()-1; i >= 0; i--) {  
        ofxDTangibleBase &t = *tangibles[i];  
          
        float minimumSimilarityRequired = 0.75;  
          
        // in the end we check if simularity  
        // is close enough to create whatever  
        // closestType is  
        STTypes closestType = UNDEFINED;  
          
        float closestColorSimilairityValue = 0;  
          
        ofColor cSequencer(255, 0, 0);  
        ofColor cSample(0, 255, 0);  
          
        float colorSimilarityV ;  
          
        // sequencer  
        colorSimilarityV = colorSimilarity(t.getColor(), cSequencer);  
          
          
        if(colorSimilarityV > closestColorSimilairityValue) {  
            closestColorSimilairityValue = colorSimilarityV;  
            closestType = SEQUENCER;  
        }  
          
        // sample  
        colorSimilarityV = colorSimilarity(t.getColor(), cSample);  
          
        if(colorSimilarityV > closestColorSimilairityValue) {  
            closestColorSimilairityValue = colorSimilarityV;  
            closestType = SAMPLE;  
        }  
          
        if(closestColorSimilairityValue >= minimumSimilarityRequired) {  
            switch (closestType) {  
                case SEQUENCER:  
                {  
                    printf("SEQUENCER\n");  
                    STSequencer sequencer(t);  
                    ofxDTangibleBase *pBase = &t;  
                    gTangibleList.removeTangible(pBase, "ofxDTangibleBase in sequencer part");  
                    STSequencer *pSeq = &sequencer;  
                    gTangibleList.addTangible(pSeq);  
  
                }  
                    break;  
                      
                case SAMPLE:  
                {  
                    printf("SAMPLE\n");  
                    STSample sample(t);  
                    ofxDTangibleBase *pBase = &t;  
                    gTangibleList.removeTangible(pBase, "ofxDTangibleBase in sample part");  
                      
                    STSample *pSam = &sample;  
                    gTangibleList.addTangible(pSam);  
                }  
                    break;  
                      
                default:  
                    break;  
            }  
              
        }  
        else {  
            // it could be that the color is not trackable anymore  
            // but maybe we new what tangible it was before  
            // so we can decide here to keep it  
            // or to remove it  
            // or to add it to a unfocus list  
            // untill it get's focus again within a certain time  
            // TODO  
            // ...  
        }  
          
          
    }  
      
    const vector<ofxDTangibleBase *> tangs4 = gTangibleList.getTangibles();  
    printf("break\n");  
  
  
      
}  

![](http://forum.openframeworks.cc/uploads/default/3064/Screen Shot 2013-10-31 at 10.03.25 AM.png)

![](http://forum.openframeworks.cc/uploads/default/3066/Screen Shot 2013-10-31 at 10.03.50 AM.png)

please have a read about objects on the stack and objects on the heap. Your code seems completely broken.

  
  
{  
                    STSequencer sequencer(t);    
                    ofxDTangibleBase *pBase = &t;    
                    gTangibleList.removeTangible(pBase, "ofxDTangibleBase in sequencer part");    
                    STSequencer *pSeq = &sequencer;    
                    gTangibleList.addTangible(pSeq);    
}  
  

Let’s look at the quoted code:

First you create a STSequencer-object on the stack, then you save a pointer to this object into a vector. After the programs leaves the current code context (when the exception pointer leaves the {}-block) the object on the stack gets freed, which means, that the pointer in gTangibleList points to uninitialized memory which may be used by other parts of your program.

This will lead to serious crashes and bugs/inconsistencies hard to track.

If you use pointers to objects, you must be sure that the objects exists while using these pointers. I’d suggest don’t use non-const references to objects as they are highly advanced, and create your objects on the heap via

  
  
  
                   STSequencer sequencer = new STSequencer(t);    
                   gTangibleList.addTangible(sequencer);    
  
  

And you’ll have to make sure that you delete the object from the heap, when you are done with it.

HTH,

Stephan

thanks. This really helps.

Speed is an issue (atm i have 60fps, so it’s no issue yet). But “new” is slow i readed (and experienced myself with java). Would it be a good approach for me to make one big list at program startup that hold objects i can use later. And have a boolean in a object like isFree.
And then getFreeTangible(); to return the first free tangible from a list.

Hope you understand what i mean.

c++ is not java. Don’t overcomplicate your code. Try it first with the simplest approach, and if performance suffers, profile the code, find its bottlenecks and try to optimize them.

cheers,
Stephan