On 16 Feb 2015 at 10:44, Domagoj Saric wrote:
Not at all. Think about thin clients which have virtually no local storage, and exclusively boot from the network. They're very common in everything from schools to government.
They run Windows on these thin clients w/o virtual memory?
Of course library developers are called to make judgment calls on what's 'sane' when modeling a given system...
In the same vein, TEMP and TMP are system 'prescribed' variables which are supposed to exist. If they don't, the system is broken "and it's not really a call for Boost" to bloat everybodies binaries trying to workaround
The NT kernel has been capable of running inside a fixed memory allocation since its inception. On Windows Phone for example, the kernel has exactly 160Mb, no more, no less. "Windows for Warships" from the 1990s had a fixed memory allocation. Cash ATMs running Windows similarly so. And so on. So the answer is yes. Remember the applications available tend to be very limited, basically Office, Internet Explorer and a few proprietary apps. You certainly can't install anything, and you usually can't run more than two apps at a time. this
hypothetical situation.
As I mentioned, Win32 services are often run with no environment variables. And launching a child process on Windows using Boost.Process will more often than not unintentionally give the child an empty environment due to quirks. And what bloat is there here? A few opcodes at most. Come back to when there are megabytes of bloat, then I might care.
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...
It seems to me all that goes away if Filesystem becomes header only.
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'?)...
There are many reasons why C++ shoots itself in the foot as a systems programming language - particularly in its poor ABI management. I also greatly dislike its haughty attitude to being more friendly to system programming consumers like language runtimes where we as a community often seem to go out of out way to build ourselves C++ only ivory towers where it really wouldn't kill us to think slightly bigger, especially where the consequences on the C++ are negligible. However are any of the items you mentioned are not an issue in a next gen OS platform. My current client happens to be building a next gen OS platform, and they use all three of your items very extensively. Are these uses without problem? No, not at all ... but they are better than the alternatives. As warty as especially iostreams is, it is very well tested, behaves predictably on all platforms, and the average C++ engineer you interview doesn't need to be trained up in its use, which is a rare thing for most C++ technologies.
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...
Thankfully VS2015 finally kills off the static MSVCRT. You'll get DLLs and DLLs only from VS2015 onwards, and it's long overdue IMHO. See http://blogs.msdn.com/b/vcblog/archive/2014/06/10/the-great-crt-refact oring.aspx.
...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?
Any iterator based filesystem parser is racy by definition. Only snapshot based filesystem parsing has some chance of not being racy. My single biggest issue with Filesystem is the lack of hard guarantees for raciness. I think for each and every API guarantees need to be stated just as you would give complexity guarantees and exception guarantees. Even if the guarantee is "this API is completely useless when the filing system is changing". For the record, I'm eating my own breakfast on this, and the v1.3 AFIO release will contain a long document providing race guarantees per supported platform. I'll admit that preparing this document is very tedious. On the other hand, I've discovered a wealth of race bugs in AFIO (and POSIX) as a result, in fact last night I lodged a bug with FreeBSD as they are particularly borked due to having no way of fetching the current path of an open file descriptor (and being the only major OS not to have that). Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/