On 4.2.2015. 16:08, Niall Douglas wrote:
On 4 Feb 2015 at 14:55, Domagoj Saric wrote:
It would have to be a very borked situation if one of those didn't work.
Considering that:
1) GetTempPath() is not deprecated (which I would take to mean that the 'manufacturer of the OS' holds this function to be sufficient for 'most users')
That's a reasonable point. Apart from its hardcoded 260 char limit.
I can concede that the 260 >byte< limit is problematic (and probably a bug on MS side) and that Boost.FS can offer a workaround (for wchar_t based code) by reimplementing the officially described logic of GetTempPath()...
2) Boost.FS is already more than bloated
I certainly wouldn't call Filesystem bloated! If anything, it verges on being so lightweight as to not be sufficiently useful for many common tasks
By bloated I didn't refer to its feature set (features and options coded so that they obey the "you don't pay for it if you don't use it" rule are "power" not "bloat" in my book) more about its implementation or "binary bloat" or being the next "iostreams" when it gets into the standard :/ http://lists.boost.org/Archives/boost/2011/08/184823.php Didn't personally look at it for years, but when I did, I found it doing things like constructing std::strings out of C strings just so that it can call find_first_of() on them "for crying out loud"...It's 'careless' use of STL containers and all the inivisible EH baggage this creates, etc... With that approach C++ will never be widely accepted as the 'one true all purpose language' (e.g. would you really use iostreams, filesystem or even std::function in the kernel of 'the next great OS'?)... Note that this is especially problematic on Windows that does not have a standard prebuilt/included C++ library so most people resort to linking statically with the CRT (which with Boost.FS brings in a ton of code)...Kind of 'embarassing' that a hello world Boost.FS console program will weigh in hundreds of kilobytes...
...I would 'like' that the default implementation stays "as simple as possible but not simpler" and add a separate function or set of functions for the various special and edge cases. For example you could add a FindFile-like API that would give you a token with which it would allow you to iterate possible temp. paths until a working one is found [if the one returned in the last call isn't useable you'd call something like get_next_temp( current_temp_path_iteration_state );]...and/or you could provide the same with a container/begin-end interface...
Sounds like a recipe for racy temp file code with security holes.
Honestly, how's that? -- Domagoj Saric Software Architect www.LittleEndian.com