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

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]