At 07:11 PM 11/12/2004, Peter Dimov wrote:
Beman Dawes wrote:
At 01:54 PM 11/12/2004, Peter Dimov wrote:
Beman Dawes wrote:
A single path class approach is really interesting. Note, however, that it is a good bit more complicated than your synopsis above because of the need to provide templated member functions to handle user defined types.
Is there _really_ such a need?
That's a good question. I personally think the need for UDT support is too marginal to worry about.
The interesting thing is that I can see a need for a generic path library
(filesystem-independent). It even makes perfect sense for this library to be
templated on the character type (because the operations do not depend on a specific type) and if I squint just right I see some benefits in adding a
'class Tr = path_traits<Ch>' parameter that will supply the path separator character and the escape character (if any).
However I don't see how such a generic path library can be separated from
the filesystem code. The generic grammar is simply not expressive enough to handle all native path quirks.
That's correct. For example, it doesn't have an escape mechanism to represent '/' in an element name. At least so far, no one has come up with any practical cases where that is a problem. --Beman