16.01.2013 19:00, Max Kellermann пишет: > First you map UTF-8 to filesystem path (e.g. via map_uri_fs()), which > duplicates the string. Then for conversion to your path class (for > passing to a system call), std::string duplicates the string again. > Makes two allocations instead of one, even on sane operating systems.
OK. This doubles the copying. But what if we don't adopt std::string and use custom memory management? This would allow transfer of ownership of allocated string from character conversion routine to our wrapper. I think this still gives some protection because it would be clearly noticeable if such string is going to be combined with char* string which might have other encoding. Don't you agree? > The protocol doesn't have path names. There are these "file://" URIs > but they are not "real" path names, even though they technically > represent ones. Therefore, protocol strings shall be char* or > something based on it. char* shall always be UTF-8. I think this matches with what I'm trying to propose: treat path names as opaque value which real structure is known only to some limited low-level facilities. And assume that every char* you see is always UTF-8. > In any case, you need some glue that selects narrow or wide system > calls. You can't avoid that, can you? Agree, it seems that some wrappers would be required in all mentioned possible implementation. -- Denis ------------------------------------------------------------------------------ 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
