Announcement

Collapse
No announcement yet.

GCC Developers Look At Transitioning Their Codebase To C++11

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

  • #21
    Originally posted by Vistaus View Post
    With so many people disliking using the latest and greatest (in this case C++20) for coding, instead using older versions for a while longer, I wonder if anybody even uses the latest and greatest?
    The readers here tend to come from server-side companies which are very slow at adopting anything. If you switch to a game forum you'll see different opinions.

    Comment


    • #22
      Originally posted by AsuMagic View Post
      [insert "modern code" here
      This didn't compile on my RHEL 6 compiler (-std only goes up to 11). This is still our main server target unfortunately.

      It also didn't compile on the clang provided with our version of UE4 (4.9 I believe). We use an older version because the project started quite a while ago. It finishes in another year .

      I don't believe it compiles on our codeplay compiler either. The focus on this compiler is not for latest standards but for parallelization.

      Its basically not practical (for another 5 years).

      Edit: It did work on Emscripten. Horray!

      As for the actual code... Honestly the first one actually is easier to read. Breaking the logic up into sections is something I like to actively pursue. The 3rd one was OK. Middle one was horrid.
      Last edited by kpedersen; 30 September 2019, 01:14 PM.

      Comment


      • #23
        Originally posted by Vistaus View Post
        With so many people disliking using the latest and greatest (in this case C++20) for coding, instead using older versions for a while longer, I wonder if anybody even uses the latest and greatest?
        I have no idea for most of them, but I am pretty sure that Microsoft tend to keep up with standards quite well (AFAIK, they are already using modules in production from what I know - the module proposal is partly designed by them). Google might be as well IIRC. No idea about the rest...
        But if IBM complained about trigraphs removal for C++17, I suppose they care at least a bit.

        Comment


        • #24
          Originally posted by cl333r View Post

          Something's wrong with the like system, I hit like a few hours ago but currently it shows zero likes and the "unlike" option. Can't post a screenshot because phoronix doesn't accept uploading images to it and too lazy to use an uploading service.
          I have come across this bug as well. It seems that Cloudflare is caching the page, or that the forum has a "like cache".

          Comment


          • #25
            Originally posted by Vistaus View Post

            Companies must not like you very much lol
            Why? Too short or too long?

            Comment


            • #26
              Originally posted by kpedersen View Post

              This didn't compile on my RHEL 6 compiler (-std only goes up to 11). This is still our main server target unfortunately.

              It also didn't compile on the clang provided with our version of UE4 (4.9 I believe). We use an older version because the project started quite a while ago. It finishes in another year .

              I don't believe it compiles on our codeplay compiler either. The focus on this compiler is not for latest standards but for parallelization.

              Its basically not practical (for another 5 years).

              Edit: It did work on Emscripten. Horray!

              As for the actual code... Honestly the first one actually is easier to read. Breaking the logic up into sections is something I like to actively pursue. The 3rd one was OK. Middle one was horrid.
              Yes, I'm quite aware of codebases not being recent enough. And that's a fine reason to not use newer revisions. It is also fine when very high portability is needed.

              I disagree about the 1st one being better. 2nd one might lead to a long line but you can always store the lambda in a const auto variable before the sort call if it bothers you that much. I know it does not bother me. Having to scroll up to find how the sort is actually performed contributes to spaghetti code IMO.
              Either way, this is still much better than the standalone function because that comparison function literally only has a single statement.

              Another (artificial) example, which might be a more striking usecase of lambdas to me:
              Code:
              struct StudentFilterComparator
              {
                  int score_threshold;
               
                  bool operator()(const Student& student) const
                  {
                      return student.score < score_threshold;
                  }
              };
               
              void foo(int thresh)
              {
                  // Some more code around here...
               
                  StudentFilterComparator comp;
                  comp.score_threshold = thresh;
                  const std::vector<Student>::const_iterator it = std::remove_if(students.begin(), students.end(), comp);
                  students.erase(it, students.end());
              }
              I don't think there's much of a way to shorten this further. It might be if you abstract StudentFilterComparator as a generic template, but this adds complexity and is not really as flexible.

              Compare to C++20:
              Code:
              void foo(int thresh)
              {
                  // ... Stuff ...
              
                  std::erase_if(students, [thresh](const Student& student) {
                      return student.score <= thresh;
                  });
              }
              You can reimplement erase_if in C++11 fine, but you're not getting away that easily with the functor.
              This is just much much easier to think about IMHO.
              Last edited by AsuMagic; 30 September 2019, 01:58 PM.

              Comment


              • #27
                Originally posted by AsuMagic View Post
                Manual memory allocations are essentially always a terrible idea.
                Most of the time you can do the job with unique_ptr and it will neatly manage the lifetime of the held object.
                Seriously, if it's anything, it's not laziness. There are so much use-after-free bugs and memory leaks in the real world that could have been avoided with smart pointers.
                Exactly. This is why I prefer C++ over C. No longer have to deal that much with memory allocation.

                Originally posted by AsuMagic View Post
                Threading is a pain in the ass without C++11. Most people used Boost threading or just directly used pthread or win32 threading.
                The former is a massive dependency, the latter is a portability issue, and it's not any nice to work with.
                I mostly agree. C++ has the easiest threading library ever.

                Originally posted by AsuMagic View Post
                Even on the simplest stuff C++03 is annoying: No initializer lists, the stupid > > syntax rule, being unable to call a parent constructor or inherit from them...
                "> >"? What is that? Pipes? The operator you use with cout or cin?

                Originally posted by AsuMagic View Post
                For-range loops are a godsent. Seriously. How can you not prefer this
                Code:
                for (const auto& [key, value] : my_container)
                {
                // use key and value
                }
                over this?
                Code:
                for (std::map<MyKey, MyValue>::const_iterator it = my_container.begin(); it != m_container.end(); ++it)
                {
                // use it->first and it->second
                }
                And that's just an irrealistic example. In practice it's even more annoying to have a jungle of it->first and it->second within a line. It doesn't make anything less readable.
                This. I use it a lot and makes my code much more readable than ::iterator.
                Although I never knew you could initialize several variables in the for loop, Python style?

                Also, is it possible to access the associated iterator using the for (type i: var) {} syntax? Will come in handy when having to erase stuff in arrays.

                Originally posted by AsuMagic View Post
                I don't want to have to pull a separate library to deal with something as basic as time. Say what you want about <chrono>, but it does what I want to and does that pretty well.
                I don't use chrono. Instead I use a custom C++ wrapper to struct timespec.

                Originally posted by AsuMagic View Post
                Move semantics are great. It actually makes RAII bearable in many instances where it wasn't.
                I don't want to free up resources manually much like I don't want to have to deal with memory allocations manually.
                What?

                Originally posted by AsuMagic View Post
                Lambdas, again, are a godsent. Why do you prefer, say
                Code:
                void my_comparison_function(const Something& a, const Something& b) const
                {
                return a.foo < b.foo;
                }
                
                void some_function()
                {
                // Possibly lots of code that makes my_comparison_function much further separated
                std::sort(some_container.begin(), some_container.end(), my_comparison_function);
                }
                over this?
                Code:
                std::sort(some_container.begin(), some_container.end(), [](const Something& a, const Something& b) {
                return a.foo < b.foo
                });
                or soon, even this?
                Code:
                std::ranges::sort(some_container, [](const Something& a, const Something& b) {
                return a.foo < b.foo
                });
                I never understood how to use λ's...

                Originally posted by AsuMagic View Post
                auto is not only useful for "laziness". It is very convenient for metaprogramming, and allows avoiding needless verbosity or workarounds. With if constexpr too, you can make so much code more maintainable and readable without having to parse dozens of lines of SFINAE bullshit.
                I agree. Analog to JavaScript's var.

                Originally posted by AsuMagic View Post
                constexpr is just really convenient. Unfortunately IMO it does not go as extensive as I want it to be, but it is going to improve a fair bit in C++20 and probably in other future standards. I find it comparable to Haskell's purity concept in a very good way.
                constexpr? I never knew about that.
                There are many C++ features I have never used...

                Originally posted by AsuMagic View Post
                I take std::array so much for granted that I forgot that it was not a thing in C++03. Seriously, if you still are willingly using C-style arrays in 2019, I just don't ever want to have to deal with your code. I never ever found any reason not to use that other than pure masochism.
                I only use C arrays for fixed-size ones or when I really desire speed. Otherwise I use std::vector

                Originally posted by AsuMagic View Post
                Moving forward, modules are going to be one hell of an upgrade. I don't know about you but I'm not exactly a fan of having to micro-optimize declarations and definitions between .cpp and .hpp files by fear of bumping up compile time. And there is so much more that makes includes a PITA.
                Yes, compile time had been an increasing problem in newer standards because the standard library grew and allowed constructs that were a bit heavier on the compiler, but this is absolutely going to be a thing of the past.
                ...modules? Is this a replacement to libraries, or something like Java packages?
                Last edited by tildearrow; 30 September 2019, 03:05 PM.

                Comment


                • #28
                  Originally posted by tildearrow View Post

                  Why? Too short or too long?
                  'Cause companies like very, very old software. A 5 year old C++ version isn't old enough for them

                  Comment


                  • #29
                    Originally posted by Vistaus View Post

                    Companies must not like you very much lol
                    That is what all big companies use. Proven industry standards that work across all compilers so they are not tied to specific crap. The most adventurous companies might go as far as using 3-year old standards, but that is mostly Google, and results are not pretty.

                    Comment


                    • #30
                      Originally posted by tildearrow View Post
                      "> >"? What is that? Pipes? The operator you use with cout or cin?
                      No. It's something you take so much for granted today, but back in C++03 you were not allowed to write say std::vector<std::vector<int>> (dumb example of course), because you had to insert a space between two consecutive > when defining template parameters.

                      Originally posted by tildearrow View Post
                      This. I use it a lot and makes my code much more readable than ::iterator.
                      Although I never knew you could initialize several variables in the for loop, Python style?
                      C++17 structured bindings

                      Originally posted by tildearrow View Post
                      Also, is it possible to access the associated iterator using the for (type i: var) {} syntax? Will come in handy when having to erase stuff in arrays.
                      Unfortunately not. You could still use auto to kill off some of the heavy syntax but that's it.
                      This would not work anyway in the usecase you provide, because of iterator invalidation (assuming you would get a read-only view to the iterator, which IMO would be the safest).

                      Originally posted by tildearrow View Post
                      What?
                      "What" for move semantics or "What" for RAII?

                      RAII is about, in a way, associating the lifetime of an object to the resource it holds.
                      This is what happens for instance:
                      • for std::vector, std::list, std::unique_ptr etc.: The managed resource is the underlying dynamically allocated memory. You never actually have to care about deallocation because the lifetime of the object defines the lifetime of the resource.
                      • for std::fstream: The underlying file handle is closed when the object is destroyed. Forgetting to close a handle can have annoying consequences as you would expect.

                      Move semantics is the std::move and rvalue reference stuff (&&). It allows indicating the transfer of a resource from someplace to another.
                      For instance:
                      Code:
                      std::vector a{1, 2, 3};
                      std::vector b{std::move(a)};
                      In this example, there is no copy involved. The contents of a are moved to b using the move constructor, and a is emptied.
                      It is part of why std::unique_ptr works so well: You can safely move the dynamically allocated data it handles through move semantics. So you have to try very very hard with std::unique_ptr to cause a memory leak.

                      It's not as simple as that so you might want to look it up, but it is pretty useful.

                      Originally posted by tildearrow View Post
                      I never understood how to use λ's...
                      For basic usage they are fairly straightforward to use, but they can involve quite a bit of C++ features.
                      A lambda function is sort of the instantiation of an anonymous class you can use as a functor.
                      I think Jason Turner on YouTube has made a few videos to introduce people to them and explain how they work, so you could be interested. I know for sure he has talked a lot about them.
                      C++ weekly is great in general.

                      Originally posted by tildearrow View Post
                      constexpr? I never knew about that.
                      It allows defining functions that can be called at compile-time and constants that are truly compile-time evaluated.
                      constexpr functions have a lot of (unnecessary) restrictions, but they are progressively getting lifted away.
                      It is quite worthwhile to know about them. At their simplest level, they allow you to define compile time constants so you don't have to deal with macros.

                      Originally posted by tildearrow View Post
                      I only use C arrays for fixed-size ones or when I really desire speed. Otherwise I use std::vector
                      Well, std::array encapsulates C arrays and is a zero-cost abstraction. They provide an interface similar to that of std::vector, but of course appropriate for a static automatically allocated array, like a C array is.
                      Its size is determined by a template parameter. Unlike C arrays, you can pass them and return them from functions safely.

                      Originally posted by tildearrow View Post
                      ...modules? Is this a replacement to libraries, or something like Java packages?
                      Something like Java packages, for C++20. They are intended to replace includes, but they will not be mandatory.
                      They promise some advantages you can look up too. Performance is actually a side effect of module design, but it's not 100% sure whether it will make an improvement in the real world once the implementations have matured. Wait & see.

                      Comment

                      Working...
                      X