Announcement

Collapse
No announcement yet.

C++17 Is Near, A Look At The New Features

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

  • #21
    Originally posted by hansg View Post

    It doesn't seem to have gotten much press yet, but Microsoft now has an excellent package manager for precisely the sort of thing you ask for: https://blogs.msdn.microsoft.com/vcb...es-on-windows/
    I have tried it, requires VC 2015+. Only has a few packages upstream. glm didn't work using CMake method.
    I wonder how conan compares to it though.

    Comment


    • #22
      Originally posted by mmstick View Post

      C++ produces code that is slower than C, while Rust regularly produces code that is on par with C. By the end of the year, Rust should easily be competing against Fortran because the borrowing and ownership model allows Rust to avoid pointer aliasing by default, but this optimization is pending on the MIR compiler frontend.

      Compared to C++, Rust is able to deliver superior versions of the same features that C++ has, with less overhead, and significantly reduced chances of shooting yourself in the foot; and to do that while providing more critical features (Cargo, Rustup, Traits), and better defaults (faster vectors, move semantics, immutable by default), while heavily embracing the functional paradigm where functional programming does best. If C++ were re-created today from scratch, it would be Rust.

      In the end, you'll just end up as all other C++ programmers: fleeing from C++ to Rust because Rust offers safety, speed, and features that you could never get with C++.
      The one thing that is bad about rust is that its users just don't know when to shut up. Seriously, it seems like almost every topic on this site gets hijacked by someone asking if it wouldn't be better in rust. Maybe it would. Maybe it would't. But certainly the vast majority of programmers out there just doesn't give a flying f*ck about runner-up language-with-one-neat-feature of the day. Do you see people hijacking threads to talk about how much better everything would be in Java, or TCL, or ADA, or assembly? No? Then would you mind not dragging rust into every discussion? Because that is getting really annoying now.

      Oh, and you're wrong too. C++ does not produce code that is slower than C; it is either on par or faster. And as for your magic-unicorn-compiler: yeah, we remember that one back from the java days. Java was also faster than C... Well, almost... Any day now... When we get the new JIT... Show us the code, and then we'll talk. Preferably in a rust-specific language topic, and not one for another language. And until then I wish you good luck getting it 'as fast as Fortran' https://benchmarksgame.alioth.debian...q/fortran.html

      Now please excuse me, somebody borrowed my lexical scope and I need to get it back...

      Comment


      • #23
        Originally posted by swoorup View Post

        I think he means, using C++ features like virtual methods causing cache misses. I remember my C++ friends talking a bit more, but I can't think of anything else on top of my head.
        But virtual tables in C has the same penalty and is just more verbose and error-prone. Most large C code bases use manually implemented virtual tables where C++ would, be it the Linux kernel or GTK. C++ used to generally slower with exceptions enabled until a way was found to support exceptions with zero overhead outside of exception handling.

        Comment


        • #24
          Originally posted by carewolf View Post
          Bullshit. Everything in Rust is inspired by C++ best practices.
          It's impossible to see objectively when you're wearing C++-tinted glasses. Very little in Rust is inspired by C++ -- much of it's inspiration comes from functional programming languages, which makes a lot of sense given that the original Rust compiler was written in OCaml, not C++. Claiming otherwise is just wilful ignorance on your part.

          If you approach Rust as if it was C++, you're only going to end up confusing yourself.

          Good C++ is as fast or slightly faster than C (due to stronger aliasing rules the compiler can use)
          C features a restrict keyword which can be used to avoid aliasing as Rust achieves out of the box. C++, on the other hand, does not feature such functionality.

          because C++ use the concept of zero-overhead abstractions
          C++ doesn't go far enough with zero-overhead abstractions. There are a handful of cases where Rust's implementation of a feature has less overhead than the C++ 'zero-overhead' equivalent. In example, vectors in C++ cannot use realloc, but vectors in Rust can and do use realloc. In another example, move semantics in Rust is cheaper than the same in modern C++ when opting into move semantics, but Rust's move semantics operate entirely differently in a more efficient/practical manner. But we also can't forget that C++ has a lot of missing standard features which Rust provides out of the box.

          the very same idea inspired Rust to make a modern language that could be as fast as C++ by using the same language guidelines
          Zero-cost abstractions were not invented by C++. If you truly want to know what Rust took from C++, that would be RAII, not zero-cost abstractions. That said, RAII in Rust is more sophisticated and thus handles far more cases properly. Rust's version of RAII takes full advantage of move semantics given by the borrowing and ownership model, coupled with traits to define whether a type is `Copy` or not-`Copy`.

          starting from scratch with a modern basis and delegating the legacy stuff to foreign bindings
          Your last part here is confusing, as there is no legacy stuff, and the purposing of FFI is not for delegating legacy things. FFI is for either importing C libraries or exporting a C ABI so other software projects can link into Rust libraries.

          Comment


          • #25
            Originally posted by hansg View Post
            The one thing that is bad about rust is that its users just don't know when to shut up. Seriously, it seems like almost every topic on this site gets hijacked by someone asking if it wouldn't be better in rust. Maybe it would. Maybe it would't. But certainly the vast majority of programmers out there just doesn't give a flying f*ck about runner-up language-with-one-neat-feature of the day. Do you see people hijacking threads to talk about how much better everything would be in Java, or TCL, or ADA, or assembly? No? Then would you mind not dragging rust into every discussion? Because that is getting really annoying now.
            In case you haven't noticed, most comments that mention Rust aren't coming from it's users, but outside observers to the language. In addition, regarding Phoronix, Rust is typically brought up by detractors that are against Rust's adoption. It's rarely ever a genuine comment about rewriting something in Rust. That said, Rust is an open source language and it's adoption is driven by word of mouth. Claiming that you'd rather never see a comment about Rust is simply not a possibility. The more people talk about Rust, the better. If you don't like it, then that's your problem.

            Oh, and you're wrong too. C++ does not produce code that is slower than C; it is either on par or faster.
            This simply isn't true, and you know it.

            And as for your magic-unicorn-compiler: yeah, we remember that one back from the java days. Java was also faster than C... Well, almost... Any day now... When we get the new JIT... Show us the code, and then we'll talk. Preferably in a rust-specific language topic, and not one for another language. And until then I wish you good luck getting it 'as fast as Fortran' https://benchmarksgame.alioth.debian...q/fortran.html
            This is purely trolling. In no way, shape, or form, could a GC language running a VM approach C/Rust.

            Fortran produces faster machine code than C because it has no concept of pointer aliasing. That doesn't mean that all implementations written in Fortran will be faster than all implementations than C. How many times must it be brought up that the benchmarks game is not a reliable language comparison tool?

            Now please excuse me, somebody borrowed my lexical scope and I need to get it back...
            So you're admitting that you have one week's worth of programming experience.

            Comment


            • #26
              rust is a cool language that will once be used widely, probably, but I don't see the reason to drag it into a discussion about C++17.

              I like some features that should be present, namely ranges and structured bindings, (maybe others) but what the hell is with all that stalls when it comes to modules and concepts? I see they are pushing them strongly for C++20, hopefully not to be delayed again. Both are essential to move the developement in C++ forward.

              Comment


              • #27
                Originally posted by cj.wijtmans View Post
                there really isnt a good C++ editor out there. except for paid ones ms studio and clion.
                i didn't use clion, but vs is no match to eclipse cdt

                Comment


                • #28
                  Originally posted by Steffo View Post
                  What is wrong with Rust?
                  it's a toy. no tools, no libraries, no developers, and requires complete rewrite

                  Comment


                  • #29
                    Originally posted by M@yeulC View Post
                    I am personally tired of C++ and its constructs. They seem highly artificial and get in your way most of the time. The set of rules to remember is just enormous!
                    did you try to compare set of rules of c++ against set of rules of c, java and c#? no, otherwise you wouldn't post such bullshit
                    Originally posted by M@yeulC View Post
                    I personally prefer to use it as "C with classes" (or a well-defined subset to agree on during a project). That's probably not the best use of it, but at least the code stays understandable.
                    it means you are unable to learn
                    Originally posted by M@yeulC View Post
                    Rust ... doesn't have to carry its backwards-compatibility burden.
                    that's why nobody is using rust: noone will rewrite their code for new incompatible toy

                    Comment


                    • #30
                      Originally posted by swoorup View Post
                      Unfortunately, there is no language closer to C++. I thought D could have been the one, but it looks like they are driving away from the C++ crowd.
                      d people are working on c++ committee and bringing good stuff from d to c++

                      Comment

                      Working...
                      X