Redesign Engine and APIs for C++17

[mogemimi]

Hello, mates!
I have the following plans for Pomdog in 2018:

Plans

• To migrate C++14 -> C++17, I will remove support for such old compilers and IDEs:
  • Visual Studio < 2017
  • Xcode < 9.2
  • LLVM Clang < 5.0
• Migrating a new build system from GYP
• Removing all tools written by Python 2.x from our toolchains
• Using Catch2 as a test framework
• Update the version of clang-format and .clang-format
• Upgrading third-party libraries, docker containers and CI settings.

New API Style

• Use C++17, not C++14
• Replacing Pomdog::Optional<T>, Pomdog::Any and Pomdog::PathHelper with the C++17 standard libraries.
• Do not use Exceptions in favor of the std::tuple, std::tie and std::optional for error handling.
• More documentations and examples.

Done/TODOs

• Ubuntu docker container for CI
  • Clang: 3.8 -> 6.0
  • Ubuntu: 17.04 -> 18.04 LTS
• Wercker CI
  • Clang: 3.8 -> 6.0
  • C++14 -> C++17
• Travis CI settings
  • Xcode: 8.3 -> 9.2
  • Update Xcode requirement to 10 Beta 6
• Fix some build errors with Clang 5.0 on a new Ubuntu
• Updating third-party libraries
  • zlib
  • libpng
  • rapidjson
  • stb
  • UTF8-CPP
  • GLEW 1.13 -> 2.1
• CMake support
  • Building static libraries and executables using CMake
  • Building *.framework using CMake
  • Building shared library using CMake (Support building shared library with CMake #20)
  • Remove GYP artifacts completely (Remove GYP artifacts completely #22)
• Rewrite tools from Python 2.7 to Golang (Rewrite tools from Python 2.7 to Golang #23)
• Use std::optional instead of Optional class
• Testing between Debug and Release configuration on CI
  • a96b288
  • 6478995
  • 6a248e0
• Vendoring Catch2 header and rewriting test cases
• New file system
  • Make resource file path flexible (Resource directory is hard-coded #19)
• New error handling API without exceptions
  • Add Result<T, E> class
  • Add IOError class
• Add test game
  • Add more examples and test cases (Redesign sprite and font drawing #30)
  • Remove the obsolete test/TestApp directory
  • Remove examples/TestGame (Redesign sprite and font drawing #30)
• Pixel perfect rendering
  • Redesign Sprite, Scene and Camera
  • Add support for Retina or 4K display on Mac
• Updating documentation
  • e2cdd68
  • 1053fa5
  • Inregrating all contents of GitHub wiki to docs directory (6347915)
  • Add documentation about Application (Documentation: Application #26)
    • dfe96c3
    • f32d260

[barsoosayque]

I noticed that Pomdog::FileSystem has system-depend implementation, and since there is std::filesystem, this part can also be refactored in favor of c++17 std:

• Pomdog::FS::CreateDirectory -> std::fs::create_directory
• Pomdog::FS::CreateDirectories -> std::fs::create_directories
• Pomdog::FS::Exist -> std::fs::exists
• Pomdog::FS::IsDirectory -> std::fs::is_directory
• Pomdog::FS::GetTempDirectoryPath -> std::fs::temp_directory_path
• Pomdog::FS::GetCurrentWorkingDirectory -> std::fs::current_path

(note: FS is reduced form of FileSystem and fs is reduced form of filesystem)

Although, I'm not sure about other methods in there (GetLocalAppDataDirectoryPath, GetAppDataDirectoryPath and GetResourceDirectoryPath). Since I am using Linux, I am not aware of AppData directories in either Mac or Windows, so I can't guess there.

[mogemimi]

Hello @barsoosayque,

this part can also be refactored in favor of c++17 std

I agree with you. These APIs will be replaced with <file_system> and will be deprecated. 👍
Currently, Mac (Xcode 9) does not support <file_system> and <experimental/file_system> yet, so I'll upgrade the build requirements of Pomdog for the C++17 libraries when Xcode 10 stable will be released.

GetResourceDirectoryPath() represents a asset directory which includes the Content directory. When you build the application, the Content directory is copied into it from your source directory. It is usually the same as where the executable file is located.

GetLocalAppDataDirectoryPath() and GetAppDataDirectoryPath() are equal to /home/<Username>/.<application-name>/, like ~/.thunderbird or ~/.minecraft on Linux, but these are not been implemented yet, please see FileSystemLinux.cpp#L70-L80.

In addition, these are platform-specific APIs which is causing confusion, so I'd like to change them as follows:

// current version
std::string GetLocalAppDataDirectoryPath();
std::string GetAppDataDirectoryPath();

// next version (TBD)
std::optional<std::string> Win32::GetLocalAppDataDirectoryPath();
std::optional<std::string> Win32::GetAppDataDirectoryPath();
std::optional<std::string> Mac::GetApplicationSupportDirectoryPath();
std::optional<std::string> Linux::GetHomeDirectoryPath();
std::string GetContentDirectoryPath();
std::string GetPersistentDataDirectoryPath();

[barsoosayque]

... are equal to /home/<Username>/.<application-name>/, like ~/.thunderbird or ~/.minecraft on Linux.

It is now desirable to store game data (or any other program specific data, but not the configs) in $HOME/.local/share/<application-name>/ according to the XDG Specification.

Regarding next filesystem API, I guess it will be more convenient to return std::filesystem::path and then do path.c_str() or path.string().

[mogemimi]

... $HOME/.local/share// according to the XDG Specification.

Thank you for the link. That seems like the right path! I'll read the spec and try it.

it will be more convenient to return std::filesystem::path

I totally agree with this direction. 👍