Friendly reminder that you should return reference to an object

no shit sherlock

File: 1491014298407.png (1008KB, 1920x1080px) Image search: [Google]

1008KB, 1920x1080px

>>62343371
But anon, you should return reference to an object iff:
1. The object itself is passed to the scope as a non-const reference
2. If the object is created within the function scope, it is static
3. In no other situation

Reminder that you don't also need multi-return functions, create the expected values first and pass them as non-cost references into the function. These are called out params.

>>62343379
i did read your post before replying
now continue dumping your animegirl folder pls

File: 5eb.jpg (193KB, 1112x978px) Image search: [Google]

193KB, 1112x978px

>>62343390
Yes but you should return reference to an object iff:
1. The object itself is passed to the scope as a non-const reference
2. If the object is created within the function scope, it is static
3. In no other situation

Reminder that you don't also need multi-return functions, create the expected values first and pass them as non-cost references into the function. These are called out params.

>>62343405
yeah that's the stuff

File: oshietekudasai.jpg (106KB, 1280x720px) Image search: [Google]

106KB, 1280x720px

>>62343360
Now tell me all bout r-value references because that shit is confusing and I understand nothing.

File: 1486700538771.png (511KB, 836x964px) Image search: [Google]

511KB, 836x964px

>>62343422
Despite having the word “value” in their names, l-values and r-values are actually not properties of values, but rather, properties of expressions.

Every expression in C++ has two properties: a type (which is used for type checking), and a value category (which is used for certain kinds of syntax checking, such as whether the result of the expression can be assigned to). In C++03 and earlier, l-values and r-values were the only two value categories available.

The actual definition of which expressions are l-values and which are r-values is surprisingly complicated, so we’ll take a simplified view of the subject that will largely suffice for our purposes.

It’s simplest to think of an l-value (also called a locator value) as a function or an object (or an expression that evaluates to a function or object). All l-values have assigned memory addresses.

When l-values were originally defined, they were defined as “values that are suitable to be on the left-hand side of an assignment expression”. However, later, the const keyword was added to the language, and l-values were split into two sub-categories: modifiable l-values, which can be changed, and non-modifiable l-values, which are const.

It’s simplest to think of an r-value as “everything that is not an l-value”. This notably includes literals (e.g. 5), temporary values (e.g. x+1), and anonymous objects (e.g. Fraction(5, 2)). r-values are typically evaluated for their values, have expression scope, and cannot be assigned to. This non-assignment rule makes sense, because assigning a value applies a side-effect to the object. Since r-values have expression scope, if we were to assign a value to an r-value, then the r-value would either go out of scope before we had a chance to use the assigned value in the next expression (which makes the assignment useless) or we’d have to use a variable with a side effect applied more than once in an expression.

File: 1498308662629.jpg (274KB, 721x887px) Image search: [Google]

274KB, 721x887px

>>62343442
C++11 adds a new type of reference called an r-value reference. An r-value reference is a reference that is designed to be initialized with an r-value (only). While an l-value reference is created using a single ampersand, an r-value reference is created using a double ampersand:

    
int x = 5;
int &lref = x; // l-value reference initialized with l-value x
int &&rref = 5; // r-value reference initialized with r-value 5

R-value references have two properties that are useful. First, r-value references extend the lifespan of the object they are initialized with to the lifespan of the r-value reference. l-value references to const objects can do this too, but it’s far more useful for r-value references since r-values have expression scope otherwise. Second, non-const r-value references allow you to modify the r-value!
R-value references are more often used as function parameters. This is most useful for function overloads when you want to have different behavior for l-value and r-value arguments.

    
void fun(const int &lref) // l-value arguments will select this function
{
    std::cout << "l-value reference to const\n";
}
 
void fun(int &&rref) // r-value argument will select this function
{
    std::cout << "r-value reference\n";
}
 
int main()
{
    int x = 5;
    fun(x); // l-value argument calls l-value version of function
    fun(5); // r-value argument calls r-value version of function
 
    return 0;
}

