Hacker News Reader

Comment by azov | Hacker News Reader

ifstream is very, very limited. Shocking as it is, there's still no standard and portable way in C++ to do very basic filesystem operations, like list files in a directory - you have to use platform APIs or third-party portability libraries.

Seems like C++17 finally resolves this. We only had to wait 34 years :)

View on HN

That's because C started as a language rather than a platform. You have always needed to marry it to POSIX or Win32 or whatever to do anything useful. Now with various proposals like 2D graphics, C++11 threads etc. it looks like they are moving in the portable platform direction.

Yes, I know. We had this "C runs on systems that don't even have disk" excuse for so long it's became a cultural thing.

I'm not sure where to draw the distinction between a language and a platform and I don't think I care. Those additions will make C++ way more useful, libraries will become more composable, binaries smaller, and life will be easier for 99.9% of people who use C++. So, I'm glad they finally dropped the lowest common denominator approach - we've been making our own batteries for way too long.

I think it's more of a philosophy than an excuse. I'd say it's only in the Java era that people have started expecting their language to have "batteries included." Big ships like C/C++ turn slowly, but it does seem to be turning that direction. Whether that's better than the community defaulting to boost libs, I don't know.

You're right about changing expectations, but it is better. Really. Too many people view boost as a giant cumbersome blob of libraries interconnected in unintuitive ways and refuse to use it, especially if they only need something that they perceive as small and simple.

We've been through the same exact arguments years ago, only then it was about things like std::string. Oh, no, it allocates dynamic memory behind the scenes - there are systems that don't even have heap! As a relic from that era some popular libraries still use their own string classes.

I've been using Qt for years to do this. I have my fingers crossed I can finally use the standard libraries.

Well it is basically an almost-copy of Boost.Filesystem which you can use today, can you not?

Boost requires compiling libraries ahead of time and linking them in, so to do that on top of Qt would be asking a lot for very little gain. If filesystem was a header only library I don't think it would be as much of an issue.

I assume that in the long run Qt will relinquish this to standard libraries, so QFile will basically be a convenience wrapper around std::file integrated with Qt's concurrency model.

Well, boost::filesystem exists for ages...

But how many million lines of header files do you need to pull in to use it?

Probably as many millions of lines the C++ standard will use, since its based on boost::filesystem.

A lot of these proposals and the changes in C++ this decade have just been standardizing slightly modified versions of Boost libraries.

>Probably as many millions of lines the C++ standard will use, since its based on boost::filesystem.

Not necessarily. A lot of boost contains workarounds for compilers that don't support certain features. Since the standard library will be expected to be used with a known compiler (or at least a new-ish compiler), it doesn't need workarounds for missing C++11 support, etc.

The biggest problem with Boost isn't simply the number of headers - it's maintaining the built libraries against your compiler.

"Let's upgrade to MSVC 2015!"

"Oh nuts, our code now links against msvcrtp13.dll and our built boost_filesystem.dll still links against msvcrtp12.dll. Time to rebuild all of our libraries!"

This is especially bad on Windows where MS's dev tools team just didn't 'get' that developers just don't care about new CRT optimizations if it means rebuilding all of our 3rd party libraries. But even on OSX there's been the whole libstdc++/libc++ pain.

Anything that can get folded into the standard library and maintained by the same jokers who rev msvcrt*.dll every couple of years (rub their noses in their own mess) is good.

Reply on news.ycombinator.com