Walter Landry <[EMAIL PROTECTED]> writes: > David Abrahams <[EMAIL PROTECTED]> wrote: >> Walter Landry <[EMAIL PROTECTED]> writes: >> >> > Brian Gray <[EMAIL PROTECTED]> wrote: >> >> Should we (do we?) have some spreadsheet enumerating various filesystem >> >> features, quirks, and limitations for whatever systems we can find, and >> >> using that as a reference regarding how to organize features like >> >> paths, file references, forks, or whatever else? It might help us to >> >> back out of the code and re-examine the problem domain regardless of >> >> the current state of Boost. >> > >> > I've been thinking that maybe the best way to provide for portable >> > paths is to have a bunch of flags that you can set. So when you push >> > something onto Beman's singleton stack, you can, for example, set the >> > NTFS and VMS flags if you only care about those filesystems. >> > >> > However, that makes it difficult to extend to customized portability >> > restrictions. That might require some kind of function stack within >> > each element of the singleton stack. Then you can push the NTFS and >> > VMS checkers onto that stack within the stack. >> >> I _really_ hope we don't have any singleton stack which affects path >> validation. It sounds like a nightmare for any application involving >> threads. > > I think I finally understand what the problems with multiple threads > are. You are worried that one thread's portability checking will be > changed midstream by another thead. Sounds hairy. So one solution is > to make the portability checking local to a thread. I don't have a > feel for how to implement that
You'd need TLS, IIUC a limited resource that I wouldn't want to spend on this. > and it does seem to introduce complexity where it isn't always > needed. Absolutely; IMO the whole issue of "portable" representations and portability checking needs to be rethought in the context of use cases. I do believe there's a satisfactory simple approach in there somewhere. -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
