Announcement

Collapse
No announcement yet.

GCC Lands Support For C++ File-System TS

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • GCC Lands Support For C++ File-System TS

    Phoronix: GCC Lands Support For C++ File-System TS

    The GNU Compiler Collection (GCC) today merged their initial support for the C++17 file-system technical specification!..

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    No experimental namespace anymore? No need to link c++fs anymore? Yay!

    Comment


    • #3
      It seems to assume a posix filesystems. I guess the interesting thing will be how well it will work on Windows and macOS.

      Also they should decide on a function style, they have so many:

      void copy(const path& from, const path& to);
      void copy(const path& from, const path& to, error_code& ec) noexcept;

      bool copy_file(const path& from, const path& to);
      bool copy_file(const path& from, const path& to, error_code& ec) noexcept;

      void copy_symlink(const path& existing_symlink, const path& new_symlink);
      void copy_symlink(const path& existing_symlink, const path& new_symlink, error_code& ec) noexcept;

      So "fail by exception" (ugh), "fail by bool", "fail by error_code", and "fail by bool and error_code" (and possibly also "fail by both bool and exception" (???), however that makes sense?)

      Also why three different copy functions? I could understand a directory one would be special, but it seems the other way, and why is copy_symlink separate if it doesn't have options on how to transform the path (to the same file, or to a similar file in the same relative location)?

      Finally the permission_mask is a the old school unix/posix permissions, without any ACL, Windows or macOS support...

      They are great people in the commitee, so I trust them to fix all issues, but this needs a bit of work.
      Last edited by carewolf; 23 October 2017, 12:01 PM.

      Comment


      • #4
        filesystem ts was optional
        filesystem in c++17 is mandatory
        filesystem ts was in <experimental/filesystem> header and std::experimental::filesystem namespace
        c++17 filesystem is in <filesystem> header and std::filesystem namespace
        there are some minor differences

        this means title and part of article body is incorrect

        Comment


        • #5
          Originally posted by carewolf View Post
          It seems to assume a posix filesystems
          not really
          Originally posted by carewolf View Post
          . I guess the interesting thing will be how well it will work on Windows and macOS.
          it was designed with windows in mind from the start, macos is unix
          Originally posted by carewolf View Post
          Also they should decide on a function style, they have so many:

          void copy(const path& from, const path& to);
          void copy(const path& from, const path& to, error_code& ec) noexcept;

          bool copy_file(const path& from, const path& to);
          bool copy_file(const path& from, const path& to, error_code& ec) noexcept;

          void copy_symlink(const path& existing_symlink, const path& new_symlink);
          void copy_symlink(const path& existing_symlink, const path& new_symlink, error_code& ec) noexcept;

          So "fail by exception" (ugh), "fail by bool", "fail by error_code", and "fail by bool and error_code" (and possibly also "fail by both bool and exception" (???), however that makes sense?)
          obviously that does not make sense because that is your fantasy instead of reality
          it has only two variants of error reporting - via exception or via error_code
          bool result of copy_file is not variant(all copy_file have bool result, which means whether it made copy or not - it can skip copy even without failing)
          and obviously "they" can'd decide for you whether you prefer error reporting via exception or error_code. sometimes one is better choice, sometimes other.
          Originally posted by carewolf View Post
          Also why three different copy functions? I could understand a directory one would be special, but it seems the other way, and why is copy_symlink separate if it doesn't have options on how to transform the path (to the same file, or to a similar file in the same relative location)?
          because they have different semantics. copy can do many things like cp, it can copy recursively or to to/from.name(). when it does copy, it invokes copy_file
          copy_file does simple one file copy, copy_symlink does what its name says. why don't you go to cppreference and read?
          Originally posted by carewolf View Post
          Finally the permission_mask is a the old school unix/posix permissions, without any ACL, Windows or macOS support...
          there is no santa to do standardization for you. everything has to be done by someone. so in the beginning you have no filesystem support at all, and next step adds some support

          Comment


          • #6
            Will it work on paths with invalid unicode?

            QString doesn't, which is why KDE programs typically fail at this.

            ---Edit---

            At least boost-filesystem seems fine:

            Code:
            #include <boost/filesystem.hpp>
            #include <iostream>
            
            int main()
            {
                boost::filesystem::path roger("\xE5");
                roger /= "\xF6";
                std::cout << roger.string() << '\n';
                return 0;
            }
            Last edited by andreano; 23 October 2017, 02:01 PM.

            Comment


            • #7
              Originally posted by carewolf View Post
              It seems to assume a posix filesystems. I guess the interesting thing will be how well it will work on Windows and macOS.
              ...

              Finally the permission_mask is a the old school unix/posix permissions, without any ACL, Windows or macOS support...

              They are great people in the commitee, so I trust them to fix all issues, but this needs a bit of work.
              Completely agree with you. There was threads about that on isocpp.org some time ago, but it seems things didn't really changed

              Comment


              • #8
                Originally posted by pal666 View Post
                not really
                it was designed with windows in mind from the start, macos is unix
                Well. except for the file system which is not POSIX. So for the relevance of this article, it isn't.

                Comment


                • #9
                  Originally posted by andreano View Post
                  Will it work on paths with invalid unicode?

                  QString doesn't, which is why KDE programs typically fail at this.

                  ---Edit---

                  At least boost-filesystem seems fine:

                  Code:
                  #include <boost/filesystem.hpp>
                  #include <iostream>
                  
                  int main()
                  {
                  boost::filesystem::path roger("\xE5");
                  roger /= "\xF6";
                  std::cout << roger.string() << '\n';
                  return 0;
                  }
                  The problem is that if you handled paths unencoded, you will have trouble doing case-insensitive name lookups, since that requires codec awareness. Qt can do that, but then has trouble with stuff that is wrongly encoded. Which is why it is relevant how they handle case-insensitive file lookups. Both macOS and Windows CAN do case-sensitive files, but usually doesn't, and not doing the same as native applications would not be nice and make the standard much less relevant.

                  Comment


                  • #10
                    <trolling>
                    I read stuff like this and I am glad I switched to C#. I would like to say that C++ has done a good job at making itself irrelevant, but I just posted an image binarization library to github recently and I chose C++ purely for performance reasons. Great, its fast... but it can't even read in a PNG without a third party library. One of C++'s recent accomplishments is providing a standard threading api... "ain't nobody got time for that." While the C++ standards committee tries to fresh the language into something that looks like an old, gimped version of C#, I thinks its probably best to just jump into the future, today, and use the real deal. Congrats getting a standardized filesystem api.
                    </trolling>

                    Comment

                    Working...
                    X