Abdelrazak Younes wrote: > Georg Baum wrote: >> Feel free to do so (after 1.5.0 I suggest), but then you have to do it in >> a lot of places, including using the wide version of boost::filesystem. > > I've tried that once (during the big Unicode saga if you remember) and > it was not funny. I gave up at the end, it's probably easier now... dunno.
Some parts of it are not needed anymore, but using the wide version of boost::filesystem would not be easier I guess. >> That >> wide version does not work on unix (because there is no wstring API to >> access the filesystem in unix), > > Could you clarify please? AFAIR wstring is defined on Unix and it is > basically typedef docstring. Last time I tried it worked. There are two problems: 1) wstring has different sizes on different OSes (2 byte on windows, 4 or 2 byte on different unices), so different conversion functions would be needed 2) boost::filesystem::wpath uses wstring on windows, but string on unices. That eliminates problem 1), but creates another one. So if we would use boost::filesystem::wpath we either would need to wrap it completely, or introduce a lot of #ifdef in all places where we use it, because we would need different conversions. On unix we don't have a choice but to use the current mechanism that translates to the local encoding using strings, not wstrings. >> so you will have to wrap it somehow. It is >> possible to use unicode filenames on windows, but a lot of work which I >> am not willing to do now, especially since the benefit will be very small >> AFAIK: GetLongPathNameA will use the local code page, so you are only > > GetLongPathNameW you mean... No, I mean GetLongPathNameA. As I understand it GetLongPathNameA is passed a string in the local code page. It converts that to utf16, gets the corresponding long file name from the file system and converts the result back to the local code page and returns it. The other ..A functions do similar conversions. >> struck if e.g. you want to use hebrew filenames in a german windows, but >> hebrew filenames in a hebrew windows will work. > > I am not sure of that. Windows > Me/98/95 uses utf16 at the filesystem > level. Sure, but as I understand it the ..A functions will do the proper conversion from the local code page to the file system storage. >> I designed >> the FileName class in such a way that both would be possible with little >> effort. As you can see from the other responses we don't have anzy >> consensus here, and I am personally not sure at all what the best >> solution is. > > My pragmatic side would say "go for QFile" because boost::fs using > wstring is not easy... on the other end but it is aimed to be a standard. > > Personally I vote for QFile because of portability issues that we might > encounter with boost::fs. One reason to use boost::fs is that QFile does more than we want: It encapsulates whole files, including state (open, closed, access rights, input/output streams etc.), but in most cases we don't want that, we only need a safe way to pass a file name around and do some manipulations on it. Because of this we could hit a performance problem if we use QFile. As I said: I honestly have no idea what is better here. Georg