You should almost never return an r-value reference, for the same reason you should almost never return an l-value reference. In most cases, you’ll end up returning a hanging reference when the referenced object goes out of scope at the end of the function.

>>62343471
>>62343442
http://www.learncpp.com/cpp-tutorial/15-2-rvalue-references/
Why are you dumping learncpp articles? If anyone wanted to know this they can just find it out for themselves.

File: 1477286674675.png (463KB, 743x720px) Image search: [Google]

463KB, 743x720px

>>62343501
But anon! You fail to understand thatyou should return reference to an object iff:
1. The object itself is passed to the scope as a non-const reference
2. If the object is created within the function scope, it is static
3. In no other situation

Reminder that you don't also need multi-return functions, create the expected values first and pass them as non-cost references into the function. These are called out params.

>>62343516
Yeah I know the unique IPs didn't increase, I should have whipped out my phone to make that comment like you did when that "other anon" asked about r-values.

But anyway anon, you didn't answer my question: why are you dumping learncpp articles? If anyone wanted to know this they can just find it out for themselves.

File: 1491014298907.png (576KB, 531x720px) Image search: [Google]

576KB, 531x720px

>>62343539
You see the problem is, you should return reference to an object iff:
1. The object itself is passed to the scope as a non-const reference
2. If the object is created within the function scope, it is static
3. In no other situation

Reminder that you don't also need multi-return functions, create the expected values first and pass them as non-cost references into the function. These are called out params.

>>62343576
Quality. but I'm still wondering why are you dumping learncpp articles? If anyone wanted to know this they can just find it out for themselves.

File: 21370964.jpg (31KB, 475x731px) Image search: [Google]

31KB, 475x731px

>>62343590
Because you should return reference to an object iff:
1. The object itself is passed to the scope as a non-const reference
2. If the object is created within the function scope, it is static
3. In no other situation

Reminder that you don't also need multi-return functions, create the expected values first and pass them as non-cost references into the function. These are called out params.

>>62343610
You could at least try posting the other articles that are on there instead of being some kind of spamming faggot, it's really not a good look for you anon.
Here, try this one: http://www.learncpp.com/cpp-tutorial/15-3-move-constructors-and-move-assignment/
But I'm still wondering why are you dumping learncpp articles? If anyone wanted to know this they can just find it out for themselves.

>>62343442
>>62343471
Very nice, anon.

I am certainly not going to outdo this explanation, but perhaps I can add a tl;dr that summarizes, yet slightly simplifies the key points.

tl;dr: An R-value reference is a reference to an object that is going to die as soon as you are done looking at it.

Why is that useful? Because, if you were going to make a COPY of that object, you can save processing time by MOVING the data instead. The object is going to die anyway, so you might as well steal the data from underneath it. What point is there copying a bunch of data and then throwing away the original, amirite?

So let's say my function --a constructor is a typical example of such a function-- is going to make a copy of a large vector. In old-timey C++, I would take a const reference to the vector as a parameter, then copy it.

In C++11, I can make an optimized version of that function that takes an R-value reference instead. This is a *non-const* reference to a vector that is going to be destroyed immediately after this function returns. So to save CPU time, I can move the buffer inside that vector to my own vector (my own vector being the one that I would otherwise copy it into), and point the argument vector buffer to something empty instead.

When my function returns, the vector that is going to be destroyed now points to something empty. The data the vector pointed to has been stolen by my function. Never did I need to actually copy over all the data, completely pointlessly.

File: 15826138.jpg (25KB, 480x634px) Image search: [Google]

25KB, 480x634px

>>62343632
If you want a move constructor and move assignment that do moves, you’ll need to write them yourself.

>>62343642
That's a nice explanation, anon.

File: 15626158.jpg (29KB, 716x403px) Image search: [Google]

29KB, 716x403px

>>62343790
By the way you should return reference to an object iff:
1. The object itself is passed to the scope as a non-const reference
2. If the object is created within the function scope, it is static
3. In no other situation

