I am finding that the joys of "str.Replace('\\', '/')" are wearing rather
thin. I don't want to type it, and I don't want to read it.
TSVN is *stuffed* with path manipulation code - this is partly because
there is a genuine difficulty with the need to handle paths in at least
three forms on the UNICODE build and, I think, partly because at the outset
no-one realised what a pain that was going to be, and so paths have been
handled as adhoc strings.
There is lots of evidence that people are often not quite sure what type of
path a function might be called with, so re-run things like
str.Replace('\\', '/') just in case they're needed. There are some
general 'preparePath' sort of functions, but they're not used everywhere,
and I suspect they would cause a perf problem if they were.
I would like to propose that we (that's me) added a class, called something
like CTSVNPath, or CTSVNFilename.
This would encapsulate a path, and would be able to return a number of
different forms of path - Windows API compatible, SVN compatible, SVN
compatible, etc. I would take the appropriate steps to maintain
performance, probably by holding multiple copies of the pathname in
different forms, as required. There would also be accessor functions to
get the name and the extension of the path, and to find out if the path
represented a file or a directory.
If we wanted to do highly optimised path compare functions, this would also
be the place to do it.
We would (eventually) store *all* path strings in this class, converting to
and from API-compliant types (TCHAR*, char*) only at the boundaries of APIs.
The main thing I think we would get from this class would be code
simplification, and hopefully an increase in robustness. I think there
*might* be some small perf benefit, but that's not certain. The amount of
memory used storing paths would almost certainly increase, but I don't
think that's a big deal.
What do people think?
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Dec 22 09:53:00 2004