>i love c++
you dont use it

>>101196508
Of course I use it. I've been using it for a year and a half. I've made several projects using it including my own portion of the STL.

Categories besides lvalue and rvalue are never worth thinking about when actually writing code. They only exist for the committee to specify behavior for.

>>101196611
>besides lvalue and rvalue

You realize you've just said all 3 value categories right? An rvalue isn't just one thing. It can be either an xvalue or prvalue. A Prvalue is a literal other than a string literal (because string literals like "hello" are stored in the read-only areas of memory and can have their address printed i.e:

std::cout << std::addressof("Hello");

)
And and xvalue. Both of those are technically "rvalues"

>>101196651
>You realize you've just said all 3 value categories right?
Yes, I'm saying memorizing the distinction between their subcategories is pointless. Knowing whether an rvalue is an xvalue or prvalue won't change how you write code.

>>101196521
>for a year and a half
you are merely a c++ babby taking his first few steps

>>101196859
Kek, you're right. I'm learning new things every day.

File: e71.png (274 KB, 680x785)

274 KB PNG

i learn about C++ just to hate on it

File: 1717686512813196.png (10 KB, 708x800)

10 KB PNG

>>101196700
You can't just say that!!

>>101196466
yes. rvalue reference != rvalue
kind of like how a foo reference is not a foo in terms of types.


what is it you have a problem with?

>>101196466
the whole point of value semantics is to differentiate temporary values from persistent values.
C++ do this by first declaring temporaries as rvalues, and then giving us the mechanism to reference those via rvalue references. An rvalue reference is not a value catagory, it is a special type of reference that can only be initialized FROM an rvalue, therein guaranteeing you it is temporary and thats how we differentiate them.

lvalue reference = reference to a persistent
rvalue reference = reference to a temporary.

All rvalue references are lvalues, just like how all lvalue references are lvalues.

and then there are special cases like const lvalue reference which can be both.

>>101197685
>which can be both
can reference both*

>>101196466
>In this example, 'a' has a type of rvalue-reference
a has the variable type "data" and the reference type rvalue reference.

After c++11 there are 2 reference types: lvalue reference and rvalue reference. This is probably what confuses you, you are used to there only being 1.

>>101196466
>Apparently
>a' has a type of rvalue-reference, but its value category is an lvalue since it's a named object.
Well whoever told you that couldn't read.
rvalue-references are not objects.
https://en.cppreference.com/w/cpp/language/reference
>References are not objects; they do not necessarily occupy storage, although the compiler may allocate storage if it is necessary to implement the desired semantics (e.g. a non-static data member of reference type usually increases the size of the class by the amount necessary to store a memory address).

>>101197685
There are also forwarding references

template <class T>
void foo(T &&t) { ... }

which preserve the value category of the argument.

>>101197856
>>101197685
Yeah I think I understand now.
Even though you can for example do this:

int&& c (42);

it still compiles because really, `c` is referring to a value with no address (an rvalue '42') so even though the type is technically an rvalue reference, it still allocates memory for the object.

Does that sound right?

>>101196466
Thanks for reminding me why I use C. So much less complicated.

>>101197977
i think your confusion arises from trying to comprehend what rvalues mean in practice. Dont do this, not even the standard really concerns itself with this.

As far as the language goes rvalues are not "value that dont exist on the heap or the stack" they're just "temporaries". Whether they end up existing on the stack or the heap is up to the implementer to determine.

The practical usefulness of rvalues is to be able to tell when you can "steal" resources from an object, not to avoid allocation in the first place.

>>101198007
> rvalues are not "value that dont exist on the heap or the stack" they're just "temporaries"

Yeah but the standard makes clear that objects marked with std::move are xvalues since their lifetime is expiring. Otherwise it's a prvalue. That's the tl;dr

>>101198026
yeah but you cant differentiate between an xvalue and a prvalue as the programmer so its not like you can take advantage of it anyway.

I'm pretty sure they're just defined separately for clarity. Im 99% sure there is no statement in the standard that says something like "rvalue references to prvalues are guarenteed to never take up stack space"

>>101198044
> Im 99% sure there is no statement in the standard
Kinda hard if one is wanting to be a language lawyer.

>>101197977
>it still allocates memory for the object.
No, it doesn't have to. It might if it's necessary, but in such simple cases it usually won't have to.

>>101198004
>much less complicated
lmao. What does.this expression essential to the Linux kernel compute? No googling

(sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8)))

>>101196859
lol, no
C++ is huge that's right but sane people only use like 1/3 of the language which is learnable in 1,5 years

>>101198153
Yep sorry, you're right. The lvalue is placed on the stack frame which means it doesn't *need* to be allocated since there's already memory for it to be stored in.
I had to re-lookup the basics of memory.

