5 ms·

> POSIX certainly has its own ugly corners, but those are the exceptions. In the Windows API, elegance is the exception. Makes me wonder how seriously OP used

> POSIX certainly has its own ugly corners, but those are the exceptions. In the Windows API, elegance is the exception. Makes me wonder how seriously OP used POSIX APIs, and across how many platforms... because large parts of POSIX are pretty bad. And as an OS interface, the Windows API is clearly superior in almost every regard (if there wasn't this tiny portability issue).

jstimpfle 8y ago
I don't know what parts of Win32 you mean, but one task I did recently that should be dead simple was listing the contents of a directory. Why did I end up appending "* . *" (spaces inserted to avoid triggering HN's italic formatting) patterns to the directory name, and why do I need to find the first file with FindFirstFile() and all the remaining files with FindNextFile()? Maybe I was particularly dumb that day, but it's the best I could figure out and I don't think that's elegant.
- magicalhippo 8y ago
  > Why did I end up appending "* . *" (spaces inserted to avoid triggering HN's italic formatting) patterns to the directory name Because sometimes you just want get all the XML files in a directory, and it's nice to not have to filter yourself. > why do I need to find the first file with FindFirstFile() and all the remaining files with FindNextFile()? Why do you consider this a poor API and what would you consider a better API?
  - jstimpfle 8y ago
    Yeah, but please let me just do the filtering myself and don't force me to allocate a new string to append a silly pattern that makes me wonder if matching things without a dot in their name is supported. Yes, "sometimes" the API consumer just wants to match XML files. For example, when creating one of these silly file dialogs that never show what I'm looking for. > Why do you consider this a poor API and what would you consider a better API? POSIX gets that just right. No fuss, expose the technical reality in straightforward abstractions. You call opendir() and get an DIR* handle (representing an open directory). Then you call readdir() with that handle in a loop to get all the files in a directory. I'm not saying I'm strictly against bells and whistles, but often these only work for a first prototype, and if API designers don't offer a straightforward way so I can simply do what needs to be done, they really failed at their job.
    - magicalhippo 8y ago
      > Yeah, but please let me do the filtering just myself and don't force me to allocate a new string I will concede that I've often wondered why the file mask was not a separate parameter, so that it could be NULL if you just wanted to iterate over all the files. As for "sometimes" wanting to filter, the majority of the times I use FindFirstFile, I do with a mask different from "all entries". Guess it depends what kind of programs one writes. It certainly is a good thing that the capability is there, as it leads to consistency. But I agree it would be better if they had split the mask into a separate parameter. > POSIX gets that just right. It certainly is cleaner to separate the two. Though I've never had the need to split the code opening vs iterating, so at least for me, the practical difference is minor.
  - humblebee 8y ago
    What is the important of distinguishing between the first file and files that follow it? Why not FindFile()?
    - jstimpfle 8y ago
      Is there such a thing? What does it do? I can only find a perl implementation that seems to use FindFirstFile() / FindNextFile().
      - humblebee 8y ago
        No, it was a question. Edit: I should clarify. It was a low effort question to another low effort question. I should state that I have no experience with the API in question. I was just asking a question of the difference between the two, and the poster above me answer in another reply that the answer is that FindFirstFile is used to initialize / reset the query, where FindNextFile is use to continue the query. To further answer the question I was replying to above, I think another function that could be paired with a hypothetical FindFile would be a method to initialize the query. I do not know what would be a better API.
        jstimpfle 8y ago
        > To further answer the question I was replying to above, I think another function that could be paired with a hypothetical FindFile would be a method to initialize the query. This is the obvious and correct way to do it, and it's the way it's done in POSIX with opendir() / readdir().
    - magicalhippo 8y ago
      How would FindFile() work then? As far as I can see, either you have some separate call to initialize the find handle (just like FindFirstFile does), or you pass the directory/filename mask redundantly over and over again, introducing the potential for suddenly calling it with an already initialized find handle but with a different directory.
- RcouF1uZ4gsC 8y ago
  FindFile, FindNextFile are an iterator pattern. In C++, you have auto iterator = container.begin(); while(iterator != container.end()){ ++iterator; } In Java you have Iterator<String> iterator = container.iterator(); while(iterator.hasNext()) { iterator.next(); } Similarly with FindFile you have (leaving off some parameters) auto handle = FindFirstFile(); while(FindNextFile(handle)){} CloseFile(handle); Separating the creation of the iterator from advancing the iterator is a good thing.
  - asveikau 8y ago
    You are correct. The actual pattern you want to use in practice with this API is more of a do ... while: WIN32_FIND_DATA data; HANDLE handle; handle = FindFirstFile(str, &data); // TODO - error check do { // TODO: process "data" which is a file. } while (FindNextFile(handle, &data)); FindClose(handle); So the loop body is the same for the "first" and "next" files.
ben509 8y ago
Agreed, if you're comparing apples to apples, it should be Win32 vs. POSIX and X Window. > (if there wasn't this tiny portability issue) Win32 is impressively portable given the sheer breadth of hardware it's supporting, especially all the kiosks and displays and such that run it.

