[Request for comments] wil::unique_string about wil HOT 7 CLOSED

Anything that has a dependency on the STL needs to be relatively isolated. This is especially true when taking a dependency on newer STL features (I don't recall exactly which STL versions are used in the Windows build, but anything newer than C++11 generally requires caution). So as its own standalone thing, likely in a separate header that nothing else depends on is probably fine. That is, if the value added is worth having yet another string type.

from wil.

This is where std::string_view comes in, at least for C++17 users. It's a non-owning string type, so it allows to write functions that accept many string types without the need to be templated. Obviously would need to be properly checked for availability before being used.

void print(std::wstring_view text)
{
    std::wcout << text;
}

print(L"foo"); // ok

const std::wstring str(L"bar");
print(str); // ok

const auto costr = wil::make_cotaskmem_string(L"baz");
print(costr); // would also be ok

from wil.

string_view is awesome, so if we can make wil work well with it that would be valuable.

from wil.

I do see one issue with my approach: some APIs don't allow you to pass the address of a size type and instead leave the caller figuring out the size by using strlen or some other method, effectively making bounds-check ineffective or wrong on unique_array_ptr because the internal size isn't updated.

This could probably be worked around by adding a function to update the internal size based on the string's length (determined by the null-terminating character), but that function would need to be manually called after the fact. Another possible option is to use a proxy struct, not unlike size_address_ptr, that would automatically recompute the length once it's destroyed. It would require explicitely calling a function with another name (put_with_length()?) since we can't overload on return types only, and that proxy struct's behavior may not always be desired, like in the cases where a function does accept a pointer for the string size, in case there's embedded nulls.

Some also return the length of the string I believe, but this would already be workable with

*str.size_address() = LoadMyString(str.put());

As a sidenote, wil::str_raw_ptr and wil::details::string_maker would also need to be updated for unique_string.

from wil.

the problem of needing to re-size strings leads to a few known bugs for string types that use a length value instead of the nul terminator. HSTRING and std::wstring for example (these types support embedded nulls, a rarely useful and in some uses not allowed). this manifests in incorrectly formed strings but often we don't suffer as the consumers take the nul terminated view.

there are cases where std::wstring::size() is out of sync with the length determined by the nul terminator (this OS bug).

As you said, this is exacerbated by some Win32 APIs that won't tell you the size up front before you allocate, you need to over-allocate, then get the value and at that point you know the size. RegQueryValue for REG_SZ that may or may not be null terminated (we need to add a flag to that API to tame this behavior).

to address this we need to make the wil types have a .resize() but this has to be optional as HSTRING does not support it.

perhaps using if constexp on tag types like Kenny does in C++ WinRT to enable an optional reset() (and block use of forms that don't in APIs that don't support it).

from wil.

one more thing, <wil/stl.h> can be used for STL specific stuff

from wil.

Dropped the idea, this proved too complex and would probably not cover all use cases. It's easier to just use the right string length call manually to then drop it in a wstring_view and do all the manipulation using that.

from wil.