>>101198175
The language syntax and language rules are much less complicated than C++.

Also, the code is evaluating whether the size of int equal to the dereferenced `x` which is cast to a long and multiplied by 1, which is then cast to a void pointer, which was dereferenced, otherwise `8` which is then cast to an integer pointer. But all that is syntactic sugar because
[copde[
sizeof(*8(...)...)
[/code]
will always evaluate to true. My C is a bit hazy.

>>101198289
Wrong, it evaluates whether or not x is a compile-time constant.
I'll let you figure out how. C is a simple language after all.

>>101198224
Which lvalue? There's no lvalue in

int&& c(42)

rvalue references are only lvalues when used in expressions

>>101198460
Dude, lol, that syntax is ugly.
Just because you write something complicated doesn't mean the language its-self is complicated.

C's standard library is less than half of C++'s, and it has far fewer keywords.

>>101198485
>Just because you write something complicated doesn't mean the language its-self is complicated.
What is your simpler solution to evaluate whether or not x is a compile-time constant?

>>101198485
C standard is not enough to code in C. You also have to understand the unspoken assumptions that are accepted by compilers but absent from the standard.
And the ABI, which isn't part of the standard.

>>101198490
>What is your simpler solution
You're failing to see my point.
Yes you can make complicated formulas (like the one you posted earlier) but that doesn't mean the language its-self is complicated.

It is a fact, that C is a small and simple language, which is why it dominates many low level fields like os/kernel dev, embedded, and lang dev.

>>101198530
>Yes you can make complicated formulas (like the one you posted earlier) but that doesn't mean the language its-self is complicated.
Do you understand that this is a complex expression necessary to access a very simple information?

>It is a fact, that C is a small and simple language, which is why it dominates many low level fields like os/kernel dev, embedded, and lang dev
It's small, not simple. It dominates LL because it's easy to implement.
>lang dev
lmao, no

>>101198545
>It's easy to implement
>It's not simple

Pick one.

>>101198552
Have you figured out yet how the expression evaluates the constexpr-ness of x?
It's not even a very long expression. It should be possible to understand it since C is a simple language.

>>101198552
>decades of VHDL and cross-platform compilers all aiming for C first
>"Hurr durr guys I wrote some tablegen files, pushed a button and got my C compiler so easily"
>"nevermind the millions of LoC stack I just went through"

>>101197327
If you get a template error, good luck reading the output.

>>101196466
>Don't get me wrong, I love C++
typical shill post

>>101200968
>Someone likes something I don't therefore they're a shill.

people who hate C++ are either beginners or have very many years on it. people in the middle love it.

>>101203982
Kek that's actually accurate.
But I guess the more you use something, the more you understand the downsides of something. It isn't unique to C++.

>>101204118
it could also be that they learned a certain way to do something that's now "obsolete."

>>101199247
concepts were added to address this.

C++ sucks ass
Rust sucks a bit less ass
Zig is where it's at

>>101204157
yes, boomers are mentally ill and cannot continuously learn things the way I do literally things that were added less than 10 years ago without a single problem.

>>101207629
Zig has no traction and its docs suck ass.

File: images.jpg (7 KB, 206x245)

7 KB JPG

>>101207629
aren't you forgetting someone?

>>101196466

prove you're a C++ fag and explain these to me

 
 X*
 &X
 
 X**
 X*[]

 X()
 X(X)
 new X()
 new X(new X())

 X&&
 
 do not even get me started on const

>>101196466
how is any of this useful knowledge? C++ newb, legit question

>>101210935
Because it goes into how the compiler and programmers are able to transfer and represent data.

>>101198175
>8 ?
Can someone explain this? Wouldn't it always evaluate the truthy side?

>>101211200
yes but who is actually using this in their day-to-day

>>101212054
Compiler devs who work on optimizations.
Plus anyone who actually has an interest in writing fully optimized code.

It's part of the language. Might as well learn it.

>>101212066
fair enough

>>101210855
>pointer to X
>lvalue reference to X
>pointer to pointer to X
>pointer to array (pointer+size) of X elements
>function called X
>Passing a function pointer to X to X
>initialize a new X object via its constructor
>initialize a new X via its constructor to initialize a new X via its copy constructor (leaks the first X)
>rvalue refrence to an X

>>101212290
>>initialize a new X via its constructor to initialize a new X via its copy constructor (leaks the first X)
assuming there is a copy constructor that accepts a pointer to X, which there isn't by default so probably just invalid.

>>101210935
you can avoid copies when you know the value you are given is a temporary

thats what value categories /rvalue refs give us: the ability to distinguish temporary values from persistent ones so we can take advantage of it.

>>101198175
>>101211289
nta but I was also wondering. found this by googling the entire expression:
https://stackoverflow.com/questions/49481217/linux-kernels-is-constexpr-macro