Reminder that you don't also need multi-return functions, create the expected values first and pass them as non-cost references into the function. These are called out params.

>>62343822
The hormone imbalance from taking estrogen has caused your brain to atrophy.

>>62343360
>Friendly reminder that you should return reference to an object iff:
>1. The object itself is passed to the scope as a non-const reference
>2. If the object is created within the function scope, it is static
>3. In no other situation

Technically, this does not cover member functions returning references to member variables, which is certainly legitimate. Especially for overloaded operators.

>>62343790
based

>>62343360
>object oriented programming
off yourself

>>62343843
How is that related to OOP?

>>62343835
Member functions have a hidden this pointer passed into them

>>62343822
Like I said before spamming isn't a good look, I mostly meant that a polite way of saying it's actually a rule violation, I guess posting anime will probably give you a pass though, but you're still a dumb animeposter replying to the wrong person lmao

>>62343854
Yes. But OP's clause 1 only allows references, not pointers.

>>62343863
You are passing this reference, aren't you?

>>62343878
No, this is a pointer, not a reference.

Unless the idea behind OP's rules is that pointers are a type of reference and included in the rules. That would make some form of sense.

File: tumblr_o5uvvrb8XZ1u86t2qo1_540.gif (2MB, 540x303px) Image search: [Google]

2MB, 540x303px

>>62343889
As I said, you should return reference to an object iff:
1. The object itself is passed to the scope as a non-const reference
2. If the object is created within the function scope, it is static
3. In no other situation

Reminder that you don't also need multi-return functions, create the expected values first and pass them as non-cost references into the function. These are called out params.

File: 1503264177358.jpg (29KB, 559x813px) Image search: [Google]

29KB, 559x813px

>>62343901
Post an example.

>>62343935
anime website

>>62343960
There's a difference between hating anime and hating obnoxious weeb faggots though retard

>>62343960
GR 13 you cock dumpster.

>Do not use avatars or attach signatures to your posts.

At least trip up so we can filter you faggot.

File: question245.jpg (101KB, 1280x720px) Image search: [Google]

101KB, 1280x720px

Why do we even have references when we can just use pointers for everything?

File: tumblr_nzjgqljejU1uol5ypo1_1280.jpg (73KB, 670x670px) Image search: [Google]

73KB, 670x670px

>>62343956
Similar to pass by address, values returned by reference must be variables (you can not return a reference to a literal or an expression). When a variable is returned by reference, a reference to the variable is passed back to the caller. The caller can then use this reference to continue modifying the variable, which can be useful at times. Return by reference is also fast, which can be useful when returning structs and classes.

However, just like return by address, you should not return local variables by reference. Consider the following example:

1
2
3
4
5

int& doubleValue(int x)
{
int value = x * 2;
return value; // return a reference to value here
} // value is destroyed here

In the above program, the program is returning a reference to a value that will be destroyed when the function returns. This would mean the caller receives a reference to garbage. Fortunately, your compiler will probably give you a warning or error if you try to do this.

Return by reference is typically used to return arguments passed by reference to the function back to the caller. When to use return by reference:

When returning a reference parameter
When returning an element from an array that was passed into the function
When returning a large struct or class that will not be destroyed at the end of the function (e.g. one that was passed in)

When not to use return by reference:

Friendly reminder:
PAEDOPHILES WITH THEIR COLLECTION OF YOUNG CARTOON GIRLS ARE NOT ALLOWED HERE

>>62343981
Do you know what avatarfagging means you fucking reddit spill?

File: sample-abdf170683abd2e1bdf20caabd077c54.jpg (117KB, 925x1000px) Image search: [Google]

117KB, 925x1000px

what does return reference to an object mean

>>62343988
Thats nice.

Drop the fucking avatar.

>>62343986
There are two main reasons for references over pointers, and they both tl;dr to syntactic sugar.

One reason is that certain operators such as [] should return something you can assign to. Having that operator return a pointer rather than a reference would mean that arrays behave syntactically different from, say, vectors. And that would suck.

