Announcement

Collapse
No announcement yet.

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

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

  • hansg
    replied
    Originally posted by mmstick View Post
    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.
    I have no idea on which basis you draw that conclusion. People who aren't using rust presumably aren't so interested in it that they want to drag it into every topic. And yes, the comment "this should be done in rust" is about as predictable as the shitstorm that accompanies a new systemd release.

    Originally posted by mmstick View Post
    This simply isn't true, and you know it.
    You need to look at some benchmarks again. C++ overtook C in terms of raw performance a long time ago.

    Originally posted by mmstick View Post
    This is purely trolling. In no way, shape, or form, could a GC language running a VM approach C/Rust.
    Actually the trolling happened when Java was introduced, and in the first few years after, when we were told again and again and again that performance was as good as C. It was never actually true, but that didn't stop Java enthousiasts from claiming it anyway - and if someone called them out on it, the 'just over the horizon' magical new compiler would change everything (same as you claimed for rust). Only problem is... it never did.

    Originally posted by mmstick View Post
    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?
    Your frantic handwaving about a purely theoretical advantage does not stack up against actual real measurements.

    Originally posted by mmstick View Post
    So you're admitting that you have one week's worth of programming experience.
    Insults are a great way to win an argument. Shows you are a deep thinker, with a firm grasp on the subject.


    Leave a comment:


  • pipe13
    replied
    coder aliases St. Dogbert
    Last edited by pipe13; 07 March 2017, 03:36 AM.

    Leave a comment:


  • coder
    replied
    Originally posted by tinko View Post
    If I would add new features to your tools in secret, that would not lower your productivity. You cannot argue that more features inherently lower productivity.
    Sorry, but I have to disagree. It adds complexity to the compilers, which results in new bugs and slower improvements elsewhere. Also, when you work in a team or with 3rd party libraries, sometimes people do things that force you to learn a new, dark corner of the language. The idea that "unused complexity is free" is a dangerous fallacy. And I say that as one of the most sophisticated C++ users I personally know. In reality, I'm most likely to be that a-hole who used a template as a parameter to another template (actually, I do that quite rarely, but you get the point).

    Not knowing Rust, I'm not against it. I'd sure hope that 30 years and a clean slate would enable a better language than C++. I just hope it was designed in totality, unlike so many recent languages that started out clean & elegant but soon bloat up with awkwardly-added features that were hastily left out of the initial spec.

    Leave a comment:


  • mmstick
    replied
    Originally posted by coder View Post
    Now, as for how you get restrict-like functionality without the keyword, the only way I see is by reducing the use of pointers. That seems like it'd come at a tradeoff, elsewhere.
    Rust achieves this by the use of the borrowing and ownership model, mutable and immutable references, lifetime annotations, and move semantics by default. This provides both safety and speed, whilst also saving memory and encouraging data-oriented designs.

    Leave a comment:


  • mmstick
    replied
    Originally posted by carewolf View Post
    No the syntax is inspired from functional languages, the idea of zero-overhead and many of the smart pointers and secure programming techniques needed together with a system near language comes from C++ since functional programing languages are usually more abstract.
    You're stating that Rust is nothing more than syntax, but you can't have syntax without features that the syntax represents -- features that are completely alien to C++. Every syntax decision in Rust has a purpose. A significant portion of Rust's features were taken functional programming languages, not C++. There's a mistake that many of your kind makes, and that's instantly assuming that Rust is like C++, so when you try to program with Rust as if it were C++, you just end up getting confused at why the Rust workflow works more like Haskell than C++. Rust is most definitely an imperative language for the functional programmer.

    Take this from someone who can write modern C++ and has mastered Rust's advanced features. C++ doesn't map 1:1 to Rust at all. Unless you have experience with a number of functional programming languages, such as Haskell, Erlang, and OCaml, you're in for an entire world of learning before you can take full advantage of Rust. You don't have ad-hoc polymorphism in the form of traits, trait generics, trait objects, and associated type constructors (aka higher-kinded types) -- Haskellers will be comfortable with these concepts though. And since when was sum types, pi types, pattern matching and bind guards features that came from C++??? Show a C++ programmer a snippet of a Rust programmer's code and they'll just be confused by Rust's features -- not something you can write off as being nothing more than syntax differences.

    Leave a comment:


  • coder
    replied
    Originally posted by mmstick View Post
    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.
    This is a valid point: C++ needs restrict! I guess the standards folks are content to let compilers implement this in a nonstandard way. IMO, they should've tried harder to keep C++ as a superset of C.

    Now, as for how you get restrict-like functionality without the keyword, the only way I see is by reducing the use of pointers. That seems like it'd come at a tradeoff, elsewhere.

    Originally posted by mmstick View Post
    vectors in C++ cannot use realloc,
    This seems like the kind of thing clever compilers can work-around. I know that some compilers will cleverly reduce code to a memset() or memcpy() call. To me, it doesn't seem like much of a leap to replace the sequence: malloc(), memcpy(), free() with realloc().

    Leave a comment:


  • ldo17
    replied
    Originally posted by Mateus Felipe View Post
    Why there's C++11, C++14 and C++17 and C is at C11 yet?
    Because complexity begets complexity.

    Leave a comment:


  • carewolf
    replied
    Originally posted by mmstick View Post

    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.
    .
    No the syntax is inspired from functional languages, the idea of zero-overhead and many of the smart pointers and secure programming techniques needed together with a system near language comes from C++ since functional programing languages are usually more abstract.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by ldo17 View Post
    Sounds like what you call an “editor” is just getting in your way. Trying to be too helpful, perhaps? Trying to do complicated GUI stuff, instead of just letting you get on with editing text?
    That's eclipse's standard behavior.

    Leave a comment:


  • Mateus Felipe
    replied
    Why there's C++11, C++14 and C++17 and C is at C11 yet?

    Leave a comment:

Working...
X