Is it possible to write faster code using modern C++ with rval

C++ cannot be faster than C

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

>>57467662
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

>>57467630
>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.

>>57467630
Yes.

>>57467923
>throws segway faults
Those damn segway faults!

>>57467630
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?"

>>57470207
> 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.

>>57467923
>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.

>>57467630
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.

>>57467630
>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.

>>57470777
>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 << "Hello, world!" << endl;" and were told to just not worry about what it meant. Teaching people to quietly ignore "magic" when learning to program is the worst thing you can do.

>>57470835
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.

>>57470896

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.

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

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

>>57472159
I don't think anon was implying anything. I think he was explicitly stating an opinion.

But you sure showed anon!

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

>>57467630
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.

File: 1322531676570.png (414KB, 600x732px) Image search: [Google]

414KB, 600x732px

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

>>57470962
/thread

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

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

>>57470207
>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.

>>57475584
Examples of this, pls.

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

>>57470814
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.

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

>>57475627
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)

>>57475663
>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.

>>57475761
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.

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

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

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

>>57470777
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.

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

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

>>57467630
anything with polymorphism
anything with generics

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

>>57467634
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.

>>57474927
>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.
>>57475761
>according to valgrind
valgrind can have false positives, i'm curious as to how many of these are actual leaks

File: 1447830078388s.jpg (8KB, 229x250px) Image search: [Google]

8KB, 229x250px

>>57478518

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.

>>57482767
>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.

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