jstimpfle 8y ago

I don't know what parts of Win32 you mean, but one task I did recently that should be dead simple was listing the contents of a directory. Why did I end up appending "* . *" (spaces inserted to avoid triggering HN's italic formatting) patterns to the directory name, and why do I need to find the first file with FindFirstFile() and all the remaining files with FindNextFile()? Maybe I was particularly dumb that day, but it's the best I could figure out and I don't think that's elegant.

magicalhippo 8y ago
> Why did I end up appending "* . *" (spaces inserted to avoid triggering HN's italic formatting) patterns to the directory name Because sometimes you just want get all the XML files in a directory, and it's nice to not have to filter yourself. > why do I need to find the first file with FindFirstFile() and all the remaining files with FindNextFile()? Why do you consider this a poor API and what would you consider a better API?
- jstimpfle 8y ago
  Yeah, but please let me just do the filtering myself and don't force me to allocate a new string to append a silly pattern that makes me wonder if matching things without a dot in their name is supported. Yes, "sometimes" the API consumer just wants to match XML files. For example, when creating one of these silly file dialogs that never show what I'm looking for. > Why do you consider this a poor API and what would you consider a better API? POSIX gets that just right. No fuss, expose the technical reality in straightforward abstractions. You call opendir() and get an DIR* handle (representing an open directory). Then you call readdir() with that handle in a loop to get all the files in a directory. I'm not saying I'm strictly against bells and whistles, but often these only work for a first prototype, and if API designers don't offer a straightforward way so I can simply do what needs to be done, they really failed at their job.
  - magicalhippo 8y ago
    > Yeah, but please let me do the filtering just myself and don't force me to allocate a new string I will concede that I've often wondered why the file mask was not a separate parameter, so that it could be NULL if you just wanted to iterate over all the files. As for "sometimes" wanting to filter, the majority of the times I use FindFirstFile, I do with a mask different from "all entries". Guess it depends what kind of programs one writes. It certainly is a good thing that the capability is there, as it leads to consistency. But I agree it would be better if they had split the mask into a separate parameter. > POSIX gets that just right. It certainly is cleaner to separate the two. Though I've never had the need to split the code opening vs iterating, so at least for me, the practical difference is minor.
- humblebee 8y ago
  What is the important of distinguishing between the first file and files that follow it? Why not FindFile()?
  - jstimpfle 8y ago
    Is there such a thing? What does it do? I can only find a perl implementation that seems to use FindFirstFile() / FindNextFile().
    - humblebee 8y ago
      No, it was a question. Edit: I should clarify. It was a low effort question to another low effort question. I should state that I have no experience with the API in question. I was just asking a question of the difference between the two, and the poster above me answer in another reply that the answer is that FindFirstFile is used to initialize / reset the query, where FindNextFile is use to continue the query. To further answer the question I was replying to above, I think another function that could be paired with a hypothetical FindFile would be a method to initialize the query. I do not know what would be a better API.
      - jstimpfle 8y ago
        > To further answer the question I was replying to above, I think another function that could be paired with a hypothetical FindFile would be a method to initialize the query. This is the obvious and correct way to do it, and it's the way it's done in POSIX with opendir() / readdir().
  - magicalhippo 8y ago
    How would FindFile() work then? As far as I can see, either you have some separate call to initialize the find handle (just like FindFirstFile does), or you pass the directory/filename mask redundantly over and over again, introducing the potential for suddenly calling it with an already initialized find handle but with a different directory.
RcouF1uZ4gsC 8y ago
FindFile, FindNextFile are an iterator pattern. In C++, you have auto iterator = container.begin(); while(iterator != container.end()){ ++iterator; } In Java you have Iterator<String> iterator = container.iterator(); while(iterator.hasNext()) { iterator.next(); } Similarly with FindFile you have (leaving off some parameters) auto handle = FindFirstFile(); while(FindNextFile(handle)){} CloseFile(handle); Separating the creation of the iterator from advancing the iterator is a good thing.
- asveikau 8y ago
  You are correct. The actual pattern you want to use in practice with this API is more of a do ... while: WIN32_FIND_DATA data; HANDLE handle; handle = FindFirstFile(str, &data); // TODO - error check do { // TODO: process "data" which is a file. } while (FindNextFile(handle, &data)); FindClose(handle); So the loop body is the same for the "first" and "next" files.

ben509 8y ago

Agreed, if you're comparing apples to apples, it should be Win32 vs. POSIX and X Window. > (if there wasn't this tiny portability issue) Win32 is impressively portable given the sheer breadth of hardware it's supporting, especially all the kiosks and displays and such that run it.