3 ms·
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 thin
by 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.