Support for std::string_view in sf::String

[khatharr]

Description

Revision of #2451

This is in a new branch and up to date with the origin's master as of this post.

This PR is related to the issue #2445

Tasks

• Tested on Linux
• Tested on Windows
• Tested on macOS
• Tested on iOS
• Tested on Android

How to test this PR?

Test driver (modified to match changes in sf::Text):

#include <SFML/Main.hpp>
#include <SFML/Graphics.hpp>
#include <SFML/Window.hpp>

#include <string_view>

int main() {
  sf::RenderWindow window(sf::VideoMode(sf::Vector2u(800, 600)), "SFML Testbed");
  window.setFramerateLimit(60);

  sf::Font font;
  bool derp = font.loadFromFile("c:/Windows/Fonts/arial.ttf");
  
  const char data[] = "derpdurr";
  const wchar_t wdata[] = L"herpboing";

  std::string str(data + 4, 4);
  std::string_view sv(data, 4);
  std::wstring wstr(wdata, 4);
  std::wstring_view wsv(wdata + 4);

  std::vector<sf::Text> texts;
  texts.emplace_back(font, wstr);
  texts.back().setPosition(sf::Vector2f(10, 0));
  texts.emplace_back(font, sv);
  texts.back().setPosition(sf::Vector2f(10, 40));
  texts.emplace_back(font, str);
  texts.back().setPosition(sf::Vector2f(10, 80));
  texts.emplace_back(font, wsv);
  texts.back().setPosition(sf::Vector2f(10, 120));
  
  for(bool run = true; run;) {
    window.clear();
    for(auto& text : texts) {
      window.draw(text);
    }
    window.display();

    sf::Event event;
    while(window.pollEvent(event)) {
      if(event.type == sf::Event::Closed) { run = false; break; }
    }
  }
}

[khatharr]

I'll be more careful in the future.
Thank you for your patience.

[codecov]

Codecov Report

Merging #2517 (5c1c795) into master (82b9821) will increase coverage by 0.03%.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2517      +/-   ##
==========================================
+ Coverage   27.13%   27.16%   +0.03%     
==========================================
  Files         229      229              
  Lines       19652    19661       +9     
  Branches     4713     4714       +1     
==========================================
+ Hits         5332     5341       +9     
- Misses      13587    13602      +15     
+ Partials      733      718      -15     

Impacted Files	Coverage Δ
include/SFML/System/String.hpp	100.00% <ø> (ø)
src/SFML/System/String.cpp	100.00% <100.00%> (ø)

... and 2 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 82b9821...5c1c795. Read the comment docs.

[Bromeon]

Thanks for the PR!

I know it's for consistency, but the API surface for wchar_t, etc. is getting quite big, for it being mainly a Windows oddity that surfaces when dealing with legacy APIs. u16string is similarly rare.

Are types like std::wstring_view actually being used?

[khatharr]

The current implementation in origin:master has constructors for string/wstring/u32string. I added string-view/wstring_view/u32string_view to match those. I didn't see anything relevant for u16.

Are types like `std::wstring_view` actually being used?

I always thought it was used for large character sets like Hangul or Mandarin.

[Bromeon]

I always thought it was used for large character sets like Hangul or Mandarin.

You probably mean Unicode in general, but most modern code uses either UTF-8 or UTF-32 to represent them, which can be encoded in various types in C++ (e.g. char, std::uint8_t, std::char8_t for UTF-8).

wchar_t on the other hand is a legacy type, mostly to deal with UCS-2/UTF-16 encoding at the time. See also StackOverflow or Wikipedia. You generally don't see modern APIs use it except for interop; newer programming languages don't even have such a type.

I'm not saying sf::String should not provide interop for those, but I think their usefulness is overstated. And in my experience, these legacy APIs tend to be low-level (i.e. pointer/size pairs rather than C++17 wstring_view). But maybe it's worth providing just for consistency.

[ChrisThrasher]

Ignore my u16_string comment. I forgot we don't have a constructor from that type.