7 ms·

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

by azov 11y ago

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 :)

lettergram 11y ago
I've been using Qt for years to do this. I have my fingers crossed I can finally use the standard libraries.
- sbmassey 11y ago
  Well it is basically an almost-copy of Boost.Filesystem which you can use today, can you not?
  - CyberDildonics 11y ago
    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.
- pzone 11y ago
  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.
richard_todd 11y ago
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.
- azov 11y ago
  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.
  - richard_todd 11y ago
    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.
    - azov 11y ago
      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.
meetingcpp 11y ago
Well, boost::filesystem exists for ages...
- vvanders 11y ago
  But how many million lines of header files do you need to pull in to use it?
  - zanny 11y ago
    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.
    - sseagull 11y ago
      >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.
  - CountSessine 11y ago
    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.

by azov 11y ago

lettergram 11y ago

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

sbmassey 11y ago
Well it is basically an almost-copy of Boost.Filesystem which you can use today, can you not?
- CyberDildonics 11y ago
  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.
pzone 11y ago
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.

richard_todd 11y ago

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.

azov 11y ago
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.
- richard_todd 11y ago
  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.
  - azov 11y ago
    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.

meetingcpp 11y ago

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

vvanders 11y ago
But how many million lines of header files do you need to pull in to use it?
- zanny 11y ago
  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.
  - sseagull 11y ago
    >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.
- CountSessine 11y ago
  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.