16.01.2013 3:02, Max Kellermann пишет: > What I would like to have in the long run is some compile-time > verification on correct use. This is complicated enough already with > just two different "string types", and I tried adding "_utf8" / "_fs" > suffixes to variable names. Maybe some sort of C++ string wrapper > that cannot be implicitly casted to the other wrapper.
Once we have such wrapper probably using native wchar_t underneath would be easy. I actually thought you don't like TCHAR solution (based on our previous discussion some years ago). Seems I'm wrong on this. However I don't think TCHAR-based solution will require less wrappers. We'll still need some wrappers for fopen()/stat()/etc. Also we'll need to wrap functions that deal with file names but not with actual file system (i.e. glob matching, path construction and so on). > My complaint was not actually about POSIX-only code - it is ok to use > u_* wrappers on non-portable code. My complaint was that the path > name was not used consistently; one path string was passed to > u_unlink(), and the very same pointer was copied without conversion to > the sockaddr_un. Since it's impossible to use this consistently > (because there's no "wide" sockaddr_un variant), I suggest not > changing this, or adding a code comment explaining it, to aid the guy > who happens to be porting this feature to Windows one day. OK. I've got your complaint here. > Extending the decoder API would not be necessary - each decoder plugin > could implement the file_decode method and open the path_fs instead of > passing it to the external library. Well actually this what I didn't want to do. I tried to keep knowledge about wchar_t/8-bit char/UTF-8 char tricks in the smallest number of files. -- Denis ------------------------------------------------------------------------------ Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ 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_122512 _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
