From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-11-12 20:45:10
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