string_helper.cpp: fix compilation error

[barracuda156]

Fixes this error:

/opt/local/var/macports/build/_opt_CatalinaPorts_multimedia_wiliwili/wiliwili/work/wiliwili-1.5.2/wiliwili/source/utils/string_helper.cpp:17:55: error: no viable conversion from returned value of type 'basic_string<[2 * ...], SecureAllocator<char>>' to function return type 'basic_string<[2 * ...], (default) std::allocator<char>>'
   17 | std::string urlEncode(const std::string &in) { return cpr::util::urlEncode(in); }
      |                                                       ^~~~~~~~~~~~~~~~~~~~~~~~
/opt/local/libexec/llvm-19/bin/../include/c++/v1/string:999:71: note: candidate constructor not viable: no known conversion from 'util::SecureString' (aka 'basic_string<char, std::char_traits<char>, SecureAllocator<char>>') to 'const string &' for 1st argument
  999 |   _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_STRING_INTERNAL_MEMORY_ACCESS basic_string(const basic_string& __str)
      |                                                                       ^            ~~~~~~~~~~~~~~~~~~~~~~~~~
/opt/local/libexec/llvm-19/bin/../include/c++/v1/string:1019:55: note: candidate constructor not viable: no known conversion from 'util::SecureString' (aka 'basic_string<char, std::char_traits<char>, SecureAllocator<char>>') to 'string &&' for 1st argument
 1019 |   _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 basic_string(basic_string&& __str)
      |                                                       ^            ~~~~~~~~~~~~~~~~~~~~
/opt/local/libexec/llvm-19/bin/../include/c++/v1/string:1058:55: note: candidate constructor template not viable: no known conversion from 'util::SecureString' (aka 'basic_string<char, std::char_traits<char>, SecureAllocator<char>>') to 'const char *' for 1st argument
 1058 |   _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 basic_string(const _CharT* __s)
      |                                                       ^            ~~~~~~~~~~~~~~~~~
/opt/local/libexec/llvm-19/bin/../include/c++/v1/string:1198:55: note: candidate constructor not viable: no known conversion from 'util::SecureString' (aka 'basic_string<char, std::char_traits<char>, SecureAllocator<char>>') to 'initializer_list<char>' for 1st argument
 1198 |   _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 basic_string(initializer_list<_CharT> __il)
      |                                                       ^            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/opt/local/libexec/llvm-19/bin/../include/c++/v1/string:989:64: note: explicit constructor is not a candidate
  989 |   _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 explicit basic_string(const allocator_type& __a)
      |                                                                ^
/opt/local/libexec/llvm-19/bin/../include/c++/v1/string:1154:93: note: explicit constructor is not a candidate
 1154 |   _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS _LIBCPP_CONSTEXPR_SINCE_CXX20 explicit basic_string(const _Tp& __t)
      |                                                                                             ^
/opt/local/libexec/llvm-19/bin/../include/c++/v1/string:1215:55: note: candidate function
 1215 |   _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 operator __self_view() const _NOEXCEPT {
      |                                                       ^
1 error generated.

However I need to test this with gcc / libstdc++ as well, therefore a draft.

[xfangfang]

This appears to be a compatibility issue with the latest CPR release. I’d prefer to address it when I have time to upgrade CPR in the future—the blocker right now is getting GitHub Actions to build for macOS 10.11–10.15.

Considering macOS users as a whole make up only 0.4% of wiliwili's users, I'm inclined to drop support for these systems.(Rather than providing pre-built binaries via GitHub Actions, we’ll leave compilation to those system users themselves.)

[barracuda156]

Considering macOS users as a whole make up only 0.4% of wiliwili's users, I'm inclined to drop support for these systems.

Personally I am not affected by pre-built stuff, I can build from source anyway, but it is desirable to retain support in principle. We could probably simplify CMakeLists code though and let package managers handle options per-macOS-version.

[barracuda156]

(Just to update on the status, I think this fix is working fine, since I am using wiliwili with external cpr.)