关于ccstd的疑问

Creator 3.x
#1

准备测试升级cocoscreator3.6 ，编译ok，运行自定义的FileUtils里面纯虚函数报错，查了发现以前的std::string切换到ccstd::string

当然，本质上还是用了std::string , 只不过NS切换了一下

:sweat_smile:

整体搜了下，发现很多模块都做了这个调整，

想请教下引擎官方人员，做这个改变是因为什么考虑？

另外，std::vector, std::map等未来是否也会做此调整？

@jare @panda

#2

3.6避坑补充

如果你的项目自定义继承FileUtils，在3.6.x引擎版本，你还需要注意以下问题

这是3.6.2的FileUtils.cpp

image

这是3.5.2的FileUtils.cpp
image

修改的后果是，FileUtils::setDelegate 会把传进来的delegate销毁（因为FileUtils构造时sharedFileUtils已经指向了新的自定义FileUtils）

对应的commit应该是这个
refactor startup/shutdown of file system (#11089) · cocos/cocos-engine@0c12729 (github.com)

在3.6以前，为了避免去修改engine层，我们通常是这样实现一个自定义FileUtils

    cc::FileUtils::destroyInstance();  // 销毁默认
    auto * instance = new NewFileUtils();
    instance->init();
    CCLOG("NewFileUtils use  ");
    cc::FileUtils::setDelegate(instance);

// 后续FileUtils::getInstance() 得到的就是自定义的NewFileUtils实例（在iOS上NewFileUtils继承FileUtilsApple，在Android则是继承FileUtilsAndroid）

在3.6，FileUtils::destroyInstance已经是空实现了，我们需要调整成以下方式

    cc::FileUtils::setDelegate(nullptr);
    auto * instance = new NewFileUtils();
    instance->init();

// 后续FileUtils::getInstance() 得到的就是自定义的NewFileUtils实例（在iOS上NewFileUtils继承FileUtilsApple，在Android则是继承FileUtilsAndroid）
#3

修改引擎代码的项目，在升级时总会流下悔恨的泪水，除非老板愿意花钱花时间让你做期间无任何产出的引擎升级

#4

资源加密混淆必须得做，js层面来改性能太差了