Re: _wstat on Windows (actually stat stuff in general)

[Kean Johnston <kean johnston gmail com>]

> Do you have a use case where hash-table lookups would be a bottleneck?
Small mobile devices. Devices with only 64MB of RAM to play with. Embedded 
devices. Just because GLib is used mainly in GNOME don't make the 
assumption its the ONLY place. Not every deployment of GLib applications is 
on a multi-core CPU system with multi-gigs of memory, or even with 
traditional hard disks. Or even hard disks at all. Places where you are 
using GLib becuase its relatively small, not using the massive overhead 
that is GIO and which serves a different purpose entirely. Just becuase 
GLib and GIO come in the same tar does NOT mean they are always deployed 
side by side.

> With dual-core CPUs we have nowadays, disk access is likely to be much
> slower than the hash-table work that GIO produces. And few programs
> would need to stat that many files anyway.
Really? On what do you base that information? There are three applications 
I want to write that even brought me to the GLib / Gtk+ world and ALL of 
them use stat because they are dealing with files. The bottom line is, 
although stat may be a low level system call, applications deal with files. 
A LOT. A HELL of a lot. stat is a basic file operation. It can be made to 
be more portable. That's all I am trying to do. It can abstract 95% of all 
of the problem areas. If you have an application that needs very specific, 
tied-to-one-OS stat structures then by all means use stat. But when a 
*Platform* library isn't abstracting a basic *platform* call, that's a 
problem and I don't understand all the resistance to it.