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
> >> 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
> > 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.
> >> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk