Platform: replace use of std::string with String and StringView

[Squareys]

Hi @mosra!

Since all the std::string is removed elsewhere, it's now very worth removing it from GlfwApplication.h also!

Best, Jonathan

TODO

• [x] Compile the test
• [ ] Run GlfwApplicationTest (currently crashes on some unset dpi policy?)

[Squareys]

@mosra Thanks for the review! This is more a "nice to have", since it will improve our compile times (eventually, when we're able to turn off MAGNUM_BUILD_DEPRECATED).

I might also have a look at making these changes for EmscriptenApplication tomorrow.

[mosra]

.. and SDL, and Android, and ... ;)

[mosra]

I took your changes as a base for a6da074ae0bb2198822e8f79f11c68d0a1bbbad1...53a74b5e6ce87920b2de5abcb8bde745c4b96524 and kept you as a co-author, but the changes are significantly different from what's in this PR. Tried to convince GitHub to show a diff between the two so you could see what additionally had to be done, but the best I got includes also a ton of other changes that happened since the PR was opened.

Things worth mentioning:

• All functions that had to take care of non-null-terminated views are now tested in the corresponding application tests, by passing a slice out of a larger string. It's manual testing, but better than nothing.
• The default application title now also uses a non-owning String, instead of always allocating a copy
• Emscripten actually has an API to create a string from a pointer + size, so that's what I used instead of potentially allocating another copy. Important: the documentation of UTF8ToString() mentions that one should consistently use either the sized or the unsized variant, to make the JIT optimize the function better. I bet you use this quite a lot in your codebase, so maybe check which variant you have and make it consistent.
• The TextInputEvent and TextEditingEvent used to use an ArrayView to avoid a string allocation. That was a temporary solution and they now use a StringView as well, which allowed me to remove an ArrayView.h include from all application headers, further reducing the bloat.

[Squareys]

I bet you use this quite a lot in your codebase, so maybe check which variant you have and make it consistent.

Quick note, because we're not using UTF8ToString() at all anymore: UTF8ToString() will call a JavaScript implementation of strlen in any case, it uses the second parameter only as a "buffer size, but the string might be shorter" parameter. We switched during the process of switching to StringView.

See also https://github.com/emscripten-core/emscripten/issues/12517.

[mosra]

it uses the second parameter only as a "buffer size, but the string might be shorter" parameter

Yes, I'm aware, but apart from the unnecessary strlen it's the behavior I want, to not make it any longer than the originating StringView is.

we're not using UTF8ToString() at all anymore

So you have your own implementation of this, based on https://github.com/emscripten-core/emscripten/issues/12517, and call that instead? In my case I'm not sure I'd want to bother (providing a JS file with a non-shitty implementation, bundling it to all produced executables, all that extra pain...).

The Stale Bot is a cancer, FFS. So many issues get just sweeped under the rug due to it.