Abdelrazak Younes wrote: > I plan to first encapsulate the conversion to/from ascii inside each of > the filetools functions. Then I will look at how boost::filesystem can > handle unicode, if at all possible... > > I am tempted to convert everything even when a std::string would > suffice. For example getFormatFromContents(), should that be: > > lyx::docstring const getFormatFromContents(lyx::docstring const & name); > > or > > std::string const getFormatFromContents(lyx::docstring const & name);
I prefer the latter. I really like to have a clear distinction between data that can be in unicode and data that is ASCII. format names are currently ASCII so getFormatFromContents should only be changed to return docstring if at the same time all code that deals with format names is also changed. > I guess the format name could stay with std::string but this would not > bring a big performance advantage. The first solution (docstring has the > advantage that it looks nicer and we won't need to convert that to > docstring if we need to display that format name somewhere. Performance is not the most important thing in this case IMO. The most important thing is code that is easy to understand. > What do you think? You will be tempted to do another cleanup ;-) We all know that our current treating fo filenames is bad. All filenames should be stored in a special filename class that deals with all filename aspects, not a string of whatever kind. That class would of course make heavy use of boost::filesystem internally. Things like makeAbsPath would go completely, and replaced by a member of the filename class. Angus made a start with the FileName class already, but it is not finished. So IMO you have two options: - convert all filenames to docstring, but don't change the existing design - Do the big thing and implement proper handling of filenames. Georg
