There's a function in shlwapi (windows, of course) called PathCanonicalize, which parses "." and ".." parts of a path, could that turn out to be useful for filesystem_traits?

Nice idea. I've got something similar in the Synesis libs that I did many years ago, and have been meaning to bring it into STLSoft for yonks.

Actually, it's slightly different (and perhaps slightly better) in that it - called deriverelativepath() - can deduce a relative path between any two paths (and handles different drives on Win32). Internally, it does all that canonicalisation stuff, so I guess the best thing would be to split out the UNIX and Win32 implementations, and then split them into the canonicalise and the derive-relative-path functionality

I don't think it should live in the filesystem_traits, since it's a bit heavyweight. I'd probably have separate headers unixstl_/winstl_filesystem_functions, or some such.

I'll try and get it into 1.8.3, or soon after.

Cheers

-- 
Matthew Wilson

Author: "Imperfect C++", Addison-Wesley, 2004
    (http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (http://www.synesis.com.au/articles.html#columns)
STLSoft moderator
    (http://www.stlsoft.org)

"But if less is more, think how much more more will be!" -- Dr Frazier Crane

------------------------------------------------------------------------
-------



"Pablo Aguilar" <paguilarg@hotmail.com> wrote in message news:cl1fl6$17sg$1@digitaldaemon.com...
> There's a function in shlwapi (windows, of course) called
PathCanonicalize,
> which parses "." and ".." parts of a path, could that turn out to be
useful
> for filesystem_traits?
>
>

Great!

Actually, the original idea behind this suggestion, was precisely determining the relative path between two files...

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:clhcqr$dma$1@digitaldaemon.com...
> Nice idea. I've got something similar in the Synesis libs that I did many years ago, and have been meaning to bring it into STLSoft for yonks.
>
> Actually, it's slightly different (and perhaps slightly better) in that it - called deriverelativepath() - can deduce a relative path between any two paths (and handles different drives on Win32). Internally, it does all that canonicalisation stuff, so I guess the best thing would be to split out the UNIX and Win32 implementations, and then split them into the canonicalise and the derive-relative-path functionality
>
> I don't think it should live in the filesystem_traits, since it's a bit heavyweight. I'd probably have separate headers unixstl_/winstl_filesystem_functions, or some such.
>
> I'll try and get it into 1.8.3, or soon after.
>
> Cheers
>
> -- 
> Matthew Wilson
>
> Author: "Imperfect C++", Addison-Wesley, 2004
>    (http://www.imperfectcplusplus.com)
> Contributing editor, C/C++ Users Journal
>    (http://www.synesis.com.au/articles.html#columns)
> STLSoft moderator
>    (http://www.stlsoft.org)
>
> "But if less is more, think how much more more will be!" -- Dr Frazier Crane

The path classes in UNIXSTL and WinSTL now have implementations of their canonicalise() methods, which do this.

"Pablo Aguilar" <paguilarg@hotmail.com> wrote in message news:cl1fl6$17sg$1@digitaldaemon.com...
> There's a function in shlwapi (windows, of course) called PathCanonicalize, which parses "." and ".." parts of a path, could that turn out to be useful for filesystem_traits?
>