/tech/ - Technology★

You just don't understand it, it's always your fault if you haven't understood every pitfall in this big beautiful language.

>>914565 (OP)

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.

>>914565 (OP)

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.

>>914565 (OP)

>>914636

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 >>914649, 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.

>>914843

>I know a lot about templates

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.

>>915046

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);
}

// later
sf::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?

>>915050

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.

>>915050

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.

>>915050

my_shape.fill_color = 0xff00ff00;

>>915043

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

>>915068

it's an example you turd.

the question is how do you pass expensive object arguments like color?

>>915100

>it's an example you turd.

Think of a better example, then, cause that one is asinine.

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 EDT
Subject: 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 - he
actually described APL as a crystal.  (For those who haven't
seen the reasoning, it was Alan's comment on why everyone
seemed to be able to add to Lisp, while APL seemed
remarkably stable: Adding to a crystal is very hard, because
you have to be consistent with all its symmetry and
structure.  In general, if you add to a crystal, you get a
mess.  On the other hand, if you add more mud to a ball of
mud, it's STILL a ball of mud.)

To me, C is like a ball.  Looked at from afar, it's nice and
smooth.  If you come closer, though, you'll see little
cracks and crazes all through it.

C++, on the other hand, is the C ball pumped full of too
much (hot) air.  The diameter has doubled, tripled, and
more.  All those little cracks and crazes have now grown
into gaping canyons.  You wonder why the thing hasn't just
exploded 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.

>>915594

>it's that guy who always copies and pastes random unix-hating C-hating retardation

>while making use of C programs and UNIX systems to view this page

You remind me of feminists.

>>914565 (OP)

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

>>915050

>But what is the best way to pass an temp object?

by rvalue reference

>>915791

The best way is actually by value because then the compiler can use RVO for the argument.

>>915886

It doesn't do what you think it does

>>915998

It invokes move semantics anon.

>>916000

std::move is actually just a cast anon.

>>916004

Its a cast over rvals which causes a move. Your user defined class move constructor will be called at this point. Yes anon, it invokes move semantics.

>>916006

So when is it a good idea to use it according to you?

>>916008

When you want to something to invoke move semantics.

>>916011

So you rather manually invoke a move instead of relying on the compiler maybe doing RVO?

>>916014

Compilers are not magic anon. Most of the time manually moving is not worth it though.