With the release of v4 looming on the horizon, I think it would be a good time to make code-breaking changes.
AudioEngine out of the experimental namespace (isn’t it the only audio engine available anyway?)FastTMX out of the experimental namespace.experimental namespace if it’s been there more than 12 months!What do people think?
Yep, i agree with you. But move from C++11 to C++14, i am not sure if it can work or not.
Yes agreed too. Moving namespaces isn’t to hard for developers to change in their code 
You can use c++14 or 17 in your project if you wish now. What benefits would you expect by moving the whole engine to using it? I think it would take the team some time and hold up the release date…
To be honest I wasn’t expecting to make changes to the engine code to use the new
features of C++14/C++17 straight away, but rather make it the new default standard so that game devs can use the new features if required. I think it’s important that both game and engine are compiled using the same C++ standard, but would leave it up to game devs what new features they exploited.
I don’t think it would cost anything to do so.
Once it’s been adopted we could then look at applying the new language features to the engine code during the lifetime of v4.
I have my eye on other aspects of the engine that I want to address over the coming months:
About namespace of audio, i think we can replace experimental with audio, which means use cocos2d::audio for audio module.
About audio implementation, i think it is better to use OpenAL for all platforms, there is an issue for it: https://github.com/cocos2d/cocos2d-x/issues/20151.
I am happy to use the audio namespace if that helps matters. Using the name audio::AudioEngine does seem a bit awkard though?
WRT OpenAL, I was interested in modernizing the frameworks that Cocos2d-x uses and these newer frameworks seem to be implemented with performance in mind, which is always a bonus. I will look into them when the time is right (perhaps never) and if I get them working but you guys feel you don’t want them as part of the main codebase then that’s not an issue. Cocos2d-x has diverged on github in a hundred ways already
You can just change this in your build settings. I use c++17 now where applicable.
Can you explain what you mean here?
You can just change this in your build settings. I use c++17 now where applicable.
Absolutely, you can change whatever you like in the IDE projects, but with cmake being so important in v4 I would like to have everything defined in the CMakeLists.txt files and one of those things is the C++ standard to use to compile the engine and game.
Cocos2d-x has diverged on github in a hundred ways already
Can you explain what you mean here?
I simply mean that many people use their own fork of Cocos2d-x and rebase on the upstream version now and then. If there are any changes that I don’t want to create a pull request for, or that pull request is rejected for whatever reason, then they can stay in the fork without issue or rancour for my own use.
Yep, you are right.
OK guys, thanks for your feedback. I will create a PR for this work soon which can be reviewed by all those interested. I have other changes I want to do first though… 
Gotcha. True. Thanks.
As we want to release v4 in this month, could you please fix namespace issue first? Or i can do it if you don’t have time. Thanks.
Yup no worries.
Thanks. Indeed, i created an issue for it a few months ago, but i forgot to fix it: https://github.com/cocos2d/cocos2d-x/issues/19819.
you guys are great… thanks for the nice job all you are doing to keep this beautiful engine alive… my c++ is steel very poor, i´m studying from my book C++11 Bjarne Strouptup, so i hope i can contribuite with cocos2d development some day… i will never turn back to higher lever languages…
Does it work on Android as well? My last tests shows c++14 is the latest working level right now.
It will depend on the version of the NDK you use and it looks like it was introduced in r18b. Is it possible to use that to build apps for reasonably old versions of Android?
If it’s possible then NDK r18b could be made a requirement of v4, but if there are issues with this we could settle for C++14 as we aren’t actually using C++17 features anyway.
@trojanfoe may be i didn’t describe it clearly. Removing experimental name space is good, but i don’t think changing to use C++14/17 is a good idea now. Metal support is a big change, and it take long time to be stable, change to usage C++14/17 may bring unstable issues, so i don’t think it is a good time to do it right now. We can change it after v4.0 is released.
OK that’s fair enough. I will remove that change in this PR. I will submit a PR for the namespace work this evening.