Working on a project that uses some non cocos2d classes. I have a std::unordered_map
I use that to store some information from a class that subclasses a cocos2d::Ref
class myclass : public cocos2d::Ref
{
std::unordered:map<int,cocos2d::Sprite*> mymap;
myclass::myclass()
{
//instantiate some sprites and add them to my map
cocos2d::Sprite *sp = cocos2d::Sprite::create(“filename”);
mymap[index] = sp;
//If I check on my sprites at this point in the code they’re still ok.
}
myclass::update()
{
for(cocos2d::Sprite s : mymap)
{
index = s.first; //this is fine
cocos2d::sprite = s.second //sprite is nullpointer here
}
}
So as you can see somehow my sprites loose all reference to the cocos2d framework when I add them to the unordered map so I can’t actually get them back out.
Use cocos2d::Map instead of std::map. cocos2d::Map will retain the values and when the map is cleared will release the values. Otherwise, you need to retain sprites yourself and releases them yourself as well once you’re done with them.
Then u need to retain them manually, though I would recommend using cocos2d::Map…
mymap[index]->retain() when u add them to the map
for(auto &s: mymap) { s->release()} in the destructor of the scene or when ur done with the map
using auto&& so that I can handle the rvalue reference returned for the mymap case
It allows you to match lvalues aswell as rvalues and let both be mutable, without making a copy.
If the map iterator will return a const reference, your code will not compile. You would need to use const auto&. auto&& lets you cast away the constness.
It’s basically used to handle an edge case, where the iterator is returning a const reference, but you want to access it in a non const way, by using auto.
It’s a good thing, because you want an universal reference in the ranged for loop. In this case, universal references are declared with two ampersands. Using only one, means that its only a reference, but you want to use the new features of C++11: move semantics and universal references, which means best performance, resource usage(e.g., no temporaries) and the ability to use proxy references in a non-const way.
It maybe is a little hard to grasp in the first place, to understand the concepts.
Thanks @iQD - I still don’t understand enough, after reading your links and others - it seems to me that there isn’t a clear-cut advantage to using && except in odd edge-cases?
It would seem to me that & is the way to go (avoids copying the pointer which may save a nanosecond or two) - but && seems to be overkill for the “just on case” scenarios!
(although I frankly don’t understand the whole thing well enough to be confident!)
Its one of the more complicated topics of C++11/C++14.
The clear-cut advantage is fail-safety.
It’s a fail safe, if you are changing the container, which implements an iterator returning a const ref, like a boolean vector. In that case, auto& will not compile, as you want to access the iterator object in a non-const way, which is not allowed and it will generate a compiler error.
It’s best to use const auto&, if you don’t need to alter the iterator object. If you want to alter it, it’s best to use auto&& to be future proof.