While passing by value was considered shit prior to C++11 it's now okay?
Consider the following:
[coode]
void foo(HeavyObject obj) {
consume_heavy_object(obj);
}
[/code]
The compiler will move the argument instead of copying it, correct?
Why is modern C++ such a clusterfuck?
Another example of fuckiness:
HeavyObject foo() { return HeavyObject{};}int main() { // URVO kicks in HeavyObject obj = foo(); // no RVO because lol HeavyObject obj2{}; obj = foo();}
You just don't understand it, it's always your fault if you haven't understood every pitfall in this big beautiful language.
Old code is written without copy elision, so it will stay okay.
New code is written with copy elision in mind when working with modern compilers.
Those who do not use modern compilers can use the old way, which continues to work.
Homegamers have full control and can choose what they do and the industry has the same choice, if they switch to modern compilers then they will very likely stay with it.
Etc.
There is no problem here, but I'm sorry that you have all that melanin and or jew gene bullshit in your body that makes you retarded.
Huh, I never knew this was a thing. Although I get the feeling that C++ has a lot of weird optimizations and quirks; I don't use it enough to really know.
C++ is made complex and bloated on purpose. Stroustrup wants to add everything to please committees and industry giants. The problem is that the fads of this year is going to be added to C++. When a project coded in C++ becomes large/old enough, the danger is that it will contain every meme feature and trick. Or perhaps Stroustrup is true patriot and he made a language that niggers cant simply learn
Like , I don't understand the complaint about C++ bloat, not because it's not bloated, but because you don't have to use or even understand things you don't use.
I wrote quite a lot of C++ code (around 80k lines) but I never bothered to learn much about copy elision because it never came up. I did have to learn about above move/copy/assign/etc semantics just to use smart pointers properly, but once I knew that, that's all I needed. I also know almost nothing about threading. But I know a lot about templates. You learn what you need to and each individual part of the language is manageable in complexity.
If you just don't like the complexity because it bothers you, or you think there's a tiny chance it could affect you, that's fine, but it's basically an aesthetic preference. If you prefer to code in C for your own hobby projects, that's a fine choice, but you can't complain that businesses use C++ when it gets the job done better.
Can you explain the CRTP so a mortal can understand it?
compiler will optimise moving big objects as arguments, which is nice, but it's still some work, passing a pointer is almost always faster. But retards are afraid of pointers and people don't care about the perfomance.
The whole point is how you pass arguments that are consumed.
If you just call a function from an object that you pass in then a reference is the best option, not a pointer.
But what is the best way to pass an temp object?
void set_color(sf::Shape shape, sf::Color color) { shape.setFillColor(color);}// latersf::Shape my_shape{};set_color(my_shape, sf::Color(0xff00ff00));
What is the most efficient way to pass the color object? Do you move from it? Do you hope the compiler moves it on its own?
at home, anything that is bigger than say 4 ints I pass as pointer (I don't like references, they hide that what you pass is in fact a pointer), at work, I do whatever the reviewer wants which is often passing or returning big objects like it doesn't matter because it's less code and nobody cares about overhead like that. I do but I try not to to not lose sanity, I code my way at home.
Why are you duplicating functionality?
The shape already has a method to set the fill color and the function is void, too.
The compiler probably just removes all of that and replaces it with a direct call, especially since you're giving the color a constant value.
The compiler very likely will go through the chain of operations/functions/methods and will compute the results and put that into the shape thing directly.
my_shape.fill_color = 0xff00ff00;
It's just a way to use a class's own name as a template parameter. E.g. you need to add some boiletplate functions to class C that involve its own type, so you make it inherit from Boilerplate.
it's an example you turd.
the question is how do you pass expensive object arguments like color?
Hey kids, did you know RVO can happen when you don't return things?
What will this output?
class BigObject {public: BigObject() { cout
ctor
dtor
FUCK OFF HERB
Think of a better example, then, cause that one is asinine.
c poos poos vary dificult!
C sucks, so adding to C amplifies the ways C sucks. All of the flaws and mistakes of C become bigger problems without fixing the problems C already had.
As DLW says, "C++ is the C of object oriented programming languages."
Subject: Re: Smalltalk Versus C++ (No Flame Wars, Please!)In some article RH writes:> A core dump is C++'s way of "delaying the objection until> run-time"Putting it another way: `Method not found' is Smalltalk's way of spelling `core dumped'
Date: Mon, 1 Jun 92 21:16:22 EDTSubject: Re: Imagery Continuing in the Unix mail tradition of adding tangential remarks,Likewise, I've always thought that if Lisp were a ball of mud, and APL a diamond, that C++ was a roll of razor wire.That comparison of Lisp and APL is due to Alan Perlis - heactually described APL as a crystal. (For those who haven'tseen the reasoning, it was Alan's comment on why everyoneseemed to be able to add to Lisp, while APL seemedremarkably stable: Adding to a crystal is very hard, becauseyou have to be consistent with all its symmetry andstructure. In general, if you add to a crystal, you get amess. On the other hand, if you add more mud to a ball ofmud, it's STILL a ball of mud.)To me, C is like a ball. Looked at from afar, it's nice andsmooth. If you come closer, though, you'll see littlecracks and crazes all through it.C++, on the other hand, is the C ball pumped full of toomuch (hot) air. The diameter has doubled, tripled, andmore. All those little cracks and crazes have now growninto gaping canyons. You wonder why the thing hasn't justexploded and blown away.BTW, Alan Perlis was at various times heard to say that(C|Unix) had set back the state of computer science by(10|15) years.
You remind me of feminists.
You plainly don't know what you're talking about.
If you want to move a param, then just choose to move it, otherwise copy it. And RVO works as appropriate if you have a move assignment operator crafted for you "Muh_heavy_strawman_foo_obj". And if you want to use uniform initialization, then simply construct in place with the initializer list form of the Heavy_obj constructor, don't create it then copy it dumbass.
TBH, you sound exactly the same some retarded atheist does setting up a strawman against the evidence then claiming it's some kind of 'fact'.
holy shit you're retarded
by rvalue reference
The best way is actually by value because then the compiler can use RVO for the argument.
I guess std::move does not do anything then right user
It doesn't do what you think it does
It invokes move semantics user.
std::move is actually just a cast user.
Its a cast over rvals which causes a move. Your user defined class move constructor will be called at this point. Yes user, it invokes move semantics.
So when is it a good idea to use it according to you?
When you want to something to invoke move semantics.
So you rather manually invoke a move instead of relying on the compiler maybe doing RVO?
Compilers are not magic user. Most of the time manually moving is not worth it though.