Re: [boost] [filesystem] i18n branch committed to CVS

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-06-23 09:28:02

On Thursday 09 June 2005 06:48, Beman Dawes wrote:

> >> Windows, for one.
> >
> > Could you be more specific? Which transformation done by the filesystem
> > can't
> > be approximated with the call to MultiByteToWideChar or
> > WideCharToMultiByte?
>
> It is the "approximated" that is the concern. An approximately correct path
> isn't good enough. Users expect exact rather than approximate behavior.

Well, "approximated" is a wrong word. I meant "which transformation done by 
filesystem cannot be done by appropriate API function with appropriate 
flags"? And, *please*, give some specifics. Rationale that says "on some 
operating system some transformation can't be done by user-lelve API" is too 
vague, IMO.

>
> >> Although that is really beside the point. The worry is
> >> the need for conversions when a path changes from wide to narrow, or
> >> visa versa.
> >
> > Why is it a worry?
>
> Some conversions are lossy. That is, they are not full reversible. So on
> unnecessary round trip can lose data.

Again, specifics? Not also that in single path design you need conversion only 
when mixing different path types. It won't happen on initialization, for 
example.

> > I keep on making the same argument over and over, but you don't hear it.
> > If
> > I'm writing a library, I have no idea what kind of string the
> > applications will pass to the library. And BTW, what if application's
> > requirements change
> > over time?
>
> I do very much hear that argument, and find it a very strong argument
> indeed. But I don't see that as a problem to be solved at the level of
> Boost.Filesystem.  Rather, a replacement for std::basic_string that offers
> runtime polymorthic self-configuration and interoperability. That is the
> place to start development IMO. Not in Boost.Filesystem. Boost.Filesystem
> is an innocent bystander that simply uses the std::basic_string
> compile-time polymorphism because that is the current standard.

Ok, I understand you position. The problem is boost::filesystem is something 
we can discuss, and I see chances of getting new string into standard to be 
zero. In fact, there is single-string design -- QString 
(http://doc.trolltech.com/4.0/qstring.html), and IMO, it beats std::string + 
lexical_cast + boost::format, and is rather popular. But that does not help,
because boost::filesystem can't use non-standard class and standard string is 
not going to change.

> > Well, I don't understand how to use it. Can you stetck the code code to
> > convert path to wpath and vice versa? The wpath_traits code seem to deal
> > with strings only.
>
> There is already an example of a user defined path based on strings of
> longs (which was a real-world example mentioned by someone in the LWG).
>
> I'll do another example, where the string type is std::wstring, but the
> external encoding is user supplied.

Ok.

> >> Please note that I'm not saying a single-path-type design is dumb or
> >> anything like that. It is just that it would be too big a leap without a
> >> lot of experimentation, trial use, etc.
> >
> > Then, probably it's too early to standardize boost::path. After it's in,
> > it
> > won't be possible to add yet another path type.
>
> People sometimes argue that it is premature to standardize some library
> component because a better one is just around the corner. The shared_ptr
> proposal had to fight that battle, for example. The LWG evaluates each
> proposal on its merits, as perceived at the time the proposal is
> considered. Once in a very great while, a proposal comes along that is good
> enough to cause removal of some component that was already accepted. The
> STL proposal was good enough to justify the remove of a now-forgotten
> dynamic vector called dynarray that was already voted in. If a much better
> string class comes along, well, then a filesystem library will be one of
> many libraries that will have to adapt to accommodate it.

I can only hope it's really possible.

- Volodya