Cocos2d-x 3.x Migration – C++11 Subtle Mistakes

I’ll probably repeat myself that c++11 makes developing in c++ much more pleasant. However, there are some interesting issues when migrating from various class structures to the new std:: template containers and algorithms.

std::remove removes all elements of a given type, not just the first one found. Normally I try and use the for (auto& element : arr ), but in these cases I use the full iterator syntax instead. Could also use an index based loop, or no doubt another approach which I haven’t learned.

// v is vector<string> may contain duplicate strings
for ( auto& el : v ) {
    // tried to use remove, but removes all found elements
    v.erase(std::remove(v.begin(), v.end(), el), v.end()); 
}

// instead use iterator pointer
for ( auto it = v.begin(); it != v.end(); it++ )
{
  std::string element = (*it);
  if(element == "string to match")
  {
     // want to remove first string match
     v.erase(it); // iterator is invalid afterward
     break;
   }
}

[I’ll continue to append new issues as they’re encountered]

Cocos2d-x 3.x Migration – std::string & nullptr

As I move our code base toward pure c++11 where it makes sense when changing or adding functionality. Once I moved from using cocos2d-x’s __String class to std::string and associated std::vector<std::string> in a couple places I figured it was a good candidate to migrate fully away from the __String class altogether.

This was mostly a simple find/replace exercise with various regular expressions, but one thing I wasn’t aware of is that the act of assigning nullptr to a std::string does not trigger a warning or error at compile time, but rather fails as expected at runtime. This was cause for more time spent to correctly handle all cases where the idea of no string or an empty string is necessary.

I would think there is a flag for each compiler to detect these at compile time, but I haven’t looked into it much since it wasn’t all that much effort to fix the code, but it did take much longer than if the compiler had flagged every location which it should be able to do.

I realize this is fairly specific to the migration process as well how the code was originally written, but still an unexpected annoyance in the process.