The other reason is that it allows functions to take const reference parameters to avoid needless copying, again without this optimization making a syntactic difference for the caller. This allows std::string::operator+= to look just like += for integers without unnecessary slowdowns.

File: 1426403694525.jpg (826KB, 1263x3071px) Image search: [Google]

826KB, 1263x3071px

>>62343960
Even moot hated you faggots

>>62343999
> le plebbit meme XD XD XD XD

Perhaps you should go learn what avatarfagging is, because you're doing it right now jimmy.

File: 1503101323806.gif (945KB, 400x225px) Image search: [Google]

945KB, 400x225px

>>62343988
Thank you.

>>62343986
Because passing pointers is less efficient

>>62344044
Now now, it took you 5 minutes to realize your mistake but you learned something new today :)

>>62344048
It isn't, it does the exact same thing a pointer would at low level.

File: 21151275.jpg (10KB, 261x210px) Image search: [Google]

10KB, 261x210px

>>62343988
ctd

When returning variables that were declared inside the function (use return by value)
When returning a built-in array or pointer value (use return by address)

Mixing return references and values

Although a function may return a value or a reference, the caller may or may not assign the result to a value or reference accordingly.

int returnByValue()
{
    return 5;
}
 
int& returnByReference()
{
     static int x = 5; // static ensures x isn't destroyed when it goes out of scope
     return x;
}
 
int main()
{
    int value = returnByReference(); // case A -- ok, treated as return by value
    int &ref = returnByValue(); // case B -- compile error since the value is an r-value, and an r-value can't bind to a non-const reference
    const int &cref = returnByValue(); // case C -- ok, the lifetime of the return value is extended to the lifetime of cref
}

In case A, we’re assigning a reference return value to a non-reference variable. Because value isn’t a reference, the return value is copied into value, as if returnByReference() had returned by value.

In case B, we’re trying to initialize reference ref with the copy of the return value returned by returnByValue(). However, because the value being returned doesn’t have an address (it’s an r-value), this will cause a compile error.

In case C, we’re trying to initialize const reference ref with the copy of the return value returned by returnByValue(). Because const references can bind to r-values, there’s no problem here. Normally, r-values expire at the end of the expression in which they are created -- however, when bound to a const reference, the lifetime of the r-value (in this case, the return value of the function) is extended to match the lifetime of the reference (in this case, cref)

File: 1439048257548.png (12KB, 902x136px) Image search: [Google]

12KB, 902x136px

>>62344033

>>62344062
Dereferencing pointer is just as expensive and it does nothing. Remember that pointers are just an int value, however your OS has to look for the underlying data structure or function pointed by the pointer

>>62344088
There's a big difference between people who don't like anime and people who complain about "ANIMU OTAKU KAWAII BAKA" faggots fyi

File: 1499267496414.jpg (953KB, 2600x2902px) Image search: [Google]

953KB, 2600x2902px

>>62344033
No one in this thread is speaking weebshit
Now quickly fuck off back to 9gag

>>62344089
I don't understand. Using a reference compiles into a pointer dereference in asm is what I meant.

>>62344104
Since when did you only have to "speak" weebshit? This is an imageboard after all, and images speak a thousand words.

>>62344104
>>62343981

Learn the difference, it may save you from looking like a faggot.

>>62343981
You're dumb. Lurk 2 years before posting.

File: 1501565683527.png (94KB, 777x441px) Image search: [Google]

94KB, 777x441px

>>62344114
Well then either put up or shut up, I suggest you to get out :)

File: 04-Akari-Akaza-YuruYuri.jpg (72KB, 848x480px) Image search: [Google]

72KB, 848x480px

>>62344110
When you pass a pointer to a function by address, the pointer’s value (the address it points to) is copied from the argument to the function’s parameter. In other words, it’s passed by value! If you change the function parameter’s value, you are only changing a copy. Consequently, the original pointer argument will not be changed.

#include <iostream>
 
void setToNull(int *tempPtr)
{
    // we're making tempPtr point at something else, not changing the value that tempPtr points to.
    tempPtr = nullptr; // use 0 instead if not C++11
}
 
