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 
Ok, we will.
Thanks.
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.