3 ms·

I've had to work with api functions like https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-enumchildwindows https://learn.microsoft.com/en-

I've had to work with api functions like https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-enumchildwindows https://learn.microsoft.com/en-us/windows/win32/api/winuser/... and friends. It was by far the most unpleasant api I've ever worked with.

frabert 2y ago
I think that particular pattern is a perfectly reasonable way to let the user ingest an arbitrarily long list of objects without having to do any preallocations -- or indeed, any allocations at all.
- mananaysiempre 2y ago
  Yes, but the inversion of control is unpleasant to deal with—compare Find{First,Next}File which don’t require that.
  - wongarsu 2y ago
    Which is a pattern that also exists in the Win32 API, for example in the handle = CreateToolhelp32Snapshot(), Thread32First(handle, out), while Thread32Next(handle, out) API for iterating over a process's threads. I also find EnumChildWindows pretty wacky. It's not too bad to use, but it's a weird pattern and a pattern that Windows has also moved away from since XP. https://learn.microsoft.com/en-us/windows/win32/toolhelp/traversing-the-thread-list https://learn.microsoft.com/en-us/windows/win32/toolhelp/tra...
- wruza 2y ago
  Because allocating well under a hundred handles is a biggest problem we have. WinAPI is awful to work with for reasons above anyone’s comprehension. It’s just legacy riding on legacy, with initial legacy made by someone 50% following stupid patterns from the previous 8/16 bit decade and 50% high on mushrooms. The first thing you do with WinAPI is abstracting it tf away from your face.