18.01.2013 20:51, Max Kellermann пишет: > > I have improved and pushed my Path patch. I guess there's still a lot > of room for improvement. You are welcome to work towards using > wchar_t for Path::value_type on Windows. >
Good. Here is my plan: 1) Further push usage of Path class instead of raw pointers 2) Introduce wrappers for low-level file system APIs: open(), fopen(), stat() and so on. Likely we'll something like PathBuffer to wrap `char buffer[MPD_MAX_PATH]` for functions such as readlink(). Also g_file_test() is extensively used in the code, probably I could re-implement it at this stage because we're anyway migrating from GLib. 3) Once everything uses our wrappers Path implementation finally could be changed to wchar_t. However some questions arise: 0) What's the better names for wrappers: probably the simplest way is to use the same names but put them to separate namespace (i.e. FS::open(), FS::stat()), but what if those functions are defined as macros? stat() is likely to be dependent on _FILE_OFFSET_BITS. Will it hurt our definitions? 1) There would be still some additional copying on Windows for external libraries that expect char* path names. Since there are many of them some reusable way of such conversion need to be implemented. 2) What about command line and configuration file encoding? For the moment those are assumed to be in FS encoding if I'm understanding right. I would keep them as such on POSIX platforms. On Windows there are some options. For command line it's possible to migrate to wchar_t-aware wmain() which would eventually convert its arguments to UTF-8. This would allow usage of existing command line parsing code and code that opens configuration file could construct Path instance by using Path::FromUTF8() method (on POSIX it would be Path::FromFS()). I think the same could be done for reading paths from configuration file. On POSIX those would be still in FS encoding, but on Windows configuration file would have to be stored in UTF-8. This introduces breaking change because in previous version it was assumed to be in 8-bit ANSI encoding. I think such breakage is tolerable for the benefits it gives. P.S. some bonus thoughts on identifier naming style: This is very subjective I know, but I'd prefer to avoid STL-ism such as empty() or c_str(). I understand that you've used such names to give people who read the code some well-known and expected interface. But on the other side it makes the whole code look inconsistent. IsEmpty()/CStr() doesn't seem less clear naming for STL-aware reader, but it preserves consistency. What do you think? -- Denis ------------------------------------------------------------------------------ Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
