Is it possible to write faster code using modern C++ with rval refs/lval refs/const...

Is it possible to write faster code using modern C++ with rval refs/lval refs/const args/std::moves/std::forwards/noexcept/std::future /std::async and everything else modern c++ has than plain old C?

C++ cannot be faster than C

Yeah whenever I'm writing C code i can actually see the ASM output in my mind, feelsgoodman

I love you.

Seriously though, C code might ((((ideally))) be lower resource heavy than C++ but practically speaking it always mean comparing bad C code to bad C++ code. Bad C code throws segway faults, bad C++ code catches errors with good exception handling.l

>Modern C++
You mean java--?
The library is so full of extra features and bloat that you might aswell use a language built with these features in mind. If you want C code, use C. If you want safer code, use java. C++ is just a shitty middleman.

Yes.

>throws segway faults
Those damn segway faults!

What kind of person creates the class dragon and then, instead of simply instantiating it, makes it an interface as well and creates a subclass that either inherits or implements dragon and instantiates that without even being sure whether you're going to extend a superclass or implement and interface?

This is what happens when you don't even bother looking up what is an UML diagram

And in respect to the question: I like C++ better than C and C#, but I generally don't work in environments where a few ms execution time matters, so I'm guessing that while C++ code might not be as fast as pure C, it still gets near enough C to be useful

>rval refs
>std::moves
At the end of the day, these are just moving a pointer around. Move constructors may improve performance over older C++, but they don't really help when compared to C.

>lval refs
Syntactic sugar over a pointer.

>const args
Shit C has just the same.

>std::forwards
This doesn't improve performance; it just means you have less code to write.

>noexcept
Everything in C is already noexcept.

>std::future /std::async
There are libraries for this shit in C.

In any case, C++ is neither slower nor faster than C. If you write the same C code in C++, you will get the same performance. If you write the same C++ code in an equivalent C (translate classes/methods to structs/functions, automatically add in constructor/destructor code everywhere, etc...), you'll get the same performance. C++ has so many features and is used by so many companies that it is hard to say if there is any such thing as idiomatic C++. Most of the language features are compile time, so using them won't impact performance of your application at all. What will impact performance is the use of some of the standard library features, which generally add more than one needs for the sake of flexibility. You can choose to use an std::string if you want, or you can use a regular old char*. Or you can use an entirely different string. The question becomes, "between performance and development time, which is more important for my use case?"

> What kind of person creates the class dragon and then, instead of simply instantiating it, makes it an interface as well and creates a subclass that either inherits or implements dragon and instantiates that without even being sure whether you're going to extend a superclass or implement and interface?

Java programmers.

>segway faults
lel

>Bad C code throws segway faults, bad C++ code catches errors with good exception handling.
You can use exception handling with C-style code in C++. Performance is always going to be better with simple, low-level data structures than with complex, do-everything data structures that provide more functionality than your program needs.

C++ is basically C with most common design patterns baked in.

Just remember that rval/move semantics are really just stealing heap pointer ownership and that you probably aren't really making an über-special tweaked system if you're doing a shit-ton of dynamic allocation anyway.

future/async is still really at the toy stage, and you're usually better off manually laying out thread tasks at a coarser level.

If C had proper templates (not macro shit), function overloading, orderless compilation, operator overloading (not that important, though tobh) and modules - all of which are perfectly reasonable - then I would use it in a heartbeat. Its just too old, tobh. But seriously, someone needs to add just those features to C because it would make it a truly awesome(r) language if they did.

>rval refs/lval refs/const args/std::moves/std::forwards/noexcept/std::future /std::async

Thank you for reminding me why I hate C++ these days.

It's like filling out bureaucratic forms in triplicate because they have to account for every incompetent programmer who doesn't know how to write synchronized, leak-free code.

Ugh. So disgusting.

>operator overloading

Operator overloading is the single dumbest feature of C++. The only time it's useful is for writing silly, academic, cutesy examples, like a special math class. Meanwhile, you introduce potentially *wildly confusing* possibilities. Like the entire stupid overload of left-shift for cutesy stream output.

Christ, there was a good decade or so of CS101 students who faced the likes of "cout

Yeah that's why I said its not important. Its nice to just say something like
vector_x*2 + vector_y*3
Instead of
vector_x.times(2).plus(vector_y.times(3))
But I totally agree its not really that important and can really fuck your shit up if you use it too much

>oop is too complicated for my tiny brain to understand so C is superior!

How to spot NEETs who have never worked on a project with multiple people.

More like how to spot NEETs (and professional SE's) who have never worked on a large project.

I worked with some "data scientist" snobs who were always shit-talking C++ as if the rest of us were drag-n-dropping functionality. Meanwhile, all they had to do was write cleanly packaged spam detection algorithms (literally an init, compute_spam_rank, and de_init) with zero support for multithreading, no communication with anything other than our own servers, no calling 3rd party code (when they finally tried it they introduced a massive leak), and no module over a couple thousand lines.

You are just too dumb to make use of operator overloading
:^)

>implying I'm too dumb to make use of operator overloading

I don't think user was implying anything. I think he was explicitly stating an opinion.

But you sure showed user!

Java is completely incomparable to C++ because it needs a VM runtime to execute

C++ is dying. It will stick around for quite a while in AAA gamedev, but outside of that, Rust (for lower level and/or sans runtime code) and Swift (for more typical higher level application code) are far superior.

It is not the responsibility of the language to catch errors, it is the responsibility of the programmers to git gud.

/thread

Probably not but you will probably be writing safer and more maintainable code if you aren't a fucktard.

There are some features that are faster than their C equivalents, but their usage is rare.

>UML diagram
Only people in school uses UML to actually represent a codebase in development. It's useful to explain concepts at the prototyping stage and when writing software development books. But keeping a 1:1 representation of a code base in development? No you are doing it wrong.

Examples of this, pls.

/thread
>hey kid, wanna buy some Boost spirit?

Memory leakage has not really been the big issue with C++ since the introduction of tools like valgrind. What has been the major cause of software bugs is the implicit casting and undefined behaviour that goes on in the standard.

Like it fucking matters for your project.

>magic
That is the biggest problem with C++. Too much magic and ambiguity allows poor coders to create a nightmare.

What I found after a quick search:

void pointers vs templates (stuff about aliasing)
having precalculated stuff vs not (because C can't into turing complete templates)
qsort vs std::sort (something about inlining)

>Memory leakage has not really been the big issue with C++ since the introduction of tools like valgrind.
Unfortunately most non-trivial software uses libraries that leak by themself...

For example, an Allegro hello world has no less than 6 leaks, according to valgrind. And given the average quality of SDL they are most likely not better.

Memory leaks are still not often the problem. A leaking C++ program is probably never going to even come close to a similar implementation in Java in memory usage during the programs running time. Because if it did the implementer would detect it and have to find an alternative strategy or use another lib.

What's dangerous is the magic in C++. You can for example deallocate something and keep using it for an eternity because nothing else will write to that memory region and it works fine. Then out of the blue sky it crashes and you have no fucking idea why it crashed. Or the classic implicit conversion between signed and unsigned integers in an if statement with value that never will be reached.

You clearly don't know what /thread means, newfags pls go and stay go

I clearly now what it means, cease discussion and kys.

While java isn't great, java programmers have always been worse. But since they sculpt the ecosystem, the whole thing just degenerates

Function overloading is overrated too. Generic functions with parametric polymorphism solves the problem when it should and if it can't you should probably have different names.

Being able to use operator overloading effectively wasn't the topic of this thread

Doesn't matter. Anything of importance has been said until then.

anything with polymorphism
anything with generics

unsigned and signed makes me shudder,
finding such bugs are a pain.

Not true. C++ compilers can do more optimizations at a program scale that could be faster than the equivalent written in C. C will perform the same or better if you're just doing a single function benchmark or something, though.

>Rust (for lower level and/or sans runtime code) and Swift (for more typical higher level application code) are far superior.
ever heard of legacy?
IBM supports 40 year old code on modern systems because people don't like changing shit. You don't get to reinvent IP or Ethernet for example. Even if your invention is vastly superior nobody is going to replace millions of routers. Changing a language is of course much easier, but there's still plenty of friction. There's a similiar situation with Scala and Java and Java certainly isn't dying anytime soon.
>according to valgrind
valgrind can have false positives, i'm curious as to how many of these are actual leaks

This is an old meme.

You can't be faster than a static binary (aka C) vs when you are calling in/out of a runtime (aka C++).

STL is also slow as sin vs any sanely programmed C equivalent due to the sheer amount of checking and templating going on in the C++ runtime.

>templating going on in the C++ runtime.
What? If you don't know what you are talking about stop pulling "facts" from your ass. Specialisations of templates are created at compile time.

This is the stupidest most uninformed post I've seen all day.
Fucking kill yourself.