On 2013/01/16 11:42, Denis Krjuchkov <de...@crazydev.net> wrote: > Some bonus thoughts: > > What if we start from different side and implement a wrapper (i.e. > class FileName) that encapsulates actual file name string (no matter > how it is stored internally)?
What kind of path name would this class represent - MPD's internal path names (always narrow), or the external OS path names (sometimes wide)? Finding a good representation for strings is perhaps one of the most difficult things in C++, at least when you want to avoid overhead (and C++ is extremely good at giving you ways to avoid overhead, something which is not possible in higher-level languages): 1) a pointer to a C string (const char *) 2) an dynamically allocated buffer (e.g. std::string) 3) a fixed-size buffer (e.g. char[PATH_MAX]) Each of these has problems of its own. For example, (1) often cannot be used because somebody else needs to manage the memory pointed to. (2) can be a lot of overhead for the allocator. (3) is very fast, but wastes memory. I think this needs to be designed carefully, because I don't want MPD to grow into a bloated beast. Maybe we need to implement two (or all three?) of the above? > This would require more effort, because there are other functions > that deal with file names directly. For example composing path from > multiple components. As far a I understand currently it's > implemented via GLib routines. Since we're anyway migrating from it > such reimplementation would be required anyway (some code might be > directly imported from GLib I think). The GLib functions are not terribly sophisticated, they are merely a convenience. Having a class that has well-defined methods for path manipulation would be even more convenient. ------------------------------------------------------------------------------ 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
