Std::string usage in cocos2d-x 3.0

For the future, at least please consider allowing some customization for the string implementation (subclass std::string with virtual methods, define the type of string employed with a define, etc).

Thanks :wink:

Ok, we will.

The Cocos Team did really well to use std::string’s instead of const char*'s. I’ve seen many novice programmers ask questions like the OP of this question on SO and other places about the performance differences between these two data structures. The conclusion is, the overhead of std::string is absolutely minimal, while on the other hand it increases runtime safety, ease of use, and consistency with the rest of the STL… Representing strings with cons char*'s is as deprecated as writing new’s and delete’s in your code where RAII classes can be used instead.

1 Like

Absolutely agree with @MatrixAndrew. std::string usage in examples above don’t give any performance penalties. It also shouldn’t bring much memory allocations - as you don’t create much strings at once (and don’t create them on the heap and forget to delete them).
In game engines strings usually optimised when them used as Tags or Identifiers for objects and components that can be queried thousands times per frame. In that case them firstly optimised for comparison speed. Though copy cost also important here. And in these cases it may be even better to use solutions other than strings.
But what i want to say - strings usage may be an issue only in few places, and it would be better to consider optimise them firstly. As rewriting strings in the whole engine may bring unnecessary additional complexity.

P.S. Another reason for me for using custom string class - if custom allocators used widely across whole game engine.