On 2013/01/18 18:57, Denis Krjuchkov <de...@crazydev.net> wrote: > 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().
Yes, why not. OTOH, we could pass "Path&" to our readlink() wrapper, and let the wrapper copy the result into the object. Or make it return a "Path". That would be most convenient to use. Adds some overhead, but acceptable for me. > 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. Right. And give them better names: maybe IsRegularFile() or so. > 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? Let's give them better names, to avoid namespace collisions with system macros. OpenFile(), StatFile() etc. > 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()). Command-line arguments are filesystem encoding, that's right, because I assumed that filesystem encoding was the same as the user's terminal encoding (think about tab completion). But converting them to UTF-8 as early as possible would be a good idea to make the code simple. We can assume that we can convert UTF-8 to Path without loss, in case we need it. > 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. Configuration file is always assumed to be UTF-8. Command-line is different because the encoding is defined by somebody else; for files, it's up to us to define the encoding. > 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? I often try to imitate the STL naming, not because I like it (I don't, not at all!), but to allow exchanging container classes more easily. But yes, agree, we could give them better names. ------------------------------------------------------------------------------ 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
