Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Basic string_view support #1217
Conversation
independent of UNICODE vs MBCS setting Set CPPREST_FORCE_NARROW_STRINGS=ON to enable. Simplistic cleanup throughout project is not possible as some Windows APIs require utf16 such as HTTPSPolicyCallbackData in http_client_winhttp.cpp. HTTP related code is not completely updated so a full package may not be produced, though settings exist to have a clean build. Use: -DCPPREST_FORCE_NARROW_STRING=ON -DCPPREST_EXCLUDE_WEBSOCKETS=ON -DCPPREST_HTTP_LISTENER_IMPL=none -DBUILD_SAMPLES=OFF
…omponents like just json support extractions from asyncrt_utils.h: base64_utils.h (to/form base64) memory_utils.h (details::make_unique) string_utils.cpp (string utils) asyncrt_utils retains error, date-time, and nounce utils
- default to enable CPPREST_USE_STRING_VIEWS when compiler supports C++ 17 most string utility and json APIs are changed to support string_views (deprecated APIs left alone) primary argument replacements: const utility::string_t& -> utility::string_view_t const std::string& -> utility::nstring_view_t const std::wstring& -> utility::wstring_view_t const utf16string& -> utf16string_view potential client fallout when enabling option: For clients passing char* to conversion that does not require conversion, string_view will be the result. If string type is actually required then an explicit ctor would need to be added. Otherwise client may be able to use more string_view in own code and futher reduce memory copies. See searchfile.cpp in Samples for example. Use of foo.c_str() and &foo[0] on a potential string_view is now foo.data().
- forced on for VS 2017 - forced off for VS 2015 - default for all others
+ add respect for CMAKE_CXX_STANDARD when set
…nto jason-ha/basic_string_view_support
…nto jason-ha/basic_string_view_support
| #else | ||
| inline const utility::string_t& to_string_t(const std::string& s) { return s; } | ||
| #if CPPREST_USE_STRING_VIEWS | ||
| inline utility::string_view_t to_string_t(utility::nstring_view_t s) { return s; } |
toughengineer
Aug 4, 2020
Contributor
All overloads of to_string_t should return a string object, not a string view, since the expectations of the function is to return a string object:
/// <param name="s">A single byte character UTF-8 string.</param>
If you sometimes return a string object and sometimes a string view it may lead to unexpected disasters, e.g.:
auto text = to_string_t(getSomeText());
If getSomeText() returns a string object or a string view, you're OK.
But if it returns something convertible to string view, after that statement the returned temporary is destroyed, text is dangling now and you're most certainly screwed.
All overloads of to_string_t should return a string object, not a string view, since the expectations of the function is to return a string object:
/// <param name="s">A single byte character UTF-8 string.</param>
If you sometimes return a string object and sometimes a string view it may lead to unexpected disasters, e.g.:
auto text = to_string_t(getSomeText());
If getSomeText() returns a string object or a string view, you're OK.
But if it returns something convertible to string view, after that statement the returned temporary is destroyed, text is dangling now and you're most certainly screwed.
addresses issue #1216
Add CPPREST_USE_STRING_VIEWS option to accept string_views as input
most string utility and json APIs are changed to support string_views
(deprecated APIs left alone)
primary argument replacements:
const utility::string_t& -> utility::string_view_t
const std::string& -> utility::nstring_view_t
const std::wstring& -> utility::wstring_view_t
const utf16string& -> utf16string_view
potential client fallout when enabling option:
For clients passing char* to conversion that does not require conversion, string_view will be the result. If string type is actually required then an explicit ctor would need to be added. Otherwise client may be able to use more string_view in own code and futher reduce memory copies. See searchfile.cpp in Samples for example.
Use of foo.c_str() and &foo[0] on a potential string_view is now foo.data().
This PR also includes changes from PR #1230
To see changes with that PR as baseline review jason-ha#3.