int main()
{ 
    // First we set ptr to the address of five, which means *ptr = 5
    int five = 5;
    int *ptr = &five;
    
    // This will print 5
    std::cout << *ptr;
 
    // tempPtr will receive a copy of ptr
    setToNull(ptr);
 
    // ptr is still set to the address of five!
 
    // This will print 5
    if (ptr)
        std::cout << *ptr;
    else
        std::cout << " ptr is null";
 
    return 0;
}

tempPtr receives a copy of the address that ptr is holding. Even though we change tempPtr to point at something else (nullptr), this does not change the value that ptr points to. Consequently, this program prints:

55

Note that even though the address itself is passed by value, you can still dereference that address to change the argument’s value.

File: 15822597.jpg (5KB, 370x334px) Image search: [Google]

5KB, 370x334px

This is a common point of confusion, so let’s clarify:

When passing an argument by address, the function parameter variable receives a copy of the address from the argument. At this point, the function parameter and the argument both point to the same value.
If the function parameter is then dereferenced to change the value being pointed to, that will impact the value the argument is pointing to, since both the function parameter and argument are pointing to the same value!
If the function parameter is assigned a different address, that will not impact the argument, since the function parameter is a copy, and changing the copy won’t impact the original. After changing the function parameter’s address, the function parameter and argument will point to different values, so dereferencing the parameter and changing the value will no longer affect the value pointed to by the argument.

File: 1505024478721.png (110KB, 777x441px) Image search: [Google]

110KB, 777x441px

>>62344135

File: 1466418476816.png (97KB, 1366x585px) Image search: [Google]

97KB, 1366x585px

>>62344163
I still don't understand, why are still you in this thread? I never realized why do sjws get so buttflustered by anime and frogs, really

>>62344204
>resorting to SJW shit
Come on now anon, this isn't /pol/. I was actually enjoying this little debate too...

>>62344204
see
>>62343981

Just because you're choosing to be retarded, does not mean you are not actually retarded.

>>62344214
Go learn what avatarfagging means in the first place, newfag

>>62344156
Yeah I know how pointers work. I was saying that using references is not more efficient than using pointers. When you pass by reference, at low level it is still actually passing a pointer. It generates the same code as passing a pointer would. It is purely a language difference.

>>62344259
This

References are implemented in pointers

File: 1477875882841.jpg (99KB, 448x537px) Image search: [Google]

99KB, 448x537px

Ranges in C++ WHEN?
Modules in C++ WHEN?
UFCS in C++ WHEN?

>>62344311
They fucked up the UFCS
https://isocpp.org/blog/2016/02/a-bit-of-background-for-the-unified-call-proposal

File: 7df821f3a168f965ac7464977aeaf062.jpg (397KB, 1013x1175px) Image search: [Google]

397KB, 1013x1175px

>>62344204
>598 year old vampire

>>62344204
>It's real
lmao

>>62344204
Just realized
>6+2chan /tech/
>calling anyone who doesn't agree with them an SJW
What a surprise!

File: 1455892775728.jpg (38KB, 362x346px) Image search: [Google]

38KB, 362x346px

>>62344311
I wonder how they will implement modules. Won't this fuck up backwards compatibility?

I guess they can't ever implement modules.

>>62344349
They could have learned UFCS from D or Nim or even Rust

File: 1503673175518.png (281KB, 371x532px) Image search: [Google]

281KB, 371x532px

honestly lads should I kys myself soon?

>>62345665
Wrong thread, onii chan

File: 1401400183270.jpg (961KB, 1766x1734px) Image search: [Google]

961KB, 1766x1734px

>>62345677
In my eyes this was actually the perfect thread
Also sick dubs anon-chu

>>62344204
it is funny that the article in that image frames 4chan as a cohesive entity capable of collectively caring about image enough to have stopped using pedobear because of backlash

File: 1493922197140.png (197KB, 842x848px) Image search: [Google]

197KB, 842x848px

brat a shit