On 2013/01/16 12:59, Denis Krjuchkov <de...@crazydev.net> wrote: > Well, I think this would not be significantly different from current > situation. If I'm understanding right mapper layer anyway allocates > memory for transitions between internal UTF-8 and file system > encoding. > Even if file system encoding is UTF-8. I'm just proposing change of > mapper interface from char* <-> char* to char* <-> FileName which > gives benefit in additional type system check for possible messing > between two representations. So "overhead" is really for additional > code correctness which I think is a good goal to sacrifice some > cycles.
It doubles the overhead. For something that is only necessary for one weird operating system that can't represent file names in standard strings. And no, there isn't even any additional correctness verification to justify it. You can still pass MPD's internal path names to standard I/O functions. What I suggest: use that path class for *all* file names internally. All conversions UTF-8 <-> path must be explicit (via the mapper library), and all uses for system calls must be reviewed. There is no added overhead here. Once that is complete, you can change the storage of that class from char to wchar_t for WIN32, and the compiler will help you spot the code locations that must be converted to wchar_t system calls. ------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
