Add wil::println() - C++23's std::println() but for HANDLEs

[fredemmott]

e.g (needs C++20):

void println(
  HANDLE handle,
  std::format_string<Args...> format,
  Args&&... args) {
  const auto buffer = std::format(format, std::forward<Args>(args)...) + '\n';
  DWORD bytesWritten = {};
  while (bytesWritten < buffer.size()) {
    const auto remaining = buffer.size() - bytesWritten;
    DWORD bytesWrittenThisBatch {};
    const auto result = WriteFile(
      handle,
      buffer.data() + bytesWritten,
      remaining,
      &bytesWrittenThisBatch,
      nullptr);
    if (!SUCCEEDED(result)) {
      throw std::system_error(result, std::system_category());
    }
    bytesWritten += bytesWrittenThisBatch;
  }
}

Would also probably want a wchar version taking an std::wformat_string

[sylveon]

Is this required considering you can get a FILE* from a HANDLE and then use it with the normal std::print?

[fredemmott]

If you're talking about _open_osfhandle():

The _open_osfhandle call transfers ownership of the Win32 file handle to the file descriptor. To close a file opened by using _open_osfhandle, call _close. The underlying OS file handle is also closed by a call to _close. Don't call the Win32 function CloseHandle on the original handle.

This is a pretty significant limitation; is there another way?

[fredemmott]

I guess that can be used with DuplicateHandle(), but there's unintuitive semantics there - for example, are the write cursors kept in sync?

[sylveon]

Ah good point wrt ownership.

Another concern was every write allocating a string. The + '\n' in particular concerns me because we might do a full copy of the string just to add that newline. Perhaps we could use format_to with an iterator that did buffering using a stack array? But then it would negate some performance fast paths in std::format. Might be worth benchmarking different solutions before setting on one.